From jvasseur@cisco.com Wed Oct 3 03:28: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 D732C21F849A for ; Wed, 3 Oct 2012 03:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=0.974, 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 n9WhzEqQVSr5 for ; Wed, 3 Oct 2012 03:28:26 -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 2928B21F8489 for ; Wed, 3 Oct 2012 03:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3529; q=dns/txt; s=iport; t=1349260106; x=1350469706; h=from:to:cc:subject:date:message-id:mime-version; bh=Zyt9XtV0LCdtmDdHuQ/iDGQkBKZSdnGz2IrZzZmMRhg=; b=nBJ0AY0p1Xf3O4JH/nOqZazBXUITuH16g7uGWWi3tRxatjp+HuE0LxHv //XbW6WATKlfOiJy+IOqhWbcu81nmAqz6qYRJ5TThxi6uhhS0az63WyYy hV+4elhQx/kGaAYiUiN308lSwXaG+DAo0mmyvCjWlDHw22cTlvjTxiujP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOURbFCtJV2d/2dsb2JhbABFgku8J4EIgiIBBBIBZhIBDB5WJwQODRqHY5hIoACLI4VaYAOkK4Fpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208,217";a="127817894" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2012 10:28:25 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q93ASNTI010358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 10:28:23 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.82]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 05:28:23 -0500 From: "JP Vasseur (jvasseur)" To: roll WG Thread-Topic: Adoption of draft-richardson-roll-applicability-template as a WG document Thread-Index: AQHNoVHQIjgRX0aakUezrH0Bx5cMQA== Date: Wed, 3 Oct 2012 10:28:22 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721F8597D@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.60.114.229] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--27.041800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721F8597Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [Roll] Adoption of draft-richardson-roll-applicability-template as a WG document 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, 03 Oct 2012 10:28:26 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721F8597Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG, As you know, we've been having several milestone to deliver applicability d= ocuments and it is now time to move forward =85 Oct 2012 WG to adopt RPL applicability statement for Industrial appl= ications Oct 2012 WG to adopt RPL applicability statement Home for Automation= applications Oct 2012 WG to adopt RPL applicability statement(s) for AMI networks Dec 2012 WG to adopt RPL applicability statement Building Automation= applications To that end, Michael put together a document (draft-richardson-roll-applica= bility-template) proposing the use of a template for all of these requireme= nts documents. Such a document help definitely help us move forward. I would proposed a 1-week WG last call to adopt draft-richardson-roll-appli= cability-template as a WG - please tell us if you have any objection no lat= er than Oct 11th at noon ET. We also hope to see some of the applicability documents for the next IE= TF. Many Thanks. JP. --_000_03B78081B371D44390ED6E7BADBB4A7721F8597Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Dear WG,

As you know, we've been having several milestone to deliver applicabil= ity documents and it is now time to move forward =85 

Oct 2012 WG to adopt RPL applicability statement for Industrial applications
Oct 2012 WG to adopt RPL applicability statement Home for Automation application= s
Oct 2012 WG to adopt RPL applicability statement(s) for AMI networks
Dec 2012 WG to adopt RPL applicability statement Building Automation application= s

To that end, Michael put together a document (draft-richardson-roll-ap= plicability-template) proposing the use of a template for all of these= requirements documents. Such a document help definitely help us move forwa= rd.

I would proposed a 1-week WG last call to adopt draft-richardson-= roll-applicability-template as a WG - please tell us if you have any object= ion no later than Oct 11th at noon 
ET. We also hope to see some of the applicability documents for the ne= xt IETF.

Many Thanks.

JP.
--_000_03B78081B371D44390ED6E7BADBB4A7721F8597Dxmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Oct 4 05:03:39 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 0CB3821F8532 for ; Thu, 4 Oct 2012 05:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, 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 lbAJ6tTf-e5L for ; Thu, 4 Oct 2012 05:03:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 618A021F8505 for ; Thu, 4 Oct 2012 05:03:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so536600vcb.31 for ; Thu, 04 Oct 2012 05:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=y1NhqgRZ2/XGhTNTm31WIjWuqMWdGv88o6I03d3nLgM=; b=W4PMQ+3C4QHDJ/uVnJxgoW+0Ft9M21SyKWfeHZ3EPZE7O9vRIjH2xP+t2scSwbon7L 0jQIraBZOLs3C6CGQn5YL6gQPK0khKbMjN5jRslFOkyxobeGdrVf2rCIl30rQSh2Nssa JDld1DogygZsSyMT0U3bsnMwANpLkywyP10wpxbvW6VFDSQbwXGfQkj1OzrVAWDx3xWt LjEZTDGhP4E7UN7FbtgaKGMt9mewWetJ5keumhLF+v4QD4e9AE6W9nehcxYO3xFSi6Ek wiLYYUFvdaGJ3ACXzVdoQx5+UxqVj9EUZt1BuStiTeLjPql7AkdrvP1FEUt7HWuCuHbK oeyA== MIME-Version: 1.0 Received: by 10.220.119.198 with SMTP id a6mr3018195vcr.23.1349352217743; Thu, 04 Oct 2012 05:03:37 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 4 Oct 2012 05:03:37 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721F8597D@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721F8597D@xmb-rcd-x02.cisco.com> Date: Thu, 4 Oct 2012 13:03:37 +0100 Message-ID: From: Abdussalam Baryun To: roll WG Content-Type: multipart/alternative; boundary=bcaec54fb6249d902f04cb3a8bed Subject: Re: [Roll] Adoption of draft-richardson-roll-applicability-template as a WG document 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, 04 Oct 2012 12:03:39 -0000 --bcaec54fb6249d902f04cb3a8bed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1, no objection, AB On Wed, Oct 3, 2012 at 11:28 AM, JP Vasseur (jvasseur) wrote: > Dear WG, > > As you know, we've been having several milestone to deliver > applicability documents and it is now time to move forward =85 > > Oct 2012 WG to adopt RPL applicability statement for Industrial > applications Oct 2012 WG to adopt RPL applicability statement Home for > Automation applications Oct 2012 WG to adopt RPL applicability > statement(s) for AMI networks Dec 2012 WG to adopt RPL applicability > statement Building Automation applications > > To that end, Michael put together a document > (draft-richardson-roll-applicability-template) proposing the use of a > template for all of these requirements documents. Such a document help > definitely help us move forward. > > I would proposed a 1-week WG last call to > adopt draft-richardson-roll-applicability-template as a WG - please tell = us > if you have any objection no later than Oct 11th at noon > ET. We also hope to see some of the applicability documents for the next > IETF. > > Many Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --bcaec54fb6249d902f04cb3a8bed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1, no objection,
=A0
AB
On Wed, Oct 3, 2012 at 11:28 AM, JP Vasseur (jvasseur) <jvass= eur@cisco.com> wrote:
Dear WG,

As you know, we've been having several milestone to deliver applic= ability documents and it is now time to move forward =85=A0

Oct 2012 WG to adopt RPL applicability statement for Industrial applications
Oct 2012 WG to adopt RPL applicability statement Home for Automation application= s
Oct 2012 WG to adopt RPL applicability statement(s) for AMI networks
Dec 2012 WG to adopt RPL applicability statement Building Automation application= s

To that end, Michael put together a document (draft-richardson-roll-ap= plicability-template)=A0proposing the use of a template for all of these re= quirements documents. Such a document help definitely help us move forward.=

I would proposed a 1-week WG last call to adopt=A0draft-richardson-rol= l-applicability-template as a WG - please tell us if you have any objection= no later than Oct 11th at noon=A0
ET. We also hope to see some of the applicability documents for the ne= xt IETF.

Many Thanks.

JP.

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


--bcaec54fb6249d902f04cb3a8bed-- From robert.assimiti@nivis.com Thu Oct 4 12:23: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 E984F21F8634 for ; Thu, 4 Oct 2012 12:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 EaM1nVF8Dxur for ; Thu, 4 Oct 2012 12:23:55 -0700 (PDT) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13C21F86DC for ; Thu, 4 Oct 2012 12:23:55 -0700 (PDT) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 4 Oct 2012 15:23:53 -0400 From: Robert Assimiti To: "JP Vasseur (jvasseur)" , roll WG Date: Thu, 4 Oct 2012 15:23:52 -0400 Thread-Topic: [Roll] Adoption of draft-richardson-roll-applicability-template as a WG document Thread-Index: Ac2hmVxToOn40BETTXijbhS615bsFgAy5m0g Message-ID: <67442429D9C35E4C975B89BE73BD33D02F89E5B004@ATLEXCH02.nivis.com> References: <03B78081B371D44390ED6E7BADBB4A7721F8597D@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721F8597D@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_67442429D9C35E4C975B89BE73BD33D02F89E5B004ATLEXCH02nivi_" MIME-Version: 1.0 Subject: Re: [Roll] Adoption of draft-richardson-roll-applicability-template as a WG document 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, 04 Oct 2012 19:23:57 -0000 --_000_67442429D9C35E4C975B89BE73BD33D02F89E5B004ATLEXCH02nivi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JP, We in the process of reformatting the industrial applicability statement to= meet the template proposed by Michael. Thanks Robert Assimiti Nivis Director of Technology and Standards Office [678]-202-6859 Mobile [404]-578-0205 From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] Sent: Wednesday, October 03, 2012 6:28 AM To: roll WG Subject: [Roll] Adoption of draft-richardson-roll-applicability-template as= a WG document Dear WG, As you know, we've been having several milestone to deliver applicability d= ocuments and it is now time to move forward ... Oct 2012 WG to adopt RPL applicability statement for Industrial applications Oct 2012 WG to adopt RPL applicability statement Home for Automation applications Oct 2012 WG to adopt RPL applicability statement(s) for AMI networks Dec 2012 WG to adopt RPL applicability statement Building Automation applications To that end, Michael put together a document (draft-richardson-roll-applica= bility-template) proposing the use of a template for all of these requireme= nts documents. Such a document help definitely help us move forward. I would proposed a 1-week WG last call to adopt draft-richardson-roll-appli= cability-template as a WG - please tell us if you have any objection no lat= er than Oct 11th at noon ET. We also hope to see some of the applicability documents for the next IE= TF. Many Thanks. JP. --_000_67442429D9C35E4C975B89BE73BD33D02F89E5B004ATLEXCH02nivi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JP,<= /o:p>

 

We in the process of reformatting the industrial a= pplicability statement to meet the template proposed by Michael.=

 

Thanks

 

Robert Ass= imiti

Nivis

Director of Technology and= Standards

Office [= 678]-202-6859

Mobile [404]-578-0205

 

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent= : Wednesday, October 03, 2012 6:28 AM
To: roll WG
Subje= ct: [Roll] Adoption of draft-richardson-roll-applicability-template as = a WG document

&n= bsp;

Dear WG,

 

As you know,= we've been having several milestone to deliver applicability documents and= it is now time to move forward … 

 

Oct 2012

WG to adopt RPL applicability statem= ent for Industrial applications

Oct 2012

WG t= o adopt RPL applicability statement Home for Automation applications

=

Oct 2012

WG to adopt RPL applicability statement(s)= for AMI networks

= Dec 2012

WG to adopt RPL ap= plicability statement Building Automation applications

 

To that end, Michael put together a document (= draft-richardson-roll-applicability-template) proposing the use of a t= emplate for all of these requirements documents. Such a document help defin= itely help us move forward.

<= o:p> 

I would proposed a 1-we= ek WG last call to adopt draft-richardson-roll-applicability-template = as a WG - please tell us if you have any objection no later than Oct 11th a= t noon 

ET. We also hope= to see some of the applicability documents for the next IETF.

 

Many Thanks.

 

JP.

<= /div>= --_000_67442429D9C35E4C975B89BE73BD33D02F89E5B004ATLEXCH02nivi_-- From cabo@tzi.org Thu Oct 4 15:09:32 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 87EDD21F8589; Thu, 4 Oct 2012 15:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 9WRXWDj-3qu1; Thu, 4 Oct 2012 15:09:31 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1621F8588; Thu, 4 Oct 2012 15:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q94M9NtP022650; Fri, 5 Oct 2012 00:09:23 +0200 (CEST) Received: from [192.168.217.117] (p548920DE.dip.t-dialin.net [84.137.32.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65763311; Fri, 5 Oct 2012 00:09:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 00:09:22 +0200 To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [Roll] Constrained Node/Network Cluster @ IETF85 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, 04 Oct 2012 22:09:32 -0000 Here is my usual eclectic condensed agenda. I'm sure we'll have a lot of ad-hoc meetings, too, but these are the = current WG meeting that could be considered part of a Constrained = Node/Network Cluster (or might impact it). As you can see, lwig is currently on top of Friday's core meeting, and = that will have to change. Apart from that, the damage seems to be limited this time, at least = before the usual round of swaps. See you all in Atlanta! Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting = - Combined with APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I GrBlrm C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG roll Routing Over Low power and Lossy = networks WG GrBlrm D TSV tsvarea Transport Area Open Meeting=20 TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis = WG GrBlrm D INT homenet Home Networking WG 1300-1500 Afternoon Session I GrBlrm C APP core Constrained RESTful Environments = WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon A SEC jose Javascript Object Signing and = Encryption WG 1300-1430 Afternoon Session I GrBlrm D SEC httpauth HTTP Authentication Mechanisms = BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I GrBlrm D RTG rtgarea Routing Area Open Meeting=20 Salon E TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG GrBlrm C TSV tsvwg Transport Area Working Group WG Salon C SEC saag Security Area Open Meeting=20 FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Salon E APP core Constrained RESTful Environments = WG Salon C INT lwig Light-Weight Implementation = Guidance WG 1230-1330 Afternoon Session II Salon E APP core Constrained RESTful Environments = WG Salon C INT lwig Light-Weight Implementation = Guidance WG From adrian@olddog.co.uk Fri Oct 5 03:31: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 7EA9F21F861E for ; Fri, 5 Oct 2012 03:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdCo1EWkFq7p for ; Fri, 5 Oct 2012 03:31:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 658A521F8618 for ; Fri, 5 Oct 2012 03:31:23 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95AVK9v010922 for ; Fri, 5 Oct 2012 11:31:20 +0100 Received: from 950129200 ([31.100.97.218]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95AVHJE010899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Oct 2012 11:31:19 +0100 From: "Adrian Farrel" To: Date: Fri, 5 Oct 2012 11:31:15 +0100 Message-ID: <10a501cda2e4$8eb25ef0$ac171cd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2i4s0QlKi8vKo2TbKvDZWWBGajZg== Content-Language: en-gb Subject: [Roll] FW: RFC 6687 on Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:31:26 -0000 The ROLL WG will want to be aware of this new RFC. Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: 04 October 2012 22:55 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org > Subject: RFC 6687 on Performance Evaluation of the Routing Protocol for Low- > Power and Lossy Networks (RPL) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6687 > > Title: Performance Evaluation of the Routing > Protocol for Low-Power and Lossy Networks > (RPL) > Author: J. Tripathi, Ed., > J. de Oliveira, Ed., > JP. Vasseur, Ed. > Status: Informational > Stream: Independent > Date: October 2012 > Mailbox: jt369@drexel.edu, > jau@coe.drexel.edu, > jpv@cisco.com > Pages: 26, > Characters: 63624 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-tripathi-roll-rpl-simulation-08.txt > > URL: http://www.rfc-editor.org/rfc/rfc6687.txt > > This document presents a performance evaluation of the Routing > Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor > deployment of sensor nodes and for a large-scale smart meter network. > Detailed simulations are carried out to produce several routing > performance metrics using these real-life deployment scenarios. > Please refer to the PDF version of this document, which includes > several plots for the performance metrics not shown in the plain-text > version. This document is not an Internet Standards Track specification; > it is published for informational purposes. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC From internet-drafts@ietf.org Fri Oct 5 11:10: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 D9DAE21F87F4; Fri, 5 Oct 2012 11:10:45 -0700 (PDT) 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 bfeH+LiBJA3y; Fri, 5 Oct 2012 11:10:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B93B21F87DE; Fri, 5 Oct 2012 11:10:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005181045.4795.47892.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 11:10:45 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-00.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: Fri, 05 Oct 2012 18:10:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : A Security Threat Analysis for Routing over Low Power an= d Lossy Networks Author(s) : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Filename : draft-ietf-roll-security-threats-00.txt Pages : 47 Date : 2012-10-05 Abstract: This document presents a security threat analysis for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-security-threats-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jvasseur@cisco.com Sat Oct 6 02:37:04 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 D1A4B21F8678 for ; Sat, 6 Oct 2012 02:37:04 -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 R9q6wkXz00qY for ; Sat, 6 Oct 2012 02:37:04 -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 D49D121F867E for ; Sat, 6 Oct 2012 02:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=159; q=dns/txt; s=iport; t=1349516224; x=1350725824; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fvFclOL4LEqk2mL2XyTCHKxPOe5MDP+I+ChVbz/HQTE=; b=blQpaJYC5eeTP649zkG8+CPvlNgCYIAqzXOKZMe3IHwOba0bzghjRrWs g4rZ1JWj5QcPy138u6gxP4NVqNl6EJYpb9Xi1n8YMdYvrycUlkFyIUpWU 6LnCzhhpYYdHhcY847YmRCP1/voQt0OeBfxXjuS8m7DGR3+EXK0mkouya o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0KAKv6b1CtJXG8/2dsb2JhbABFvg8EA4ELgQiCIgEEEgEnUQEqFEInBBsah2OYGoEon3KQbWADpDCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="128937847" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 06 Oct 2012 09:37:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q969b3er000559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Oct 2012 09:37:03 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.82]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Sat, 6 Oct 2012 04:37:03 -0500 From: "JP Vasseur (jvasseur)" To: roll WG Thread-Topic: ROLL WG Agenda IETF85 Thread-Index: AQHNo6Yk+PRcaDPFO0aZZPusKmgXtA== Date: Sat, 6 Oct 2012 09:37:02 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721F9CB03@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.79.165] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19246.000 x-tm-as-result: No--30.463200-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 Subject: [Roll] ROLL WG Agenda IETF85 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, 06 Oct 2012 09:37:04 -0000 Dear all, The ROLL WG will meet in Atlanta. Please let us not later than Oct 17 if yo= u would like to request a "presentation" slot ? Thanks. JP.= From cabo@tzi.org Sun Oct 7 02:32: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 33DD921F8522; Sun, 7 Oct 2012 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.924 X-Spam-Level: X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 ADCXvlu727Zk; Sun, 7 Oct 2012 02:32:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D921F8514; Sun, 7 Oct 2012 02:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q979WP7i026511; Sun, 7 Oct 2012 11:32:25 +0200 (CEST) Received: from [192.168.217.105] (p54891E9D.dip.t-dialin.net [84.137.30.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 475A688A; Sun, 7 Oct 2012 11:32:25 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Carsten Bormann In-Reply-To: Date: Sun, 7 Oct 2012 11:32:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1498) Subject: Re: [Roll] [6lowpan] Constrained Node/Network Cluster @ IETF85 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, 07 Oct 2012 09:32:35 -0000 On Oct 5, 2012, at 00:09, Carsten Bormann wrote: > Here is my usual eclectic condensed agenda. ... and here is an update based on yesterday's changes. As you can see, the lwig/core overlap is fixed (thanks, Barry), and = there have been a few other relocations to avoid other conflicts. Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting - Combined with = APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I Salon D APP httpbis Hypertext Transfer Protocol Bis WG Grand C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG *** roll Routing Over Low power and Lossy networks WG Grand D TSV tsvarea Transport Area Open Meeting 1740-1940 Afternoon Session III Salon E INT *** lwig Light-Weight Implementation Guidance WG TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis WG 1300-1500 Afternoon Session I Grand C APP *** core Constrained RESTful Environments WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon D INT homenet Home Networking WG Salon A SEC jose Javascript Object Signing and Encryption WG 1300-1430 Afternoon Session I Grand D SEC httpauth HTTP Authentication Mechanisms BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I Salon D OPS v6ops IPv6 Operations WG Grand D RTG rtgarea Routing Area Open Meeting Salon E TSV rmcat RTP Media Congestion Avoidance Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG Salon D OPS v6ops IPv6 Operations WG Salon C SEC saag Security Area Open Meeting Grand C TSV tsvwg Transport Area Working Group WG FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1330 Afternoon Session I/II Salon E APP *** core Constrained RESTful Environments WG From jvasseur@cisco.com Sun Oct 7 21:59: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 CBB0221F870E for ; Sun, 7 Oct 2012 21:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 UXFO07KhlPKE for ; Sun, 7 Oct 2012 21:59:50 -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 1812621F86EB for ; Sun, 7 Oct 2012 21:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16642; q=dns/txt; s=iport; t=1349672375; x=1350881975; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FCDiL7bQAlp9x/YP5uLtCInCub6QCSihz3u/tvmUhqc=; b=lbCmSS2rzzRJp93BeuHqQTd06S3vvjc6fNe1v8QupqIbGAW9OmISu3N5 87WO4Lzs5bvfspVybIfe0pYTXhOsnKBcSjZf67UQMI/dPtRuf0y69AR7O 0+BvbbXz3Nfw5C+Y05snjdEdY25hym3HfGUxPkCHvSSr+/wLaDuqepMhA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPZcclCtJXHA/2dsb2JhbABCA4JLvFuBCIIgAQEBBBIBZg4CAgEIEQQBAQsdBxYcFAkIAgQBDQUIEgiHY5knnn0Ei0uCaoJGYAOkMIFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,549,1344211200"; d="scan'208,217";a="129210126" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2012 04:59:34 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q984xYgK009957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 04:59:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 23:59:34 -0500 From: "JP Vasseur (jvasseur)" To: Robert Assimiti , Anders Brandt Thread-Topic: [Roll] Adoption of draft-richardson-roll-applicability-template as a WG document Thread-Index: AQHNpRG1KHAOaN8B90u+DmhPnjvKnA== Date: Mon, 8 Oct 2012 04:59:33 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FB2CB7@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721F8597D@xmb-rcd-x02.cisco.com> <67442429D9C35E4C975B89BE73BD33D02F89E5B004@ATLEXCH02.nivis.com> In-Reply-To: <67442429D9C35E4C975B89BE73BD33D02F89E5B004@ATLEXCH02.nivis.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--46.026300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FB2CB7xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: roll WG Subject: Re: [Roll] Adoption of draft-richardson-roll-applicability-template as a WG document 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, 08 Oct 2012 04:59:53 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FB2CB7xmbrcdx02ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Robert, On Oct 4, 2012, at 12:23 PM, Robert Assimiti wrote: JP, We in the process of reformatting the industrial applicability statement to= meet the template proposed by Michael. This is a great news, thanks - We are looking forward to moving forward on = that end. Anders, do you think that you could proceed similarly on the home automatio= n applicability side ? Many Thanks. JP. Thanks Robert Assimiti Nivis Director of Technology and Standards Office [678]-202-6859 Mobile [404]-578-0205 From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] Sent: Wednesday, October 03, 2012 6:28 AM To: roll WG Subject: [Roll] Adoption of draft-richardson-roll-applicability-template as= a WG document Dear WG, As you know, we've been having several milestone to deliver applicability d= ocuments and it is now time to move forward =85 Oct 2012 WG to adopt RPL applicability statement for Industrial applications Oct 2012 WG to adopt RPL applicability statement Home for Automation applications Oct 2012 WG to adopt RPL applicability statement(s) for AMI networks Dec 2012 WG to adopt RPL applicability statement Building Automation applications To that end, Michael put together a document (draft-richardson-roll-applica= bility-template) proposing the use of a template for all of these requireme= nts documents. Such a document help definitely help us move forward. I would proposed a 1-week WG last call to adopt draft-richardson-roll-appli= cability-template as a WG - please tell us if you have any objection no lat= er than Oct 11th at noon ET. We also hope to see some of the applicability documents for the next IE= TF. Many Thanks. JP. --_000_03B78081B371D44390ED6E7BADBB4A7721FB2CB7xmbrcdx02ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Robert,

On Oct 4, 2012, at 12:23 PM, Robert Assimiti wrote:

JP,
 
We in the process of reformatting the industrial applicab= ility statement to meet the template proposed by Michael.=
 

This is a great news, thanks - We are looking forward to moving forwar= d on that end.

Anders, do you think that you could proceed similarly on the home auto= mation applicability side ?

Many Thanks.

JP.

Thanks
 
Robert Assimiti
Nivis
Director of Technology and Standards=
Office [678]-202-6859<= o:p>
Mobile [404]-578-0205
 
From:=  JP Vasseur (jvasseur)= [mailto:jvasseur@cisco.com] 
Sent: Wednesday, O= ctober 03, 2012 6:28 AM
To: roll WG
Subject: [Roll] Ad= option of draft-richardson-roll-applicability-template as a WG document
 
Dear WG,
 
As you know, we've been having several milestone to deliver applicability d= ocuments and it is now time to move forward =85 
 
Oct 2012
WG to adopt RPL applicability statement for Industrial applications
Oct 2012
WG to adopt RPL applicability statement Home for Automation application= s
Oct 2012
WG to adopt RPL applicability statement(s) for AMI networks<= /span>
Dec 2012
WG to adopt RPL applicability statement Building Automation application= s
 
To that end, Michael put together a document (draft-richardson-roll-applica= bility-template) proposing the use of a template for all of these requ= irements documents. Such a document help definitely help us move forward.
 
I would proposed a 1-week WG last call to adopt draft-richardson-roll-= applicability-template as a WG - please tell us if you have any objection n= o later than Oct 11th at noon 
ET. We also hope to see some of the applicability documents for the next IE= TF.
 
Many Thanks.
 
JP.

--_000_03B78081B371D44390ED6E7BADBB4A7721FB2CB7xmbrcdx02ciscoc_-- From Gerald.Paprocki@us.elster.com Mon Oct 8 12:07:31 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 E2D351F0424 for ; Mon, 8 Oct 2012 12:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=1.215, 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 nMvxxYgdX2lV for ; Mon, 8 Oct 2012 12:07:30 -0700 (PDT) Received: from mail198.messagelabs.com (mail198.messagelabs.com [216.82.254.163]) by ietfa.amsl.com (Postfix) with SMTP id AA7A71F040A for ; Mon, 8 Oct 2012 12:07:30 -0700 (PDT) X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-2.tower-198.messagelabs.com!1349723246!2896195!1 X-Originating-IP: [129.179.1.27] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20675 invoked from network); 8 Oct 2012 19:07:29 -0000 Received: from ip27.net129179-1.block1.us.syntegra.com (HELO us-smtp01.smtp.elster.com) (129.179.1.27) by server-2.tower-198.messagelabs.com with SMTP; 8 Oct 2012 19:07:29 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: roll@ietf.org Message-ID: Date: Mon, 8 Oct 2012 15:07:34 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.2FP3|July 10, 2011) at 10/08/2012 02:59:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Gerald Paprocki is out of the office (returning 10/15/2012) 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, 08 Oct 2012 19:07:32 -0000 I am out of the office until 10/15/2012. I am out of the office and will be returning Monday 15th. If assistance is required during my absence please contact one of my primes below. - IP AxisLink Secure Tunnel server - Inyong Park @ 919-250-5698 - EA_MS Interfaces - Bill Phillips @ 919-212-4888 - EA Inspector - Ying Xu @ 919-250-5446 Note: This is an automated response to your message "Roll Digest, Vol 57, Issue 6" sent on 10/8/2012 3:00:11 PM. This is the only notification you will receive while this person is away. From dat@exegin.com Tue Oct 9 11:50: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 90E921F0C3E for ; Tue, 9 Oct 2012 11:50:53 -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 6BydLOnRYOa0 for ; Tue, 9 Oct 2012 11:50:52 -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 2F59F1F0C55 for ; Tue, 9 Oct 2012 11:50:49 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so5578180pad.31 for ; Tue, 09 Oct 2012 11:50:45 -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:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=eVKg4Nxk3UJsDo3ihwhjz7a1LDUjf6swG4Cpa7E6E5w=; b=RoQ/ImJr0QWxj+3p8dynjPKpyTt6l4Xx5Dv4i8zWP+rc64Ohl8e45+skLjdy2OgRBG KcA30U88HJV7sJC/uC0rVymwLDB01s7UegCxPk8Z0RL5ByGSeDNOWRte/MQkxX4l66QN 4C/xMVhulQJgBX7cmIbyLSmjJlFt87ci4OQuAJKnMcwt3iQoAc1HeTTudYXSV1YuD5Bd IpcRzxhR8QlB2A85jvxcPcaOxpARZflynyuiML2/WItHTnB5zPa/tSOBWnZPcnvnJ8zf TB3DRZucAFf3RqxflpFme+G6XjOngjthA8DJQqs1iUByeMvRgjvWIBH2hUFI3TPRLG4t qJJw== Received: by 10.68.231.67 with SMTP id te3mr66731073pbc.134.1349808645223; Tue, 09 Oct 2012 11:50:45 -0700 (PDT) Received: from [192.168.10.104] (S01060014d146ff29.vf.shawcable.net. [70.68.63.160]) by mx.google.com with ESMTPS id bj7sm12959175pab.24.2012.10.09.11.50.43 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 11:50:44 -0700 (PDT) Message-ID: <50747202.8020702@exegin.com> Date: Tue, 09 Oct 2012 11:50:42 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "roll@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnRoh18skT+W+iQor8AFXTiLkAPIHqel7RQIiZARAR1cvx7+jOY/JuBYKB3AfdgqONPUwQu Subject: [Roll] Clarification on SenderRank in RPL HbH option 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: Tue, 09 Oct 2012 18:50:53 -0000 While writing ZigBee-IP test procedures for RPL and discussing with other ZigBee-IP members, it appears there may be an error in RFC 6550. RFC 6550 says: SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network. Firstly, it seems wrong that the source of a datagram would set its SenderRank to zero. If this packet were moving up the DAG the first forwarder would set the Rank-Error bit to 1, because the SenderRank field in the HbH option would be lower than its own rank. Similarly, if the datagram were mistakenly moving down the DAG, where the source's real rank was higher than the forwarder's rank a potential routing loop could be missed. Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank is a 16bit field. Wouldn't doing this allow for potential routing loops to be missed? Could someone (preferably one of the RPL authors) please clarify. - Dario From pthubert@cisco.com Wed Oct 10 02:43: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 B611E21F84B5 for ; Wed, 10 Oct 2012 02:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGW-PJGQiFio for ; Wed, 10 Oct 2012 02:43:34 -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 BF48121F84AE for ; Wed, 10 Oct 2012 02:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=396692; q=dns/txt; s=iport; t=1349862212; x=1351071812; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tJtQ1zo1J6JFAewnBCKC6GUelpmtCBuR3V8f6QhaIRU=; b=ko2cu8WxYrRDJXo6kiey5ZhvvwmisnQjhxo42yoGDwd/1UlAmxV3ZdlQ G2k1j8VmfAm1Uk6/tbPOjv+CxTqSWzAUkGLd6SIQTkaENfxmgSSUpJQ7C YYVu2FSmBzRj5o30EQpapm/ubYSfupzdvI2Xq6BxPl7KqGIbankv/0ok0 8=; X-Files: image003.png, image004.png, image005.png, image006.png, image007.png, image008.png, image009.png, image010.png, image011.png, image012.png, image013.png, image014.emz, image015.png, image016.png, image017.png, image018.png, image019.png, image020.png, image021.png, image042.png, image043.emz, image044.png, image045.png, image046.png, image047.png, image048.png, image049.png, image050.png, image051.emz, image052.png, image053.emz, image054.png, image055.emz, image056.png, image057.emz, image058.png, image059.emz, image060.png, image061.emz, image062.png, image063.emz, image064.emz, image065.png, image066.emz, image067.png, image068.png, image069.png, image070.png, image071.png, image072.png : 5185, 21096, 352, 7144, 23628, 3141, 11768, 8313, 31104, 3597, 6258, 1857, 499, 2983, 9901, 1699, 3707, 3739, 12962, 511, 1785, 359, 837, 2681, 1418, 4284, 1421, 4408, 2897, 896, 2871, 862, 2894, 909, 2879, 897, 2852, 863, 2850, 842, 2873, 1745, 306, 2875, 903, 7538, 8965, 2758, 3998, 2631 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFZCdVCtJXG//2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208,217,50,150?png'208,217,50,150,150?emz'208,217,50,150,150,50"; a="130111979" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 10 Oct 2012 09:43:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9A9hVvU009658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Oct 2012 09:43:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 04:43:31 -0500 From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "mcr@obiwan.sandelman.ca" Thread-Topic: ROLL WG Agenda IETF85 Thread-Index: AQHNo6Yk+PRcaDPFO0aZZPusKmgXtJeyTciQ Date: Wed, 10 Oct 2012 09:43:30 +0000 Deferred-Delivery: Wed, 10 Oct 2012 09:42:00 +0000 Message-ID: References: <03B78081B371D44390ED6E7BADBB4A7721F9CB03@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721F9CB03@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--40.910500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_E045AECD98228444A58C61C200AE1BD8221C21C0xmbrcdx01ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Oct 2012 08:18:26 -0700 Cc: roll WG Subject: Re: [Roll] ROLL WG Agenda IETF85 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, 10 Oct 2012 09:43:35 -0000 --_002_E045AECD98228444A58C61C200AE1BD8221C21C0xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, I introduced the concept of ARCs to the routing area WG (see attached). I think it would be a good idea to present to the group how ARCs can be use= d to implement a generalized sibling in RPL.=20 I'd probably need 15 minutes at least since the concept will be new to many= ... What do you think? Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur (jvasseur) Sent: samedi 6 octobre 2012 11:37 To: roll WG Subject: [Roll] ROLL WG Agenda IETF85 Dear all, The ROLL WG will meet in Atlanta. Please let us not later than Oct 17 if yo= u would like to request a "presentation" slot ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_002_E045AECD98228444A58C61C200AE1BD8221C21C0xmbrcdx01ciscoc_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 10 Oct 2012 09:43:10 GMT"; modification-date="Wed, 10 Oct 2012 09:43:10 GMT" From: "Pascal Thubert (pthubert)" To: "rtgwg@ietf.org" Subject: resending: draft-thubert-rtgwg-arc Thread-Topic: resending: draft-thubert-rtgwg-arc Thread-Index: Ac2gvGIxkN5HezkASauyNAzKtn4SKg== Date: Tue, 2 Oct 2012 16:38:45 +0000 Deferred-Delivery: Tue, 2 Oct 2012 16:39:00 +0000 Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_053_6774667080697367696578677167697876667775686673747865687_"; type="multipart/alternative" MIME-Version: 1.0 --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: multipart/alternative; boundary="_000_6774667080697367696578677167697876667775686673747865687_" --_000_6774667080697367696578677167697876667775686673747865687_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkRlYXIgUm91dGluZyBhcmVhOw0KDQoNCg0KSSB0cmllZCB0byBwb3N0IHRoaXMgYnV0IGFw cGFyZW50bHkgdGhlIG1lc3NhZ2Ugd2FzIHRvbyBiaWcgZHVlIHRvIGluY2x1ZGVkIHBpY3R1cmVz LiBSZXRyeWluZw0KDQoNCg0KQWJvdXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC10aHVi ZXJ0LXJ0Z3dnLWFyYy0wMC50eHQNCg0KDQoNClRoZSBBUkMgdGVjaG5vbG9neSBkZXJpdmVzIGZy b20gc29tZSBpbnRlcm5hbCByZXNlYXJjaCBhdCBjaXNjbywgYW5kIGZvbGxvd2luZyB0aGF0IGxp bmUgb2YgdGhvdWdodCwgd2UgZm91bmQgYSBudW1iZXIgb2YgaW50ZXJlc3RpbmcgcHJvcGVydGll cyB0aGF0IHdlIHdhbnQgdG8gc2hhcmUgd2l0aCB5b3UuDQoNCg0KDQpTb21lIG9mIHlvdSBhbHJl YWR5IGtub3cgYWJvdXQgQVJDcy4gVGhpcyBpcyBub3QgeWV0IGFub3RoZXIgRlJSIHNvbHV0aW9u LCBidXQgcmF0aGVyIGFub3RoZXIgd2F5IG9mIGxvb2tpbmcgYXQgYSByb3V0aW5nIHRvcG9sb2d5 IGFuZCBmb3J3YXJkaW5nLiBJbnN0ZWFkIG9mIGZvbGxvd2luZyB0aGUgYXJyb3dzIGFsb25nIGEg cGF0aCwgYSBwYWNrZXQgd2lsbCBjYXNjYWRlIGZyb20gYXJjIHRvIGFyYywgZWFjaCBhcmMgcHJv dmlkaW5nIGF0IGxlYXN0IDIgZWRnZXMgdGhhdCB0aGUgcGFja2V0IGNhbiB1c2UgdG8gcHJvZ3Jl c3MuIENlcnRhaW5seSwgQVJDcyBjYW4gYmUgdXNlZCBmb3IgZmFzdCByZXJvdXRlLCBidXQgdGhl cmUgYXJlIHRvbnMgb2Ygb3RoZXIgYXBwbGljYXRpb25zLiBUaGlzIHBhcnRpY3VsYXIgZHJhZnQg bWFpbmx5IHByZXNlbnRzIHRoZSBjb25jZXB0cywgYW5kIHdpbGwgZGVmcmVyIHRvIG1vcmUgZHJh ZnRzIHRvIHNwZWNpZnkgYWN0dWFsIHNvbHV0aW9ucyBmb3IgdGhlIHNwZWNpZmljIHByb2JsZW1z IHRoYXQgd2Ugd2FudCB0byBhZGRyZXNzIHdpdGggQVJDcy4NCg0KDQoNClJPT1RBQldlIGhhdmUg YmVndW4gcmVjZW50bHkgdG8gb3BlbiB0aGUgdGVjaG5vbG9neSBmb3IgcGFydGljdWxhciBhcHBs aWNhdGlvbnMsIGluIHBhcnRpY3VsYXIgYXQgSVNBMTAwIGFuZCBJRUMgU0M2NUMgaW4gdGhlIGNv bnRleHQgb2YgaW5kdXN0cmlhbCB3aXJlbGVzcyBuZXR3b3JraW5nLiBUaG9zZSBuZXR3b3JrcyBy ZXF1aXJlIG11bHRpcGxlIGZvcndhcmRpbmcgc29sdXRpb25zIGZvciBlYWNoIG5vZGUgYW5kIGEg cGFja2V0IG1heSBoaXQgbXVsdGlwbGUgdHJhbnNpZW50IGZhaWx1cmVzIGFsb25nIGl0cyB3YXkg b3ZlciBhIG11bHRpaG9wIHdpcmVsZXNzIG1lc2guICBJbmR1c3RyaWFsIFdTTiBpcyB0aHVzIGEg cHJhY3RpY2FsIHVzZSBjYXNlIGZvciB3aGljaCBzaW1wbGUgREFHUyBjYW5ub3QgYXBwbHkgYW5k IHdoZXJlIGV2ZW4gdGhlIE1SVCBhcHByb2FjaCBpcyBub3Qgc3VmZmljaWVudC4NCg0KDQoNCkFz IHlvdSBnbyB0aHJvdWdoIHRoZSBkcmFmdCwgeW91J2xsIGZpbmQgdGhhdCBhbiBBUkMgdG9wb2xv Z3kgaXMgbWFkZSBvZiBtdWx0aXBsZSBBUkNzIGFuZCB0aGF0IGVhY2ggQVJDIGFsbG93cyBhdCBs ZWFzdCBvbmUgYnJlYWthZ2Ugd2l0aCB0aGUgRlJSIGxvdyBwYWNrZXQgbG9zcy4gWW914oCZbGwg ZmluZCB0aGF0IGFuIEFSQyB0b3BvbG9neSBjYW4gYmUgbWFkZSB0byBmb2xsb3cgdGhlIFNQRiBw YXRoIGluIG5vcm1hbCBvcGVyYXRpb24gYW5kIHlldCBwcm92aWRlIGFuIGFsdGVybmF0ZSBmb3Ig YWxsIG5vZGVzIGluIGEgYmljb25uZWN0ZWQgZ3JhcGguIFlvdeKAmWxsIGZpbmQgdGhhdCBtb25v Y29ubmVjdGVkIHpvbmVzIGFyZSBlYXNpbHkgaXNvbGF0ZWQgYW5kIHRoYXQgdGhlIHByb3Bvc2Vk IGNvbXB1dGF0aW9uIGNhbiByZWN1cnNlIHRoZXJlIHRvIG9idGFpbiBhIG1heGltYWwgcmVkdW5k YW5jeS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQW4gQVJDIHRv cG9sb2d5IGNhbiBiZSBleHBsb2l0ZWQgaW4gY2xhc3NpY2FsIHJvdXRpbmcgb3IgaW4gTVBMUy4g VGhlIHJlY292ZXJ5IGNhbiBiZSBkYXRhIHBsYW5lIG9yIGNvbnRyb2wgcGxhbmUgd2hpY2ggcHJv dmlkZXMgYWRkaXRpb25hbCBjYXBhYmlsaXRpZXMuIEJlY2F1c2UgQVJDcyBhcmUgKGF0IGxlYXN0 KSBkdWFsIGVuZGVkLCBhbiBBUkMgdG9wb2xvZ3kgYWxzbyBlbmFibGVzIGxvYWQgYmFsYW5jaW5n IGFuZCBhIHJlY3Vyc2l2ZSBvdmVyZmxvdyBtYW5hZ2VtZW50IHRvIHRha2UgdGhlIHRyYWZmaWMg YXdheSBmcm9tIHRoZSBwYWluIHBvaW50cy4gVGhlcmUncyBwcm9iYWJseSBhIGxvdCBtb3JlLCBi dXQgd2UnbGwgaGF2ZSB0byBkaXNjb3ZlciB0aGF0IHRvZ2V0aGVyLg0KDQoNCg0KQWJvdXQgSVBS OiBTdGV3YXJ0IHJlY29tbWVuZGVkIHRoYXQgSSB0YWxrIHRvIEFsaWEgKGFuZCBlZmZlY3RpdmVs eSBKb2VsKSBpbiBUYWlwZWkgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIElQUiBjaXNjbyBoYXMgb24g QVJDIGlzIG5vdCBvbiB0aGUgd2F5IG9mIE1SVCwgYW5kIHdlIGNvbmNsdWRlZCB0aGF0IHRoZXNl IHdlcmUgZWZmZWN0aXZlbHkgMiBkaWZmZXJlbnQgdGVjaG5vbG9naWVzLiBTbyBjaXNjbyBkaWQg bm90IGNsYWltIElQUiByZWdhcmRpbmcgTVJUIGJ1dCB3ZSBjZXJ0YWlubHkgaGF2ZSBJUFIgb24g QVJDcy4gV2UnbGwgcG9zdCBBU0FQIG9uIHRoYXQuDQoNCg0KDQpQbGVhc2UgbGV0IHVzIGtub3cg aWYgdGhpcyBhcHByb2FjaCB0cmlnZ2VycyBpbnRlcmVzdC4gV2Ugd2lzaCB0byBkaXNjdXNzIEFS Q3MgZHVyaW5nIHRoZSBSVEdXRyBtZWV0aW5nIGluIEF0bGFudGEgYW5kIHdpbGwgYmUgYXNraW5n IGZvciBhIHNsb3QgZnJvbSB0aGUgY2hhaXJzLg0KDQoNCg0KQ2hlZXJzLA0KDQoNCg0KUGFzY2Fs DQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1 Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ108bWFpbHRvOlttYWls dG86aWRzdWJtaXNzaW9uQGlldGYub3JnXT4NClNlbnQ6IG1hcmRpIDIgb2N0b2JyZSAyMDEyIDA5 OjU5DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU3ViamVjdDogQ29uZmlybWF0aW9u IGZvciBBdXRvLVBvc3Qgb2YgSS1EIGRyYWZ0LXRodWJlcnQtcnRnd2ctYXJjDQoNCg0KDQoNCg0K SGksDQoNCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBkcmFmdCBzdWJtaXNzaW9uIHNlcnZpY2Ug aGFzIHJlY2VpdmVkIHlvdXIgZHJhZnQgZHJhZnQtdGh1YmVydC1ydGd3Zy1hcmMtMDAsIGFuZCBy ZXF1aXJlcyBhIGNvbmZpcm1hdGlvbiBzdGVwIGluIG9yZGVyIHRvIGJlIGFibGUgdG8gY29tcGxl dGUgdGhlIHBvc3Rpbmcgb2YgdGhlIGRyYWZ0Lg0KDQoNCg0KUGxlYXNlIGZvbGxvdyB0aGlzIGxp bmsgdG8gdGhlIHBhZ2Ugd2hlcmUgeW91IGNhbiBjb25maXJtIHRoZSBwb3N0aW5nOg0KDQpDb25m aXJtYXRpb24gVVJMOiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0L3N0YXR1cy80 NDgyMS9jb25maXJtLzJmMmE2YjBjOTg0MTUwZTZhNTNhMGM3MzRmNWFiMDQxMWM2OGMyODgvDQoN Cg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQoNCg0KICAgICAgICAgICAgICAgIFRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCiAgICAgICAgICAgICAgICB0aHJvdWdoIHRoZSBkcmFmdCBzdWJtaXNzaW9u IHNlcnZpY2UNCg0KDQoNCg0KDQo= --_000_6774667080697367696578677167697876667775686673747865687_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDU1IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRlYXIg Um91dGluZyBhcmVhOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkkgdHJpZWQgdG8gcG9zdCB0aGlzIGJ1dCBhcHBhcmVudGx5 IHRoZSBtZXNzYWdlIHdhcyB0b28gYmlnIGR1ZSB0byBpbmNsdWRlZCBwaWN0dXJlcy4gUmV0cnlp bmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5BYm91dCA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRo dWJlcnQtcnRnd2ctYXJjLTAwLnR4dCI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRo dWJlcnQtcnRnd2ctYXJjLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGhlIEFSQyB0ZWNobm9sb2d5IGRlcml2ZXMgZnJvbSBzb21lIGludGVybmFsIHJlc2VhcmNoIGF0 IGNpc2NvLCBhbmQgZm9sbG93aW5nIHRoYXQgbGluZSBvZiB0aG91Z2h0LCB3ZSBmb3VuZCBhIG51 bWJlciBvZiBpbnRlcmVzdGluZyBwcm9wZXJ0aWVzIHRoYXQgd2Ugd2FudCB0byBzaGFyZSB3aXRo IHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U29tZSBvZiB5b3UgYWxyZWFkeSBr bm93IGFib3V0IEFSQ3MuIFRoaXMgaXMgbm90IHlldCBhbm90aGVyIEZSUiBzb2x1dGlvbiwgYnV0 IHJhdGhlciBhbm90aGVyIHdheSBvZiBsb29raW5nIGF0IGEgcm91dGluZyB0b3BvbG9neSBhbmQg Zm9yd2FyZGluZy4gSW5zdGVhZCBvZiBmb2xsb3dpbmcgdGhlIGFycm93cyBhbG9uZyBhIHBhdGgs IGEgcGFja2V0IHdpbGwgY2FzY2FkZSBmcm9tIGFyYyB0byBhcmMsIGVhY2gNCiBhcmMgcHJvdmlk aW5nIGF0IGxlYXN0IDIgZWRnZXMgdGhhdCB0aGUgcGFja2V0IGNhbiB1c2UgdG8gcHJvZ3Jlc3Mu IENlcnRhaW5seSwgQVJDcyBjYW4gYmUgdXNlZCBmb3IgZmFzdCByZXJvdXRlLCBidXQgdGhlcmUg YXJlIHRvbnMgb2Ygb3RoZXIgYXBwbGljYXRpb25zLiBUaGlzIHBhcnRpY3VsYXIgZHJhZnQgbWFp bmx5IHByZXNlbnRzIHRoZSBjb25jZXB0cywgYW5kIHdpbGwgZGVmcmVyIHRvIG1vcmUgZHJhZnRz IHRvIHNwZWNpZnkgYWN0dWFsDQogc29sdXRpb25zIGZvciB0aGUgc3BlY2lmaWMgcHJvYmxlbXMg dGhhdCB3ZSB3YW50IHRvIGFkZHJlc3Mgd2l0aCBBUkNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGV0eXBlIGlkPSJfeDAwMDBfdDc1IiBj b29yZHNpemU9IjIxNjAwLDIxNjAwIiBvOnNwdD0iNzUiIG86cHJlZmVycmVsYXRpdmU9InQiIHBh dGg9Im1ANEA1bEA0QDExQDlAMTFAOUA1eGUiIGZpbGxlZD0iZiIgc3Ryb2tlZD0iZiI+DQo8djpz dHJva2Ugam9pbnN0eWxlPSJtaXRlciIgLz4NCjx2OmZvcm11bGFzPg0KPHY6ZiBlcW49ImlmIGxp bmVEcmF3biBwaXhlbExpbmVXaWR0aCAwIiAvPg0KPHY6ZiBlcW49InN1bSBAMCAxIDAiIC8+DQo8 djpmIGVxbj0ic3VtIDAgMCBAMSIgLz4NCjx2OmYgZXFuPSJwcm9kIEAyIDEgMiIgLz4NCjx2OmYg ZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsV2lkdGgiIC8+DQo8djpmIGVxbj0icHJvZCBAMyAyMTYw MCBwaXhlbEhlaWdodCIgLz4NCjx2OmYgZXFuPSJzdW0gQDAgMCAxIiAvPg0KPHY6ZiBlcW49InBy b2QgQDYgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIgLz4NCjx2 OmYgZXFuPSJzdW0gQDggMjE2MDAgMCIgLz4NCjx2OmYgZXFuPSJwcm9kIEA3IDIxNjAwIHBpeGVs SGVpZ2h0IiAvPg0KPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIgLz4NCjwvdjpmb3JtdWxhcz4N Cjx2OnBhdGggbzpleHRydXNpb25vaz0iZiIgZ3JhZGllbnRzaGFwZW9rPSJ0IiBvOmNvbm5lY3R0 eXBlPSJyZWN0IiAvPg0KPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89InQiIC8+DQo8 L3Y6c2hhcGV0eXBlPjx2OnNoYXBlIGlkPSJBcmNfeDAwMjBfMiIgbzpzcGlkPSJfeDAwMDBfczEw NTQiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxl ZnQ6NjcuMnB0O21hcmdpbi10b3A6MjIyLjU1cHQ7d2lkdGg6MzUxLjc1cHQ7aGVpZ2h0OjM0MC4x cHQ7ei1pbmRleDoyNTE2NTkyNjQ7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLWRpc3RhbmNl LWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0 OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDph YnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlv bi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6dGV4dCc+ DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwMDMucG5nQDAxQ0RBMENELjI3MkFGOTQwIiBv OnRpdGxlPSIiIGNyb3B0b3A9Ii0zMTkyOGYiIGNyb3Bib3R0b209Ii05MzAzOWYiIC8+DQo8bzps b2NrIHY6ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0iZiIgLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0t LT48IVtpZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3NpdGlvbjph YnNvbHV0ZTt6LWluZGV4OjI1MTY1OTI2NDttYXJnaW4tbGVmdDo5MHB4O21hcmdpbi10b3A6Mjk3 cHg7d2lkdGg6NDY5cHg7aGVpZ2h0OjQ1M3B4Ij48aW1nIHdpZHRoPSI0NjkiIGhlaWdodD0iNDUz IiBzcmM9ImNpZDppbWFnZTAwNC5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJBcmNf eDAwMjBfMiI+PC9zcGFuPjwhW2VuZGlmXT48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9 IkNvbm5lY3RldXJfeDAwMjBfZHJvaXRfeDAwMjBfNCIgbzpzcGlkPSJfeDAwMDBfczEwNTMiIHR5 cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6M3B0 O21hcmdpbi10b3A6MzkwLjNwdDt3aWR0aDo2MjQuNzVwdDtoZWlnaHQ6NnB0O3otaW5kZXg6MjUx NjYwMjg4O3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDttc28t d3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdyYXAt ZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250YWw6YWJzb2x1dGU7bXNvLXBv c2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVydGljYWw6YWJz b2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOnRleHQnPg0KPHY6aW1hZ2VkYXRh IHNyYz0iY2lkOmltYWdlMDA1LnBuZ0AwMUNEQTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0iIiAvPg0K PG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89ImYiIC8+DQo8L3Y6c2hhcGU+PCFbZW5k aWZdLS0+PCFbaWYgIXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRp b246YWJzb2x1dGU7ei1pbmRleDoyNTE2NjAyODg7bWFyZ2luLWxlZnQ6NHB4O21hcmdpbi10b3A6 NTIwcHg7d2lkdGg6ODMzcHg7aGVpZ2h0OjhweCI+PGltZyB3aWR0aD0iODMzIiBoZWlnaHQ9Ijgi IHNyYz0iY2lkOmltYWdlMDA1LnBuZ0AwMUNEQTBDRC4yNzJBRjk0MCIgdjpzaGFwZXM9IkNvbm5l Y3RldXJfeDAwMjBfZHJvaXRfeDAwMjBfNCI+PC9zcGFuPjwhW2VuZGlmXT48IS0tW2lmIGd0ZSB2 bWwgMV0+PHY6c2hhcGUgaWQ9IkFyY194MDAyMF82IiBvOnNwaWQ9Il94MDAwMF9zMTA1MiIgdHlw ZT0iI194MDAwMF90NzUiIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDoxNzcu MDVwdDttYXJnaW4tdG9wOjEzOC41NXB0O3dpZHRoOjM0My41cHQ7aGVpZ2h0OjM0MC4xcHQ7ei1p bmRleDoyNTE2NjEzMTI7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6 OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjlwdDtt c28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDphYnNvbHV0 ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0 aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6dGV4dCc+DQo8djpp bWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwMDYucG5nQDAxQ0RBMENELjI3MkFGOTQwIiBvOnRpdGxl PSIiIGNyb3B0b3A9Ii0xODY4OWYiIGNyb3Bib3R0b209Ii0yODc3M2YiIC8+DQo8bzpsb2NrIHY6 ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0iZiIgLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtp ZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3NpdGlvbjphYnNvbHV0 ZTt6LWluZGV4OjI1MTY2MTMxMjttYXJnaW4tbGVmdDoyMzZweDttYXJnaW4tdG9wOjE4NXB4O3dp ZHRoOjQ1OHB4O2hlaWdodDo0NTNweCI+PGltZyB3aWR0aD0iNDU4IiBoZWlnaHQ9IjQ1MyIgc3Jj PSJjaWQ6aW1hZ2UwMDcucG5nQDAxQ0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0iQXJjX3gwMDIw XzYiPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBlIGlkPSJBcmNf eDAwMjBfNyIgbzpzcGlkPSJfeDAwMDBfczEwNTEiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0n cG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6MTM5LjI1cHQ7bWFyZ2luLXRvcDozMDYuNXB0 O3dpZHRoOjE4NnB0O2hlaWdodDoxNzMuMDVwdDt6LWluZGV4OjI1MTY2MjMzNjt2aXNpYmlsaXR5 OnZpc2libGU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtdG9w OjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6OXB0O21zby13cmFwLWRpc3RhbmNlLWJvdHRvbTow O21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmFic29sdXRlO21zby1wb3NpdGlvbi1ob3Jpem9udGFs LXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1wb3NpdGlv bi12ZXJ0aWNhbC1yZWxhdGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0YSBzcmM9ImNpZDppbWFnZTAw OC5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIG86dGl0bGU9IiIgY3JvcGJvdHRvbT0iLTU5NDM0ZiIg Lz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJmIiAvPg0KPC92OnNoYXBlPjwh W2VuZGlmXS0tPjwhW2lmICF2bWxdPjxzcGFuIHN0eWxlPSJtc28taWdub3JlOnZnbGF5b3V0O3Bv c2l0aW9uOmFic29sdXRlO3otaW5kZXg6MjUxNjYyMzM2O21hcmdpbi1sZWZ0OjE4NnB4O21hcmdp bi10b3A6NDA5cHg7d2lkdGg6MjQ4cHg7aGVpZ2h0OjIzMXB4Ij48aW1nIHdpZHRoPSIyNDgiIGhl aWdodD0iMjMxIiBzcmM9ImNpZDppbWFnZTAwOS5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hh cGVzPSJBcmNfeDAwMjBfNyI+PC9zcGFuPjwhW2VuZGlmXT48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6 c2hhcGUgaWQ9IkFyY194MDAyMF84IiBvOnNwaWQ9Il94MDAwMF9zMTA1MCIgdHlwZT0iI194MDAw MF90NzUiIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDozMC4xcHQ7bWFyZ2lu LXRvcDo5LjU1cHQ7d2lkdGg6NDc0cHQ7aGVpZ2h0OjQ2Ni4xcHQ7ei1pbmRleDoyNTE2NjMzNjA7 dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRp c3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5j ZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24t aG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTtt c28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJj aWQ6aW1hZ2UwMTAucG5nQDAxQ0RBMENELjI3MkFGOTQwIiBvOnRpdGxlPSIiIGNyb3B0b3A9Ii00 NzM5MmYiIGNyb3Bib3R0b209Ii01NTM3MWYiIC8+DQo8bzpsb2NrIHY6ZXh0PSJlZGl0IiBhc3Bl Y3RyYXRpbz0iZiIgLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48c3BhbiBz dHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3NpdGlvbjphYnNvbHV0ZTt6LWluZGV4OjI1MTY2 MzM2MDttYXJnaW4tbGVmdDo0MHB4O21hcmdpbi10b3A6MTNweDt3aWR0aDo2MzJweDtoZWlnaHQ6 NjIxcHgiPjxpbWcgd2lkdGg9IjYzMiIgaGVpZ2h0PSI2MjEiIHNyYz0iY2lkOmltYWdlMDExLnBu Z0AwMUNEQTBDRC4yNzJBRjk0MCIgdjpzaGFwZXM9IkFyY194MDAyMF84Ij48L3NwYW4+PCFbZW5k aWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iQXJjX3gwMDIwXzkiIG86c3BpZD0i X3gwMDAwX3MxMDQ5IiB0eXBlPSIjX3gwMDAwX3Q3NSIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRl O21hcmdpbi1sZWZ0OjMwMC4zNXB0O21hcmdpbi10b3A6MjMzLjE1cHQ7d2lkdGg6MTQ4LjVwdDto ZWlnaHQ6MTQ1LjVwdDt6LWluZGV4OjI1MTY2NDM4NDt2aXNpYmlsaXR5OnZpc2libGU7bXNvLXdy YXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlz dGFuY2UtcmlnaHQ6OXB0O21zby13cmFwLWRpc3RhbmNlLWJvdHRvbTowO21zby1wb3NpdGlvbi1o b3Jpem9udGFsOmFic29sdXRlO21zby1wb3NpdGlvbi1ob3Jpem9udGFsLXJlbGF0aXZlOnRleHQ7 bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1wb3NpdGlvbi12ZXJ0aWNhbC1yZWxh dGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0YSBzcmM9ImNpZDppbWFnZTAxMi5wbmdAMDFDREEwQ0Qu MjcyQUY5NDAiIG86dGl0bGU9IiIgY3JvcGJvdHRvbT0iLTM5MzlmIiAvPg0KPG86bG9jayB2OmV4 dD0iZWRpdCIgYXNwZWN0cmF0aW89ImYiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYg IXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7 ei1pbmRleDoyNTE2NjQzODQ7bWFyZ2luLWxlZnQ6NDAwcHg7bWFyZ2luLXRvcDozMTFweDt3aWR0 aDoxOThweDtoZWlnaHQ6MTk0cHgiPjxpbWcgd2lkdGg9IjE5OCIgaGVpZ2h0PSIxOTQiIHNyYz0i Y2lkOmltYWdlMDEzLnBuZ0AwMUNEQTBDRC4yNzJBRjk0MCIgdjpzaGFwZXM9IkFyY194MDAyMF85 Ij48L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iX3gwMDAw X3MxMDQ4IiB0eXBlPSIjX3gwMDAwX3Q3NSIgYWx0PSJST09UIiBzdHlsZT0ncG9zaXRpb246YWJz b2x1dGU7bWFyZ2luLWxlZnQ6NTQ5cHQ7bWFyZ2luLXRvcDozNjMuNDVwdDt3aWR0aDo1Ni4xNXB0 O2hlaWdodDoyOS4xNXB0O3otaW5kZXg6MjUxNjY1NDA4O3Zpc2liaWxpdHk6dmlzaWJsZTttc28t d3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1k aXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9u LWhvcml6b250YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4 dDttc28tcG9zaXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJl bGF0aXZlOnRleHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDE0LmVtekAwMUNEQTBD RC4yNzJBRjk0MCIgbzp0aXRsZT0iIiAvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2 bWxdPjxzcGFuIHN0eWxlPSJtc28taWdub3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFic29sdXRlO3ot aW5kZXg6MjUxNjY1NDA4O21hcmdpbi1sZWZ0OjczMnB4O21hcmdpbi10b3A6NDg1cHg7d2lkdGg6 NzVweDtoZWlnaHQ6MzlweCI+PGltZyB3aWR0aD0iNzUiIGhlaWdodD0iMzkiIHNyYz0iY2lkOmlt YWdlMDE1LnBuZ0AwMUNEQTBDRC4yNzJBRjk0MCIgYWx0PSJST09UIiB2OnNoYXBlcz0iX3gwMDAw X3MxMDQ4Ij48L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0i QXJjX3gwMDIwXzExIiBvOnNwaWQ9Il94MDAwMF9zMTA0NyIgdHlwZT0iI194MDAwMF90NzUiIHN0 eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDozNy41NXB0O21hcmdpbi10b3A6MTgx LjNwdDt3aWR0aDoxODkuM3B0O2hlaWdodDoxNjcuMzVwdDt6LWluZGV4OjI1MTY2NjQzMjt2aXNp YmlsaXR5OnZpc2libGU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNvLXdyYXAtZGlzdGFu Y2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6OXB0O21zby13cmFwLWRpc3RhbmNlLWJv dHRvbTowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmFic29sdXRlO21zby1wb3NpdGlvbi1ob3Jp em9udGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1w b3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0YSBzcmM9ImNpZDpp bWFnZTAxNi5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIG86dGl0bGU9IiIgY3JvcGJvdHRvbT0iLTM4 MTc1ZiIgY3JvcGxlZnQ9Ii03NzQ4ZiIgY3JvcHJpZ2h0PSItODIwMGYiIC8+DQo8bzpsb2NrIHY6 ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0iZiIgLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtp ZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3NpdGlvbjphYnNvbHV0 ZTt6LWluZGV4OjI1MTY2NjQzMjttYXJnaW4tbGVmdDo1MHB4O21hcmdpbi10b3A6MjQycHg7d2lk dGg6MjUycHg7aGVpZ2h0OjIyM3B4Ij48aW1nIHdpZHRoPSIyNTIiIGhlaWdodD0iMjIzIiBzcmM9 ImNpZDppbWFnZTAxNy5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJBcmNfeDAwMjBf MTEiPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBlIGlkPSJBcmNf eDAwMjBfMTIiIG86c3BpZD0iX3gwMDAwX3MxMDQ2IiB0eXBlPSIjX3gwMDAwX3Q3NSIgc3R5bGU9 J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjE0NS4xNXB0O21hcmdpbi10b3A6MTQ5LjVw dDt3aWR0aDoxMzUuNzVwdDtoZWlnaHQ6MmluO3otaW5kZXg6MjUxNjY3NDU2O3Zpc2liaWxpdHk6 dmlzaWJsZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6 MDttc28td3JhcC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7 bXNvLXBvc2l0aW9uLWhvcml6b250YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwt cmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9u LXZlcnRpY2FsLXJlbGF0aXZlOnRleHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDE4 LnBuZ0AwMUNEQTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0iIiBjcm9wdG9wPSItMTE2MjdmIiBjcm9w Ym90dG9tPSItMTI1Nzg3ZiIgLz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJm IiAvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxzcGFuIHN0eWxlPSJtc28t aWdub3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFic29sdXRlO3otaW5kZXg6MjUxNjY3NDU2O21hcmdp bi1sZWZ0OjE5NHB4O21hcmdpbi10b3A6MTk5cHg7d2lkdGg6MTgxcHg7aGVpZ2h0OjE5MnB4Ij48 aW1nIHdpZHRoPSIxODEiIGhlaWdodD0iMTkyIiBzcmM9ImNpZDppbWFnZTAxOS5wbmdAMDFDREEw Q0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJBcmNfeDAwMjBfMTIiPjwvc3Bhbj48IVtlbmRpZl0+PCEt LVtpZiBndGUgdm1sIDFdPjx2OnNoYXBlIGlkPSJBcmNfeDAwMjBfMTMiIG86c3BpZD0iX3gwMDAw X3MxMDQ1IiB0eXBlPSIjX3gwMDAwX3Q3NSIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdp bi1sZWZ0Oi04Ni4xNXB0O21hcmdpbi10b3A6MTYxLjQ1cHQ7d2lkdGg6MzE1Ljk1cHQ7aGVpZ2h0 OjIzNy43NXB0O3otaW5kZXg6MjUxNjY4NDgwO3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1k aXN0YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5j ZS1yaWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6 b250YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28t cG9zaXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZl OnRleHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDIwLnBuZ0AwMUNEQTBDRC4yNzJB Rjk0MCIgbzp0aXRsZT0iIiBjcm9wbGVmdD0iLTYxOTgwZiIgY3JvcHJpZ2h0PSItODY1MDFmIiAv Pg0KPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89ImYiIC8+DQo8L3Y6c2hhcGU+PCFb ZW5kaWZdLS0+PCFbaWYgIXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9z aXRpb246YWJzb2x1dGU7ei1pbmRleDoyNTE2Njg0ODA7bWFyZ2luLWxlZnQ6LTExNXB4O21hcmdp bi10b3A6MjE1cHg7d2lkdGg6NDIxcHg7aGVpZ2h0OjMxN3B4Ij48aW1nIHdpZHRoPSI0MjEiIGhl aWdodD0iMzE3IiBzcmM9ImNpZDppbWFnZTAyMS5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hh cGVzPSJBcmNfeDAwMjBfMTMiPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2 OnNoYXBlIGlkPSJGb3JtZV94MDAyMF9saWJyZV94MDAyMF8xNyIgbzpzcGlkPSJfeDAwMDBfczEw NDQiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxl ZnQ6MjM3LjY1cHQ7bWFyZ2luLXRvcDoxNjUuOXB0O3dpZHRoOjQxLjI1cHQ7aGVpZ2h0OjM5Ljc1 cHQ7ei1pbmRleDoyNTE2Njk1MDQ7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLWRpc3RhbmNl LWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0 OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDph YnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlv bi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6dGV4dCc+ DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNDIucG5nQDAxQ0RBMENELjI3MkFGOTQwIiBv OnRpdGxlPSIiIC8+DQo8bzpsb2NrIHY6ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0iZiIgLz4NCjwv djpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9yZTp2 Z2xheW91dDtwb3NpdGlvbjphYnNvbHV0ZTt6LWluZGV4OjI1MTY2OTUwNDttYXJnaW4tbGVmdDoz MTdweDttYXJnaW4tdG9wOjIyMXB4O3dpZHRoOjU1cHg7aGVpZ2h0OjUzcHgiPjxpbWcgd2lkdGg9 IjU1IiBoZWlnaHQ9IjUzIiBzcmM9ImNpZDppbWFnZTA0Mi5wbmdAMDFDREEwQ0QuMjcyQUY5NDAi IHY6c2hhcGVzPSJGb3JtZV94MDAyMF9saWJyZV94MDAyMF8xNyI+PC9zcGFuPjwhW2VuZGlmXT48 IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9Il94MDAwMF9zMTA0MyIgdHlwZT0iI194MDAw MF90NzUiIGFsdD0iQSIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjIyOS45 NXB0O21hcmdpbi10b3A6MTQzLjlwdDt3aWR0aDoyNC44NXB0O2hlaWdodDoyOS4xNXB0O3otaW5k ZXg6MjUxNjcwNTI4O3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0Ojlw dDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNv LXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250YWw6YWJzb2x1dGU7 bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVydGlj YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOnRleHQnPg0KPHY6aW1h Z2VkYXRhIHNyYz0iY2lkOmltYWdlMDQzLmVtekAwMUNEQTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0i IiAvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxzcGFuIHN0eWxlPSJtc28t aWdub3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFic29sdXRlO3otaW5kZXg6MjUxNjcwNTI4O21hcmdp bi1sZWZ0OjMwN3B4O21hcmdpbi10b3A6MTkycHg7d2lkdGg6MzNweDtoZWlnaHQ6MzlweCI+PGlt ZyB3aWR0aD0iMzMiIGhlaWdodD0iMzkiIHNyYz0iY2lkOmltYWdlMDQ0LnBuZ0AwMUNEQTBDRC4y NzJBRjk0MCIgYWx0PSJBIiB2OnNoYXBlcz0iX3gwMDAwX3MxMDQzIj48L3NwYW4+PCFbZW5kaWZd PjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iQXJjX3gwMDIwXzE5IiBvOnNwaWQ9Il94 MDAwMF9zMTA0MiIgdHlwZT0iI194MDAwMF90NzUiIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTtt YXJnaW4tbGVmdDoyMDEuNnB0O21hcmdpbi10b3A6MjY2LjZwdDt3aWR0aDo1N3B0O2hlaWdodDo3 My40NXB0O3otaW5kZXg6MjUxNjcxNTUyO3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1kaXN0 YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1y aWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250 YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9z aXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOnRl eHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDQ1LnBuZ0AwMUNEQTBDRC4yNzJBRjk0 MCIgbzp0aXRsZT0iIiBjcm9wdG9wPSItOTUzMmYiIGNyb3Bib3R0b209Ii00MTYyNWYiIGNyb3Bs ZWZ0PSItMjAzMzhmIiAvPg0KPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89ImYiIC8+ DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYgIXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25v cmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7ei1pbmRleDoyNTE2NzE1NTI7bWFyZ2luLWxl ZnQ6MjY5cHg7bWFyZ2luLXRvcDozNTVweDt3aWR0aDo3NnB4O2hlaWdodDo5OHB4Ij48aW1nIHdp ZHRoPSI3NiIgaGVpZ2h0PSI5OCIgc3JjPSJjaWQ6aW1hZ2UwNDYucG5nQDAxQ0RBMENELjI3MkFG OTQwIiB2OnNoYXBlcz0iQXJjX3gwMDIwXzE5Ij48L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3Rl IHZtbCAxXT48djpzaGFwZSBpZD0iQXJjX3gwMDIwXzIzIiBvOnNwaWQ9Il94MDAwMF9zMTA0MSIg dHlwZT0iI194MDAwMF90NzUiIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDoy OTUuN3B0O21hcmdpbi10b3A6MTc2LjNwdDt3aWR0aDo2OS43NXB0O2hlaWdodDo2OC4zcHQ7ei1p bmRleDoyNTE2NzI1NzY7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6 OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjlwdDtt c28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDphYnNvbHV0 ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0 aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6dGV4dCc+DQo8djpp bWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNDcucG5nQDAxQ0RBMENELjI3MkFGOTQwIiBvOnRpdGxl PSIiIGNyb3B0b3A9Ii0yNDI3ZiIgY3JvcGJvdHRvbT0iLTU3MTdmIiAvPg0KPG86bG9jayB2OmV4 dD0iZWRpdCIgYXNwZWN0cmF0aW89ImYiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYg IXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7 ei1pbmRleDoyNTE2NzI1NzY7bWFyZ2luLWxlZnQ6Mzk0cHg7bWFyZ2luLXRvcDoyMzVweDt3aWR0 aDo5M3B4O2hlaWdodDo5MXB4Ij48aW1nIHdpZHRoPSI5MyIgaGVpZ2h0PSI5MSIgc3JjPSJjaWQ6 aW1hZ2UwNDgucG5nQDAxQ0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0iQXJjX3gwMDIwXzIzIj48 L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iQXJjX3gwMDIw XzIyIiBvOnNwaWQ9Il94MDAwMF9zMTA0MCIgdHlwZT0iI194MDAwMF90NzUiIHN0eWxlPSdwb3Np dGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDoxMjQuMjVwdDttYXJnaW4tdG9wOjMwMy41NXB0O3dp ZHRoOjU2LjNwdDtoZWlnaHQ6NjEuNXB0O3otaW5kZXg6MjUxNjczNjAwO3Zpc2liaWxpdHk6dmlz aWJsZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6MDtt c28td3JhcC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNv LXBvc2l0aW9uLWhvcml6b250YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVs YXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZl cnRpY2FsLXJlbGF0aXZlOnRleHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDQ5LnBu Z0AwMUNEQTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0iIiBjcm9wcmlnaHQ9Ii01OGYiIC8+DQo8bzps b2NrIHY6ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0iZiIgLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0t LT48IVtpZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3NpdGlvbjph YnNvbHV0ZTt6LWluZGV4OjI1MTY3MzYwMDttYXJnaW4tbGVmdDoxNjZweDttYXJnaW4tdG9wOjQw NXB4O3dpZHRoOjc1cHg7aGVpZ2h0OjgycHgiPjxpbWcgd2lkdGg9Ijc1IiBoZWlnaHQ9IjgyIiBz cmM9ImNpZDppbWFnZTA1MC5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJBcmNfeDAw MjBfMjIiPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBlIGlkPSJf eDAwMDBfczEwMzkiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7 bWFyZ2luLWxlZnQ6MjM3cHQ7bWFyZ2luLXRvcDoxMDcuMjVwdDt3aWR0aDo2MC4xNXB0O2hlaWdo dDozNy41cHQ7ei1pbmRleDoyNTE2NzQ2MjQ7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLWRp c3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNl LXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpv bnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1w b3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6 dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNTEuZW16QDAxQ0RBMENELjI3MkFG OTQwIiBvOnRpdGxlPSIiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYgIXZtbF0+PHNw YW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7ei1pbmRleDoy NTE2NzQ2MjQ7bWFyZ2luLWxlZnQ6MzE2cHg7bWFyZ2luLXRvcDoxNDNweDt3aWR0aDo4MHB4O2hl aWdodDo1MHB4Ij48aW1nIHdpZHRoPSI4MCIgaGVpZ2h0PSI1MCIgc3JjPSJjaWQ6aW1hZ2UwNTIu cG5nQDAxQ0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0iX3gwMDAwX3MxMDM5Ij48L3NwYW4+PCFb ZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iX3gwMDAwX3MxMDM4IiB0eXBl PSIjX3gwMDAwX3Q3NSIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjIxM3B0 O21hcmdpbi10b3A6MjQ1LjI1cHQ7d2lkdGg6NjAuMTVwdDtoZWlnaHQ6MzcuNXB0O3otaW5kZXg6 MjUxNjc1NjQ4O3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDtt c28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdy YXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250YWw6YWJzb2x1dGU7bXNv LXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVydGljYWw6 YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOnRleHQnPg0KPHY6aW1hZ2Vk YXRhIHNyYz0iY2lkOmltYWdlMDUzLmVtekAwMUNEQTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0iIiAv Pg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxzcGFuIHN0eWxlPSJtc28taWdu b3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFic29sdXRlO3otaW5kZXg6MjUxNjc1NjQ4O21hcmdpbi1s ZWZ0OjI4NHB4O21hcmdpbi10b3A6MzI3cHg7d2lkdGg6ODBweDtoZWlnaHQ6NTBweCI+PGltZyB3 aWR0aD0iODAiIGhlaWdodD0iNTAiIHNyYz0iY2lkOmltYWdlMDU0LnBuZ0AwMUNEQTBDRC4yNzJB Rjk0MCIgdjpzaGFwZXM9Il94MDAwMF9zMTAzOCI+PC9zcGFuPjwhW2VuZGlmXT48IS0tW2lmIGd0 ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9Il94MDAwMF9zMTAzNyIgdHlwZT0iI194MDAwMF90NzUiIHN0 eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDoxMDVwdDttYXJnaW4tdG9wOjE0OS4y NXB0O3dpZHRoOjYwLjE1cHQ7aGVpZ2h0OjM3LjVwdDt6LWluZGV4OjI1MTY3NjY3Mjt2aXNpYmls aXR5OnZpc2libGU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2Ut dG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6OXB0O21zby13cmFwLWRpc3RhbmNlLWJvdHRv bTowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmFic29sdXRlO21zby1wb3NpdGlvbi1ob3Jpem9u dGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1wb3Np dGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0YSBzcmM9ImNpZDppbWFn ZTA1NS5lbXpAMDFDREEwQ0QuMjcyQUY5NDAiIG86dGl0bGU9IiIgLz4NCjwvdjpzaGFwZT48IVtl bmRpZl0tLT48IVtpZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3Np dGlvbjphYnNvbHV0ZTt6LWluZGV4OjI1MTY3NjY3MjttYXJnaW4tbGVmdDoxNDBweDttYXJnaW4t dG9wOjE5OXB4O3dpZHRoOjgwcHg7aGVpZ2h0OjUwcHgiPjxpbWcgd2lkdGg9IjgwIiBoZWlnaHQ9 IjUwIiBzcmM9ImNpZDppbWFnZTA1Ni5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJf eDAwMDBfczEwMzciPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBl IGlkPSJfeDAwMDBfczEwMzYiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0ncG9zaXRpb246YWJz b2x1dGU7bWFyZ2luLWxlZnQ6MjgzLjU1cHQ7bWFyZ2luLXRvcDoxNDMuMjVwdDt3aWR0aDo2MC4x NXB0O2hlaWdodDozNy41cHQ7ei1pbmRleDoyNTE2Nzc2OTY7dmlzaWJpbGl0eTp2aXNpYmxlO21z by13cmFwLWRpc3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFw LWRpc3RhbmNlLXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRp b24taG9yaXpvbnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0 ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwt cmVsYXRpdmU6dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNTcuZW16QDAxQ0RB MENELjI3MkFGOTQwIiBvOnRpdGxlPSIiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYg IXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7 ei1pbmRleDoyNTE2Nzc2OTY7bWFyZ2luLWxlZnQ6Mzc4cHg7bWFyZ2luLXRvcDoxOTFweDt3aWR0 aDo4MHB4O2hlaWdodDo1MHB4Ij48aW1nIHdpZHRoPSI4MCIgaGVpZ2h0PSI1MCIgc3JjPSJjaWQ6 aW1hZ2UwNTgucG5nQDAxQ0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0iX3gwMDAwX3MxMDM2Ij48 L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iX3gwMDAwX3Mx MDM1IiB0eXBlPSIjX3gwMDAwX3Q3NSIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1s ZWZ0OjM0NC4xNXB0O21hcmdpbi10b3A6MTk3LjI1cHQ7d2lkdGg6NjAuMTVwdDtoZWlnaHQ6Mzcu NXB0O3otaW5kZXg6MjUxNjc4NzIwO3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1kaXN0YW5j ZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1yaWdo dDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250YWw6 YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRp b24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOnRleHQn Pg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDU5LmVtekAwMUNEQTBDRC4yNzJBRjk0MCIg bzp0aXRsZT0iIiAvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxzcGFuIHN0 eWxlPSJtc28taWdub3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFic29sdXRlO3otaW5kZXg6MjUxNjc4 NzIwO21hcmdpbi1sZWZ0OjQ1OXB4O21hcmdpbi10b3A6MjYzcHg7d2lkdGg6ODBweDtoZWlnaHQ6 NTBweCI+PGltZyB3aWR0aD0iODAiIGhlaWdodD0iNTAiIHNyYz0iY2lkOmltYWdlMDYwLnBuZ0Aw MUNEQTBDRC4yNzJBRjk0MCIgdjpzaGFwZXM9Il94MDAwMF9zMTAzNSI+PC9zcGFuPjwhW2VuZGlm XT48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9Il94MDAwMF9zMTAzNCIgdHlwZT0iI194 MDAwMF90NzUiIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDoyMDAuMTVwdDtt YXJnaW4tdG9wOjI5My44cHQ7d2lkdGg6NjAuMTVwdDtoZWlnaHQ6NDEuMjVwdDt6LWluZGV4OjI1 MTY3OTc0NDt2aXNpYmlsaXR5OnZpc2libGU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNv LXdyYXAtZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6OXB0O21zby13cmFw LWRpc3RhbmNlLWJvdHRvbTowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmFic29sdXRlO21zby1w b3NpdGlvbi1ob3Jpem9udGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFi c29sdXRlO21zby1wb3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0 YSBzcmM9ImNpZDppbWFnZTA2MS5lbXpAMDFDREEwQ0QuMjcyQUY5NDAiIG86dGl0bGU9IiIgLz4N CjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48c3BhbiBzdHlsZT0ibXNvLWlnbm9y ZTp2Z2xheW91dDtwb3NpdGlvbjphYnNvbHV0ZTt6LWluZGV4OjI1MTY3OTc0NDttYXJnaW4tbGVm dDoyNjdweDttYXJnaW4tdG9wOjM5MnB4O3dpZHRoOjgwcHg7aGVpZ2h0OjU1cHgiPjxpbWcgd2lk dGg9IjgwIiBoZWlnaHQ9IjU1IiBzcmM9ImNpZDppbWFnZTA2Mi5wbmdAMDFDREEwQ0QuMjcyQUY5 NDAiIHY6c2hhcGVzPSJfeDAwMDBfczEwMzQiPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUg dm1sIDFdPjx2OnNoYXBlIGlkPSJfeDAwMDBfczEwMzMiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHls ZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6MTIyLjE1cHQ7bWFyZ2luLXRvcDoyNjku MjVwdDt3aWR0aDo2MC4xNXB0O2hlaWdodDozNy41cHQ7ei1pbmRleDoyNTE2ODA3Njg7dmlzaWJp bGl0eTp2aXNpYmxlO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNl LXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0 b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpv bnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9z aXRpb24tdmVydGljYWwtcmVsYXRpdmU6dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1h Z2UwNjMuZW16QDAxQ0RBMENELjI3MkFGOTQwIiBvOnRpdGxlPSIiIC8+DQo8L3Y6c2hhcGU+PCFb ZW5kaWZdLS0+PCFbaWYgIXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9z aXRpb246YWJzb2x1dGU7ei1pbmRleDoyNTE2ODA3Njg7bWFyZ2luLWxlZnQ6MTYzcHg7bWFyZ2lu LXRvcDozNTlweDt3aWR0aDo4MHB4O2hlaWdodDo1MHB4Ij48aW1nIHdpZHRoPSI4MCIgaGVpZ2h0 PSI1MCIgc3JjPSJjaWQ6aW1hZ2UwNTQucG5nQDAxQ0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0i X3gwMDAwX3MxMDMzIj48L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFw ZSBpZD0iX3gwMDAwX3MxMDMyIiB0eXBlPSIjX3gwMDAwX3Q3NSIgYWx0PSJCIiBzdHlsZT0ncG9z aXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6MzA5cHQ7bWFyZ2luLXRvcDoxNzkuMjVwdDt3aWR0 aDoyNC4ycHQ7aGVpZ2h0OjI5LjE1cHQ7ei1pbmRleDoyNTE2ODE3OTI7dmlzaWJpbGl0eTp2aXNp YmxlO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21z by13cmFwLWRpc3RhbmNlLXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28t cG9zaXRpb24taG9yaXpvbnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxh dGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVy dGljYWwtcmVsYXRpdmU6dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNjQuZW16 QDAxQ0RBMENELjI3MkFGOTQwIiBvOnRpdGxlPSIiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+ PCFbaWYgIXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJz b2x1dGU7ei1pbmRleDoyNTE2ODE3OTI7bWFyZ2luLWxlZnQ6NDEycHg7bWFyZ2luLXRvcDoyMzlw eDt3aWR0aDozMnB4O2hlaWdodDozOXB4Ij48aW1nIHdpZHRoPSIzMiIgaGVpZ2h0PSIzOSIgc3Jj PSJjaWQ6aW1hZ2UwNjUucG5nQDAxQ0RBMENELjI3MkFGOTQwIiBhbHQ9IkIiIHY6c2hhcGVzPSJf eDAwMDBfczEwMzIiPjwvc3Bhbj48IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBl IGlkPSJfeDAwMDBfczEwMzEiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0ncG9zaXRpb246YWJz b2x1dGU7bWFyZ2luLWxlZnQ6MzMyLjE1cHQ7bWFyZ2luLXRvcDoxNjEuMjVwdDt3aWR0aDo2MC4x NXB0O2hlaWdodDozNy41cHQ7ei1pbmRleDoyNTE2ODI4MTY7dmlzaWJpbGl0eTp2aXNpYmxlO21z by13cmFwLWRpc3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFw LWRpc3RhbmNlLXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRp b24taG9yaXpvbnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0 ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwt cmVsYXRpdmU6dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNjYuZW16QDAxQ0RB MENELjI3MkFGOTQwIiBvOnRpdGxlPSIiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYg IXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7 ei1pbmRleDoyNTE2ODI4MTY7bWFyZ2luLWxlZnQ6NDQzcHg7bWFyZ2luLXRvcDoyMTVweDt3aWR0 aDo4MHB4O2hlaWdodDo1MHB4Ij48aW1nIHdpZHRoPSI4MCIgaGVpZ2h0PSI1MCIgc3JjPSJjaWQ6 aW1hZ2UwNjcucG5nQDAxQ0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0iX3gwMDAwX3MxMDMxIj48 L3NwYW4+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iRm9ybWVfeDAw MjBfbGlicmVfeDAwMjBfMjAiIG86c3BpZD0iX3gwMDAwX3MxMDMwIiB0eXBlPSIjX3gwMDAwX3Q3 NSIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjIxNi45NXB0O21hcmdpbi10 b3A6MTY0LjM1cHQ7d2lkdGg6MzA0LjVwdDtoZWlnaHQ6MjI5LjVwdDt6LWluZGV4OjI1MTY4Mzg0 MDt2aXNpYmlsaXR5OnZpc2libGU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNvLXdyYXAt ZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6OXB0O21zby13cmFwLWRpc3Rh bmNlLWJvdHRvbTowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmFic29sdXRlO21zby1wb3NpdGlv bi1ob3Jpem9udGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRl O21zby1wb3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0YSBzcmM9 ImNpZDppbWFnZTA2OC5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIG86dGl0bGU9IiIgLz4NCjxvOmxv Y2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJmIiAvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0t PjwhW2lmICF2bWxdPjxzcGFuIHN0eWxlPSJtc28taWdub3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFi c29sdXRlO3otaW5kZXg6MjUxNjgzODQwO21hcmdpbi1sZWZ0OjI4OXB4O21hcmdpbi10b3A6MjE5 cHg7d2lkdGg6NDA2cHg7aGVpZ2h0OjMwNnB4Ij48aW1nIHdpZHRoPSI0MDYiIGhlaWdodD0iMzA2 IiBzcmM9ImNpZDppbWFnZTA2OC5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJGb3Jt ZV94MDAyMF9saWJyZV94MDAyMF8yMCI+PC9zcGFuPjwhW2VuZGlmXT48IS0tW2lmIGd0ZSB2bWwg MV0+PHY6c2hhcGUgaWQ9Il94MDAwMF9zMTAyOSIgdHlwZT0iI194MDAwMF90NzUiIHN0eWxlPSdw b3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDo1OC4ycHQ7bWFyZ2luLXRvcDoxODAuOTVwdDt3 aWR0aDozNTFwdDtoZWlnaHQ6MjA3cHQ7ei1pbmRleDoyNTE2ODQ4NjQ7dmlzaWJpbGl0eTp2aXNp YmxlO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6OXB0O21zby13cmFwLWRpc3RhbmNlLXRvcDowO21z by13cmFwLWRpc3RhbmNlLXJpZ2h0OjlwdDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28t cG9zaXRpb24taG9yaXpvbnRhbDphYnNvbHV0ZTttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxh dGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVy dGljYWwtcmVsYXRpdmU6dGV4dCc+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwNjkucG5n QDAxQ0RBMENELjI3MkFGOTQwIiBvOnRpdGxlPSIiIC8+DQo8bzpsb2NrIHY6ZXh0PSJlZGl0IiBh c3BlY3RyYXRpbz0iZiIgLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48c3Bh biBzdHlsZT0ibXNvLWlnbm9yZTp2Z2xheW91dDtwb3NpdGlvbjphYnNvbHV0ZTt6LWluZGV4OjI1 MTY4NDg2NDttYXJnaW4tbGVmdDo3OHB4O21hcmdpbi10b3A6MjQxcHg7d2lkdGg6NDY4cHg7aGVp Z2h0OjI3NnB4Ij48aW1nIHdpZHRoPSI0NjgiIGhlaWdodD0iMjc2IiBzcmM9ImNpZDppbWFnZTA2 OS5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJfeDAwMDBfczEwMjkiPjwvc3Bhbj48 IVtlbmRpZl0+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBlIGlkPSJTdW5feDAwMjBfNTQiIG86 c3BpZD0iX3gwMDAwX3MxMDI4IiB0eXBlPSIjX3gwMDAwX3Q3NSIgc3R5bGU9J3Bvc2l0aW9uOmFi c29sdXRlO21hcmdpbi1sZWZ0OjE3Ni45cHQ7bWFyZ2luLXRvcDoyMTkuODVwdDt3aWR0aDo0Ny4y NXB0O2hlaWdodDo1MS43NXB0O3otaW5kZXg6MjUxNjg1ODg4O3Zpc2liaWxpdHk6dmlzaWJsZTtt c28td3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3Jh cC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0 aW9uLWhvcml6b250YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6 dGV4dDttc28tcG9zaXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2Fs LXJlbGF0aXZlOnRleHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDcwLnBuZ0AwMUNE QTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0iIiAvPg0KPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0 cmF0aW89ImYiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYgIXZtbF0+PHNwYW4gc3R5 bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7ei1pbmRleDoyNTE2ODU4 ODg7bWFyZ2luLWxlZnQ6MjM2cHg7bWFyZ2luLXRvcDoyOTNweDt3aWR0aDo2M3B4O2hlaWdodDo2 OXB4Ij48aW1nIHdpZHRoPSI2MyIgaGVpZ2h0PSI2OSIgc3JjPSJjaWQ6aW1hZ2UwNzAucG5nQDAx Q0RBMENELjI3MkFGOTQwIiB2OnNoYXBlcz0iU3VuX3gwMDIwXzU0Ij48L3NwYW4+PCFbZW5kaWZd PjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBpZD0iRm9ybWVfeDAwMjBfbGlicmVfeDAwMjBf MjUiIG86c3BpZD0iX3gwMDAwX3MxMDI3IiB0eXBlPSIjX3gwMDAwX3Q3NSIgc3R5bGU9J3Bvc2l0 aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjMwMy4xNXB0O21hcmdpbi10b3A6MTg0LjRwdDt3aWR0 aDoxMTYuMjVwdDtoZWlnaHQ6MjA4LjVwdDt6LWluZGV4OjI1MTY4NjkxMjt2aXNpYmlsaXR5OnZp c2libGU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtdG9wOjA7 bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6OXB0O21zby13cmFwLWRpc3RhbmNlLWJvdHRvbTowO21z by1wb3NpdGlvbi1ob3Jpem9udGFsOmFic29sdXRlO21zby1wb3NpdGlvbi1ob3Jpem9udGFsLXJl bGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1wb3NpdGlvbi12 ZXJ0aWNhbC1yZWxhdGl2ZTp0ZXh0Jz4NCjx2OmltYWdlZGF0YSBzcmM9ImNpZDppbWFnZTA3MS5w bmdAMDFDREEwQ0QuMjcyQUY5NDAiIG86dGl0bGU9IiIgLz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQi IGFzcGVjdHJhdGlvPSJmIiAvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxz cGFuIHN0eWxlPSJtc28taWdub3JlOnZnbGF5b3V0O3Bvc2l0aW9uOmFic29sdXRlO3otaW5kZXg6 MjUxNjg2OTEyO21hcmdpbi1sZWZ0OjQwNHB4O21hcmdpbi10b3A6MjQ2cHg7d2lkdGg6MTU1cHg7 aGVpZ2h0OjI3OHB4Ij48aW1nIHdpZHRoPSIxNTUiIGhlaWdodD0iMjc4IiBzcmM9ImNpZDppbWFn ZTA3MS5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJGb3JtZV94MDAyMF9saWJyZV94 MDAyMF8yNSI+PC9zcGFuPjwhW2VuZGlmXT48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9 IlN1bl94MDAyMF81NyIgbzpzcGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBz dHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6NTcuMjVwdDttYXJnaW4tdG9wOjMz OC45cHQ7d2lkdGg6NDMuNXB0O2hlaWdodDo1MS43NXB0O3otaW5kZXg6MjUxNjg3OTM2O3Zpc2li aWxpdHk6dmlzaWJsZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjlwdDttc28td3JhcC1kaXN0YW5j ZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1yaWdodDo5cHQ7bXNvLXdyYXAtZGlzdGFuY2UtYm90 dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250YWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLWhvcml6 b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVydGljYWw6YWJzb2x1dGU7bXNvLXBv c2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOnRleHQnPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmlt YWdlMDcyLnBuZ0AwMUNEQTBDRC4yNzJBRjk0MCIgbzp0aXRsZT0iIiAvPg0KPG86bG9jayB2OmV4 dD0iZWRpdCIgYXNwZWN0cmF0aW89ImYiIC8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYg IXZtbF0+PHNwYW4gc3R5bGU9Im1zby1pZ25vcmU6dmdsYXlvdXQ7cG9zaXRpb246YWJzb2x1dGU7 ei1pbmRleDoyNTE2ODc5MzY7bWFyZ2luLWxlZnQ6NzZweDttYXJnaW4tdG9wOjQ1MnB4O3dpZHRo OjU4cHg7aGVpZ2h0OjY5cHgiPjxpbWcgd2lkdGg9IjU4IiBoZWlnaHQ9IjY5IiBzcmM9ImNpZDpp bWFnZTA3Mi5wbmdAMDFDREEwQ0QuMjcyQUY5NDAiIHY6c2hhcGVzPSJTdW5feDAwMjBfNTciPjwv c3Bhbj48IVtlbmRpZl0+V2UNCiBoYXZlIGJlZ3VuIHJlY2VudGx5IHRvIG9wZW4gdGhlIHRlY2hu b2xvZ3kgZm9yIHBhcnRpY3VsYXIgYXBwbGljYXRpb25zLCBpbiBwYXJ0aWN1bGFyIGF0IElTQTEw MCBhbmQgSUVDIFNDNjVDIGluIHRoZSBjb250ZXh0IG9mIGluZHVzdHJpYWwgd2lyZWxlc3MgbmV0 d29ya2luZy4gVGhvc2UgbmV0d29ya3MgcmVxdWlyZSBtdWx0aXBsZSBmb3J3YXJkaW5nIHNvbHV0 aW9ucyBmb3IgZWFjaCBub2RlIGFuZCBhIHBhY2tldCBtYXkgaGl0IG11bHRpcGxlDQogdHJhbnNp ZW50IGZhaWx1cmVzIGFsb25nIGl0cyB3YXkgb3ZlciBhIG11bHRpaG9wIHdpcmVsZXNzIG1lc2gu ICZuYnNwO0luZHVzdHJpYWwgV1NOIGlzIHRodXMgYSBwcmFjdGljYWwgdXNlIGNhc2UgZm9yIHdo aWNoIHNpbXBsZSBEQUdTIGNhbm5vdCBhcHBseSBhbmQgd2hlcmUgZXZlbiB0aGUgTVJUIGFwcHJv YWNoIGlzIG5vdCBzdWZmaWNpZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcyB5 b3UgZ28gdGhyb3VnaCB0aGUgZHJhZnQsIHlvdSdsbCBmaW5kIHRoYXQgYW4gQVJDIHRvcG9sb2d5 IGlzIG1hZGUgb2YgbXVsdGlwbGUgQVJDcyBhbmQgdGhhdCBlYWNoIEFSQyBhbGxvd3MgYXQgbGVh c3Qgb25lIGJyZWFrYWdlIHdpdGggdGhlIEZSUiBsb3cgcGFja2V0IGxvc3MuIFlvdeKAmWxsIGZp bmQgdGhhdCBhbiBBUkMgdG9wb2xvZ3kgY2FuIGJlIG1hZGUgdG8gZm9sbG93IHRoZSBTUEYgcGF0 aCBpbg0KIG5vcm1hbCBvcGVyYXRpb24gYW5kIHlldCBwcm92aWRlIGFuIGFsdGVybmF0ZSBmb3Ig YWxsIG5vZGVzIGluIGEgYmljb25uZWN0ZWQgZ3JhcGguIFlvdeKAmWxsIGZpbmQgdGhhdCBtb25v Y29ubmVjdGVkIHpvbmVzIGFyZSBlYXNpbHkgaXNvbGF0ZWQgYW5kIHRoYXQgdGhlIHByb3Bvc2Vk IGNvbXB1dGF0aW9uIGNhbiByZWN1cnNlIHRoZXJlIHRvIG9idGFpbiBhIG1heGltYWwgcmVkdW5k YW5jeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbiBBUkMgdG9wb2xv Z3kgY2FuIGJlIGV4cGxvaXRlZCBpbiBjbGFzc2ljYWwgcm91dGluZyBvciBpbiBNUExTLiBUaGUg cmVjb3ZlcnkgY2FuIGJlIGRhdGEgcGxhbmUgb3IgY29udHJvbCBwbGFuZSB3aGljaCBwcm92aWRl cyBhZGRpdGlvbmFsIGNhcGFiaWxpdGllcy4gQmVjYXVzZSBBUkNzIGFyZSAoYXQgbGVhc3QpIGR1 YWwgZW5kZWQsIGFuIEFSQyB0b3BvbG9neSBhbHNvIGVuYWJsZXMgbG9hZCBiYWxhbmNpbmcNCiBh bmQgYSByZWN1cnNpdmUgb3ZlcmZsb3cgbWFuYWdlbWVudCB0byB0YWtlIHRoZSB0cmFmZmljIGF3 YXkgZnJvbSB0aGUgcGFpbiBwb2ludHMuIFRoZXJlJ3MgcHJvYmFibHkgYSBsb3QgbW9yZSwgYnV0 IHdlJ2xsIGhhdmUgdG8gZGlzY292ZXIgdGhhdCB0b2dldGhlci48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+QWJvdXQgSVBSOiBTdGV3YXJ0IHJlY29tbWVuZGVkIHRoYXQgSSB0YWxrIHRv IEFsaWEgKGFuZCBlZmZlY3RpdmVseSBKb2VsKSBpbiBUYWlwZWkgdG8gbWFrZSBzdXJlIHRoYXQg dGhlIElQUiBjaXNjbyBoYXMgb24gQVJDIGlzIG5vdCBvbiB0aGUgd2F5IG9mIE1SVCwgYW5kIHdl IGNvbmNsdWRlZCB0aGF0IHRoZXNlIHdlcmUgZWZmZWN0aXZlbHkgMiBkaWZmZXJlbnQgdGVjaG5v bG9naWVzLiBTbyBjaXNjbw0KIGRpZCBub3QgY2xhaW0gSVBSIHJlZ2FyZGluZyBNUlQgYnV0IHdl IGNlcnRhaW5seSBoYXZlIElQUiBvbiBBUkNzLiBXZSdsbCBwb3N0IEFTQVAgb24gdGhhdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIGxldCB1cyBrbm93IGlmIHRoaXMgYXBw cm9hY2ggdHJpZ2dlcnMgaW50ZXJlc3QuIFdlIHdpc2ggdG8gZGlzY3VzcyBBUkNzIGR1cmluZyB0 aGUgUlRHV0cgbWVldGluZyBpbiBBdGxhbnRhIGFuZCB3aWxsIGJlIGFza2luZyBmb3IgYSBzbG90 IGZyb20gdGhlIGNoYWlycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24g VG9vbCA8YSBocmVmPSJtYWlsdG86W21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIj5bbWFp bHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ108L2E+DQo8YnI+DQpTZW50OiBtYXJkaSAyIG9jdG9i cmUgMjAxMiAwOTo1OTxicj4NClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpPGJyPg0KU3Vi amVjdDogQ29uZmlybWF0aW9uIGZvciBBdXRvLVBvc3Qgb2YgSS1EIGRyYWZ0LXRodWJlcnQtcnRn d2ctYXJjPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlRoZSBJRVRGIGRhdGF0cmFja2VyIGRyYWZ0IHN1Ym1pc3Npb24gc2VydmljZSBoYXMgcmVj ZWl2ZWQgeW91ciBkcmFmdCBkcmFmdC10aHViZXJ0LXJ0Z3dnLWFyYy0wMCwgYW5kIHJlcXVpcmVz IGEgY29uZmlybWF0aW9uIHN0ZXAgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBjb21wbGV0ZSB0aGUg cG9zdGluZyBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFz ZSBmb2xsb3cgdGhpcyBsaW5rIHRvIHRoZSBwYWdlIHdoZXJlIHlvdSBjYW4gY29uZmlybSB0aGUg cG9zdGluZzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNvbmZpcm1h dGlvbiBVUkw6IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQvc3Rh dHVzLzQ0ODIxL2NvbmZpcm0vMmYyYTZiMGM5ODQxNTBlNmE1M2EwYzczNGY1YWIwNDExYzY4YzI4 OC8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQvc3RhdHVzLzQ0ODIxL2NvbmZpcm0v MmYyYTZiMGM5ODQxNTBlNmE1M2EwYzczNGY1YWIwNDExYzY4YzI4OC88L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBJRVRGIFNlY3JldGFyaWF0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhyb3VnaCB0aGUgZHJhZnQgc3VibWlzc2lvbiBzZXJ2aWNlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6774667080697367696578677167697876667775686673747865687_-- --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: attachment; filename="image003.png"; size=5185; creation-date="Wed, 10 Oct 2012 09:43:11 GMT"; modification-date="Wed, 10 Oct 2012 09:43:11 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAdUAAACcCAYAAAApmTHnAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAABPWSURBVHhe7Z0tcBzHEoADHww0NDQMNHthlhRX xdAw0PBBV1nSmRkKChoeNJR0Cw4GGhoaGhoG+nXP7NpydLczOzuzOz9fqlRx4t3Zma9H29s9/fPL L/wDAQjMJnC22T/6Y9P9PvycvelOTi+6t4d+zi67q7PL3T7+T3f17+ednN+9vD8v/fPsxTIABCAA AQhAYCqBQRmdXuxeqbISZXg9KEL5f1/kv7+V/CNr+PpDsXfbQSGfnd/9Naz9z83+16ncuB4CEIAA BBoioIrih8K01qQox60qGPnzp5IVZdK5X3R/G0aXu5tBAZ9c7P6HAm7ol4elQgAC7RF4vrl9cnp+ ++K7K1SUgFWY5VuXSZVmDMv7YvePVbzde/OxIm7ws83db+3tQlYMAQhAoDACg8Wp1tIP12zZLtns leYMxStK9uNg5Q4u5v9u9v8pbNsxXQhAAALlE1BrR4NurKsWq7Mm5fvjbFfOrC+61+pOfra5eVz+ rmUFEIAABFYmMFif+nJVF6L8W87xsD6bZSDyt67k3St166+8PXk8BCAAgXwJaBqKsT4vd+9661Oi UctUoOra/DlFprs+lE5zKMXl3ykvof89RCk/eG5/plxD5LJatYMLWTnhPs7395uZQQACiQkMSlTP P0uIsrVz1HxSm24yuCZrepmfbHZPdT3382p/yqO96D5n/6FjvRlX+sGC2zjxLzHDQwAC6xHQF5wG pPSRoFmlqgyW5RClej81ZD1ieT9Z3a/fi1uoe16LW/ReBvPxYSJ/M/A02A+BrcpUPxrypsrsIAAB CBwhcF+JilW3roVjrZe+oMHulSoDXrDpt+5QWaqPyDaVo/JIZTI5yCbFh4IW6fcBT4AABAII5KBE 7QvbvjDV/UdOZIAgF7hFzz6Nm1k9F9bC1QISq3kvTHqPKllyaBeQPo+AAAQOElhfiZrzzevBVUuQ Sh0bVRXbUKzDVLZaOOK7t6SvdQ51EGUVEIBAtgRUkaoSs2eQy5yX9RbMh8FdRypFttsj6cR076mi M4FTSylaey68VYtaXdlJF8jgEIBAGwRUiZk80SUUqZy9mnzUvoh7G4RZZSgB40KWvSmKTz66tCFA 4g89Ueb6UcmHXajEuA8CjRIw9XJtq7K051z3lCjpD41utojLNh+AalXaNK203hQbfHdF+7yIAmQo CNREwJxlSUpEUkWKEq1py2S/Fo3sHXJuU6b59FbyVoPjiCbOflswQQikI6CKtD+jSpLyogp6cOdi iaaTIyP7EzB1o23TBQ2CSrLv1R2tCtZ/VlwJAQgUS8CcQ2mD7QQvlN7KvbbpLAR2FLtJGpp4ypiB 3oK95gy2oQ3FUtsgYCInjWs3bg9RW3u1e48SbWMf1b5K/RDUmslqacYOejJeGx2bj83atxHrq5lA X6BemnLHi4okj6/mHcPaBgKa92zyZW1XHCkqEu93yFT3Ig+WzQaBMggksUqtq/iaSMcy9gCzjE9A y1pq/EHMQD5V1upBwj0cX16MCIHZBDTKMabbqn95XFG6bbZoGKAyAkMRlL5r0bcoVqwWtJB0IKKH K9ssLKcsAno+Y5LfIwUd2XOf7i1fzmXtA2a7HgGTtmNzYyWaOEJnHhlDXc54hdaTKU9ukEBvlW5j fCFrkrymGJDy0uBGYslRCeg5rFGwscoo6seyfDRjvUYVE4NBwBLQXywTPRjDKpVfeiIR2VkQSEcg ZmyDjbLfvSNyOJ28GLkhAhogYQoozHQtkTPX0KZhqVkRiOZZsu+Aa7xKWYmXyZRCwBZpMO3NZgVC mBqo4pKiNVopkmeetRIYvE0xIojNhzb9X2vdKqwrJoEoyrQPdlArN+bcGAsCEIhDwFRyMoX/Z3fX +cDveRyZMEplBPo6vLMquQxVWwhsqGxzsJyqCcQp0iJeLUmrqxoUi4OAD4EYylTD+fla9aHNNRDI l0CMFDkTzU8x/3yFzMzSEZitTPtweyIC08mIkSGwFgEtYzgrpkLfD8RSrCU+nrskgdnKVJPMcfMs KTKeBYHVCPRdpYKPhbQUouahE6i4mgh5cCoCGgY/p4ygjfajnVoq+TAuBHImoB/j5h0QmA1glCtu 4ZxFzNx8Cdgk8Bm/DHIveWm+tLkOAnUT6D/OpR9yYElEKfxC/EXde6Ta1aFMqxUtC4PA6gRM71fb I/lroPW6xfO1uhiZgA8BU//TFLkP+5JUqxbL1Ic010AAAragRPc2qOer5rPLvZy3so+yJaABRKHV UlCm2YqViUEgewKqGDUgKaQ2uOnrStP07GXc1ARNfplG5QYEEaBMm9oqLBYCyQloKk3Yx70UkKD0 YXL58AAHAf06DDnXQJmytSAAgZQE1PoMcgtL+UTOW1NKhrEPEjDdY7RY/UTrFGXKhoIABJYioG5h PTedGuNhDAWJDeG8dSlJNfwcDQzQQthTlam6hwlAanjjsHQIrEgg+IhKKjNx3rqi4Gp/tD2r2H2Z olD1bEOrotTOhvVBAAL5E9B3UZiHbXejnXXyXyEzLIKAadMkSdNTlKlxt+A+KUK+TBICrREQ4+DV VANheKe1xor1RiRgziMkwXqSMpUzVrnnBldvREEwFAQgEJ2AyXENeL+pgYHVGl0c9Q9oc06nunrl eord1785WCEEKiKgClINgUnGQ++JqwgDS0lFwH69TazVq5VJ5IuPSLlUUmFcCEAgNYGg4jVYranF Uvb4fZrMp0lfbJe7Pa6QsuXO7CEAAUtgKLM6KfdejArN14chBH4iMPVsgVZKbCAIQKBWArZg/zSP nXEh056y1i3hv66gyN7L7krdxP5P4UoIQAAC5RGYGlti4lCIKylP0LFmrGHlkyqNaFoNtTFj4Wcc CECgAAIhcSbEmBQg2JhT7Ksi+RfAJ9ItJn7GggAECiQw1Wol9aZAIYdM2YSPS5Uj32AkrT5CIFII ae6BAARqIzDZalWDRCrR1caB9fQETs7vXk6JasOFwdaBAAQg8JBAb7V+9TVOtF46KYcV7SQTJi7B Rb4bQA/bqddb0QZgKRCAQHQCtki/9GD17dRlYlL2j6JPhAGXJWAEP61u75bI3mVlxNMgAIFyCZjW cp6K1UQHE+xZrrBtMQfpC+gjcHz/5QqamUMAAqsS6N+1fh28tFiEHMWtOmEePp2ACs03XcYELvH1 NB0yd0AAAhDoCfQF+qfUEL4CXiEEtOWal3VqLVjcvYXIlWlCAAL5E9CShf7v392e47aMZWpbtXmW 1qJeZcaSZGoQgEDJBGwzdL+jN01bpFVmhtK2BR08I9Euus96BpDhMpgSBCAAgSoIqKJUhelltco7 mSO4jMTeC8+zoAPuhoxEx1QgAIGKCfTpjF7V69SyJZUxg82gXze+bgZNQM5gykwBAhCAQFMEvM9Z iQxed19MUaj0+1tXVjwdAhBom8CUc1be1yvsFS2T5ZUyI18+p+e3L1aYIo+EAAQgAIF7BPSoTrIz Pnuds0oVPOAtRMBXoVK9YyGB8BgIQAACngRMUKlnlTvN5vAclstCCWjHA5+vHMK0QwlzHwQgAIG0 BPoApg9e73IUazpheCvUy90NCcXp5MDIEIAABGIQ0OBRFGsMkgFjTFGotBgKAMwtEIAABFYgMKEC 3pZ3eyQB+StU/O+RkDMMBCAAgcUI+NZqlx7XNyjWmWLRyF3cAzMhcjsEIACBzAl4B6CiWMMl6Q1Z +vmFP4U7IQABCEAgBwLe73yCl6aLyxeu+uOnj84dEIAABCCQIwHfd7+4gt/lOP8s5+RbKUk7zme5 ACYFAQhAAALBBHwVK5WXPBA/39w+8anli0L1gMklEIAABAol4K1Yz+9eFrrE9NPuK234lLCiMH56 cfAECEAAAqsS8FKsUopWr1t1ojk+3FTY8ChdRdmqHKXHnCAAAQikIWAU62X3bezHeDelY1maGRQ6 qgDz6bm3LXR5TBsCEIAABAIJeNUqMI3O948CH1HXbXo+6vwSITepLqGzGghAAAITCPjoCfV2Nl8c wlTScJr23cfmQU3YfFwKAQhAoEYCnrWC24250aa1zp6omPQ1/m6wJghAAAJBBHyOCptMtVHft+l3 OmKlcvgctOe4CQIQgEC1BGzbuN1+1MMpEcFqtFUL4dDCfKAQJt3UlmCxEIAABLwIqFEm56ej6Zdq lD3b3Dz2GrD0i7wOnKUZeenrZP4QgAAEIJCGgKbQeBwf1h+4ZM5RXYFJ1HRMswsZFQIQgEBFBHwC XUXfXFW05J+Xoqa46xxV3cLVAmBhEIAABCAQlYAqTZehVuX5qk/FJKNwSd6NuuEYDAIQgEDtBLR5 uSPotT7dom16mvyaqH03sz4IQAACKxPwqRuvinflacZ7/Mlm99SlUOk6E483I0EAAhBojYDRM1pc fyRmp4r8VXX7isL8NK5UOUdt7ReA9UIAAhCITcCZWSJKV9uLxn7uouO53L6coy4qDh4GAQhAoGoC rhoIong/FgvAx+1bZVRWsRJj4hCAAATKJtBX6/tanRvYz+3btVv4uOx9y+whAAEIZEvg9Pz2hauM YXGZJi63r5aYovNMtnuSiUEAAhAomoBHR5sPxSzQp3wUbt9ixMlEIQABCBRHwHpLHU1bxKItYmGu RFz9gihiIUwSAhCAAASKJeByA6vSzd5j6loEbt9i9ycThwAEIFAcATHiPjjqJORbG7gvRTjajge3 b3F7kglDAAIQKJaAbRM3UhRC/0463mS5QLFCXzu+CMo5GM6SMJOCAAQgAIGpBLSSUnG6ye9rYP9o KgyuhwAEIAABCMwloEUfRhXrm+5k7jOi3i+T3Y53CejeRn0gg0EAAhCAAAQ8CZislJG6wFlVWnJP toAIK0/BcBkEIAABCJRJwGX8nZ3f/ZXFylzRVdqdPYuJMgkIQAACEGiWgOuYMosUG5eVKsFLfzcr QRYOAQhAAAJZERAj8CrrusAuKzXbUOWsxMxkIAABCEBgCQLa0Hys0tKq1qrTSpWk2yUg8QwIQAAC EICALwFXis1qzcyxUn1FyHUQgAAEIJALAVddYIkE/rT4XLFSF0fOAyEAAQhAIBIBl7WqJXcjPcpv GNdhL2epfhy5CgIQgAAElifgslYXDbK1NX5Hailylrr8DuGJEIAABCAwiYDLWl3MOMxmIpPwcTEE IAABCEDgBwGNBM7CQByroai9VBEaBCAAAQhAoAQCo0eZpoNN4pr1J5vd09H6iUsf7pYgNeYIAQhA AAJZEnBVWdLua0knPlY7cdWk2aSrZnAIQAACEKiVgOi162PGYtL0GpdGl4e/rRU664IABCAAgToJ uDyw+vdJVu5sQp7a95xkVQwKAQhAAAKtE1CLdORo8zoJH83bGXkoJQmTUGdQCEAAAhBITWDMaJSj za+aShp1Ds82N48JUIqKlMEgAAEIQCATAuZ4c6SJefReq4tr8UxAMw0IQAACEGiDgKaEHg1Yip0u ena52x9/WPe+DeSsEgIQgAAEaiVwcn738qi1Kjmr0VzATrP4TXdSK2TWBQEIQAACbRBwleCNVmRf DmlfHc/hSXCA24b8WCUEIAABCGRGwNHSNE4UMK7fzKTOdCAAAQhAIAkBDUg67gLuPs9+qMscPsP1 O5sxA0AAAhCAQB4EnMedm7vfZs30j033O67fWQi5GQIQgAAECiIwWpNhbi1gLT1IwYeCdgNThQAE IACBWQTG9d5uP2vwsfNU7as6a3BuhgAEIAABCGRGYKwWsFZXCp6u8zx1rm85eGbcCAEIQAACEEhH QJXnMS/t883tk6Anu85TgwblJghAAAIQgEDmBMaqK5kKgxIlrG7i08vuvfHoXnSfVQmPdrThPDVz qTM9CEAAAhCISkCjf9WgHFWqx2oEi2IdnczYoJynRpUjg0EAAhCAwMIE+vQZaVC+2ztav30bLbbf K9kHPcVVO983XeWCj8cGSta0dWGoPA4CEIAABNolEGSRHrFUH5y1+mji4RotPKxKOFqB4XZlysoh AAEIQGAlAmqtjgUleetF6Tf+YAneNx/S0lLBv0+/uVqJDY+FAAQgAAEITCYwWppwrMfqvb87eCQ6 S6kOg5NmM1mg3AABCEAAAusSmO0GFos3rqVqlWqcCv7rsuXpEIAABCDQGIE5bmBVyAdxzbFUxSf9 5c/N/tfG5MByIQABCECgEgLBbmDJWY2uVDVwqRKuLAMCEIAABBolMFaa96DhKfFERwN2Qy3Vo6Zv o0Jh2RCAAAQgUCaBZ5ubx2cm8NYcafr8bI+udLTdzdEKErt/gusglsmcWUMAAhCAQMUE5DjzladC /TbaUzzEn/yggkTFoFkaBCAAAQi0QcDHDayxRKO1Gpxdaf5lrWpZJ4o/tLHBWCUEIACBlgh4uoHd GS+aFuNr9mpFpZYgs1YIQAACEGiHgMsN7FWu90yKN3gq1eOHs+0wZ6UQgAAEIFAxgaNuYFdHmvtM xgrpq8I1dRIPVY+oGCxLgwAEIACB9ggccwNL1ss7bxpaw3DMWlWT2HswLoQABCAAAQgUTOCQG3hS 1otWRjqap3OoEn/BsJg6BCAAAQhAwEXgvhtYvbmu6x/8/ell9/6gtUrB/MksuQECEIAABMom8JMb +KJ7PXk1Gtl7QKnS1m0ySW6AAAQgAIEaCHx3A4fGFGke6qBYnUmuNRBjDRCAAAQgAIERArMKHt0P WDo9v30BaQhAAAIQgAAEAglo2kwfsPQhcAhugwAEIAABCEBgICDu360e0EIEAhCAAAQgAIGZBKjt OxMgt0MAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQWJ3A/wFX/7Vqq4/70wAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=21096; creation-date="Wed, 10 Oct 2012 09:43:11 GMT"; modification-date="Wed, 10 Oct 2012 09:43:11 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAdUAAAHFCAYAAACkb2NsAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFHoSURBVHhe 7Z0LYB1lmfffd87k5KQXSlqudbkVRNIWQaCURlpFClZgXUGLuOh+iuvdDz/YXV0Vm6Ze8bqKq4su 6LqgCKsiglYIFxtsaCt4oW0UkIWqINA2gTbXM5fv/845aXNrm7an6Uzym5KWJOfMPPN75sx/nud9 3uf1GxsbDRsEIAABCEAAAntPwN/7XbAHCEAAAhCAAAQcAUSV6wACEIAABCBQIQKIaoVAshsIQAAC EIAAoso1AAEIQAACEKgQAUS1QiDZDQQgAAEIQABR5RqAAAQgAAEIVIgAolohkOwGAhCAAAQggKhy DUAAAhCAAAQqRABRrRBIdgMBCEAAAhBAVLkGIAABCEAAAhUigKhWCCS7gQAEIAABCCCqXAMQgAAE IACBChFAVCsEkt1AAAIQgAAEEFWuAQhAAAIQgECFCCCqFQLJbiAAAQhAAAKIKtcABCAAAQhAoEIE ENUKgWQ3EIAABCAAAUSVawACEIAABCBQIQKIaoVAshsIQAACEIAAoso1AAEIQAACEKgQAUS1QiDZ DQQgAAEIQABR5RqAAAQgAAEIVIgAolohkOwGAhCAAAQggKhyDUAAAhCAAAQqRABRrRBIdgMBCEAA AhBAVLkGIAABCEAAAhUigKhWCCS7gQAEIAABCCCqXAMQgAAEIACBChFAVCsEkt1AAAIQgAAEEFWu AQhAAAIQgECFCCCqFQLJbiAAAQhAAAKIKtcABCAAAQhAoEIEENUKgWQ3EIAABCAAAUSVawACEIAA BCBQIQKIaoVAshsIQAACEIAAoso1AAEIQAACEKgQAUS1QiDZDQQgAAEIQABR5RqAAAQgAAEIVIgA olohkOwGAhCAAAQggKhyDUAAAhCAAAQqRABRrRBIdgMBCEAAAhBAVLkGIAABCEAAAhUigKhWCCS7 gQAEIAABCCCqXAMQgAAEIACBChFAVCsEkt1AAAIQgAAEEFWuAQhAAAIQgECFCCCqFQLJbiAAAQhA AAKIKtcABCAAAQhAoEIEENUKgWQ3EIAABCAAAUSVawACEIAABCBQIQKIaoVAshsIQAACEIAAoso1 AAEIQAACEKgQAUS1QiDZDQQgAAEIQABR5RqAAAQgAAEIVIgAolohkOwGAhCAAAQggKhyDUAAAhCA AAQqRABRrRBIdgMBCEAAAhBAVLkGIAABCEAAAhUigKhWCCS7gQAEIAABCCCqXAMQgAAEIACBChFA VCsEkt1AAAIQgAAEEFWuAQhAAAIQgECFCCCqFQLJbiAAAQhAAAKIKtcABCAAAQhAoEIEENUKgWQ3 EIAABCAAAUSVawACEIAABCBQIQKIaoVAshsIQAACEIAAoso1AAEIQAACEKgQAUS1QiDZDQQgAAEI QABR5RqAAAQgAAEIVIgAolohkOwGAhCAAAQggKhyDUAAAhCAAAQqRABRrRBIdgMBCEAAAhBAVLkG IAABCEAAAhUigKhWCCS7gYAj0NCwxBpjzeLFN3ttp86oNqbNmrYhbHKFQne1XmZMXAFu5f10dxd6 tLcw2WOtvnTcDV3rex/5yuVB8jMdq3HZskocsQJGswsIjE0CiOrY9CtnVSECDUuW2EUfWJ4Panz3 WfElhvluW7CF2FRJFJPPT2ACa+LCwb6NjlrUcE/OM3dFHZGZmO9sm+neY/LxQCGzZkoYVx8nkXPv 33uRixN5DvLV9jETR88np95pbVww4Yz8zCdnNNz5nGf9KFoa5NaY+mJg/N/4NnBCG3Yb01uIu50N QXdNV9G01cb+9KC4/PJFRQS4QhcRuxlXBBDVceVuTrY/gbq6Ou8bj9cW9DOv0NVd5QSw29T6BdOV l/BIRaOXnre0qcZM8Y/Im/gQk7MHh1H1kdLIqig2R0nKDo5jzzpttTaw+pn1+g5gYwmdpy/9a71B whlbbYkSVmpLDhDHr9h+LB0j1h8rQY91/Dgynv5E7mTjICqFs3F7lbWPhaa6qG825TurN0iIi3aj /7TO+2kJcK+QPGZs0F6Wfmlwd9RtCpGpMT2KhGNFxGHThxb2IMCV8iT7yToBRDXrHsT+YQm0HHi6 H3QdnFcO1DNdxqVac9uiy9gcqMjt2DXrTKEqKp5krVcd2cIRcRwfUhV3HRLZ+CjPhF4kxSwrn/6V XEZODMs/cnqpXw4Uxn7aue1/k1cM0U/3670PUQeeuhNqHap8rL7jDqfeNld+0cES24OTQLekyqZP iJ0UOwFWMCsM7jzjUH+vj0x1Z1Ucd9pOr9VWmyDuiF+QAD8mAVbqORFgJZ1rumpMV7GtyxRrH2/r nj27taThbBAYBwQQ1XHg5LF8ig0NDXbhZ+6qVtRUXaipUUDZNskz+aPNZu+4fNz2YkVv1dKHEyQ4 k/qiSxdBRnGQBJWJSrpoUv+5mDPRpD5d6pO9svr1iWDyb1SSnDRtJfuGkeqdqncyBJx8iUCCJKGy 7TFgmwBXieUpLtp1Mbj+/1wnweVDlmmEkbh0Gdu5dquxf6oueH/qOL52XUtU/5RuNI9qz13dpjsw hUKXXxMU57WvViTMBoGxRQBRHVv+HNNnU4o+/WqlaieYblMd+JOmnrf07pcoEq0zheDYKOo8zpjC KYonfS+OpBAKJ/VncHRZgtRfKSW7fT9x8VmlQ8hUe0Unuw3FcJF2f+PLAlx6GEn+Lj2EmFzpVVb/ ehLfqF6iq//0V86F+55ENw6E9rEqk3/a64jWxR3+n9bkztygH67T4O7Wgu3u7u4q9NbW1vbe8qFT u0knp/qiwbidEEBUuTxSR8BV0C78TFNNbbfJd8VK3RozQTfe472N3rF5Gx0XxfnT4rw9NucFB8WR buRJmlZxZnKDL41q9k/MbhPMfRhdlkVmO8vtoV4/vonC70PeiZAN3f+gn5VesydPDv0FePCDSf/T LEX7JcVVpjnJBhhf6YDZim71FZ+jX0Ta5DgTSYWfV+HWH/LV5vHOzrYNi5beubbF1G8w1n/Kj4Ou Gmt6tmwOuuZNW+2qm9kgkGoCiGqq3TP2jStHn0oIdteoAKbgB0GtxuhOsF3xSVtje6xuvsfq7jxb qqlqIBd9Kvz0cn2Rkv51N3rdrpM/2solOBUhVxKGbengbcKZ/GhbSVJyqCgoStCUYC6lkt0wpUtt lqay9G3Jb2P93A78+V4b6848EWuNIZcqkpMt+XGSrFUxVmJw8hMvJ5RimLykT2Cdbf3FtizECdXh hHpnNvd/b58dyetLkW6ZXZJtd9Gt/jlI0e1BOv7L3dG82IsSx8aBAlm7bqsXPepN8X/bEp2xOrAT Hy2Yti5FtV1NV5/T2djYuCdPB3tNnB1AYEcEEFWujVElcOOmA6tOmj5zggbXJnYb/2/8jb2n5W08 UxWoJyliOcHmqqaoIEjlqgo9+4Y8B41xJjf6vYw6twtkKXIcTjAToVQ0paMFMqFX/6ObfawKWOsG VPWvvndWRkpsRvZRacHzEgZX7RtKMZ6UiRs9z3fjjO5xQGIrxdfP9b6Nvqa4uN1WBr57svC9qBgc raLlg6Io8JRydZCE0fpxGNdJzCeqCFmGWC8Ke482kSchS8aTk+pn96U3FJLHgdI4szIEKm32fOMl s4kGCrDT55J2bhddPVTs4nRKkW758WdgsFwey06i2ySdnKDRweNT9Vxwqv7/jRLbsCrubA9M/mFF tb+5YOndq1qi6He+7W6TyHZu6Dqy69JpN7lKZjYI7DcCiOp+Qz8+DqxINO9vDiYaW6gxRf9vjpsS zOnoNHN1Z52bN8EMBSq6geru7u7j/cWzfPNNoqdd3qyHsiylgksVOEP+Xz8NJZgSO1drI+W0RUlh IJXo1YtdlNQl+0J9v0EC8Iy+f067UTrS2yI7f++mdHZ3mVbN5+zsO/Lk+7fEixcvLkdNt5iLL14c NzaWGy30BbUDg9vKXwB505zsdNBxGmbVeTebxfrFLfparL9vsVueniw4M3Jm8wY3l3aCzqvGhmam 5Ez3hOgAPUwcJzGTi8LDwyic7ihqXLTa5XMTqLEm1bgjJaG8E2ar54d88q179iiPqW7/d1fp5gGR cX805VRyMgfJKoVsFNFGZ2n/Z+lZJvLiOAjjwtp8wT40I7/hty1x/W/8LvNEd43prO2q7Zo94Y6u yoNmjxDYMQFElaujogS2iagpTFAcdoy30Zweef5cSdTJxnMi6opZVEqkWCoRvb6b6R6KZ3/RTAKs 5N5rTVjsdVFmUUfolWC66MWlY51gduuYoQ73mL5t82zuL6GNn9Y7N0fWPq7XdAc18W9VnRr0CeXF i008pHBmgl7Z3g/dbGNaW5dt+4EEtaJc92Znja2tUavps2eZkanlbXUgWfz1tm990+T+31VU33zz zULXX4D1ymfN0bmqwrRAjS9UP12nh5KJisALErY6Zb5romJPnbR1cjnKldC6oqW4YH1f7nZD36UH pNK/5YT9LlPL/aLbvkRv2cdJRG2tEh3xKRJaVSYrzo40Byhv/pyP4t9uzW/+bUtwxq9NLv+7ySbY 2lYwne+csbBTftpVSL03uHnvOCeAqI7zC2BvT39YEbW5M3TTnKPo52+0f91N3e2vHDkmN1N3T939 Ktv+olkSTzUzUEbVDb1pl52xDV0hi75sp2606ySmTxrPe0J5zWekHhsUYW6VYLbuUjDLe3Hq44Qy Rfq4t+4a0fvdOGVra6uY9hdgvTVvHkl2UEpar+iLiOtm1umZZLG56v6v5I6sPfUg33TN8CL7kihn j7BhdEIcFI+NvaLmxHqKbmNNe9KerFLNGtj1qvRtn8gmAtsvyt2RteVraPtY77ZsRBLN6udHa09H 65vXJs0vlMffGkcP5Tu9B7697p5fe3bB77rj4FnF2lvm96zcOiIovAgCIySAqI4QFC8rERiRiLpY cYCIuvG33RDRvkjEZRe3j7UpZathzNi6nnou6uxWYNKpUcLndCP+Y+x5v9Kd/bHImj+a2iMemXz/ b8Nbbl4cJRFm/5HLcS6Y++I6lgDLucvMpdOcIt79tI7xtFz3y1LEG1uXbm57cMaEQs2W2VEYHGFy etgKwxPDODoqLvYcpdfXSPryumSqlZCvls+rcn51aew1mZrTJ7Q7CjD7j++Wz7B0DZXU1tpqpbLn SbznJUXHymerfdbvbadpavHqmwJT83Ct6dpi1rVtoVHFvrhCxtc+EdXx5e89Otu1nefXtBXaDtSA 1rFem9K58aBIdG9EtBxx9k2Hcf+WC4RcQ91uJQu7VAzUa0IVCFnzkH7/qFKN/6u04/qge+rDtaee 2qnRQkVW/VJ67SuNizJnL0tPCnaPwGf8TaWId1mcpJsntG5xz2QasW1x39adWOfdcouxW848KRe0 bXixH3tHKqQ8Qb86Rs9AR4bFntnyu1PWglRVY/KmJlelb/tE1s183dnUoG3p5T6IfdOZlN7I6ZEv jk+UWJ+oOuPLVfz0TKf17g1nTrm3JV5wbxAHz/tTgy00p8j4BbifzEdU9xP4tB+2ubp+gpoqTJGd x1XlNy+sCu3rdDtSUYsbE92LSHSbiJai0CR9q3JUxSSd+kGPbqIduh8+oTG7P6p8yYVAv/NVMBQc FDx52eGLgosv1vhmXwGQG9dsvcO0ph0m9g0h4KLb2U5t29XC0Jp1yZcxP3MLGNwssb3q/kdyx099 ZHoQ5Gcqha+hBPsyCe1LldKfpKizRoo6wfOr3NyqftFsn9AOB3xwNLstZeym9EzXg9qlUts3mai4 VVHsL2ybf5+Knn6pB8knnu6qfeG1FDxxFY+QAKI6QlDj4WVrq+sndbV1HxjVTDihujNeqFvUa3TD cTe1ZAb/thtYMp1ihOnc4UW0R1FJh+6GHdrVE+oAsCpnvF9ppoqr2vxt7YNtxVtccVCSVixv7dLP 9tWmsXE8eGL8nqNL1+shKS6lkjUmnjdPKo283KWRr79/eZVfa05R84+Xaaz05DDoPU0VUBqrjd3j 1QRdn4VS2lhXbjJl2InsLlLGfYVSpTnJmonkH6D3/a12cYEKsEINJ/zmkOr2n62Kz1zRqwYVprvr habPLHyBjk/j9xrd1ZkjqrsiNMZ/31x9/uRCV9sBmnA503ZF58X5wnlqoHCcokQ313Fbhe6Ip7aM REStXZ3z7AO6462paW3784BxLDfm6VK3hJ9j/Mob+en1pZHnTXNFaEofe6bFdd1a9OXluVybPUZa eFJoopMlgS8zsatAthN1vU5QLfBEFUKVRtTLVcd947NDjt4/Xdw3HqtJQrpGT0u+NBCbj7v+pE5e d5+39M67tIDAKo3wv7Ch7cgXmBs7cl+Oh1ciquPBy4POsbmzfoop1ByQN10vzXe1nafhqYWKEo/V RBc32lSq7uzrsLOrOaKDRTTUdM8oHBiJDhLRW265OEo64bjjbJ/fMQ49wSnvKYFkCKBdc4utGvW7 Zv3G/I8bp/3Gg7UHFvLxS1XtfbKqvee6lLFE90CNz0toNR83l6sqTY120aybijxMQ6YB47F9aWIt k+uW+4vjy2zsvTWMTVuVjVfOmPrnO7VgwC990/3nR9qOb0dg99SjY+d9iOrY8eUOz8SNUy1ubJrS FpvJ+cg7KV+I/85EXefohnSEm7S/XUhHktZ1STI3HloeEy2JqAqKog4Vf2h6gussZH6jm9hqxbmr XSQ6WERnzyaHOw4uu1E/RTdOO3+C2awD3+e+3HV//Ae+4h8/9aXHB2HvXF2zimbDkzV/+RgJ5BRF vJNzalhRKn5yY/vDpYrL/ZT7zZHV/FuXxpmm9/2tCp0uUKY5iEzh3hlTNvykJTr9Z5Otv2m2Xdk+ 6gA4YCoIIKqpcMO+MULFRkrtdmsll3vmdVjvvHwULVBEekSpgZFL7bqIdARC2i8adZaqrqhX6eIt iYjG5tE4Z1cr7Hyg6BV+9c6ZL3/m4outionKPVldKhcR3TcOZq87JZCMe05zjT9WrFPV8TqXMl68 +Bava1btDGVzz9FCRq8Jo94TpZFuHFUCW+2XxmNLXwP7KJYPNShNnAzEejm3Ms+5mg+tffqbO7xY Y7D1N+gTtlY1Aps0F9a1tGQbJwQQ1THm6Bs3XVJ15NQNtVrdoy7fFV0chPkLc158qFrSbhPSbdMS dtaKvE9IJb6u6COOAs0PDbfovX9WJHqvFPm+opWIznr5M/2ns7S23q1iIiLRMXZZjYnTKVeNuwXT H5XIPlpXV/cf31g//dB82HWWLvdX6hI/S71KpkhYD9CiA1rY3l37LkVcmic7ZBtmHFafMkWw5s1a 0/3vw9g+mu/wbmzJLbjTN1v/GNT67ZqmU+HFFMaEa8bUSSCqY8SdLir1u4NpR0/ZcIFSUhdZU3Wm bhRVOTdhINkGpbGGO+9tQqomSKWpLt36et7NC9Xj+L1RXLzPHDTjvuUfeEmxLxJ1IsoGgSwSSNLF tvVpCex3lSr+3sKrb5lY6Kit1xzoc1RZPF/p4iP18DhFU7/c9J1EXJModrg6g8ECq2ZRKpR6iT53 y7wouCqyhTu9Z6OftFSdfqfWBN48f8LKF7LIDJt3TQBR3TWj1L6irm6J9531TVM1WX2Wi0rVXvxC 39rDSp1knI6WU7s7OwP30mQpNT2Vu/HRMOrS3NE23RD+GOfMCu3ip685+JzV7e3LSk/YmtYyj0g0 tdcEhu0ZgfIUma0S2Ds1heeuxTfH3pZ1TSd7UfwaPVS+Iox6XqIPitLE8QG5vBo0lcXVPXwOG8GW I9uk9sCzeWV4LjBe7nwT2r+qh8WtKm66VXNgfxdsDtpYJ3bPfJbWdyGqafXMTuxSVDqx0GUOWvVw 06ukiW9UQKp/1dqtvDpJaWm0Hed2E81NhDSn8dFkHdAt6s/arnf8XjeAX6ju4ieTWhetmz17mZuY b9pdhyI2CIwTAkkWplXXvmcedF96eP3Ud9Y1HaFFjV6lD8s5qiieq0/QFC0KeECuKu9C2O1p4kGM ts3nTj5z7hOXO1yvfo+N4ndqGOXXZkr+FgnsXXpi3dC0dOFm5r9m/yJDVDPiw7Vr63IqsKg1sf/i fGdwoZZbWSzBO6qvuVEpKt2ZkLonZgmpxkiV2pKYhs9rtTOt/2lb9WH/mdo7/PT2hoWPbftQz16d ETKYCYF9S8DVDMzx3OIM5lsqdvr24qW/rO2Ke16htV7PUu/iV6nQ6TB99qa5SmK3tG4SvQ7+LPal h2Vq0pIz55btMaep3uE0RcJL8jlv+QVLm36o+a+/VHHTRhU3qTkKWxYJIKop99ptnXU1hxdqD4lO 8M5Savb1EsJXSxjVSa207TwqLU9/0ec3kpDq/W1aTFtjpNHDqta9tZgzTU0NZ/+pT0jnLCMiTfnl gHn7mUC52GmzHmh/JFN+1NxbP1FT1BapEv4SPazOkWBO08PrpGQ4pVSXMMTivlV5+pYt1LxZN4f2 9Yp8L1Jl/oZ8Z3xzi63/ntaP+CNjr/vZ4XtweER1D6CNxlua47On+nHXUQcXvAskgm/TiixHu6Vf 3EPurqNSJ6Yl12oN566oGGzUB3h1ZIJbfc9vun3ZOc/0Cel8hHQ03MkxxigBiZ6LKH/Q0Ljkhxcs vf1ItVBcrCzQheojfKyEcqqv9HBSbR+pXmFIJqlf8WCpSNDVQhylfNO/aND27fmCuXlNvOA7Jt76 +zneQ21jFOGYOy1ENUUuVYm/9431tYf6YfTyaq/7jUoLvcZ6WqHDNVsoR6VJT9MdbKX0rotKNU4a FjfrQ/yk3n+H50U33N646JG+RvREpClyOqaMCQLlz9aT+qB+fm3dki91rWs6M7DxRcoQnadmEdOk mLVJBXESvQ4zB3ZQelijr1P1SPxu1Ty8xXoFFTadcb26RP12vrdy05gANoZPAlFNgXP7xHTVenN2 PorfrXB0XvLYmrRTKy/ovSMhTQog5EapbhQEPVEcbtL89V/pM3pDENifzp/QkozNzGlkjDQFrsaE cUBgdqnI6Rc61V+sic9eGsQd53mR9+Y4dsvZedM0B1aLtbtOieU5sIOY9C1pVy4onKgP96VqLPHG vDE/XhXVf8czNS1zvLu1jjBbGgkgqvvZK81x/SES03OrnJgaianmt23vu7vrqDSZBqMpMKoydItD 31G05vtNL13460a3vqg+hWwQgMD+IzDH3t2mB94bG5Yu+e6FS+97cXdUfHMUK3q1nhZnj2vVYyLn WiS6JRAHFzdtWy+2lBr29dfrlUZ+XWy6mlYF9df3eqa5dn3bsyysvv/8O9yREdX95A8npkrz1kv3 3qXx0nO1IIbE1I29OCHdgZjqw6WWaMlUmDDs6Y2CcKMKG34be/bGg72anx7nPsDa5rdScLSf3Mph ITAsgaSGwTOP6JdLWk4/fVn0gH11LoouUnHTK5RkOkjFh1Ose54Oh4let6WGnbgqfWXNq20UnqMH 8VUdJ9Rev6bzlDuD6f5fWVQ9HRcfojrKfugT0yprXJr3HI2BlsV0B71GZV/fWGmSLgqj5yMTbtRi zT/R1w3LG89+iLlto+xEDgeBvSAwb7VaFXrmDve1Jq4/NIq919kwXhxGxROdwHp+3hu2cniguKqp v52n180LqwprtYzA9ZqOc6um4zxNr+G9cE4F3oqoVgDiSHaxQzHdUV/Rspi6yDQMir0qbtissdL1 elS9xcsd+KM59o5n3HHnUb07Evy8BgKpJDDHrnxGkee1dbOWfPPb6+48W5/xf1AjlrMkuIdIXKt2 Kq56qk46NuXsbA3/fFFJrsvzHfYbLV79rZqOs6FcmZzK8x7LRiGq+9i7Wrv0kELeq6+y0cDIdBdi 6qJTjZd2Kz30lFaWuT0K8j+Y/Mhzv2T8ZB87jN1DYD8QcA0m5nrmLo29Ni1qbJqbi81bVMV/viLX wySu1aWVcwb34u9r+NK35qs5Wj/5lI2iy6vyuetbehfcaLZ0/5E2iKPrUER1H/Fujuqnae3Sl+nj cKVWvXi1Is5SmneEYqpS/Kf1BPt9z6u5RsUOTyVFRyzovY+8xW4hkA4CyVCONQ+4L2W3vlZl7Fts 0LtY1RSHa0pOjbuHaB6sjO1fd7G9m1qp17B/mH7/kcgU3xrX+l9Uivn7ty9d+Je+KXXpONOxawWi WmHfOjEV1JP1YXi3JrlcqIhTIeduiqlnvh/Z4Np5dvUTFTaP3UEAAhkhMN+uXCdT/3WNd8rX47D6 siiI3qA6jCN1S5nkTmH4iuHSQutuOo6m7kxX+vjzSgtfsqihyYnrXUo3qxEM274kgKhWiK6a3E/S SjFzJKbvVbPsC1XJl1Nv0N2LTBHTCnmD3UBg7BCYYx96UqvnNEgUvx7E4aUmjP9e8eiLVTE82fXy jlxaeFC3plIrRK2H4SJXa0/TJPYbIuv9RPv4fHeX+R3tD/fd9YGo7iXbtXV1uS3rDj6uuiP4RzW5 f7eyvJNGIqauAEljJj162nxKRQlEpnvpB94OgbFOQFHmX5UW/oLSwt/Kh/Glqha+RO0QZyobdqDr cDhcM4lkDdikoMmtYWX/LgqDhVV58617O+v/46muIx+5dNpNxbHObbTPD1HdC+KuCCn/cPQ6PSte EVvvBJW47zIyTcR0WwGSdWL6DdK8e+EE3gqBcUZAaeHNilyvUXbsOr/LLvbC8M3SzZMVlWo6TpW7 vwyKXPsVNHm5iSp+en8hH140I//E1c3RKT+Y7z30l3GGcJ+eLqK6B3glphMLNf7JVYXgg3Hs/W1O auq6opR6eg7dXCXvQDGNv+/ZnmvVJPvJPTg8b4EABCBgNB+1U1mu/6pbuuS/v72k6XW6B10WxcEc L1d1iOsVPqSgqTzP1Y235pLx1ujL+bj6jWp9+MVeY+6jr3BlLipEdTc4NixZYhddtfwovzp+ZxgF 75JQuqbXpTENxHQ3SPJSCECgUgRal2k6jm9+qPvTjxYtbTpXw0ofVmeIl0lcDyg97A9cfm7geKtf L/GdW+VZt1j6VzW/1Y23bqmUbeNxP4jqCL2ucYyp5y65c5G1VR/Sg95Lk/USdzA9pjQhW0W/UdgT hr1KrRCZjhAzL4MABPaQQLkV4s9vqzm/+eDutstyYc+7tELOi5USrh6u/eG28VZFB7qnXRKF0avz Gm9tiRZcZ6Z2P0bbwz1zBKK6C24atyj4XWaWpoleqQlgb1Q5e9IAe7jFh91SMckMGtWw62nxL0qz 3KQx068yZrpnFyfvggAEdp/Aa3vu6NSt6KtrvbN/sDXuuNIG8Zv0oP8iRa7DVApvH29V//Ha2MZX elF4kdnofak5d8r/zLcPPbX7FozvdyCqO/H/mqj+iHyXlmyKwv+ryPNwJ5rJ3LBhGt73W8v0ef3+ /siaT8/zfvnL8X15cfYQgMD+IjDb3u0ayPyLIs8f2Si4Ug2FX2lz/jRnj1vdasCWjLe6e5tbtMM7 OoriL1eFhQtXeWd8vrfbW0FKeOReRFSHYaXodEqhK1qggPNjuvw08O+XU71DC5GSNQ/d78MwUBek R3RlXvPMRPOd17oiAjYIQAAC+5nAPG/FyrXr61ZtOWHaYhsU3y/VPElLzk1ybQ+HZNxcx6a++a2e faV0dk4+b69VgPGVOd5KCitH4EtEtR+kGzcdWHVkzfEnVEfm/Vo54jKlcv1Sz82BA/19b3Fi6zbX UlDX4o+Lnv3s/NzK/zU9IyDPSyAAAQiMEoFyz/Cb1kRn/zyKut4WRj3vVSP+o9RX2E/WZHb1If22 0vcuYMhN1A3wSgUYC9ZEZyzr7p523/wJd1DItBO/IaplOLrYDp4xpeMNSn5cpStpeqkkffjl2JJU rytUCsMteqp7UN8vOyN3/72j9PngMBCAAAT2iMAcT2sue+aLijx/EobRlXHU+1rVikwfdrw1aa/q ujJJXD3/NEW2N+Wrn79Wjfq/Mi+/4ok9MmAcvGnci6qbJnPB0qaTo7j7o571LtJgvboMKjId1PYr uRZK/TRNHARhHAePxF78zeKEadfOd4UBbBCAAAQyQkCp3Eclru/RNJqbdMP7JxsH863vH6iikWGn 4CTi6uUm2Di6wvNCF7U2dtd492qu7NaMnPKomTmuRXVtXHfgBY33nB/F9mNq8/WSUiHS8HNOEzF1 0WtQfFaKe0e1V/WZk70Vj5DqHbVrlQNBAAIVJjDPW/kLTcFZfXBX25ttseddSvfOVNRak4y3Dggs FLW6YbAksPBOVRbvpurO+Jo1Xv1X1T7xzxU2K9O7G7eiqvTHMRqS/1eNHbzdTZOJXDekYaJT17Ba qQ83btqhq+qhyDOfm+c98JNMex3jIQABCJQJaApOl6LWb67pPuUnUc2E9ylweJuCiBcpxhi6hmtS yBS5jN0EZfQ+JJ2d2+zVL9nQtv6BS6e100dYTMedqKqyd0Kh23tVZKIGNes6LVnlIVmfcPBWnnMa RtLd3ickpt/w44nXznVjEmwQgAAExhiBORMe+qtO6WMtpv7uOCwu9WzudBUy1ej/h0StydTCpN2h pwrh4PvH1c78+Jqo+ya1Xh3398dxJapr4lMOq+6K3yOVvNKtSZhEp8NU9vZ1RNITW7uG6O8IbXC1 Gjg87J7c2CAAAQiMZQLz/JX3rY3rL+qIzRVx0Ps21ZnsNGrN+f7hcRhdE5v8yzQn9guawvOHscxn V+c2bkR1TfSKl4W2t9HG9m9Lze2Hr+xNxk4VucZBcb2m1Xx5+e83Xdc4u3X4OTW7osvvIQABCGSQ wGy3Eo5V1BqUo9bcTqJW3S+V8VMrudw7vDg8xRUx1XRPa5o9QWnlcbiNeVEttRmMzsnF4WeVzjhB YwflrkgDvV1q4qA2XkHxBc3J+rmfM0vm2ft/P2/2OLwqOGUIQAACItAXtXZG8f+LomSs9W800Dq0 Qthl/cpFTHEYf3dLvu2zinavlTirsHN8bWNaVJXuPcjvMJcpnfshPUlN3dFUmdK8U1X+BsUnIxv+ 22RNk5ntBu/ZIAABCIxzAknUqiBDqV2NtfZ+RkHpaRJXP1m3tf/mipiUAdTvJ6l/8LKtsZ3ZEtcv U4Vx63hCOGZFdU284CVhHHxEgelbJJp22Kky7snKVfZGYbeKlR6IPf+j6te7kmky4+kjwLlCAAIj IaCx0l9ota6LqqJIw2jRxbmq/BQnrAO7MbmlMJN0sNFQ2yUKaV+subD/tHzpwhXJKjrjYBtzorp2 bV1uy8yDz8zFwefVzOE0PWEN22bQFSO58dMwKD4T2+i/ijl79Xy7YvM48DmnCAEIQGCPCMy3K59u aFzy7vOWNv1a985/VsHnDBPbHaeDPe9UG4XfvWBJ0xXNE+tvU7OI7j06cIbeNKZENRk/nWXeYMPg S+oOclBS9q0B0sGbS/cmi4sXe9bp9w0/++Srf9jY2DgunqIydG1iKgQgkEICijiV4zVfVzp4dRT2 fs4z/plqGFEVaerNkHSwxl/VQn26ij+vy3fFn1hjT7lujn1oYwpPq2ImjRlRdSvLaPz0XTlVrElQ J5Xmng7SyXKbQaUsuvWruyIvvGqev/p3cxsbKwaUHUEAAhAYDwSUDn6wOapfXGXCpZpS86acn5/m hHVwJyaXIlYgM0kDrp+OTGFms6lfqoj3f8cqozEhqmvi+sPyneaDKgG/3OT83JABdHmvX7p3o7IV 1xe9WOne1aR7x+qVzXlBAAL7nMB8b+Um9U+//NwlTWuqir1LbVX+GFV8Kh08aNWb0jir8sTmH/JR eFyLrf+ACph+tc8N3A8HyLyoNvfWn5D3zSfF7iKX1h2y+K4T1CTda0xY7GlVMfhnljee+9/jZdB8 P1xTHBICEBhHBJJ7qW++09Jb/5gp9n5ei5yf4YpDBy+ZmQitalnU9rVe46zfWhWdeeVPZ226u7FV t+UxtGVaVCWop+dz9kuaDlNf6lM5tEeD69ubNLCM47t7c1UfUTHSQ/OWPTCGXMipQAACENj/BObl V65U1vBNYRBdbX37Ws+vqokCN+2m3zCcm+OqVGHO82drnPWbi9bV/suNbQfeOpb6BmdSVBvq6rzz Hp5yblXO/pueil6i7rxOOAddVZou4yfLtG2NTPi9SZ734dPtik37/9LDAghAAAJjk4BWrHmyuVj3 9rx34EfVLOIffb/64NI4a//7s5t2o3FWP3eUDcOvHzd15pS1nW03zp7QOiZ6A2ROVN36p4uWNr1e Dztf0+IyB+2oICmn7khh0PucItgvx1Ojq2e3PzD8mm5j89rmrCAAAQjsFwLzJ7R2NDQs+eiipfes D4OeRlUGzzDJImCDxllVTKppjdNMEPxbR772oLWd9V+fPWHl8/vF6AoeNFOi2nLg6flFS++80Mbe V+UMCepQndxekNS7QbNpPrZ82cL/bmwcH5OOK3hdsCsIQAACe0ygfM+9YY1d8Meg2PtFNWA6w1rV vAwaonM1MJqtMVER0Ce25s205vjsz823d2e6tWFmRNUJqrfRf7s69F5t/NzkYQuSkkFwLeVW7Hk4 Mvaf1bfyznmNK/f4wuCNEIAABCCw5wTmeCtaWuzpb4pD8zWJ6rmqccm5Epf+WyKs6iKhnPA/5aOu Q9d4p3xEc1kzu/B5JkTVrYGa32jeJkH99A4F1VX+anBVa/81q3L7/SrXfnjPLwXeCQEIQAAClSCg ZTOfWJurf8vWKP6CGvNcosi02q0E1r+AyUWwScVwHL0ligsT1Q7x/2m6zp8qcfzR3kfqRXVtdf0k v8u7Qo0kP6bWHFXDRqhuubYo6JWk3hbnwn+ZKyeONkiOBwEIQAACwxNQU/5NzT3178vn400mCN/h VVVN1gImQ4XVpYhNdFFef6uxRCaFNdWi6gS1o8NcqSnDV9kdCKrr36ux1V7Ngbqu6HtX0dCBjzUE IACB9BGYP2Flx9q6ug92rJu2MS72XqGG/AeHrrWhm71R3pRqTBr16CcXVcXGtsSnX+ki3fSdzY4t Sq2orq1+swT18X/ShKaPCvIwEaqmzLg0fBh0hHH8rXCS92E1a96aJfjYCgEIQGA8EZjd2qqSX/Pp luiMZ+Jiz9JcVfURSc/gAcKqihgJq7KTF2rh82qlgv9ZqeDMLB+XSlFNxlA7Hr8yEVSzA0H1kykz W8X+C7Y2/MT89tVMmRlPn07OFQIQyCyBef4D17cE9X9VUennvap8XTKTYxhhVXHTeerUP0mp4PdK WNdl4YRTJ6otm06v1ip979Ko9VWJoA6qFEtWl1eXJM1/2qzCpWse27z+k5fadgQ1C1cbNkIAAhAo E9DsjJ+qteFWW+z9moR11rDCqrBWi54vkLD+u1bFeaea+D+SdoCpElUnqN4U7+0K/ZepHdLwgurG UIPeZ1WU1Pi2E9v/o7W1fUz1jUz7BYN9EIAABCpFQK0NV0hY35vbhbBKE15h4uJnmuNT3j/fPvRU pY6/L/aTGlGtU+vBVQ/7b1MgerVWmpk0pMo3WbZNKd9iz3OKUD+6/OPnXDePpg774ppgnxCAAARG jcCIhFX9B0zsva4qzLet9eo/OFur44yagbt5oFSIqms9eO6SO9/gW/PxYQVVvQaVAnBNHZ6LTbxU Eer1cxHU3XQ1L4cABCCQTgK7FFatcOPmsZoofquauW9u7j5/2fwJd2xJ49mkQlQvWHrnBUL271at B4fOQ+1rjF9Unje39LITNynlO7aWCkrjhYFNEIAABEaTwEBhrdYY66Cq4FKDCBeyfsDPb9qkgtZ/ 04yP7tG0cSTH2u+i2hLVz81F5suahypBHbp0W2naTPGFyDOfM7W930BQR+JWXgMBCEAgewS2CWtv 99e8fGEHwupXqXzpKr/De2HtiXXXJtN0UrTtV1FtjheckI/Dr2rqzDGlFQz6rbun75Iq3zDYqkHq L5ratZ+d106Vb4quHUyBAAQgUHECJWFd8N5c0Pttz88fMzRiLTXht0Hx4x3rap9TgfAtFTdiL3a4 30RV844OrzLB5xTPn5bMT+o3R8mdjxNUrbnXrXmoX311be8n2xHUvXAzb4UABCCQHQLz8itWtMRn XukFmm7jVx0+ZLpNadm4qXEYfa7F1D+jXu8r0nJ2+0VUmzvPP6C6uu1jktLzXOMMtRgcwCNZaSYK Qq0Rf11QaJegtjIPNS1XDHZAAAIQGAUCyxte9ePzlt5zqHoEf0ozP6YmEeu2TSWrym7anHdULgq/ pDmsb0rLHNZRF1Ut4Vbt9256b2y8d7hB58Hr6zlB1WozKvIyP3hu4tQPv7anhdaDo3ABcwgIQAAC aSLQuGxZvHZW3X92rK+tjYLgI4pMJyvY6qerbrhQ4mrtKZ4Jl6md4eXz7cr9vhbrqIuqt9n/ey1E 8FE1d/CHdktS2KrpMwpTmwLfXPHannSWTKfpwsMWCEAAAmOVgCtCaqk9/fNmc+4ABVtXaGploX8g lkSrybKf4eJ8aDasnXR+w+yeO7r2J49RFVVV+r7cRtEnNPg8KRpc6Zu0H8yZoNjzkMlFV2q1mVR3 zdifTuPYEIAABMYLgXnq695cU/epfOeBh0g8317KZm4fMiyvxaqILHxPR0fbIw0fb7iusbFxYNXr KMIaNVFdE9W/yITRZxXCTy89afQ756RbkgqTisU/mFz+CuXGWWB8FC8CDgUBCEAgzQTm97RubbZn fywfdR0htTg3VkJTyrp9hNXNYVUnPjWF//Sij921wZiVd+6v8xkVUW0+7PwJ+ac2X6VI9AyX3XVj pv23pFtSUHxGDx8fnuevSE0V1/5yCseFAAQgAIGBBOZ7dz+9xi64Mgx7v5/z1RzC6Uj/lW1KzSEO UuHSp++NFjxx1n5qvr/PRbWhocGe13Dmm2xsL1M4qsKkgYW8avrgmjt0au28T1120rk/bm1dybUE AQhAAAIQGEJgjl2xTlNoPqgg7HpNtTl0QEVwIrAqXDL2ZRNM8WNrD6t/z+y/jv4a2/tcVM/92M/P Vv57mSbrqs/DoMYXLjee/Cz+3mNTI7UfXMaKM3yQIAABCEBghwQuO3Hh8m+vv+ezWq1smVK+E4cW LqmLfBxf3PW09wtlRv9ztFHuU1HV3KFjfRt8WiH58OOoSvuGUXh/0fOWXNr+QO9onzzHgwAEIACB bBFwwddjmw+85tgpdceo5d77NFfVDixcUsclVcMqTbysJVf/+3l25f2jeYb7TFTV7HhCvrP3w2ox eEpSlDRcx6Sg+JecV/XBM+wKKn1H0+scCwIQgECGCVw6rb3YHNulmkZzvKZhnisVHVC4pBSo68p3 uOa1frLZ1l8y31v59Gid7j4T1XyHeZ1O9M16YvCSFlP9tmQcNSh2RCb65FtnPreqtXW0TpfjQAAC EIDAWCCgRg+bmnMLPlwdFY+zuaoZalm47bRiBXFu6o2NvTOroujKlqmnf1RTc0YlG7pPRLU5WnBc XgPFEtTqKJk+02/rG0e10U2PT4uuY9WZsXB5cw4QgAAERp9A08znfnPeummfjYPgC1rRbOD4anmp OBuad4UbvWbjm9tGw8KKi2pzZ/3E6urivxrPKiwflPZ181EVpkdx0NybYxx1NBzMMSAAAQiMVQKN Wlv7xlWnf+vY07xT49iq9e2gxhBJf+DcZBuGn1CvhAfneCv/sq9ZVFxUCwXvdVEcvUX57KFpXzcf NQr/6uXyH5rPOOq+9i37hwAEIDDmCVw6b3Vvc3x2gx9uPdn3q+fEtl8w52p51BvBs2ZWGMZXKA38 r65D076EUlFRbY5f8WLlt6/Sk0F+cNo36c8YBkHkeddEtd1rTPu+PC32DQEIQAAC44XAfHv306vM GR9R/c4N0ppDYxUq9W1uyo0L8qzpfUe8ufBjrb/avC+5VExUk2rfjt4PDp/21YCxUr9aTuDeoCv6 qvr67tMnhX0JjH1DAAIQgED6CEw88fl7O9ZN+7KCt49r/mpuyPxVmzvAi4IlzaZO1cCtm/bVGVRM VPNdZqFU841akn3Y5dxKad9cw/wJK17YVyfDfiEAAQhAYHwScCvaNNec/9V8x6bXKIqb33+aTd9q NsaGr/TNlH8QoS/tK0oVEdW1Ud200rI8/uT+TY6d0aR995Xr2C8EIAABCPQnMF/LhSoNvEyN9W+S 9kzr3x6htJqN79uw+E9qdbh8nrdyn0zmrIiodkRTLvU8W6+ngwFL8mh4WKpqNVeItC+XPgQgAAEI 7HsCr64/9747W5q+o6byV5TXWt1+UFcNbL3pNo4/3Fxd9163+k2lLdprUW3urT8u79kPqFn+kN6+ SXlzqBlCpH0r7Tf2BwEIQAACwxBoX70ssLb+C1rE5tWetTPVBkKvKq2MVk4DW0WyF+a7av9HcV/F 567ulai2HHi6n99k3y9Tjyqlfbcv6WatW409qUf67xm1039FtS/XPwQgAAEIjAaB25cufOrcpU2f 9IPgG5qNMqApRNIy1/MmqWHC/1ULw/vVmWlzJW3aK1E1m/25Us63aQkeLWE3qBVhKRX8qJfr/eK0 9puKlTSafUEAAhCAAAR2RKBx2bL4xqmX/M+MjRv+Lhebi/s3hdhetBS9wg/tYnVauraSJPdYVG/r rJ98aLX5sBT/gP4rBDjjXB5bIltU7PpvE9d1PW1mV9Jk9gUBCEAAAhDYOYFL22/qbfFO/4SKaF/h 1l6NTf/ewBpb9bwqdVp6X3N09m1uAfRK8dxjUT20YM6SjWdrvNQJaD97XP46WSp2ddD7/I2zZ7cO av5bKdPZDwQgAAEIQGDHBB5ve+T3x9XO/Jb6Dn1IWqUl4spylHRa0mirNXV+1POPdbPqPlmpPvR7 JKrN1edPzne1vU8NHQpDo1TXezF8wXrxp+dPaH0eh0MAAhCAAAT2BwG3RNyayHxVrQvfIL06bnvV j1spzkWryRSbd31jXe335nvmsUrYuEeiKkE9S3VJCzx/UJTqqn2TJ4Do9qgtajLTKmEi+4AABCAA AQjsGYGaWQv/umXdPdfaIPiUotWq/p2WjNKtEtvDqqL4HWtn1X3ENZDYs6Nsf9dui2pflKpS5SFR qn6mhdiD52IvunretNU9e2sc74cABCAAAQjsDYHZrcvCNbb+24GNFhuTOz3psN83xSaJVnNqaRj8 fdu62v/UFJtH9+ZY7r27LaouSpW4L7CDotSkOCnJV9vvm6nm90yh2VvX8H4IQAACEKgEgdtntm1e tH7aNVEYflMaqoBwYECqFkWH58P4bXWzllzV2rpse0XTHhx8t0R1bXX9FNMZv18dKYaOpUr8JfrP xl7wzdFaYX0Pzpe3QAACEIDAOCPg1l1tPvz826r+tPl9OvUzBkSrSZelXC6y4UXfWX/7V+ZY89e9 wbNbotrRHc3TQrDzB4+lbo9SDVHq3niD90IAAhCAwD4h0FT7+NZFT9f+u6LVkwdEq0kziOSQM4Iw /4aGjy/598bGZf1rmnbLnhGL6qZNl1TFtRvepEXp8kMqfvuiVBv8J1HqbvHnxRCAAAQgMAoEBkSr sZmbNKbv177Qy3kqYorfunhp0w0yp31PTRqxqP6u9qljJkTxBdav8vrPSy01ekjy00Spe+oF3gcB CEAAAvucQDla/boqak+xvq9+9eUeC4pWEy0z0awtJnplQ0PDjxsbG/coWh2RqK6tq8vVrA3fLGE/ IJky029zi49rVPfZmCh1n18QHAACEIAABPacgItW12rZt04TP6lGui8ePG81mdUS2vcs/MzNTWYP V7AZkai2rZ8+JR93v1Zjub7rm9i3JYIqpY9t+FPTZv7AvNQ9dzbvhAAEIACBUSAwc+GmeH3TN+Mg +LTN+ZpOU6oEdtqmNcGlZ9HpflftCQ2NSx7ck7HVEYlqPu46K7bmJW4eqnLO28/auu5JQafaPd3E vNRRuBg4BAQgAAEI7BWBZN5qXP9dKdk7NKg6MFpNxli9SepneMmiLy//jUZWB64UM4Ij71JUmzvr JlYVzFut8aoHz+1xDX71Z31g/VUjOBYvgQAEIAABCOx3AsHU4Jnc5qrvqR7oo8rADohW1Wjf17Jw 5+fagqvVJ+K53TV2l6Lq+7V1XhSfaX3PDi5Q0iBvFFv7X37t+q17Xiu1uybzeghAAAIQgMCeE9As laDFLLjNM8HlGsY8cFv+NZlekywKc7QxE85saFhy6+6mgHcqqm4Rcm+jeb2Ec1KysGu/rVyM/GyQ M7fNb2/f7RB5z3HwTghAAAIQgMDeEZjcPXn91nzbg1EYvco1AN6mcRpj1Xd5VQIvVgr4pwoYd6vl 7k5FNejaMjFva8924fDAAiWNpSpKVQ3ybf7m4jMUKO2dc3k3BCAAAQiMLoHFp57ac/26pu+rMGiB Z9VoP+4rWEqm13jSuFcFzxaOMPndW71mp6KqCqhZOs2ZakvoCpK2n7Gr+o1Md+wVf0SB0uheCBwN AhCAAAT2noDr8evbs5eHcddzClSnD56Uqn7AU32v90JlbL/k0sUjPeIORdWlfu3G+HxV/VYPnpua dKGw9okt3f4aM2Gkh+J1EIAABCAAgfQQCDZvedZMsXcqZvw/VtNbtmmd6wfs2SovNq/pfcr/mnRu 70U1eOrgmqr85ld4WsVVYeo2CqWoNQo9Y3/23PQiBUrpuT6wBAIQgAAEdoOAy7T+MjjjB2r9+0Zj czUmLmmnE1cvJ+kLopP8QnCYfvTHke52h5FqoWbrcWFkTyq1IRyY+pXGdqtC6o5L21f3jvRAvA4C EIAABCCQNgJRzltpwugpVSodO6DDUqk4d6JnvFc21C3538YRLgk3rKiWqn6L5yXN8wdV/ZYaEMdP Pt8d/ZbUb9ouD+yBAAQgAIHdIeDXBh12k3+PCpOOSQqU+jKzpek1VfrrlYuefsQ12R9RFfCwoho8 5VdXVcWLVPWbHy71qwP99LnpAanf3fEcr4UABCAAgdQR+Nnli3rPX9p0l8TzLSpYKpQXrklSwKUq 4Ghe0LZhihpBPDsS44cV1ULBHKTq3hOGTf3GpkvdlX5K6nckeHkNBCAAAQikmcCyZctiz579QBR3 t0tUD9ueApaouumrNj5cQvkyNYK4cySNIIaIasOSJfa8pU2nSZUnDMn8uq6EcfznoqfULxsEIAAB CEBgDBB4uvDUxsM6Dlytvg9/278RRHn4M2+j+KzjL19+30hSwENE9fivPFIVm+gMhcL5ZFG38uaq flWxFHmxbTEF0zmy7PIYoM0pQAACEIDAmCYwY8bi3o6Hm36heqFF0rpttUSl8VXrq8F+/ZHTfV+6 t8tx1SGieuRTG6ps3szVHB3VE/dfkcZ1cbLFyJpVtQ+2Fc3sMc2Yk4MABCAAgXFCwK1c0xLVr7C5 uFvTSPMKLEtnnoyrqr9+GB1X6DY1yuB27ArJEFH1/eBgY3J1g8dTk7VTY9Pr5/wHZs9uLfVzYoMA BCAAAQiMAQLBZLM2v9VsiL14QMjo+tzr6wCd4qzmzvqHJK01hdjUdFtT48dmom/8fLcN/jDfrtzs MAwQVTeeuqjxntMky0PGU11uWX/+0l2Y/PiuA+AxQJhTgAAEIACBcUOgVnq4xYtbvSicpSByW3cl NTtSgGqrtCTbWwuFeFEc2cMjG79IP5huY++oyIa++i29Sj2CVw4R1eOXP1Jl42CuekkMM54aRDlj VwZGqV82CEAAAhCAQAYJNFfXF5TKPbTbuIjTrw5M9yTP5mtNV/RixaQvSnK+LjYtb+V5q3llb9+q n+uPfu3SwuWXxEFxpZlsf9cXbPqu0cPyDywKXanwpatv6n0gOuMEvXi48VTXPallfs9K2cIGAQhA AAIQyB4BCeq0KI4+lY/tKVFcnOZX1RyctN91/X7DMPl3aNMj6aj73bbTlajmcu5ngbHx9/2asHub qHqb/bef13CPaYkWPGxMUGNjc7SKlFyqdzstKbJkOwg9/9G6ujqvtbV1e1lw9phiMQQgAAEIjFMC QW2w0W7MbfZyOQWQ3sA2vEPnkfajNGhN8SRmjduqc96dJ7c/sK2Xr8qazBf8Qs3EZGm3WH1+TTFR 6gGbcsrancqKw9d8e13tzMjUP6Jvu5zO6muLMYWeyeufe4ICpnF6lXLaEIAABDJCQMu49azJnf+J INw41/er5yRm71RMhzkxV7gbhtJU+8uDC+aJ/nVGvsS2NwqLE/VVeucwOy+LbCGXy31I9cVGY6tJ yjnSOuVxnHs0ioMbthw++Wq9m6rgjFxYmAkBCEBgvBKYY+94ZpVX36jFYr6jKTNT4/LqNCPlUUoX u6DS/rhNU0xf1K9e2FX/ujZJI1JqKbP2UdJNN4qrxdLd0jiTjRfcymLlI3UHr4MABCAAgf1NIJq6 /ufeppn/pSztFepz75Y0HbFJrkZJqvlcb6+5Z+6gKaY7XPpt+L078S3/xi0JF/QGmij7pWiqWW/a R2wPL4QABCAAAQjsVwLz2tuDZmuuroqietXmzlXB0YiCy6RnQxCqF5K507Spyf6Egaexm6JafnN5 NqyUfaXJ1XxzXvv9I14Vfb9S5OAQgAAEIACBMoH53spnVgVnfFzLvt2gKTMHxvEIRjBtTmnaoEdD n7e+c+Gm3tbWwaIaa4h0N7dyxdSm2HqfnOPd3babb+flEIAABCAAgVQQiA6Jfm42mu/mYvvekaSB k5rfOPpLkDMrhpsJ4wqVVMUbTxnp2bmDGpd7tvH3zLTwHtK+IyXH6yAAAQhAIG0EVA0cNHunfCYX Vb/c+vmTtNTbDtPASYGSGgHHnvcTv/ZIrSmeNFEasLnu+/erAOn1/Ze72eFJJz0m3Aht+PuctV+e I2PSBgh7IAABCEAAArtDYL730J9aojOWemHxWztNA7v1VSPboeYQP57XfpNriDRUVKW4NyiWvUBl xQXllXdqh3W55DDsUi+JL/yfWW2PD84l785J8FoIQAACEIBAaggcFN0e7TIN7Kamxo8GnvnNjuz2 e635RT6KnlT34JcM7Bcx6C1uPVVtEtSf9/bG36OrUmouBQyBAAQgAIG9JLCrNLBbuU2p31BZ3ds3 1B7RMVzq15ng+3ODreaB/I16bYN6Geb0pmFNK092/auX8z81f8KKXa4pt5fnx9shAAEIQAACo0rA pYFXBfUNcVj89pA0cNKu127pNbnbLm2/aYcLy/jzVmuQ1tb/UMvSXK75NwcNF60mCh0GKva136yZ +cqHTOuKUT1RDgYBCEAAAhAYDQLRg8Ed5nR7o6qB3+epMDdKmkKolsi1643jdaYn+P3guan97SrN Uy2YP8Yd5gEVNZ0/pGApWd5Gg7Nx9KBnvH93K6SPxolxDAhAAAIQgMBoE5g3b3WwJj7lM1HgvdxW 5U92TSHKVb+BJqD+0J8e9Oxs1ksiqu+csbD32+uaviclPsfm/Or+BUulnQUvxNbXnNT7nxntE+R4 EIAABCAAgdEkMMc+9OdVcf1S9cRP0sCui5KyuO1e7N8xt13Liu9kS0S1tXVZ5Nmz74pt55MKSY/v e30yJ9VtNv7ha6b13t7ePpqnxbEgAAEIQAAC+4dAXxrYN7n3ufVV9bWmpmfyhp2lfp2l29oUPrL5 4Pbjav/0A61n80FNncm5dk3lzkkbpLifbWdO6v7xLEeFAAQgAIFRJ9CXBg5D75WeZ2flPPsj8/ip vWb2HTu1ZZuoXjrtpuKaeMGtURS823i21s1JDYOgqNbBX7is4dw/tC4b2jli1M+SA0IAAhCAAARG iUCSBvZUDRybJaHn3zV79q5rigY01O8uBL/zO8xq1fq+2kWpWoC8uXeid13rsmUjXxNnlE6Ww0AA AhCAAAT2NYFoavBj71k/OH7a9KdH0pZ3gKi6gqXr199zgwqTFmpdmxdizy6b37OSOan72mvsHwIQ gAAEUknANYUwefPjHTV7GGz0AFF1BUuBqV9RHZvHYxvdPnnWufebVtK+qfQ0RkEAAhCAQOoIDFlP tbZQ+9yWrrZrAmt/OJc5qalzGAZBAAIQgEB6CQwR1dk9d3QZz1yTXpOxDAIQgAAEIJBOAkNENZ1m YhUEIAABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4 CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgK MyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAoz IQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMh AAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEA AQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQAB CEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEI QCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhA IP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg /QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9 BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0E ENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ 1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV 9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0 +wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7 CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsI CyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgL IQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAsh AAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEA AQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQAB CEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEI QCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhA ICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAg IwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAj BBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICME ENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ 1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDV jDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWM OAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4 CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgK MyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAoz IQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMh AAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEA AQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQAB CEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEI QCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhA IP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg /QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9 BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0E ENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ 1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV 9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0 +wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7 CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsI CyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgL IQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAsh AAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEA AQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQAB CEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEI QCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhA ICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAg IwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAj BBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICME ENWMOAozIQABCEAg/QQQ1fT7CAshAAEIQCAjBBDVjDgKMyEAAQhAIP0EENX0+wgLIQABCEAgIwQQ 1Yw4CjMhAAEIQCD9BBDV9PsICyEAAQhAICMEENWMOAozIQABCEAg/QT+P0G1dZJNU3EDAAAAAElF TkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=352; creation-date="Wed, 10 Oct 2012 09:43:11 GMT"; modification-date="Wed, 10 Oct 2012 09:43:11 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA0EAAAAICAYAAAA/QvTgAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAD1SURBVHhe7dyxDcJADAXQjMIodMCxBHsACdtk BAQuGA1kJkh1xfkVrk/5elL0XXhq1zi2+f0xMmCAAQYY6Gsg1tM9HkYGDDDAAAM9DZyX2E/t9rq0 Ob5GBgwwwAADDDDAAAMMMDC6gSxcSpACqAAzwAADDDDAAAMMMFDGgBIEexnso280fJ+tHQMMMMAA AwwwsM2AEqQEKUEMMMAAAwwwwAADDJQyoAQBXwq87ci27Yic5MQAAwwwwAADIxtQgpQgJYgBBhhg gAEGGGCAgVIG/iXosDx3eSbOyIABBhhgoKeBvE7a8ySqt5zgZYABBhhIA/mv+wEQywLHpKRieAAA AABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: attachment; filename="image006.png"; size=7144; creation-date="Wed, 10 Oct 2012 09:43:12 GMT"; modification-date="Wed, 10 Oct 2012 09:43:12 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAcoAAAEHCAYAAAAu6ga2AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAABt9SURBVHhe7d0hcBxH1gDggwcDAw8GBoad2Uly qmIYGGgYmKpotWaGgoKGgoK2doGgoWGgoaFhYK7f7MqWbe1Mz+7MzvTMd1Wq+//z7Ez31yP1dvfr 1//6l/8QIECAAAECBAgQ6EPgbHn749Pl+snDn5Pz219PF+sXX/xcrF6eXazuuvtZ33zzjO0zz85v f3tYnj7q7Z4ECBAgMCOB/y7v/n3fsZwt1n9EB3R2sb7+olNbrN+m/+2f0n9OF6sPD+t1mjrwTYe7 en5vMKOmV1UCBAgQqOsEUwfxV+kdX6/lX6zf33eqn0av52+enSxXP3mzCBAgQKAQgfupz69HgjrB I4x+P3Wk68vwjxHp/5av/1PIq6OYBAgQmJbAL8u77+IPcdUhXqxfpf+exFRoryPCIaeKN+1TraPe r5nG6H5ab6XaECBAYCCBmNq7D4iJqb/NutoRRkie0fsabGrLj5vp3PVV1Yn+uT6JWYGBXjWPJUCA wLgFzpZ338co8T54Jv33Ox3ijL8QbEahl/ElyRTuuH93lY4AgR4E4g9fTMFFlOV2lJhGFoV3Cg+C XT5Hkj6+bePrLSSH/v+PbkG53x7yTcTu6u8SrbczCTcni9XvAoh6+KV0SwIEhhX43DFW64kpenLc neJmNPt5SvDhdolqbTSNfocV7ebpD6OAo17RCW1H9JefOvvFmDvWNBUfW1pS9O1U2qSblnUXAgRG LzDmjnETARt/YNevolOIzsGeweZXKtq0+pKQ1hHvt4dsZgNGtK1m8yXs2qizuT1dQYDAkQXi23xM /0VQxuAjxs3a1nU1MtpuU4g/8KIs+30pIgjnUycakcgxIh/FaPTzqDOipftVcHcCBAhsBR52jION KNLoIU27va5GN2nq7eflmx800PgE7rfyxPT1Zlp34FFofJFKX6C8L+N7V5SIQNECg3aM1aikWi+8 vJ8mNTos+nX6VPjBR6GbqdqrGAlPQ1QtCBA4qkB0jjEK2HZSve+piwCf7eh0szE9/fGyLeCoTT6a h8VoL6Kit/srj7NNaDNNfFM9dyLBWqNpUAUhMCWB6JiO1jlWU6dpLSv9YRLuP6W3qPu6xPTt/frn sdY+q8jnNEUrAUL37emOBIoTiM5xuy2g32/uDzpGI8XiXpPRFTg6sGrdcxO93GtC++0ezqtYCzft P7pXQYEI9CNQTW1tjpDqr3PUMfbTeO76qMDRRp3bKdropH3h8zISmJhAdI7b/W/9fPvWMU7sjSm/ Ol+OOnvKERxRtGn5wEiz/PdFDWYqUEUVpmjRXqamdIwzfavKrXbVcW4Op+5+JiWNNGMa2Hp7ue+H ks9IICL2qiCErlPFbaacruPbsymnGb1QE63q56juFOnadWKE+N2rAoGmkepwoq+Aas1RoDqiqEqA 3V0e1TgGqfqWnLLumFqa41s1jzrHu13li+0hs1QkxYjfn3lIqiWBEQr0MXqMCL8qkjD94RhhlRWJ QO8C1ZJFx8Fum7M311cyAvXefB5AYCPQ+ehxm6EkcqIyJkDgs0D1ZXST/KCzKdqIGYioWblnvWkE OhaIX6rY79jZ2uOmc7y0obrjhnK7SQtsv6RebfdWdpGx6loKvUm/Mip3DIGIoqsy2HQQcLD5Jrt+ YfrnGC3nGVMX2J6Y00lcQLXkkX43jTKn/taoX2cC8cuyPW3h4D2P0TnGSFSkamfN40YEvhC4jxXo ZBvW5gtxmukRMes1I/CowGafVwejR3u6vGEEBhHodAYo/S3wBXeQZvTQMQpsEwPcHLy1I607xujR 9M0YW1mZ5iQQW06qIKDNQeKHrmVeiyWY09ujrl9N2VSZcw7vIGP/pDP1vF0ERilQpY+sMgIdlkYv 9mSKTB9lEytUHwJdjCCrXzrZP/poHvck0JtANwFAqzv7nHtrIjceWqCTDlKmj6Gb0fMJHCzQRQBQ 5KyV9efgpnCDsQgc2kFusuWsXlrYH0uLKgeB7gQ26fNWd3uvZcaeaCeYdNcg7nRcgUM7yCoQwC/A cRvN0wgMJBDrj4fELMQX6gjmk5d5oAb02HYCB3eQEeCTtoq0e6qrCRCYgsD278feiQzuO8wpWKjD BAV0kBNsVFUiMJBALLUctK86zox1uMFAreex3whE+PchUybVZ40gvVkECDwiUAX+RLaefdNYpiUc 20q8WoMJVOfYpfyMe7/AOsjB2s6DCZQmsEltuX6xPbJrnyQGN/I8l9bqhZe3OkVgcwJH6xc2plO8 sIW/AIpPYCCB+IIeQTsHJDC4kkt2oMaby2O30yB7ZdOJDtIWj7m8KepJoF+BB2nyWn9hj1FpHLzQ bwndfZYCVSacPdYJdJCzfF1UmsDRBLZ5ZVt3mLEFLRK5H62gHjRdgVgI3+cIHR3kdN8JNSMwNoEH U7If91gSunSYwthatJDyxDRrFZ7dfh3y2hRrIY2smAQmJhAd3j5RstX+y/PbXyfGoTp9CmwXy1t9 M4tRpzDsPlvFvQkQyBWIL+upw9wjccHqTrBhrvJMr4v5+tZnyMW6ZVq/nCmZahMgMGKBTSKUlrlk /U0bcYsOWLTtdMXVHtOsKVnA3fcDFt2jCRAg0CgQ06qtt5SkYB+jy0baeVwQEWNtX6AquMdhyfN4 QdSSwEQEPq1ftom7MLqcSOvvWY0q00XbYJ300kR2DBn690T3MQIEBheopmPjdKJWHabR5eANd+wC xGiw9SgyHZosmvXYLeV5BAj0JRBJB1qlxDO67KspxnXfKj9rOgS5zTep6uBkWfjH1ZBKQ4BAJwL7 zKylv6GvxWZ0wj++m0REa6vEATHNmjpV06zja0slIkCgW4G2s2zVjJw4jW4bYei7Venn2szHp3Bq 0V5Dt5rnEyBwTIE9R5cGE8dspD6etYnyyt9DVM3XpyjYPsringQIEChBoP3ocv3OwKKEln2kjNvk AfmJgu0ZKrSlFZsAga4FWo8uI9DHIKPrZuj3fhHN1eqkD5l1+m0QdydAoEiBtqPLSJsnrmPkTV2d 0dYiv2EE9zhmZuSNqngECAwqsDmHN38Jq9qjKWPZoG228+ExR546vnctgnaufPMZZ1sqFQEC4xNo ExRZnUbirMtxNeJ2eiDrtI/qdG/7IsfVgEpDgEARApttdmlrSM4ugiqT2ep5ERWbeiGr9cicRkvX xIhTdp2pvxHqR4BAnwLbnLE3uX9303VXfZbHvRsEqgNKMzvJaCxTrV4pAgQIdCMQ5/bmB02u7qKD 7ebJ7pIlsA3ayftGk4b/Tu7OYnURAQIEWgm0mYqN4Ekzeq1497+42t+TGbQTDWMj7P7WPkmAAIEm gSoqNvM0kmp9M51e0nRP/36AQHR6qUFykwhcG+ofgO2jBAgQyBTYzvJd5SyFVRnQ5InNlG15WXwL yT0SJpKZt7y9ywkQIEDgQIHsZC+WxA6UfuTj8e0ja9FYGqXu8d2RAAECLQTarFtGQFCLW7t0l0Bu JxmjzafL9ROSBAgQIDCsQATttDjW8HLY0hb+9EiymzPnHeuWgnYKb2zFJ0BgUgLVfsvcIJ+L9atJ Vf5YlWnRSb4VtHOsVvEcAgQI5Au02cp3qrPMh40r05D9Rc5IMgXtvJZEoJ2tqwkQIHBsgUj4kvc3 3cgyq23yO0mgWaAuIkCAwAgEcpOqG1k2NFZu3laQI3jrFYEAAQItBaoltdid0JB61N/4HbC5a5Ix 4mzZNi4nQIAAgZEIZO9ksGb5ZYtFLtambxjx7zrJkbzpikGAAIEDBPI7S8ljKuZcsBhxHtAuPkqA AAECIxLI/ds/+wFSLpROckRvt6IQIECgIwF9QANk5G7NWtS1JtnRK+k2BAgQGJ9Abmd5ev7m2fhK 32OJNumN0nErTZFPOskeW8GtCRAgMA6BrM4yomXncupIJAjIPE9S/r9xvMNKQYAAgd4FcoI6qxOk 5nCeZRpF3jSOJIUF9/5SegABAgTGJpC1lz7OJE6HRY+t7J2VJ3WQlzrJzjjdiAABApMTyMvOtrqb ZPrSrG8KFxOt/OReZRUiQIBAfwKZuWGv+ivBAHfOWaiNs8ucAjJA43gkAQIERiiQOsvrxhnIxer5 CIvevkgxl9wU4RoLtBEJ2/7uPkGAAAECUxTYHNG1uqvtLFMk7Mly9VPx9Z9NRYtvKRUgQIDAuARi oJVOHXlf11lWA7GSg3tyFmUjJHhcTaM0BAgQIDAWgRgxNianWazfjqW8rcrxdLl+0jS/HOeTtbqp iwkQIEBgdgI5p0sVlxM2Z10y9lPOrrVVmAABAgT2EsjZXhgDtL1uPsSHmtcl1+9FuA7RMp5JgACB MgVygntivbKIvqVxXXIqUUplvmtKTYAAgWIFJjFbmXMiyMli9XuxraTgBAgQIDCoQE78SyS4GbSQ ux6emezcuuQoW0+hCBAgUI5Azszlz8s3P4yuRs0Fty45ukZTIAIECBQqkHZNvK1PRjCyLSONU67W JQt9FRWbAAEC4xTYnmv8sSEZwXimYJvOlyxuf8s43wulIkCAAIEHAqfnb541pbgbRdaeSBpQ36Ov 303yOBSvKwECBAgMLnCazi9uSG4zbGxMLJY2pRaaRMLawV8FBSBAgACBxwQ2gaQp3+vF+p9dPzHy HEwvsuvUFu5i9XKwwnkwAQIECMxCoGkKdrBEBNUZk3U9eDpf0pTrLN5RlSRAgMDgAk0Dt0iBd/RC NgXwmHI9epN4IAECBGYrsM3aUxsFGzs0jgYU2XUaFk+vjlYYDyJAgAABAkkgMvKMIrCnMdde2jM5 inBcrw0BAgQIzE6gMRFBWjbsHaXpqBO5XHtvAg8gQIAAgR0CVQKc+viZdwfjRZDOrps0Z+BZvxfA c3ATuAEBAgQIHCCQOsrrXjP2pGHr+wilPU1bOyJF0MOypgdfjXavygGoPkqAAAEC0xGI5b+6Pf7R xx00qPvm0OVIPHt++1t0mvXJBVZ302FWEwIECBAoWaDXZcKmIevOEeUxw25Lbj1lJ0CAAIHeBZq2 ixw0qmyaXn28ozSa7L3VPYAAAQIEWgk0bWXcO/i08VzJx6KJUmL0VqV3MQECBAgQ6FmgMQ9sisnZ qwixHtmwYfPRxLOpg/0rNnv+srz7bq8H+xABAgQIEOhYoGlUuVfC9Kbkso2daEo4UB17coxNnR2D uh0BAgQITEugaVQZ6Vhb1zhytDZ2hjWbOT99NnWYT5frJ60L4AMECBAgQKBDgaZRZeuBXbUNJKcj rM18sPooKXqHrexWBAgQILC3wHZUWZcwvd3hznHDgzrKtDh61Azte9P5IAECBAjMRaBpX2XrHOUp KKf+qJIdo8mY6/06m89cGkE9CRAgQGC8As3ZetYvWpU+0ti1HlWmDD4iXlsxu5gAAQIEjihQO6ps u1XkmzR2zWuWNwflzTsilEcRIECAwDwFmk4WaRXU0yaNXWwFmSe5WhMgQIBAaQKxRFgzY5of1JOb xi6y+JSGpLwECBAgMF+B2q0iaVtjdlBPVhq7lMFnvtRqToAAAQIlCjQF9WTnf61NYxeZd87fPCsR SJkJECBAgECaNb3ZPf2aecjHrjR2sW1EIgEvGQECBAiULNCUqjVrB8ejaewkEij5vVB2AgQIENgK NGbqyVla/DqNnUQC3i8CBAgQmJJAw+6O68a6fpHGTiKBRi8XECBAgEBZAnWxOLHMmJUbYJvGTiKB stpeaQkQIEAgQyDWIesy0GWdfpXS2P2R8SyXECBAgACBIgUastBdFlkphSZAgAABAl0JxIBw16hy rwOduyqY+xAgQIAAgTEI/Lx880Pd9GvWNpExVEQZCBAgQIBAXwK1p2X9uT7p67nuS4AAAQIEihCo y9Ijn3kRTaiQBAgQINCnQG2S9IvMdHZ9FtC9CRAgQIDAkAJ1Z1TGNskhy+bZBAgQIEBgcIEqwU4c r3Wx/ufRn+Xtj4MXUgEIECBAgMCQAnX7KdOo8vmQZfNsAgQIECAwuMDpxeplzTYRiQcGbyEFIECA AIFBBU7Ob3/dmXjgYvV60MJ5OAECBAgQGFqgIaDnw9Dl83wCBAgQIDCowBcnZj0S1JN1ksigNfBw AgQIECDQs0AK2vkg8rVnZLcnQIAAgXIFUkDP610dZaxhllszJSdAgAABAh0IpE7yqiag52UHj3AL AgQIECBQrkBdKrvTi/Wrcmum5AQIECBAoAOBui0iaaR53cEj3IIAAQIECJQr8HS5frI76YDk6OW2 rJITIECAQCcCdXsp05mVbzt5iJsQIECAAIFSBf63fP2fnSPKxfp9qfVSbgIECBAg0IlAXdIBx211 QuwmBAgQIFC6QE1i9H9Kr5vyEyBAgACBgwXSWuT7XZ3lwTd3AwIECBAgULqAjrL0FlR+AgQIEOhV QEfZK6+bEyBAgEDpAjrK0ltQ+QkQIECgVwEdZa+8bk6AAAECpQvoKEtvQeUnQIAAgV4FdJS98ro5 AQIECJQuoKMsvQWVnwABAgR6FZBwoFdeNydAgACBkgV+Wd59t/Pg5sXqY8l1U3YCBAgQIHCwgKTo BxO6AQECBAhMWeBkufrJeZRTbmF1I0CAAIGDBM7+XJ/snHq9WL0+6OY+TIAAAQIEShc4O7/9bXdH uX5Vev2UnwABAgQIHCRwslj9XjOifHnQzX2YAAECBAiULpA6ycuda5SL9R+l10/5CRAgQIDAQQKn aR1y54jy/M2zg27uwwQIECBAoHSB08Xqw84R5fL2x9Lrp/wECBAgQGBvgbpkA9F5/nd59++9b+6D BAgQIECgdIGzNGLcnZVn/Vfp9VN+AgQIECBwkMDJ+e2v9lAeROjDBAgQIDBlgRTI87ImIfrllOuu bgQIECBAoFEgdZI3NQnRnzfewAUECBAgQGDKAini9eOujjJywE657upGgAABAgRqBeoCec4Wq79F vHqBCBAgQGDWAmk0+bwmI8/bWeOoPAECBAgQOL1YvxLI4z0gQIAAAQI7BM4W6/dS13k9CBAgQIDA IwJny7vva0aT/0TGHnAECBAgQGC2ArWJBhYy8sz2xVBxAgQIENgIpNHktcOavQ0ECBAgQOARgdj2 Eds/du6fTGntwBEgQIAAgdkK1E272j8529dCxQkQIEDgXqDuoOaYkiVFgAABAgRmK1CdP1kz7Xp6 /ubZbHFUnAABAgQInJ3f/laTBP2jtHXeEQIECBCYtcDZxepOtOusXwGVJ0CAAIFdAk1JBs7+XJ/Q I0CAAAECsxWoS4Ke/u2DadfZvhoqToAAAQIhkHK7vq1JW3dFiQABAgQIzFbgf8vX/6nL7fp0uX4y WxwVJ0CAAAECqZO8rIl2/UCIAAECBAjMVqBx7+TF6uVscVScAAECBAicLFa/1027ni1vf6REgAAB AgRmKRCRrBHRWtNR3swSRqUJECBAgEAINI0mBfF4TwgQIEBgtgJNo8nTxfrdbHFUnAABAgQINI0m JUD3jhAgQIDAbAWMJmfb9CpOgAABAjkCMVqsi3SNw5tz7uMaAgQIECAwSYFYf6xLMCCv6ySbXaUI ECBAIEegcTSZ9lXm3Mc1BAgQIEBgcgKbtUmjyck1rAoRIECAQDcC6YSQP2rXJo0mu4F2FwIECBAo T6A6IWSx+ntnRxn/trz7vryaKTEBAgQIEOhAIHWQN3WjyTQl+6KDx7gFAQIECBAoT6ApgCd1kn+J dC2vXZWYAAECBDoQaEouEKNMOV07gHYLAgQIEChToO5Q5u1U7HWZNVNqAgQIECBwoECcJVm/Lrn6 KIDnQGQfJ0CAAIFyBdJ2kLcNHeXzcmun5AQIECBA4ACBdCDz84YoV8doHeDrowQIECBQsEBMp6aO 8mNdRxnTsgVXUdEJECBAgMD+AmcXq7vaTvJifbn/3X2SAAECBAgULBCJAxrWJT/YM1lwAys6AQIE COwvcPbn+qRhJPmPsyb39/VJAgQIEChYIHK5Nq1Lnl6sXhdcRUUnQIAAAQL7CcRUasZWkA/2TO7n 61MECBAgULhAY/addDLIyXL1U+HVVHwCBAgQINBe4Oz89rfGdUnnTLaH9QkCBAgQKF/g5+WbH2rP mEwJz+N4rfJrqgYECBAgQKClwC/Lu+/ieKza0eRi/T6ua3lrlxMgQIAAgfIFmg5ijpGmdcny21kN CBAgQGAPgaakAjHKjFyve9zaRwgQIECAQNkCTcnOq07yYv2q7FoqPQECBAgQ2EMgJ8I11i2lqNsD 10cIECBAoGyBKj1dWnesD95Z/R2RsGXXVOkJECBAgEBLgafL9ZPGTjJNucrj2hLW5QQIECBQvkCc G9mUwzVGmSeSCpTf2GpAgAABAu0EchKdbyJc1y/a3dnVBAgQIECgcIHoJFOi8/dN6ekiz2vhVVV8 AgQIECDQTiCy6eR0kraBtHN1NQECBAhMQGCbmu5d00jS2ZITaGxVIECAAIF2Am06SXsl29m6mgAB AgQKF9gE7jQkOd8E7rzTSRbe2IpPgAABAu0EYgtI1ppk6iSdBtLO1tUECBAgULhAnPCRs08yOtIY dRZeXcUnQIAAAQL5Allp6eLwZZ1kPqorCRAgQGAaAjkJzqvIV53kNBpcLQgQIEAgXyDnPMltxp13 Z8u77/Pv7EoCBAgQIFC4QOoAr5r2SG7+fXUncKfwxlZ8AgQIEMgXiC0dqQO8zusk1ze2gOTbupIA AQIERigQ0aq5nVmVSOBi9Tqnk5SWboSNrUgECBAg0F4gNv7HNGrTJ7fbPz5kdZJOAWni9O8ECBAg UIJA2vf4/L7ji0OVd5U5Raz+kdNBbgJ3Vs9LqLsyEiBAgACBWoGYbk2d2ucRYtq+8fUUbESqRjBO Vie5WP19cn77K3YCBAgQIDAJgbTW+PKRDvDTFGwkEcjKtLMZRX6M6ycBoxIECBAgQKAaKaYR4KMj xeggH+9E01aP2O7x5U81Kk05XqkSIECAAIHJCKTO7iZrOvWRjvHLz6VpWYkEJvNeqAgBAgQIJIHq hI/GDvDbkeO3I8n1C6AECBAgQGByAtvtII9Oo+Z0oDHVGltFJgejQgQIECBA4PT8zbOcznDXNZFs QDo67xEBAgQITFLgm+0gbaZfI/An7aWcJIxKESBAgACBEGiTNOCLEWXaX2mq1TtEgAABApMWqN0O 0jCy3Gz/cETWpF8QlSNAgMDcBfKPxNoZ7Xo9d0P1J0CAAIGJCnS1HUR6uom+IKpFgACBuQtk52o1 BTv3V0X9CRAgMD+BQ7eDPLJNxBTs/F4jNSZAgMA0BTbbQdZ/HbJv8rHPioCd5vuiVgQIEJidwMli 9fs+neQmc091tNZl+r9fxKg0zqr8+giu2YGqMAECBAhMRyC2c3xx1uTD9ce0LzI6wtOL9avoCCNI JzpCW0Cm0/5qQoAAAQINAmfnt7/FCSHViHCxeh4d4c/LNz+AI0CAAAECBAgQIECAAAECBPoQ+D/g 6P+YDJsCpgAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image007.png" Content-Description: image007.png Content-Disposition: inline; filename="image007.png"; size=23628; creation-date="Wed, 10 Oct 2012 09:43:12 GMT"; modification-date="Wed, 10 Oct 2012 09:43:12 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAcoAAAHFCAYAAAByyrkJAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFvMSURBVHhe 7Z0LYFxVubbXWnvPZJIS2mkoUEAupRZSwt1eMpiKfwFri4iXIooHj+A5eLyDKKLQNFEQVERRf8UL clSOSH89HLVQS7nYQEIbQZG0QcQeKNCCtJ2UNJnJzN5r/e/ak6STS9vpNPf97hLaJPu2nrVn3vm+ 9V3curo6wY0ESIAESIAESGBwAi7BkAAJkAAJkAAJ7JkAhZJPBwmQAAmQAAnshQCFko8HCZAACZAA CVAo+QyQAAmQAAmQQHEEaFEWx41HkQAJkAAJhIQAhTIkE81hkgAJkAAJFEeAQlkcNx5FAiRAAiQQ EgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJkAAJkEBxBCiUxXHjUSRAAiRA AiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81hkgAJkAAJFEeAQlkcNx5FAiRA AiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJkAAJkEBxBCiUxXHjUSRA AiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81hkgAJkAAJFEeAQlkcNx5F AiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJkAAJkEBxBCiUxXHj USRAAiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81hkgAJkAAJFEeAQlkc Nx5FAiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJkAAJkEBxBCiU xXHjUSRAAiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81hkgAJkAAJFEeA QlkcNx5FAiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJkAAJkEBx BCiUxXHjUSRAAiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81hkgAJkAAJ FEeAQlkcNx5FAiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJkAAJ kEBxBCiUxXHjUSRAAiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81hkgAJ kAAJFEeAQlkcNx5FAiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLRHCYJ kAAJkEBxBCiUxXHjUSRAAiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIkE81h kgAJkAAJFEeAQlkcNx5FAiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAoQzLR HCYJkAAJkEBxBCiUxXHjUSRAAiRAAiEhQKEMyURzmCRAAiRAAsURoFAWx41HkQAJkAAJhIQAhTIk E81hkgAJkAAJFEeAQlkcNx5FAiRAAiQQEgIUypBMNIdJAiRAAiRQHAEKZXHceBQJkAAJkEBICFAo QzLRHCYJkAAJkEBxBCiUxXHjUSTQS6C2dpnMxzHrU7e5R5fOjoo4fprs/Y2KlYoSIdJSmAOHl5Yx X8SSGZGMDzibe4SXXfWpRVmBu6qrqx+Cqx34/fIMJDCeCVAox/Ps8d6HlEBtZaVa+sSMkmR8kxNL lUZw8rzXR0zh+5gVn57Ny7qOcNNvXLx8zeTcz5TRxlNCz54mlThGdgpHRI2REj8Xfpnvy0ohS+x5 D1i8olq2iV1T/iFLpGeMzt0VriSV1Gabu2VR3UMvi1ohmnXC84T7F1fir2Af4QlZmhEmp+DpdCyN v7Sb8rxV316UqaunsA7pQ8WTTQgCFMoJMY0cxL4IDCaCaRF3YyIV9aQoU76oXLzBjXVEk5XRXVPK fSWOlkIeYqz6CIidkGW4xmxtIJ4mp3NKQXuMay3EbvnUQuEPvsPPcBj+JyCSdm8pVPBfH9NzXze9 l9/jzMHpcW5c3Wq4vYiR9nt7w0rjTq0CBvLtad/+WuJWjHhNyM4XjCjRGIcfiemNSrgdxlXbIfib 1+lEWiv3KVdAWKXIQkW9GE5TGhPppIhrt/S1THXb+pzociOBkBCgUIZkoifyMGuXLZNLv/BELN8S 3JsIake+wRhzaMSkDtXSHKOMgtIYJQze/yFnUBRoDf5AjHZLm/3G/nKwrZ+B2PttIIu92mh/fMCm ZN7lYT72OX/3pYIbtfe+e5PO7m/NkRDII7t1Fjdk3gL1NFB9e3NWV4XSvgYXI7V8OSrNVt+IzK5O +XRUJNMirZ5rMm/eCnHeADFNC5POwirtisfj2RXXnJmmRTqRX2nhHRuFMrxzP+5GbtcCz7lpTWk8 LaIpmEQYQJmWaiYsoWkdURFYgoWIoLXEVKCC3V8BiW4J6/3LGl95m7UL4UAdS1u/O+x7a3tT5DwV zSmq/VwQfCpwcieR+NsKpzkOxulxgdQbc7Y1WQUU1DqYpfR92M9bhIm+GC2Rz+7qTL6yePnqliaR 2Cyku8U1XgqrsVk4q7vcUi8LKzQzltjxXkhgfwhQKPeHFvcdMQJ3bZ8SOfqI2dFYKl0m0qLEc92p EMQTZcqcusvI4/HefTzewKvwBg5XaGD4BZbgfomgFb6hNPFGjM4BXqjbdbz740HfDwl9zt4tqr2C KmCcwoWMDf8wxwrjHAvrvMb6ma3DFx9AIKaehynZGNVii+g0fxcd7kvNzps3e0ZvgM2+C15cbDEr nF58UzJdVdVqPcPcSGDMEqBQjtmpCceNBVbiNWvKYqWlUSFSJV7WKxOR6EkzJ+ujRac4Xpvom0xU Hu8orBdq6eAt3b5N26iVnEUYGEDBSl2wWSsr+OdIiGDOQdt3onq9rT0/z61QIshmaCfUDjkQvNz5 d289IHZ/AkCwT/HX7hbV3NkGEdTAGO2xSq1FGlimdh33DMzLGfYQ/Fpjg29b6IgwO31T8rdoqdiE U7/acWJ8Q5NObMGS6HOu63akS+OdWAdNcR20+CnjkUNPgEI59Ex5xj0QaJoyN+ql3BJYiKUxky71 xEHTFl//0Ez48d7km9TxUovjlePMwtuq261ASiqn543YBqN0B7DYVbWhdYV2v9l3i2/OE9krxDmp 6/O9HaL2PegxVvDyrVIpfHzfFUQAdQf52JgbjK0T57DRNEOlmC4uiyXE3SrZc83g5z0RuwjwUUCe v2jZRzjtHeU+WVjlzcnh/ghrEB/Uc3z+xAeCiesG66iBp9u6dPHXIYCGDz3mLMsD/2m4AoxwHCyM mpZIKvmk6XD/2uQk/uKlxOZYabqzNDW9o6psZYovLBIYLQIUytEiH4LrWmF0d3iTkFVRlhbujOgO 70yYjW/EO/GpsCpOVNKbjPdIGwuaCxXN2Yrdb9o5QMHbsD4Aiyh4f+62/Pq6EfPfyIXvZfH+jbU3 IQKXIP6Rxd/d62qBQgc/z91VbtEO4rcFZtLLuEFrN3X/Ru3E756DfgSBplYF4JDMaqWQoiGyvk0f OaAN+uilFazuQ4Svj5UOonCwWhiwsrBs2K0Rx0ClpwUBsRAnne06CXdR2m0R5tJcdpuhJdjNxXit iGF6ENbjRnNe7B6LNTDYu4U0uMhuUd3zUHJWfu+niD4fJnLz3L0waj8J4XtlrdAzMQlnBm5cH9Zn 1PxT+9GndkXb1jd58/8snOhfy4W3K5kSqfiZ53RWtdbTZXtAzxIPLpQAhbJQUtxvnwTyhREpF8ep bWIuvKXz8QY4Jyr9o2BM4U0xSPbrdkXat8Sc+zD4f5FWYmAt5UzAXuszz5rBkllOBHFt/ENmIQow BSF8ElInZcqmSeDSzyG5Ygfu7Xno3jaYsq96Qm2GNmoXWpMW3gubd2x8bcbxs3rf8sunt5ulYmm+ BIiLxApR19raV9nzpXEo7EkrZ3brefX2exXbKOB7Vuy2NO/Yugp3kNMUb4sLN7eYjUVEuEldqKw3 E/Dj4DAZGI4HixiEFfmeVlgFcj6Nzfu0Lu9YzkYUpdKqc8TqWk4wdwuq/XcBH2p63bn9Xbnd8xcE HVvr00zHuafjY8rbbC6qnchdRjwZLTFPdmx86C/N2QV/Fa73MoKGUnH8odW5z5codyiSAIWySHA8 TAgbcHPq1NmTEIE6qb8wQmiOsm+wueXEbiHrde1ZVSzgDbU/5F7LMBe3kwvWhK8zi/x5rbPWGrT2 JwQR6X8QQSXT+M6K4ma8hb+Ke3rZR7oDVGOHlnITTp/2Ss1TiMr0yh+F6C1dai66SJg9VrOpwBFt 63ffVZsQraK+z13WjYEHw6ZotOaFKVXn0ilzW5l4Hf9/PG9Zs8EGuNq14nvuWQGES4UV1k2olzAj uelIV8Sma6MPAt8TYa5CJL1TjC+OhKgebUXTyjWYl0LUIN8yAms0mKUg06RHRPfDCt3tBu6+39wc 5yZaoryC0dXYpxplFbR2PI0o3Jfgf4bVueOpAVbnpmQnA4XGwAM5AW6BQjkBJnGkhhAI4xGzy1Jp MUlk3aMQcPOmDt/Y9+E3Q7reYP1n/YUxcNQVEVjTE6yTE0ScHX+0tmuC9s1Rp2CX4stkYG2k8LUB omgtwRfhOGyHID4D2ymdTplWlHPr7BXBpRDB/pVnukDPflVB9FrrUfJtpGiOrevYDwetrdawrxd2 QqsFPhBI8Tzu8vlAVJV4wN5xJaoXrYC12j693PXi7syYcA/3tD5ZKXMU1h3foL0ukFQHQSWtezeK M0Zw0jKlHFmUFdorsj28er0GWPeEQWzMsTj/sfjpBUFBhXyr88T4X/5iEn/KivQr6dj012u6VnaO Leq8m/FCgEI5XmZqFO5zoDB6czo6xTy8+c0Typth3WO4LWhZYDh2L5LtpzD2Rk3uthLtULUH49DI NN75sFYIy1CYTnz/Mn74D7wpPqV9H0aT/oc5VDwPIfRX3LNUDxBBW0unLU8E+xp/o0B0/F+yFW7l KkghNuvL3RB8KfFgj7vXWqPlSTm53YgTXKGOg+E3HfN0OkoDHbE3KzQ4Iz5Q9bjfc+7cwbb84KPu 3+/J6kQ5vy4f9q8o/Ws0lXxgnX7zgyrT+UxpaWzX0tnnvI4PRkW4Ncb/HHIE+0+AQrn/zCb0EVhn LPGS7mRYjMfOnDyYMNrSpd2pGd2f9gu2GIM3tB5BzP3dvX5oTcUurB3iE7/qEsZvx1X+iq9WmAwv wZfa6qWnPh0/c1PnUryd2jfr3knoFsKqeqrgaD6YPe7ewM0rxXZ8NeJ+Gq1btxArFG7dKXDYWldu KR6MmA0oCtaubZxUIKB70bS9WZ022AlBQtjlTHjjP6ejpS92+OLROzc8tFp7cx9zI97rXnzW69Vt d7Mgwmg+QGP82hTKMT5BI3F7veIo3GOjOzILUcd7iVHeXLxh4fnoL4zd6QN7+sCff8O9wtgtijAr kE5h1xE7cW6UPzOdiB19Hh/8/4E3ymdQ2vspV+rnno0fs+Ur02f5F10ksV5Yl7uStQ5hQ+I/buOM wL6s0Ou2PuvM2LHlOHxsOhVieRpyLk/3TbYS/54ErSyD6JbZtc98qzP34axQq7M3SMjB+WyBhGOh 5x9AeG+Hr51GsWPzA81yQUPaeC+K0vhOumjH2QM2ArdLoRwByGPxEi0lS0qTyaStCn682CYWICDi 7cZ4c+FGDXIYA6uxO0du/y3GPsLYBfdpB07WgTep57GuuB5fzVh3fFYkvY3lW9u9FXbtMM9KnNPW KFphKUIkxyI63tMQEeixQi+xVqgSz+K0zyKo6P8tXbpCJWfHp0Q9fQoCc09D2M5cROKegoxQa3Xa j0wIKlIl1uq0QUP7tjp78m67bzwIN8ID7shyHPw2rHGfh/VvH+G9rTLVdv86kViLp78FsV6ve1Pd dhY/GKIJH8enoVCO48nb31tv6ExMgmNrspsVM6W/45xIRF6I6MHZeM+wdclyKRs9bqyg38Q+tsEt xn7CKNejqs7jOG9zaWvypRUrLtK9VqKNIsVXFc3EfZEOze+7I47tw7cdoUAP4++Ha5cvk5/69G3u pvjsWUipPR25q6cid/Q036Rn4qEtg4VYBrGbpCIFWp35rtqe9U2Yl4gFOhkfCk/GNa/2tXlVOLGH 3R3ikSbronW919KlsfaarkbbloxbyAhQKCf4hLeUJA5KJdNTdGnZidGof67x5duRkjYbbzBOUCel J7+/kBzGAxFGex0EgVRV0Uqc4I/ckA8vCNKqENkK0WgDhzbU1tbedc89Rv7wiTVTYlFzCvJdT0OU 87y+VqcpU04ElROwRGkLViCmZ9AAoT7rm70uWltJaDrs0A9gifT9iKLu1LrksWha/LEpm3jUjYhn vR1esrpivY2X5hYCAhTKCTjJDZ1LDo7FkuXwZ82WKb3YRGOLUW9tJixH+Jv6i+PeFxutC9ZGtQaB N7k1xsIsRgrjBHyyxsaQrEcCEaumpkzswB09Yr9s1G2P1QlP7mlopnmGyWYTSBuyfUVRAQoWpw0Q CnI77XM8WHBQd0Rtz9pnj7XpulgrNefhx+cp24PMqD+rye6vmjJz7/Mi7is1stHeB7cJTIBCOUEm N3CrxsTUqFSnRmNt74SmvQVRfjNQIA4JbPsjjraUnBXHoKqcjUrN4u2jffca4x5cqRTGCfIkjc9h 9LE6kbICq/O/UD9CtZ+0ptL4/mJ0NllgdKYKz/bBUMly5aK0EDYrmHsMDOrvorUvCMexAUFvgmV7 piOcWumbVeucBEJmS9eLVGpHTVkj1uO5TTQCFMpxPKOVlcvUDzesiaO22BujUfkurDcuRQHSY2yG PqqM9ZQkLSDhP08cwUOj1A2y+tsROPEqPlQ/BGvyj8KksMaY2r3GSGEcx0/OxL/13Dp4UAu2BaX+ WpCi8o0fbjzisKifeiteI2fjA+BZSEVCPVxdjlWImIT+BWko1msyWDTtQBctquM6B2Ft9L1wtbw7 ajo3i6i6p9ks+G+UO9y0OX508pK2u229YG4TgACFchxOorUeUa+zYt2G1W+NGPkelPJ+G6TRlhDr zvsvIOm/Z70R3TnsG4QVR5T/3Am31Ev41P2w7/mP6KPVw2uuOKcjCLCgMI7DJ4W33EPApqjUyNat EM3/gpv2l+fcvKnM7dh0Fl43b4HQvRnLCjNRhrgclmK5g24r1srcu4s2V/Q9V0YxWNE4Fj/4vK+z V6H4/aMzkpt/3WTm3l8u3e1VsrGNMzG+CVAox8n8tbRUOqmT4nFh3DdGY/6FKOON3Ht1LF6juQ5K QX3qfTQizhNH+8nZloLDGwTEUfwv1nIew2lWm4pj/nj/p0/IBp/IXxGips7mjXMjgYlDoLuCUwdE czVGtbqlcpmT2rjmRFR7egt6ni5CNO3JEL9yWJaTsa7Z7aK1luYguZs9lmagmTbpBOlVxpyNXd9i jJNEb7X715n5v1COatmaSm6/oKyV7cLG4aNEoRzjk9ZQkiiLpcQ0faJ6q/H1e9D4Atajitj2xTl9 7K5esqdxWHEMejra6L8giKETfydx2HP49NyghHtfadXZ63tbFuGzbzXzF8f4U8HbG0oCwbMvUYrP xdrmsmXfP/8Law7TMf8sFFw/V2fSZwnl2JZlk9EJLGbX+wNrc5D0qZ5uKt3F+vGSc6bi8+slKPb3 Ad8Xf58Wq/hFk15wnyu9F0o3JJMs2D6Uszi856JQDi/fos/eYBZOjRnvmGgq+264Vj+IjhjH2DYc Oeuxp7XR4KcPGi0E4uhYlyoi4zVKb2Z3ovXjc2iY9CA+F9+7avY5G+t6al22ri36PnkgCUwkAoG1 WWZ9KeLX+CD5a1vveEb5KdXS8c4zfub/4DX4RlSTmozMk0iwZGEFs/+aZv8gICQSYy1zFs5Zj6L+ y7Q0f+g4seLXiJr9o+e5ryEACMFy3MYyAQrlGJodWI8xkRbTXKHnlZj0+1DKCzmPalKu1+K+rcdA HPFlfA8C6e9EbhncqrIV+no/Xqr3/b524XM9hcOrW+lSHUNTz1sZowQuqWhDQM5a+0ly7V3bL44c W/78eY4rFyEY6O14WU7DR9KDJRIrc96aQYp05H2oDeocO8qF5bkEr+bFeG2/Go2ae5p04meeTP4D a6jw53AbiwQolGNgVhpMYiqa+h0T7RBLEDXzQbygZiGtAwahDbTpXnvc033m1kWCoALteV3a+NtR 1etpqfSKjFQPrKld+GKPOM6ppziOgenmLYxTApdUBFGsK+1Xs1lyOJb334kSeu8SJnMyBLMC65k2 Cqg7cnZgnmZvDEF3fiZKKR+OV/enlNaXR9TUXzWZBXd40mtlXubYe0AolKM4J836jGmeiFWXwLWK F5H9hDkpt/Jo10H24V7tsR7xKTZnPZqX7QsY3Yt/tebkc/7c41atoTiO4gzz0hOVwBy58hWsad5e W7nsR+dsWHM6Ggm8z2S77Gv4cLx2rWjuXsvck2vWvtKtaDrOJLhmL0Ot5UtLpPzvJj3/B67M/HWO fHLbROU33sZFoRyFGbMCqUU0IbT6qJLmXAQLoJicrbNaqPWohJ/NZqXWO3DMRoQW/KLcEfciDD2o EFJDt+oozCovGUYCwQdSJZ7A2J9A2lZdNGYWoWbsxSinNw8qOBUBQJMKDgBCvVlI51JlzLt8U3L/ Opn4SUakH19zUuq1/KYBYeQ82mOmUI7gDOQLJIJzzsUnSSwo9uQ87rmUXG5tw+5q3Tr6deR3bROO v1L56jfeId6j7G4wgpPIS5HAHgh0V+X5dW3dst+cX7tmJkJ9LvR15kK0KbGBPJMdNxqx7tc9BgBZ yzMIxEOBdiHegdf64ogpaVi8sewnDSLxoBv3XuNrfXQePwrlCHDHGuShrq8TSqgrChbI3rVHhbXH jG88vQMvsmfxCfUXSk25t9v1I0TbCAyAlyABEiiYQHcHlL/jgK8jAOhbMyZvPldKjQAg83ZbDQju 1snSRbplLl2r73l7llxyOc8oPynOhrIuQAuwdeaf6hfNXuL33hHeKxBMNpoueEYOfEcK5YEz3OMZ egQyIsVH8eI4F8+97ba+59qSwZqFbXfVYz36u7TJbsMPH0Kozm9Mhf7D/LZHvWG8ZZ6aBEhgCAl0 BwDdh1PehwCgw2wAEJZLLsTr+kxo4SFYy1SDRsz2FjLIVf5BbF817M1qX4r/EDvcO5pF4t50qdjK tl9DOFl7ORWFchg4FyWQ3cE5sB5hQZrtQvjPou/eb7Cov2KOevKF4DZpPQ7DbPGUJDAyBOAFehUB QD9EjeYf37lh9UJEp19qTPatWOM8FIIZ2atgmkAwsQQjq+BZ+ibaf30q2iF/2KQS93ppsZnF2Id3 DimUQ8j3wAQSXTq0hyLkTqOQ3j2ZUnU/Pi12DuHt8VQkQAJjgABahOl5SjyAhtRrFtWtmecY8S/4 gHw+vE6HQzCjg+dk9kTB9/TMFMfiJzcioO9TkahzByr+3OWVlj9f07WS7xnDMMcUyiGAeiACaTwv iwX/V5QRv/Md+YNq+ejTwS2xJewQzAxPQQJjl0CQ3yzF4/arySS+r7S5zHiZC7H2Mh1twGJ2mUaj eEjfbXfaWG6Zxj0cP/miMN5lkc7kT5rk3J9uSs7Y3O3yHbuDH2d3RqE8gAkbKoE0jvjBXNmYE0hu JEACoSNQLRtbhCOuQseR25SJ/LvOZi9EWsnRyolMsnljyJUGk76R8UEBA2xBLqZ0IJj6S1K7H5gx +flbm80Z/33p7PO3WOs1dDCHYcAUyiKgNpQsKY+md56FJONP4wk9r6AgnZ4CAXkWJAWyCPg8hAQm MIFquf55WJhfbJZLbvP85GWOyb4fkbLHINW63BYi0RoWZr8CBrn+majrbktdOs5xSovbtF/6oTs3 PPSdjEisqlGNr05gZCMyNArlfmBumjLX9ZKxmdHUjv9A77rLUCjgoFwVnUHa73Sf10aw2hJzqA3Z hdqtryAZeSUFcj+gc1cSCCGB7vSvG5vNwu9rk/qgzvqXok7sTFiOUxDQk3PJDiaYxgqmdcnKM5Gv eQfSSh5Yp+d/B+Usm1gar/gHiUJZILtmnThMbVPvLJH+NQg9m2ETgwsSSN9L+15mC57ce5TUd8yR jTa/ihsJkAAJ7JPAHPlgEp/Fv9NQmviJ22Eukqbrcum4J0IwD7EVfwa3MG3T6VxaCazMt+Fz/MIS KVag+Pr3vFLxZwYJ7hP7gB0olPtg1lKSOKi9XZyBTjnXolgAekE6MAq7m7gOcmyvBdkrkOZXSnbd 3pvisf9zxCNIgARCTiAQN1fc+XJJ4u6XUv4SvAVdAS08HWJ4CCzN7qCf/DXM/CjZoDTe+6Xx3hbp EN9tdhI/+X3tOb3NEkKOtqDhUyj3gAm5TuqHT606tsSXH1NKfxS+fxQuxnK5XSOgQBb0cHEnEiCB oSVwZFdj+kj0yaw8adl/3/n0mgvRU+9j2pgzlOPGc0E//d6f8goXoDLeVHjBlsHCXHLesjXfbFZn 3I8P8MmhvcOJeTYK5SDzioixQ9ZtXHN+RLlfMFKegBDsPbpZe+uwar/L9zPo4EELcmK+VDgqEhg7 BIJcTFf85redS+6fFt35PqSVfExJNdtGydoloQG9MYOKYLmAH3hkz3S1/zPflP6iKZP4jmj3Wqor 1jMhbS/TS6HMg4Pq/5PcmDgN7Y8/g6fq3Y7jIrVpkHqMwTHoA9ldqByBOi/jAbxbS++7QdQaNxIg ARIYAQIXlK1M4TJ34r3rtyhV8O8mm7lUus4M2xtzsMIFufZ9OldHVooPaaPPM5PVrYjB+K85qtG2 6uM2CAEKJaDULlsmz69b8wa3xHwU0axXIEx1KkJ19upmtWuRyHWyfSAbtBI3VavHHuMTRgIkQAKj QQAl7GyLvZvQoeiXvoh9QnqZpRDDo2BhOqj4FXQe2r3tXr+Ey3Y6CrN/DYJ54RM6cWNnWqzFudpH Ywxj+ZqhF0oUDZi6aPmat+ExugquizdZV+qeollzblYXqR5eVujM35Df9F19SPYnbH0zlh9x3hsJ hIdAd9Dg51AD9j+V1lcZXy+BGB5q28EPun7ZnU4ipJvwff9X0ai8HdblbbAuc/WluQUEQiuUv+2s LJ0Wi5+EogFXwY16ESxEtOwYxLdvKXW3vDKoRIy1gC34wQpo5tfmyke3sFA5X0kkQAJjjYCt9LOs btnlb79u9flGZK+GEXCGcksOMjo7oLVXzjDA2iUCFvHLq/A2t6BZz69PpyseqSlbSesyrEJpcyKn RcXlqGDxSTwch9uHBMUAgGNg82TrYg3crF7mdey3FnvdUu0+9shYe2HwfkiABEggn0A9aslWR8Xv Wkyiod2YK5TXdQW8YMfCHYta6v0LFtim8D3BPu6b4K69O1qy8/amzILbqqNrnw872VBZlHdtnxKZ FZ99qjbyC8jVfTcq5kgbrGMtyf5bEB1m3ay+54ms9zcsf//gtUnmjgvY0SPsrxmOnwTGFYEq2diG 2MObscy0Muqba3w/+3bHiVQEgT390t1ywT4QTOWUSaOvVMq31mVd2K3L0AglFrnjMyfH3udrcT36 Jx8RVObfQ04kfPrBCwHRrK/gwblXO/7NQTQrA6jH1RsEb5YESGA3AZSwa6mtX3bpouUPvU9nu65E 2tvJ6FJSapB7OSDYB9ZlsOTkqDOx5ATrMnl7g07cirqxL4aR6YQXShvRevZ1qyonRSKfltJcDhF0 UANxQJ3EYCnSulltMI/vt8PSfBKuiK9WR9f/IYwPBsdMAiQw8QgErb2UuLtFJlZ3GHGl8bIfRiGC I2FxDrAuA2MC3jZ43srwpnhlRIvTG0Ri2ebkxscvqWjLTjw6ex7RhBbKhs4l5fj0dIFSkeshgycI WxtxQH83q5D45GSLCvieb4z3rFHmR9myitvZBDVMLwWOlQTCQwDu2B0Qx+ubvMSDxs8uV9KZi9xL WJcI9umXShIYFniPdBx1tvC9X82Mz/5ys07fHaaqPhNWKOEmeAPcBVciPueTynXdPVuRypqSENDs Nnym+l2Jitx0mlr7LN2s4XnT4EhJIKwEqt3GRxDs8+6cdZnZp3XpuMi79PV3jIid3mwWfHOOXPtM GNhNOKGsrKxUd2yYdmaJ8b6JT0Fvtq7UQa1IzK5di9Q+KiWa7F+kMjfcV3feb+rq4JrgRgIkQAIh ITDAunT2Yl2igTRK4CGVTv6br/1562Ti+knp5ANVZa22QtCE3SaUUNoSdE0b1IWO9r+MtI/jIIED ax4GntaewgGZNvgZfm+U/5X5av3f5tU9PmEnmgMjARIggb0R6LEuO7X5jNZdsC4jR6Fj0oD3UFTy 6XHFnoJ4jrvaoxVfgwfvxwj02TpRCU8YoUTo8/RoVH9MaHGldN1JGp98Bs2LtBGtdpHay27SUty0 qurcn9ShwPBEnWCOiwRIgAQKJRBYl45YhmLpD6I4QT3qsCSQd4ka6v1id+x7KN5jYVwehApA9VEh 5jbpBddUq7UbC73WeNpvQghlQ2ZuVdQxNyLx8R1wCwzqas3lRUbsWmQHPhE9ZFSkDpP6RHVr43ia L94rCZAACQw7gepo4x9hfFwc0V6d9PV7HTcat0tYQRWfvM3Gftj3XGHU+Y7xp6M59GfLNyYfrapq tZbKhNnGtVDetf3iyMzJz78t4jg3wJ16ihnETWBnKnC1wq3uZzNb0OT0+9mMvLWmbG3HhJlFDoQE SIAEhpgA8i631tYtu2Lx8ofW+V7mi7AsZ9gqZv1bePW4YhXad0nf++XO2fFrsAz2GxRXnzDvseNW KO165Iz45kuNVl9G2HJFUIIORQr7b7a6DqK0UIAi8yesRV4/XyIvsmyInyiejgRIgAQmIIHuvMuf wK36F7Tc/bojXOuKLRlQAq875xKtCadDLH8gonJWi1n4nSr54D8nApZxKZTNJnFINCo+jU8316D3 WmSPuZHdrlbo532uktfMUev/dyJMGsdAAiRAAiNJwC5TwRX7XqxHXic8fSlcsTBO+rtibbUzuGId twxW53UdInV8g1lwXY1cu2kk73U4rjXuhBIFzd+Auqv1iMb6EHzj0pZfGmBFwmduCwjA1bpVOOr/ ehl9a/UEcgMMx4PAc5IACZDA3gjAFbsDrtjPnrds9V9cr+taWJYn2kIEA12xWJ7EezBWwt4fNdlj mv3ElXOijevHM91xJZT4dFIV1dlbEJhzHpIgB0/9wM9tExA/k/mrcNWX5slHf09X63h+RHnvJEAC Y4VA4Ip1xc8QtLMBgZHfcKRTI5VtDt0vKhZLYQaxITBYElj4wv5zP33ZSe0PtLa2jssMg3EjlHC3 zo94/u1I/TglKLFkyyr12bq7fWgvjZYgf9COdw0KmaO5MjcSIAESIIGhJFCtGp9olon3o2DLzXi/ fTeKqx8ULIHll79DhCw6NcGmcU4Qvv7pnU/HP6MPmXsvGt1nhvJeRuJcY14obVHzRcvWvAPlyr+F eubH5fpG9vtQEtQhjKAMIQoICHm7ctI3z5NPJkcCIK9BAiRAAmEkMEc2vtIyaclHOzp2/s1kM59y 3JLDBl+39AQMnOkQ0u+rf0YPafGW/LSqbOW4quQzpoWyacrc6KLlq9+F9I7votLOIYMF7fT0jfSz XVth7H+t/Jmd35loOTxhfBFyzCRAAmOfQFUXBM8VNzZl5v9D+F3LEMgzW2p0YOqXb4kKPrAsI1OF 8b7WEU0e3NKZ+H5VWePOsT/C3B2OWaG0Iqm2uZfDoXqzcJ3ywUXSlqLDWqXXhcK8+kvV7vrfiKrx gp73SQIkQAITg0B19PFfIYbk7xE/c6uS7gKbtz4gyAeuWVs1Da6/r+yKiooGs/DrNeMkfWRMCmVD SaIsuk18GCL5VSuSg0e2ImjHOmG9zHot1ZXVzuMssTMxXnMcBQmQwDgkgDSQJ5vU3A8hb/1b8AKe D+sSxXr6ZiXY7yGiDvJIPhvVqcOa1RlfnCOffGmsD3fMCWVLSeIgN6WuRGzx9XbhcXCRxG0jYQdB PQ8o5X9mHgqaj3XQvD8SIAESmOgEEED5fIuTuHyXNrdIz7sYFmSJdbvm1922libEUsI9+y/axCYh P/MzKKj+4lhmM6aEEsCmuh3iE8iOvA4u1cFF0rbG8vyslObuSU78yiq5cvtYBsx7IwESIIEwEUBh 9e0NXYmPR6Nmu/D8f1ORSDmaUAwUSwn3rNDvjuL/6D4ypsVyzAhls1k4LWpSy5HAeoXtdzbQkgzC jG3B8w4E7fx0W5f84gVlK9vD9AByrCRAAiQwHgjYOq8tlZWf79hQsQ0RsVc6keg033YgyUsfMQaW JXItkez37ojRMrAsZePmsTi+MSGUq/UZ8ckCImnER1G0XOVM9fwNIukG6R+7wPUWGfe/ckHb+oEl ecYiYd4TCZAACYSQQFUrOogo8dV1OvGq73XVKbfkqKBdVx+xRJ01vKnDF/uuCLL+GtTYFMtRF8qG ziXlB5ckPwta/w5LcqBIIkcyKEfnde1AcM93ntux8YZLZBtFMoQvPA6ZBEhg/BGY5zbe0eTN3yGz mRvhhq3sX5jAppLkxNJALOWYFMtRFcqGzg9Oikafuwrm4uchgm7/cGJbR9CxlmQm8xr6bC//8Mlt P2htbRuXJZDG3+PNOyYBEiCBoSFQ7T5+L5pB73Cymf+rItGT9i2WZ3yiRj65ZWiufuBnGTWhRJ5k iett+gQSIb8EmxEu6n5GYne1HZ3JvAxlvOGyk3fePl7rBB74NPEMJEACJDC+CaAZ9FqI5cf2KpZB E2hzYcSPJluchdeOlTZdoyKUTVMuRjGB5y+HFl5nyzUMJpL4Mbp/dCFkWH6m2m38TWvr+H5IePck QAIkEHYC+xRLlCi1XaGErz68y+/MtDiVEMvWttHmNuJCWVm5TK17avVHELRzM/yqBw2IbrVrkraP ZDbzKirqXjkv2vSb0YbE65MACZAACQwNgb5iWQI3bL8AHyuWjmP7d32kw4+/0pCp/EZNWWvH0Fy9 uLOMuFDeuXHNe9Ej8qt7FknkSWa7XgOqustO3fnftCSLm1geRQIkQAJjlUCvWGa6voc1yypbTL1P NGyuKIFrpP6SG5u8C9XavlfT1ZgerfGMqFA+Zuaf4/jmVqR6HDxoCojNk8xmdiBPsvayk9u4Jjla TwWvSwIkQALDTCAQS73gY8rL/FBFSk4caFlasXQjSpu6aIdKtZxceXuQcjIK24gJJSovnBQx8hbl qCNy0a1IM+3drLvVVtzJ7oQl+dXyk9t+yMCdUXgaeEkSIAESGEEC1WptA5pAf1Z4me8rN3r0QLFE bVjHnQRt+HLHhvhryMtcMYK313upERFKNF0+KmrMrWiJdUpgXuc398StoBCPFcl2QLhVVHjfGq1P DaMxAbwmCZAACYSZAII171vnJT6HBhffhgF5+IDUkaBFlzvVePrrTTKxtVo2PjrSvIZdKNFKZWrE pG6AzXgOIlgH9CmzIonSRl1Qy1vN1OwN6H7NYgIj/RTweiRAAiQwigTuqz9nxeLlD8VhMN1o+1YG lmXvhix6W5TAkcdIbcVywYdgiT47krc7rELZ8HKiLHJox1WIYPqADfntX1AAP0PtVt+gjPwvMqXm 6zUUyZGce16LBEiABMYEgbr6etNyUuWPOzbGIZbeF2FBlgcBPj2b9UIiIwIVfOYjd6QedWFRkKBx 20jd/LAKZfQw8S8Y2Ketk3lArqRNLIWvFZ8Ufue46guIaNo1UoPmdUiABEiABMYWAbvk1hSf+w2x wznYIDUQ3sZYvnEVWJVBQ2j9XiTfP9dUMffL8EB2jcQohk0osUB7lhR6mXKiB8Fq7DsWmyuJFiso cr4u68jPzB/BTwYjAZXXIAESIAES2H8CdumtobTyxmjnlEMhiJflPJG7q5Z297J0pDafNjvU32Br /Xz/r7L/RwyLUDbrxJHC11+D+TwwwrW3oEC61Tjq4zCf/3f/b5tHkAAJkAAJTEQCNV2tuxrkwuuj Jn00TKpzjcQoYU32emFtjqUtVuNlbm4Sic3VqvGPw81hyIWy4fAlZdEtO66D2TwfsTsYX780EHQC QXQT6reqqxG99MRwD5DnJwESIAESGF8EatSDW5tM4hrpZ96A9lwnaqsj+e25IJYI+pmOJb1bYJi9 a45qRLnT4duGXCijW3a+Xxp5GUah+q9LIqgHwTvZ17XUtavqz7u/uq5x+EbGM5MACZAACYxbAjCk /twk5l/r+N4PlOMcFqSN9JqVNrjHwBZTp/vav66ltPKzVbBEh2uwQyqUqAz/Zqn8eulGov0r79hF WCxKWvv5J5uSz/ysru7xfFNzuMbH85IACZAACYxTApedfN5v79iwZqbyvTpoSFmf4J6ggLqLJsbi X1Ppimao5o+Ha5hDJpTNnWccpUrMzVI6R8BsxP3m6SCacgZuZiMegl7eeElFW36SzHCNjeclARIg ARIYxwRaW+u1V5r4frTDnACR/IhNKewb3BNU7okiMLSuWS/4y5zo2j8Nx3CHRCgbDk/Eoi+Ja3GD e1iXxOC8zHO+o74Ac3rEcl+GAxjPSQIkQAIkMHIEkDrY0aAWLovqjhOkjNT0D+4RsCwRE3OEFt5X kV95CQJE/znUdzckQhndKhYLof9FqgjWJfumgvSsSwqt6ld9+ZwnuS451FPI85EACZDAxCYQBPfI BZ8XfmaFdKJHGT8vCrY7v1JI/daIrz+9/ZCLl1e03T2kXssDFkpUfz9eGr/WVlKwCaH5W++6pFE/ ntm+4e66ukauS07s55mjIwESIIFhIbCq9ux1i5ev+YrxM9+Eu7UsPw6mN7/SN598dsfzj1cr8buh vIkDEkrrco28nPksIo+qbB3XPsXOsS5pN2PMg5OUuLGC65JDOW88FwmQAAmEioAtc3fX1Lk/nbnN TSDt8FL4W+HI7GdZOk650rIW3ar+VKMatw4VoAMSyugWsUQY9UG4Vwe6XCGUUP5N2lHXVsnG7UN1 wzwPCZAACZBAOAlc0rY+06zOWObpkkrXjczRSBHpNdCCerBB1shpUWE+2VJZef1QdaIqWiibzRlH wdMKl6sziMsVSu97KWj9LZfNTv65tTWck8pRkwAJkAAJDC2BOerJF9bp+V9ETv5/IT1kmjG742Ks CxbLgA4iYz/evmHa/UK1NgzF1YsSyqYpc0vUdudqVKM7qdu/uvtegmLnqO8u5KrXMhU/b219vO/C 5VDcNc9BAiRAAiQQWgKTTj7v4Y6Na75nfO96rFdCGPPE0gb3SHWw0t6yBlF5cY1qPWCPZlFCqXa4 Z8Pc/TBucGD1ncDl6r8kHOeGC8pWtod2JjlwEiABEiCBYSFQ1VrvN8SWfDPasX0hVLEGlQd668H2 dBkR0j/bFZMvra1d9q26uvoDCiTdb6FsNgvjQqSusoqdX6jW0ghaoPjZDG78G5fNPhsu17XDAokn JQESIAESCDeBmq6V7evE/Hos890N7anIKwULaYJPU7kuasVefX7tIw+B1FMHQmu/hdLzU+91pDgb jmDcTF7tPbhc0VYThqZanemacoetqHAgN8ZjSYAESIAESGBvBN6WOO+RPzSt+RnE8kp4OAOB7N0C F6wz3Tfe5xpKKj9qu5IUS3O/hBJVD46MSPkJhOVG8xdQA2sy53Ldoh1neQ1drsXOB48jARIgARIo kEDb+novoxLfiPjibAS8nh6EvXaXT7UuWAT2SBRTf280Fb8HvSt/W+BpB+xWsFDetf3iyMz45k/A ZBwQwAPVhkh6Riv1AxFPPyXair0dHkcCJEACJEAChRNAybot63Tiq0b4P0GqYvmAwulSliDv8pMN MvEo9t1R+Jl371mwUM6IbzkVIbeXogeYDb3NuxYcrgh/xY0844rOn85pezLPH1vMLfEYEiABEiAB EiicwHOHev/zxu3qnVj6uyS/cPruwB79FteXS4Urbi/8rP2EElFBctannnUvqRi8Pl5LSeIgmfI+ qZQ6PJfcuTuAyAbwIJ+lC97gm+6rPf/lOfVPFnMfPIYESIAESIAEiiJgCxE0ybk3K+2fgzaPhxnR vxasikhffxxNnn+PJs8v7+9FAoty6TUrYh1uxUVNmbkbXNd7AQmdr+WfqCOt3gxH74UiSAfJL3pu cyZtZQTxmJeN32tLDO3vDXB/EiABEiABEjhQApuSzz4zMz77p77nXYNCOLJXq4KKPbbJs5mNjsgf rVxeWdta37pfwaaBUCbFjEhUJVGz1TlOi8i9Td78X6Md5oZ0qXh5c+nG7Mwd+l+EUOV9arniOKms y9VvE465qSay8vUDHSiPJwESIAESIIFiCNg+x81afNcI814sB87Mt9rscqEtTCB19l9/uDz+nzVK PLc/1+heo0z6MFVfQN7JyVDiDyqpPojgnGeiKXn3jNSJzwltFluF1nnWZM4PDOvS+Pfqtr+tFRX7 c1nuSwIkQAIkQAJDS6D0pHNead/w0I+Ul72xf8UeVFC3KYzTI9r8W8vGyi9WVbX27Qm5l1vptiiT +lAVf822jja+LXEAq1Q5JyLlY7mLaFuNgnT5ImnPZwN4sNc/jTK3Vle0dQ3tcHk2EiABEiABEtg/ AkHFHrnwF47seD/E7bQ+6SLWqoTFh/z/DyRnx3+MM/+90LMHQjntiHItt0vrOoX2Qfp6A3ZgxAax O/2WHqGl2vdRuF2vmu+s/2uhF+N+JEACJEACJDCcBNbUnrV10fKHvgGN+jF0MdY3rsZKJ6xKX14O q/JLhVqVOdfrrEW+ePyhVyGIqPuDANoeXewvkN2jgzEJb6z0jZTtTZkFp3ie93xNWSPXKIdz9nlu EiABEiCBfRKwQaUNRyz5XeTFHX/BzvMHsyqxZLgUVuW38fuCelYGQnlZu9B3Cv0KlBYWpa1ssPct WBiVMqKk83GtvQsjMfHLJ/Sb7+sU+jl3qvdqNUJ193UO/p4ESIAESIAEhoPAmvimXYu2xr8Hq/K0 vlZlzgrE/9/gar0U1XpuK+T6gVBedJE0i6+/f6eRjpE4sqAN1qY1OJWjjkRgz9Wel7mqxHEfNNvU A81q4Z1z1IN9UkwKOid3IgESIAESIIEDJFDX2qobpi/5LazKj0Oo+lqVQWk7J6J9+RHkVf4KeZWv 7utygVDW1dWZJh17TaFYa1BlZ19H9f7eiiW+EDMr3SjqEbjn+r5/uCdSjdiFQlkwR+5IAiRAAiQw lAQCq/Kl+PfgAT0NEbBYq+wuGhfkVdqAVHMCnKOLa+tq77QauLdr95awc6X3ms4vZ7Afd2xTRax5 mc12NnqO+jjq6f1lPw7nriRAAiRAAiQwpAQCq9JJ/B7pIM/B/Kvqc3LoFYxCNPcwHzjnpntWiH10 Fsmr9ZrebkwJJHffa5T5F0Tupc2l1IjuuV840c/WyLV/G9LR8mQkQAIkQAIkUAQBN+7tMjvcn6Mu QJ+8yu7OIrDvsgnRPm127Q0XNe/NquwVynQqlolGxU4obMGlA7r7f3mIgP0littdWy3X7ncNvSLG zkNIgARIgARIYJ8EEFjqNYvEXYhSvRwm4Kw+1Xpsv0ojS1yZvXTWp779ZyHasns64W6LMh7XYldb MkilzOvpNfiBCPlxbDF0vxMX/3l5l76mqqxx5z7vmjuQAAmQAAmQwAgSKN2Iaj0nrflPCFYdCg64 PXmV6HiFsnaOo3z/7bOmzv6KEI2v7Fsok0ltouZloeWZQUDPHpc2URHWjaChdNfrCJH9rk4eU19V cTcr84zgxPNSJEACJEAChRGoqqr3m0zid9C0q5SUFbulrftfUhzp+Qjq+XLtT/fkfu21KJMiKGO3 HSGvNpfSRucMvAsIqONEheel/4mC6Lfev/ycm+vq2DGksOniXiRAAiRAAqNBwIuJv0c6xDqE07w9 10C5W9+CoB5Roox439KbHrhHdDXuGuz+eoUyV8bOoLqOsr7XgcmUViTdqPCz6eexjvnl+bLpjnl1 NguEGwmQAAmQAAmMXQLxJ5LZ9tkV9yBVZCECUEuMyaWKBEE9CEg1IjOvPaVOhPL9aa9CuccydjgK xdGxJgl3a7brWc+XV50VbVo5dpHwzkiABEiABEhgNwFb07XFJB7sEGYrzMlj+wT1WO+pVJOkNu+4 KznlKduuqz+7XovysvYVKGMXH1DGzuZIYgFU6EzqSSxiXnlWdO1aTgAJkAAJkAAJjCcC7XHvn2q7 8wcUHvg3KR00/8j1brZ/wxvr4u9zjy6d/Q0E9exZKC+66KIBZeysQNrNy3Y1eI7+eI1a+/R4AsN7 JQESIAESIAFLwNYgXyfn/1pr+UGUkZuEtpI5MHad0nEFlPNkN+Ydi58M0Llei3J3GTs4V217EFtI wDah1Hql66qrq+XjBffu4rSQAAmQAAmQwFgjsFNk/nSwLHkB4jg7/966W0tGlXbPbZo6t9XmX+b/ Pq8yjxCuTP9TGxe10SNwtaazOPiXENpr58jGLWNtwLwfEiABEiABEtgfAuVJt1PG5SPIpTwBy4pO j/vVWpdGqAi6Mb/FS7k/wDn3LJRp4SYjaDIJH24KJQv+M9sVv2Z+2Ur2mdyfmeC+JEACJEACY5LA /d9elFmyfM1DQsnLguCb3nVKuF+VI9EXZG4sJaYh+vWFPVqU8ZTItJfoVp3NPKIP8ZfVtK1kIYEx Od28KRIgARIggf0lUI+mzkouedTXyR2IUz2ib7UAVJyTcjIie+bXLlu22TaA7jl/H9drMi7Sbsp8 ZVLVefdVtdb7+3sT3J8ESIAESIAExjKBralNrx8WnfKY9rz3onCOzK1PYgvcryaqtVl4zs1r/gc/ SQ8qlDVdjWmYnL8TrY+P5XHy3kiABEiABEigKAIzNolMx2z5EAJ63olw1yi6X+V0En/gfnWM58+L J0WJKNuDUBZ1VR5EAiRAAiRAAuOEgC0+0OwkHjFdsh0ZHrtrv9o0EWXdr2JGe8w7AsPpbfTRx/U6 TsbJ2yQBEiABEiCBogmkXfFitEtsQvoj2kraHsw592vghrXVCLR7eu3yZc/0rFNSKItGzQNJgARI gATGKQHfKPG01P6ZcLei1kBP3I51wJoIJPPMRbet+jXGFgS0UijH6SzztkmABEiABIojYIuk7zwp 3gTX6wfwFetplpUTTGmr7czxtrS7WKekUBaHmEeRAAmQAAmMZwJ2nRI9Kv8EgcxaoezNAwnWKV30 ePbfGCuNH4QxdtCiHM8zzXsnARIgARIomoBnsE4p9DYsTJbnn8RWcIV4Hozfn4rly9UUyqIR80AS IAESIIHxTCCejnfuim5/AiXNj4Uw9uZTBu5Xg2VJI05B3deHbN1XrlGO55nmvZMACZAACRRF4KnU Y97M6IlPoT/lBfC3Ip+yp/BAsE7poHLPcZmUazWSQlkUYR5EAiRAAiQwrgk8++1PeTOuW/M3pYwn hYzuHkwuRcQY/41IpQyMSVqU43qqefMkQAIkQALFELA5kk2Ruc8J3w1aS/YmiHQH9Bhfz0JtHtem WVIoiyHMY0iABEiABMY9AVd4L2rpIgVE9gvogY0pRTxm4iiSLtoolON+qjkAEiABEiCBYgikU7Gu SIl+CW7WQ/Ir9ASVX9GZ2ZP6eJz3BQplMXR5DAmQAAmQwLgnEI8nvfaOKc8abU6FBYnI19yQbOQr 3LGO1GJW7cbKP1Iox/1UcwAkQAIkQALFEGg/9VRfPr55s9BoIWIrDexeqbRttyKokP7GRdPLg9BX biRAAiRAAiQQOgLl7U/5O3X8BVcKDyakzZ3sNinxFyxMIdTk10rbrIJyIwESIAESIIHwEVixdKle 9PTqbVBFPWD0BkUIpJ4Uj8dt8VduJEACJEACJBA+AjZFZJ3z5m1SawilbbfVY1DaXEr8MSIuRJIW ZfgeDY6YBEiABEigh4AWul0hyBUNm3s9r8HvbNFXIyaJJC1KPi0kQAIkQAJhJmC8NsTx+H0QWIMS NeyE9mzaCC3KMD8fHDsJkAAJhJ2AJ9uTysRzsTt5zlfre4U/9uBYLE2hDPtDwvGTAAmQQJgJYBEy 06FFSigzJZ+DLWunpCxLyxiDecL8gHDsJEACJBB2AslUXJdE5D9RZGB63+o8AZkgYYRRr2F/Sjh+ EiABEgg5gaBfyF4YUChD/oBw+CRAAiRAAnsnQKHkE0ICJEACJEACtCj5DJAACZAACZBAcQRoURbH jUeRAAmQAAmEhACFMiQTzWGSAAmQAAkMTgCBPANrvebtSqHkk0MCJEACJBBqAkaK0sGjXnN17CiU oX48OHgSIAESCDeBmEhHtYwdJqWCJParZGfQpxIbhTLczwhHTwIkQALhJhArLxcmO4ABChDgZ6Yd xe00hTLcjwhHTwIkQAKhJuDJ7BRlDCqg93Rttjisx1ULacT2ZEpQKEP9hHDwJEACJBByAspXFWjQ DKHM26xOQiiNNK+KeBuFMuTPCIdPAiRAAqEmAIWcYrs2B57W7s0G9gTfKtmJfpSGrtdQPyIcPAmQ AAmEl0Bl5TK17uk1FWixNdD1KhDIY+RrIi58CmV4nxGOnARIgARCTeCOrauUUNHJSvsOmmr1NymN kH7SLT2OrtdQPyUcPAmQAAmEmcA/hCOm+kfD8+pgUTKPRJA+6UvjbDf3b6JQhvkZ4dhJgARIIMwE vCNcJ9KhZwmlnL5Rr6Aiha+V3rRq1SK6XsP8kHDsJEACJBBmArFUusQXJbOkNSj17mIDEgV5EOBj PKE219XVM5gnzA8Jx04CJEAC4SZwUIWU2bgVRtMnj9IalLI9ZlIv2pRKBvOE+ynh6EmABEggtAQ8 kTlaGtU34tWKZmBd6k3pdCwtyiiUoX1AOHASIAESCDOBWqSGLHp6zRuhi26uXF1uC3Io7SbMiyIu fdFFoQzzc8KxkwAJkEBoCSzauiqCGJ5ZyJWEZ7V/xKvx4I7d5J7qeWI9hTK0DwkHTgIkQAJhJnB0 ypUvaTFbBJE8+WV5YFNK6Wsjnrusvd1rBSSuUYb5SeHYSYAESCCkBLYk01NMtORUpVxptLebAnyx kMqscCJPt7a2Bg2dKZQhfUg4bBIgARIIMwEvFjtFaXFwrjVznk7iOy309nKT3RQsWFIow/yYcOwk QAIkEE4CTVPmumqbOB1C2CeQBy5Xoa3TVaink6VTUjaQh0IZzmeEoyYBEiCBUBPwUq5bIuWZ6BkS yV+ftE5XDT8s9PLJzaXlWQplqB8TDp4ESIAEwksgli4t1Tp9hnRdlV+Rx1qU8LZ6WorGS9ruzvYQ 4hpleJ8VjpwESIAEQknAM96xSopDc+uTeTmUQYUe0V4uxV/zwVAoQ/mYcNAkQAIkEE4CuUIDq2sM +mvlFxqw1mRgXUr5TDK2Y1eP25VrlOF8TjhqEiABEggtgTOfWFEiopPfLqWKQhl7OVinqzG+j583 b96yNSsqdiOiRRnax4UDJwESIIHwEYjHDj1K6cw85Sip/bz8SVvy1TcZX/gPPvvtT2dEfV0vHApl +J4TjpgESIAEQknAul3Pe3rNBTAeJ5k8a9LCkEF1Hv2iKyc9Xldfl59ayYIDoXxaOGgSIAESCCGB pZtWlHWIye+U0oXbNT+IRwnje9o4cqUfn9Yh2vrCoUUZwoeFQyYBEiCBMBJoT8WPc6Q5WcLN2sft mmvUnDK+/n11292Z/mwolGF8WjhmEiABEggZgZaWSkecqOF2VWX93a6BdSnlP7wu+eRgflYKZcge Fg6XBEiABMJIIDljxqSI2PFOCOVAtyvyQhD1unLzU9lOUT2QDoUyjE8Mx0wCJEACISPgxtpPkFrO HsztCr9rZ0Y5919S/dgAt6vFRKEM2cPC4ZIACZBA2Ag0NU1xnTdl32GURJGB3bmTAQe4XeF4fUaU en/NLzKQz4hCGbYnhuMlARIggZAR8M6ePkl1infAmozkV+MJejYL35OOWrl5y1GdoqJxUDIUypA9 MBwuCZAACYSNgJuOvwllXU9A1R0U4+nbpFn4IoXiA/ddUrG7CHp/PhTKsD0xHC8JkAAJhIjAyyWJ mEyZjyKIp6RPp5Cc2xWOWL/l1ZjYsCe3q92NQhmiB4ZDJQESIIGwEdicFic6WpwnXUfl505KB25X 30NtdHnPtFIvQ6EM25PB8ZIACZAACYiWSuROPm0+bJA7KXTfIB64YmFQyq0Qyj9Utz2e548dCI4W JR8mEiABEiCBCUmgfeOhs6TIXiSV4+a7XW0Qj/Z9a03+SsSzf+9fso5rlBPyceCgSIAESIAE8gkE 1mRL139AFKfl2mnl1TnPdWxOlkjnv05re2yv1iTXKPlckQAJkAAJTEgCgTVpskuxFun0CeJB5KsV Tvz3QGr9EU8PVomHFuWEfCQ4KBIgARIggR4Cd025ODJj+2ZYk3KANYmfWbdr0nHFd+dUDyyAPhhF rlHy2SIBEiABEphQBGYkt7xBGg1rMjrAmjQaOSFGPDBjx9Hr9lRggBblhHocOBgSIAESIIEBBPzM UhQXqEAj5j5rk7bggDZep5b6R7fddoJXV1dXEDxalAVh4k4kQAIkQALjgUCzThyJUJ0PI9IV5ery UkJsAI8VTq2f2J5V6yCSedE9ex8ZhXI8zDzvkQRIgARIoCACntYfVFIdH+xs+0x2b0FdV99Loa7r bU+ckuy4oLWg0wU7USgLZ8U9SYAESIAExjCBpswCtNHKXo7i525/axLfW/tynVcqVtW1tvZrIUKL cgxPK2+NBEiABEhgKAg0lBweK/G8z6IKz8wgZTLPmlS2wIDO+kLLH66ZkUzV7Ic1SYtyKGaH5yAB EiABEhh1Am7q2HMhju9HER6p+3cIsXdnTKsbkQ/vrzVJoRz1qeUNkAAJkAAJHCiBZnPG4VKLa4Wj So3x+5wuiHT1s51aqK/96+zkP1v305qkUB7o7PB4EiABEiCBUSeg/egVSql5aKWFijt5QqlQhcdu 0vkfr0z/v9b9XJvsGRiDeUZ9inkDJEACJEACxRJoMAvOjIjsJ6R0Vd9+k1JIAeE0/ktKOTfXdD2a LvYaFMpiyfE4EiABEiCBUSXQULKkPJJKLoM1eQhyP3AveekgsCaNnzXacb7/r7PPfrq1dW3R90qh LBodDyQBEiABEhhNAtF08j2oIbAETZmxDpnXBCQoLhDIZmO50Le3ttbvVzpI/zFRKEdzlnltEiAB EiCBogg06MRxUW0+Lx3X0fnrkjhbUFzA89qN49xQJR/dXtQF8g6iUB4oQR5PAiRAAiQwogRaWpY5 kRNWX4kWWicE+ZL5FXi6A3i0kPeUb/w/q0XVowd8bxTKA0bIE5AACZAACYwkgfbZqxcjHeRfEeU6 MIAHka++7/3Di4mbqqrq++aKFHmTFMoiwfEwEiABEiCBkSfQpBecIP3Mjcp1y2335fwNumlzJjNG ypvXfOmcf9TUNw7JDVIohwQjT0ICJEACJDDcBBpMYmpUePXCcavstWxjyd7NBvDYpsxGPOyViZ/X 1dcX3B1kX/dNodwXIf6eBEiABEhg1Am0tFQ67izxCeHKiyQEsW/OJDRS2cjX7Guo53pjTVdj0TmT gw2UQjnq088bIAESIAES2BeBjhPj74HN+Hlbkm4wkTReVhglb7/s1HMebW0dGpdrzz1RKPc1O/w9 CZAACZDAqBJoMm85Xcnsl1FhZ1Kf9lm4K2td2j9amHs9KW850JxJWpSjOtW8OAmQAAmQwP4SaDaJ I5Tx6mFJzgqCd/qtS0rlCp1N/9k4JdfUyLVt+3v+QvanRVkIJe5DAiRAAiQw4gSaplwcVdteuAbR rOfbQB2j86NcUcnVrkt6mdeEjCyrVmufHa4bpFAOF1melwRIgARI4IAIqG2bPwjX6kdzXUHyStRZ l2uQCuLhh8635rmP/v6ALrSPgymUw0mX5yYBEiABEiiKQLNOLER+h12XRKW6fiIJ4bTVXPH7X0/K 6G+LYVayYT59UXx4EAmQAAmQQIgJoKjALKxLflU5zhFB8E5+RqQN3sm5XJuVI6+vKmvsGG5UFMrh JszzkwAJkAAJFEyg2ZxxlCOyN6DZ8hyrkH2KCtj41kAksy8L5Xxpjnz07wWf+AB2pFAeADweSgIk QAIkMHQEmjvPONyUlCwXyn2vPevAfEmsVXrZLqHkzfPUow8M3ZX3fiYK5UiR5nVIgARIgAT2SKCl MzFZR8x1yolcbq3IwUTSrkuiK8hdZqp3u2gbOZgUypFjzSuRAAmQAAkMQqClJDGpw9NXo4/kFYOK pF2XdCJCZ1KPOU5m2Zy2JzMjCZJCOZK0eS0SIAESIIE+BJqmzI2KbfozjlTX2sTI/pakzZ9ULkqh ZzMbjNKfmyeffHmkEVIoR5o4r0cCJEACJBAQqK2sVIueVh9H1Z3rEJwzqEg6sCS9bPo5aZyr5zvr m0YDHYVyNKjzmiRAAiQQcgK1y5bJxcvWfAgW4w3ScWLG75sriZIC0E5XoL3kC1KbL8yLPrpqtJBR KEeLPK9LAiRAAiEmsHj5Q5di+Lcg3aPU+H4/EjmRRBrIVqHE9fPcx389mqgolKNJn9cmARIggRAS aPLmX+gIc4t03bgORLJvj2VEvqI8XaYNSZN1SAP5+WgjolCO9gzw+iRAAiQQIgLrvMQFiGH9jnBV hdaDiSTcrX7X674xXz/Labx9LKChUI6FWeA9kAAJkMAEJ1BbWysXX//Au4yQ31auc1QQ3ZrfMgvj D9ytWJT0pfza6qq2m85qHRtQKJRjYx54FyRAAiQwYQlsn3JxZPH1iUsQuHOz47iHatsJpJ9IIqAH Iul3aaO+t7pq4U11rfX5PbVGlQ2FclTx8+IkQAIkMLEJ/LazsnRaZvN/OChgDjGcgtZYA9YkJSxJ BPRAOuUPxc7MFyGS/aN7RhUShXJU8fPiJEACJDBxCTS8nDh42mHep5QUViSjOZHsu0llRVIjmsfc mVVmeU3F+q6xRoRCOdZmhPdDAiRAAhOAQINJHBo9XFwtRORqiKQcTCSVFUltRVLfqVT6szXyyeRY HDqFcizOCu+JBEiABMYxgSazYEbUz16rItGPQAhhMQ5iSSIFBD/PoN/kz5TT9fk5Y1Qk7TRQKMfx w8hbJwESIIGxRgAiWaW09xXllrzTIGjHCmX/TbnIk/SyHUbLH2QPkrU1XU8Oe/PlA+FEoTwQejyW BEiABEigl0CTnvsmKbyvKyd6diCSpr9I2gLnViQzbXC43iqmZW+qaVs/op1AipkuCmUx1HgMCZAA CUxgArW1y+Sib6+KVO+HiDWZuWcr434NVXXmDCqS6ALioAuIznS9Cvm8qdpt/NZI9pQ8kOmiUB4I PR5LAiRAAhORwD2oSL4h+v4muaClWq59Ym9DRJusErFNvQsdQK5HwYDZOZHsW5JOBq2ySlDgPL1J OOKr1bLxx+MJG4VyPM0W75UESIAERoDAog2r3qh8p1YovblFLVxaJR98bbDLNpvE0XKHuRxC+Dm4 W0tRVQe79RdJJRDUI/yu1NNCmevnycf/ZwSGMKSXoFAOKU6ejARIgATGN4HA7XrdA59EEYDjYFce lzJdH8HfX+0/qiadOEtpcZUbLXm3DdhBEfMBA0dnEPRiRu3WrnSzVvJz1arpj+ORDoVyPM4a75kE SIAEhonAouWPvEn54n0oNxdYh1rrK5tkYi3cpY/ZSzaULCl3O7ZfpJS41omWHI/AnAGuVrufFUm4 Y4XOdj0MHf081iT/NEy3POynpVAOO2JegARIgATGBwG73uhsy34B1ckrkOQY3LR01DRl9PJmc8YH hIhNjqSSV0AAr0TQjuNnBy+iY9tk2YhX3+u61+jol6qjazeODwKD3yWFcjzPHu+dBEiABIaQgNrm vs0Is1gp1VtJxwbiCC3eqmVpLezLmYhcfVvgavXsemS/rTuyFQ1AOnCeexxHXTfHXbtlCG9xVE5F oRwV7LwoCZAACYwtAi0liSnCN1+S0okFLbC6t6BggEIRukjJx3MCOXjao3W12vQPryv1v1DWH2Un zbx1ftcv0mNrlMXdDYWyOG48igRIgAQmFIGODnExHK1nCkfaIuV9x4Z0Dz+zZ80LXK0wO71M5x+1 MrdUq8d/J7oenzB8KJQTZio5EBIgARIojgDWH49CUgdSPBwn35rc19ly+ZEoIpDNtOO4ezKuqq+R TZv3ddx4+z2FcrzNGO+XBEiABIaQQG1tLdJB/vAxRLEeEzRT7psGuccrBa5W9JH0Ml1/RyPmH5Q/ 2/7teVWtY6qP5FBholAOFUmehwRIgATGIYFFyx8+VfqZK5A36QzW5WPwISHAx5jXvUz6MS2cb1VH 168WVeNw8AXeMoWyQFDcjQRIgAQmGoGGkkSsZJd3NUzDKUiYLHB4Mpcfqb0XjRP5GErcPV/ggeN2 NwrluJ063jgJkAAJHBiBWEos0NK8B9Vz1GCNlQc/O3yzMCjx3yFGeCdgHwrlgU0DjyYBEiABEhiL BFpM5RRt5NWoMVeyPwE8wVhQTABrlIdJW4hAJFrnyMYJF8CTP2e0KMfiE8x7IgESIIFhJtBhJr8H grcQHT9QXKBQt2vupmx3EKnggjVqvudnP33XzilfuKSibZAKBMM8iBE6PYVyhEDzMiRAAiQwVgg0 6MQbosZ8BlYhqtMVF6hqiw8E9VyFunzm1KqHhXj092NlfEN9HxTKoSbK85EACZDAGCZg00Hefv3q jyAHcrYtfA4vakGbRP4ISvRAHPGF42xATyCUjjs507nzlib3LRur/T9uKuhk42wnCuU4mzDeLgmQ AAkcCIFFtQ+fLHX2MhQ+V6a78Lk9nxU+KF9OBAMxtN/bfzvB5bKpdvxfd0JYkwjnSUFid2DfTtSt 2yaN6PKyphw6OiE3CuWEnFYOigRIgAQGEmjoTEyKlGSvciKxo2AJYgesNXYLop9JCd/PpiGNrwtf tMOnmsSvO1Dntc1oswtfm5Ujk1qqzdDDndqozeXSS1aZtVtFTksn7EahnLBTy4GRAAmQwG4CtZWV atHTep7UYgEE8XmU1HkdQrkTZuMuWIdtwqhX0fHjVQTpvKpF5BVXmJeF9LbPkY+9HAhhfzG07SpD slEoQzLRHCYJkEC4CSxdIWT7bISqanGL1pkXhYq96sldW+Ox6a9Vda1MhZvO3kdPoeTTQQIkQAIh IFCVq8P6INYRH+wz3MF7L4eASOFDpFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5J AiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJkEDhBCiUhbPi niRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4 K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJkEDhBCiU hbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6A Qlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJkEDh BCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJ FE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJ kEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAAhTKEk84hkwAJ kAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJ kAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAAhTKEk84h kwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAoQzjp HDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAAhTKE k84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAICVAo QzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJhJAA hTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJkEAI CVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJkAAJ hJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJkAAJ kEAICVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7kgAJ kAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGsuCcJ kAAJkEAICVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAWzop7 kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEKZeGs uCcJkAAJkEAICVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUToFAW zop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQOAEK ZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRAAoUT oFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRAAiRQ OAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRAAiRA AoUToFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodMAiRA AiRQOAEKZeGsuCcJkAAJkEAICVAoQzjpHDIJkAAJkEDhBCiUhbPiniRAAiRAAiEkQKEM4aRzyCRA AiRAAoUToFAWzop7kgAJkAAJhJAAhTKEk84hkwAJkAAJFE6AQlk4K+5JAiRAAiQQQgIUyhBOOodM AiRAAiRQOIH/DyZF8HBGRPL0AAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image008.png" Content-Description: image008.png Content-Disposition: attachment; filename="image008.png"; size=3141; creation-date="Wed, 10 Oct 2012 09:43:13 GMT"; modification-date="Wed, 10 Oct 2012 09:43:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAPgAAAB5CAYAAAAUPex2AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAvaSURBVHhe7Z0rkBxHEkAXHjQUNDQ0NLtj3p1z hA0NDwoedIQ1u2ILFwoaCi6U1Q0GCgoKChoKHrQrq3v3Zr0zWZ+ub/dzxIbtiJ76vKysT2ZW1sUF /3RN4N8347+O/672w8ur/fj64W93Pd7trofD8d/V9fDu+JvHb/fjL8dl7W7ef9s1HBoPgR4IiKJd vfr9J1FEo7D35t8fzb//LPa3Hz9PE8T4xrbh1/Hy8mb4rgd2tBECzRCorsgRk4bZMfzxoPy7V+// 8/3Nu6+bAUpDIFCTwO7m8EKU4up6/G1SlIKrcs66zIo/9+nlDze/f1OTMXVDoBiBf94c/iHbWzkX m63up9UotGOymCevt5f74b+c64sNNyoqQUDOqjtjvJq3seXOzTlX6IVlG4X/Iiu8GPRKyIA6IJCU gJxDrVJb49RKtt25+mG388MtW/mkQ5DCUhOw2297nh7elVXqZy6w2ycuMGN9/7sr7eH/bXuPXGqP /237YMrdjx9K9kW8A+LmE9tEavlQHgSiCMgWfDYofcmrDMNhqmd8LQpa0lotdUmdsiuR1XZW/qy7 EztRmglIJs4owfAjCMQSyLkFF+NbLUWO4WEnOLNLmA2Hyf3z03ndTCqs6jHi4TchBESxRflSrtRi YbZlrsSH/OPN4assCr8f/ieTSMmdS8jY4NuOCaRUbFmRpmi0YRM+4hwKLxMiRrmOFaqVpttAFBOe uXjFFkuxOTsT3nlxIUzFH54oDuAepq1oS0ftmBX7bjdtC+N81+a3stIwAM8LXlZhe75e7E4cDvjU O1KwWk1No9jGtYT1N1iE1kpvL7PYI0zUpCqWd7buwei38YMpMCVyxZ6DNTAApRkrl6/e/yx2iihF tzun4Rb3WhpZdF+KdfNEx4WbYBATW949hEY7IHHrsYou3gmZKBrtGs3KTUCsu/EGNM58ueVzXP4y L8ZwYNteUloN1DWFaMZcz0Sxa4rvUdHjjlJ3MqnXbD91ZyYwW20jYsVR7MyiCSo+1hhqJ3UzuQdV xsftE7AXQaKMaCh2y9KNjVMQ9yWrecuSDWib3dYF5jCzRjeMZwGU634637kPuvkmMiZGoa7cFtc+ JSoM8KviYlnMvGYBwbYVI2+JqqvZZuqOJDBnIPUPmDB3n7G2RsJu6Gezd8SkivYPlpEAGbbsDQlR a8okYJvi10u57QqP4aUT6fo30/rQAxJWiAGOcFd/vlW+nIJW/N1f9pom94yryKpUpfO23Tv8VXZ+ pdpGPQEEbKofX/+oXG7AiBZAt+9P5wQd/kY4s/KzZW9E5tYFdj2+9d6Sc95qRHJlmzGPE++zuXhe uFtQVkbParPJBAJcYGy/KgusgeqDPCtmp4fhtZLQ5Ozsq9xiSMOAUklQDVYbsmWXsYO/vLAQZwH5 ZfUUSyqGtMISar+6oC272Haw2ZQRqmyZAjKA3HEvuIxceq0laMuOOzWvmO3rmx6RaXZbxV3gvMJY UemBO8JfVtT1droy+7id/kzrB+fh+nYE10lLAg22bzrpVh/NtC9y+vi4jdUT10YfMm2xlVbJ/Z+e QslTCNEm0fdQbvyWKWhThthsfB+3wO26cLxM72G5EyGKchN5tBA2P39CYHqDzX2fQSIoQRdBwNug ZrZUWMojAPMTJwG5Suqj5Bh0nSiffhBg1bxHuQPh8nkQAZvC2bWLxE/uz9TXminnJP9S+RIC8QSs kde1XRclx3ujQ56ii9x3uVHu+MHKL+MIyLVTl5JL/AWx6wpfn1th4saIExG/gsAyAjZxp3Mlx1V7 krK8/ewB7wNn7mWDlF8vI+AzTiWhI+P0iLOXtdIEseAKWzY4+XUaAj5+co6RM+v5VUk1f5qcbYhQ SzM4KWU5gSkYZnA/oLH1yynTnW5HDjVJbWtyrS0XCyVAIB2B+TENPQ2UGbubNrp5zYLcw003Kikp KYHZpftJsx1t9jzuc+4mDDDpeKSwDASml3P0xzU2dx6fnppxxpjfZZAHRUIgOQF7IcrlPtvKedwa KOTtLw2ISbOEmyH5OKTAjASc7rOt2JKcLgYDAot5xpFI0VkI+BndVu7q9Qn34xmhLOOPQgsQ2PR5 fNOdLzC4qKINAj7n8VWm8HY9BLdZd0Ib45JWJCTgOo9LgpJV2ZjsnVrVqLbxgICEg4ui6hPwPI+v IzvrZDXXo9Xwd9cflLQgLYEpaYniCrb3xw8v0tZaoTRJTOfwEd5XaBZVQiA7AY9grr7HvsxQ2ixm I4DWMItlHypU0COBOebjoxrKaoJkeuybbbPp2L3WOZnhuu0cDYeABwEbtanYn+T42qXBzXUNdHWW RA9h88k2CbiCuyRFc3dkXE/7rtIX2J2UaHAJAvO16PPPbvWWsHH1xoUSo4I6VkVgNTox3ZFV3GJr cQ+savjRmRIEXLvaLtIuu6J4JDNlCZjUAYHWCIgCd+0ydga1mMSJXVoMWxsptKdbAkbB36hK3vLj Ca5zhgTidysZGg6BBARcsSHiWk5QTfoiXKu3nD/S10qJEOiPgPMY2+Iq7rrrzerd30CkxXkIdHkW 1yyErN55Bgql9kvAFeXZlEXddcmd1bvfgUjL8xDoahXXkjl0G2ubR66UCoFHAl2s4q6ZiAsljGgI nCbg0h0xxlVnp81CrN7VxUMDGifg0J8vVeNG5N0lR35zotYaH2A0ry4B1you6c6qtVDN1kLMeTW5 UHFfBHbXw+HcQinv91XrjTGufVZW8Prnh2pkqBgC/gRcMSRVsh65MlVs+tlUf9nyJQQupiysWoLG Che0tKB5AlsYtRAII6BlfZE3A8JKW/i1K+6cK6ELAfPzzRFwpTiTHXMxKLtfx0vNes7jgcVEQUUr IuCwab0p1lU9idxwKNYQKoLAighoXilJMV7EJ+4yCPBKyYpGHF0pSsC+hqKkWC7iE1ffGTOWQMnJ VpQKlUFgRQR0n/j4W/auiuO9Sad89p5TAQTyE9B84rJNz9oCWZ01f12RLUTWHlI4BOoScOlY1nvi 6r1vsz0vYgSoy5/aIZCdgLZNz3o70/FSaJvJ4rKLgwogkJaAak3PGZtebWZJy4/SINA0ATXoJddO 2eUey3o2aFocNA4CaQm4dC3Lu37arJLdupeWH6VBoHkCqrtsP75O3gHO38mRUiAEzhLQcy2MH5Kj 0/zfWS17yXtCgRBon4DrOnbygDLZhp8No2vxJYb2ZUgLIaAS0HQuaSpyLW8U529GKQTyEFATMl4P t8lqdTwqiP87GWkKgsD/CTj07m0yVtpMwvk7GWYKgsATAro//LmhTW6jyW+Ck0NIyhjO34w+CJQl oF4ftTncJBvryYysz5NDSJola5o32VpkFpC/h9hy3cB2eFG229QGgXURkBVXdsKza+zuQXFVvdPu jZ9K72RW6LfqIwbnCjwxIawLP72BQF4CsrhG6d4JnTyboNGV9C20ATIb5cVC6RBYB4Epien4MVTH Tn5vJouzVNSztrIleFYRr5qsY+TRi2IEXIEtXsrv0juHWf5Pr0pkItBmkWLIqAgCfRGQ10S9dez0 gqu7rOWJFPWFBY9VXLYaJH7oa2DR2jYION8bcOifV3RbtLFtrjzYB9cGW1oBgSYIqFmTFAX3fqp7 ibFN8qU3QYlGQKBjAlpgWZLHPmOMbTKDVHkFsWNB0nQInCIgehTqAw967DPG2MaDBwxWCKQjIPrk bXDbB94PDza2hVaQjgMlQWC1BIw36oOPkkctrkHGNu6Dr3aQ0bF6BOw1be3dcOuSjnxNKMDYdlcP ATVDYN0ETCalW8cqHn9t1GVs8zbNr1sG9A4C2QhMGVbHz+eUfFGGVZexjaeKssmVgiHwSODsbtoo /iJMmrFNkjAuKpwfQwAC3gQkxuTvq3iSC10njW3mYC+X0b1bx4cQgMAiArNv/I9jJU+ig6e2B0lm jkXd5ccQ2B6B46eFk+6gj41t8t9cJtne4KLHbRB4SNGU1P71xNhmMri00VVaAYHtEZBteXLv1ZGx Ld7ntj1Z0GMIZCEQFHfu2wJrxTNB8L7f8x0EIAABCEAAAhCAAAQgEEPgLwFtWcp/o77cAAAAAElF TkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image009.png" Content-Description: image009.png Content-Disposition: inline; filename="image009.png"; size=11768; creation-date="Wed, 10 Oct 2012 09:43:13 GMT"; modification-date="Wed, 10 Oct 2012 09:43:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAPgAAADnCAYAAAAzUZtFAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAC14SURBVHhe 7X0JYFTVuf85597ZEiIZEBdUarFVglFftQQSCdqK/VOgajf11S6vdlPbh32v/yra/hOSLq7V6qta l/J8rWtd2oJUxGiV2AwhggtLLFoqKNgnJBMMyUxm7j3n/zt3JmGSTMhNyDI3+S5KSHLm3nN/5/zO d77vfItZVVXF6Mp9BCorK/iJS7aZp4VaTRaOGizOzBhjplTyY4ILn2TMFowZMimPZ6Z5OGOSO2+l 2ETG2UellCZ+oJRinAvWxpVoZEwkmehqx6US7cKQW/AZi3HBJRMtBcp6MxpnSdzJNqda1va/T5eX TH5Ef0+XBxAwPdDHcdXF3kQO+VtZ7MQFlWs+JJiY0S7VDLVfTGNCnaipCqL6leLgsMIfUNgQJlMS XO+6BH5hYhFwfsBTtMePWJKD0vofzvf4MCgtmc0stMHPQW8sB21MJf1+sUsx+Q5vNt+eHn73n/XW vC1SWHuxYmyNx1iik/yXHr0g2dhYjbWGrlxBgAg+yiNRVFQk7tke9ofjLNjK2IzeRI6dKDj3MwXi QmKDhz5ucFA7NXQOQ9MkdQjsfJPxA+efXTxOkVz/L7gv89VTvHd+E3C+4HPC+SHWCyUnMalOwc+w S5A24zIpFFYDJZM+v9qDxeEfRrP51v3Nz78qWdl6Kx7dycLhjvCGaLK4uNEeZYjH9eOJ4KMw/JHC i/3W7taAGdx/dGRTcq6fq7I2xc4EkaeCVlmIDIKCRQ7rnP/wxx78LjnF+YxFoA8MDrQA0yHW8cfA VwPN/VhiusivpH0SBL6NHyWwT0j4fZN2sHbZ0DZj4saIKqu3guytaDSamDK1IFnast4aBcjH7SOJ 4CMw9JHCEtPabQZYkB1mSjaLN78zz+dn87hSHwVhAmBbgBvYReu98RASeehe7cDC0rWl7yb+QX1N fM5DgpshJdSpSspibBMuEZIlfG3yvSnBwgbWrDZG2Lx6k+1vjIeCsfKOuvjQ9ZHulA0BIvgwzQtN 6oLdZn4sZP6L2GuVmj55lmDGx8HhEEgc4EKYXBgpQkOHBiF6bKRddsyRrKlNedc2O61np+7gbLsP IqOzSHL0qeunLiS93g10qgqpz2nCGwJ/BUH8IN7xMEj5j+I9vwhbXUKywF5/TD1Xz+c+kR+UkdaQ FYNk17o8XUOMABF8CAFN69NBmLdPEHvl4rYAuxAq6wmY7wEYufzgdIqKaTIrewC71dQWOc1VzZ1U x6VtpxeGlJkN97eYXisck7nTHBZx/CT7hRWG6S33gcu5sXL0c72jwM7C+V2K53oxSqkKXd9nvW9a pegyD2jCC9gIeQD3DChlFChpXcqVvLitnW03YsZTEVbyRytkNkJvj5HePnSTkgg+BFhCWgfMZrOw fpNcCJPUZzCJz4IEy2dC6AmdltISZHShN3cjsrP1TREZti0Yu0BdDqOVlVSC2zCCJyAdXwWdkjCa wf6lbPBoM+cq5hjFuQDZ5ZtYWFq6v6ZeA2ADt+Ux+OuYVNuUGIb93cBnZoLeeVyxPCxCM/EsP+6t FwI9X7Q53tl9pN7tAPFTUjybbt+T8HrxEOixmID2p+IIr8jg4gq+n73eOnPyo7XqrGfDwQnvPjZ9 e0dVYyNZ5Q9hjhLBBwmeo1fHpoREbN/HzSZ1kVTqXIi7o3AmlScg9fTW2+22Wx9MO0YsTRhwWP+F j2vrs0NkEC4JYm9Ugu0ED98RQrwMiu6wBHuPxXhHOMxVNMq4/ortrl5FwLLp+LKdrV6yIFlVXZ3V orb5jSKjdW4BiJtqm7qmMyu208eiDpGhUDA/3uZoPPNDuOvJWFwmo3en4Ph8Gh4zVVv18VXvBHwg rMGNTrWjc9ue3ZiHxQqGQs1djnVQ+PDuhVhs5gGBEp9MtO9va1q74LWJK2t9Zat2hqc1X9JCZ++D mapE8AGipqW19b75Uf9ettjPohfi4x8BM/MwsVNbXUxc2c/W25HKIHWndId+qjfVSZAaEpm/CfX1 NdxpB46pNqSIzEFkBiKHrdbQHnt2pr6ah5Yd+L/zq/63c613/i6tTn3Ndjlb4Ra9kGS2cf6dcO53 4NqLf256sPniZ6afsF0UxEwfiyszCmt6kKmZ2FxMBU8/Dkk8BwtQEdoGsML53RFeL4RazcDlLHIi iHUiCAwvwHHg//HZ8kcnRN9+OKLm/ZZNir9Nunqfw5n1F0Rwl3hpYrPm4Em8WV7uE/JCTERswR2d MiWpMUn7vjBxnUNlLRRTExriS1MRpJbvKSFewuoQidusgVnNb4cnTO/ok8hdBHbZ8SFs5niwtTg3 7Miw271fWV3B599Q8ySkvt8MGYezZGIWN8Uc4DK7L8JrCd5rO693PSpF9vQiGIJ8n477XCVU8uuy yXg4wsv+h02ytoHoo4jEEII6zLcigvcDsD6zZs27Z2hic2VdiAk3kZum4WYLntp6a1LrBUDCoiY7 8LkmWJvW20KthRZcz1n+m6FgMM42bE/M0hLVr+kDL1IPTd+0ChCH1NfHXh9U/qziH/Ovr/lTNsID iJkgL4jL/antvMamh3OOXgad04XUogl9H2qAMVUo+0r8/Ouq2fd4g6/s3lBrdEtxXiM8dunqCwEi eB/IQGKD2MEPm83vXIFJdQmkbyEsyoaW1gfdgqe2mXpaYuJaevbGIJK24yRsBf7/SwFveTUaD8fh 190xq9PpQ5O5eOxM0qoq6PwdIHtWwrNjlK0WQbJfJJScofRRWup4wZHojmTvcXXujnQ7bN8nQXf/ hkzIC9sD4acjcs59VlzUl+fVtY0dBIfuTYjgPbBMETt0vGhKfhMS+0vYPh8JSWMenNipLbgmtrZ2 YwXogPyJgtB/tg3xsN9u32BNOrGttOWR1Fmv1m9bhm4Qc/1OPQkfObzkzeRu814zxGbA3/0CEHYR 4+oE7SYLad1ly0g5/Ry4UkZLqXE2YJcrxBHhxXCZXQSnobUNcu6d74Xki+d11LXnOh4j2T8ieBrt zUUVRmzbXz8smtu/xWTiS7CIg9jCpydUnxK7S1o7x0AWs604BPcGxcXDCSb/DAt0U3nHS+2O6t2y cSTHNaef5bir5rF96GR9JFzyakHUvAmuuqVg72eA9aexVB6pfQf0UVw2qd5pgdexNgik0040i3FC OG9KG3smIkpu2h7d9uolk1tcnEnmNExD0jkiOGCsbS+aaG56/js4pvkezq+PgnwAsUFtrTZnu9LE diSKsuNc8b/DUfMpW1iPWfEpb4a3b2+brfVpD+nRQzKbBnETx1jGHaPdqs2BRc9H49EK02YLsCae B8n+KXB4AgJrtL7Ta/t+gOiwjBi+w3Cu/wXEuJ75kfCM5Q1K/Oqpyvnv93VEOIiuevIj45rgejtu Rs1yv59XIkKqhBs+fbzTP7Edw5DdjgkG67d5b0g0/aU1XLDfmax6+z2G9OmRnNXFHatiIHqs8pSi B+ZvDz8ZbFMfR8TaFQB7AQxz+SA63AyyEV0H38BhT+tJwpwKD7mrpGVfsKBizU21ibInxrN+Pi4J XokQzcVbw8fyZvYf8Cj5GnTssJ7IfbqOdkrsTmIzVQupfWcyIV54+oZPtjo65jjSqYeb9Gnvtf3w m3uhNlD0MouHT/IrdjmT1hdBdEh0+LlnMciljt4cq7uf+0SxsK27/AH5uQY17+fTw1NfmTwOnWXG HcFr28vyF2xiF9lK/ieIfRJ0OFOrz1ldLPskNn8BUuED7bhZXlU33PN9XN+/vKNxv7Zr1AbLlsDZ 5y7EqV4GW8f5kNaTHINcNqJrQ6ceO2HmQeKfj9OMuW817Vy+vaPsV189I/pu4zhyfx03BNdGtNbX Vn/M9KsfwodskTB9+Snn6yy2GBfEHtesG4WXR2ipNlZuqA2UXRmM+35pK+ub3La+hKOzw7VE7+U4 k3aa0ScbWMgnK9v+vu2XC+/fNPHW/Pyih4o7xsf5+bggeK0sm+zfVHMpfJ6XYLSP0cZX6HZZpXan XzgmRBz0X2sIfmc8BIndUbfPCbWga1QRcIjO2ZYVsaJrpwTDy7FXv4JL+8swjk7QpxWOL/+BYNeU Iw08gbWzjODGyThau7UtFj69gZ1z/Szx3Duj+jIj8PAxPWUrKyv5gsqnT/FJfjMGvxwRm0EnVDOb W6mzpcOOz0L8JWOvSiFuskJy9RxNbLKGj8BUHNgjzkt5sG2CRP+BGRMrTCb/L4Jg5mr9u69tO5xq tDRHqKr9bVvGTouwORUFW/e9OJbDU8cswSMlJeaCymc/C1H9UwQm6gSFfRrRUuetmC5Wci/8y/8b mQxv/3Pl/F3j/YhlYJQbndbprfvTDfL0dVL5/1XY6vsIT5sO/RvuxNrnP8NZRm/btbXdSbYhzsSC 8Lu2meEbYZe5b6xa2sckwbGqT/CvY1fCR+UH0LXDTrSSs3XrfnVtx6WdQDjmS1LwZVaINehUQrOq yXg2OpQd3FNniY3RyKSSexLN5hpY3L8Hcl+K8S1Ibdu7BwLpuaCDWQzTNxVb9ut8fntOJFFyTal/ /duDe3rufmrMERwDdbzfZjdDIi8WphlwXEd7JiHoclTRh97WO5DaNwoee2g2Jgltx3N3svbXM8dD TrC3NrcXXdMaDK8UUl4LF1hn297TCOcECznS3AhBEFyEr0UNVtm11uHWmrGUGHLMEFynS1q+ZeLZ GOBb4O1wKvKDw/bS2xPNSUMEtzN4qWmf5Uel4buFheNvzG7ZOID8Sf1NNfr9aCKQjjB7roGdvtGS ef/K7ORSpIs/zlHTegSzaOnuuLwa4jTMl9+JveattfmLbivvWIUs1t6/xgTBNweKQvWbwl+DRfXH 2JIfk4rPzkZuHccA33JLbpZc/MxKHL+yPO+BNnJS8f5EzvYGndt2hK02IILtekjzs3RijlQmmQO6 eWfIKqIFEalm/9jfFp3dYJzzvVn8uR1eR8bzBK9VRUf42wurYSG9xDB8Exz/8V55wbSvMqS2ZdnY mK1KKn51zanRbVWNL1G+L6/P4H7672y3OWtoMMq+ail+lbDtb8LGlofglOwGOMMM6OAV246FIsa8 75fytZu9DJGnCd6gyqYhMOEe6NDnIE7YTG3Je+QAw7YMv9PkbsMKfvsE3vKLYrOxqRw5FegaPwjM 4nW7aoOLrjFjTRuxZa+Gzj0t65Y95dOuw3/PwU7wNw287LuzRN3LXkXKswRvkGehoF7iDjivnKsH JJsfecpKjkzclrUDCUZ/mAiZK2d3NFKyfa/O1kPsN/Tq9qKTK353z9aaRr/Elp1JbNlNJIrpvWV3 bDXCKLFs6wGkdP5uqVj/3CE+flQ+7kmCoxxOsZCJ+zAAszVqvR1X9ODowCOdzJC/iGykP3h62YJX 6Vx7VOZYTj1UF0cs52x9gyj7iqVEn1v2VLIJG4VaAych3fXyelm25M/L5q/w2hzyHMFB7jOExe/k plGSPcVPeksurRiIfZ/BYjfO5hvfLaVz7Zwi2mh3pteW3TCn6eQePR1jtE0HXq7TQPL7EH66tGnf xb+d7KHyyZ4ieESWnYlcXvci6WFRLy8lPWO0vo1tuW0nUe5WVRcEP/JgcQes5HQRAlkQ6NyyL9+6 +m8QGnfDwn4q7DTdj9LS+QGE6T8cno43vxXeOemv7Yt+dV4eYtc9cHmG4BFZ8klk67jTMP0nZbWU p51XYGh7E8n4v1dwSstzxY0PUOlaD0zC0eyi3rKXcrauwSy7yLbkvXCRgGOMVu8yDlgcf6gkJLmJ PHDJyqOCLUfCW3IZPB73j2bf3TzbEwRvSMz5DGpm3I4z7uOzkxtWTyeLqb1ZGvxbpbxuHSMruZvx pzZpBLBlfwPHYt9A/YmbDO0Fiewxjhdk1wWSo/QUtuv5KDTzXR9y5daGyiodX/gcvnKa4JWVFXzh j9Z8Dt5pt8Lb8Lis5MZq69Tzs+11KKCDc8u6+hzGm7qWwwiUirXbEFp8BWZUEyT4l0FyX8+8fCmS m0Gc2lxhtsmWyL6Sm0sn524Rhpwm+OLKmnNRyucW3ge5na2UtnZK/leQ+1uloo7kdg4TyAtdKxd1 uxCZ9gPF/U1I5/U9TeaeLs/6e0jyPGEnr2ITRVOksPC+0paWnHR1zlmCQ+cuhc59O3Tuadkkd6ee BJPIyqTgV2Jg/uGFCUR9zH0EtIvr5kBZVVtMNMNB6kcIWsrvTXJnu36YbVs/Zc0zWitP3vdwLlZC zUmCQxeaKSzrNp0zLVs0mBO/DYdykPsPSZ7/H+XjIDNH7tNibPWwGAY06Ni3mm2sGZ5SP4UkPzyb JDdMc7JMqhsWbgq3IuPPilxDIecI3iDLjuOW/Uv4l85K1afq7i7uZF3RVe85/63BOq6eI9btyTVQ qT9jAwGdFwBVWH4j3xdI/GjdqSV29xrv2rqO7boOcLKSt0cSZc2l/rqXcuntc4rg8C0/HCVob0Xs 3nxdYbdnkoYUuVHvC+RGDaAflouNTbkEJvVl7CGgg1UKj6h49JnmmkmQ4NfBtTW/u1t0Ko8+SP4h Zifuha/GV2ALyhnf9ZwhOKqL5PuCrBr+4+dDv0bu+u5H2I6/uU6gx9iqJGdLy3kdkXvs8Skn36il pdr633jRfUcGwsjOai0FyQPdSO44w8CtVfhm4Ajtjlo579JysXZLLrxMThA80nRxwAzvXAonoq9D SqPQXw//FC3OdXltW72oDHtJOV//fi6AR30YPwjoJI+17Yt+4QtFJ8FV8jKdpbXbPIXw0cok52aJ T1q/quVlF0EIjfo8HXWCby4qMuSWd79pSn4l8uT1OpLQzHaiwuDEgnPJK2bzurfHz7SiN80lBMrz VrU2qHMqJW9HZlb1VScfe6Yw0vYiqJGQR/P8iv8IqZ2XprO/jtprjDrBW7eEzzGVXSnMQIHOfdjz Sidq2JkQ7DvY9mwdNaTowYQAEECWl2iDOv3HtgpMxr78M52qYyc4TgooXVpJyq8f6Q+/WlFZcX+1 Lm01SteoEjwi552AsM8bQe4p2fKnYbeufYD3MKGWlIt1lOZ0lCYJPbY7Ajgn39XAyv4d57QTsMH8 hKM/ZmQR0iTH3C1AcMqyT1fWbCplbNSMbqNGcDjr5/naEtXIRH9aapvT4zgM5EZ+LDjzG//552Wf XDG7eh3NM0IgZxBAlpcdKGp4BU5sH0DCxjN6hppqoxtIPo3b9s3Qxy8cLX18VAi+eXORYc4U/wZd 5YL00Ve3gUtVGLE6QPmfssOTv/dakH3OzELqyLAiMIuvfSMiSv6d2cajyLF+XE/Lut6Xc67K/Upc i+KJS/W5+rB2KMvNR4Xg0ZOnlPll8hrU487rmWrJ0Wm0I4tgv0ERgjvLW9b3VsxHGiV6HiHQBwJI 5RSpZ3MqlZ38la5mmml00zkLUL0W+rh9qdnKXi06rei3I13ZdMQJvkaePmWitH6C7cux3cPxnOXO UWeQ1OGvnHdcV96xcUzkpiZ2jG0EEiHxKMJHTweRL4eAQsmkA+qmTt+t9XGhEtXLt4b/gdjzF0cS jRElOPTuYGGcXas4m5tyQ+1uXMQKiK15Yo8Q9tJZSLM0kkDQswiBwSKgY8JhdLsekY/F2Hme3dPo 5mxIEREJn/YbNhtlXyjmdSM2t0eU4HDcvxAAXOoUhutRmMDRu20rLiX/+b+d0lrfSIGfg51v9LlR QABGt10RVraU2fKxXvq4rkOf8sIsaVP8h7XBo64u7/jniOjjI0ZwHInNZCz5I+gkcNjvHjqb0rul wpdH9/yTLR9pPWUU5gM9cgwisLrq3PULK5/pQx+XequOtEPWV4Ox6auY+OeakYBgRAju+Jn7k9dB Sp+YTe/WOagRXP+KUKryvGPqPhiJF6dnEAJDjUBVVZWqDRxEH9dGNy4KbVtehaOzDSMRTzEiBBfm 5MWc24gQ05K6p/R2tuZ7lZA/nCXWeb4W1FBPGrqftxBw9HF+zvVSxU6Bwfisbvq4tjnpqimMzUUF 3K9VvlF0W1Vx47AmBh12gusQUIPbS3seIehhS5+BJ2BzvLng5H0vUqJEb01m6m12BODOuivCS64R tvEnxKRMkeqAUEt7uQXglv39xTPDK3GHN4cTx2EleCUCSRZuYd8Ak09O1Qw7YDVP+fBiy8L4qgJD 3V3cOLwr2XCCSPcmBHoiUHBy63rEWdyGyLNKZCbqFnmmDW4IiT4Ozm7XbI4XfTdd7nhYQBxWgi/e Ev4wom6uQE4rXy9fc33mbatdKC5UXWzUtQzL29FNCYFRQkALrFpWttyn1GIItjmOj0f6WDhFcKQd 4/YX2vwFT6GLTw5XN4eN4Ltw5q3a1VKU9Z2GyJpu/dcvh8wtSS75rwu2RTex4uF6PbovITB6CCAR 6Hv1fO7PcEL0iIFMMJlCzok6M01EUKr/hyyutQhgGZbUY8NG8HfjYi5s4593nFcyDWtYyXAqiD/y laSPL589zEaG0RteejIhwFgiKJ/3x9gTcHb5CtRSOGlmVkyBJFf8FEv5L2+KXnzdcNQ8GxaCw2Nt gq/NvgqpbQqdGmIZF/KtYaditZvCuKmUv7SbJgEhMJYR0Fb1CD/rZq46Psm579jM8vU65yD0c8OQ 6jvbwjufQVjpkBftGHKCVxZViE9tqvkyygDOdQYuwx3VycyiCS/ZmnhCPsPyxvLQ0rsRAikECmae tbV1S82vUYe8l8HN4QfnU7mtLkea5teGOuJsyAm+eEvN0TZTV2BlCvXKigqCQ/XemzB8PynPW0uB JMSAcYFAcWO1XcsX/drHo4thautlcNOJTbiyzjPj7C4cKw2pFB9SgkcKK0ze/Ny3oWYXpSR3xrGY Y1izLWjfd5vh+OusZVyMLb0kIeAgUM5XNdXzsmXgwOMwuE3obnCDXs5ZWNj8str8oZXiQ0pwM1pT aEv1BejeyIyaaTnXKVEdvm9LGuLu8pZ1OVnHieYiITCcCCRC7EV/jD+CTEWXQl2FZ3aKI/qrk55M WedDiv96KKX4kBFcZ2mxZrIvCs6nd7K5EyynjphtdzAhbynn694ZThDp3oRAriKg9esGa95/SZE8 X3u4QSfv6qojEIdBig8ZwdnJ0wu51XQZN33BbtLbOeCHXU3x10yWP2wH+rk6qNQvQiATAeuIqW+I 5p2PIf7ispGQ4kNCcKSG5YsqaxZCUp/YS3prl1RIb2HIX88Sz0VpuAmB8YxAacsjiQgv+z0q537V MMSE4ZbiQ0Lwc6+uyfNJ9jUhRLDbQX7aPU9Lbysu/kTHYuN5atO7dyJQEGQb2mKsBlL8gsy86l26 uEyeH7R8d6H9+kNFbUgI7jflfLikznb8bTOMa07nte7N5d3leeuaD7Wz9HlCYCwgoEsT1/M5dyjJ z0WNBBQz7KGLCx6WHcnLd+WXvX7MIWZiPWSCrwgclXekxb8FMk/oJr3TI4FjsV2WIVaPhYGhdyAE hgqBRFBE/G3s2YNJ8e04Fz+GH5oUP2SCHx2fXgzHlrmGPufOSMWUruONc29+vxm23qdz76GaGnSf sYAALOpt9QakuN2HFOdsol+xzz4YvviVS1oeSQ72nQ+J4E2FFwdk047LENN9WE+vNd0hZE7daQl+ P3Kb07n3YEeIPjdmEeiU4hCMvXRxBGkJ/PzzJzbvuQWJSgcdaXZIBN/euvskkPs8hL3x3tJbWgie ecist95j8KKnixAgBLojcDAp7rTk/DgpY5+oXFbx2GCr+wya4JHCElPstRbicH4i4kG79Rykx7m3 vQ9pUn9fWkrSmyY2IdAXAomYqPf5ZT1cWBFthlDqzuAsnRSCsaAU6vNnLN2wEidQscGgOGiCW7vN kN/PPwcpDbfUHqmYpGWjs48nQ8g31TGYbtFnCIHxgcCz18/fv6ii5kkw+0z4qwacaMuUeuu4ryor eU7YbD0GP3prMIgMmuBm0DwVtX1nOPHd7ICKrd1SbewrDM4fGOrQt8G8IH2GEMhlBKqrq1UiUbbS 75cVnJtHZNb60SSHoJxomtZnIpGS/xrMbnhQBIdxzWc077wAnUGxtYztud5i6O8lbwwl1CZybMnl qUV9yxUEzJj1vzxorEHmoy/1dF/F9yaiUr6QOM28D/0dcIj1oAi+Ndp6mN9WC2BcQwmiAwRPVwaF OFdPt049t4211OUKhtQPQiBnESidvL6jXpY9jn05VF6R12XT0vq4geSMtl1shthpeIGXBvoSgyK4 3943C7r38U5S926pkLWRgMeUYCtLW6rpaGygo0Htxy0CCc5q/VK8DT6hxFcGrxwBqvINxS/Amfh6 nIkPqJz2gAn+YOHF/o807VgM7SDEM63nuvwQqigiFezLe0Lib2RcG7dzlV58EAjAGewD1myuQLbV EyHFuwzX6RTLBo6hz5u2e+eNUHvfH8jtB0zwKc17cCzGFqNAKB56IKGi3p7D1J+E7W/V9OnRdqpS MpBhoLbjHYFSOIOhOukTgrMrwKXDkHW4GyT42bGmmTwLxUSeqGps7P7Lg4A3IIJXVlTwT1U8fxak 95E9Sntrax8cbtg+W5grqUrJeJ+u9P6DQcAKsTd8bepl+JD0OBPXtnUZQKqnT8yvia5kxzDXpYcH RPD5N9QE4HH+eRyN4bwu07iW2p5LJl+24tYusp4PZnjpM+MdgW9Pn9++fFPNH2DJOhP5lDPOxHUl FMd1dX44PD3AmPva4gMieDAeP1yxQDkypnZzTdUVE3FAr11a/lBzRjRW3jjeh4renxAYOAKNjdXS FGWrUfVHn4lPyTwT1ztkbJOPbg2ZOqlKg9u7uyZ4ZWUlR3HzM3TeqMxc5/pBKRc7+YGJsNCB6Adu O0ntCIHxgkA8zt7z+fnr2BGfk+m66ji9MOVHeOmczadUbNSpmN1g4prgC55+2mB1DDWPOT7T3TUV ndGOdZFQMLyHrOduYKc2hEB2BHZOnZY4IbpznbLVPFjTfV3C1FGJhY8ze160puY30MPb3WDomuDW a6bfx+xZCCQ58NCU+IY6jnznkkdaQ3uSRHA3sFMbQiA7Ajr2O6Lm1gsucd4Ngqet6WnfdKjG9pzw 1NAEfHpoCR6MhfIla/+Y6KF/p3WDhOlj62ZR3DfNW0LgkBGw4u2v+P3+NsjO/O6+6Y5EnRQTHcXY RD/v5kGuJbjkHcUgc7jn8ZjzvVQtTPDNbh5IbQgBQqA/BIJR2LQ2Q1p3Py7T0lxxn5WUpU37Cmsn T27pN9OLK4JHShD7vY7NAZf9OBDr6l3a9xxh3/zlUDDaRtvz/gaOfk8I9I+A1sM/2rxjHbxUy8Gt LpXYiRUXzMcVK38vNPOXk1nd0BC84LVW33458XScf2fRv5G5hbF1r+1+zyqe3H/nqQUhQAgcHAGt h9ezsrWoSHil5lyXV1tnjLhtnxELqUm4S1t/WLqS4NFo2Of3q9OQSBHu5xmx387ZHEsgBHzdJS62 C/11hn5PCBACKQQS8fgGnz/QDE7nZ2KipbhkagL+PqOysuLdqqrqTDW9F3yuCG4G2Ym465HpKkRd NyH9m6YjITA8CEwPB/e/28Y2oK7AsTgu4wdSkuvzcIYYcX76ktu2rUK24oNu0/sl+OaiCkNuqZkt GA905YvCO3Xq3/jHBtK/h2eQ6a7jF4GdIctiMXOdkBJ5D01/l+tJqiq3oYQ4btuJjJf2U/ukX4KH o9vh/85mQ3pnPf/GKTjp3+N3HtKbDxMCqeiyua9z5zyc+zsfg0IiMLQ5rqPHFry2U/88oYPAtMxd XPXUVORpPDbOrLgZZpv1PfoleHR7lCs/0zGqwrl5+nLOv3FzaYgI6d/DNMp023GNAJKR70Y+Uxsh pAeY5+jFTkKI09vb1L31qlQtrKz5F/DRVCoPtRKk6ee+BxMxVYlGKYJHmkoCIiy+jKUhD47uW5gh 2k1kUtw2yXp9WnsU9jV5BLYJOO/unqQFHLcN5dvlPI8uQoAQGDACRUUVYvnW1acJ5UcSUzZRCjaR K+sEMDoAshZBWBdk5l1IPcAh+SSoxxfqfxi+gGPt1tWE7I421Po06muuPrujvLqOOQTfE2oVR7JJ c7E4fNbgZhyup1g4uDqhyWjnAU1fcRx+1q3zKed3HUZmz2hQ8wqR31XFQ6yx5ur5jgvd7x97jDcO IDB9wMjQBwiBMYDA8vdWC2GLs1Gg81pEaQYQE4okbDyoI7iQ2CV9atWHoVxb38BOO4lATvxDZ2RA yrQtCWa90FkowSH4huu/GF+w7PnVyMnyZeEPTuwks6n5i9XCtqAG9HBh021wby3x74We4LDf385i i5Y9Byu+tO9XE+/6yOGFd01u6d/bZgyME70CITAoBFZf+Wl7fuVfVvqk9XUhDB3M1VWht6dQ7fmA zGKfnQlPFWcrnPRPLanWDsE122v5Oc/67NhWmew41dG1e/qkZum+VveFz3dkSidI6f4CvjDJ2Acd UsiG25cssXDvQb04fYgQGA8IVFVVgUZr30JW1WXSSjyAYgch2aNSkBsctPzWIduGEI9lxoR0GdnC W3bv2zdz8uNcqiJuCJ9KV1jo7+bSOnAM5+gAyQ6IdnH79knHbxhsPaX+nkm/JwTGGgL5+eGnW2Mt D3JpXZqZG93Ne6bzIWp5W4d48rcyMyp1Eby4uNGOyLI/Yh3Q7nGTD+oek+2pjlUdZgHFXrcEu2Og 6V3dvAi1IQTGKgLFHatiET7vemkn5kOKH5/aQbtkobOttxNMqCdrbvhUe3nVgXoE3Y7J9oTY349o 5y9w2/4cVoUM75n+YdXSGwnaY7DA/7ycv7Sj/09QC0KAEMhEoJSv/Tt80G+AO/gvwadAfzp45mex FLxncPFsT9fVbgQ/r6OuvV7MewhWtYVQpkM9q4b2NRyOgm/rIzS+wgo2raaoMpq4hMDgEMjPZw+3 tavFyEG+yOFVP/p42rimCxKssWZPe5+t715NqJejSz7zvbBf2W9CfJ/qWPRcGNtSWV3kO0nDf2N5 R+P+wb0afYoQIASKO+r2YatexVXiDESKHtXfLl0X+1S2jBuCPTRrfe+qJ7092WBssx1jm3RlbNNb cydlE2P3hGfueY0KHtAkJQQODYFLTz57w/2vrbkDFq0K8MvX51ZdVxNC0Di493ooHn4lW7ryXgQf kLEtbVjD67xcYIh7qODBoQ0sfZoQ0Ajo9MnCPP1uJYMLsYUu7Wsn7VjPbaea0B/ZGdvbsgnXrL7o qLDwd9HGXkSo2mcPZmzDwTzsalZcCfnzYr5uQDWTaCgJAUKgbwRmiY176vmcnyO7qj4bn5jt2Dpd TQhOJ3JFX8I1K8HLtbHNKHuI2+rTfRnbUsq9JaGlP5wMiufIsEbTlRAYWgSODYqad9vkg3ADvwxb ddGzVDc0Y53C6cVwfnhHX/zrM5oM6RxfgLXsLRQfT7nP9SpGprcHMKwJdp1eEIb21ehuhAAhcExH XXynMe8X8E+fD2MaKppknI071YRkHLx/WJ+h94VW3+GiW6Mtasbkx7FqzOjp2eYY1pSdwON+WS7q 3qShIAQIgeFBAGfj2+vF3J/gGPpe1CcLplKmpeuHK7YTVrYXDhbN2SfB08a2P8B1dUmmZ5sTB57K C7UWHmu/G57XorsSAoRAJwKJoPyjP8YWw5p+obaJOYS2de1u9dT05sZ97CDJTg+a8CGrsY1DetsW 8qBbPy0X65toGAgBQmB4EYAKvL+Wz7vRL5OlTJjTHPsXlzEp7Mduv/1KCwErfXbgoATvaWxzTsWc 6HP1WzaJRTpD0ob39ejuhAAh8O2ZZ7+K0sJ3wNL2M2zRTVvJdVbM3JKKRuv76jdlU5exjWljm3ad s/4mpe+20pYIgsTpIgQIgZFAwCktbJQtRyjp+fBenSVx9o1S3W39lerul+DMMbaFn4CxrVib7XDj W0r9a7ePxEvRMwgBQuAAArN43d56NrdSB6NI4X/GTanufgmujW21ct4f/TKxBNki6guM6BMEOiFA CIwOAm+Fj31xWvPOy3dGp+44mHGts3f9EtxpGLfeln7+pCV89xbzxpbReTV6KiFACOiyRnBuqWWT u0eN9YWMK4LXXD//g/nLapaW87VkNac5Rgh4CAFXBHdSLwlG5PbQwFJXCQGNgCuCE1SEACHgTQSI 4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5io ESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAK ASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4c N+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHg TQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4 K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1 IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI 4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5io ESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAK ASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4c N+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHg TQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4 K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1 IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI 4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5io ESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAK ASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4c N+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHg TQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4 K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1IeAKASK4K5ioESHgTQSI4N4cN+o1 IeAKgf8PWo6ifxoED9cAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image010.png" Content-Description: image010.png Content-Disposition: attachment; filename="image010.png"; size=8313; creation-date="Wed, 10 Oct 2012 09:43:13 GMT"; modification-date="Wed, 10 Oct 2012 09:43:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAngAAADyCAYAAADeI7itAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAACAOSURBVHhe7d0vcBvX1gDwBwsLHywsDCx7ZbXV zrQwsDCwMDOxrLBCQ8PAQMPEEjAMDAwMDAwszLtnV0pk19p/Wkm7d3/fjOd900ire3+7to/vveec //zH/xEgQIAAAQIECBAgQIAAga4CZ4vlT78uVj/v+jqbL/86n69eNv2aXa5uZpfLu0N8nV8u/246 jqo5bf7tf4u777q6eR8BAgQIECBAoHeBXxZvftgOYmYvVmcPg58UbL3eDrTSv79P/+2Lr0cM5st/ 7lldrl7d87x4+8e2d+831AUJECBAgACBfARmi9snETicpwBiE1CkAOzqXytgRQAiOBuiwfl8+fn+ /VpdbweHEXxvgsMIzPN5es2EAAECBAhMTOC3xdsf45f69sraZkXNSppAdXZvxXB1FQHh7OL2z3hm Ytt8Yt8upkuAAAECBE4rsNkafSxwm81X74a4wmRM4w0oyz8G4kzj6vVmVXCzGvj74u770343+HQC BAgQIDASgXvbpekc1rett/EGCQK8vO9d2iL+tHlON0Hg2cXt03iWYyV5JN96hkmAAAECBPYTeCyI K89R5R0ImN+E7+989TGCwMhETivNz+N7wHnA/X6OeDcBAgQIHFkgyl8UZ5nSKkaxorFeiRPEPQhw 1r/0Hytp0rQcSVWmaZNSJW1eE4FJo3FFENOoVMuEA77tP2bS0YIU+L3ZPgeohMyRf2j5OAIECBAo BR4GcV9Lgkwm2/Rhrbn7mZtRv+5h8OSX9u7vnjjPtu319Y+DdQ3AhyVnyiSJzAPEdSJI/IFUBH8p G1gCiJ/ABAgQINCLwOYXb/ELZlPXLaNfrmleH9ZbZ8UKSvH1oOaac1S9PEoHvch2cLhd8mb93F5v nZFL9zuDwNCW70GfJxcnQIBAVgJxJuhrdmqxZRSHx8f5y/Cxg++bMhgRDGR140ymk8AmKNx0C0nP +tdAcKzPfTHuMpv89easn5XjTo+HNxEgQGCcArEqtVnpKFawRpLkcL+obVm/LP23Z9pfjfM5HPqo N4Wwv50n/Xa+cCzfMxH0RbmX2OrdHB0YurvxESBAgEADgfglFatXRQZfHH4f8hbr18SDMnhTc6zB DfaSkwrMFnf/faSodtkTuHieh7kKvgn64g8kZ/tO+gj5cAIECNQLxA/q+IH9rd3W8H65bM69xRg3 QVwEofWz8woC4xQo/sja9Cve1Hcc4h9a5fZuavWWfob4nhznw2bUBAiMX6AoRZKyNYsyJAPr4rCV vPC17pdkhfE/c2bQr8C3JKbls7KkUFEuJXXPGNIfZkUnj6vYBRD09Xv/XY0AAQKFQFEguMhmLX7g fjn1lyDOg0ngcAKbfsrbmcDDOfdXFm2Os4n+cDvcM+DKBAhkKBCZb8WWTln5/qQ9VstA7ltWnh/o GT5wpjQqge1C4ul78+b0PyOKjPvUr3f5zM+HUT1KBkuAwKEFYqsmslqLrZATBnQPs+2UWDj0nXd9 Av0JDKXU0brEkoCvv1vrSgQIjEUgMu9ie6M80HyiMzdbB6rVhhvLk2OcBNoJxM+aTYLHyUoipWzi 4qxwOsenB2+7++fVBAgMXKD4yzoOKZcB3Qmq6X87KK0kwsAfFsMjcGCB+Hl00jqYWwFfBKAHnq7L EyBAoD+BOIdS1p4rMlyPVwvra//K8gC0rLf+7qkrEchZ4JRB3/qP3uvyZ5aAL+fnzNwIjE4gztAV 1e6LxuDHbPEVXSjK/qkON4/usTFgAoMWiKCv/Ll23CLp2wFf/GwdNJLBESCQn0BRvHS+en60pIi0 Ohd1suIzbbPm9zyZEYExCMQfkveCviOUbFqfU76KP2Qlfo3hKTFGAiMTOPYq3Xol8CaKGdtqHdnD YrgEJiRw7JJOZUHo5TMJGxN6yEyVQN8CR12lWx88Vkuq77voegQIHEtgU8Nz3Yrw4F05ytJOaQtZ a7Vj3WKfQ2C8ArH9ua5Hd9DkiM05E6UDxvusGDkBAtUC2zU+D11BYL3rcW0r11NJgMBXgagDt26y HRXZD9IGbPsciUwxDx8BAlMUeFAD9HAlo4qKAqnLR6pmIFFjik+aOU9aoKgDdcis11RIuNg6SC3H HAye9KNm8gQI7BDY1Ag9QkkpwZ6nkEDOAltB3ee+V+pieyB+SEWGmYAu56fI3AgQOJRAUY8vJVCs e9seakdFsHeoG+i6BI4pUGZ4FfXpDhDUpQO+qQ6dA77HvKM+iwCBqQhEWZZ1wHczK7dd+z5CI9ib ysNknnkIFNmvRVuwfosOr4PE10XbMRXX83hYzIIAgVEIxM5I7MIc4mf7OnAU7I3iSTDIyQmUf+ml 1bS+W4OV17uKlcDJoZowAQIEBioQf8gXnXxSqZReV/aKovKpzaSf+QO984Y1CYEiIysVAu77GzzS +eMHh/Zfk3iMTJIAgZELbJ3du+k32Ft9jN8FiiqP/AEx/PEIrFvlvOn5G/ldBIu+kcfzHBgpAQIE HgrEVm78johEjT7P7RWtItPxHEl0njkCPQvEatr67EVvyRKbljfO0/V8s1yOAAECAxA4RLAXZ7GL igmpKP4ApmgIBMYpULS9iYSGVFOux9U6B2nH+TgYNQECBDoLbAV7vW3jFt055qvnFgk63xZvnJpA 76t1UXQ4aivJfJ3ao2S+BAgQ+JdAdLcoFg+i20VPpVdiRyi2hnETIPBAoPfVupT96nCsx4wAAQIE qgS+BXvLu16Cvai8kFb1tEjz3E1eoMh+Si29+ihEvGk27WzE5B8rAAQIEGgtUGbj9lRua11uRTWG 1rfBG8YuEEFYkeW07/J4Wd38dRTAHLuJ8RMgQIDAMAR+Xax+Lnvk9tFBY3ln+3YY99UoDigQ5x76 qFtX1qpbPrMMfsCb5dIECBCYuMDX40OXPWzh2r6d+NOU4fQjuaGsOL5n67D1krct2AwfElMiQIDA wAU2R4r27phk+3bgd9rwagWKVjJ9LHFHmZS08me1rpbcCwgQIEDgCALRyqyX329pZdARoyPcMB/R j0AEdvumn6+TLq4dUO3nnrgKAQIECPQvEAsP0QVp31W9OLok0Ov//rhiTwJxKHW25zmF4nyedjA9 3RGXIUCAAIFjCUSAVrQ02yN5sCienH4HHmvMPodApUA81PsGdpEJGwEiagIECBAgMGaBTbH+vTJw IyFDoDfmx2DcYy/+WokVt45/ray3Ya/i4Oq4JYyeAAECBAjcF+hj+zaSE2MLOLJ5+RI4uMC6P+zH roFdnFWIEice2IPfKh9AgAABAgMQiDp4++x0bQI9yYYDuJk5DmG9Yveha2BXnE1ImUc52pgTAQIE CBCoE4jt232yb2PnK8qOCfTqpP17I4EieSJKlXTcii06VqTM2kYf5kUECBAgQCBzgagPm343XnVt 07lZ0cucyfQOJVDWseueERR/pThfd6i747oECBAgMHaBWIlbNwL43GURpejqpFXn2B+D440/grLO fWLLvn1X8dfJ8UbskwgQIECAwHgFItBLO2XPu3d8Sv1uU4/38QoY+UEFNkvG3f6KSOcCLpd/C+wO eotcnAABAgQyFojkw8ia7R7orW7snGX8gLSdWtFMOf3l0KVmjwOfbbW9ngABAgQIVAsUv5dTHbxO HTLWO2kSMSb+lBX99KJydssECoHdxB8c0ydAgACBowh0DfSKBI60eKMk2VFu03A+ZL0de9M2sFu/ 3hm74dxKIyFAgACBCQhE/dhOW7fRFUOJsvyfkH22YyPxwt5+/s+IGRIgQIDAMAXid3hk3XY5UlWW LJMAOcw7u+eoOm/HRqkUdez21Pd2AgQIECDQj8B6F+667S5cebxq+ayfUbjKyQU6b8em4sZR5Pjk EzAAAgQIECBA4F8CnevVpt/v0VUD6YgF1nv2rQooxh6/wokjvumGToAAAQKTEojFmLR1+771il4q byYJY2SPSkTmrduLpdTq2Nt3s0d2sw2XAAECBAgkgci4bZ2IIQljPM9Ox5p2iiOO5xYbKQECBAgQ eFRgj0QMSRhDfaa6rNpFDTzn7IZ6R42LAAECBAh0EyhigsvlXZtt26J2npIq3cAP9a62q3ZxE6Md yqHG47oECBAgQIDA6QXW27atzuJHT3nHtU587yJCb3uw8vxy9UotnBPfOB9PgAABAgSOJBBty4rf /S26VsUOn0zbI92ghx9Tti9Z/tP0hhUHLy29nuhu+VgCBAgQIHBagbPF8qdW7UmL5Et1845214oD lC0j8RQEXms8fLRb5IMIECBAgMAgBTp2tLoRQxz4dq63ZD80X7VbfYiI/cDDcnkCBAgQIEBgRALR evQ8OlU13LaNXUBJmQe6wbFM2mpLVgHDA90JlyVAgAABAnkIdIkt8pj5AGYRy6JFk+DGUbZVuwHc NkMgQIAAAQKjEGi7OxiNFGzZ7nlrW6Ons3ZSm/dE93YCBAgQIDAxgeJsXoohmi4mpSDvY/TCnRhT P9Mte8ulooMNVu6KunYXt0/7+WRXIUCAAAECBKYoEL3om8YecWxM7NHyKSn2xBsEdvGaqIOnVk1L YC8nQIAAAQIEHhWIWrltumBEH3uUDQRaLZHakm0g6iUECBAgQIBAW4GiS1bDxab0OqVUdgGXyRTN +sbZkm37mHo9AQIECBAg0FYgSq0V5+0aBHpRRDnKr7T9jKxf3yaZwpZs1o+CyREgQIAAgUEJFAtQ KXO2WZC3/Kxe3vr2RRZK4wONlkAH9dAbDAECBAgQmIJA6yzb1E51Ci4759gmUzZFzleTxjJ5AgQI ECBA4KQCZ/PlX01W8orXTDXIm71YnTXqTCEN+aQPsw8nQIAAAQIEvgm0WpyaWpAXdWaaBHfR+00v Wd9WBAgQIECAwJAE2uQOTGYlLybaZHkzkimiFs2QbqixECBAgAABAgRCIJIvzi+Xb5rENFFyJWu1 xsFdAtNyLOtHweQIECBAgEAWApEj0CTIy7YgsuAui+fYJAgQIECAAIEHAhG8TTLIi15tjSZ+uXpl 5c73DQECBAgQIDA2gckFeU2zZc9TcDe2m2m8BAgQIECAAIGNQNMgL8qtjFqtbPGx/Kdu9U5wN+rb bPAECBAgQIDAWiBVAHlWF/cU/57KxY0SrWmHCsHdKG+vQRMgQIAAAQI7BBrlHcQCWOrmNSrEaLbb pDmv4G5Ut9VgCRAgQIAAgYYCTYK8qPcbMVPDS572ZeumvB/rlicFd6e9Tz6dAAECBAgQOKxAsyBv 9T5ip8OOpIerp8Dupj64U+euB2qXIECAAAECBAYuEEWORx8XZTGJgT8ohkeAAAECBAiMSyAFeNd1 QV68ZpCziua7dYOP9mOjWIYcpLBBESBAgAABAmMUiBq/jdqaDa2lWfSMjYOCVQFeCu4+CO7G+Fga MwECBAgQILCvQNG7NsVCdYthUWJu38/q7f2zy+VddXC3/DyaLJHeVFyIAAECBAgQIPBNIGKhugWx qEIyiK5eacnx77po9Pzi7R9uMAECBAgQIEBg6gJNmkCcvNJIw3N3L6d+M82fAAECBAgQILARiIWv wS6OxfJhXTHjOFDodhIgQIAAAQIECNwXqOtbW2zlphyHo7vVpvymPWRJFUe/LT6QAAECBAgQGIlA Wih7V5nDcOyFstqt2TH2VxvJw2CYBAgQIECAQB4CZWvX1JP2cvVl11dayXt2lNk22ZqNgsdHGYwP IUCAAAECBAiMWCACuMrzeCkA/G3x9seDT7HB1uy7gw/CBxAgQIAAAQIEMhFoUAT55qBTnS1unwwi yjzoLF2cAAECBAgQIHA8gSYNI+J43MFGlIK7m5puFS8P9uEuTIAAAQIECBDIVKCudEq0ez3I1OsS K+KDB1F5+SCzd1ECBAgQIECAwGEFosBx1ULa2cXt095HEAFc5fZs2r7t/UNdkAABAgQIECAwEYHY qq3Kqo3aeL0uptUtG0bixUTsTZMAAQIECBAgcDCBqERSuYo3X/7V24dXrt4VNe9OUGm5t9m5EAEC BAgQIEBgGAKxQld0sdhRGy/92+de4q4Gq3dXwyAxCgIECBAgQIDA+AXO0ipdTa/a/WOvqtW7iDC1 Ixv/g2QGBAgQIECAwHAEylW8ityHtHu6V/x1tlj+dLR94OG4GgkBAgQIECBA4KQCdTuoscrXeYAp uHtdsQfcbyZH51F6IwECBAgQIEAgP4HqXdSOdfHqU3VXL/OjNCMCBAgQIECAwDAEalfx0k5r65FW punKnG3t6Q0ECBAgQIAAgbYClRm1qTBy2+v9p+qC0bKs9QW9gQABAgQIECBAoJVA2qZ9uTMfIi24 tSp8PHuxOqtKrjhow9tW0/ZiAgQIECBAgEC+Ar8s3vxQFZOlBblnjWcfnSl2J1d0PNTX+NO9kAAB AgQIECBAYCMwu1ze9RKXpfN3H3ddaK+0XPeKAAECBAgQIECglcDZxe3TqlW83xZvf6y94Gxx+6Tq IrFUWHsRLyBAgAABAgQIEOhFYN2+7PNei29Vh/miHksvI3URAgQIECBAgACBxgJVx+eibnHthdL2 7LuKfd6XtRfwAgIECBAgQIAAgV4FKmvipaN1lR9WFDe+XH3ZuQTYpaBer9NzMQIECBAgQIDA9ASi 92znI3RV0WHUxZsepxkTIECAAAECBIYhUNW6bHZx++fOUVZ2r2iyvzuM+RsFAQIECBAgQCA7gbSC d7XzGF1VV4s4pLdXhkZ2lCZEgAABAgQIEBiGQOdzeGnp78PO/d3U3WIY0zMKAgQIECBAgMD0BOq6 Wjxayi5qrFQd3ovDfdOjNGMCBAgQIECAwHAEqppRPNpKtqrAsQSL4dxYIyFAgAABAgSmK1DVtuzR AK+mDcbNdCnNnAABAgQIECAwDIH2Ad58+dfuzIzl38OYllEQIECAAAECBPIWKOoSp7InsSIXX2db dYhbB3hVLcqifErelGZHgAABAgQIEBiGwLr37Keq3IjH/u08lUrZBIVft2sre5xVFc8bhoVRECBA gAABAgSyETi/XP7dNsB7+PoCI6I+JVKyeS5MhAABAgQIEBixQF1JlCbBXzH9qj3d7b3fEVsZOgEC BAgQIEBgNAIpiLtpEsjtek25gjdfvd/1gkcL542Gx0AJECBAgAABAuMTqOxccbn6Uhf8lSt489XH nS9M2RzjYzFiAgQIECBAgMC4BaIWcV0gV7eCt7NNmRW8cT8cRk+AAAECBAiMU6CyyknNKl65gne5 vNu9gnf7ZJwsRk2AAAECBAgQGK9AURNvvvyn9SrefPWuNsB7tPXFeK2MnAABAgQIECAwGoFOyRaL 9eJc1ZsFeKN5BgyUAAECBAgQyExg9mJ11nIF7+orQWUdPIWOM3tUTIcAAQIECBAYk0BlMuzWWbxI yvh9cfd9owDvLPWpHROCsRIgQIAAAQIEchKIWKzRKt7DRbmalhjXOSGZCwECBAgQIEBgTAKNki02 iRXbEzu7uH26KzJMwd+bMSEYKwECBAgQIEAgN4EUp72uXMXbJFbcC/AWy592vikVQc4NyXwIECBA gAABAmMSiKTXigDvW2LF9qTiQF5VVPi/xd13Y0IwVgIECBAgQIBAbgKPtZb9V2LFw0lXtsN4bNkv NzXzIUCAAAECBAgMWOCxZIs4Zlc55JSC+27nKp5SKQO+3YZGgAABAgQITEGg2HG919lieVc77xTc Xe9OtFi9qr2AFxAgQIAAAQIECBxU4Gvt4gj0muywztIq3c4ALxXOO+hoXZwAAQIECBAgQKBWIIK6 dbz2eGLFwysUNVa2qiH/6/9vEiXWDssLCBAgQIAAAQIE9hGIEnatEmAfy87YBHo6WuxzK7yXAAEC BAgQINCPQKvgLj4yBXNXFat4N/0My1UIECBAgAABAgSOJlBZRC8d5rvXwPZoo/JBBAgQIECAAAEC nQViye9++u3qy/aKXqqV96zzxb2RAAECBAgQIEDgNAIpoLupaFv27jSj8qkECBAgQIAAAQKdBc4v 3v5RlU37y+LND50v7o0ECBAgQIAAAQLHF4ht2qq2ZSnT9uXxR+UTCRAgQIAAAQIE9hKozKadrz7u dXFvJkCAAAECBAgQOL7AVpXke0kWm63b2MY9/qh8IgECBAgQIECAwF4CVUWP49/2urg3EyBAgAAB AgQIHF8gOldUJVtYxTv+PfGJBAgQIECAAIG9BBokW1jF20vYmwkQIECAAAECJxCwincCdB9JgAAB AgQIEDikQJNVvNYNbw85YNcmQIAAAQIECBCoF6hbxYt/r7+KVxAgQIAAAQIECAxGoG4Vr+hdu7j7 72AGbCAECBAgQIAAAQL1AnWreNG/tv4qXkGAAAECBAgQIDAYgVjFm6UOFlVlU2YvVmeDGbCBECBA gAABAgQI1AtEAFdZF2+++iDhot7RKwgQIECAAAECgxJIAd7rylW8+er5oAZsMAQIECBAgAABAtUC kUxRJFVcrh7tURv//dfF6meOBAgQIECAAAECIxKoS7g4ny8/yaod0Q01VAIECBAgQIBACJzPV+8r t2ovl3ekCBAgQIAAAQIERiQwW9w+qQ7wVl9SEPhyRFMyVAIECBAgQIAAgQjg6oI85/E8JwQIECBA gACBkQnM0lZsdemU5adfFm9+GNm0DJcAAQIECBAgMF2BSKYokioqsmrjvJ76eNN9RsycAAECBAgQ GKFAbMPWbdWeXy7fjHBqhkyAAAECBAgQmK5Ak/N4KQi8mq6QmRMgQIAAAQIERihQdx4vVvmiht4I p2bIBAgQIECAAIFpCvy+uPt+Nl99rNuujZ620xQyawIECBAgQIDACAUiYzYlXXyu7lebWp0J8kZ4 dw2ZAAECBAgQmKzA2WL5U12/2uLfBXmTfUZMnAABAgQIEBihwNnF7dParVpB3gjvrCETIECAAAEC kxZI5/GeC/Im/QiYPAECBAgQIJCjQArwrgV5Od5ZcyJAgAABAgQmLXB+uXolyJv0I2DyBAgQIECA QI4CTYO8OLuX4/zNiQABAgQIECCQpUCjIC962qaze1kCmBQBAgQIECBAIEeBxkFeOruX4/zNiQAB AgQIECCQpUCLIO/mf4u777JEMCkCBAgQIECAQG4CjYO8+epdtEDLbf7mQ4AAAQIECBDIUqBRCZXy TN7H3xZvf8wSwaQIECBAgAABArkJNCqGnIK86G97fvH2j9zmbz4ECBAgQIAAgSwFZhe3f9b2ro2V vPLrKksEkyJAgAABAgQI5CYwe7E6i1W62oLIRZC3vJst7v6bm4H5ECBAgAABAgSyE5gtbp+kIO9T kyAvXne2WP6UHYIJESBAgAABAgRyE/hl8eaH8/nqQ5MgL7Z1z+bLv3IzMB8CBAgQIECAQHYCURYl BXg3jYK88lzejVIq2T0GJkSAAAECBAjkKNA0wzYCwWJrN53jy9HBnAgQIECAAAECWQnEObum5/LW K37Xul9k9QiYDAECBAgQIJCjQGTMFpmz30qlbEqmPPq/cYZPAkaOT4I5ESBAgAABAtkJnF8u/24a 5JXbtquX2SGYEAECBAgQIEAgN4F29fKKNmfvtDnL7SkwHwIECBAgQCA7gdiyTat5bxqv5qVyKrH6 52xedo+CCREgQIAAAQK5CUQNvBYtzmLL9oNM29yeAvMhQIAAAQIEshOI7dfYhm28mhdn8y5Xr7Q6 y+5RMCECBAgQIEAgJ4HYem2fgJH63l7c/pmTg7kQIECAAAECBLITKGvmNWxztim5Igkju+fAhAgQ IECAAIHMBNZtzq7bbNluCiTbts3sYTAdAgQIECBAIC+B9Wre+zaBXuqY8Tnao8m2zetZMBsCBAgQ IEAgM4Gin20qk9Iy0Pt0dnH7NDMK0yFAgAABAgQI5CPQum7e+nxeOs/3/tfF6ud8JMyEAAECBAgQ IJCZwPnF2z/SNuynNqt569fe6IaR2cNgOgQIECBAgEA+ApGE0bakyiYgjPp5vyze/JCPhpkQIECA AAECBDISiBW5Vu3ONmVVyv+9lnGb0cNgKgQIECBAgEBeAnHGLs7atd62LRM3rgR6eT0PZkOAAAEC BAhkJBBdLTqdzxPoZfQUmAoBAgQIECCQnUDR8my+elnUw7u/JRvbstVfPQZ6cU4wO1wTIkCAAAEC BAicUiC2XYtzdnVB3WP/XgZ6112TMeJ90W5NkHfKJ8BnEyBAgAABAtkKzBa3T1KwdtMp0CuDv9fR UaMN0CbDN84F6qjRRs5rCRAgQIAAAQItBPYO9Oard1GDr8lHbp8DjCxfQV4TNa8hQIAAAQIECHQU 6CHQ+5gCuGe7grYIAh+uFkbtvY7D9TYCBAgQIECAAIGmAmWgt7zrunUbSRyRzPGwxMqu7eDYtm06 Nq8jQIAAAQIECBDYQyBq6O0T6K0DxNezF6uzIrGjTNB4PFt3vnq+x1C9lQABAgQIECBAoI1AGejt lYzxpTK42wR9qVZfm3F5LQECBAgQIECAwJ4CZfuz1atGwVrXEixptW/PYXo7AQIECBAgQIBAW4HY bo1zc50KJtcFfrGNm84Ath2T1xMgQIAAAQIECPQgENmyZ/PlX7P56mPXhIzH3heBY6wW9jBElyBA gAABAgQIEOgqcHZx+zSKF/cW6KWgsWu3jK5z8D4CBAgQIECAAIFHBKKzRV/n9CJg1NLMY0aAAAEC BAgQGIhABGZR9HjvhIzUJUO3i4HcVMMgQIAAAQIECKw7Yzxe964u2WLr36OlGU0CBAgQIECAAIEB CKTzeFd9ncnT0mwAN9QQCBAgQIAAgWkLxLZq2qL91FeAF9eJ9mfTVjV7AgQIECBAgMAJBSKrts/g bnOtKMtywmn5aAIECBAgQIDAdAXi3FynAK+oqbe8i6+ymPLqZQR10S4tvmTVTveZMnMCBAgQIEDg hAJRv+5fwV3Khi0Dt9VNBG3F18XbPyJoi9IqJxyujyZAgAABAgQIEKgTiFZmEbgpVFwn5d8JECBA gAABAgQIECBAgAABAgQIECBAgAABAgQI5Cjwf5VFIJfWYVixAAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image011.png" Content-Description: image011.png Content-Disposition: inline; filename="image011.png"; size=31104; creation-date="Wed, 10 Oct 2012 09:43:14 GMT"; modification-date="Wed, 10 Oct 2012 09:43:14 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAngAAAJtCAYAAACljA0SAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAHkASURBVHhe 7d0LYB5Vnf//c87M8yTphTYtdxSkXKRQAcFe8kgqKrIFxPWGy4qru6631V10vezPdZWSrpfVVfcn uq66XtAV5ef1LwuIUlhsIKGNsiCl4S4UBIW2CbS5Pc/MOf/vmedJmrRpm7SZTDJ5P263tHkyM+c1 0+STc/mesKWlRfFCAAEEEEAAAQQQyI9AmJ+m0BIEEEAAAQQQQAABL0DA4zlAAAEEEEAAAQRyJkDA y9kNpTkIIIAAAggggAABj2cAAQQQQAABBBDImQABL2c3lOYggAACCCCAAAIEPJ4BBBBAAAEEEEAg ZwIEvJzdUJqDAAIIIIAAAggQ8HgGEEAAAQQQQACBnAkQ8HJ2Q2kOAggggAACCCBAwOMZQAABBBBA AAEEciZAwMvZDaU5CCCAAAIIIIAAAY9nAAEEEEAAAQQQyJkAAS9nN5TmIIAAAggggAACBDyeAQQQ QAABBBBAIGcCBLyc3VCagwACCCCAAAIIEPB4BhBAAAEEEEAAgZwJEPBydkNpDgIIIIAAAgggQMDj GUAAAQQQQAABBHImQMDL2Q2lOQgggAACCCCAAAGPZwABBBBAAAEEEMiZAAEvZzeU5iCAAAIIIIAA AgQ8ngEEEEAAAQQQQCBnAgS8nN1QmoMAAggggAACCBDweAYQQAABBBBAAIGcCRDwcnZDaQ4CCCCA AAIIIEDA4xlAAAEEEEAAAQRyJkDAy9kNpTkIIIAAAggggAABj2cAAQQQQAABBBDImQABL2c3lOYg gAACCCCAAAIEPJ4BBBBAAAEEEEAgZwIEvJzdUJqDAAIIIIAAAggQ8HgGEEAAAQQQQACBnAkQ8HJ2 Q2kOAggggAACCCBAwOMZQAABBBBAAAEEciZAwMvZDaU5CCCAAAIIIIAAAY9nAAEEEEAAAQQQyJkA AS9nN5TmIIAAAggggAACBDyeAQQQQAABBBBAIGcCBLyc3VCagwACCCCAAAIIEPB4BhBAAAEEEEAA gZwJEPBydkNpDgIIIIAAAgggQMDjGUAAAQQQQAABBHImQMDL2Q2lOQgggAACCCCAAAGPZwABBBBA AAEEEMiZAAEvZzeU5iCAAAIIIIAAAgQ8ngEEEEAAAQQQQCBnAgS8nN1QmoMAAggggAACCBDweAYQ QAABBBBAAIGcCRDwcnZDaQ4CCCCAAAIIIEDA4xlAAAEEEEAAAQRyJkDAy9kNpTkIIIAAAggggAAB j2cAAQQQQAABBBDImQABL2c3lOYggAACCCCAAAIEPJ4BBBBAAAEEEEAgZwIEvJzdUJqDAAIIIIAA AggQ8HgGEEAAAQQQQACBnAkQ8HJ2Q2kOAggggAACCCBAwOMZQAABBBBAAAEEciZAwMvZDaU5CCCA AAIIIIAAAY9nAAEEEEAAAQQQyJkAAS9nN5TmIIAAAggggAACBDyeAQQQQAABBBBAIGcCBLyc3VCa gwACCCCAAAIIEPB4BhBAAAEEEEAAgZwJEPBydkNpDgIIIIAAAgggQMDjGUAAAQQQQAABBHImQMDL 2Q2lOQgggAACCCCAAAGPZwABBBBAAAEEEMiZAAEvZzeU5iCAAAIIIIAAAgQ8ngEEEEAAAQQQQCBn AgS8nN1QmoMAAggggAACCBDweAYQQAABBBBAAIGcCRDwcnZDaQ4CCCCAAAIIIEDA4xlAAAEEEEAA AQRyJkDAy9kNpTkIIIAAAggggAABj2cAAQQQQAABBBDImQABL2c3lOYggAACCCCAAAIEPJ4BBBBA AAEEEEAgZwIEvJzdUJqDAAIIIIAAAggQ8HgGEEAAAQQQQACBnAkQ8HJ2Q2kOAggggAACCCBAwOMZ QAABBBBAAAEEciZAwMvZDaU5CCCAAAIIIIAAAY9nAAEEEEAAAQQQyJkAAS9nN5TmIIAAAggggAAC BDyeAQQQQAABBBBAIGcCBLyc3VCagwACCCCAAAIIEPB4BhBAAAEEEEAAgZwJEPBydkNpDgIIIIAA AgggQMDjGUAAAQQQQAABBHImQMDL2Q2lOQgggAACCCCAAAGPZwABBBBAAAEEEMiZAAEvZzeU5iCA AAIIIIAAAgQ8ngEEEEAAAQQQQCBnAgS8nN1QmoMAAggggAACCBDweAYQQAABBBBAAIGcCRDwcnZD aQ4CCCCAAAIIIEDA4xlAAAEEEEAAAQRyJkDAy9kNpTkIIIAAAggggAABj2cAAQQQQAABBBDImQAB L2c3lOYggAACCCCAAAIEPJ4BBBBAAAEEEEAgZwIEvJzdUJqDAAIIIIAAAggQ8HgGEEAAAQQQQACB nAkQ8HJ2Q2kOAggggAACCCBAwOMZQAABBBBAAAEEciZAwMvZDaU5CCCAAAIIIIAAAY9nAAEEEEAA AQQQyJkAAS9nN5TmIIAAAggggAACBDyeAQQQQAABBBBAIGcCBLyc3VCagwACCCCAAAIIEPB4BhBA AAEEEEAAgZwJEPBydkNpDgIIIIAAAgggQMDjGUAAAQQQQAABBHImQMDL2Q2lOQgggAACCCCAAAGP ZwABBBBAAAEEEMiZAAEvZzeU5iCAAAIIIIAAAgQ8ngEEEEAAAQQQQCBnAgS8nN1QmoMAAggggAAC CBDweAYQQAABBBBAAIGcCRDwcnZDaQ4CCCCAAAIIIEDA4xlAAAEEEEAAAQRyJkDAy9kNpTkIIIAA AggggAABj2cAAQQQQAABBBDImQABL2c3lOYggAACCCCAAAIEPJ4BBBBAAAEEEEAgZwIEvJzdUJqD AAIIIIAAAggQ8HgGEEAAAQQQQACBnAkQ8HJ2Q2kOAggggAACCCBAwOMZQAABBBBAAAEEciZAwMvZ DaU5CCCAAAIIIIAAAY9nAAEEEEAAAQQQyJkAAS9nN5TmIIAAAggggAACBDyeAQQQQAABBBBAIGcC BLyc3VCagwACCCCAAAIIEPB4BhBAAAEEEEAAgZwJEPBydkNpDgIIIIAAAgggQMDjGUAAAQQQQAAB BHImQMDL2Q2lOQgggAACCCCAAAGPZwABBBBAAAEEEMiZAAEvZzeU5iCAAAIIIIAAAgQ8ngEEEEAA AQQQQCBnAgS8nN1QmoMAAggggAACCBDweAYQQAABBBBAAIGcCRDwcnZDaQ4CCCCAAAIIIEDA4xlA AAEEEEAAAQRyJkDAy9kNpTkIIIAAAggggAABj2cAAQQQQAABBBDImQABL2c3lOYggAACCCCAAAIE PJ4BBBBAAAEEEEAgZwIEvJzdUJqDAAIIIIAAAggQ8HgGEEAAAQQQQACBnAkQ8HJ2Q2kOAggggAAC CCBAwOMZQAABBBBAAAEEciZAwMvZDaU5CCCAAAIIIIAAAY9nAAEEEEAAAQQQyJkAAS9nN5TmIIAA AggggAACBDyeAQQQQAABBBBAIGcCBLyc3VCagwACCCCAAAIIEPB4BhBAAAEEEEAAgZwJEPBydkNp DgIIIIAAAgggQMDjGUAAAQQQQAABBHImQMDL2Q2lOQgggAACCCCAAAGPZwABBBBAAAEEEMiZAAEv ZzeU5iCAAAIIIIAAAgQ8ngEEEEAAAQQQQCBnAgS8nN1QmoMAAggggAACCBDweAYQQAABBBBAAIGc CRDwcnZDaQ4CCCCAAAIIIEDA4xlAAAEEEEAAAQRyJkDAy9kNpTkIIIAAAggggAABj2cAAQQQQAAB BBDImQABL2c3lOYggAACCCCAAAIEPJ4BBBBAAAEEEEAgZwIEvJzdUJqDwHQQWLz4MqPUD0e51IvU 136ztkE+MIavTY1OqS5d39DfoFx9MKHt1v1aOfmfUr39/UfE/jz7OL5rfLir5wc/uMj+8Ic/HOW9 F6k3XKRcy5o1/pi8EEAAgdQFxvBFNPVr4AQIIDBNBBYvXizBrPr65pNzTfREOEv+UwJNNWypBlVX 71RhWHNC+agEtqEvNUHkopPX33PzLKP95wx7xVYpszYo1LvjtTPz9klit8mZdWBt3XHOufn7fP94 3qDr5d02VtpsKtZt65ML2+NnSw402rlKz8mNd114+dqK0o27BTyrbtbnX2bj1qC0qV6Fvf5gkVM2 1Dt6JZzWHPrL/f315dqJ3MlHHt131hF3SbgkHI7n1vFeBBCoChDweBIQmIECPqjdeutpwaaGzb63 zEewoN5JT5iW//nAIT1YkZszK9TVZBOpyPdoHdlxtz3KGok9VlKNMrOKRbdYGROqeJvTRhtn1dHy oUOcHKHKqudprY5XOjZK/tK/jPyFkoNZt0sOMtVOOH8JyVv29QoGQ5dc0Fjev6/j7fZxf3y3Yl8H 99fr3+NbJxHVN22Ul/yl0apopd2i6VsZONcX62KnVjZKPjGof6JYr5/wPYfyf/bBLY88+HBXY7cP h6+8XEXtunRXqEL/yarfRXG97u8bDIcNWvV39SUHTq4gPDLqfesR2+1FF13k1tBrOO47zycgkAcB Al4e7iJtQKAm4INbtWftkFmNDV2mz6k6yRKFSIWhcpEEuFBSVPn49ZvMfDVv87yCchK+dKCdnhur uuMlaEims5LR6oLARidboyUAulr/lXykFsIk5CWvJNz4Vy1sDf55ROAaDF+Df7nPQcrq2OiYX7Xg OOb3j+eN4wiOQxZ7O743GDym0w0Sks+o+g1+krQ8eYsERh1ICE7yWpL/JFTXwqFSBaeesaruQR8E 5a22RwWPFgrR1qSnUbtYbws3XdnV2Hfl5b+UI6x4oqyLT9RXorg/Ur0ypG37XX2f6ldRo+oqX3Tm RQOdnWuSbMoLAQTyI0DAy8+9pCU5FlgtwW3VbsGtX/JZfSDdNrN8h5B0nx3TscksNLGZU6zvfn6P dXVa6+dKXDtEu4qMG+rjVGC1drU04bPAsKFHOcTO8FELHdVMVksko6Su3aOYvGnE+3b98zS7SeNI mmOOpSOOOSxB7hImdwuM0gM4+NJO+SHsM4d9ynIdDP9yPugeJLejKDnQBq6/oNW9MqTdLwHxYV1U 3T2q8Ynv3HPzE1aXeiThdcqbI/khoC9UUST/XZGewQHpGbSNZ3b1/PCiiyxzCKfZ88vlzmgBAt6M vv00fioIrL7sMr3qihsKMp+tIZnDpvqL/X31JqxXsyMdmqIrH7lqkzlieHCT6z5aetkWyu9zJJad JOOjSVzznVkyUFoNZdID5F9JLhjqNRoW2JJVBMPSxm5hZpqHs6lwc/d5DXv23y0w7nZ/xhYOh96l g3p5JE5PngCtVlQvrfoMSA9udejcWeds5aFYa5lQ6bbssPoxGYbv77unceP5m27u63ArH5IfKJ6R IfuKfHK/zFS0EgJ7uvoabXjk0wMyLFzp7OykN3Cf9503IJC+AAEvfWPOgIDaNcTJ99Q6mU8lw59R 3fktN59mY3NwWKeP17F7rtV1hxUKrs44fWqgrcS1QOZr+aQ2MrgNZ5UenREpbigcDIWCcXRFpXm/ JESMOpSZTGPb80KGPV7S/nzOeNqXDP+OzU6S0T7fmrxnwl7jCIcjzrlzmLga/mr/P3m8JOb5OZO1 185RdR8C/VBxLH2+TnoE3Rb542PynPX3arOxUNfV77aYx2VY+CmjSk/JLMBH+6NooL7Q39+v6ntV X2PlHWee2cNQ8ITdfA6EwD4FCHj7JOINCIxNoBbiilGf9L31y9y3PYQ4Y91zpMPkKBWXn6+DYK7/ xhkkc9uqk/WTb7mDc7KSKVk7u9+yDG67BTAf1nadbDfsz9XR3aRjsdo2HxBiGfmz0S5JyH8s+WiP HFG6kHZdfTGKf/WYohPJCtehxQVju1FjfpdfOWFnVxuxj1d1rLu2ongPgdDJZEdZReHNkvuYZEeZ 7jh0aP93w/7k/3vEnycqHO7sma2ebbTrrT1zQ7+NiIL+dh4szTi4dulNCVDSA+jnCfrfI1U0+g8y HLy5qN0mXde9VYaC77F6xWPWFZ+QIeAeKURTkTmAEv7UwA/PVAMt9Pzt6ynj4wiMS4CANy4u3jzT BYaHOJmmXt8v05vqIzVbFQqzzr/85lOsNUcUjTpGvtEdtccQNxjZhlaBVr/JjgxvY+s12p/7UQ1l 1TA5FNB2yTDJ3w+FtWo4i8v91W6cJLH5kKD75U9+qC55ydul8oeWwJUkk+qbtO6prhGQc/nhP2We cNo9IR/0ySZJDfJhPzpYkV6f38p/y/GGTTbbUwN96rVSxkTZB40x3fvjsNfPkXHIqBAEJnYny/X4 4LbnGyKJ3VorZV/UYmlSKLFz9/cmi2xtIa70nya2soA2eYv/+usXsVTTk9MF8ZIfDOTPVb16QauW nPHhsFCUGOmTf+3wfi3M8EYM6x1Mjj8UDn16Hu/zVHv/0G97+vzdewOHBfvDZfWI/FLLksyXXG0o i0UiZ7XqLEgvYI9u3KSK6vFVm9Rj7W7lPWEkwS9UPfL+AR/8ZDVwT1P3hsHVwRN+mzkgAnkWIODl +e7Stv0W8KtRv/abxrn19buHOPmGf7hMUj9Wvg0fU3D2cBvok5WTqhXyDWxnT1yt42oyQ9zg8Ofw 4c5amEu+6fppej5myPQp56TonIwXSiDxNdl819CuPWEStLTkV5/nkoDnw9Rd8v6KLO2UxZ9KVmuY R6QHyq/cTL77x1o94wOXFPKIJfDKJ8mqzXq1qXmgTY6Twmvf/Wr7f9Ji7VNDtX5MB9mPa9nYWzqo ryE8XkY5k/7aSBcPlpvzPCMLmWXBjJEQdLTgSy+ZvwcujMsDJ8s9TFY1y8vflDnV35MBevlaLiue B3s/ZeW0/F2d/7hEQxMU5I/+IRgMhbWh52rwq/bo7d/w8b56A4cHQB/yk+fQX8nJtc7Blf7x8VMQ /M8B0uqBotMbJdA+buv042Zb8Z71urRVHtROWfbRx5DvmJ5G3oRAIkDA40GY8QLt85eFMqw6u76v f47MF5olc+MWrN8ULS4W1VLpczpWlqoeNjzE+ZoWgz1fUvptmF+122Xie+JqPW3VlFbrWKv1wCXf 6qvDoE6GP20knWh+pryWyhky3Cn/LYVzdVmWzko3k/SmWQlqTj8q30y3yht3GBXcJ10qA/KN/6Hh PWENuv/pJfqOR0d9OIbvGTFasBkMR/6TB2b847VHgCWz2p6VD94xNAJfvb17fg1z96uqX7mp8TT5 Eu7L3/gexPnyyTJ3rtbF59TBzkTH+LI3cr8XSs/hMdIx6uuuJEPO8ow2SNjyRagHg6CEQPkZJXmE B3v8dvYCDs4vHAqEY76twwPgrr2A1fBXDXq1iQgm9KH0TP+r2lz/+fLzhPRO7mvIV97sJ/z1vePM rh0s9BjzDeKNORYg4OX45tK03QWu2npx4egFd82uV41zpDbcbBOXn2u2hIsK2p4eu7pTJcydpE28 UHZSGPpmW+tpqB1sWIgb+n413uGvXa5rqOetFt4ksA0b5pK4FsvAZcUPaEqvm5Qw83PO/JCmr0bs g5tspyUjp7GE0S3yeY8lPW/a3C2hrSyB4Un5pD80FNTAT0/c9ts9znPajx4onq/sBJL7qNX/1rLR 4LO6drcrGnZfq6HwkBfICtgGSXiLJDs1ynOyUALi0fIDS10yfCxDzJKopNK1DA0PDhkrX1fHzZI/ GyM9s9pnyKTjrzZEXBsaHhwWrs4vHMu/iVrP4WCQG7r4XYd9fTdk8kPM6EO+EnDlnJvkaJvrivq+ KzctvLOsSnfLD2rbpK29MtDdu3ZRVy9z/LJ7XjlzNgIEvGzcOeskCPy+rlT/RF9/g/TKzZEHfY6M Ki46vnHzImcbF0s31lLtoudLh8dcP7SazJEfmeSqPXFphrja8Gl14UFFxqdsnwz7+jlt0vvmv2v6 +Wwyr83ZZ+TSHpL/HlAmlN9tt0S8LbbgHmsIw/7tYXRv80D77sOgw0ObDLCe3jkJ6JxiygpUQ2Hn XbVQePtovYWrV1+mX/nxW47Tlf5GP2RsrD1GilrPlkfpJHkk66PKwHHSaz1PjuF7/vwea4E8m36O on/apAvQjy+HsreJ/9ZS6wn0QbA2J3Bsw8B7G/YdZchXVv7KyU6R/3eK/Bs+z/+hmKxHie6XzuRO 1+PuW7Wp8Z52VbpDLm9HNfQ17mgeuC7ZMo4XAnkVIODl9c7OsHa11pVmycrVevmeIr1z6iD5fnOi 7bGLla5bJF0Rp8lw1AskHNUlYW5w8cCwQLczzI2l52EPuLWeuKQk3dAihmpwTOa9+dWjTkKcSnrf dshfS7eck+2mZHsqLT1vxjwg79xmdPhb+ebU39DX+NCSWdf5YbzdX4PDoBLcZMYbLwQmRKClZY2s plEPDoW/4T8kDPvv1t4zDq5vmHO0PNZzdMGeJJ9TL/vXHStJrtHF8ZGxjY6SZ3yWPN9F/29S/mkk q8qDovwTTOYT1ELfriFwn60Yw5CvX6NSnTpxov81VOpF5h8qV3mgqPUm17vttx1m5T1RJbrH/4yk dH2PzBftlfmihL593gPeMF0ECHjT5U5xnYmAX8V60afXzpYwN2u7iqTnoH6OcdEL6vr0SfKlf5H0 FJwsY5YvlNlG8jXeJ7jB4c6dgAcU5vYW4irJ4oXYRba3OoTqe+K03zxeNpRXm+Xv/iCX86CKzTYb GN+TsuWGy89+OPmmOtrL94vwQmAKCjTPumOLf35lBax/rdt1NrfvCTxn9drj6qPwcFk4sUSe/aMk OT43WSiizVz5QUaGfJ0sGNGypkLNkh+6ClJCZudijxG9fsl48BgUBod8h713sOzQYOjT6gQ50Any leFP/aIOI6s7nKvfKGtTOut67b3tZoX8cGXulW+Mz0qXeE9jX2Ov/JDle9J5ITDtBAh40+6WzawL 9vOGLtrUeFCX9MrJwzpPigKfscPpk2XO2fMDVThedlY6pTonqFpzo1reY+f3g/0Nc9Xj+Dlxvgeu 1iPge+L2GuLcZpkN/qRMZu+UHo1tclmbZHHqH5bqOzaPuGvD/tU1taybWTeU1s4IgdoPLQ9KAHxQ Gnzr8EZvrCvN6esPT4zi8iJjgsOkZ1tWoesjYhn+9b198o/Zx0YJgX4Y2DVIx7uMCsu/Q/nJrfrv eRxDvrW5gCMq1yQ/pPmvEf7fdbKUY4n8eYlfPCU/F8piJZnzqtz/Fo25p6fYdd96W+q0OrxPavdJ b3rD9mjb9t6mhRtYPjQjnuTp3UgC3vS+f7m7+o2LLwv6Nt12UKS2z5M+sIPO31T/wp44WiHFUpdK 0jrTV1hIfj4f/Mk8Ge4ZvnJ1LD/pj2QbHuIGh1eTIdU4HnA6ll644T1x4w9xubtJNAiBAxBYMtC2 Q/7Z3iG9fjInTl7Dhn47XOm58jdHyM4up9tAHabiyiJb7j9RCr3Mk3/lPvT58Cddfcm8v6Ks/E0O UV3lm1T+GZrvt8dLTL5eJJ+18y1DPX3+57rkgl6Y/PKjAPIxqd3n332HLES/0zSG93bYFff2RzKl IpTSQP3q2eZZbf7rBC8EppQAAW9K3Y6ZdzFbZVXrpgWbpXcumiuL9xaqu285U5vycqkFtkx+nJaf rOXLavULbu0L+cSHuTiSH8ZlgYNUEJFdl3xhXrdDhmwelr+8N9Bmkyws3CgVRf64t564mXfnaDEC Ey+wVLfJKnCZjxqqDcnRa9+hkgLjLWtPk4Iph0u9n2OlANCJxrjDpddPhnylWLRLCkb7uoBzTBD6 hR47Q5+v/bevLef20NPnL8HX7qvN6TtDzn9GNRoaVTBSA9KpX+ui6pDAJ9WYi/fLAo5nCXwT/1xw xP0TIODtnxuftZ8C7VuX1YWN0UH9au4cWXJ3uJ33yNKiC6R3LjxdyjUska275Ktn7bFMhloHh2X2 r2cu+Wl8aIhV+90Y/FfnHpkP1CulemWBg/wE7tT98vW6U051X0UHm8IFR25s6r7az53jhQACU0Cg ZY3MU9XqzuRSqlNrh14dvWccHoVzFqkwOk02ujs1jionaR0d6Rd5VEOfOygZ5pXpFkM9fQcQ+qpr s6RXz0iJGaX+RP7zT3zg0zbaKuW9hwKfLPC6VxZ1PNvQ3/XsklmdzOObAs/RTLsEAt5Mu+OT3N5r ehc3HFF/pNScqxwkE1ueaxqjFzlXWFZwldNlK4QTZP+lWs2swblzg7W1xhfo/Bfvapjz8+aS2XjJ 1lry2iGTqfvk47LQwW2Xj2yUEneboljdLz0ADzSZtmotMf8a/KbRPclInA4BBPZbYOmsO/4gn+x/ tQ3+G251pQX1Lny+fN05XXrglkbRwPPlK8Mh8uPibJl554Pffoe+kcO71a9bflbfzsCnk8Dn4sqT ssPcr3vqF65vt6VfyzdbGRVQBL79vtN84ngFCHjjFeP9exXYKIGur75RypSEcyPVf9whxeKZUpv3 hfLlbqkEr2NUMqlZvvztrF1QnQkzpsKo1VOPDHOSyvw+qVG/jLDGO+SjsoJVfjklazHc/8qHNsm8 vfvKyj3YHLTdM3TxPPk8yQjkVqBZt22TzNUuDfS//sM3VOb3SaHk+KQoNifL16IXjT30JUX19vDa deWuT3u+s1H+Z8wR8qcL5S8uDPzeftZWA1+xcf16e1abrOHdHKrCs1HX9mdZtJHbRzHThvFtLlP+ 6X/y6pBrOF/mnsyXiS8n2KI5Xb7kLZXhiqWBKR4xuG98bd3asOr3Y++h8z1zfrXb4HCrLffJNvP2 WTlCrxxXhllttxRjvVtC5J1SyfXeSAUPNQfr/Oo9XggggEAiIPP7qj19obplkGRPoU8+7od2ZUWv mhOE9ckWMyOHd/cU+nYJfMkPsrsEPmMu9HsCS3kn2TIw7jCNxfXtbuWv5W2PEfh4WCdSgIA3kZoz 5Fitskl6vez1JVt9HWXmRaXY6ZXaBiUXBAt97bnqwohBjHEOudbmyw310smhZAulWL4QPitFq56R L5YS7HzPnNsgua9T6ic8tFS3jyxDMkPuA81EAIEDE9hT6JMCyKfJhhwnWatPV9GAlFDRjfK1xw/t VkNfoUF+nqyt2k3m8+0h8O26eMMHPl/SKfk6JyMaSh0jv78+kO0I5WtaNfDNC2VId2Wb7Ef4pNKV ZzdvO/rZSxZe7etq8kJgXAIEvHFxzcw3D++lk10Wlkgx+mbZ9/RlRsUv8IsipCadlJAa3Bq89oVu rEOug4Eu6aXzXzOtDLdKsTkJdPKF71n5i20S6H4jM1zWW203NOk2WdHKCwEEEEhHIAl9xWRO3y8G f1CVnr6jIxctllW0J/lC6qrcf4b8MNsowU6mo+iDfLmWpPiKD2rjDHzJ188Rgc+83shxCs49IH+/ YVHj5vXt5VJ7WOj/Q39ffRclWdK573k8KgEvj3d1AtokvXTzpNrUglAq0MvOk03SS9fse+l0ICvH asMOyWmGNhwf25BrtYBwdbjVB7rqPqxRn7OxLIBwz8bOPWac/q0Ngg6nyh1NwYb7J6A5HAIBBBDY bwEJfX4nGj9S8IvBg0gv23Kj4+XamWVxpe80+cI2Tz42X36fmwS+wdp81d650c+9a00+H/R29vBV d93Q5hIbxCq2dbcX6tRN66OzbrWm/ECkw65kriEvBPYgQMDj0RgSkJ9SD45cKKHOnlqsd83yheZl MpggpUskjO3aSzfGHrpdF0TYSJY72KjHWb3dD7dKNfmH5afkX8uPvnfKezuaGG7liUQAgWkg0GTW rZfL9L/U1vkXFx7u2nxm5NRZksSWu8rAYvlhdp4ku3nyuwQ+2YrX/zCc7Ic7vsBXHdJNtlxcIf+x wv9QLaWkHqyTLeLWq9IvpJ6TbK+mtp3ceHTXwm6GcqfBozNpl0jAmzTqqXeixbIN2Nc2NR4sV7ZA HoQXyeKv86Ri+8tcYA6XIdHaarDBKvH++vfdSzcU6GSfLj8bzxcRdnEkYU6GW5Xdrpy5TwoYS6CL 75Thjl8v1bf5oRBeCCCAwLQV8MFqoVa3y5e82/2Xzta6N80Otz98pizoWG6se7H08D1fvjYeJD15 EvjM7J2Bz4c9H9jG0sO3c8FGoPXxgnW8/M1bC7HdKvnvVw9uefxX99tSmx/Kbeg7Yit76E7bx2nC LpyAN2GU0+NAV8lPmid23b9Qeuoa199jmuqUPs9a91Ljh179z4hmcBXYXr7oDG/q0Bw6CXTyVUYW REigs89IspNAp7tlvsp9ss/PBlk11hGVw982z7qNIYXp8ahwlQggsJ8CzQPf7ZF5fH6j6XUS+P61 tfflC8Li9hcZEy511i2VGp0nSYWBebK/7jyZxyz77RYk4w2bvzdq4Nt9ha6W/XRr9fdeqwL9WvkK XnG2rr2v2HVjh135P0rveJSwt583MQefRsDLwU3cVxOqoW7zwn4VHbxoyyMvs6r+FVq7kpQeWVCt yO6/cIx9x4jBXjotvXQyd87Po5NtvmyXDONuk167u+QL1QZjzYZFhz73N0NDBn5VLU/bvm4VH0cA gRwKNM+6yf9g+8vkl3wt7HBnHG5V8UXy5+UyXeXM2A4skq/CjdrZeRL26pKvrbUhXf81dtTX8D24 a3P3JOxJ5Xi1Ur6or5RaUjK1pmEdYS+HD9QYm8S33DFCTbe3tc9fFoZd0cGRqq+FuuAVoQrODkzo 6zslu/3435OVX/ucT5cU7ZRfg710ybBrt/TSbZMvQo/Ix9pkCvA6s9D+qql7w84tvrrbphsb14sA AgikLiD7WvupKdfKD73X+pP5enyyu05Jwt/yOCq/SArBHy3l4GWFrpsfhMWiH8Ctrs6VsDfa1+sR izV8oSoJd9Vi8hL2AsJe6nd0ap6AgDc178t+X5Vs0XNo6NTCcIt6iVXhBfJP/Gz5oS4JdYH8T+bB 1b4+7GM+nXxxMLVA599po4EBCXNdSVFhZ6SosLpZMt9NS4PbHxi62O79vmw+EQEEEJixAklpllD9 RAB+Uu3hKx0t8/WWyhfrZpnH/GKpPHC4fO1tNEE4uzpy4hds1Obv7aY2fCiXsDdjHyppOAEvB3e/ w57RGEXhIaYQnl5n9eutsi93JliQbJeTLIwYW6hLim+aMOmt8+VLbBxvd0566pTb7Ixrk5IA68rK tDcHt23NARtNQAABBKakwLCyLD/2K3Q3PbW5KQzVS1xUeYnW0bEytUam16j5w1fnjj6UO/aw115e eXNYiB6OGqMtMhITTUkYLmpcAgS8cXFNnTdLnbq5YYOEOld+gXLBecbYV0mf2xG+Rl2yoN4PviZd +XvvqUvm0/lixVKbzpcwkWDXrWO3RQZxH7Da3aJ0+KtaOYBq46tju7wQQAABBCZBwM9jbt65YOOf O2zpBFkY93LZlvFlqjxwqizWaJTFGo1BsV5WasiP90mx5dHm7e0t7JmVRlc+Jjt33BhuC6/tiEq3 qLD/j0vNHV2T0EROkZIAAS8l2DQO63eUiBrDQ0NlT5DdJFZJPbk/lWB2ooylSo7zW+D4/9v36ted 8+kCWfUqI69xJD1ylW3K6k45wg2S9X6+TN/2aBpt4JgIIIAAAvsvsNS0PSA/xfupMV/xc/ds7Eqy B9BLpILB2fID+8HyBX1hENbVVeftjTXs+Vp7QVF+gr9AugYucMY+qVzDNe12xc8iZTY29jduoezK /t+zrD6TgJeV/DjO2+FefogEsEPVvOj8grWvkTkYTbJaaqg6+l7rKNXOkyyQGFwkUe6TDSPcVu3K 26QK+6/lv39uZqublw5Qk24ct4W3IoAAApkKDJ+7JwvrinabfUmow1fIvL2XOm2OlMoGtbAnsW2M YS/ZbMiYI2TKzjulx+CdBRuv7yl2XdvqVl5fr6Lfyzn/mGmjOfmYBQh4Y6aa3De21pVm1fepw6Qw 3emx6n+jdMGvCkwgiyV8vRGZVbe34piDoS4ZfpU5ddX6dDL+arfKbLwtTutbpUzK2lla37JE1+rS DUxu+zgbAggggMDECSQVDIy6UY54YxL2triVodGvkK/9L5XEdqT05x0iW6gV9zWMW12k6+srVGdx y7zs5RL5lheiyodtoP+nXZV+KDtp3B71R3+UfXGfmbgWcKSJFiDgTbToAR4vWQVbUUcXI3O+LHV/ g/yDPcVIQEsKEI9lsUSy+tUvlBgcfq08LVnwaTnCjfIT3NrZc4+/ZYkvwskLAQQQQCCXAknYC9Va adza9gWXhWbLL8+W7yAXSIHll0vP3MES3xb6sFettef3A5epPbu+hurs+S49KdoSBLOlt+CVUovh lfI5m+uK6pr1dsU1ZS27E9Wrp5oH2vpziTmNG0XAmwI3b3hvXcHZSyTMrdKBni2LJ5Krq/7j28ti iWQ3icD/A6ytfq106bjiu9E7VGR/VimY/xnalHrg9inQYi4BAQQQQGAyBJq610SDYW9jXWn29h73 Eq2s79l7mXzfOETm7B0mYc/47zNWwt7udfaGLc6Qud61IdyjJSj+rXP6b2Xa0HrXp3/arlb+t/Tq /Z5evcm4q2M7BwFvbE6pvKvVlmR7MPW8Yo+Ria213jrpeUt2lRjLEGxtXp3vcndxvCOOK09L/90m OeZ/S9772TJfW6maEXkhgAACCMxwgSUDbT0S9q4XhuulY2F2sS8+W/oOXi1h7yyJbofJyE+jkXos UiIr6dnb/eW/NyXdDjuHcLUM4WrZkSOO3ye9ej9qtyt/EOrogWR+IK9MBQh4k8y/+rLL9Ctb1h4h pz1dJkNcJNvUvE6Heq6yY+utS2rVBYWkWolUPO+Xf4RS0kTdJz9J3RyZws+azbp7JrlJnA4BBBBA YJoJyJBqj0wBus7/apWt04px/Z+qOL4wtvYUacqhshJ3VrLX0T6HcH3D/Vw9fbjM9/5bE1feZbX5 +Xqz8kqr+u+I6sM/MHybzcNBwJskdz8Mq7arI1e1rC1Zpy6Rsibn+rlyshy9OgS7j+3CfAHiZAg2 qsi/wfJT2rrHlLE32Si4rqnY5je15oUAAggggMC4BZr91mmh+qp84lfvDFae3l+pvEZ69c6TwPYc Kb21jyFc36FX3fYyWZgh223IOO6F8o3tQm2D/w171A/ag9LPoj71BMO34741B/QJBLwD4tv3J/td JvpV/ZEyDPs6CWSXaCV165JiwfLPZk/7CtYOWy1CLP9WfG9dXOmNK5U/yr+jO+Unpatmzz7uhmSx hFQu4oUAAggggMBECJwer7tTevXuvKrr4o8fP/eRc6WQcnUIVxvfQzff57dqMeVRhnAHF2bU5upJ J8YL5RvYC11s31tXdAzfTsQNGscxCHjjwBrPW30BShWbk2WLrzdIHaGLZLeIBcmiCT9frjaHYfTj +SFYWTBRWwUr9U3+KCVRHpd/L9dXTOEHzbo2BDvQNp7L4b0IIIAAAgiMWeCShVdX5M3X+V/++1kU x6+XXXDPi228RIZkDw7CYjKE67e1HG1hRvX7nN9RY8/Dt6px0RNN3VeXx3xRvHFcAgS8cXHt+80d 7oznRK54lnH6jfJwrzI6LBgjO8LuY9HEYG9dMnk1jmTBRPSE/Lu4PY7iH0Vzzc3JfAleCCCAAAII TLJAraDyl+S0X2otr1xWCOMLZA74+bKo7xgpinyIH2mqztUbZYu0PQ3fqvAOvWXzVR2m9N9RV7S5 aeEGqrFO8H0l4E0A6MaNi4O+kxufIzPpSs66d8guE2f7HjhZ+LDPgsS+Xp3v8o4rZSUbSf9BguBD Mo/h+gYbfe/04oZHkiFYHvsJuEscAgEEEEDgQAWai+s2yDE2bKx702e29z38KhOrS2Qe+Wnyd4cH hbrQh7ykV2/X167Dtzo4Q6o8nCE9gu8088KvtduX/HfUUHlcOjN6D/Qa+fyqAAHvAJ6E9vkXF6Ou h58z65TiOTIn4R1SU+hME1R76/wchT3XrpOfe/zcOgl3UTTQryoDT0oN49vlL7730DPH/KLWNX4A V8anIoAAAgggkJ5AMgfcqO/7X+221CwL/94gc/XO8QszZPh2zj6Hb/0c9KQwv8xLV+qz2sZ/W+xV 327VK3+o+qNHZEEGo1YHePsIePsB2L51WZ2aW3+M2rL5wqIKLomNemGyIjYJdskWz6Mf1T/MUuKk Ngz7rI0rMrfOXhNr+4Omwob/9Z+03FfG44UAAggggMA0EWgyba0S9Fplrt7RMsv8jXFl4LWS3I6R sHeon1O+x31wk5qvtaCnzfOUDlcX4+gdus59vd2VfiArbzdL0Ht2mjBMucsk4I3jlrT2lmaH9epo 1WjO1zZ6h5Qt8T95JMFu1K1easdOhmElAPoq4VLmRBZNxPcbFf5/Znbf95YPyPJ0XggggAACCExz AZmrt1ma8C+/n33BFZt7tr5Kpp+/Ub43vlD+7ggZvg32Pnw7uCDDHCHfMD+mo8p7inX6263l0vdU 1PVA86xO9r0d5/NBwBsDmO+xC+eGxxaK+s+lG/rtOvAP4L4XTvh5eH7yaVQpV5wtPyEde7+1gbtS NdprlnffGjG3bgz4vAUBBBBAYFoJHDVwXe9RobpaLvrq9nLp5TpUMnw7sFIK9T9Xhm9nJ6NdslvG bqNdg/P0ZCRMvn8ukP/39wUXvVnVz/svGQb+UaRV59C2m9NKJJuLJeDtxX3jYlk8cVfjsWaeerWs l3i3PHDHJsOr+6hfNzi/zu80oSrlzdK990tr9VVSkLi6EWx3NjebsyKAAAIIIDCZAvJ97yY5301S E/YYq+a8OYr6Xy2jWsfJ98l5/jpG3f92RNAzC5UJ3yejX2+v08H32vXKK2XP240M3e77LhLw9mAk +8QeU7xbnSd7ur5bHsYX+LftO9jJFmLSa2ejco88tI9a534Wav2tpUH7A/u+FbwDAQQQQACBfAos NXc8Ki3751b38n8P3cCbZVTrdTJH72SZvrTAV/MftZ7eyB692TJy9nYdV15XLJor28vLvqEOVQ81 dVNeZU9PDAFvFxn5KeOoSBXPLlj1HukebvJ7v0qh4b1sJVZbEevfF1eetbYicxDMD8ta/WezaX8y n/9UaRUCCCCAAALjF2jWN22TQPd/N9aV/nN7n3ujq5TfLNOeTpIqFAdrqUKx96DnV91KIFT6/TJL 6rVqW/zldr3sxzecvP2Rls5O+UbNa7gAAa+m0epKh0oBn+Xy+LzHKPMnJjDJVmLW7xM76qsa7JKe PRt1Swh8SHaq+F45qL8yeYB5IYAAAggggMCoAkt88X6j/nNjf+l7PUH8einq/yZZuHiqBD1ZeSvf f5MdMnb5/jts1a0UWH6eBL3PGOv+bNU9jV/u0KVfyiKPx+HeKTDjA95GV5rfo+yLCk7/tewTe7GR MVk/FJvMC9hHsJP3bJMVQp2yN+z3y/KrWd9KsONfFwIIIIAAAmMUWFKtd/ftqxbM/96iLSe9Tqv4 rdqaJdqER/hFivsKejI3/kzt7Ddk4cYt7W7F50M1+/al5qanx3j6XL9txga8rfMvLmza9sTJRRe/ XdZNvD0Ig2KyhHsvBYqrPXbShVwLds7ob8+drb8vP4nsyPVTQuMQQAABBBBIUeCS7u6KCm+/un3+ /B/pLSetcnHlHS7WL5KQVwt6sjVudYPbnS/5s3WR1EuW/W51cLbsqvFiq/t+1GpX/kejju5eotu6 U7zkKX/oGRnwZAHFc4tbHn9NUbn3SRFGWRnrx/33vPOEr2HnizXKqliZYxffI5MAvjUU7NhGbMo/ 5FwgAggggMD0EGjq7o4k6F0rV3vt+mjFK10cS9CLl0nQO0yb2mKMXTYTcMnQrZVFjqYgCzH+vBBV LuxR+jvtpvR1tSC6RxZilKdH6yf2KmdUwJMFFI1W1S+rc/r/yNj/SyXxJ/PsdvupoGY8uE+srVT6 pNfuIevMt6JgdnWOHcFuYp9EjoYAAggggMAwgeW1oCc18F6j4/I7ZZ/3F0kdvYXJNKrd9rv1IU96 +OJkIcYcCYPv1pH703hL+LmOoPTDmTg/b0YEvPb5y2TP2PqTi1aGY5V9mw7Doh+KlcURo/5jkp8C 5AEpyANULkeVgd9J769fFftlmWPHqli+/CCAAAIIIDCJArIV2k+v6rr42uMbH3+zjfrfoVSwWHbG mOtDnp9aNfJVrVXrrF8IGRwVOPV5Kau8qj0qfS4qN7Y3z7pu+yReeqanyn3A6+gtHR1a8xpj4/fu HI7dwwIKSXKB7BUr5U7kuRl4RPaIvaZgzJcl+VPHLtPHlJMjgAACCMxkgUsWXi2T8NQ3pOLFT+tj 9ba40v9XUkdvkQnrZP58ZfftQmvz82RyngzYhec6XSkV67u/3G5XfqPJrLt/JljmNuDJvrFzi/Vm hWxa/I8yx+6lg2VP9jQcayTYSe6XbcUGHpP33+iM+nLJ3P6bmfAQ0EYEEEAAAQSmg0CyVVmoPtMh Qa8Sx+8O3MCrZJGFBL2i75zZw0KM2G99Nke+t/+DsdF5Mrfvk5IJ1krnzZbp0Ob9vcZcBjy58ScU 6t3bZLnr38jEzLl+np2Tve1Ge8lSbD8x0z8Y26x1G6RQ8WdeXPz1/+wvKJ+HAAIIIIAAAukKJCNr ofp7mZ/3XRO791pXfrlUujhS1tPW5ucN/54v3Tc+A/jevCB8gQzrfl92mvpOu1t5hVpw5N1N3Vfn chFGrgJebRHFOcrpj0paP1XJ4Pue6tlJ167c6GQ4tt+Vy5usNl95+Jmjr6x1A6f7ZHJ0BBBAAAEE EDhgAZmf9xsZg32zhLXzZb/aS/1CDPnenizE2G1+nh+2lXl7yfd/E7xZR/E58ZbNn83rIozcBLx2 u+z5xoaXKu3eJitointcHZskeBmOlbIoUvbkIdkC70cDYfmKZn3HE00L2w74YeMACCCAAAIIIDC5 Ak163fVXPXPxjX4hhorL75YUd6pEgVDq6VVX1w57+ZIqLnZ+EcaRgbPJIoz1dsVnbZdd17QwP3vb TvuAN9hrZ6TXTrY3OVUG4PfYa5cUKpaAF0eVp7Rzt1gTfkYmWzLPbnL/HXI2BBBAAAEEJlxgcCFG u1t2k4nNh2QY9tVBWDhSvt+PWlYlGeHznT46PDeOo+VmXrhG6uRe1Wza/jjhF5fBAad1wGstl04q Gv13Stu99tr57li/5YmLKj2yZ+ydMhr/pRVSMTsDb06JAAIIIIAAAikKNOkNj8j8vPfcZkvXq8rA h6Tm7YukrMpsGcJNCiLv0p2XbHQgvXnz5GOfK2i9VLLFvzYX2+5I8RIn5dDTMuDJCtnZxVCdL+Gu RUqfLK5tHzYq2ND2YlH5dzLP7ltzjf7yEt2+dVJ0OQkCCCCAAAIIZCLwYtN2XWt/aV2xXl8aVwbe Ip09J5jQz72XnrsRw7Z+EYbU0/M1cLW5uGjiZe3lFR+JooXXT+e6edMu4MkK2ecU6uy7lDMfMGFQ n+wdu+v+dPIoDS2iiCrbZT5em7OFNU3FdUyyy+SfGSdFAAEEEEBg8gWaZ7X5wsafaA9W/kz3xx/V rvIymZt3iA90uy3CsDI3T/4nvXmLJFh8u1Ds+mKHLX15qWn73eRf+YGfcVoFPClQeKZR8eWyiOKV 1f1jRy9YnCyikJsnxYrvl7d9fc4s/R9LBtbtOHAujoAAAggggAAC002gKV63sf2QZW/SW4oX28rA pX7OvvTm1Y3Wm+fn5snoYJ126oPSQbRUSrGsPrHr6LaF1WLL0+Y1LQKeDMkeFNbb8wIXf1K2mljk JGXLEpjdkJMtxiTcSVdsl4TwG61RH5cl1Hezb+y0eR65UAQQQAABBFIRaOreEMncvO/Kbhg3hS76 oKnYP5e5eUf4QJfkimGvpHevWjfvJSqKfvRg4+Y1D9szrl5q7ng6lYtL4aBTPuB1uDOOKdap92hr LtVhIGnbB7vdixb7uXZ+8qSNBu612l5x4sLnfX1h9/RK2yncXw6JAAIIIIAAAsMEZDeMJ2V07wMd qnSrjPR9xC/C8Blit1HB2upbmQ52sBRKvsKqumUdbuUnlup1904H0Ckd8DrsS5qkOnWL9My9Yk9D srJFidJ+i5Ko/Kyy7oZqr93td6vu26eDP9eIAAIIIIAAAhkIyNy6n8q8/julJt4nrYrPN4W6g1xU 3q1uXtKxJCOEWhXeJL19p3bolZdee8rTrS2dnbssyc2gEXs55ZQMeFvnX1y4v+uRPzUu+rSUN5Eh WemxG3VINkgWU9hy+VFl3L/bZ6Ir8lSkcGo9KlwNAggggAAC+RKQLc9+137wsreYLeGlttz/blmA cayM1+5hAYbPeeGpslHCVavunvcRKafyY1nE0TNVRaZcwPPz7eqjzW+W4PbPspJl/l6HZK1k6bh/ vTF69XJz+41q4VRl5roQQAABBBBAYCoKyNy8sszN+6wspuhw0UCL1mFJ5vMXZCvTXS5XpoHJXD0T hkcFsfqqqXfHymYLssp2as7Lm1IBT6COKhTt+6Re3QdkPFyPtkp2aEi2Un7WWvezMAxW+wQ+FR8a rgkBBBBAAAEEpoeALMr8VYcuvT620WU2thfLAoxDfMjbdQFGsp9tENTr2F4eu/qj29WyTzaZDQ9N tVZOmYAnW4s837jCJ6Q37nV+5YobpQSKNiOHZNWz0RVLc7Rv3FR7OLgeBBBAAAEEZpKAdBhtUYG6 dH101gapyPERbcLF2kgm8atqh738fvY+kxil3iojusdJGbd/kq1Pb5tKVlMi4LWXS2eJ0+dlMcVS X7R4t+KDIuYhfYyO4jJDslPpCeJaEEAAAQQQyJnA8vDW78qQ7V1BFH1cBeZ8GbINdx2yrZZS8eXZ pJRKHH+nPVrxgRMPft51U6WCR6YBb/Hiy8w3N/3ytSbQn5ZwtyjZI263XSmkDk0oy5ejqF+WWvw4 DIKPMSSbs39JNAcBBBBAAIEpJuDr6G5sKL15R5/7jI6ji2UBxkF+P9sRpdp8ebZY5uX5BaGxu/LB bY98bFN/6craDhqZtiizgNc+f1nxtrt++WdhoK+oLqYYZVcKGaoNpARKXO7vkpj81Uq58VMrZl33 bKZinBwBBBBAAAEEZoTAkoG2Z9oXLPs7t614vyzAeH9YqD/Sh7ykQ2rYy2cYCXnzZOj2C8WCPWJj 7+LPLJnV2Z0lUiYBr7WuVF/cov5aejY/IRMV542+mEK6PU0ou1L0PyJp+d+Wh+1XyCoXXggggAAC CCCAwKQJJKtsjfpcuz1rs2SSNSYonuT3W9ht9wu/+MKEssOZ+nBPYb7KOuRNemTa2HtBQzHa+i4Z eP2EDsOGPS+m8HvNlu9Q2n14eSAlUHghgAACCCCAAAIZCTSZW38o8/IedpXy52XksVnWBujdFl/4 fWz930+BkDepAa/196WDiodtfY+skr1Mxl7r9xTufKGZ2NkbnYn/QZYe/zaje8lpEUAAAQQQQACB IQGZl/cb2eLsLyWkfEoF7k+NjNlW5+XtfPnQNxTy6uYrKQH3b1nUypu0gLextzSv7jD3DzJI/WEp IGNGDXd+Lzgb98uWYz8IwlkfXKpvmjab+vL8I4AAAggggED+BWSLs9+1Nlzw9rBn62MyUPvWICws iCO/jkD67WqvoZDn1D9aV7eg1ZZamo3sgTuJr0kJeD7c9RZ9uDPVcCddmLu+ZAmyrDKu9Ftnv7Kl 8sxHXlVo65tEB06FAAIIIIAAAgiMSaB54Lrtsi7gQ+2utFlF0UckwxxurfTkDasEUgt5Pve9sxDb Yqsq/dNkhrzUA15r7wVzC8Vt/2CScGdGCXcyGy8IZL5dtF2y79cPmr3wn0rh7YS7MT1ivAkBBBBA AAEEshJo0m1fXK9LPbJm4ONSRuWIpFbebiFPFo0q81cF69xGVfrokknqyUs14F1Td0HDwnLX+2R7 sVq4G1kJWkqf+GXFvufuGafNv0YN7nNLBq7rz+pGcV4EEEAAAQQQQGA8AstN2zfX25LU6y1/PCgU j4j9nLwRIc/6/i1lrHrrDuvURl36xyW67anxnGN/3ptawLtq6/zC8fO63qkD9WFJcdJzt5dwZ8xn bjh567+0dHaOLCyzPy3icxBAAAEEEEAAgUkUSEJeVJLSbuXVEvKOHj3kyXarNn5rT+x2tM6W4dqB th1pXmIqAW/j4sXBonvmvVnWCX9CtqGYtfucu2E9d4S7NO8vx0YAAQQQQACBSRBYHrZ9s6Nc6opV +bNBoW5RHJVHnZMn9fPeU9zuHm0/dNkVUmNvlF0eJuZiUwl4PXfP+zOjzWf3Hu7Kz2gdfPrnJ2/9 ND13E3MzOQoCCCCAAAIIZCewtNj2UxmuLceVgS9IyDtuDyEvUCr6Z7XFbFn9z6v/q6WlZefy2wm8 9AkPeO12xYVGgpuMN88ffVjWL6iodEu4+8z1pxDuJvBecigEEEAAAQQQyFhAhmuv64hKMng58AXZ 9eL4URdeSC04HVU+e+4//WKrUrdfl8YlT2jAkwrPy02s/t2EwXOknp1c78hQWl1QUe6VcPdZwl0a t5NjIoAAAggggEDWAkvDtuulJ0+rqPxlKYZ8dLIl6y4LL6S0yiFax59tL5e2NhXbbp/oa56wgNdh S0cZpz4lZe6eW92Ed5dwZ5Keuz5p31eemjXv8y2dt7KgYqLvJsdDAAEEEEAAgSkh4HvyZOHFP7nI b21WPCQJeYPZKAl7fnVtIPvaVj4v9fT+WkqudE7khU9IwGutK82u61EfkS3IzpZfsgHvyBWzJgl3 cey0+9rT5e6Pvipsp87dRN5FjoUAAggggAACU07g+jXnXHX+5WuldIqsrg0Ks+2wjR6chDxJTLIH RNjkrPtEqyn9bbNue2KiGjEhAa/Yo/7Caf326sa7IxeE+NovMlwrlV/0VXOMunzFrE7C3UTdPY6D AAIIIIAAAlNWoGXNGrexf/GXdhTnHSk7XVwqYc5Up7BVX37EU7KT79h7dTG2f2ydfcEHZJeM3olo 0AEHvPaodLZx7nIdhgUX71LrTsKdcpJPnf7JnMC9Vwr7dU/ERXMMBBBAAAEEEEBgOggskY6tja7U 0hPro6TX7iLf8SWlUnaGPAl8Ogi1i9VfF/ue2SDbXnxrItp1QAGvvbzseSawn5YLO0zGYH0W3XlN MlQrSVWK/g2srwT6/YS7ibhdHAMBBBBAAAEEppuAz0AdwRnvj+O6BUFYfLn0fUlkGhbypINMevIK Ko4ub1crf9Nk1v32QNu43wFP5t3NrYvd5bLF2NJqN+Oo4e5xbdw/Nuv2xw70Qvl8BBBAAAEEEEBg ugos1Xc83h6U/t7F5e/IvrWn21hy01B28v9tlTP6aOPij7faxX/VbDqlhMr+v/Y74BV7zJ/Look3 SsmT0efdRZXtWumW6y5/xS1r1kz46t/9bzGfiQACCCCAAAIIZCAgK2XvbnfL/t5ElW/L6OfRLllZ W30NzseTharnh27eX61uuexzLS1r9rsI8n4FvA678hSl4o/47sRdV8wmY8uRlWl38TfdQnflGplg mIEhp0QAAQQQQAABBKacQFO44Zb1dsUaF0Vf0GEwe/j6BZ+pdBAEJnYfXLX6lg65+F/tbwPGHfBa Dy8dVPx91CLlUI6pjh8PH5o1suTXDyzb6xfqOS3Hd9+U2h5r+9tgPg8BBBBAAAEEEMhS4MGue79z wryTSjIm+9ZdF134bCUh7zBtK59o7S29oXnW/pVOGXfAKz5h/lxC3av8st6RJVEk2vmSKFH5PmuL /3B8eFNXlnicGwEEEEAAAQQQmIoClyzsrrS6cksx0ktNofgCmfI2NB8vqY+njSym1U3FOvW+9vnL PtbUvWFgvO0YV8CTSstLjHX/KMlylKHZpJjxDinZ98kbPnF2Z1PLuvFeC+9HAAEEEEAAAQRmhECz vmPzer3schuXv66DQuOI+Xh+qNYERsfRu8228FeS9sa9X+2YA97Gw0tzzO/V5TICu/vQbFLvzpdJ sT8+8Zljvt90AJMCZ8RdpZEIIIAAAgggMOMF7MH3X6O3nPRtFUXvla1eZdHqsF1c/QpbY2bLjmbv 79Avb1uqxzcyOuaAt/1Je45x+kIThtJTN3Jqne9IlArN9weB/sTChVdXZvwdAwABBBBAAAEEENiH QFN3d9QamE8VInuG0eHK4fXxqqtqJabpuNmqgdfJob4+HtAxBbyNdaX5Qa/6WxkULo5Il3KmZN5d HPVZFXzuL0/e+lDnhG6VO56m8F4EEEAAAQQQQGB6Ccj+s0916GWrJUt9X4ZlDx9eVtjJ6KjkrEIc 2/fJXrXXNZu2J8faujEFvJ4+8zqtbLPaZWGFD3cS8fxuZNdEs+xVnZ2dw/oWx3oJvA8BBBBAAAEE EJi5Ag33bm/tObnxK1IyZbWsc5Ch2trWrz7tyQIME+gTwzh+6+rLL/uk3992LFL7DHittnRYQZKj 1Gop+iQ5/OVXeUji/H3FqH9uHmjrGcsJeQ8CCCCAAAIIIIDAToElSzrjjbb0tR7l3iA7vZ4s62jl g9Uc50dOZai2IKOo7z7n8rU/kFlxD4zFbp8Br2jtn8kkv+dXz7IzNMoOFhLuKtaa4MthY/k+1T2W 0/EeBBBAAAEEEEAAgV0Ffnj5OX84//KbPxPH8VeMCetHlqKzvmzKYcXY/k37gmUflrIp5X0J7jXg tdozDis4/Xbjy6IM2xTXH1RLxJTA97Asufj20u4NFDTelzQfRwABBBBAAAEE9iDgh15bGy74Sdiz 9Z0SsJpkCa28szrzrdqLFwSyT9ibVVf4A+ng2+cesHsMeKtXr9bnf+zGi+Ugu/feyVw8WTVbVi78 j7ix/Ed673heEUAAAQQQQACBAxNYu+jhnlX3NH7RxXaJlE2ZO6JvTUZRjTGNsh3spa1zSnfK1Lj+ vZ1tjwHvnNU3LpApd28LwqBgR5yhOi4sf3XHnMB+ewm9dwd2N/lsBBBAAAEEEEBABFpksWprf+ma YtG9XkZOXyvddr77rtqLJ7+bIDTSm3d+2BeeKB18v92vgFdU5mVOxyfIWKz0EA6be+fLotioX7bS +NIPL3/FtiVr2rgpCCCAAAIIIIAAAhMgIHvP9qy3K77krH65BLp5I8um+FW1eraKKxdv3HTZPUuW rBm5+nXY+UftwZPNbWcX6+xbZCGF1L3b5XPlTPJ/d0eRuXasS3UnoL0cAgEEEEAAAQQQmBECDy6w tx2/JbxJOthekyx6qKW8avHjIJQ6Kq/sO+U3nxeMLXsCGTXgyWYVi+WgZ5mC0cN3rZCDyo5kkVRF Ca5sPHPrDkVR4xnxoNFIBBBAAAEEEJg8gUtklWy7WvbvWgXnyg4Xc4bK1CXbl2k/uHpCpJ45e/Xq y37csoftYXcLeBs3Lg7M892bVKBnyzDsiNbUqrI8YQJ7zZLOzj12C04eAWdCAAEEEEAAAQTyJ/D0 7O3th/bO3yhRbLkflx2siyc16nxj62Qy3iXn/Mvaa9WAGnWxxW4Br+vkxkNlVcVrJTGGw4dnk7p3 Npbae+baqLHyFCtn8/cw0SIEEEAAAQQQmBoCixZdVO655+b/kmHZM2X1bGEwk/nOt2SUNqqcHfYV jpHFFveNdsUjAt7qyy7TUmTvHKXtIdU3D+vBq4bHLmPcd5ePocDe1ODhKhBAAAEEEEAAgeknsKRz TdyhSz+Xda4fk2l4hw8fU/Uhz2k9R+bRvXHjKYvXjDaqOiLgrbrh/oIsx32FRLni4LLchMTP77NS LMXp9ufUH3unGmDl7PR7VLhiBBBAAAEEEJhOAtG26AkzL1hro+gSbbQenDo3uNjCRfFr1T2NV0gv 3tZd2zUi4IXrNx8kobBJJXVWdk6x83vOOukLlC68n5yzaFG5k8UV0+n54FoRQAABBBBAYBoKNC3c MNAelb4v3Wyv1TqcpVxt4zAJaxL4lA7cogEVnCqbU9zS0tIyYuHEUMBLhmdbbn6RUvGR8jm+lPEQ RXWFrn4mMnpdZ+eaasU9XggggAACCCCAAAKpCkRBV1vBzntQgtipw0+U9OY5VSw723ziF+67VXVf LR1xO19DAe/EK+6XbWXtuTKmWxyx76wPd7EfnlW/UQ2NT8hqDV4IIIAAAggggAACkyCwufHJnhO2 zb9WRlZP1saEQxktqXRiAolpp5/Wt93nudED3tF9m2fJB5tlpYZ88vDeOxmelWJ40qt3Y9jwdJmA Nwl3k1MggAACCCCAAAIicEl3d2W90uvkP/9exmXDnVuX+WFaSWexPbWrr2uWzMPrG7UHL+xXx8pq iucn8+1sbYzXv9OvnlWq1xq1rol9Z3nYEEAAAQQQQACBSRWQGHeXzI97VqbMNezsgpOA5zOaVoeF KjpRLqh9t4AnlZD1qo/98lSfDHctbizDtrIU1z0cNeh76b2b1PvJyRBAAAEEEEAAAdVf3/hsobfr ThfH547cusyvmLBFY8MV7QuWdQzviEvm4J146f2hrMY4TrY4C5P+utrL9+b5CXiSENeHDUdXKI/C U4YAAggggAACCEyuwOYn5lYWNXa1W2tfZrQUPR5cCOvr4SldkOy24ukntn9FzVJDQ7BJwJvbv7mg rDpZ+vlkbHdkcWNZPVtR1myce+tdkVoyuQ3ibAgggAACCCCAwEwXuP+K50fHr/7Fr6X3riK/pGZx VSTZ1ULWWUhf3JlH1DfMkb8amoeXBLzGRiW/65NNYKSI3m5VUHxBvPuWLGHv2Zn+gNF+BBBAAAEE EJh8AV/jrt0V7zUu6pFR1VmjzcPr1/WylkI9PXh1ScCrb1DzZardUdUFFsMLHEuJFKX6TWA3TX5z OCMCCCCAAAIIIICAF4jqn/5j3Y4Fv3PJdrJ+Ql015lXL4Tldb8KDh+8wmwS8yNnjtdRSGbH3bPJJ VkkFvMfKfc/skHFdXggggAACCCCAAAJZCHQ1OluIt2hnhq+z2HklsqVskvtqr3D14sVm1d3mefLn 3erfKZsssLizcZfieVm0i3MigAACCCCAAAJ5F2jfuqwuOvKQoiys6F903MPuhveeF/sh2uZZbT23 Ryt2DrPuAmGMFDoetowiXPXkXCPF8RZoOzz3yWf57cqcibWOH9t+5Gmx6mYD2rw/VLQPAQQQQAAB BLIVCBeEh5jerrcd3yijp9vC+PyP3djXbtUmo8OiUuVDR7062ZY2itXBWxdcXLhfPZzEvPBhtUif oDfPl3wndfSG71Pr+/lkZp4yzz78kHJNC7NtMGdHAAEEEEAAAQTyLtAvm0sUnX11UKg/LZk6J5Ps Al+2zle8kzWxztcnHl7xxEmnnlN18oG/fnDb5ueEQTGS5RTlcJF62DhVmC/hTlZYDK+C5zvxtHWR e/rjZ90Vd9KBl/dnivYhgAACCCCAQMYCYWP0rNkWfstW+j6vg4KxsQS4wXg2PNjVrrMW9gIdBOdo E5xjAql8F/X2hVIYzxzeMH+OZLuR6S7JitKFF5qtnZ2du9VOybj9nB4BBBBAAAEEEMidgN+N4k69 7GcDLvig1K57TrUXb9/N9FVQfO9e7b0DYaNqlHRoj5QSKX7bip1HkP3NJPHZSJvufR+WdyCAAAII IIAAAghMhMBzGxf9/qFtm69xNnqX1oEZpUbxHk7jc1zyy4VdMsnuMGUOSmrgDQt4yQw8P/Drom27 9+1NxOVzDAQQQAABBBBAAIFdBRZ2X115UK34kdQ9ebPRes5YevB2PYb04El8c7pBiqpIotu1D1D+ HOlYyboNXggggAACCCCAAAKTI/DHhmduP7R33t3S1bZCopqvbTKeEwdhY+Miu33Hwz2B36JsZ2Hk 2kG0CsOoYTxH5L0IIIAAAggggAACByawaNFF5Z571n5bJsudqcOw6Pxii7G/BsKuroddoWi7peZd tTLysE+W/5a/DA8a+/F4JwIIIIAAAggggMCBCizpXBN3qDOulQoo/0c7dexY+u/8copkvp521yVb lclrt1joV+JKh54uGNMwvl7BA20Sn48AAggggAACCCCwaMGJTz249dHrpffu3VICRRbV7r0Xz6+n sHG02Rr9GRmibbS9vV3PCKOPfCNX0srkPGtt3erLV2u/TQbUCCCAAAIIIIAAApMj4Bdb3K9L35dw 9hcyzHrQ3jrcJACqOIoq0ov3+beuftl9soq2yxW165Mst0uZY5/ntLEVdcRFF/1Ajt05rsHfyWk6 Z0EAAQQQQAABBPIrICshflPXYzqkoPHL9rjYwq/B8KnNuXaj6r7TuWaNrQ3R6mg0Gr87hjNmwV1H nGaWEPDy+/TQMgQQQAABBBCYkgLvWHRO+Zv33PwtKVp8liy2qHPx7pEtKXVn42es1p++vuWs7qUt LSo8uWFT/GDPSb+XBRaxTLoLhrr/JN1p7QKj7fPmNtzlg2BlSraci0IAAQQQQAABBHIq0Nnpe+PO uMWq4uOyguK4XZuZ7FORvNxPzjs4/mVTbUpdeMWll0bnXrb2fklwkexdMazinR+iNcY6e3RjlwS/ WTmVo1kIIIAAAggggMAUFri/6+Gnjms8+aeyguL91Z0tds6aqy2seNQU9We6ZZuzwWaELWvWuPZg 5WbZDkMWXewsk5KsopUJey6WtNioBlfbTuHmc2kIIIAAAggggED+BC5Z2F1pd+EPjI3+Shm9cHC0 1ec0KwsrpD/u3978Ty+7v3NN21Djk+AWqrmPWNXVL5Fuzk4WP0QrfXpaHVrf0DhP/r47f2S0CAEE EEAAAQQQmAYCjf2/tVsKbVLe5JVJQEte0jHn3G1BbWHF8FYkAa+/r6unWLB/cMYePHI7C+nGk4UW ZWVPkLc9Og2azyUigAACCCCAAAK5E3jrEasqV25be7VsK3uuNmGdD2jWRtt0UPnkUnNT164Nrg69 NnZZ3dv4qKzAWDJ8uzNJhX7NbSGMzQvaD152S9Owsd3cydEgBBBAAAEEEEBgigr4xRZGnXGj0/WP SgfeiVa2LpP+ux8+2PXgLcsX7n7R1SHahrkV16fvkX6+P5FB2dANDu7KdhcyUFuQjsAXR33hf8hb Ry2nMkUtuCwEEEAAAQQQQCA3Avd3ndh9QuNj/0/WTXxM6qL8ThZPfMHPzxutgUnA+/mlqyrnXfbL DqODSHrwwqF8Jz14xoQy3FtervrL8yUq/iE3SjQEAQQQQAABBBCYRgKXLLy60mFX/ih2lb9yQfAl v2PF8IUVw5uSBLw1spI2DEq3W6u6pdvv8OF7kvlpfNqZhUVVPH316st+0dKyhi3LptHDwKUigAAC CCCAQH4E+huiB8Med0XUZ//T71ixp5YNlT95sr5x6yE9XXfp2B6WrM7w8+/kNTgPTwZnV6z6wg1r ZS0tw7T5eU5oCQIIIIAAAghMI4HmgbZeKX/yr/sqYDcU8A5peLqi+sNWWZLxUtnQouhUrYiezMOT onqB0/bF0ROmTgoeE/Cm0YPApSKAAAIIIIDAzBMYCnh+hWy7W3mzrKP4sBTRKw7lOz8PLwi0i+Ol ql4fL0R3zTwmWowAAggggAACCEwfgRE7VISqcK9zlT9o544fPtEuGaY1enbBuddtXLx445LOzp17 ZEyftnKlCCCAAAIIIIDAjBAYEfCiBYf0mK2P/kL2vVhU3eusOnfP/y6b2YayB9qFalPj52U1bfeM 0KGRCCCAAAIIIIDANBQYEfCauq8ut7sVPzHKvFkbPXewXIpfcJHsS+vs87er6PTVl132K7+H7TRs L5eMAAIIIIAAAgjkXmBEwPOtjZ6z8Nfh77d1Bk4tlQIpUiSltppWaqjIn4omCi5edcUNt/q35l6H BiKAAAIIIIAAAtNQYLeA19h4Zs/2J27+sXPxGdJrF8r2ZUmz/Dw8+XMgw7Srwm3hYcqo30/D9nLJ CCCAAAIIIIBA7gV2C3hLOtfErap0ndRJ+ZCUwzt45zhs7b+0PjKy8Z9LwPts7nVoIAIIIIAAAggg MA0Fdgt4SRsa1EOuR7c7ay+Ubjvpvhu22CIwBRW7v+5wpe8t1W1PTMM2c8kIIIAAAggggECuBUYN eO9YdE7565vWflfH7hwdhA2Dq2mT3S1kVp7R6vgotpcklZR5IYAAAggggAACCEwpgVEDXmfnGmvr S9fbHvvrwNnm3XrxZG6eFEJ+q/TiXUUv3pS6n1wMAggggAACCCCw553M1i7q6l11T+MXZZj2RfTi 8aQggAACCCCAAALTR2D0OXhy/S2dnba1ofTzcI+9eCaUIdy3/Y9dds1LzYb7pk+TuVIEEEAAAQQQ QCDfAnsMeL7Ze+/F01IXz5zQELv3XrXg4vde0n11Jd9UtA4BBBBAAAEEEJgeAnsNeCN68ZQbORdP Ch/L7mXaqvgtx297/KdSNuXG6dFkrhIBBBBAAAEEEMi3wF4D3ohevFjm4oVBg4urJVP8S4ohSy9e MMs6e1mHPePOpeaOp/PNResQQAABBBBAAIGpL7DPgJf04vUvvr5YXLBWmrNLXbzqHrXaxU2y7PZN 0ov3b1O/yVwhAggggAACCCCQb4F9Bjzf/OZZnT3t5dIntI3ONDo8cqguXtKLJ3vUyhZmLo7/rt2W bmgybZ35JqN1CCCAAAIIIIDA1BYYU8DzTbjh/q/9etXJ7/qqs1GLkV47W9ujtlr82Pfk6WOMcx9q 7b3gfc2zrnt2ajebq0MAAQQQQAABBPIrMOaA17JkSbzR2a/0WPdqmXj3Qvnlu+8SGamV53vxZIML +5ZiQ9dG+avP55eMliGAAAIIIIAAAlNbYMwBzzfjh5ef8/S5l9+8Jozi7+ggmOtcNNQ6Jz16PuRJ D98/teuzOpvMrT+f2k3n6hBAAAEEEEAAgXwKjCvgtbSscRsXL/7vnrsX/Fj67/5S6qQkvXeDLz8f T4ZvF6g4/lSrOuPBZnPHA/lko1UIIIAAAggggMDUFRhXwPPNWNLZGXcEpU/auPJiUyie4PwwbW2o tjofT6KfNqcVbf3lGxtK714y0PbM1G0+V4YAAggggAACCORPYNwBzxMs1W0PrDely+NK5csmDObJ CtqdvXjJfLxQ1l1EF/f0q9+sPnnx//WlVvJHR4sQQAABBBBAAIGpKbBfAc835fqWrqtXfeygM13k 3i/z8UYO1dqoOh8vrnz03HsaH5X6eD+ems3nqhBAAAEEEEAAgfwJ7HfAa2mRAsiu9IlCbBcbHZzn ZGRWUt7Onjw/Hy8oNCobf6bVrnyy2axryx8fLUIAAQQQQAABBKaewH4HPN+UZt22rTUo/aOJK8dL mDvB2l3m46lk0cWigq1c0Vouvam52Hbv1CPgihBAAAEEEEAAgXwJHFDAq4W8u9br0uU2qnw5CMN5 Nh5WOkUWXWjllPTwnVkw8ac7XOk9Mn/v8XwR0hoEEEAAAQQQQGBqCRxwwPPN8fPxzvvY3BfK1LsP yK5lemiXC/lYbSsz35P3KhvHT0lP3gebZ7Gydmo9BlwNAggggAACCORJYEICXjIfr67UUtyhjpRB 2jdqLYsu3PCVtUkRZCUp721h0T0u7/1c80DbjjxB0hYEEEAAAQQQQGCqCExIwPON8YGtNSz9fRhH C8Ow+CeyWa2EvOpWZv5V2+lChmvtR4s9zrXOLn2ekDdVHgOuAwEEEEAAAQTyJDBhAS8JebrtqXaz 8lJbGfgvU6xfJmVSdhZB3hnyQtn94mMS8hQhL0+PEm1BAAEEEEAAgakiMKEBzzeqyay7vzVa+cFi ZeAbplB3gux4QcibKneb60AAAQQQQACBGSEw4QEv6ckrrmtd70ofjqPyF4OweKSssPX9d0OgteFa evJmxCNGIxFAAAEEEEBgsgVSCXi+Ect1208k5B1qK+U1smftIYS8yb61nA8BBBBAAAEEZqpAagEv CXlh21ck5BVsVP6YCfcV8rTaGCy+Yonu7J6pN4N2I4AAAggggAACEyGQasCr9eR9UQohq32FPBXb y3rc/Hkd7ozPLzV3/H4iGscxEEAAAQQQQACBmSiQesBLQp5p++J6u4+QF0iFZBW8P7b6sHa7co1f rDETbwhtRgABBBBAAAEEDlRgUgLemEOeNioICpdYWzmk3ZX+T5Nuu/NAG8jnI4AAAggggAACM01g 0gLemEKes0rJ/xkTnuviqLE9XvnBpuK6dTPtptBeBBBAAAEEEEDgQAQmNeANhTx3lmxXW/molFA5 PI7LI+vkSchz1ikTFJYqVfnG+mjlB/7yBWdf29m5RqIfLwQQQAABBBBAAIF9CUx6wEtCnr7132UI tqwqA/8YFOuO9SVUnO+9G3zJFmfSg+dD3vEqir955d2//Ei5XLq6eVbbs/tqEB9HAAEEEEAAAQRm ukAmAc+jN5m2/1yvSk/ZSv8nTFh/isy7k5674Z10TvldMEwQLrRWf7FQdMe1upVfbdbrHp7pN432 I4AAAggggAACexPILOAlPXmm7Wft5WXdyvZ/UhcKJWVktHZEyJMpeVZ68qSInjbmH3RUfoHsdbu6 Sa/r4LYigAACCCCAAAIIjC6QacBLevKKG34lZVH+RkXlT8sK2lXaBBLy4hFX6//sh3BNUDxPxZVj b3Ol1eaZ6GdNCzcMcGMRQAABBBBAAAEERgpkHvCSkGfW/bZDl94ZR5XPGRO8VoKcsX7xxfCXzMur DtkWTgqiyjdcozmmw5a+s9S0/ZGbigACCCCAAAIIILBTYEoEPH85S3XbZtmq7F07bOM2YysXB4W6 g+Jo5Apb/75qyAvmuFh9JtbuFOn9+7wPiNxUBBBAAAEEEEAAgarAlAl4/mKWmM6t7Ssu/ru4bfND rjzw7rCu4Rgf8kYbsvVDucaYt8hq2yXt0YqPR2Vzo6yy7eHGIoAAAggggAACM11gSgU8fzOaNlxd ltj5mfV25b1RufcjOigsl5W00nMXjbhXTrrwXBz7IdszdeS+WyjY/9tqV17ZbNY9ONNvKu1HAAEE EEAAgZktMOUC3uDtWG7WXdNul92jY/cJrYM/NWFdvfVDtsqNuGO1IdvZ2hT/SceV5bdFZ336kYOf 86tLuq+uzOxbS+sRQAABBBBAYKYKTNmAl/TmmQ0PtdaV3lboi+6zkfvrsFh/VHXIduSmFjtX2Ybn hC469fgtm/+t1ZSuajZtj83UG0u7EUAAAQQQQGDmCkzpgOdvS/NA2w6pj7e6w561KSoPfMiEMiSr qytqR7z8KlvZEUOGcw/V2nyqWBlY2qGWffbalvNub2lpGdntN3PvNy1HAAEEEEAAgRkgMOUD3uA9 WGpu/X/ttrTJVgYul8UVfyKrbGf7IVsnwW74K5mrp7UyhbrXSuA74/yP/eJfO5y5TlbpPjoD7idN RAABBBBAAAEEptYq2n3dD9ne7O7Whgv+wvR0vU/2sX2rhLzj/EILv9vF7r15Zd+b9zxn9b/HNl61 3qy8olw/t6154LrefZ2HjyOAAAIIIIAAAtNZYNr04A0iJwEtVJ+8LVpxhyr3v1+2MHuJ7GRW9MOz uy/A8L15RgVh3YU2ilYU+575aqteeZXsZ3vvdL5pXDsCCCCAAAIIILA3gWkX8AYb8+Lw9hs2upf/ psf2fEgWYFwSFhuOTIZsd9nmTP5C5uZJb54JD5H/99G6uHL2elf6clmrXzTrtm08HggggAACCCCA QN4Epm3A8zdiib7paRWof1hvV9wRV3rfq1SwXHrz9Ki9eX4YVxbfysfPksC3os6p/2yPS99uKrat z9tNpT0IIIAAAgggMLMFpnXAG7x1y83tV98ZrLx9oBx/WPawfW1QbDhk1N48+YRqb54JpUDy3zhV Pk/C4eeNMjfInrYPzOxHgdYjgAACCCCAQF4EchHw/M04PV73SPvCZX9rthU74nLf22Qd7VKZexfE 8e772fo6erEdSBZhaF28Qt7zP+3l0n+GBfUrWW37RF5uLu1AAAEEEEAAgZkpkJuA529fU/eGSGrm faPdLbtJVQp/59zA64K6+mOSlba71s3zvXnJ9mey3VkYvtTZgZe4WP+g3az4TqRNu8zP656ZjwSt RgABBBBAAIHpLpCrgDd4M5r0hkdUUX1AiiPfEg/0/o3SwcqgWD/bVnzdvJG7YPiVt0mBZBPIwG3x Ylvuf3Wo3Nc6zMqr+xvu/9/mgT/0T/ebzPUjgAACCCCAwMwSyGXAG7yFUhz5v1sbSjeFPfGlUlLl z2VI9lSjC8pvd7ZrSRVfMDmu+GHboF7m510alcsXFXuf97VWveinsuXZXTPrsaC1CCCAAAIIIDCd BXId8PyNka3OfN28f2m3y35hI/v+IAhfKoswjnIyZDvasO3g/LwgDI9Qpm51sdL3almI8Q2rzFop tNw5nW82144AAggggAACM0Mg9wFvaNjWbPjfxadc9pZv3n3DG2wcv0sKJL9IaufN9r15u9XOk09K 5ufJLxMUT9MmuELF5dva3YrvKFe8pcmsu39mPB60EgEEEEAAAQSmo8CMCXj+5nR2rrFNobp6o118 43Y77x1Rue+1WqkzgkK9qe5ru+v8PB/0ZIcM+RWExRcHuvBied8t7dGKbylTvE2C3kPT8aZzzQgg gAACCCCQb4EZFfAGb+US07lVVtt+qsOWfhTH7p2u0n++DsLFganNz5P5eLu+qvP2tAS9wtlam7Ot i3653pa+a1XYRtDL9z8SWocAAggggMB0E5iRAW/wJiXFjY36YLst/VRXyu9wQXC2LLA42n/c9+jt /pKFGP7vtQS9oHiuDO2eqwh60+2Z53oRQAABBBDIvcCMDniDd1cWT9wmQe+2dnvWa1xl4C+01mfJ /LxD/Dy80RZiyFjuXoJetL7JbNivOXrX1F3QcEhf1zK5nl/l/smjgQgggAACCCCQmgABbxhtk7n1 p+0LLr5eb3v8TXG59y9lb9vTJOjNHU/Q007d0u7O+r70AbapxujepPjyGF6rL7tMr7r8hpXahl+S HsX/0xS2/WQMn8ZbEEAAAQQQQACB3QQIeLuQNHVfLcXw1Dc63BnX2bj+TVG599UyIHvqOILe2bLX 7dlxpf/Xqiv8cbsq3RL1qXuaZ7Vt39vzt+qKGwJjzZt0EBwvgfILrba0Verv0ZPHP1oEEEAAAQQQ GLcAAW8PZEv1HX+Q+nmflaD33d2Dnq+hN0rH3ODQrRzThIUXaRO+yA30PVasU1evt2f93KjejUvN HU+PdsqwKzwy1u5lRhu/R+5zQlu5ot2tfFuTXtcx7rvKJyCAAAIIIIDAjBYg4O3j9g8FPVv6L5mR 9yZb7nu1zNHzNfTq/fy8UYOeHNNvf6aUbIEWhM+VXx+Ky/3vjk3D/7utXLqmGKo7ZYHHo4On9sOz 51++9jWya9ohSakWCYqyovdUZ6N/bTWld8m+uPfO6KeUxiOAAAIIIIDAuAQIeGPkkkD2R3nr56RH 76rIzXp7XOl9pVPGD93uNehJSFOx/JLCyrOllt5ble1/q+yK8f9Jj941VtlfRw3qgVU3qEhb92p5 T0GqLku+c7JQ18jnhC8puMqnO9xL3rfU/Op3Y7xU3oYAAggggAACM1yAgDfOByDp0dPqn+90K6/q c+W/kDl652tlFod1s6qLMZKeu93r6PmeOZmXp4yRd4eFV8sg7qtdpe+Ouh59rWtb+6RT7kw/PGtt nFyR3zJN+/fqwqtiWfHRql7+/mZz05PjvFzejgACCCCAAAIzUICAt583/XS97mEJei3tbtl/mdi9 tlLuvcA484KgULcwKaMSS728UQom+965uDKQnFX2xT1DCiyf4bdKS4Z7a+Fu8JL838s2aX6Y9+Ji 1Lt1Y//ijy6Z1dm9n5fMpyGAAAIIIIDADBEg4B3gjW7SGx5OFmPYM75h9aw3xOW+C2Wo9TTZw/Y5 MlcvKZg82hZo/rSD+936HTL29BoMedKV967euvnb2udf/HFZ6TtaFeYDbAmfjgACCCCAAAJ5ESDg TdCdlNWxXXKor27tuvibD8575DWx7XuNBL0XGR0cHxQaqkFvlx66nafefUh3+GXVQl4gifAjasvm be0HL/vSWOvrTVDzOAwCCCCAAAIITCMBAt4E36yFC6+uLFTqB3LYH6x3Z53jIvv62PaX5M+nyDw9 kwzFRr7Eyt5D3a6XVQ15YaBt9Cm3JexZ/ILLvtHZuUaW3PJCAAEEEEAAAQRGChDwUnwilutb16qC WitFi88Mrbq4MtD7Yhm1fb6svF2QzMWLZC7eKPP09nRJPuQZE9TL7//yzbtv3t4UqqtTvHwOjQAC CCCAAALTVICANwk3Tnak+I3sjvGbDls6SvruXhUN9J0rK2RPVNadIH8vpVHGehGy1lZW48puFwtM bD/dEa18dmm47vqxfjbvQwABBBBAAIGZIUDAm8T7LLX0fi+n+w8Jdf/RbldcGCj9HamZMt/F1dIo Y3pJj58voWKC4GhZpPHFVlfqkULIbGk2JjzehAACCCCAwMwQIOBldJ+l5p2VqFY0To+9A2/wWpOQ J8O1QbioEFW+2Bqs/Mtmve6OjJrCaRFAAAEEEEBgigkQ8DK4IVLqpKi3PfomKXpcv6cSKvu6LD+H TwrnSQdg+IKijf9N6vG9o8lsuG9fn8fHEUAAAQQQQCD/AgS8LO7xtieOVVa9RAWh2XPplN0vzG9f JnuYyQe03/oseYMM1cpfBSsrfTu+1KFKH7z2lK67Wzo7WV2bxX3lnAgggAACCEwRAQLeJN+I1YsX m3PvLr9aYtkh0gUnZ5d9Z2W3Cv/yhZHlDz6+SXKT35Mw5/9KPi4ddlJEWTrtKmXfd6et3iofimSb 2wF5wzPyKfPkv0+9SKmNk9wkTocAAggggAACU0yAgDfJN+SiTY0H79DuzcWGg0If4PyCiUr/dquc rsh0vAEZeX1Ga+dXXXTLrwF5T0Xess1oHcuw7B8l3D0ln1Wxxj1olOmzym5XKnw0NLYSLTz6D0s6 28axYmOSG8/pEEAAAQQQQGBSBAh4k8K88yR9LjxYq+hp6Y27ybp4h4pdLEOvDzjjeqVDb4d04D0q aa8sfXOPhmG0Xen63hVh2x/HdJndbWN6G29CAAEEEEAAgXwLEPAm8f6uXr1av3L1fz9ptHrLk3V9 T71qoLNP9rHd+apOq6u+ipN4YZwKAQQQQAABBHIlQMCbxNvZ0tIiI6zJnrVdMnOOFwIIIIAAAggg kIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzs OTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAAC CCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ 8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOA AAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAII ZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVW DooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAA AgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIE vOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgg gAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAAC qQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86e MyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCA AAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigAB LxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwII IIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBA dgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHl oAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggg gAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DA y86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigAC CCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQ igABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5 MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAII IIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDw UmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AA AggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghk J0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYO igACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAAC CCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS8 7Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCA AAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKp CBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4z I4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAA AghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEv FVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggg gAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2 AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWg CCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCA AAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDL zp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAII IIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCK AAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7Dkz AggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggg gEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBS YeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAAC CCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQn QMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6K AAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAII IJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs 7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAA AggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkI EPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMj gAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggggAAC CGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8V Vg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAAAqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCA AAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvOnjMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYC BLzs7DkzAggggAACCCCQigABLxVWDooAAggggAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAI IIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoAAS8VVg6KAAIIIIAAAghkJ0DAy86eMyOAAAIIIIAA AqkIEPBSYeWgCCCAAAIIIIBAdgIEvOzsOTMCCCCAAAIIIJCKAAEvFVYOigACCCCAAAIIZCdAwMvO njMjgAACCCCAAAKpCBDwUmHloAgggAACCCCAQHYCBLzs7DkzAggggAACCCCQigABLxVWDooAAggg gAACCGQnQMDLzp4zI4AAAggggAACqQgQ8FJh5aAIIIAAAggggEB2AgS87Ow5MwIIIIAAAgggkIoA AS8VVg6KAAIIIIAAAghkJ/D/A5L1E1UQSl11AAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image012.png" Content-Description: image012.png Content-Disposition: attachment; filename="image012.png"; size=3597; creation-date="Wed, 10 Oct 2012 09:43:15 GMT"; modification-date="Wed, 10 Oct 2012 09:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMYAAAC3CAYAAABJ5SE5AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA2iSURBVHhe7Z0tcB3JEccNAwMDAw8ePJawSMpV 5eDBQMPAqzo9PbFAQ8GDhoK2doGgoaHhQUFDw2R6dp9Ptt/2fOzOTs/uL1UqX+XtzvT8e3qnv+fF C/4HAiAAAqUR+Nvx8U//PPZ/l7+rQ//L5aG/vbrpX1/ddI/uvz+4//5f1N+h+yTvDH/9vYzjx7p+ +Pfn8Y+Pfym9HsYHgSQE/nV8/LNsUL9hb7o3SZs+Vjginrs8dB9Hobu9uH74+er48H3SQngYBHIR OJ0CcgL4r/+h/z3qqx+xscuN40+au4tD9x+EJZfzvPcNArKZRvUlXv2pKgi6iuZOlqfLm/43OVXk tIPlIBCNwNWv/YV8Zds4ESJtlSlhPfTv/AmI6hW9P3bzoHw5vV7u1KNBV5+52Rp9/3SayIdhN8xn od8icHHsfhC14sp7ftYTBqeavf/D03TyOCn/1rBlZE5/kuDx2oXsiAEtrk7H9HclhOGzd8gJnNgm YvSe3KpLACzC7F3A7qt+ct2KN6yw2veaU2QJ7hkc4x/HN391gvBqSVXpuYv08vrtTzJHzaU/95oN J+HCws8pUpO9y87tYwzyRV1AVRpjFK8sCEEKSl5lPHQvJUC4lNooglf7Q5CCAc+OCIiXZYwWx0WY Fa+NqEM/Ht9+txVwRbCX8rr5kwk7xP7WGFUml3qRaUwPhvi9t0N2wHAReB/8m6N2DZi92gNe9iXg KwrF5eqZk+thko3hhEH09OYWvxDBsrG9JyrXC+awF4cAgcOFGDJnGNnIg3cmI/4gjHSqwJbUpDlY Pn9X1K1c20x4ITzZ80dmKT5kjTO4LLunVLVJjGgxRvmyhWEX1dQJyH9zcRbDPzwLTyyCgGxob/Sl 2xH3MCqfBZIdMAQn0+w34RUfoXzco94cUrwTTwlnP8h7URPwUBABnz6TaId4npFqEsQ2+QFvS7gj PeVr5VUmpysnT8YLUQiIOpr6keL0iII27qEhQBVf9eaZ5TxMcaPz1BwE5IMl7t4UAeH0mIP4+G7K KSHeEGES3pAFgE8cwtt96d7BO3iVA3RCKod3Le4gIJcI4+qPCw+S3LwSP4JvcXySuEKs6uTjF6hN ccCu+JTwJDa2JKoV3sIAc3xgKTJYxymx4k7PmCrp9PBR8+5lxjTbf2VsMhBM+uOUaGsvpJwektyI 3THy1xcP+Z5LEYEjdNK2pGKkNu30wO54MXozYqOpfE2aFIs/iB4bz8VoBU+7bdAQLRTon42Lw5fk x9qRXmXeW/eSWKHAY7Epmfi8mFjP466Ew2dsxiSjYU9sUyrGVY01NPch21KEY/O5br7CLi4BDXti 02KRaHdIAdpWkxBjhUIMtJ3sCZZ5Sv2ROvRQ9eUWhQOhQAZCCPjWqHsSjtHQDjZF5qQIbZ3t/x4r HJtIIYlJKkMotr/pY1cYIxzirWy6r5Xv3BGIaCMUsVtmP8/FCUf/ocmSWd+bCaHYz25eeKVRwuHK DRaetuxwogMGDSl3mpSlgtFbRyBGOEQraWKdQwBPb1ggdkcTi4HI6giMLUXV/CrzKetjAzQ1KVCi 3qQWV99vTREQVZJgOQAY6vfUvDehqe20LWJj9pbJMtngkeeCN5vwP29rvzWzmqFux99CO6lWmVPR fSFKwK6QRl3NcAFCTSLgEw8DuXam7I1QBR6xCpP7rEmiRufO9CWiTjMx0ah7vPFU8Rp0j01yAKLN IuDvIdRUqtoOnlGFUqW36dC92a0BYaGsCmnWVw2lUB6UKX2vGkpMXAKBMTSgJqdWKXAKpXyY8xCU 4A5jVkXA37Wopao7Q33VmNkgrdPR7aFWl8vTq+6anUweCv6tqlL5Cw21BEHaZu5kW9pYphrfkBNl jY906LQQ160NuKBiLwgEXbjuJt7iWKinxVrSWXyVTNAaAiGbt3iPqkCEu40U4Na4Dr1RCGhtmeS3 qEHOPeRD7kr3NzUfitMiG3deXAYBX7+hBf7mXD0nA/v7Kdxl6F8H5wKN0jgtluEvo8xAwO3fySZu ou1ku2+/UZVcR0AJ1IV0OBP5KTMA5dVtIBCKbYiNnLVSd1K8C9Vqn/m9vNWftRpe2iMCWrpI9qkR ypQ9KzR760q9x93W0JolbqFFxLNOjZSbUr2Q+Db9/S3Jgg3tnB2QqoUVsjxU3p6Iud3o3DOjPdJk v58dbJY9LTEUiBYPaxIewRLVWKGxXJyehAgPt4qApv0kJ7l6qz528088R8Veq1tpW3SHbI2kaPh4 oUfwnrRJ4XHxj23By2paRiDgTLpLWlvsXdvfCAdZtUk483B5BFQNKDVbw0e+U9UphKI8l5khCwEt LT1J7Q+VrH4hNFu86SYLfl6yioDmUJJDIJput/Hvok4MhCIaUx6si4CmBUWnM4XKBYdEwx3cplmX l8y+IALano5Wp0IJg7u6f3lB5jBUPQT8PZDT4YU4dUpraOWzb8mNqsdhZs5GQEuQjVKnJqXLtSMh JyqbL7xYGYFl1Kmvjx2EojJbmX4uAouoU8+7SvvKvTVakMxdOe+DQACB2erUKSgiQkG2LPttKwjM VqeGHJPuEaHYypZgHYKApk7Jfg+iJB0XsgvHg6PzAAjUQ2CyqYcLWLPn6/GFmSsjoF4hQCiiMneY vhoC2mVHWfXg1VbCxCCwIAK6nbFCn9sF18JQILAoAlOXXEq606ITMRgItISAVtlHdkdLnITWRRFQ u/ZTdLco1gzWEAKBph9pteANrRtSQSCIwHRvg4hAX3B0HgCBRhGYzJtyCbONLgmyQWA+ApoBPn90 RgCBRhHQOhXimWqUqZA9HwGtT7NUsc6fgRFAoEEE1KvJcNk2yFFIXgQBqfNWGiTcLjIJg4BAawhI ivmkYNz0v7W2HugFgcUQmL6em1jGYiAzUHsIEMtoj2dQvAICkw2fCfKtgD5TmEUAwTDLGgiriQCC URN95jaLAIJhljUQVhMB5669n3LZ1qSLuUGgKgKXLl6BYFRlAZNbRADBsMgVaKqOAIJRnQUQYBEB BMMiV6CpOgIY39VZAAEWEZhy10oOlUV6oQkEVkFgqvGa/P+rEMAkIGARATqFWOQKNFVHQLnP/r46 cRAAAjUQUO/ko1CpBkuY0wICWjdC6SBigUZoAIHVEdDus5e7+lYniAlBwAICV64TyKSNQZcQCyyC hhoIqDe4Xr/9qQZNzAkC1RHQot7ca1+dPRBQCwF3e+uHc6oUtyrV4gjzVkdA7q+fjmHQOqc6gyCg DgIXx+4HJbj3qg5VzAoClRHgqrHKDGB6mwi40+Ju8sQ4Pnxvk2qoAoHCCEx3IOw+SU/bwtMzPAjY RODq0H0675Hq39ukGKpAoDACmuEtpa6Fp2d4ELCJgItf3E7fi9G9tEk1VIFAYQSmAnsiLNy9Vxh8 hreJgFqDccC+sMk1qCqOgBa/EBWrOAFMAAIWEZhs4uzUKG5qtcgxaCqOgM+PmnTTdh+LE8AEIGAR Aa0wCTetRY5B0yoIOK/T6yk37cX1w8+rEMEkIGAJAU2NEmGR3y3RCy0gsAoCajbtDfUXqzCBSewh 4Fyx74l22+MLFFVEQGuTI2WsZNNWZA5T10NAM7rdb1Tr1WMNM9dCQLp9TMUuvGpFUVIt1jBvTQS0 3lESBa9JG3ODQDUE5AIYYhfV4Gdiiwhcum6CiifqCaPbItegqTgCqouWbubF8WcCgwioDZspSDLI MUgqjoCoSJptIT1rixPBBCBgDQE1/cOlnf94fPudNZqhBwSKIhCMWxDQK4o/gxtFQCLZiifqI+39 jTIOssohICqSFuUWFavc7IwMAkYR0C6CEWOcuIVRxkFWOQS0YJ6oVvJ7udkZGQQMIiB2g+aelUCf QbIhCQTKIuDu5H6jXAJDW5yy8DO6RQTcSfFSEwq6f1jkGjQVRcC325zoE+XtCmdw0+SgKAsY3CIC k5e/SAGS/P3aX1ikG5pAoBgCWiv/UbW6KzY5A4OARQT8xS+KCuVOkt+JWVjkHDQVQ0DsCunsgReq GMQM3BoCYkhrl754g5sCpNbYCr1zEBDVSGvhP3ih+g+oUHNQ5t3mEJB4hKY+eZuDVjjN8RWCZyCg t8DBNTsDWl5tFQFpz6+eFE6FIp28Ve5CdxYCPmNWc8sOgTxabGahy0vmEJDgnMQiNML0tv2D+iTJ g+YWB0EgkIPAqSZb8yBp5akntUpSyfFA5XCAd0wi4Db23TOb4Qs1aHDJ9vchm0Ii21xUb5K9EJWD gLhTv970pyuEh6vA+nchofBRb9yyOfDzjlUEzhYUua+/Fxj595QVO/GvFwoyZq2yF7pyEAjVZIeE wgsOJ0UO9LxjGQGtwXJIKPy7rq7b8vqgDQSSEYhxvU42SXMuWarwkiHnBesIRDRYHqrtzv9RbGSd wdCXh4CkgYdUpbO/H/pf8mbkLRAwjkBEg+WzJ4V0/jC+NMgDgXwE3EnwOuu04NLIfNB50zYC54J5 KULCqWGbv1CXiUCo2i4oJFzwkok8r5lFYHYw7+ShcikiZhcJYSCQgsDgnnUBuUB6R+zvkqKeMj/P goBJBOYE8z4Liy9O6h59pq1z25JebpLVEBWLwNDepnuKOg180qDf/HdyKoj6dcq0jZ2P50CgCQS+ KTDyaeTdo6/Yc9d8ycbnxtQmWAmRSyJw+uqT27QkqowFAiAAAiBgH4H/A5/iJuczA0I4AAAAAElF TkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image013.png" Content-Description: image013.png Content-Disposition: inline; filename="image013.png"; size=6258; creation-date="Wed, 10 Oct 2012 09:43:16 GMT"; modification-date="Wed, 10 Oct 2012 09:43:16 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMYAAADCCAYAAAASCr1LAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABfySURBVHhe 7V09cBRH2u7uGXGyhasUkn1k1lVRdXKApV3b9cmRIToUAdGJCBEBESgSigSRcIQcSUTgCIiQI8sF p11BgK7KgS7TZVymr4yMgJ3u73lnd4WEpnd7Zme1MzvvBPxI3T3dT/czb78//bY/Nzcn+GEEGIGD CPgMSLoIPPtLeXBwV4xTqzrA31IMGmm+FFqckEKewP9HnN5ozK4RokplUW8bf/wrrGfElvLEVqON zdNy7bVTe1woFgJMjFhwfSz8uykPvxViVGsxoY0eU0KdpEV/7E8QollM1v8hDf7R+Lfz66QcRJWJ feXP1RtD+3svAHNMaRs/3ZBS/oZ+bApPbZbk2obze7hgJAJMDIeF0ZQCJAGMMn+TWkESmJPNqkoq h1a6UwSEGEbLRKCJsB8gzbooC2PMqlRyEyT6t/DEKpMlHv5MDAteFVMeVVqcw9bl/LFAjIQfafrw h19/bHIy/oAwE+g7yIKOovNVM/5aKm9F6+CXLzy1ckqukaThx4IAE2MfMOu1b88Ipf8utDyjmhIh 7hYoo0tNSnUCYmQKUmVqpy5VqiDOE+2JFZYmhyet0MQgPeGPQJ/BlgNkEGek1MNYLLmQCCnwjwwD 45CK801pgg/Cz2P+85UU2s59E4UkBrZJ48rIy9BiL+ALOlgnQ/fn0mixgW2Y8xZGhgr9R12mWz1s ShO8a2q99s0WTF8/wfK1XGSLV2GIQQr0sR1xAQS4DBUV5lSwQabHBii7tOA3pFJb2LL8Rxux7Xsg Ah4ssNVwUXvJlzaRGZM1qAMQWeq6OTi0hnkjqZKnTsR5KO3zVVl6KLV3v4hSpO+JUTFfn5TGvzqw Y6ZAhOHkS/NjzT0S1E2kG8LTGyX5Al/a7j3QA0KfhqjP2IHtzn6rmVDySxCTfCUheTp5YGjAh0Rf KKIU6VtivDTliVqgb2CrdCZcHJ1IByM2jRIrRuvfjoIEcRfzd+/WdiEJV0GaumRqPOGWMRCj+O8P kJBngMFg3Lbr2H2UIuvym2UtP8x1+0OQqJ8pVuo7YpCZVQZmATyo2/WTP1Vsh37GdmgFW6HNsJmO mkvekaQ1Qynjh97zRWqjUhs/p5T6gaxuibdfZNky/hQRBJa7mX7VQ/qGGPUtkzevDOkRCXQHhGDg 00hblCdQPIkMfRdqUfKrjzG+x0RwSNSRWiBglhbn8bP42y4QRGtzoarKi54Ud/oNr9wTg0yub4yY VdpMJ9wqkD3/p/dD8mG4JSnIE0pBX5AkvAuSnIBXfwofhsuxJAmFrRhxDQSZXpflO0NK3O0Xx2Fu iRFamf4UN6EIXw3DIuJICZIOSj3EVoC+dPVt0ruCMCJimOHX3he38avbtN3C35f3dDMXWOq6y+yb wFwFQX58/7m4nfePTC6JQR7qgVptScCbC1K4TF29DJRo/PnjkCcfnpL/3HavWJySze0WbU2VUZfh e5kK/RwOTyNuaxZm8fMVr3xpz5LmUDdrRXJFDNo27Ri5ABPiFJxf7lga8RihD3fyPFHug02nZGh1 kmIGMM9AilyQRt2ALWPUqXVEGcOjXiEFfUia63ncXuWGGGR+DQL9wPXr1ZjAqsLE7jnYnGaVC32K AKTIQ/zsIREEDsV5Zz0ECvobrc+si28v5c1JmHlihLrEWz2LbdBNkMJt1WLLpIWeaWwL3OpwqbYI NAmyXitPG6FnXT5S9TL66brOl/TINDHIQYX9KukSTqfejNGvscWaGfPXltvOMhdIjADwXcQHa9nf EdNS6BsuBKHI3jxJj8wSY12Pk0/ipktwH4VoGCHnakNqMe/WkMSr9Ygrhjj74i70vmWEsV/bsw62 6MdH6VFefP+ZuJ7lucocMRqh4A9czYWIVVrxPXUpNDkW2OR6xLzYe12oWHviFnTARYTgLDnNmxHT MLWPvlTlyaw6BjNFDPLGwtH0COC23TqRlECSgOvY9/K2qVes2Pfehi/kLPSPKSMoJKdtwOY4jCmv YNadzKK1MDPEIMeSFGbJAVAKt/4oJTKwKLgLHxEg/Q4fuBUX6UFbK8S1/YrThNdJb8kSjpkgBr4y NxGzM98OGJYS7RDKxu9jSY+61/zeui7/LUt6R0+JQabYgbckJRD41/6pep7M7J60ffeLVyKO9IA5 PlN6R8+IQUr2wBvxK85bj7ZdMlJk3orRdgwFLbAnPYLyLUAw2waGpt5xttcJGnpCjDAitkakaBNi UA8Fvz7mYf/JFqdcUwtzeAt65AYMJi31yNCkC70DSvn3vSTHkRPDlRTkrDOeyqTFItcrtIedp0gE KOabZHlslao0NMD0mBxHSozwMFFNPGorKZAfzAMpsmrj7uHayv2rKcz/d69c2gkoogEJ7SxPkxwv Yc7tRazbkREjDGMOBn4Vqk06GNYncr/42w0gdAr6YnK9jd5B5NCBeYogxMmjDkI8EmLskaJ9jqS5 MbV2i/WJdkurP37f1DuUkA+spy/JnGuCRziDc6Tk6DoxYpECClp/TDmPwhUB0jto0dPizxI5ukoM UrSRvuWpQ/z+HH09XMHkcv2FAG2TXMmBiGuyVtVzbHXx6SoxkBeWggHbxT0xKbo4wXlp2pUcMtCP Kt7XpW7nteoaMaq6vIAwj3qyM/vDpMjLyj2CfrqQox5fpZ6SZaubR2a7QgyKsESYxzUmxRGspj57 hQs5yAdCuxFYts52a/ipEyNMCynMvVbpw3H3yt1xsj7xwwhEIOBCDjr3QbsSrKPr3QAxVWKEDjzs AXEU1ZojlULGS161K4PpBkDcZm8QIHIghOQiTLmPbD2gZG/Ynfy7GyHrqREjjJR9E3q1rTmI6H6I 2nE1yX6K3iy2vL21bsotz2DrZD+SIBGyXvt2K20HYGrEOPZW3oNXe9QGfhj75OvJ7969KEwazLwt xCz2F9LgNjKM0NUGU9a1JWpLiMH6Ks0QolSIEWbRxm08VmDpzuowILC6lUXwuU/ZRuD9Z+YK7jc5 GV64GfGQpYpODKapjHdMDEoIjBQqULbtjxYG6RorXXfKZHt6uXdJEaBsIjDPTu4E8pXNWUzKOOW7 Skvf6JgYgaGD7y1zm841EnUlxYXrMQKCfBZw7H0vA++VPS+AWcCHenUvUXcHuHVEjDBlo8R1VJaH LmEf9yu3OugfV2UE9hAgbzeFoeN+wF8jYUHAYVATD54dL5c6zVmVmBj1LRT5K6ysgF4RXOJ5ZQTS RIDOZlRl+S6ZaiP1DZwKDVO6ImdxJ+9NTIxGepRh+8uR86nLFzZ2MnCum18EPnwmZpC6Fdelieg4 PKNu4sP9SycHnBIRg0I+WsVBhU48v5qpPEH5XQbc808RoG0SzoRfVIGp2ELVdSCXng2V/5p0SxWb GKEjr6bnbfdTUO4nSpnJ08kIdBMBSpSARG1zeEe08w+H4jrZUsUmRpjhuoUVitJmpulo6Sa43Ha+ ESDnX7VW+sHm38DttNde4uqzJOsxFjEa0uKG7V5fI83Dca+ynG+4ufd5QiA08NhMuLBSISPJPTpf HndMsYjRUlrAu+0pycGBcWeAy3eEABl4KPctGlmKbAiZSOju97g5qmIRgy4JsUoLJReTiKyOUOHK jAAQoFSg1Q/lq7a0TEjZtCQGxFdxwNojRngvhRAnbcyqx0NZPNx1aXEnzou5LCOQJgLQe+G30E+j 2iTC0PqNc/XcHjHI5Y48P6/WkSkOjd/XXu3hfj8Ebu2ctd1uZFhapDnH3FYCBOqHm8qPbUnccOn1 PejIK67m2wNbqfAOu3rygnml/Xns3arIQn0f/99tlT3Qk+KnBGPhKoxAqgjgyuo5+Dbg+AuvFjjw kCWVdGS6Hs3lpQeIgcpbqLT/oNE4GDjesiHcoZ1G0JZLZ7kMI9AKAVIDqqq8aA0XgY4MqeF0T+NB iSHNljSyNRE+6RmxlKeLEcgKAti93NHaTHcqNQ5KDGEgMbAbc32gdCstz1XU19scF+UKGpfrJgJk Ga2I8gxuhF+Ieg+kyT/w87bbqYPmWq3+E4cXDVbOQh+ZbeojQ5542M18P90EldvuDwRqQ2JxYCf6 /nFXC9UBYmihXyvE6yZ8Qn0Edz7fWzffnk37cHrCPnG1AiJAlqd1Nb4Mw9FNy/Av4+ePW0FzUGJ4 UL51x0jOMSk6xpAb6BAB+Nx+hK5xLUrXoGOw7bzhB4jxhRBbO510yIgZCuzqpAmuywikgQDpGlVV egydIvKEqTLiMnY4V2zvOkAM0g2qprTtctf2oQaNuESu+TQGxW0wAmkgYKS8YyMGLoufQuTtnC2M 6VCsFMLGX6NTw7E6xqSIBRcXPhoEQr+GKa1GhqVT5K2Gw88Tt6J6c4gYUMC3oIC3S91fbyu8VdU7 0ptujgZSfku/IGCE+REf+4nI8RhxHj93I4ZSUMCNAyxMCgeQuEivEWik+dyMPB+OM+M4Gz4SFblx OOxci7a+DDq+6nkSt2k+X+31wPn9jIADAhTvF3kEFtupC1HbqajzGKRjWB8ihfHk92DZhkOHuAgj 0HMEKFKcgmLjbKcOEUN5Ygssim6jfin92binoXqODHeg0Ag0TvlRitjDcYCW7dQhYtREDcp3hCAx cst4GhcDcmLmQq+yvA7eiCe2SPGo7dQhBjTYdXD4IIX2PoAUL7byigv3u9gIxN1ORZ/5BhGaWaXp shfPN2fH5IuWukexYefRZx2BuNupSGIY+DJg+z1JpDjui+85Wjbr0879c0IgxnYqWmIo8dpos3rc l5NMCifIuVAOEGi1nYK19X/3DyGSGFJ7998P6dVTCN/NwXi5i4yAEwK0ncJNrxtR+QtwPG+cEgo2 kyVEEiMMG3/n9C4uxAjkCwFPrCKyY/RQpxE75e8ie7oUG/S7WAnX8oUA95YROIyA0XodST+ioQnE BBjBxOCFU0AEPF0VOpoY+CnpGXdZYhRwXRR9yKHZ1nyz547YjwcicSea/+etVNFXSgHHb5SuIk3U yU+HTgf0KuZrpKl9scXEKODCKPqQjZbQMyxHXgOf9IxlJkbRV0kRx0+WKVvSDyXGAAkTo4jrouhj bhx5jcxtAMf2CGWQYolR9FVS0PFDn6Cs/ofC0HG3ZKh7MDEKujCKPmxcixedpxmXWjIxir46Cjx+ 2SJPM1mmWGIUeHEUeugt8jT7wmdiFHpxFHrwdBdMtGkKN70yMQq9Ngo8eOVpa24DBBIyMQq8Ngo9 9N1BsXXsTwsEUv4P6xiFXh7FHTydu6iacbpzcv/VeiEgiMBliVHcpcEjj7hzMgSFfBksMXh9FBYB HGfdhaMvcvxMjMIuCx54KwSYGLw+GIEIBJgYvCwYASYGrwFG4CMCyJ22HYkH4qVYYvBKKS4CCsQw 0ZfBMDGKuyx45C0QYGLw8mAEWMfgNcAIuCHAEsMNJy7VjwhoMww3Nzv4+nFueUzJEUAeqWFYpg41 YHBzGEuM5LhyzZwjUD/ffdgqJYW3y8TI+eRy95MjgHtgoiUG7odhYiTHlWvmHAHKPBg1BHL8MTFy Prnc/WQIUMIDS85zIeD4Y2Ikw5Vr5R4BP1Ja1IcVsPKd+/nlASRCABJh2JalE9cE/B9LjESwcqW8 I0CZQGw+DIyNJUbeJ5j7nxiBQ2e9my1poVnHSAwrV8w7ApTVPPLxPVXlrVTep5f7nxSBkaiKOAe+ fVpWeCuVFFWul18EfjdlipGKJAZGtUEjY4mR3/nlnidE4A8hRlr4MJgYCXHlanlHIMC9GJaoWqnF v/jimLxPMPc/EQJKiS8jYgfDtrTHW6lEoHKlPkDAiNHIUSABW20QNy29Yx2jD2aZhxAbAWNGRUQG QmPkJuW0ZeU7NqJcIe8IVEx5XEkxGDUO6clQ8WZi5H2Wuf+xEVBanLFW0madFG8mRmxYuULuETDi vM0ipb3aCkuM3M8wDyAuAuEZDItjz2ixUfJebDEx4qLK5fOPQOCfs/ovlHiyf4Ds+c7/dPMIHBHA FcZ/p2thoh74NlaZGI5AcrH+QYDio0CM8agRNQIHmRj9M908ElcEdgKBbZSMNtMq9fjTdngr5Yos l8s1AkaZH6SJ3kZpHfzSNNOy8p3raebOx0Eg3EZpY1W8v/DUnpmWiREHWS6bawT+CMSUsmyjoF+s npKVbd5K5XqKufNJEJBG/MNqphXy56g2WcdIgjTXyQ0CL015QqroaFqyRn0YkssUTcsSIzdTyh1N A4HAmMtRGc3DtpVcbkbTMjHSQJvbyAUCkBYnWindMFLdtw2Et1K5mGLuZBIEkFRtyua7IKW7JCsb TIwkyHKdXCOANP9XcQdG5BhwacxPrQbHEiPXU8+dtyFQqY2fU1JFZhukG5NqQ/B2RyjdzfaYGLy2 +hIBadRsi0haq9LNxOjL5cCDIgTWa+Upm4mWfq+lbrmNojIsMXgt9RUCz/5SHhyo6XmbboG0OY9L 8uOBJFa++2r6eTDWBb0jpqVFtxBIj6M8OeOCHksMF5S4TC4QIL+FEmbedhjJKLl4Wq5tugyGieGC EpfJBQKBETdw4WTkmQsK//CUvOM6ECaGK1JcLtMIQFqMwMs9HZVIjTpuhJyDtHjtOggmhitSXC7T CMDLPW/3cod+i8VWfotPB8fEyPR0c+dcEKg783B01fIYIa7YggXZKuWCMJfJHQJhoKDQ96ykoHxR A9XHcQfGEiMuYlw+UwjUAr1kC/2gjnq+uJ6kw0yMJKhxnUwgAA/3NLZQ9ly0Ui6flv9cTdJZJkYS 1LhOzxEI020Ks2D1WSBQ8LhSiaQFDY6J0fMp5g4kQUBp/wGCBCN9FtSeFP6lU/L5dpK2mRhJUeN6 PUVgPSjfQgciswqGHZNiccx7figlTpxOs8SIgxaX7TkC4cUvxtywOfKEkVvvPzfX4/gsogbFxOj5 VHMHXBEgvUIG5qnNkUftKM9ciuuzYGK4zgCXyxwClE1QBQKkEMPWzkl9+7SsrqbReZYYaaDIbXQV gfCMxY55hADBEeuLjNh8/7ma63QL1WyfidHVKeXG00Dg2Ft5D5Jiwk4Ks6s9eTGNLRQTI40Z4za6 jgCceDeFNFOtX+RNluTzjTQ7wxIjTTS5rVQRQHDgBXi2cfDI/mgjrpf8zkyzrHynOm3cWDcRCCNm hVxq9Q5kErxb8tbudqMfLDG6gSq3aUWAnHNaiZWSXKvaClVq5WuQFAj3aCUp9ErJqyYO+Wg3RUyM dgjx71NDgELEkZDghgrk+WdD5a+ilOWqLi+AFNdaSgqEkteOq8m0LFC8lUptirmhJAhAH0AStPBM 9sjAW+gO6mNIOJlkj+2IB7LFgaPwnfBsG//D5HfvXuwm6YNrHZYYrkhxuY4QQCjHqDJiutkILnO5 BgnyBOewV8l5d+zP0Hlnj38iTiChgfEELFDt80J11FlUZmJ0iiDXd0Mg0DiTfTDBsg7kUsUrT2Jr 9Qgm2ZMtt08ghRTexfGUzbK2dzIx3KaVS3WAQCPB8uEDRSCD0uIVSNG6ddo+QVIcFSmoM0yMDiac q7oh0CrBcrsWDBRtzzdnx2KkvmnXpsvvmRguKHGZxAiEplfLHXjtGtVGr3zhq4un5Np2u7Jp/56J kTai3N4eAo0EyzcQDB4fFRw2gp/iSvyK6dRgYqSDI7cSgcCxtxrm2ejLW1oCZsTMmLd2u5egMjF6 iX4fvzt05mlzzXZ5i3XoRlwZ89cWew0NE6PXM9Cn78c1wgu2BMuthoy78c7j90yMPl0XhR5Ww5l3 IQkIINME5YvqtdRgiZFk9rhOSwRwLnvBmqzACTuzgK3YqutdFk5NxizExIgJGBdvjUDdmScnOsIJ 8VRaiyXhiVJH7XRQmYnRAXhc9SACoXn2AwUKpoLMOIWowzp1K5XWYjbCxIgJGBe3I+DT/XcJnXl7 reKePASIVKWQ2/jZLpEtzbPcrvPHxHBFisu1RIAiZJGO382ZR7FPQm9JJTdx1dF/4eHe8D21TZG2 h17S4pL6bk4JE6Ob6Bao7Tc4a/HJbalVhInvwsr0G85hbPue2AAcr3upUMeZDiZGHLS4rBUBo/Vv nqeefCbERi9im9KeGiZG2ogWtL2SH//WoixDxcTI8uxw33qGABOjZ9Dzi7OMABMjy7PDfesZAkyM nkHPL84yAkyMLM8O961nCDAxegY9vzjLCDAxsjw73LeeIcDE6Bn0/OIsI8DEyPLscN96hgATo2fQ 84uzjAATI8uzw33rGQJMjJ5Bzy/OMgL/D7pSZt31B75kAAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image014.emz" Content-Description: image014.emz Content-Disposition: attachment; filename="image014.emz"; size=1857; creation-date="Wed, 10 Oct 2012 09:43:16 GMT"; modification-date="Wed, 10 Oct 2012 09:43:16 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1YaWxUVRQ+8/qmHSiFSYNNkUJnKoRSqkHTRKpFbhcKZUtbp4QqkSVlDUhLW2jD YgV+aMCAJhKMGP2BkcgijUbQQCwQxRCCBImSSLCgiSAugAQMS8bve2/ezO0yZChUYuQk37vnnru8 c88957x7n0tEFgAOjQPjdyooy3uKTHOL+EZPLBZxyZH+IrWQx2l9yKp4kTUQ5hgiz7jaNp7a7JG8 k6ZgAskGfACmG+ZSLkkD7wUMb8sPHDY9BPadCpQC7JuhTOkFnjRQ9QjzgzCHIx+uDGsu0+rVNMqv EsJtppIwn4J2jkkFsDxrDAqLeuDpBcYDQ4DBAPv2FmnS+XLIqqEwdb4UDAZRhGkDhSC8M6NQZsC+ 82SmLMbz3yG1KldOrs6V6rXzE+uacuXKtPgy1n14/RHUoW5wL+qBl3Nl9PU+ZZQ57WzLjk9J/Bzy 0DKsPeHaKx7DyjxGH7dhGGacYQYNORPcLtgNm94NDdDXzJZCmSUvSp3UwwaN0OIm3rexsEdZFtrw uh9HQI/kBQllE1A2Nd8oq0JJHUrdKYlVS8TDORzb8xXR+GS0ca/Yh3sb8gsjAJ5wiBN6AVvdpIKK iqQCtiWFZBNQ2j5EacQXSsH7AK5Xn9/Rp72P6PJMjHF0033nHAyApjDBwhbdL9+pasiVm42272xa YvsO6z5odRF1+kcr6g1Lbd+hzGlnW3f7jg/v1X1nKur0nWqU9J1XUHbFd5w9MbhOrMPahNBD25Pk AKJ4Ify5FhaZhHIpynJZBNkM+Hj3kLMnaTI/sSt7kpfQMZ6p6bMDsTKvYcTHuU23EWcGs6Q1v0Fa nHgOhnxRX7N0suZY9oQ6TEdMt49n2tuJk2g81XD63Cs+2rt0eSzxzP4PYht+dA++C7H40YPYbptv /8+xrcdqNL4rMVyMmJZ4kStu++yZpUQGQcRvPo6Bo/iwEeEHKrdz3pB0FRfmOxmLoSRrrMUNU+Gz Cs628eGxfm1O/cwby5z62be759f1mZ19aoS1KDx0XtfhbvrrdtP5aPPrfXQ+9v6+fMFnUe9/93tk z6nv0RNKXGmwmRcQ8e0X2QNsLBA5F9O7PUrMVIzkGZN3Kc6C65g3R+m+Fbk36Xug28XmO+qnr//2 Y9dA53ttL3vO6PZac+BO7dU1u3TUI3a7cEdE7rT/IBW593qUy+3FAcgEnPuyPWvkiSZ5tXTSmKSe D/Nqm1QytqgcJa+zAzzIaXL2rdfxFFdt+ZgC2Xk07Twq5pz8ifkizesTb85AzpMe1WMra3HnPUi4 Di3aWgXhspKi/MDcwt9PNCfJ8F4Hd608/f2NgpHzzmx4VPXyf/fZtYF/HZKtZypbjAsfTd62cvnG by5XNiZelm1PHl6xa8Tajy+n/Owal7Bj9/6z2UcPP78hYcq+sj9Wf1m5+c3dvj6lT83dl5Qyp2by 6VV5Lb++tjg9++jZ7XvdjU3H8y8s3BU/Z+SU6+/v2dT69CdQQ0pGTyraWTB9lYhHGR4nLzv2MNlF o/7KpXJQzwSMEFB8YcOOL8QJyA0jcfEZ1v8PD7iZgHNnywjxvOMUg+ce/I2S/yb0fxB3ur+x97// echUkVzix9ppI6dk7mKdjqaA4QCt6QNgKgtelCTK2Y82Jel17icRLScZaCkHqjEp5416f8b0+n+I eej7wbcN87cDm97IlRX5S2rS9709/gR4Ynxwac0WT2Cwb015avWslhSxcnCu+Lc11uT1DAwurlhW sxf9FqL8+qG6mscnzqijL+h6rvvp/JKhO1oDL0HJvsYvWBZhU6I0SQsjMkRT1uOODfzZ22x8J3C1 Xl26tdJpk2MaD6FjJ9jMXIcxQxuu1tMOpC2ojykqKZz+wiP+98DnVV6rV8ubkzd/NWsw2y9CdmvK tXr6qiOj3X6D/NgQ89Pbvbv9XY3jYBgrJlJRJod4yllnrIAMp08/VPQ+/VH3Ag61rzvjOFcAqAJo MhoxH/ADzrrBhskENwHwhiXWfyVuT5DzPAdvG4/Z+H+HffoA1JUGYskzYmaI51oyQjzH63wx5Dno kAkw7vXYjXYmyFFhu7T5b5kF+SDMx7XqPmTz/+3vr6kia+aeeQCnTAvV4cuigOEA99cHwKwWvChJ lLMf94Ck12k7oqPt7G+0gZZyoBqTct6o/3Tgovr/jc7+6UTLE8eOM0/w7HH3ecIHHRnbzBMH4PRV sxfUEU6e8Awx+90uVjE8bCfYLKY8MaKpY56gb3eSJ3bf7t1dzRMB6EwUAIzNsUA6wL1rT9xDxrhO jE9SKYQ+IAHoSkwfweQtQPfG9L09O8aSezwqLsqdIHI/7e57pUeZUXSInGvvRgc91+h7r/PF8Isc IBPgHmepDrm3CU1A5D7vh4B5aybAbwTcw/K/KpQk5qJxAPuRWGeuGgAMlQ/xdChyz2+bq5z2tmUG qnwf/Zp6M196AeptqEhexTdL+gIkL0D+HyRpnWvMGwAA --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image015.png" Content-Description: image015.png Content-Disposition: inline; filename="image015.png"; size=499; creation-date="Wed, 10 Oct 2012 09:43:17 GMT"; modification-date="Wed, 10 Oct 2012 09:43:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEsAAAAnCAYAAABHeLXLAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAFzSURBVGje 7ZixEYMwDEW1ARXpsoA3SBWWIB1tChagdFgng7BIJmCCpOAAG2wj43DR5X6hCj7Iz1+Sgdq2JQQv AAGwAAuwAAuwEIAAWIAFWIAFWEPUxelBRO851KvS+szVa12dFdHLfIYqdflN/TpHf8S8OwqUK1Eu OF1fLzlRvzdxrr5p7lmRU8eFdSrqx8GwbChWgnnR3Zsms3SlKkPJmU5wAUvWj6AduR1Whj5Y9rW8 v9b64nJjaBfnBdvPTtWLhDW7awFrdMVGoqY7TXek6mU6a+op9rWboie3N7juTdWLg+UrldBuB0tJ 3Z7f0AuBxZtmsYudSm4nrKVeMCy7V8FZvjKcRvu6l8X0nHGxe3uWSy8OlumAZaK+3eZOs1S9zGno GfEh13Gmaape+DnL3tmt0/3WwTNVLxJWsMGuBsOgNz9jQqWWrJcIay6F9WQ0mzVnkoYOnbH6n8DC /yxAACzAAizAAizAAgTAAizAAqy/jA8ufbMDrg3kygAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image016.png" Content-Description: image016.png Content-Disposition: attachment; filename="image016.png"; size=2983; creation-date="Wed, 10 Oct 2012 09:43:17 GMT"; modification-date="Wed, 10 Oct 2012 09:43:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMsAAACNCAYAAAAZ+o5CAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAs8SURBVHhe7V0rkBw3EDUMNAwMNAwMS1juNq5y oGGgYaCrfHtrZnjwoOFBQ/t2wEJDw8BAw8BAR08z65zvdlqf0aelea464p2RWq/VI/X/0SP+IwJE gAj0gMBvu+GXzcXtH+eX+zeby/3hm7/t/t/N5fBF+jvf7j/ffQfjmP97gXF/3h2+6wEjrmFlCHwV iu3w2m7u7fC3SxBS/H4UJiuMRih/3b3/YWXQc7naETjb7X8ym/2qlFCECNb5dvjLPH99fvHh92e7 w2PtWJK+DhHA5ju/HN6OX3P5+qTq9+3wESfP092HJx2yhUvSgAC+yrjamI1/s/HQL1QJyJwwQ3CM zsMTR8MO64CGzavhzGz8d01s/tgTzgg/TklcJztgGZdQEgF8afHFLaGDGJ3i0wPLmNF/zP8b44DR g+5Zzcbn8137oONg7bSuldxxDc4F6xE2qNks/6TckNjgRk94DwE4u7h9nuoLvtnd/mh1p1Gw3qUU JOhiZ9v9nw2ykSTnRCDlVWsSjDfYxNjMOemeGxvzmlPxpfn7uFjoYfY2ulqNdXBORQjgKz+ZVkVn oMeGM1/1/QuNfg1cp6zgGvPxomslhUbRzi1IivWLLPjq4ppmFWIjbK3d7WEytn6XyKsmTs5U18iC LOdUoQhsdofvrek3UkGGgMA7Hzqvxuch5FPozfsYPOCrae1DoZEP6miyVxEowRH+ESi69l0jaOoW loggXB+nOLMgwwausDxlEjFBwzCjXhLuZbeWJaPYrunrOZrMh9ehVzSeMhp2+gIaFuglN71ctWLh m66rJtbNHQl9vMLxlIlFu/J7k98h1MJ1o9GaVRPKSWiuvXUaRAIYq2BNmjm3JwLW0hNs5TIh9JX8 IZ7Lqv5YBK7Xa7q+VmdQKAHWshNiDjV+A/gfQudZ8/Ojo9PzaoaPVsdGkSb3gY0GDgh0hEAxjCOe 1SGnjA2ZYXBmPNgp30SYirela/wiXjEcPQ0HvE8Z4M5wmTSgx4xi/SY2j90z+tZcCZjsFIO0/M4U g+aXMk2BSc8A14i4B4dE18Iy5hqTv8cjMF6DUXzD48NFgYkHOvTNkC8Z7f6h6C57fsy9ocAsQzHR 25N+4hWOgRgu6iaJgA8YBtESXtYynjABqAY+OuW+O52MNhqY5uBAdNM+7n36U2DSAo/RfBV5ZCLS rp8e/5gRbcapT600CkwMvA/fsSHknuH0VOLTYJ5yFG+BMeb/lPOubixrYfEJW6ENX/Xe8BIY8JDh RnF89ALYWF2gn6w9OjgO4bJvefHTXNkYxBrIFy9gYZ404NLJGAhuxcd9+ArfGYMvPZk0JR45a2JZ hyQD9DxR1fOYj8Agxk8PxUop8RUUgMmvj1ImepA1mpWdUctXHkOt85EAQSGIHWyRqSyT3IeGvrI5 87A7roim4Q6k5M4SkCIhhcbYSHJetf9HbIocdpbhoaD0JSjH1diif2Is2f7Q58oDV+UrKAjOCxya jzeCwOh0lm8VTNIzzPTJbEQwZCN8J5mRCEzdCuabQRljwKpdBD6xXhSUyN3X4Gu2/6ZwHUOqxSot oDaE29WRlydKg1t+GckeuTDruo772Nh5oizbdK2+PZXXRaPYeZPyWuLHbLE2d8j2TavMJt3LERir xsw7LBG5sXwW5SNYq4crgtj8vsp7qXLelSbPw//Sd7VLpz0dJw4dUKX3pdr5JHNy185K15cCxy6L sKndt1UIc13H8PGtQljOSV0mQShzsI7lpIFjt4mA073Qk7Jvm+M46g4DkDZZSapzIzBax4SeOkbH zU1DsfFdYQzMWyjGimYncvnkuqjiY2vgyh5ZZsQ1u4XLEi4r+42bkl2OR1zNmGtddsO1PJvdT9KH t9W8Fx8vLAtMtLx169AuhcI066h0+VOo0NfZbK3POkZ/CJ791k4X1CGmntL6ttRLfzeny9gCQjLz rTwnQe8ebIaybk4XVyIXs92a2ZOqCZVK+aLOtWriQZy7uj3zqNUzsRECXZYx1SVgnUcjPPgMkGxk K7ZBpnSLUZ0LBeIkpZ5xX21swJaolE4X+PBUpnm4jkTVUt7S7iCtDxCQvPoqP9BSA1RYxtiijrs8 FwIOPVlXrWSXUq9SunNxjuMWR2Ds3TPjpDT/r+ZDvarQ6eLbgBP6IiB2hNPSem9VSTm+nONzxRGQ i4s/dFfAKjuF/JcpqTT21xDbBZQhpDhrOKE2BKYbznybd8STjSFYV9/q14X8fqKNm1XPte2n7ulx Be7OuDXyf9BdgZIMael+b6pboCuT8pSwFMmulE3FjWesqdsGJOgUAraIuAnHx4mC+seuMsCnfs+e eOjq1MRSRtzcORGwpmJHawofwYGHPyeddmzpVIEJLzsBnGD1CLh8e17CkjsyWTxVYBljoOTqN3Ip ANABzkco5p7J3kHOcarktyyU4gTnaQKBSAuYrcyfVbnnqdLE/lkdkUj0ijphct6CeKqsbh82sWCv rgz3yichuDfb4niqZIOWAydAYAymNN0XHF3k7vyeLxrZ0U+lvyrmCRjIIcoiMNXTnm/eeleQTJXU LNS5ErtU5zpnQYSDakXAVQH168li4sSyrMFRrSXfcZZlNRy0dwRsKJYc4PslS44LT5Xet1af6xOd lka3ybJqRxEKnipZUOegKRAQnJbpo0zEdE0oSz11W0rBHY6hDoFTH/ssEfFS/8cmKv6pYx0JqoHA fadlls4NYhh+a5XKa3CJc6pAYGp98uloCUuu3CPMfj4Abf9ZZfEyFawhERoRODots/RvkRR79lXR uB1IkwsBWzPC5OC7ngv63aXYZ88uC6KWDxOBighQsa8IPqduCwEq9m3xi9RWQoCKfSXgOW17CFCx b49npLgCAq6qflTsKzCFU+pEQCqcR4+9Tp6RqkoIiEGTWiqRV8KG0xKBbxCYbcetqccFeUYEaiOA 4LLZ8JbcxchqL57zE4EQBBAGIMSCvQgZi88Sga4RECtj5Kyv1DWqXFx3CEiOSBRg7m7BXBARiEVA qhmbJassllC+RwRqIyD1tqAjsjZ3OL8aBJ7uPjyZreK3HT6qIZSEEIHaCBjF/qUgLHmq9tVeNOcn AjEISB2UcOrEjMl3iEB3CIzVx0+35oYe092CuSAiEIuAo9pk2lzlWCL5HhHQgICUPozylxpoJA1E QAUCUsFvmoxVsIhEaEEArY1PWsJyFU7WsnDSQQRCEJD8K8hrCRmLzxKBrhGQSvKbE4dRxl1zn4sL QkDMimR1/CAs+XDnCMyF5EOP6XzpXB4R8EdgY/JThK6ubFDkDyWf7B0BqU03Q/J75z7XF4SAlEKM RLCgwfgwEegZgfudkO5eydh3pWfOc23BCMwlezF4MhhKvtA7Aix51DuHub4kCIiZkam7IiWhmIMQ gUIIoBgF/lBEzxbSM9HEcycLLWGFmMJpdCIg+FO+3P8NvSKtQNGDr5OZpCovAiHCcvrZ/QF5+nmp 5OhEQAECS4XFhvGzIqUCTpKE7AgkEBZGIGfnEidQgcAyYWHpVhVMJBFlEJC89aIgmaovLIVUhkec RQkCZxe3z6NOFyr1SjhIMoohINUGm+/HMnxijFgxFnEiTQiIWZGXwwN/C/0smrhHWooiILXAO+WY LEocJyMC2hAQO3tNpwuijnn90sY50lMcAalh0fF0wQlUnDBOSAS0IYAKkw6r2LU2mkkPEaiGwFx7 CRPS8vnZ7vC4GmGcmAhoQwDF806dLihgoY1W0kMEqiKA0+NEP5abqkRxciKgFQFzstwcTxdGFGvl EulSgcDm1XD29SrGHiwqeEIiFCMAhR7KvmISSRoR0IEAfC5sVqSDF6SCCBABIkAEiAAR6BWB/wAZ UacNi82eqwAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image017.png" Content-Description: image017.png Content-Disposition: inline; filename="image017.png"; size=9901; creation-date="Wed, 10 Oct 2012 09:43:17 GMT"; modification-date="Wed, 10 Oct 2012 09:43:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAPwAAADfCAYAAADSk77/AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACYtSURBVHhe 7X0LfFXVme9aa+9zck5CkAPyEAUUHW0AxRfSxAYFY6Wjrbbzq2Vqx9uL7czt9ba0znV0ZiwhQTvo 9OH057WKHa+1Y+urWq1aqkEFNKkgWjEQFHnIQ5BXwBDOa++15r/2Scg5JwFPSM7Z+5z97V8jkO7H Wv/1/df3rW9937d4Q0MDo8vfCLRWVRntm9oDjE00GWsHGBGFP0QoHDZjLMqPiU40YrHIJoln9KPK HGslK1/rsKdMabP9jao3e8+J8N4cmHy0qrW1yug4qdKsHGsGWKwd5I4M6VTsAnzrFMXsz3ApzmRM gbzCZlxVMsUmMW4YjOFX2RcXuNOWnKntivEdnKsAU7wDz70rldjBDNaGD6yPRVmSRSLJSeHK5M/n nWk1NDSqfPSN3pkbAkT43HAqyruePVwVnhiOlEUZGyJBbCnZWEOp08HS8zjj47jgI5VSQRAbpGYm 4xx/pvjIOe4Q+tfHUvCKKcwPCi9O3YdnFQjOma04t7hSMSblLvx9Pd7WqicBqczVVszaDUsgXn1g ZaIogS3iRhPhi3jwspteVTVfLN7UFGIxNkQwVm3Y7Ev4c4YS/EQwM0Vsrn+4yaGh9Y8mrHMpkLeb 7CnqOr/79AtUBtf1nc7UoP+Bv+kJI/UKvFViulHKwvcsfA9GBVsrhHod9sEy02BrYAV0dE0A1qd/ j+4YCAJE+IGg54FnW4ZdZFpRsywUYxGY0ldIJj/PJZsOLo8EC0PQ0qJPYudE5sHoYGpCSJ8IpMTy HpYAJoWEUvYnWEK8Kbl6mTHrBSs8cnvTrRdGsdTMZbYZjAb66h1E+CIc7qqqKmjySHkoao4HwS8H aS4TitUoLirApDKQHBTTahfmdrcG708/u7Rz9yM9mjul+rstgSOvTJkDuX9BLxecH9gfuKRt6eVD XErrIGdimVT8cVOULbOGdxwksz93WHO5kwifC0oeuQfaPGjuHxmRsv0LINjXuRDToajLNMmFYTrm c4rkOZBPE05PCl3kTpngqXV4SgN3v6Nrbc54suuXemGvf45caEdq+e9c2nrXz+q26L9/+mTgfNsh P1yAUi//eRQT1XbF1WPKsp+yKs0NtfHmTo8MQ1E3gwhfBMPXevjKcNTsmCANaw404HUgwinaXBdw oOdE8iPatMu81lpVk1qCjlyByFyvnbvW2CqqpNqA3x8GYx0m4j+dTPD3cU8MFB7DpTrVUfS4CZde MowWQkwASfX9euaBA5Bhm4+Z2vGXWlJo5msHX9dkcBTcU+TXk4fjU0hC/R9iSjRLxn9pJeTS2vLm jiIYMs82kQjv0aHRZvudqyMVI8NsqrDVDWDmF0CG4dCmmkgpU/0Ymtwxl7tMZ2nrLXEJjzjX62Yb PAeJ2AYm5A5lsXeZYFuYCG402aEPwjyk2kPM0nvqR6CJYH89bFmbNk5U48e+arD2iRkaHtt7IhTa acZ4KBRi7CwrKSfAdTCZK36GzeREgxvj8f0AXgifgoDDUE9UqfYfa8mRmiwcra8njMOYK1ajTXdb FexFaPxDHh06TzeLCO+x4XGccO3m8JDNZkO/fh0K9mKQopwLEwzu3gLrq9Fd62KY1/qSdhLq1ojD QD8EorwFcq9gllzHAubmSsa2aFJH2iN2x9g9ySXzZtuDuT9ej8lq9s6pcCZuNTFxmKEwK5dMnAuz YhYmnVkg8enoUwhTShk3wH/H3eCQus/R6DH5cZ8tO3H7CiXU3Ykwe52I3z8BJsL3D6+83V1fP59/ dUHTyE6bfQMfuYEb4jSYv2HHbMc+99E0obO9BpKntr9sbZbHpbKhn9WLCKR5FWq9Bfp659bousR1 Iw7AfHfvahk2J2h91FHGQu1jEJRzKaamS5nk09H80ZiUKhDjA3XepfX7In/30sTxVThWymua+BWx 9uVTytsQbkDXpyFAhP80hArw/684XDPUDIsvCKn+ESvmc6AF4Yg7htneJfha88FctyD8UUwJW0H2 Jni8llpMNrMw62y6pS7e0OjNyDYdM/DE6tVl7eFY2GTRzyIg6H9iXrsE/T8BfoqgM4kdZaLrWedr i8f+BKuDp5URuGvu5D3r29ra+ggLLMAgFskniPAuDtSKsppQKBY4z2aJfxbSqMOCNZzaTdMy29u8 PSLo2hPPeYxLuRvr8ceVYE9bMdZqRhG9NmJl3MUuHfengUW5GTXHwXd4DVyBV2Gpf46S1hAuApr5 fVo43aY+fALwQSY2Si4XWeERj9bGn4fDka4+F34US194wXhk37DAxMg5pxnMmgez/TomxAlHgmP6 MGVT216i27OOSDW1Dg6tXwkun7Ei1u5S2qt2fBgfmWEzxM7HhDYXQTl/ja4PR3Dg0YnfjY+VjMHD /7Tk4va5ky+Ftm8kbZ8l3qThC8j3+vnz+VUNr59o2Z3fhDX+PcGNk5yA9aPsnfd4qaUOSf0Efq0W eNQfhJd6aWR1+6FSz0hLWUDmJKxabsRW5DWCiQh8GrxvB5+O/YdXADG70opvwrz5I6tCQNs3k7ZP k3EifIEID+GtCEXFVTBOb4LVfi6kE7HtfW9LpbbUtLddJZVt78Ye+JOYHB6Lhax3/CjAmvjI070Q 0YTfRezAbGAzVDszU9uNmUufIzkCthVVQjydYPL2WtHcVqBh9vxnjJkzZ3q+kcXewFZVc4pKsIUg 7gKsO0/VWl1rqd7C2pWhBl+cQ3Sm7k8Y1o18+Km/mx5//sMJ9jZXvexujQP6bY3j27YeiA55Ph4I LwdKIwDhKcAnmIoQTCd9KtIPHv8A7pli2Kp6B5+wdVtkzJZxsR2+N/GJ8HmU4kf2zQnEg0NnY2vs F/A8X4WFeLA7Mi7js92pqE6QiYUKFOpxwe0b7RHy8YvjK/eOi7VSMQkANiqwVxP/w83hcc+KuPUe sKyCww7k1y79rIHUpNd2khEYq1TyUtVpxLeEx63Rk0ceh9zzr05FadA16AisUjUnTjxh6822Ug9D IKfptFRHq2c45VIa3XHYSXkYWeRLEa36tUSYf2eaWLmmlJxxgwmwjqt/YeEVj4VE4Gpk3T7EpHW4 27GZ/h0duyBlEsv64CmI/10UPMwXrZLnozSPfy9aww/y2DtVZSZFzhWS3w4mX6ZDYZHN1isMtmed LuO2ba8Xgv8kEWNPIVackkT6MSYrxowJBT+a+GXMo7fBz3HWkYk104RiCPXVcfy2lPIPSpi3VIvl OjfAdxdp+EEc8mcPX1nZ+ZkR38J20u+htGcjiCQAE7032Z1KMnqdntiMqaDeFOWXv7Cg7r+I7P0f jNpdu2IvNNQ9anDzanjxfgWVHkUY8pEswNQbEWCsHXywsgzTvEZI6+FVVs2l/f9a8T9BGn6QxvAV OeP0CpW4BZmj1zNDlEHwesWGp8JgtXc5cRjG/NP45+3YR/8Apruv15WDNASstezKcGfnvr+Dv6QR TrvRTrhxVj0APQbCDDKZjL+DRMHvTzNXvjpY3y+G95DTboCjpPfWQ6+o2qBt/X+Y71/AghFavbeP zVlj4geaZjsCQ36YLFeN1XbzLvIcD3AA0h4fZW+wLp889+01u99/R3I+FcQfBcyd+PyeK1UzQATK xsDEP28rG9emHYGD1wpvv4kIP4Dx0ev1U9fthImo7hWmUYVXISo0a+cHnnddnAJET8Ix9yesH79T uW7vc9NGvO3LLbYBwJ3To3v3LlMnix0bN6vTVghmo1CnORFbdzofN4v0tkN6Lq1zt6px6/1CeiJ8 TmLU+yZdETY4OjIXYvRTEPpk2Ud+ekqrQ9Zsaw+y3/4jydUtF4vXPhg1am8OJWmOs2H0mIPABP7h ns1s5CvCBt0FPx//QRntLNjhTBVmKEX6JEhvlL6mJ8IfB0FWqJphlSL8A4jSjwxhDIXn13EM9Vx6 uw2OI7jnodlXw0H8fzYMH/erq+J/pKINx4H38T4yge/s3Lxz/Gu8ku9E2Y/PCtOs6GWBdZOe2edu tU96b5zYseV4v1cMzxHh+zlKIPtJWKTfIYQxD9o72Gu97pjwOjze6lBcPoQSMzdWi+a/nBNr9X2U Vz+hHpTbJwzdZv1yUsXbf7U7vB1kvwTWWHnfpId5z7CmT2JNX8Kanrbl+iFWLWrGWajTdB/8vN+C dg/AVM94Wod5Yt8HcSDWTmwB3aKGT5iHOO4d/fgE3ZoHBBqQI/9CY91v4Sz9vm1Z+7RPJf3S3nwk 3DDDDE3Ffv2dLfKSs/PQDE+8kgif4zBACKYJ2/o1VuVfwtabQKx7Ftn1el2TPYEgGnHjNyfX3V99 4FE6WSVHfPN9my4EsmTBrN8goWbe0UhvI7vWCASnGzL576vU+YjVL72LTPocxvSNxGcvh/J+CHu7 U1JlmDOtc6dEs85Xt5OrhLC/81zD55umTEFuF12eQmDmsmXsl/XfbD1j2ZYdmLAvQRBOb/PeKcbL z1C2MXKzGPLKBL435qlODLAxRPhPAbBFfm4WXHCLsS6f2FelWMcL79iEsskQ5renYb1OGYgDlMo8 Pt6L9NlreifTDoavUlO4LAttHzH2FcRKlEzyEhH+GMLVImsu5Da71zCNzzh13LM88SjD5BSOxEkp vzMMhYSX17bkUVbp1YOEQDrpYZbNFGYgnGG1gfQioEtrqcmozh/fPnzsylIJkKI1/FGESJMdCTC/ hBPnnD7Jrk96kdYhyMY9VoW8YRpv/miQ5JFeUwAEutb0v8WnGnXNfpTLzviqtJBlZwaHYlKfx/aa cwrQpIJ8gjR8HzCD7BeA7P8J024qbPVMzX4kci65Xwp2Bxth3X5x55+pRHJBxHVwPwJNrzbHxq1D VawyaPnp0Ojalj/yEV1M1AyGhmJiH4/7Vk4IbPt4cFtQ+LcR4bMwb1E1VaiK9gvM+NNSxSoyA2oQ vKGdc3sgFwvUCOseJL5QiGzh5XbQvggSxxGRt44rMRKkn5o6Lqvn0qY+Yi7GcmZVHohP/eOowIai TnQikz5tcPU+O4Lh70GF1Jq+KtNosisruQ9nnTVUrG+/j7LcBo13rr6oVry1A1Vx7kJcxcvaL5NB eJ31iF8gTPpvOkPtN+kjwFxt7AA/XtSNH2DfMx5vkRedxe3kvQiqmaWPUNQZVemXkwBjJQ/ait1V sX7ffaVeMXYwsS2Gd1WLleviSdFo2/H3UBYrk/QIsDICZSGIxfUPrT3hsmLoz9HaSIQHMqtkzclC irsRMDPLOT7ZiY3vuZyjmG27A6GXP2cnWj8lshezyB+97bXB5ct15Rwb9QqyNb2dTCASr+xMHI31 g1VlNScWKwK+J7yucYYTTudj8xXlj3URyWyyI8kKZGdc3r3hwISFZMYXq6jn2O6D8g8gxU8wyeOE 6vTlvGL6VC/Y9rPlIX6bPjAjxzd66jZfEx6DViZl8Ftw2NzQfZZZb82ePIQp4O4N7RMWXjfiUXLQ eUp8B78x+qgu5ET8OpmMvwQnXtZ6XqfTBpEdxa4V+8W1g//1/L/R14Q394ovIopuPsy3rjrxPYDr fVlo9kOSq5+pEclGInv+hdErX0C05AY4bX8qE4nd2Yk2OsnGLAufhNCcb6+QNSd5pc25tsO3hG+R M2oUM+7kRmCI1IUm064ussckt+5Vw+1GMuNzFafSuW/JwrqXQI6FUAhJ5wirtMu2EihtxGaYNv9u sXntfbkPD7KfyZW1WCfDZK/ZU0e94UxWHAaRLBc3I6imKE9jLR3qudOTmTOXsU1s3DYh5UmGGZya UfcAOzhGAE57ZZ341p7wu8VUHst3Gn6VumykYFY9Sh4hsCY7ik7DgTldsqVJEb5ZH3jgjrjRV72A AGoZ7ESqxL2ocLshe6tOm/Yw96tQbPxbLfvmlHmhvbm0wVeEb8WBjtKO3gRzbA5onRlF1xUyq2Ry nW2oW2v50p25AEj3lDYC1cGVf4ZiuAfq3E4d8Jm6nMAsXfCEG5eLyPaiibX3DeHrESHVGWXwrPJ/ 1MeQOKfBHLngeNU1Dq3ER9JWt6Ik1erSFmPqXX8QkEbwOWzJLTGyvPY6wcYIhkbj7M9v4mixMf15 p1v3+obws9dWXoo65Hchr71X3XjtpJN2/BPUoPvxkjuueM6twaDvehOBar58E7PlA1Y8Ftc+ngwH np2AtucXI3zjf9XX12fE4XuxN75w2mH2PRkm/P+DFu/Ka0/T7aky0kkETD9QcfbBhV+bMoWKTXpR Ul1u0wEx/mMEYQxDCayLMsqbwQ9kBsMGZGjo6Zd+vXkc34Fjvr17lbyGX3G4pgLx79/HLPy5bCed E2yDAcNq7NnEEH7blLa2kqls4l2RK86WTeHNB6Tgv7YT8Y3ZDjy9TQcZOpfLwByva/mSJ7wZYp8X MLdSpajSlLc+5y11TPOqpMG0R55qxhcnFwvW6iWT2lehUuFiZE1mKAa9ZQctjzOt5BWzF7w0uWAN Oo4PlTThVyRqPgOy34H99iHZ9eNTxz8ltynBf1DLmzcfB3b0iM8Q0OWuUfvqaTsZfxnZc5lreWh5 aJDzuM3/1stavmQJjzLDkYDBboPZXuUcA5Xuk9cnuFqJTize74ZH/nWfyS11dwAITBPLNnAlf6tP FUpPrikWLV+ShNfhjpZd/lU46r7mjG1a1ZouM17/akkiYd4/gLGnR32KAOpWr0C67Cv62OkMj32X lkcK7df1qcJehKckCf/gushFnNnzod3NXjXk9baKstcrw/rX2nKKpPOiUHq9TYjA+wBtfCx1VHAP r9O0/OVXLWia5MV+lBzhkcE0GgUo52O//eRssqcKWSTbUXxyUTVf+Z4XB4TaVBwISGGtxG7u24iz z2gw/EKYAkSVJdmVXuxJSREe+e3BIJNzEQZ5hVOILMOU1+t2CyUK5dOVkw/+lxcHg9pUPAgsmTy7 FanTT+hTx9Jbjdh7nT5bAdbPxsGjo7zWo5IivLmfXcAUvxW1iBA6m+6o0+e+YRpQarXBxQ9pv91r Ylh87Wloa4T+YC/Z8ei72YUynJBbLs42lfyi13pWMoRvxZnttjRuQsVZ1BHPjJ/Rxzdj5v3Y5kYD HRjhNREs3vY0Ta37CwI5fovQ7Ewtj/oKcOidyKWYUVU131Mc81RjBjL0HYrNRPLSNY4PJd2U11tw cKkqrv7zxYWznh/IN+hZQiAdAa3lpQgug5bfkhFjr8+n0/XwODv7wXeWnOMl1EqC8DpWXkhVj+Oa YUWlm/Ka/Yh/YurNIYz/tKGhkU509ZL0lUBbzNihDZCypuwtOu28A7nOMEVwhpe6WfSEH4bqoVKx b2CRfk5Ks/dw2qlHJu19qEe0aIpo3ucl4KktpYHAtPK39uKEquUobZ6xRSdtmxll5ZVwEte0tlZl pti52PWiJ/wf97PTodW/iz331LZo16XPbE/VqlMvVq47+IKLGNOnSxyBhCFbbSv+TmbBSxRJSy0t q6KTRp7fFwS6avKKsppQIeEpasKvKKsaghLT87B+OjnzDDgY8nDU4XdbbW4tooMjCilSPvxWKLIR puSrKIia0XntrceK8kxLJpzTanQte1RdGoKDT0a3qEtq+X7jX4JRmYoGLdBV1IQ3Y5ELsAv6DSdc Nl27p2Llo1KI+3GE0JoCYUmf8SkCtfHnO5gtXkedO8tx1nVdOHUWWXQVIWwK16ySM84S+81vH+rk D8D4bw4I/ieu+A8YEwXdqy9awsNRh20PdQv23Csz99y7AZfvIh/uQZ/KIHW7wAjIQOBtbAe/nn3O vJU4rLPo/loqazV00n9wrubA+pyI+8Jo4if42VTIphYl4XVyjLTl1ZghP++AlbYNp/fcUX3kE6nE L7DnvquQYNK3/IfAI8PmBFBkZaipkgZ2g7Zq31HGldqiQ61Ls0KXV9MWQHecCFb4W5FUW1ALtCgJ v3h1ZAwI/T3MlDgxpscrr0177SzFqSBLN504/hH/iR/1uBAIaEebLloJM33aGXu3fresjD8EsWsS zJhjJ5FLl3Vp5x2UkEP0LkeeU3wF/9iztX3dlkK0ufsbRUd4HbmEfIWrUZ1qSmoLLo3wWrtLe6cq Uz+67gCdA1dIQfLTt8wom27bqgnBXK/BKXcn6PxlKJ/xUN6ZXrujgYIb9T49WL/juhEHCnpeYdER fvHqpjHguC5ZJTK0u+Oos5KYCH7zx3+tozLTfmJggftq8fY2sPV11LYLYivOTJ06rLV3bvVPBWQV VXM6sMO0vsBN18FAxXNp7Y50uC/1qd21d1SpTTj682eNjRRRVzyjWnwtreVtu5Vh3ikT8SdBdtXf Shc6DBfPaP/S+4XufVER/uF1TaNwaHef2t22rDgKjj2M+nQ7Cg0ifc9/COha9SDuAiRlLXU88xln yR8bD6egKlN7ElLqQhoFvYqG8Fq7w1F3NXbce6/ddQVaxrZYhnyooOjRx3yNwDSxfC1y4m9DlN2a VJRdbrre0fCc72q6ow4BO4W9iobwi9c2jYaHE9pdZHrm9XrISnZr948KCx99ze8IVPPmN5D7fhOi 6jZl58X3hY3elsP6Hct9td2NZK6iILxOPghy8UUEy5+dmkTTt+KcYyFJu/udeS72f5poXgqRvBnR nfuzD6nIbpZjzlvxA7AGCu6w020pCsJHJ4WHc2nf4Gj37Fx3oIxePIG1O2l3F4Xe75+ebjY/hWCw m3EKTWdmEk0mMl158x8jYsSVmopFQXjJy6fjqKjzHMdIBuF1DL3aK7n1uN8FjvrvPgKV7x/8FUqp 1UN7x1Cboc8GOYRXfA9q4RXcYVcUGh6FAIcjSuF/6/OcM9NfMUdaSRSg5c9Uru1Y5/5wUwv8joDO yvw4xhYzmfwxdusSfZE+peHVrucWXL7NDbw8r+GRDVeNGbHOyUJK1+46qg57mahhdx+lv7ohOvTN vhD4UnlzB2OxnyMI7EFhGrYTQtt16b/biSjCc4wPGxoaXKm+5GnCryi7shInSfwPJngAoUwZwEG7 2yhE+/vrJ1/aSqJHCHgJgWnirT1S2D+WycTTWst3p8xq7Y4dpf3gvSsOO8+b9Ga04zQm1exUvntW zDxTqEIbuK8NhQS9NNjUFkJAI4A6DBtR5GqhlMnljmkPC1UTHkpql7Tccdh5mvAtw+YEhbK+woQx JPtsOK3dgeCf5tbvXkviRQh4FYFqsXwNzPdbbTvxrt6u01WYlDD2WoFYQXPg0/HxrElf2b5nGNbu 18AcwvZ7mnZ3nB7sIOfWY22NOL6XLkLAwwiA9C22Mv7JTia3GyaOmJZqdy1/y7UtZE8SXp+v3cHi NYg3npSKUe4mvD49RnNcfZAIm3TMs4cFnZrWg8DF5mtLDMn/b7zjwB6pVMHDaT2v4esWvTlE2PJv saeZ6axDmpyUdgzxy0/WxpsPkVARAsWCQHjqvielkP+A7WVXncye1PBmrP1UaPErejnrnLRCtddk iSeLZaCpnYSARkCfZ1gtmnGQ6b5H3UTEc4TXzjpY8F+Bdq/s7axL6PpVTddPjn7oJmj0bULgeBFw +yBTzxFeO+twvvuXEeaPE2DTnXVOUw9C8z/W1kbOuuMVOHrO3wh4ivD19fOP4azTJ3mwDz5OjCBn nb9llno/AAQ8Rfi6RauHoNb8nKM566Dvn1x954XkrBvAgNOj/kbAU4Q3o3tGYdtt1tGcdciWedKt GGR/iwn1vlQQ8Azh61HCSrBgjeAikg6uU2sekXWo+/1K5fsd5KwrFcmjfriCgGcIX7e6qQJOuivh lDMzEmUwDSA8qRNRd3+grDhXZIQ+WkIIeIbwoXDsBK7k55wSQGneeV0YELG1u81A7JUSwp26Qgi4 goAnCK+985KFqsHt0b3MedvCIR+8Jbw22u4KQvRRQqCEEPAE4ev+vinMbH0wpKPej8CLGna6fncU 5vyLZM6XkNRRV1xDwBOED41lQ4HATBAc1ntaApzOIWasHYf5kDnvmojQh0sJAdcJrzPjcGLMhYrJ 8dnmvLKT+mzY5vDkdjr2uZSkjvriGgKuE/6rtzweQgrcLDjn4J1PK/PlHP2sotD4Lz1x7bWU9+6a iNCHSwkB1wnPwhEkyfArhGPOZ67fYdAfsETiZQq2KSWRo764iYCrhNfmfJSxSdhnPyO90IUu+oeq n2C/fNMcbrpSztfNQaFvEwL5QsBVwtcteqkMrK4D2XuZ8wi+ieFEmRerD6y08tV5ei8h4DcEXCV8 KBoLwyk/A4RH+fleqbCfIMz2Zb8NCPWXEMgnAq4S3uJmRB8Q6RTr716/w5xXtnbO87VWZLxr1T3z CTq9mxBwCwFXCW8q8wzFeXmv7ThlJzADNM896R0y592SDPpuSSLgGuFb9l1UZjExHZZ8ZnSdU6WW xZkh36XKNiUpc9QpFxFwjfBW2AzhCGgdP2+kr99xPIeGozMBD72LuNCnCYGSRMA1wofCrEJxdkHq +Nwuh51ev0tY8YptMiMTt5ck4tQpQsBFBFwjPEj9V3DND8tcv+sTYmUCZ2evnPu9M2n97qJg0KdL EwFXCP/IvmEBZMadC0i1eu9B1jk0kselLf9yLU6YKk3IqVeEgHsIuEL48eGLQzZTn8X+e6bDTufG MRU3hfUXCqd1Tyjoy6WLgCuEZ+FYGNVpL3Ly3TOq2+hS1GpnLGy+X7qQU88IAfcQcIXwpoqeDGU+ Vpev6r6cYpXStmDIr4ysbk+6Bwl9mRAoXQQKTvjW1iqDSXYeIDUzYAXhQXZ9UOTKJ574KqXDlq7M Uc9cRKDghG+/IFIGbl/YV8CNZPDQC/l2Q0MjOexcFAr6dOkiUHDCs3YWYFKdzoR2w6d76PWWHO+0 xo58r3Thpp4RAu4iUHDCR8JhA4UtxjnV6rr57iTMWDolftOkWCVS5OkiBAiBfCBQcMJHWTQEro/X Hvpuxmvyo5SVxPp925KNS/LRT3onIUAIAIG8Er5+/ny+ouzK8hVlNeX67xpx1LE5Dew2M7bjUgkz SaH4xvd/Po8i7Eg0CYE8IZBXwl9w6+ohwc72HwY7ef3sBS9e+4aa8RUh2WXKyZBJ98s55r2FH1Sn fbxnry5PnabXEgJ+RYAjoi1vfV8la0YjrmYDN8wh2GK3uz6kCY2Q2p7LOV7KtqNMqAewN/8aylbv M7nciAkA23OxWCwcStTGmw/mraH0YkLAJwjkVcN3YWggqAb/E6bz46THZV5KYi7gLAwv/Y0g+W+E UksQU/8+bID1UpY9EYyJL1fhdFmfjAl1kxDIGwKFIJHUp8nAJ5f6ST9ZJqtbejLomhgC+GuQm2W6 Gs4wwQ43tbU1UjBO3sSAXuwXBApB+Jy/0TMxpKx/mYwfYJLfNY2/RbnxfpFI6mdeEciZjMfTijB2 2/Ac6tP179JJdNJGPh2Tz8hR1uP9e5ruJgQIgaMhkFfCt2PT3VZymSZv6qCJ3C4s+aHe7Q2GCP4b 1aXPDTO6ixDIBYG8Ej6yqf0wjpD6HUJoLacUdQ6X9unZtnWIGeZPpvHlFGabA2Z0CyGQKwK5sTDX t2Xdp890xwdeRe35fbm8Qk8KOr4eVembEmH5SC7P0D2EACGQOwJ5JbxuRizM9iHO5jl46FGC/thm vbNjJ+3tAcEWYN/9UO7doDsJAUIgFwTyTngQ97AU6ik0Jt5VgrrPdjnBN1YyKjm/+w8NdWtyaTzd QwgQAv1DIO+E182pVOwN2OkfZIbTpjW0a32PqLxllWPZ/Y2UD9+/UaS7CYEcESgI4TuGj+9Ams7v dEZcX847obW7tHfij9un7CJTPsexo9sIgX4jUBDCVx94NCE5e0YXuMjennO88lZS17BbfP3k9pZ+ 94AeIAQIgZwRKAjhdWusWGQjNHyzE1rb7bxzTHkdnSPfRHr8PXSWXM7jRjcSAseFQMEIb47dcxjU fhZrebvbW489el3pZg/+bJjGm/ceVw/oIUKAEMgZgYIRXkfMSSH/pLjek0eNG5jy0kpKJfjD8o11 S3NuMd1ICBACx41AwQjvmPVhcxeKVyL1VcKqdw6hWJPk6mfV1Qeoys1xDyE9SAjkjkBBCd90a91h rsynYNaj3kXyEKpZ3lHLm3fk3ly6kxAgBAaCQEEJr+vNC2b9GQ1ej3Db3088eOozA2k8PUsIEAL9 Q6CghNdNi41lnShhdXdCxOePGPEoHSnVv/GiuwmBASFQcMLXIrBmycLLHqgVb20eUMvpYUKAEOg3 AnktYtnv1tADhAAhkFcECq7h89obejkhQAgcEwEiPAkIIeAjBIjwPhps6iohQIQnGSAEfIQAEd5H g01dJQSI8CQDhICPECDC+2iwqauEABGeZIAQ8BECRHgfDTZ1lRAgwpMMEAI+QoAI76PBpq4SAkR4 kgFCwEcIEOF9NNjUVUKACE8yQAj4CAEivI8Gm7pKCBDhSQYIAR8hQIT30WBTVwkBIjzJACHgIwSI 8D4abOoqIUCEJxkgBHyEABHeR4NNXSUEiPAkA4SAjxAgwvtosKmrhAARnmSAEPARAkR4Hw02dZUQ IMKTDBACPkKACO+jwaauEgJEeJIBQsBHCBDhfTTY1FVCgAhPMkAI+AgBIryPBpu6SggQ4UkGCAEf IUCE99FgU1cJASI8yQAh4CMEiPA+GmzqKiFAhCcZIAR8hAAR3keDTV0lBIjwJAOEgI8QIML7aLCp q4QAEZ5kgBDwEQJEeB8NNnWVECDCkwwQAj5CgAjvo8GmrhICRHiSAULARwgQ4X002NRVQoAITzJA CPgIASK8jwabukoIEOFJBggBHyFAhPfRYFNXCQEiPMkAIeAjBIjwPhps6iohQIQnGSAEfIQAEd5H g01dJQSI8CQDhICPECDC+2iwqauEABGeZIAQ8BECRHgfDTZ1lRAgwpMMEAI+QoAI76PBpq4SAkR4 kgFCwEcIEOF9NNjUVUKACE8yQAj4CAEivI8Gm7pKCBDhSQYIAR8hQIT30WBTVwkBIjzJACHgIwSI 8D4abOoqIUCEJxkgBHyEABHeR4NNXSUEiPAkA4SAjxAgwvtosKmrhAARnmSAEPARAkR4Hw02dZUQ IMKTDBACPkKACO+jwaauEgJEeJIBQsBHCBDhfTTY1FVCgAhPMkAI+AgBIryPBpu6SggQ4UkGCAEf IUCE99FgU1cJASI8yQAh4CME/hthA9CUy9MWMQAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image018.png" Content-Description: image018.png Content-Disposition: attachment; filename="image018.png"; size=1699; creation-date="Wed, 10 Oct 2012 09:43:18 GMT"; modification-date="Wed, 10 Oct 2012 09:43:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALUAAAA+CAYAAABtJFqyAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAY4SURBVHhe7V0rkNRAED2JRCKRSCQOHLeBKpBI 5EkkVdxuziGRK5EnT95dIlYiTyKRSCQS5vUksLefpCeZJDOTR9UWRZFPz5s3PW+6eyYnJ/zTC4FX efkCv9Nl8WGxLC+6/Opn1H+/zm+e9DKKNxOBJgTuEXZVfs1WxcYQ9y5blX8G/y3LH3ifec8XDBax JS+esceIgAqB5/nmwT8CG/KORtyOg2OxLH4uVsV1TXZVI3lR2gi8zK8fG2KcGS94aYjxfXCv25G8 TnYty2/i1c9v3mb55lHaPcjWncATS2evynUm0/oI8mHqd5h2LjDrmHaTAokgAP1pCPzR/ODBhtfA Ab/DzEq/MCudnt++wwBPpIvn0QxEDozW/AzNOXciH23/svht/u8qO799/ybfPJwHMyJrJTpG9PFI HtlqcIlKQI9fYDbYDcvV/z4EJfT87vX3QoFmUFZRlrG0/lX2qTyNrNvTNBcdAWJl1vMMIC+EuGsM GJBwqmm7HgSwQwaR8bKDLG6NBke8nd575PFivTKSHB7lhQwKE3+GhzRTcpbfPh25WZ1eBywwsMVu O3P4GdgGDywwmQTq1C36mxCiskkIWfD07zwjVUAGeGC9FeFfifbI4hia2ccMZnDC4jL8lkdkocST JZPXj8jVdL1GeGsu0yvkEghptX8/ZyD4UXf3GzkSjoO36UFm6QjjtTAw+lmTxt0Y0BK37kVwI3Mi kWfB9BoA66MPqw5bs0aiuUtrgnd1GjJ7MmvZDLIsepDt6+6Zr6j93H0TiNl54Y0FpVm0z0XOOaFr yzbdNZ8U9SDERY/hhPexiyXy0yHWL5Eoc68XI2J/iISjuhQToabBxGynihvHjnub/ZBuXRbnqBqc rYPBwq3LIlDKQekR2jjp7f+rfrp0kYQy486tjyA13OOnZsXNcJI3sro+yEai3JI7s/DasiDB9OSw EIRnTi054kqokK6XiImDXEzaa1vtrE9r2wVgcRZSh9KW/whUC3uXKsh1MusfNASpbbV3ZogomrEj NThSc6LM9CKqEnuUSuqaHaYqqbaLvdHRUNKfoZCH2lkY10WbFHNZDIL40TbUHzeifpL12sr6HJmN I5OWVb2vtoruSzJaK2pa+jHece209vPWgZ+i1c8yXTFEN3BvTPN4W+6gC//Bu09jpfKt6unHVN6x VkAJasSXaR0cknDBzdZVhKM165R0zDJi8g1putRyKzYqIH8xKrGlSN8G3S8gGbZrk+UsDUVCRdLb jGwMyZ9gny2lxJpzVkzIb9AZvC4DPVo5Z0cfDoVpPU8DhB7U2GC7k4bVCGh1NrgyiMd2XME2Rjng xUlokhsIqGd131LEQdy3huxG10nkTvAIWGK3x7O9RUWqDZqtZNWkRWHUINNI8N1GAzUIqIht1nCa Zx29xm7p0RccNRHb2yjr1SLeHDoCmiRdr8yj1F1oC1Marys2oYNJ+8JBQCV3uybpuuwPPDQIUMcR DmS0JAYE2kLCUBDOwQZU0/nx0rYE0dmAGJCnjYMhIIvHls+NOEva6iByLwtEkJo7VQbr/2QfLHsh WxI0TbySk6i2v4UjZaJe9HRVLD63TZfJUm3chtnMY8PptYb0uxE1IbM9XsN8/2arOMq3p2Zt9Lhk SOlt1Td4mlSDlKtuk7l2yPdIXZ0m6k1+UFOnRLPx26IoW8XJt3v7I/d0t68YNXTR+DDwjSkhYPW1 +yH6e6RWxQsVuhsbMVMCmG2ZBgGFDNlTFnuklppoTXlgA7ERo2ZqfBoSpPZW2fPomOE+GPaTE+gV 3vjYNVwgpkat8dtjySyfPnH+WsTRWLbTOQ5bAwBhlfEh4BtTQaAPmQ9GP3aBcamn5vEGqdBqunZU hL7roxJwb2vWcWvny8GjpZDWhFenhp6ODCm9ueJbv0+huOxMxwurU3jkW4Ipgcm2hIWAyyFIu569 1VOH1VRaMycE5MB3x8iHSn7MCUS2NTwERGcrTinY9tb01OH1Iy06gED1kVNVCQdJTQpFg4BWjpDU 0XQpDQUCGjlCUpMrUSLQtFmXpI6yS2k0EDh2yDtJTX5EjYDdA3D/uGCSOuoupfE1AttyhKQmL5JB oJYjJHUyXcqGAAGRI9zwTTIQASJABCJC4C9sYoJWkEZmVwAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image019.png" Content-Description: image019.png Content-Disposition: inline; filename="image019.png"; size=3707; creation-date="Wed, 10 Oct 2012 09:43:18 GMT"; modification-date="Wed, 10 Oct 2012 09:43:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALUAAADACAYAAABCvCLbAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAA37SURBVHhe 7Z1BjBTHFYZf1Qx4HUDiiBRvTG6OFMnLIWF3k8jsKXAC3/AhAg4RPsIhsjjhPWGkSIZDZPsEPmVz Ak7gQ8RaSXZnk0gQKZLXJ5AIErnZkgkEpqvyXs/MBpbZ6e43PTOve/+WIkWmXver7/1b/epVdY1b XFwkXCBQJwK+Tp1BX0BACEDU0EHtCEDUtQspOgRRQwO1IwBR1y6k6BBEDQ3UjgBEXbuQokMQNTRQ OwIQde1Cig5B1NBA7Qg4LJMPF9O/xflDcod2QjPe0V7N3byn5U12j37iVtY194INEUSdoQIR7YZg nXszhrCfotvrPM2MXEDR3Y8U7pN3d12kb0X8baKnc26lNfJnV/gBEHU3eH96bX5q6inNpgL27u2Y xJmxCFcpnhjDo0h01zu/JmLnkX3zaK+8c/XNtq2oV+NP9/ukeTj6+I4LboYcvVX9cFIrOv5fCF82 G77FQn9Ugz4V7sK2EbWMxM3H4bD3/pcU3GFycX9hWlUz4PSFt6wth5DcmGu2rlfNfa2/tRb1apyf 9Qkd4lH4KAOa1UKqg12M8RsW+K0Y4o32Ln/9F/9deVqHfvXrQ+1EzRO7t0IMJ2Kgk875fXUN3FD9 ipEF7W7xPW7satD1H7uVb4a6nzHjWoj6n3F+7+OEjvOIfGIsI3Kk9UjxEY98j1x0X1Okp75BfSsS /SZwks83qflS+hMCv1F6lwuvxeBmHbl9Y8n1I3Fq4j872PyzCL3yV6VFvdb+OU/0khMu0DFybqrs aPAre9l5t06B/sGiXX86Ra1JvLZ7fwQh4cmso338R/Q291X+f7mTW87BA8XLexp0tcqjd+VEnY7K gc5wSet0aekFv465PNZyPrYo+K9Dg+5yLfhu2X8kZd+v84bys+Tb76Qju3P/H+2HeZikJ94veRcv VnERqDKi5lx5XxLpAwqRc2W3d5iYdW1b5MIy13m/qFONVxaLeESXSfFBoshVnqHfYC2eo1zm6slS CczHcgvzok7ryXHHeYrx5FBEOA/ulLfCF3safrnKr9e8HLplzGOcQh3lFOrwUIOB8CN/tgp5t1lR d8txH3DeeCxvEF9plwaCPg+N9tKc++t99X1qYrjanj3mfeMoL84c0wpc5hmx4c5aTs/MiZrFPOOS +LE2P5R6LI9MS8HR59gjsfVfY0/g6jegc1c55z5ncdXSjKjTSU+kCzyzf181MHJZKlD4Q5VyP1U/ SzaSuQqXE99XTbxlQuncxV2eLllK50yIerU9f8ZRPF/0lSibergC8hlv6PnU4ohRsv5Gfru19vxJ TvdO84MKrb6mcSB/7mBz5erInczxgImKWurMROHjwvVW2dNA8eKzXXR1EnXjHFwr3SSdz0R3umhq wlWSW7yR6tSkB5iJiLq7Q07EXGgSyEvfd52jy1ZGhEorN4fzEicXGxd41fR4juZpk3ROQ46rJJMb tcf+OZekGj5pfFVE0DLjpuiPzO5YOTBJWHkDW5d2UjGa9avvBU9zaQxyXGkK6egKT0RvSr6ew6T0 JmMbqaWD7SRc4cUOTjnyXTIyN5p0tk6LI/l6brNVWjEhfyFvujipUbuxsLAwcoKSO4eY3GRBz+R5 WGfi4X7DI/Ovv+8ecP6MywKBaf+v9Tf8g989CNPf8lxohkfl3YP84n+fkjfyQ5red29q+o9vJg/4 a7TRXyNNP2RFqxXmOXcON3Pt00i3RNLi7ob/EacZn46++3iChsBcc+WSxIjj+lEuey7T7vwP3R5X OjIyUcu+5p2P6Q5/MHomT8eji0u+4X54sLHyoaWaZx7ft2MbidFB3zrH5dQFebPmYDCbJOGOVFZy tB2qyUhELZPBkMQ7uXIvXsqWiYhMSCZdChqK5DY1lvlOZ9R2V7MQyNvaJ/E218N1C2xZD+j+e+mi XkvmP+TzLzjlyN4dxh+JXuJa8wEsZ+eMltFmnVH7L6ekQpU5anfy7E/Wwvwno+pOqaJO82ei81nO ph2XEp1fOYvFkyxa1fl32cEno3au8h/n2WvhZ1dG0bvSRC0O5sqfeY9GZyJYj0+HRhGUKt9TRu3Z 5uqCvIUz+8HbiTkVuSYFhcy2BRoMLepOhWPu91lLqunXzJFOcVXjXUwEC0Sook3lLczL5u+xLgZ/ tc4lPz66olRhZy6+yFIpJZ7PieMac/St0Hi23tub3N2Efi1rQaW7iHIEE8GKKnQIt2UrsU/ctRzn rLR4t9+RMga8vqLubQPlMyKO9905l37DxrPdmJ4nN7BEI4Le3aSFMpwdgi1MJ0hA9PRdEq9l7ZEX rTzfTXPDzrNeST9k9e+7JHwl+5q33AoqM9jOvueBgpZdWxD0BNVk5NEyoD3f5Y6IHga5JGcXlpGK vCTqQqt/GcCkA3wSEPJnI8KatBsy+ooesurZksrufOKGKvdt7P3gzSrHPbnfltJ5LsQ//5771bCv kVJ8wU3MEJC9H2+4Bzce0g/2s1OSum51zTyM0473mSxrnE9FLWvyXJ2QnGfgBpVcD2BBSyF+XJtX cvmERqYIpMJm0bJThwY4duhhmP43C/vvRZ1P048kyoeuw587J0X3dGUJFwhkEJA9Ppm1bFl5TL+O KnZ1cmo+E6KYWf/W6dlvuEAgJ4FuLXvg5DFS+4pUT3LeMm3mZTdd0Q9et3wAn+1W1IEizqJt/QjI 5FFKeVv1TDKIx9HJ9ovcl+evUUo9ZPDJ4AlAbsfQcHsQkGJCbLbf5d/Rub9lj3k5vfeDUf3ayCLg i1taOf3w+8vEx+e4lXq/Mn3DvWwSkBXq0Igs7K2X1EPirmzeI5KKmbc573gc7qVfv3cvFjX/+lOJ F58YKkd94QKBQgQ6x5i5s1sa8c+Z7HzCW5r5eknMvM15c5HDyw/eFHp6RuM9BFGXyXM73Us+4Ru4 bZVXsWWBMB2Z+4h5Y6SWTUaZG7vzkuW8CHs88sJCu34EYiPhjw22TkNke3NW+blT0uMDtktB7JNy 7lOKM7hJFQl0doAOSENydCoV9fPX6dzA2WeOG/EGp/Vnr/vFPE3RBgQGEeAfV1oaJntIRS1lFd+I Q60E8gTxFPZ6QKzDEJA1DvnGlbep3stKMQY9Z2OXXnoKUt5zHDbdMUSSQ7hLnXAOAwe21SLwopjZ 88Kn327u7UtbT+Uch1xfBPfu0j3eQA43qRZGeGuFQPoBQZtulyHmXp9e+Uig90Uwf8bO5ZX+h5Sk y5o8quN4AyvSqK4fUi2TD0l4Tna9rF5kfqMof0my9C2/4Se/JYjDGstCj/tsJpCeiEuRD6DMPjPm FXrdLc/y3zNFDfQgME4CsofDJYH39hfcCv2CqIc+ImGcHcaz6k9ACg5yLkzW94y5qh/1x4UeVoWA 5Nn8g1RHOM8+p/EZI7WGGmzGQoD3gnzU+RWDXKeqbvgEUY8lPHiIloAmHYGotbRhNzYCG+kIH8if 56EQdR5KaGOCgHysm+eQd4jaRLjgRF4Csk7SaPgDg/ZdQ9R5aaKdGQLyDYAcF8wO9U1HIGozoYIj RQlslY5A1EVJor0pAr10hEL8sucYRG0qRHBGQ0DSkRd/CRmi1lCEjWkCELXp8MA5DQGIWkMNNqYJ QNSmwwPnNAQgag012JgmAFGbDg+c0xCAqDXUYGOaAERtOjxwTkMAotZQg41pAhC16fDAOQ0BiFpD DTamCUDUpsMD5zQEIGoNNdiYJgBRmw4PnNMQgKg11GBjmgBEbTo8cE5DAKLWUIONaQIQtenwwDkN AYhaQw02pglA1KbDA+c0BCBqDTXYmCYAUZsOD5zTEICoNdRgY5oARG06PHBOQwCi1lCDjWkCELXp 8MA5DQGIWkMNNqYJQNSmwwPnNAQgag012JgmAFGbDg+c0xCAqDXUYGOaAERtOjxwTkMAotZQg41p AhC16fDAOQ0BiFpDDTamCUDUpsMD5zQEIGoNNdiYJgBRmw4PnNMQgKg11GBjmgBEbTo8cE5DAKLW UIONaQIQtenwwDkNAYhaQw02pglA1KbDA+c0BCBqDTXYmCYAUZsOD5zTEICoNdRgY5oARG06PHBO QwCi1lCDjWkCELXp8MA5DQGIWkMNNqYJQNSmwwPnNAQgag012JgmAFGbDg+c0xCAqDXUYGOaAERt OjxwTkMAotZQg41pAhC16fDAOQ0BiFpDDTamCUDUpsMD5zQEIGoNNdiYJgBRmw4PnNMQgKg11GBj mgBEbTo8cE5DAKLWUIONaQIQtenwwDkNAYhaQw02pglA1KbDA+c0BCBqDTXYmCYAUZsOD5zTEICo NdRgY5oARG06PHBOQwCi1lCDjWkCELXp8MA5DQGIWkMNNqYJQNSmwwPnNAQgag012JgmAFGbDg+c 0xCAqDXUYGOaAERtOjxwTkMAotZQg41pAhC16fDAOQ0BiFpDDTamCUDUpsMD5zQEIGoNNdiYJgBR mw4PnNMQgKg11GBjmgBEbTo8cE5DAKLWUIONaQIQtenwwDkNAYhaQw02pglA1KbDA+c0BCBqDTXY mCYAUZsOD5zTEICoNdRgY5oARG06PHBOQwCi1lCDjWkCELXp8MA5DQGIWkMNNqYJQNSmwwPnNAQg ag012JgmAFGbDg+c0xCAqDXUYGOaAERtOjxwTkMAotZQg41pAhC16fDAOQ0BiFpDDTamCUDUpsMD 5zQEIGoNNdiYJgBRmw4PnNMQgKg11GBjmgBEbTo8cE5DAKLWUIONaQIQtenwwDkNAYhaQw02pglA 1KbDA+c0BCBqDTXYmCYAUZsOD5zTEICoNdRgY5oARG06PHBOQ+B/1yg0Xkcaa7gAAAAASUVORK5C YII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image020.png" Content-Description: image020.png Content-Disposition: attachment; filename="image020.png"; size=3739; creation-date="Wed, 10 Oct 2012 09:43:18 GMT"; modification-date="Wed, 10 Oct 2012 09:43:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIEAAAE9CAYAAAAs3wHqAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA4wSURBVHhe7Z0vdBw3EMYPBgYGFhYWlrWs9rXv tbAwMLAw79XnMws0DAw0DEy8Cw4aBhYGBgYGtpo9t00u3pH2j3Y1ml/eM8lppZlvvtVKo9HMZsO/ WRA42zffb/9sz8537ZX8bS/bm+1lczj9O79s3sjvZxe3v8szswxOJ+sg0Bl91z4Xo253zadg9L/H /gVS/BWevRYSraMNoyYj8Mv+7bfB6C/Od82HsQaPPRf6/iiziMwUyYLRMC8CP+wPj7YXt0/DW38X M+Dsv+/a9zLb/Lo/PM6rJb33IhDeymc53/pk0oTPzfll++qn/ZtvMNdCCNy/+e+TjTRhPTBojI4M zQtmhoxEkMXe/SJt9CJvkFFHkkdmJ23NIHr8vG9/ZPcxgCzy3Zc3bLoBm8Nx4XjcAoohTv/k/49b yND2uAgcT7iwTpFPxL/rlm6n8kB/Qmz5tDGD9JBiytsfwH0nC7cpb5wY8WzX/NFnwBhJOiLJAjKB TN36JixyB7wf9Te9d+oMexMD4PKcbBfnRkjeVDHSAp+k67llN9efgD34zZO3bcG3qPM+9kzvKW99 rI18HswZbi6Bt/vb71Knzw7IhY1/quf95+pdzKiDfw87DVmvzIWrmX5kUZbs4hVXcPjel6Jct26Y upA8WTfIGkEWlaXomF2Obu+fsHi6f/vvcnzzpyq53R+ezP6JWPATN1X/Sc/LG51EgPD2yxs3abDM D8+zlf1iW/o6s8jrd5+8A5Bvf1gvrC+xLsHcM4F8YkrXeZJ8yQQIjhsrjpRBi9rEz98kkEt+OJ0A rak9MyRIZJ3sgVPWAEKUxC6LaZbDkVSMcnMJ0m0DU6ZBo6tiOVJO0i8Fg9BGSDUX9kX0I162JD+A UQIIyKmz3ACimPocqkSTlX2KM8V62FZ3vjAxpvELghjYESXNMEdgEk7SDM8AnwMxYNEbOxy7SQLY QqPA7Nex6c/iIlDDPkVnDZNu1gweSAv2jcooHr4YAcLvL6MdGWvQBcJIPEPiAvCLdkYcY0kmkVOw BBCqdYtKQMrQKOiOOLXMAN1hSiT+X7Y/Hk7JukswsbsQx8Xky6rwiPnQ5ZvnLUT78/jF/6+/tS/l BNWKWzzpE5C6Vz6/ePtbcoc0tIWAnPPH9sly3GpLK6RNRqALrY5eB2sOyR3S0B4CMSdJtziqZeVr zzz5Je6ugkf2xKwD8tthtRFSHCNyuraagAycH4GoVzB4wKra/+aH1NYI8o2P7QamXAOzhYZTaWMH JWwHKyeGLPQiJ2G+Lk9Ubu+v1DsuBvXcQOwGKmdFdDEYYggqh8C3etHFYDgR83Y45I4RYR1wrTqG Croo6s44Syh8DJToTw7p7ibtEqCXNkZ0S8gRcWkmm1eeLoGEcj4goVHzjkhvxSEQmwVcZtYozkoZ BYrNAkKQjMPTdQkIxGYBC7kDSsDRrAwJs0A99+XMWimz4OosINtFooUyW2Dl7pkFVjZACcMzC5Rg hRVl6LyDetwga4EV7bPI0OoZAWuBRWyw6iCxeAECR1c1zzKDR9Ou1JJBYxk4bY6i3q0Pt4xsaoXU yQjE8goQNpYMpd2G2raQeAG7dk2WPB46Vk56+WSlaDgMATVLN9vCYWBabM220KLVZpY5mnKWbeHM iBfYHdvCAo2ypEix00K2hUtaY6Wxwrbwpu+wiG3hSkZZcthoUmYukyxpjnXGUiuRsS1cxyhLj3pM rPhwYWhOC5e2xgrjdR5CLXAkFKpYQSyGXBIB7Yo5C8IlLbHiWJHkk9WloF8R6jKHjsUQcq2sTLvN KpWagTSknZt1MDorEwGthh9Zx8q02axSxdLQlliVfFYA6CzU7wvp5vvdxJUVZMTgDyOgpp/DTVw/ bWKBpGQeq58DGym41O8lpChF9RS4DyH7qBwbP6seBO8KdkWr+84KODH0QQ+ttLuUsfOBgnMttcLV 1iuWOzdtmvqxOMLqCjSmweKrlZRrZVfgy+ZfaatGEO3aK+fw1K9+NJiUiyX1k0C7XSQu5PoRQMNw YNS+IpjUORG0AyO2hg7IwdbQgZFjKuqFrDkwiuFXxe9sDasw43gluq2hdrmEreF4cK08ydbQiqUy ysnWMCO4Vrpma2jFUpnkZGuYCVhL3er1jNkaWrLlaFn1zKScGo4G1tKD6t0C8g5YMuU4WWM3joki Goerqae0PESUszVlyvHCav4BuXwyvmeeNIOAmp304vapGUUQdBwCsfMC7hqOw9XUU5KCVstOakoZ hB2HgFrKjurm40C19pQWPyBeRGv6IO9ABOTW8VYulvbEEEiamoFd0twaAmoCikAOIYk1nZB3IAJc NRsIWI3N1UOjkKyqRp3R6QSBcGjUn4UkbB0BrHIECCKp3MAp6mlFrjk0SkGwgjaak4jiFRUYOEUF yTnU6x/ASZQCof022qKQtPX27RvVIFbGhkiiKIT2G+j5CaldYN/CCRronsL2dUIXNLGOgF7hlPBy 6/ZNkl8LJ6POcRKEtht1x8fK9XOqmNi2b5L0mrtYto1JndDINgJ6reP2zrZ2SJ+EQCSm8DqpExrZ RkBzF8uhkm3tkD4JAc1dLOuFpE5oZBeBmLuYmEK7tk2WXHMXSwXU5I5oaBeBiLv4xq5mSJ6MgOYu FoIkd0RDuwgEQ9/1egvJRmLXsEMk13YGuIuHIGm0bewKulG1EHsIAnKvkMrnQxCrsK2at5hClxVa /AGV9DoGLWcGHmigJaciD4EHBgQd2R46MbSmppaxlO2hA4KwPXRg5JiKekgZB0cx/Kr4XU1Tx/aw ChtHlYicHrI9jCJYQQPJT8wN5AoMOUUFtdYhaWmmQGvnWbaHdmyVRdLYjSPiCrPAXlan4gjqDSTZ cQ29LGtlkobtYSZgLXWrZSmjqoklS06QVTtClt8mdM2jVhBQ6xtR2saKGafJqd09lMso03rnaRMI qEWuuHtowoaThVQrn+4PTyYPQAflI6ClpilfeiScjIBa/hZH0WR8TXSg3TWQmEMTSiDkNAQ0b6FU PZnWO0+bQABvoQkz5RUSb2FefE30jrfQhJnyCqlVO8NbmBf7YnpXbx3hLSzGTlkFCSR43+sswluY FftiOsdbWIwp1hFEzVmIt3Adoyw9qlr8Em/h0uZYZzy1zhHewnWMsvSoWkp7il8ubY2VxlPL4FIR fSWrLDwsLuOFAS9xOI0E5Cgq0WIZZOLcIAOo1rpUs5Vd3P5uTR/kHYGAdh2dgtgjALX4CCSwaLWZ ZZZKJn1nBxKAOvNwdFciAtoJIiQo0WIZZNrumk99MwGJKTIAXmKXHCOXaJUFZdIymMq1tAVFYai1 EODm0VrIFzRuJI3tu4JERZRcCIgzqH9N0BxyjUu/BSGgVkIll3FBlsooCgElGcG10rUeUNK+sqIH ck5AgICSCeDV8igkqMWSE/SABBPAq+XRkLbuhVIN9aoWPdFDQYDQMuixgQSQABLAgQ0kgASQAA4E BMLO4Ka3+hnh5j44QqSxDzurWkICSBA+B82h73PAxRMnBIEETgytqQkJIMGGaieQYMPtI0gACeBA cBYpmUy5h+iEIZDAiaHV3QEzASxgJoADrAngAAtDOCBHyawJ4AEkgAPMBHCg+xzckbnMORM4RXRO AFEfEkACSAAHmAngAJ8DOHBcE/TfOyDQ1AlH1Aupf7ZnTmDwrSa3kn3bv9MeEkACSAAHmAnggHwO du1Vb1rbi9ungOQAAUjgwMgxFfUUds2z2PP8XgEC5DGswIhTVaBY9lQEK3ieLOcVGHGqCnq9A7Kc T8XXxPNUPjFhprxCajWQJOoo7+j0XgQCVEMrwgzrCrHdH570egzDxZR1pWP0xRDoJ0HzaTEhGGhd BLRayetKxuiLIaBdRZPPxWKCMNB6CHAfcT3sixlZu4AiW8hiBEWQfAhwCykftmZ61sLOzy/e/mZG EQQdjwDBpuOxq+ZJvSwegSXVGFpThMASF2bWlTzbNX/0FsgMxTOByAECBJY4MHJMxbNQ8Kr3/OCy fR17nt8rQEANLAk5jSpQERViCBBTEEPIwe8/7A+PlM/B3w4gQEVBIISef+wlAieJPkgSfAV/9ZOA QyQXLFBPEslY4oID5CnwYWZdS/38oL0CIwcIaK7jsFZ46QACVMRrCAc2eA0hwQavISTY/Lo/PMZr CBFCAYzmE15D50TQL6HgNXRBD7yGLsysK6mFnkv0ERA5QCCQ4Lo31jAkvXQAASqGNcFzZYeA19AD RbSA00AOYg09kEDzGkq8gQcM3Ouopq65bAkz88IQLczsl/3bb73g4FrPMO2/690hcEPZBzc0X4HE HPhAwbmWav0Dgkt8sEMLLgkhaG98oOBcSy3NbVg0fnAOjw/1Y3EFclvJBxLOtZQ3nosozkmgHSnL msE5PD7UlxBzJen1cx8oONcycgfhxjk8PtSX3IXKTEDSCg80kDOC/uCS5qMHDNzrGEtaQeZzJxTR 8hWc7ZvvP4dBLq7IJ0Rczk7g8aGmuIiVULObYzxic/j8roKcQPpAx4mWWtApwagVkqC7hxiykch0 3s0AoQCWdiWt7zcJT6sQnrpV6nYB2tWzEFKWSgaJSKobrYq1GzPtP0QMSZdfMUx1q9ZtB0PW0tQ3 vrcdN5RsE6Xb4ml5DBM+C3IEbRsFpN+oruIYCch/XA+DtAxm2ucCJ1E9HOg0Ua+n98wIpx7EyiDx p46cC6iRRSdEIO6wUo6omcxOScDWsFIWBLUi9w/+cyIRblYvB5LXB2wNaydBdH3QHCqHAPUEgUjO gitQcoJA7/qAiupOGHCv5qn/gK2hL/sfF4kn6wNODR2SQFQWz+C/8Qdy1uAUBtTuLqaEQBS2hs65 QMYS5wRAfRAAgYoQ+Ac2iINS38UYLwAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image021.png" Content-Description: image021.png Content-Disposition: inline; filename="image021.png"; size=12962; creation-date="Wed, 10 Oct 2012 09:43:19 GMT"; modification-date="Wed, 10 Oct 2012 09:43:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAaUAAAE9CAYAAACr532AAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAADIiSURBVHhe 7Z0LlFzFeee/qnu7p3tGg9QaCcxgMBI2eEBe2WaBaBzZAWsJNl7Hxz5SfNZJHBOfk8Trxz6cOFl7 NczEsePsOhuzj5PH2t71Y08iZXcxa2GtgdhYILEifmALhigggUASQkgNDDPd031v1X51ezTq50zP TPd9dP3vsQwa3Vv1fb+vjv5U1VdfifHxccIDAiDQmsCBNdenvYKbzhRplafl1dJTF5Ggq0jqNH91 udZqrSChz7WghRBa08sknUfI854iN33UE97jVMiV3eHTs1tePFgCbxAAgeYEBEQJQwMEGgns6xvN ZArFQeWsulaXy1uI9BYWnjcKIbNaa4e/cFmYBGlygn/WPOa3LEtEZf5zX0jhK6VnieTjLGT3CyW+ VxpQD/Ofz26d3V8EfxAAgfMEIEoYDSAwR4BnRO7gifUDU5n8ZtL+DqnlO0nKC0nxjEiIlHScitSw 0lR+Vf6hz/17FclApYT5f1asuX9q5ZvvWahUSQt9nL+8nxVrjyrS93JH8tObNk36CAYI2E4AomT7 CID/9M0z709dmTs8rCj9XtJyB4vIJq0oKxzJMyIjLIrFxKjP/Ard8qixOFUESgZqprWvSIkCr/z9 jPv9unTUnd5Z78yWoYM8q8IDAnYSgCjZGXd4zQTMzMjNu+s8Tb/Bm0AfFlJeLLTo43/yZMYIkeoq J14KrMymKoI3q0md4pnZX0mt/6u31jvKe09eVw1A4yAQQwLOjTfeGEOzYBIIdI/A2NhOsf4X3Au9 afWbrAf/kWcvvySlM8TzGNcsxRlBml+ea2KGme0Y4TKiUvnF20rz/37uZ+dmRQv5MTf7Yl3i9lxu YzV/dQMp9W5RdJyj+tInXyOeme4eCbQMAvEjgJlS/GICi7pI4K6+0f71RXkrZ9DtZC25koRjMuhY iBbYzgmW3YzYVPIZlB9MYMpzyuXxT+umVCb/wSRDCJMMkRK8ClhJfTBLdvzqAsuARuxYoUwnJd/3 f6Ic+TmVpXs4IWLGdGpmd5wJaJIwVivRP8KG9yly8ya7L5eh0u6N+ZnxycnuTvG6GB80DQIQJYwB KwiY2dG227+/IaVLnxTkfJBFpn9BMaoSIuWzYPHyGn9T4iW2V1hyHmKVmfSVMy2lOsrac5ZVZC4D TxnZccinC1larmIZup5/XSmFvIAbybDgpHlSFIhT6xlZZSYWCKBSr/DLd2nH/bcupTzPn34v/+k/ lVK+mZtImUx0k4GutC6x1j3CP/9qidR37x3f9vz4+MQKN8GsGBpwMmYEIEoxCwjM6TyBu/pGsuuL Q+8Snh7jScvr+W98p+WMZU6MgtmMoFkWjmmtxQ+11N9h8TkwSN7jeZ6RuFnPO/LkYX34Sx/3xica //IfGxmRt5wc5FnNVLpQyKYGadVrJaltSnk38VLhP+apVJaFpy8Qxlazp8AWzvhTZU7bo2OcIFFm EXoN/7CvImwVzalM4AQLGIun0AX+F06cEF944qXL/s8Hhv7KzOjwgEBiCECUEhMqGLocAg/rN79K 6ezv87cfDmZH55bQ6hs7J0Zm4c1XZh/nkJLyb0iovV6BjrrDnjn0uqLEg7mlt75MMTWs/PIvsYB8 kIXmCtaTrFkebCVOwbKhWdKbexYTVDPLUp73vBL6j2+7Ztt/mJycwHLecgYPvomEAEQpEuzoNAwC B/ToG8lX/84R8kaSLs+OgmW4uq7PL5XxvtIMa9KPedHsjlJJfoeFqLBSIWrlZ5D5d8JbU3Iz72AN +TVH0iiv+vWbzacF97faAGdETLppLiYxe0J46l/ekH5oVxuf4RUQiAWB8//5FQtzYAQIrJyA+Qv/ gP6590ifdjnS3RYs1yme5NQJUpC8YA7EKj6+6usHpa9uGxigW+7+g5t3b+3fP9UtQTIemrav6//R C9/97LZveKfofVrQh3j57ce8OVQ2iRFza3LLgmGW9XyvRI5MDXM1iZ0szjcsqyF8BAIREEBKeATQ 0WX3COzru7Xffan4Ed5T+VPHSQ3PH3yt6dLMjkylIM4SUP5Rnh2NDQzo371z7J/85Je3fqN04433 d8/AupZvvP9+es0Fz8z+5e0feuz1Nx35FicslHlP6Cq2Lcuvrug/Gs2cUDqpC7XvX/rM2uFdlxaP o2JEaJFFR8slgOW75ZLDd7EjwPXqBjPT8qNKKE5oSPVVUrdrl+uCM0acPMAJBzOcRbeHZxLj2Ufz j8elxI8p/kpnXU6EMMuO7mglmWH5SXTS7eNZU/F54evbeBlvT+yCBoNAoI7Aiv5LDDRBIC4E9unR tX3TtJM392+XjsuCdO4Y0XkLKxUUOAnA955UQn58tl/8+nVi/6NxEaS5Zb2Sl6VHeWvpHwLL60q9 LpW3WbZkGV6jpdy21G/xPghEQQCiFAV19NlRAof06FBaizEtxb/goqnpucOtNX2YvSOTQqB9/bdS 0Y7brrnpq+cOpHbUmA40likWV/Hk6LVBU8ufJFU+5+oUnPSQ5mau7YBpaAIEuk4AotR1xOigmwSM IE1rsZP7+AgfUHUbBYkz0fhMDx+ALfJf0F/jw67/7Lr0/h/FOk1aZ/p5drOxwm2FqsTf87kokkLw 4V08IBB/AhCl+McIFrYg8LB+e45Ptp4XpPpSQSY12mFBUl6el+4mSgPit6+T+08lBKiZ2nXs4ey+ FS4EdswUNAQCCxKAKGGAJJLAob7RVUoVPsFZdjxDctygmkH1c06Q/PLzSsvbn8gf+vdJuVDPI5cP u4qOFmI1eYaJDDSMto4ARMm6kCff4eN8K+zUNP0me/L7vDTHglRXaIEFidPBuapB+TivXn2M1pX+ yweGXkxMuR2XvFc4GfzRIFJzRWCXGzWTbeiXZ3lviZ5abhv4DgTCJABRCpM2+loxAXMw9tg0/SoP 3DEWpHQzQeJ0cP6LOBCkf3X3xLbd3TwEu2KHmjRQLBIXYaUfnqtKvpI+zHksLhH7inD0D1bSDr4F gbAIQJTCIo1+OkLAzaffxZsjn+O9osEGQeJtEyNInA7+rFLljxlBalYstSOGdLERriYxrSTt5fp1 pjL5inqqXJshTpQEfXtFDeFjEAiJwMpGfEhGohsQMAT2ld76ZuXrLzqOu66pILnBkt1zXKjhX+/9 w1vuTKIgnYv0YCY3yYL05aAU+DKFKUjyKM/ydRt691axv3LuCQ8IxJwARCnmAYJ5FQIPz4y+Ki3L n5WO3MiHjRqw8NYSC1Ipz4kPn7/76vzfJP0uoU2ze17iJbcvcHHWe+urhLczJkzVisp1FuohLvb6 p+18g3dAIA4EIEpxiAJsWJAAlw8a0Gn9Md70vyUou1NfWNWcQ/LK0/x38JcUJzX0ys2rXG3imJKp T3Jm4SE+ZzR/8d/Cw4XfM0Vm+eFrmL7rOPIj3M4LGGIgkBQCEKWkRMpSO8d27hSZIr2PBeeTvD8i gruEqh6zZ8KldMyV5F9Ra73PJy2pYbGwbpE/+KmW9DE++HuQlcYL9oiCX6ZkkrlnydTym7uuncXZ LNlxAVa+hVb/dclRv87nsipZfHhAICEEUCU8IYGy1czM9wpb+KbxP5NuKtdwz5C5eoLB8F/Ad5cG Nv7zt0x/p9CLnC4Vzzx1Qlx5tykgzuL0avaxj502rhtlMgTMLxZmzVdweM/yz75UHqBPb1X7+Zp2 PCCQLAKoEp6seFll7T41enFK6a9zYsPbOa25dtmOBcmUz/H92R9poXZskQef7HU4poK4e9ZdzyRu ZnG6mqVoUzBPElRiIXqCFevggDP0/UfOPngmSeeyej1u8G9pBCBKS+OFt0MicNfMSPai9NDvcCbd 7eav3fplO545sSB5J4Twf+MG8dDekMyKRTcjIyPyKyc3u96JY6nAoFxOuydO+3vvuKWU9ASPWACG EZESgChFih+dtyJwQP3cOxwl/5pLMwzWL9tx3VW+u8+f8oU/vnf85j/BX8QYRyDQOwSQ6NA7sewZ Tw6ot17haOd2LmnHglSX2MDLdtr3TG7Z/zySf/wOCFLPhB2OgEBAAKKEgRArAvuOj14gtPcJ3i+5 XgfnkaqubgiyzViUSD3EiXifwb5JrEIHY0CgIwQgSh3BiEY6RcAdlu9g6fktU16nchX4+SdId1b+ c/znE3z25nin+kQ7IAAC8SEAUYpPLKy3hLPtXit9bSp/p5qdR1Jlb5YTob9y98TN/9d6WAAAAj1K AKLUo4FNmluH+kayfUp8iI/dbK4IUvWynRmmPD/Set+q4Q2fT3JNu6TFBfaCQNgEIEphE0d/TQlM TQ1ey6rzMVOpoCH925TNUd4zJZc+vem5b7wChCAAAr1LAKLUu7FNjGf79NsvlFJ+mmu2DTYu2wWF VmdIqDu40vXBxDgFQ0EABJZFAKK0LGz4qFMEzKV9aT27nRNBf7Gh2GqQbRcs5P3oVFH+eaf6RDsg AALxJQBRim9s7LAsn7mCDx79Hs+SGqs2BMVFy88L7fzhu/v3T9kBBF6CgN0EIEp2xz9S7/lKin7p lT/I6d+vbryOgveWvDIfVJK77564Cdl2kUYKnYNAeAQgSuGxRk91BDIFdzOXtfuouX6hWQo4//Af SlJ/Edl2GDogYA8BiJI9sY6Vp/tmRi/wyftwUNuuySFZviJpSpPzJU5uOBorw2EMCIBAVwlAlLqK F423IuBm6c1S6x1BGkO1KJlZE3/ENe8eKZ068w0QBAEQsIsARMmueMfC24f16Drh69/la1JXNS0l 5Hsv8M8/t/WSSZxJikXEYAQIhEcAohQea/Q0R0D5NMqX090c/LZqlmTq3SnfN5eq7tu7GaWEMGBA wEYCECUbox6hz2aWxJch/bZwpFM/S+KrKsw9SSf5j744PjlRe2dFhDajaxAAgfAIQJTCY42emICZ JZFwtjXMkkx5oUoK+P/+9viN+wELBEDATgIQJTvjHonX87MkKdyGWZLk+nakj/P86c/Gx8dr76yI xFp0CgIgEAUBiFIU1C3ts/UsiQXJ8wp85eRf8j1JP7MUD9wGARBgAhAlDINQCCw6S9L+0wM6++VQ jEEnIAACsSUAUYptaHrLsIVnSWWeJclvbJL3newtr+ENCIDAUglAlJZKDO8vmcAhPToUZNy12kvi WZIs0leX3DA+AAEQ6DkCEKWeC2n8HCoQvYGEbJJx5/BdSZVZ0nX9+0/Ez3JYBAIgEDYBiFLYxC3r 766ZWweVEr/CB2P5HorapLrgllnlH8MsybJBAXdBYAECECUMj64SyLn5S7T2bzWdVKeBC04BV365 xFXCv4VZUldDgMZBIFEEIEqJCleyjOVbZfvSkt7Hs6RX1VtuRIkPJp1Wjvh6sryCtSAAAt0kAFHq Jl3L2/bOuut4we6XTU27mlmSqXHnlU158P17b9/2qOWY4D4IgEAVAYgShkNXCIzt3CnSRG+Tgq6p dHB+P8nMkjSpvCedr4yPT6B6Q1cigEZBIJkEIErJjFvsrd5++71rtdK/pqWUXD7ovL3BfUnB7w+f yaz+QewdgYEgAAKhEoAohYrbns4Kgl7Hi3ZbRTBJOi9K0uwl+d4rQuuvv3t2z4w9ROApCIBAOwQg Su1QwjtLInCob3SV0vSrWjj99WngZGZKmo7LgaH/taRG8TIIgIAVBCBKVoQ5XCdPF9xhvs78vZzu 3TQNnATddd3snufCtQq9gQAIJIEARCkJUUqQjd9c8/5Umrx3tEoD51nSC0oS0sATFFOYCgJhEoAo hUnbgr4uy59e5/jitpZp4JrTwK/OIw3cgrEAF0FgOQQgSsuhhm+aEhgbGxNpv3CdkHoTL9Hx05gG Lhzny+OTk7jqHGMIBECgKQGIEgZGxwhs+9Q9ORLqNi6wKmtulq1KAz+FNPCO8UZDINCLBCBKvRjV iHxys3QZabENaeARBQDdgkAPEIAo9UAQ4+AC17lLS5+28RUVA9VnZQPbgiw8hTTwOAQKNoBAzAlA lGIeoKSY5+a91ST0e5qmgXveLJ9Z+jbSwJMSTdgJAtERgChFx76nevZ0ZiMv3V1vZkW1CQ5miOmX HK2/3VMOwxkQAIGuEIAodQWrXY0e7/uVjFD6nSRFqqaCw/zhWfXUyYHcQbuowFsQAIHlEIAoLYca vqkhcKJ4ZDUv271TcB54/RUV2veLXJT1HtS5w6ABARBohwBEqR1KeGdBAp6mqzi54Y0tl+7I3QOE IAACINAOAYhSO5TwTksC+2ZGB/huivfw0p1LuupMrFm6U8HvH/dyxYeBEARAAATaIQBRaocS3mlJ IJOlNTxLurXp0p3yZ0iqPVtePOgBIQiAAAi0QwCi1A4lvNOSgEfqOk4Ff22lrND5x9wuy09e6fS3 gA8EQAAE2iUAUWqXFN5rIHDo+MgqR8mb+cAs3+dXd7us72vy9WO3XfMLTwAdCIAACLRLAKLULim8 10CgMJxbq7R+d/2BWXO7rNL+NEl95+TkBIqvYuyAAAi0TQCi1DYqvFhNYGznTj6apEa5htBwfVkh c20F7zGdUUrdDWogAAIgsBQCEKWl0MK78wS2/8W9g1rLd/EsSejqKypYkPxyidfy1P69n73laSAD ARAAgaUQgCgthRbenSdw+pj7KtaiXxSSMxyq9pOC7SWil6XQe8YnJqo2mgAPBEAABBYnAFFanBHe qCNw6NCIk6HSFl66G2pWEZznTqf4j+4DOBAAARBYKgGI0lKJ4X2ijTQoXflOPh/bsHSnfI8LPNCD 3x679hRQgQAIgMBSCUCUlkoM71Mhm1tFSlxvsu5ql+4cc2/SlNbiTizdYaCAAAgshwBEaTnULP+G yzP8I54jXdp4YDbIust7pewDliOC+yAAAsskAFFaJjhbP9vXd2s/17rbyv7ztOg8BZMG7pdmeZKk D27tv++srXzgNwiAwMoIQJRWxs+6rzPFIl93rt8aHJitUSXOuhM0LVTqgHVQ4DAIgEDHCECUOobS joaKujDMO0m8fMdDpy4VnAm8rBzvb+0gAS9BAAS6QQCi1A2qPdrmN8+8P5Um+nnWolU1te7M5lJw bYU+Rg95j/eo+3ALBEAgBAIQpRAg90oXm7OP8NKdeJuZJdVUceADs5wKXmI/H9yyBddU9Eq84QcI REEAohQF9YT2mafcBZrUWxqqOJilPKJpTnK4P6GuwWwQAIGYEIAoxSQQcTdjbGxMyAy9gVO+L6q3 tVJaSL/kCbk/7n7APhAAgXgTgCjFOz6xsW7bH93Tz/ed38QGmROy83bNp4JrOnjP2DakgscmYjAE BJJJAKKUzLiFb3WRBoQWWyqp4FVPZeluhuvgHZhAAdbw44IeQaDHCECUeiyg3XLHJRrmJbprm6aC C3qZ508owNot+GgXBCwiAFGyKNjLddWkgkst38KzoXR9KjjXuuNm1TOU8yaX2z6+AwEQAIFzBCBK GAuLEqikguu3sSg1pIJrvtGPhHhgy4tIBV8UJF4AARBYlABEaVFEeCGfXSgVXExzxXCkgmOYgAAI dIQARKkjGHu7Ed5P2rRQKviAQw/2NgF4BwIgEBYBiFJYpBPaz6GZW7PC1zfw0l1wz/m551wqOP/8 /+1CKnhCowuzQSB+BCBK8YtJvCzKFbO8k3S9uSipvio4GzrDPzyIVPB4hQzWgECSCUCUkhy9EGzP FwoDmsTmhltmza2zQhRIqR+HYAa6AAEQsIQARMmSQK/Azct5knShybyrfkxpIc7Imx5w5U9X0DY+ BQEQAIEaAhAlDIiWBA6seX/aVXQ9v8D7SdWlhQSZouBa6cfosfyLQAgCIAACnSIAUeoUyR5sZzB/ rJ8nRLyfJBr3k7QuSlf+ePfu7eb0LB4QAAEQ6AgBiFJHMPZmI3lNWZ4NXVPZTzrvY/B7ogInPvxk fHyiphReb5KAVyAAAmERgCiFRTqB/biCLmIBeh3PlNj6alUy+0k0o4T3cALdgskgAAIxJgBRinFw ojTtwJrr+aYKuo4THFJN690JfXzw6qlnorQRfYMACPQeAYhS78W0Ix55J9x+hySLkq5ZuzO3zmrf 8/j/H9m9fQf2kzpCG42AAAicIwBRwlhoTiBLGdLepvr7k0wlB35mtJYHxyfGsZ+E8QMCINBRAhCl juLsncZccnOk5ab6+5OCakOceack4dBs74QbnoBAbAhAlGITivgYMjY2JrgI62Zem1tVu59UsZHX 8856Wfr7+FgMS0AABHqFAESpVyLZQT+2/dE9WeV7b+Kku5oyDmbpTpVLPFHSj9zzqW3THewSTYEA CIBAQACihIHQQCBTzPbxGaQ3mVTw2iKspt6dLvCPf4IirBg4IAAC3SAAUeoG1YS3WaTCILtwbZDU UFNeKKg2VCQlsZ+U8BjDfBCIKwGIUlwjE6FdaZJX85woV29CUIRVyJcHUvR3EZqHrkEABHqYAESp h4O7HNf40Gwfr9ltrlzq11iElf9scvvV2/LLaRvfgAAIgMBiBCBKixGy7M+9wvq01uoKc6lfY2kh VeLJ0mM7tlfXHLIMENwFARDoKgGIUlfxJq/xTPEkJzmo11aSHM4/lSKsosgFWh8fn0AR1uRFFhaD QDIIQJSSEafQrCzqTFZo8Yb6JIegKKvWs3xo9rHQjEFHIAAC1hGAKFkX8oUddsl7Fc+K1tS/FYiU kDODlMehWYwZEACBrhGAKHUNbfIaHhnZKaXnvt6s09VdoER8mJaE0s/QNfRi8jyDxSAAAkkhAFFK SqRCsPMvjtybIUePcFeceXe+w6Aoq1ElqSZ316hVCEahCxAAAasIQJSsCvfCzgaVHATxTKnu+nNT +EPTLFcGf3x8chLXVWDMgAAIdI0ARKlraJPYcL5P+PS6Ztef88SpqJSaTKJXsBkEQCA5BCBKyYlV 1y31tLuaZLPrz03NO5p1XflE141AByAAAlYTgChZHf5a56VIb+B1ulQDEq7swJXBTx9ee9lTwAUC IAAC3SQAUeom3QS1zeWF0uQrrnkXnEeatzy4rsIvkyPFk3//8Su9BLkEU0EABBJIAKKUwKB1w2Qu LxQkObAcBVkNVapk/rWghfxppaoDHhAAARDoHgGIUvfYJqrlhcoL8cSppDQ9MT4+Xl15KFH+wVgQ AIFkEIAoJSNOXbeydXkhyQniosAnZ3/adSPQAQiAgPUEIErWD4EKgNblhXiXSeuCl6EjQAUCIAAC 3SYAUeo24QS0v2B5Ia9MfFr2SO6H+WICXIGJIAACCScAUUp4ADth/kLlhZRWZZJ6cveu7ajk0AnY aAMEQGBBAhAlDBAy5YX40OxVDeWFOB2cF++KgpxJ3KGEgQICIBAGAYhSGJRj3keWCileo7usobyQ ObNEuqi8Eq6riHkMYR4I9AoBiFKvRHIFfuQ18W2zdHlwkV/dGSWu5OC5bubpFTSPT0EABECgbQIQ pbZR9e6LrufmeJludb2HZuZk0sEPrx2GKPVu+OEZCMSKAEQpVuGIxhjpepdzaaGGSg6KM++0Fk99 9uJH/GgsQ68gAAK2EYAo2RbxOn+/eWZNSnl0mcloqFm5M7/VvuJDs89YjgjugwAIhEgAohQi7Dh2 dVn26rTjiMvZttqxEOwviVktxNEdO3agvFAcgwebQKAHCUCUejCoS3Epl6WUr/Wl5sIkvqBi/tO5 4qtlrhH+LGreLYUo3gUBEFgJAYjSSuj1xrdpHgQb6tPBjUjxM6sUHe0NN+EFCIBAEghAlJIQpS7a WCgU05z2/eqKBtVeWRGkg0uJPaUu8kfTIAACtQQgSpaPCC+TyUlHDM3NjGqW7yrp4Lht1vIhAvdB IFQCEKVQccevMynkJVppp8YyTnJAOnj8YgWLQMAGAhAlG6LcwsdDIyOO8r1LK+ngVUkOSAe3eFTA dRCIlgBEKVr+kfaeP5Lrc6RzuSnEWj9TqqSDO0eQDh5piNA5CFhHAKJkXcirHM5TSmvF6eAmzaFJ OrhSJ5AObvMAge8gED4BiFL4zGPTYybDmXdz6eC1p2OD1bwyn6d9NjbGwhAQAAErCECUrAhzCyeL 1McTpI3B6l3VntJctfCSkhJXoNs8PuA7CERAAKIUAfS4dOll3AFO+17fLB2cr/crelnveFxshR0g AAJ2EIAo2RHnFl7KSyrVwasekw7ue2aL6XhuY75oNR44DwIgEDoBiFLoyOPRoUkHl+RuaJoOrjyl hDqyu6bEQzzshhUgAAK9TQCi1Nvxbend1MlBl5RaT1wGvH6mxMt5ZV7WO047tqM6uKXjA26DQFQE IEpRkY+4X++E67L4rA9mSo2Px8kOp8fHJyBKEccJ3YOAbQQgSrZFfM5fc2WFFvqSVldWKFInLEUD t0EABCIkAFGKEH6UXReoyDMlva5xnhRc7ueRJ1+I0j70DQIgYCcBiJKdcTde856SWB+s3lUv0lW2 mDxy3dP2ooHnIAACURGAKEVFPup+dYYrg2uzp8RP3daR1r4nUhClqGOE/kHAQgIQJQuDHkyFhJsS kpreo8QiVXZz689YigZugwAIREgAohQh/Ei71t4wT5Aa71EyB2eFPDF48ZV+pPahcxAAASsJQJSs DDuXWiWaKy9Ud4+SMlqkeemOj87iAQEQAIGQCUCUQgYeh+5MNQdSLEpCcznwOot4P4lLD53eTjg4 G4dYwQYQsI0ARMm2iLO/QTUHonUtqjl4JMULO7Y3yJWFpOAyCIBA2AQgSmETj0F/QTUHTRc2reYg OB1cyNP1l9HGwGyYAAIgYAEBiJIFQa53ca6aw8WtqjlIrhCOG2ctHBhwGQRiQACiFIMghG1CnrPu +HjS6ubVHHimRArVHMIOCvoDARAICECULBwIOWFSwcW65tUcuMQQoZqDhcMCLoNALAhAlGIRhnCN KJgSQ8GNs+ZprOaQRTWHcAOC3kAABOYJQJQsHAxcbTVNWg3XJzPwHUpGpMpTqOZg4aiAyyAQDwIQ pXjEIVwrtLuOO0Q1h3CpozcQAIE2CECU2oDUa69IIY0o1Txmf0mbag6Cnkc1h16LOPwBgeQQgCgl J1YdsXRkZKekMl+DXlmqq23TVHNQ6gVUc+gIajQCAiCwDAIQpWVAS/InXzm51yWpOPPOTI2qPDEi JYQvhHxpB+reJTnEsB0EEk0AopTo8C3D+CdJKJJZrRtPKXFrnq/1WdqBunfLIItPQAAEOkAAotQB iElqwsu6riCZa1piiNfzpENFM4nCAwIgAAJREIAoRUE94j456KYga80TpINr3lHSNIUSQxEHCN2D gMUEIEqWBd/UvfOFf1F93bsAgyBfKjVlGRK4CwIgECMCEKUYBSMsU4SmVGNfZqaktfLM8h0eEAAB EIiGAEQpGu6R9VrQxRRf7ndhkBHeuIbnUVqejcw4dAwCIGA9AYiShUOA9ahhT6kKAxdkxQMCIAAC 0RCAKEXDPbJei5RxSXH2ncmw47zw+YenTvy7MuvVqciMQ8cgAALWE4AoWTYEMqaekBTZVm5zsVbM lCwbE3AXBOJEAKIUp2iEYkvWEVoPNa0QrsnPF3PYUwolDugEBECgGQGIkmXjwqMpRxFlmrnNC3j+ W4YHkX1n2ZiAuyAQJwIQpThFIwxbtDtYuTep+hF8apYrhBOdOUxH6qq0hmEU+gABEACBCgGIkn0j 4QLOcKhVpaBgOBfDE4IvpcUDAiAAAtERgChFxz6SnvkupUEWoBpRqmiSIl/RK4MX34KZUiSRQacg AAKYKVk2BsbGdhr9GWy8S6lSzUEKLjG0e7dlVOAuCIBAnAhgphSnaHTZll27+NoKX7VIB2dVIsLy XZdjgOZBAAQWJgBRsmiEmAv+JKmhphf8kfBIyrO7t9dfR2sRILgKAiAQOQGIUuQhCNGAhS/4M4bg 4GyI4UBXIAACjQQgShaNCnPBn6P12hYX/JU5Mfx52rEDiQ4WjQm4CgJxIwBRiltEumwP5921vlZW yOCwEh4QAAEQiIoARCkq8jHsl8/PYjzEMC4wCQRsIoC/hCyKdi7H2XeC+iouN67SSUmYKVk0HuAq CMSRAEQpjlHplk1FcvnW2aHKVejnn7myQ3xtBT03Pj6OPaVu8Ue7IAACixKAKC2KqLdeYMVpGXMp MFPqrWjDGxBIHgGIUvJitiKLeVbUeibENR1W1Dg+BgEQAIEVEoAorRAgPgcBEAABEOgcAYhS51ii JRAAARAAgRUSgCitEGCSPi9Q1pxSmsu+q7a8UpDVU95skvyBrSAAAr1HAKLUezFt7ZHOc/Yd175r tnMkTO279BmbcMBXEACB+BGAKMUvJl21iEuBt4y5y3WGuto5GgcBEACBRQhAlGwbIgtl35GH7Dvb xgP8BYGYEYAoxSwgMAcEQAAEbCYAUbIt+nVXode676Kag23jAf6CQMwIQJRiFpCumiPIIS0HTZmh ujpD3K3w+WdTXe0fjYMACIAA9pQwBs4TyEgpxarK72snRZq0KpIHUcJwAQEQiJQAZkqR4o+g8wWX 7yKwB12CAAiAQBUBiBKGAwiAAAiAQGwIQJRiEwoYAgIgAAIgAFHCGAABEAABEIgNAYhSbEIBQ0AA BEAABCBKGAMgAAIgAAKxIQBRik0oYAgIgAAIgABECWMABEAABEAgNgQgSrEJRTiG8CFZFF0NBzV6 AQEQWAYBiNIyoCX5E77lr+X1FK7wUPsuycGF7SDQAwQgSj0QxHZdyBJ5fJ/S2cr7TSZMmmvj4QEB EACBCAlAlCKEH3bXBV3UWupiUPeuWpNYqfi3KaLMRWHbhP5AAARAoJoARAnjoZoAZkoYDyAAApES gChFij9enWNPKV7xgDUgYCMBiJJtUUeVcNsiDn9BIFEEIEqJCtfKjeW9o5bZdytvHS2AAAiAwMoI QJRWxi9ZX4ucp6U8w3kNeEAABEAglgQgSrEMS3eMylKBz87SbIvW+QCTzHSnZ7QKAiAAAu0RgCi1 x6nH3wqmTq701doedxTugQAIxJwARCnmAQrTPEUK4yFM4OgLBECggQD+ErJsUFTOyTZ/pHSx22TZ eIC7IBA3AhCluEWky/ZIQX6Xu0DzIAACILBsAhClZaNL3of5ApW1VqdMmSEuzJo8B2AxCIBAzxOA KPV8iGsdlEJgpmRZzOEuCCSJAEQpSdHqgK1a6VYxF55HSAnvAGM0AQIgsHwCEKXls0vkl83uU9KV 07SulGpobGwM63qJjCyMBoHeIABR6o04tuWFW/A87ThneEupWZadUFLxlUtIwGsLJl4CARDoCgGI UlewxrTRK1hxlFcUoqnyuILcNbRrN2ZKMQ0fzAIBGwhAlGyI8pyPt118i8elhM7wXKjpaSUeDK5F OOAqCIBADAlAlGIYlG6ZtGMHaenIQkP7lT2llNb+Rdt3I1e8W/zRLgiAwOIEIEqLM+qZN8bHJ4z6 TFEgQk1W6bRO94yzcAQEQCCRBCBKiQzb8o1W5dIrJERNNoPJexDSYZWSF079/CD2lJaPF1+CAAis kABEaYUAE/e56zYu3805wWqEPaXEBRQGg0BvEYAo9VY8F/cm5ZpL/mrzvk2VVumY1Dy+uuKWxdvA GyAAAiDQJQIQpS6BjWuzruf5klSx3j7BeeK8fJehKw9jTMQ1eLALBCwggL+ALAhynYtc+06erSQ7 nH+Cqg5COIMPHRuyDwk8BgEQiAsBiFJcIhGiHSw/XrPueFVP5j2PqzrgAQEQAIFoCECUouEeXa+6 WCahg+sreGZUYwfXxZMZN7MqOuPQMwiAgO0EIEoWjoCmM6VgOU87JLwLLEQCl0EABGJCAKIUk0CE ZobIeSTF2botpaB7c1DJ8wmiFFow0BEIgEA9AYiSZWMiSwVNvm7IvjPLeTxXclzHxfKdZWMC7oJA nAhAlOIUjTBsyZDHW0lnWtRkFZ4211fgAQEQAIFoCECUouEeWa/5PGlBcm6mdD7RYf6iP4WL/iIL DjoGARAgiJJtgyDHi3dCc1HWFhf9OeZKdFz0Z9uwgL8gEBcCEKW4RCIkO9ysp/h5pdVFf44Wa3HR X0jBQDcgAAINBCBKlg2KI08e1pJcznaoe0w6ntaO9tWaXbTdMipwFwRAIC4EIEpxiURIdhy+4+Me OeoF7q7x9lkuM8Tp4ut2E65EDykc6AYEQKCOAETJsiFhLvpTmo4HolR10d/cnUr8Y7GeMFOybFTA XRCIDwGIUnxiEaIl7umKKFU9vHwnHb5OSavhqZOHnRCNQVcgAAIgME8AomThYPDIKyitX653vZIW LlKD+dOoFG7huIDLIBAHAhClOEQhfBs8SeJ0/fUVgRm8r1TQZV7CwwMCIAAC4ROAKIXPPPIeM1T0 eDuJl/DqKoVXirLyGp4HUYo8SjAABOwkAFGyMO5ZkSmz/JxoLMoabDO5fI4JomThuIDLIBAHAhCl OEQhbBu4/p0UOpgpVd+oNFdqKKWkvGRsbKz2sqWwbUR/IAACVhKAKFkY9jyvz7EcvVApNVSnPZpc HhTrmu43WcgKLoMACIRLAKIULu9Y9HbsxGM+KXqB9aghLTzYU1J63a7d9WoVC9NhBAiAQI8TgCj1 eICbuVep6kDP8581r+ogxHpUdbBwYMBlEIgBAYhSDIIQtglBVYcynQxECVUdwsaP/kAABBYgAFGy dXik6EUWJFR1sDX+8BsEYkoAohTTwHTbLD6M9LLQara+n3NVHTxUdeh2CNA+CIBAEwIQJXuHhccz pZZVHVxUdbB3ZMBzEIiQAEQpQviRdq2LZSU0VwtvVtWBXPJQ1SHS+KBzELCUAETJ0sCTyAWlhppX deC0cImqDrYODfgNAlESgChFST/CvouZjEeaD9C2qOrAt9MOR2geugYBELCUAETJ0sAT5X0+O1u5 gbbxnKxLwl83NrYTpYasHR9wHASiIQBRioZ75L26WS+YKbHqNFZ14FJD/NP1tAvXokceKBgAApYR gChZFvBz7u79xC1lrurwLCtSTVWHyrXo0uH/37DLUjZwGwRAIDoCEKXo2Efac1DVQdORhuU7cy26 m+K7/mjDZ05uxrXokUYJnYOAfQQgSvbFfN5jPqh0iq9Ff6kegTlAy//Lbjx7YoPFeOA6CIBABAQg ShFAj0uXGUElocXxyjUVVTkNlTzxNHmlK+JiK+wAARCwgwBEyY44t/AyWyJHPxmUFqrJs+MdJUEp kvLVVuOB8yAAAqETgCiFjjw+HRYLhZJQ8mgl1+G8Ks3dQJt2HHoN0sLjEy9YAgI2EIAo2RDlFj4e KzxWYkEyyQ6q5pVg+U6nfaUv24W0cItHCFwHgfAJQJTCZx6bHj8w9CKnhcsng2vReb3u3GNmSsJJ SR4cV+1ucrI2Ng7AEBAAgZ4jAFHquZAuzSGl1XFeuaudKbFG8VElbkhemM/nsktrEW+DAAiAwPIJ QJSWz64nvnSLxTzPjE43FnYIlvD63JOEtPCeiDScAIFkEIAoJSNO3bMyQ7M8UzoSpIVXLeFV0sSp T2ra2L3O0TIIgAAI1BKAKFk+IorFTEkIcSTYR6piYbaZWKVSStClliOC+yAAAiESgCiFCDuWXeV4 pkRmplRXLVwr8yM+X6uuHNuJauGxjB2MAoEeJABR6sGgLsWl3MZ8mTPCnyVRd91f5TxtSmjn0l27 G++2WEofeBcEQAAE2iUAUWqXVI++t2ly0ufUOz5AK+rSwhVJJ0VKqQ2feeAOFGbt0fjDLRCIGwGI UtwiEok96We5W67PWvvwXhNJIdZeltu4tv7PRkZG5IE116cjMRedggAI9CwBiFLPhrZ9xzzyprQW T81l3M1/GCSFa+pzRWYDC1Dfob7RVYfU6NABNfqm//az1R+UZzO/dejQCGZR7aPGmyAAAosQgChh iBAVaZqEeqqS61BV2UF5/Fu9Sij6qDyT+sIrM/rOGUWPOlrezyUf/jMp7ybgAwEQAIFOEoAodZJm gtoaGxsTZvltX9/oQCZLF/CO0mkzLapJC1em0IPo5z97P//ZR4WQbxeue5FMpQd5DuXwn+7ftGnS T5DbMBUEQCDmBMT4+HjMTYR5nSJgRGjw7ODqgigPe756nSD/TTw32ixJmHuTNrAi9TXri8Uo+HEw k5q7mVZ55eeVcN+zRf7gQKfsQzsgAAIggJmSRWPAPZu5dkbP/J0m9YAU6r+z2PwOJzLcKhzn9ULK poIUiJE5s8S/5vecKjfTHqe1xR9ahA+uggAIhEAAohQC5Nh0IVKPKxL3sRit4nTvfs6uS5kMO83L dIHotPEILtSq/HJJOPT9LS8e5Ksv8IAACIBA5whAlDrHMvYtXSfuy5dF6g9YVPazErEQmRlPkGPX tu1GxHifaYY/ebDtj/AiCIAACLRJAKLUJqheeW2rvP8oF7v7Pd/3n5N8texSHzNTYkF6aUjQ/Uv9 Fu+DAAiAwGIEIEqLEerBP89dk9/P853bg2W44N6k9h6T8OCXuai4ED/62ti2M+19hbdAAARAoH0C EKX2WfXMm6a0UGkg9z948e7PtfKNyLTnm8nC03qGl/wemJiYaH/Nr73W8RYIgAAIEETJ0kGwdXbP VFnIz3Mx1u8FB2bbECbO0GNaYko5WLqzdNjAbRDoOgGIUtcRx7eDrXL/SSXUp5TvPy05nW7hh7P0 TIaeUE/TDd4j8fUKloEACCSZAEQpydHrgO1b5MGHhRT/Rilvls8rtWzRzJI070HxjOqBLQcPNhRv 7YApaAIEQAAEsHyHMUBUKtK3BIn/pH2zv9T8v1MqPxfTpASy7jBoQAAEukYAM6WuoU1Ow1v790/P Cv1FPrvE+0tGexoTH4KZEumXBhycT0pOZGEpCCSPAEQpeTHrisXB/pJsvr8UpIKXZs0524O7xrad 7YoBaBQEQAAEmABECcNgnkDL/aXKkt4MT6EOIBUcAwYEQKCbBCBK3aSbwLab7S8FqeCCXiaH7kug SzAZBEAgQQQgSgkKVhimVu8vmUO1QcHWoFireoZy3mQYNqAPEAABewlAlOyNfUvPzf5SSUmuj+c9 zdXEORXc43J5zj6uCo5UcIwXEACBrhKAKHUVb3Ib35ref5Cz7T6pPF7QIypoIe5NrjewHARAICkE IEpJiVQEdg4ODO3h+5e+xAt4z0o9gwv9IogBugQB2whAlGyL+BL83TS7p1CW+k/KWn8xe827kAq+ BHZ4FQRAYHkEIErL42bNV1vF/udXv+Glr22anPCtcRqOggAIREYAohQZ+uR0bK66SI61sBQEQCDJ BP4/agFhIxMjcdQAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image042.png" Content-Description: image042.png Content-Disposition: inline; filename="image042.png"; size=511; creation-date="Wed, 10 Oct 2012 09:43:19 GMT"; modification-date="Wed, 10 Oct 2012 09:43:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAADcAAAA1CAYAAADlE3NNAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAGUSURBVGhD7ZqtU8NAEMUjkUgkEonEgSMJzIBE IpFIZkhyOCSyshKJbHMnTiIrkfwr7NuSGUzx92s6E39v3r2P3WvVDGlZ9/HxPOSDiva7DKvjdkhv bZ++BfIm5EMaxqoN+WgC2fTpBQlSoAROTM4gS77Df5k0Np+QxuMgh/g6GU/JhO08+2Q8psevplvf IkFeh/WJuetHO8TchvEUCfIqpAtjcWNAF2IVCbLp44OuatuN90iAW9NJS33IEiDWxJ6z+JxqJIvS n0XHSlpEZqNYkxblqNhrWod45o5KjQwfrfr0iQ1+ac+DnxoXrkOLihlgyTmCZ9A0+F53413JJO08 +9ZkYlZcIAH+TvsbxQUSoM+HloPYJqPZUFcUyZ5PFLaE0q6GC9BaDLam7YXBaJLAzoI+0VsPJeuP 22Dw+lM1U/5x9YfPP6tn2IKt/smOh/l6FpyM8/UsmLzK1xPmntgttoe7ASyZpH/Pjl4P+lOZP7JA n6z3YDSKWQsmpP7w2ac/4ulDsqfsk7mIRSRA/GIXn31qLj8wLya1M8dd1AAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image043.emz" Content-Description: image043.emz Content-Disposition: attachment; filename="image043.emz"; size=1785; creation-date="Wed, 10 Oct 2012 09:43:20 GMT"; modification-date="Wed, 10 Oct 2012 09:43:20 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1Yb2xTVRQ/fX3d3hiFsuCYMkdbNhmDIJJ9oMmCd93WsWyQbXbJMEQ2MjBbhmyy f4QIAzGKLoHwgZAAERMSVJCI4gcNaskS9cOiEzAhuihGEyUiQkLA6LD+Tl9ve7utTbdZ/MJJfu+e +++8c88957x7n4WI2gFJLjAMSQd1og02ImfFGh+RhTrmE3Wi0yoHhEuRRrQXjcUa0SpLbOfIUYNK rugEAbQUcAIQt8QiLJQL3gFojsB3PK0pDB67HqgFeKxb6DQTPFOeyIjw+ZAh25cLLSQLKoP6n3SJ 9EifLijCZ6OX5+QAMwAHICkDjANwAYuAAoDHzoJAla9HWwcUZp1vBYNBFBE6wI0gvNNdRs2wbytt pOfxvD8k9njoyose6nitLbOr30O3N6TVcd2J1w+hDnWD51H37/ZQxV+z67hN9nPf0rTszI/QHl5G aE947Q3LsDJDm23TNE23anpQox+Dpwm7YdLr4QnqmrmnjDbRc9RF3bDBdmgxivcdKsuoK0IfXvfD SuiR1Z5eV4Oy/+zfdS0oWYdaW3ZmSw8ZLEPanl8Rj89CH+8Vj+G9DfuF5gfPkMQCHYCprt3b0GD3 cp893FaD0vQhbo36Qi14J8DrVeVLfcb6iNpeiDlSN9V3foUB0BUhWDhE/5fvtPR5aHS76TuHe0zf 4boTWt1Enf3jKup9vabvcJvs575U+44T71V9Zz3q7DsdKNl3XkE5Fd+Re6LxOrGO0CaEH8qeZPkR xVvgz9tgkbUoe1HW01a0NcPHU0NyT3KpLXMqe1KSPj6eWdOn8rAyh6alWW26TbPqwSK6WtpHARnP wbAvqmumCdaczJ6wDk2I6bHxzPaWcRKPZzXkmMny8WSq7cnELY9/EMPwl/8g/yfjLw9iODavPohh 8/upxq3KTyWGfYjpIRtRAOAzZpEgykcbf9v5/MgPE1E+T9jkuYIWCGuEn2AupjKF5oa4JSJyJsEZ Ni0y16XIVM+2ychUz7iplq/qs3npyMrQovAI8f2Dg9T/z6CqQ6LxB74dWvXe6I1P4o1X7abyqRvv LCUaLlXlT3+PTJnqHq0QZMmFzRwAkfMC0buA7sWpI6l3G4L0HMzksyTfmVgKrl2OYqH6VvR+pO6B akeTH6+fuv7EcwMpsJcpM769ApO219TsMl6P5O3CO0I02fH5Inq/NYTFNgIZw4C8F4ONIQtq+2rX VtpnPMJXWHvV6vJ6lG4gz0jDsyo4NBeFZVt9pZfOfJl7DRX92dI12LWz+zNHm5HzKKNj9bptuNsO Miyfb32zBY2VVeWl/sbK3y+/YaflM60X2m98c+qi41K/taLg699+rlox7/t9C3caL7fPerXw4mN7 5vhyWm05rS9dNxYOnNMGznl79s7xPb37XpDe//BG48l1h76CSKqqWFt+xtu0h8gQmiFzrFybzkMU mi8sohj1QkALA8WnJgwvxwp8HqRjwTzbHbqvG+A2AvKe5Q7zfC/hXK/DaH+i5Fyv/jeY7F4lP96M L3X8/c4puojmBRfWzjaSJechrlcDAlgOsFs4AZgqBAdKJrYyz2ObMqn1fNQZpHzrTN5cv4aeeqAD Qllu3DsvxKv/Dlox9uSlvrbTwOGDHnqhtKdzwcdHqi+DZ1QHeztPGP6C429p85oeD2RTKJ96yHVq e2fJDH+Br2FH53mM24Lyi4e6Op9Y09zFvqDqOfDTtZ7F71z174KSc7VfsHyGSXbyWY5wdIWpcT/u xYCxSJ9zzH+nW9y6t1P20bDCo1HaCTbTBzBncd+dbrYD0wnUK8urypqeWeg6Dr5k3d3u2zvOZh39 bFMB999E273Gu93sq7KN7XYd7X/M0nsSvXvs/YrnwTChmMhBmRXmuZ3rHCsgTY55GBV1DH73xfwf G1uX81iWPww2GfvHPGABINcNNkL8/hrAEWkJ/Qvi7QnWok2nNg1nusi9j893hahPFNvucDvP9YEv hvBCgOM8mdgrFhE7xPxbLEI7+zWvTfUZkzd9W/1Wqe9KPNf8vqjjp58XTJmqPiuEetaI/XbqIrpm F1ZnALJMfV4wdWW/qAdkXoj73wUuqf6DmOi/S7y8IJZxXuC1Tz8vOKErxzLnhWNw8pbN7V0MmReG F+kfJIpNTJ90XhjZNT4vsG9PkBd6E717qnlBxjTHQCaQBzwKJIppdEeIY5KpFi1OIB3gJMdxPJmY HsKaA0BqY3p8DKkxmjimsSCQOl7l48W3IaxxzvPRu2Wq74SG0OPoED2TTkcHNdeoe6/yPtiuGCgE kr2LuzCW89ZGQH4XasC3AEw6wGMYTFx3A+zDi+ltPCVF7+ixeV72x5Ysg9/Hfs165wIOgPXWRDSv wr9pLsDkAJj/FzZ6lAZwGwAA --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image044.png" Content-Description: image044.png Content-Disposition: inline; filename="image044.png"; size=359; creation-date="Wed, 10 Oct 2012 09:43:20 GMT"; modification-date="Wed, 10 Oct 2012 09:43:20 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACEAAAAnCAYAAACBvSFyAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAADnSURBVFjD 7daxDYMwEAXQvwENpmMBb0CFlzAdLYq8gEvDOgzCBNmACZiAKEBQEpSAMZjmimvxw//0ZVRVhavn cgAhCEEIQpyOMJJLAD14Vl+C0LoIBEMzIMC6VJnEO8KoNGFAF4bh/QmJhCq9IzKOeriBm5QcaMFE U2gdeEMYk8fvB48g9Fwa6Q8xLeQrAtcFdYtiWsb5ZsDb3Jj4dMR3FJ+wfZE4R3FEZ+zshmUvuESy qxvGgvo9tp1hhVAiKv8dMkdi2RmHRLGMxK7G7aNY+cu123JCbP34Viw9aghBCEIQghCEOGIeQHN5 IOvFsRoAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image045.png" Content-Description: image045.png Content-Disposition: attachment; filename="image045.png"; size=837; creation-date="Wed, 10 Oct 2012 09:43:20 GMT"; modification-date="Wed, 10 Oct 2012 09:43:20 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAADoAAAA3CAYAAABdJVn2AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAALaSURBVGhD5ZohUMNAEEWRSCQSiUTiwNEEZkAi kUgkMzQJDomsRCKR0DsRiUQikUgkEvZfciWUJHfphd5t2hmmmaHp5e3u7f7d69raqr+Os3wjTuRl lIrHOJVf+i9K5CtdT0aZ2GVvo9F4ehol4r0KWHcdpfIOBmEHHGf5ZpyK3AQ472F23u0KOQNOxGec TXdYeJb23nUXT85/lu5/CR4UoecC+ZOoxHnQsPSgDz2Bvu9l+XqQsEUZoT1WKSEu14eZ3A8StK+w /UlM8jJMUKqZLh78k5SotgYJGl/J0WqAUv3rFZQkYrD7lOTeR5+wxXeJPDhgaNb+QXUjEBCw0rg9 lph6owUCPErExf95tdLmUfR4FRVYnPrP56XAUsLy2vEAtut+VY34eHq2kIykxt5rzS0b7/ZMjD1N D1oNQ7RqnYEpio6yp21vwEhQVHbOMUrR04binRpzAsT/mx6uK7AqbxQV3mBdFwbw/MypLQdg27iu 6fV+ldEtyxcM4zUru1oK+7CcIM4mio3epX3LcuimjaRKWCpvbUoYjHKQPW65Gtjr/eiYrMapSH5c hm7NmRlZXb6YvKsyMhnGq2dcFy9D2TyvokTmVUm5gur7bfat8iz3MAYwxIkpjEmovLFPUIAtk1Sr 9EQ2bis9SpVx8LxSU4aJB5LYvKj4JTu5yEk1sDMoKSgoRAGEyJ9GggsoANBBWezZ+v6ZE6h1gqo7 YeAGWsAucMrHEbQY3Mk3YxhXPcsJFCVEedOyvftlCA6gGtBUYlo9HDooVI9NV2MM49BBVVmh03fr Br3pTJcDKGDV4XQq742eawDF6KavhmMp36PmxQskIySxpTxgn4uUsyZjg171PktQGK1s0Ce2ocwW VEdINH46sSk77EFVz1oopdbDsEGAzrybipumUB4UKIDx04E6gTE4UF1za35TzK+82Jaq6vnOID1a NYSWj4MH1aE8iGG3bSiv7Oe+AVkgpMuz9Ka+AAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image046.png" Content-Description: image046.png Content-Disposition: inline; filename="image046.png"; size=2681; creation-date="Wed, 10 Oct 2012 09:43:20 GMT"; modification-date="Wed, 10 Oct 2012 09:43:20 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEwAAABiCAYAAAD6MTVtAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAn5SURBVHhe 7Zt9cJRHHcd393nuLndJCIESykuSBgtjeKulJVPygpOaQbFM60urdHBGx1Znqn/UOo5vUNIw4z9t rTijjFOro1Y0tYMv2BYcC1NAk2o6TkUwCBhIAiEDgRxJLy/3PLvrd+8S53IH5PbyJJDL7kwIcL9n b/dzv/fdow0NDcSM9Amw9EWNpCJggGnqgQFmgGkS0BQ3GmaAaRLQFDcapgnMqq2t1XxEX7x5doV9 Vn4gp9+dl9su5wW75IJg2+AaX1dfIS0Onef6M968JyZVw+rLy1lztOIOdsV+yjdwpTHCySlJQqel yDnlC/QeZIW+Z5vdivv3Bh4I3jwEeu88aRp2LFCZV3Iu+CgjdBe12CeJJMuZ7QtRyoKUWSFKyEIq yb2Eso/nOcOLw7T4X0W086re8qdeelI0rFmsX/ZeRO5mlOyitl2O/DhAKSWCO///kSBIKFBavgJs +/H3BGn8m6yum3oEeu/oObAjgcoCJqPPAtCD1LKDUgoiBSdSAlDiwL9jrwEiZAHOvo9w/pMWWVmt t4WplfYUWPPlioA/Qr4Cs9tILQswXAIq4+4oBg4/MNkSl5MdxwYqldbdksNTYKTQXwXLe5Iwn19y zeAnFDRJGKXrIjnkM8fKy61bkZhnwGCKISr4F2BfhXBUGe1VAhplLEcK+eXe48HbMppkkh/yDFjO IJnHJKlFBIyZV2ZDmS9VPq3UT0N3ZzbH5D7lGTCXsPdJxvLG91jjbUgFA+ITXKzZfXmzbzzpqX7d E2AqQWWuuwiLZ+k4+RtuErQolRZjtGQJafNkfV5C9WRBDa2tQjAWSSskprt6Kf3uwg7kt7fW8ARY bEuMdCPKSZWgTmTEElrC1Lru8UfurFPBZCLzef2sZ8DyafAEFnc5jbTrxnuITaCqALKSEPErX4S8 0iKqNwJcrtebz2Q+z4D1dh0fgPP5kxQufnkxLWWoFPLx5yYhxCsA13grgPNiZ7EPqmZR95BD7e8j ve/2BJgqnRR8lWikgLtPaVxOJhoy0Wc8A6YWUrji0glBrJ1CuA5qQ721wfepHC7ZB6rsfxQcs+18 xtgmLtmv/UP0u0dk5e16bzJxaU/bO0U9PfIsLT5lSbkGSyuDZtB00gxk9zFNQsIbhT4xgFP44r4s YaiEWAHFvDmgeDflsrqbLWnvKJzfWTx0PtNsWYuip8DUO5fSzsgZWnLQoqwAJVI5NM2HXca2P2aM apSqDIRwQOsdvL4T0bYPfy8GGD9AXgMcIMbAQdcsu1gI/gAZIOTshZKjpbM6h7V2n4Gw58BGoPWH c9YfHIz2ngO0u7DrEEwLDC0kDKipVeqhoqEkDuFuD555LmoFv0HnDr3lEPa6L0oOSyJy8UwpwPni 4JJHPJoyC81IIWusPHrPBbLgZN3yWd090PQMWKT1yKQAU+9cxI86ff/O+yefH9wnBWuTaHbBG9lE SJScogvAWrDdn0tpf0vOi/6xavgvV5VZlfJOZxHrPHsmmL/Pz4OHYIYj4Bg0bgT0GDuFtlmwfUqW QvE+9O7FQCQ8lN9a5OtBb8n7QafiMoo6BHG77CAJEh9CGxtCgkVyCh07eGl4Xfjv8FvXH0cC5Xn+ wblrkVo8ibprI3pmfphhSlER823UwsfiRNCO/Fl08Mq2mlBr2GtkUwLMi0UfkeWzGS/8IqrxrxLL mq9MOrUrQpWJwgu4Lmxyj0PJUzWs6YIX7z86h6dphZcLS56rhraGz14t+R6U6GEEibfh3ziiJcQS vRuMHV1e+EqbSPqpgCAvtYgPlnm5rknzYV4ucnSu1aFjYhHt7LhAl+3jlFtMiFUIIv54/ZkwVOfW spSNwq/xezvpgn8U0/PdXqxp2mhY4mbX0gNdlwYLtnLOH+fc/Q8MMaUcUwcvakDbqpiwXm6OVq6v r98+sc4A5puWwBSIB0OvD+7/zobfSOZ7REr3cKxTolKWMYqGcwLEF1joSsrETzdtffNjE4U2rUwy 2aRqaw+RYtp+8QwpOQBUixAF3s+YzZKDgTJYy/LPEdKtKru//WgJ7WjL1DynrYYlbhiRsJPR4BOS kh/AFAfjdWyC9cGnob7FMV5gscX5romcfWYFMAVvLTvQ6wyRbZLLbYiUfSq9SIXGYZ6+pYLTnTid Xz2eltVvT/V509okkzdc6ut0DoWr3pkd7D9NhFuBCqBgbACNR1PUoQsJF6vO0CVvldL2cPI8qsvb 5RTfdeehtrlXl+ddVk2FUZms0bDRDW2Z2+jsX3H5VVfKx4TL2+OalhgJEAhwCwb5XLUtnBcTW0Tq 5L5FVKzzD8iXIPIHJkUFeXXs41kHTG1PHcpU2W+/CS/2deG6F2GGY3etDoxRSqE0rbOFfAHQ5gDU ajbb+rGQ9mtI7T6NMux2IlhKUy8rgY3SyV3Vu8cVZCv6mf3JDc2RU3bCJP2EX9DfcWn/GRS3QG6O Sregg1E02FJ6bFkNbGVrK2dF7i8AoB6BIJKSp8WuJtAAAup6NDyKoHNMlVY3OrnPamBK01Q35HRl yQ8B5Tl0PIZUd3eMSxs55hoPVNY6/WulCic/sswRxLcXPq0jHjWTKiSNs8Gs1jDVh2uRaxZ/9JmD 37aEswfVeFnc3DJvyGYlMHW3DNl8Keu1v8l54CCc0tNoBZUhnZjw5ZasBNZ7vLCMC/JLOPGnLTuw FH4roEqjdE6wxsv+sxJYx5ySdqRZz6NMwi0ZZzwGWq9nJbAt4UbnjYa6vWguPoyuz24U5MPoYsRP q9IeuO1GWH5/df6Yh7ISWCzbb9gh17LDp51h8iVkoV/DlfeL6gpDetcY1BGgOlVxZ6kkNpFx1gIb 3WRNqKnPvc39kRD0EcH5X6FxQt3wTkktrqF56vJW8n9nPbCR5NVd5286DE6b4fhflC56ZqMHymmb aFxwRgAbZbKWNp2L5sI8mXgC55e43qjOSfQQ6Elrfhq3onjNcFPk8ys2vOxY9CHc0Thw7eO66698 xgFTKFpbd4ga2vQulGszvPsL+PpORPXN0rluOiOBJZhoTzREtjMqP4soejL2HYGkk6cZ6fRv5Bpg okOvNWz4bZTRhwQRv0fO5sRzttQbWjPO6V8PnMrZYKIncBfjMXyh4hnhRsOQVUfnKRY4o00yGSCg XSFFdzwvqfgcrmW1EHx5ivx3rKYZYEnU1oUbo280fHivkL5H8WWN/W1kyZg29bS57nQzUpTy8u1M RdQZVRpNBHQyLOP0M6BpfJgmNAPMANMkoCluNMwA0ySgKW40zADTJKApbjTMANMkoCluNMwA0ySg KW40zADTJKApbjTMANMkoCluNMwA0ySgKW40zADTJKApbjTMANMkoCluNMwA0ySgKW40zADTJKAp bjTMANMkoCluNMwA0ySgKW40zADTJKApbjTMANMkoCluNEwT2P8Ac/3YeireSjsAAAAASUVORK5C YII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image047.png" Content-Description: image047.png Content-Disposition: attachment; filename="image047.png"; size=1418; creation-date="Wed, 10 Oct 2012 09:43:21 GMT"; modification-date="Wed, 10 Oct 2012 09:43:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAF0AAABRCAYAAACws6q4AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAUfSURBVHhe7VwrkBNBED2JRCKRSCQOHMlCFUgk EomkiiSLQ56MREZG3mVXRJ5EIpHIk8ij32RDvjvf7enZzVB1VVRlpnvmdU//pmevriL8e13ePH1T 1q/2/4py9TwC68tg8bJcPxpPbt8Xs/q6mFXrYlr9pf8/tP2Np9U9xo1n1c14Wn8bTavPb8vbZ5eB VuAuATSA0wHs8hsJ4JcSXD4Rp5JRYE/rny6Auo6l0/CH5szBK1A3+j29KNdPutRsW0FAADBBMGP9 RtBx9XCIjfa12mpbEH3HbcF/V64fOy6/f8OLyeqjL1Ac8+CI4YAHC74P4I29XwCYk79Z/WMT4dS/ QwUySPBHk9UHW2DGBCbGu2of4nnYaxLCnS2v43EwOzB/vbAhAKhtscppqni6Pd5uflsAuC42DJ7N yVpa8D3xLeTkvyfvbAH6dnNbk0Aa9wWC2CQ6+gSHM5wDeDgBrs5bxfqpx/lex5rscVfabTohXuAj IyblMdEW+x2OzvUoQ5twlJXNj6RVfuDXd7GUw0mAjSkJjr1V0kQ22Ym5x2CADy021Xd2ZpMy20iK 4bQdS4epFQzsrxPTwMEokFmbRjI3nP7HayukFV7Rwp5ZWnox7mCS0npzhKUUJrZiaLfnkwD93yg5 VdfYvAOsD0iMyupFU6G0MZPXXfP3ogdnY6stB+Po2KZSB1c1fXLulvtYJhHPO2jKTpuoJuMlZcZJ KqIyXKJAMMhLpE/olSkZOkm9Ke1nxC6IdFMRNWbTAF5U44uv9cjyaCotEV2shUia6MZYVEOoa0GO Z8gm/tXfbW6OZXWfZMJxBhZV5rArpM15ULWganMrlFy8a9iXUqZZvTCeYqmygSqx6mPeNMItCwU6 HoLSswl4OGEP0mFTlB1sBb1ah1GXn208yWReRery5250VHk1Ql2FWywqljd0McBnRc89zh1DEekz SUBdlBiuCpGzRI3Omk6tXQIk5WCYQAdZRF+mIh+yW8YlHJLev01CISwa48iMUK8xhcgYE21Z29t6 8TSZeccnp/o4iCAzFM3MoFwaVcrM4OrIWxTJ5BInQVxYWdtENEMKJFjBdCG+qdNoSiAxzYzLwvs+ 1iIbz2aGQ8gqgNCVQVK84OYAIiZNi662wYbQMXE+4WXs38zaziMfQ3dE1nYO2NGclG07B7IGmlnb JUDP2i6AOrHM2i6Au9m28zfMCmxbnqVO26km/0l+hQNcgb6VvP/3xsmKTPcEZ+h3DmJCIRMzb43b E+znFAOqS8Y6EyPaltflJlOjtbnoaHneSXX4bGKYJKbtEMsmhgd1Q1dzb9sNedDqiKquqznb9Y5A Pkem7bUKQkpGtpdNWpedZmfKpBu6HplL6RNigradrO4qT6S3PToCzAzVo+Cj+1Bd1TFqwynz3sXI 77VjLLfg697bIo4XW+xQGJ/pgVkavhiSY/VQ4Rsbj46akvr2AC4UH5b5TqBT/SVaSzXLbhMh6gQ6 teMlsux+L8MNdHrUTI60L4+ak5WMK+h7lxzzIbxEFBFMAOgPTa87fR07dws4CS8I9F1kk/seXVAP Ap2imaQ+XeWyccmxvqCj/JuLX56S8wR9kUu8noBjmhPoeCSW70kD0G6m2oIOcxL9Aw7h20uTgumj DU1cPs/pf4fy04GOHph8adEh2FtSraDTN8Fyus8AuHKkZ74J04uP4jPhEYXsPuiqpY4+oRiF8SUz 2YFOr6hzDSWOKgB0XM/F4Za5KARy7J0VISPgg8A/Zd+ahDKzobEAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image048.png" Content-Description: image048.png Content-Disposition: inline; filename="image048.png"; size=4284; creation-date="Wed, 10 Oct 2012 09:43:21 GMT"; modification-date="Wed, 10 Oct 2012 09:43:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAF0AAABbCAYAAAARKIneAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABA8SURBVHhe 7Z0LcFTVGcfPOffuKw9geagkJFDU0CC+RU1sUAoqTtXW0apV6/gYnfq2rR3RtlKwamvH1kcf0+lL rXacoc5YK8rUFIXYoKGgjkgQkAQCAZqYJYRk7+7ee07/391N2Gd2N9k8mLnHCYnZc88993e++z/f +c4jfPny5cxJo0tAjO7tnLsRAQf6GNgBHwl5WbbsEb7k3tVus0x3MYO5dWXOcHN3mWQCjSwVPaeh RLeXm9t8jJkBLzNZgCm9zIzgI1lzsMkcAxajdsuCQSfQix+sL/J62SQQqxVSncuYmocnOZlxrRg/ a/FPBfKKA7hS6iDnbDuaoodz3sy56BBcrDeC5md60DRqpjSFRo3GKN1o2NCXPQLYS+snuH3yYinZ dULxBVwID2C6GeO60KKslW3fRxJAI3H8XjKFC5GD/t+2dPwcwq93cK7eDQv+Gt6WT5ifGfVLLwzh zUwqaZRIFfA2w4K+2VNd0tM78VLBxJ2o01lMcJ8QGkCSHStgjH7PmtAC0Tagf/EzvlNDoEFMXG2g mL1CiDUWk+/gLVqjTza7j2YJ0hYuXJiVSboM68ML5kZM99OC8we4pp0A63YBVdRqbdA5wE4uuL+x YObUCpAatKHmRiNMRQOcge+XcamuZIc1T6uoaG33Tw9WGHvpNTmqUt7QN2+u1lqmVl3GuPw9iEBK dDdJBGinf3CyYi4YF1ELTviyyUZlJn1CI9plRxsAXy40w1Qu1AWaVJfzPs3Tyb/U3uI/tg/wraOF fF7Qv/jiWteBSvNWPNxzmuaqBBGuVOqzRiFDdIQelRmYv5KKOk0Z/wX5tvWEQ5IoL32PSky6FJMq agCYP8qfyri6wJTWVbxPTNjHj9/l9df0Fhmbx73l56zpBHzHxN23AsrPhK5PlBbUNUmv+2FLKyKR z8DHQVjpVljmdvgqu/AzASGqCv/CfeTHoR0quOIz8H9l1PHiIy+u9Sb0DWnfIrw15IFSYVJGUE47 Wu4F9CjPzxeNLePZ6gegkxeyfMWKtEJMn130SP1NsMNfaboLwMnJiE8xANHeL6A4PA6p1hQL4z8B n7cTOa3d7Vus2cdXDZS/8/NtfDarEvDlNfjoGrwTwXpYhVsXi7iUl8KfPAON4EN5XqG78EbFezlJ d7fhoy3R8Uopt2tMe9jsDr81Xt3NAegbVO1UqcTpgstPjKC/j/kD5u72ysj1U16JrJcL5jAZfkvX PV9KAQ45IKu0LPMwflwZ5uwZ5mWf1S9dDPcufSMOZoWbq6u1wEa/1+t1lUkzVMc0cRHyL8RbNIHe gJhl2y9LciLLp7dNSusQGul3muDPzueN7ePN6o9Al4sqlAquZ5pWIk0TksC2Q3I/hf01QyYWwY7u wAPpdscWl2DjFmxwh8XlMjF51ms1B18p2GCmurparNzIPAGff5JusWvgHd0GsLM51wA/5iklw6fO mtxW0j+pNkohH66aPKthysFXkl/PMWuLgY50o3e6Ko6oS4Smz4GHMQMVPhm2dD5gX4EvjC4Z6W0i brQMHn2b4votE7Z0vX3mhHcL+mCdnZ3qGFenOZO3He4+qWRD7xd8JZf6AaasSqhJKRpAJ8tOGQvA MMjbxNcMrtglXYe7Xft41SflvMUYM9JxNx6A/t/S89Rk49AMyHItKqvZzp3gGrlpZDsprzN5GdHx T5cG5zk8zXdcm6oo3a+qjJ3B6a6eU0rMYwCtUA9JZc3k+3oT4ctKlD8BL6BOY4SEFOvkuaYX4+2s Yywyv4VXfooG3FeoOg21nAHop8DVAjQP6F6FWAl8b7iCscHKIAMdGkr68bg1qMCl8OOuA/570Ewn Wp38/XK+79BQK5bpukT4vpXo3A9CSubCOMjy01q90MiIxPGaUgv2sYqti+eW7KK3qNB1y7W8hNCu zowN8KM7cr3YzgeBtd8GoXm57irBb0qUKT80/VX/y6ucPDPPa2626njjATnZfApjhivwhq4G/BAs O8XX74/tQDqr8fNLz3/sv/7lSWcjNjQ2KWFw5PWfrwJ93fMB/iQaAOY+lCe3m8NrMOn73yIRvuI8 662+0XgkCgOU8117W4yKf2oudphJ6wyA99HIN1nrSQuF5i6B3Cye1CfCrUbFRzNdbQXth3J55gRL /8r0qogSWj2sN5R5ZJiu2NjwXvKNeNYf1xU1FlxWsj0M3ZOsHlSvUZbVCH89Ylt9fIgBcklODbqA UsjST9we9uhmT+2kbGUX+vMES+/sXKva2IyIUOxGkotk9zDTze2Hs8x2dGg3zxfvfVLoSuZaHln9 DL57ZwubtkoXegR+42mQFI8d7YxL9Fz4vQvf54fDavY+o/KDclfbqBlKynSdGfTvwoTCdlsHM8ZB jjwBQMODM3stxn9y40kdH+QKaCTz1YlNB3Z0mT/FI9xjmZF2OwaU9Cy2FII8+qNrLLd4aYM8/8SR rFN82SnQ55aVGhgQraVYdizKnbEu5CMrGaH5txc7itnLzc3N4ybYdD1mnFavWPxXjfHbLCuyrX+0 mmDxEqaC2CXX2PmmjPypQS2qGA3wKVFGitK1Rcq94HkFrNg1WMiWrAfW9K6psXsvshoDo1HhfO6x cO1aVi7atrfwiibdZKdikqXcHkzFyw103g43MzaTq9CsVj7n7Zm8JZjPffLNm3Y1gGkKch1p7jKz ldNQ25KfA/j34Lrtz/fGo5kf9Wty6+hglVoF2bTsEHK8xsNy7FA0E5e7VfDRhr6vlY5k/dJC9/sD 3bhpE/X0tuuVlKjjVKbZA1/gR3igj0aygoUq+zS+rjXMg7cyIf8Cfz6cCh5SoyHiqfgturf7/oa9 tXZwbSRSWug9vtIIpOVd+LlhOwIQl2wdR++EV/V3ZnHrayNRqZEqkzrYsMG/j7r/gWLwKeDJyDTN C+/tB+5j5Q3LEPEcibqkhU6TvsIlG9DlBxMsnSaMbT2Ub4Z51xN1of3jIoCUDxjy58NB9UOEOV6F xQ9MhPSXAYOCOykgL/yxJVumXJZP2bnmzbjCy+jBEgjGW+2ZfXuAQXFzyIq0Pg0L99I63nww15uM t3wA361p4ruQknq7bklvc3QA5TqGS+tX62XteYWuf0boWOgTQs/yPiBbdu8OHccERoBr4sE6vm5r oSsy2uVhcmO/FNrdylIbom9zIgr0t5g/0WcJyZ5q6DsDU4mFSxmhr372kjBauh5yguG0i4bPBmaX n9zRVfmvwt1+bEuqEes+w5T57ZZlfRZdFBXnNPSv2+HsLLfXc9/6SdcWLECWEbq9kkorboKNY7EP XCrF/m6GxW9o+m5sURX27jVueF+C3aWs8J7+1WgD+k6uZNSj+Q7r2rOoUHcedNWu4W3vgqY3Yfpu o9S0ZdDCnkLdeDyVs3r5hWssrh5AJ3ow1aOxKE4zQZPWEw2ytiAj1kHXveh6leiRmlty9XKNeO+j 8QSqkHWhVW57/GXbhcFpDaY9c5YaFubHYnrKt9F7ypo51vZhrSoe1NLLQ42G9If/XCMa1xXyIcdj WXCTsZAh9GtIefRZ4waFFJXEG0CC/+3pRvfFw61/1k0BR/NCzXzhzBebOuCxPITwxl5O657iEvn0 8COxUkIuH67MZIWeb8WP9vy+LR2bpBBPInpqJOo7xit2x8rmuRh76PW+auxnGFpyoCdxmzev2eow EJ9R8i1bVlJkRsd6LHbDNJ//nKEhd/YcpeV2Obw0JdwPYYC0g0w7UWZI33kpt9RdDZ7aoqGAdyw9 AzUaOMEml2OG6XC8zMQ6Vepol+gGO9uBPhQCg1xTWux/FVb5DzswFhefoalMqE6JkPzOoVi7Y+mD QJ8XWhW0OPstfPfu/mXZlN2e2KbgH1OXDMXaHehZ3o7KMrYJ06hvRCd0juAajrU70LNAL9/faJC1 IxtCBHHQ46zdG85P2x3oOfQDlT62CZqS0doRh83Lk3Gg5wCdwiFCc/0WIp7e2rm6UO/RZ+VQlJ3F gZ4jqTKv+SE8llWIuGJ3T7zM0EY2ViSEXEy7SHIpzoGeCyXkIWuHtr8I8L3x03vRUStDZMC8NLDT n9MKAgd6jtApm2mw97HVZ3dsS330Spg54u3k2cwvDZrH5VKcAz0XSrE8c8sqsTpCvI1Vwfa8cX+i yXv8VxSS7sW0uTlbkQ70bITiPqfNYrD0N2HeRsIKAnvzG3crkpgzZ3uyFelAz0Yo6XOsqv0Ie1wP xP+aLN2WGMbP1oM907MV6UDPRijpc73L7IayvI1FzZCYRC8G1j6RSfOr2STGgZ4ndHsXttTewGVJ EkOHFjDsv1In9XylNHHaKekeDvQ8oVP2sJAbMIt0KHFtrb3bA1EwdbzZrjvQh8B10Ev8PtYLFd8T v1uFdN3eqc3Yl5kvAL89c3IsfUgt4rcEV5/TiSrxu1XIjcQa92k6K53sQB8S2MwX9fg6LCU4pvJw yl78SjxyHGkzjXLPcqAPAzqdwofZoYTh/ep7l0SkKbZCS7DoKHn9I9adSnMm1rZnVJG8TjYaRt2P 2kv1JZEiby+7fbesmNjqq+icabWFaC/TfjHDBxm/AesfsSosur8ttmGY4zDEbSeYc9ZWGJvTHnHl aHo2cwjgtDIml9BcqbuXP/+Bee7ihr7aCTBx7FKxT2o6kmwHBsKjxJSO9o8zhgMc6Nmg43MM/aHU OPtAE9+Ai/Kax8Ofx6T0TZCX6KFxCQlHgijZPa2sNOP2Tgd6DtDhoWBpPimF7RYWI7h1BX6+G5bu ix72EEvR41gikJn1q+9bEs5UtAM9B+gDWSiaSPCjxx6myEc08ig7cZTF2sGO0nKg5wO9P2/02MMk VYHA0wl+jO00lDFoeNeBPhTo6a6xd14DJ+c1bu79xXpVey5cTTr/JiU50AsFnRTfPq5WuOG93IAN YvWePv40duedDm8Hp2ofSQ70AkK3i4qeHUaST6BvwZHm/3Z5+S8b5IJT6XxL+tCBXmjoMYuPbiLA yXNun18o9S23itz2zaUr7ZGtA30EoNumbh/ihrOHwn17IDs/Cof4Qyt/frW9w9yBXnDo0Y3OCPXi 7GVznRTu699ccdFztDOx/8B9B3oBoduhXQJumYfgVP4R5yZdh3Xu65LPMHag5wY96xmO0WPIcc6v FW6FrNynAub92Aq/13EZcwOcmkvRkbcZUuzcBOh2GLvy3pHcuurNRy98YbATrR1Lz94QmmDasfZU XJK902DI3hyAndYo5plwOHh1jWjamO2PpTjQs0On1VspnGKhFxzwFNqKaNgdJ0yu+GFd0SY6Kz5r cqBnRWQ7gEdsnDpL+zw5C38JQb5uCHlljf7+K/kcFe5Azwl6NJMtJ3TujWl24q95PF5cxG5aKJq2 5FGEndWBniOx2PIKZUVCn2JO4+bSLYHH54UaScvzTg707MgoXuKBnOCsRmslNvV+/Rz9vTdoZ3X2 S9PncKBnIednARrztGF19GNhn/9mDHY+Hyrs/usc6FkI9pSVYsd08M6dUyufrAutKsjx5Dn/naPh tq5z/RECjqWPgTU40B3oY0BgDG7pWLoDfQwIjMEtHUt3oI8BgTG4pWPpYwD9/wMl/vdFIgWLAAAA AElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image049.png" Content-Description: image049.png Content-Disposition: attachment; filename="image049.png"; size=1421; creation-date="Wed, 10 Oct 2012 09:43:21 GMT"; modification-date="Wed, 10 Oct 2012 09:43:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEsAAABSCAYAAAAclym5AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAUiSURBVHhe7VwtcBQxFK5EIpFIJBIHjruDGZBI JBLJDHe3dcjKSiTyZNtdcRJZiTyJRCIh30uu3d5tfl42mUuyYaZTZpqfly/vf1/e2Vn9lw8Ci2b7 ZPG1m81X3fl83V4t1u32wc+q+7lYd//oR/5/g7Gz5c2HWdO+yOekHpS+a7aPcdD5uvs+X7W/74DY A+Lze9XtsN6bpnvlQVJ6U4h7iHMUl8T6LYATHPjldXP1ND0ULBQtljcfhdjcRgdpAHxcDrg4adBe NttHQsQ+iRvenQKkwz1J3AVnJwcaRCCYLgovqhsYFBNoMBoC7B9RgSWr1rdcAQ4qxffeOopL+DOW U2kNcaGHYJA0rNtv0uq2f6OBNV9ev/c/SLslt0Gs4aKUcShYPaULzyWYHkZDXOx+v7fN9bMjvWrh QDaYIFwQeulB7AaKF24Ee9OBCeBq6Ehx4F8sWuByiIsCJx3OC+rDqdtgEQdfCPNCAKRbY9HcPKcL HACABaSw4kHoBEHOYieJvrAp1iCE9Rahyxzh14HjRtPEAQqcFErUfAmXus0rUhhnEaEQXXwncF1K ziAujO0YCwPge0FnyjWwO5k9K+O9WcCJAAp+E0tfCesKbvQiw/Vm4Kd4bRBpksxmeIkgZTm8VIiT sxnKegQAji5X6EsuNx2NF4aMRQ7FeBanb7ZqP7MWjTxYOcmj0z9Yx5lU5ewZQ4wgJtaZIveBMpgf djhtl7//O4sJkJW0LHzpTv5pRpJh8osyoLfczgfTbwIKOuE0x/fblfxDppOK8dbdlPhpZR4xGNjc ulCCAxCEu/pcOKf1CDZLEjTItFITZ4CrZ2/cXQWi8mvK8I+bHMc5Y9BV90bAFOca00YU9GqAgoOX q/iZUDYaAV06WuXO9a5CinnsgLw2lKmAnzm4BeRYz1XdbUC6kl6qbwS0IZwprNEinPSxxxGnmOdY RxsVu0jglairvKE0KXZnT9Z798wmGpN63Og7s7OzyFUJskG/Ct4ua7HSB9N3OL0TelH6+VnnQypC B1ZKuXTWoWINNuaoq756CLs2Co/5zT/WzcdcV32CHw6ax3wOikn0qda2ZBmKyTAEwddkCVPNrwc5 uM8iFSwGahWsChYDAcbQylkVLAYCjKGVsxhgIe88hS85DEjMQ7X1l9WDPwZOFxvie1qwGylloZp1 YNykMZ+VWO0V41hxhlqC6U2cXTNeVfu9H3XsoZ9mZIwTkW7SW6wKuNyBcKHf4pza65RcNilpjPGh UOFFIex7NFlFp5JB9o4ZT5CvKI6fk+3DIVapc8Y4OJNuqlAutZjNGZzDgbYyydSenHgfNNREYwEu +V3MZxqhCEtxHevLCrQgMDiqxJ0JveWJjrHJMkLhI1OhK3CjZyByzHl0QlPZwKG4fjBu7JdbTgYw aghheZgN/dbnMFUm/aAcILenK97ManvDQz6YyKjuHzLqKp4PQfUmKPWJ6LBhfXYmlL7K52tfkiEK mEQhr/M7Y6vYtldez2lT56g+fVSaFKjXDAzHNACzP9g0PZK6+xtZ2ikkFS01805gKcOwc2nWk5ME DtJKVm9svxdpSUU0MIHwibKrAbqvUf5/CoCB7ag75MhGYJhfTDdIk96gHjU+Db8O50CsS09fuzTK cAYTgJWcseC2ANADRy3pRKOw45582VtEHEA6q/q8/RAw6isStf2F2MXu1pYM0PiIYXqAjgaGBIoQ rRJaHIwC/j4FLUUISUNYteLDGR/UKig+qNU5FYE+Av8BRkBZLoKX8KkAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image050.png" Content-Description: image050.png Content-Disposition: inline; filename="image050.png"; size=4408; creation-date="Wed, 10 Oct 2012 09:43:22 GMT"; modification-date="Wed, 10 Oct 2012 09:43:22 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEsAAABSCAYAAAAclym5AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABC4SURBVHhe 7VwLcFXFGd7dc+4rJAMhBSohCUaFBgOoNSCR4KTo1Prow9ba0gft1HamL/t+TG1Jw/ShUztjmTq2 KrR2pi2tnT60+BqrtWESMVLFhsQCBkiEUALcQEju45yz2+/fc3O55+aS3DzJlSyT4eaezZ7db//3 /v/y+vp6NhVa06wVfvuw6WOFjDMWPjOlcCFnIebTX0SYheeOGbLtJy/otevb2uRkzp2fC7DqKirE rTvLA+FQOGCy0DymYkuElFcoISuZ5CHOlNIg4ANTIp8JdqmSTOHXFjzp4oz/lxnsdSB10ObRVhYJ EoixmlhjdCLBm1SwGvqrZ5ghcx6z4jXCENcoJVdzLuZhgSaQAfUo/ICwgNFA4xzQCDymb6WNHw2k zTi38chRUloAtJMZqhFf/zUeNV8w59t9q3petMcbuAkHq6WlwmDlhfl9QXatUmq9YLyGCRHAIgMc iBEY+N4FCP+fgSllqQlCA0CAEmASnvQJv2vyI7JT0mFSRUF/ezDo1qghtrGIfeCZu6/tr6/fmHHY kYI5YWBBBpn2id6Zpiz8ABbwcSHUZVhdnhCGCw4Bg0WOT0sAxwWRHwEfx2b04dNzTKhH7JB4Aix6 cqzvwujj2357/EO+BlU9X5wIfs7vzH4Wu3yvYfBqUFEe0YF0iJWc7IAiykn9OetUXeA1mxJtcuEX pq8Q777FUOYWXz97rsle8+6W/htD2ay2IVAdrKur0/Sb2saVsprV2kJbRT4nHLmeCaOUg920rKHd HmClQTM4w04DbDXQxQsqyS5Ds16SbQmaBJVmAgHyUINN/6Tj9HIl/9xn+H4UnB1tzyTTCMze0PF3 csWuUWH57VVFL8ZSxzVqa2uzAXvIPqTdgoeXLOXcehATW89N31wsygQrJNgibYewCAAJ0QWW1H1U HB9iWHg/gO0HBBHl2KeBwyugxd0Yaw+eHUA/QcBj0SBN5kipCAhDGKQfBhFCihxEP9o4zpaZ0rlJ 9PvE/uiCljJfZ3xgZs2qeoEl+r9nAEzuqAVHxVvuX+zb61ESY6asRwM3huZFjn9ASb4Ri19Ik9YA ZBDVtNMEkrRtxQWPuOCoFzkzdkhmt5pCtDEWPUwLCPGgCgeh9cKegUwWZPl+LpZKJUsMpUqA10qw 2wrAEQKoUBpCvz+TPEy+37FjmOZTDmPfZmG73ZwdvMpxnB9jelWmL2ha8chRi4eurBH/6Bw3NiTZ 5Gf8O9BCn8DuznDZZrDioQXQRJUjHaWcU6CBp5TgjwnOtkcj7HhHpDS+Z9NiGzZf1lqromKD2N61 x2g93OEPhliJ7ch3cW6sw9iLscA8vJPINsN8iBbxCLIT29CMn+0Abh0zYMJocWcwx7GOK27fvEq8 2DQuYDXJFVcL5bsHk6tihmEoB/uURk16JwkkkrxM9YC9/gSae6ggWtj6yF1vj9ZvHB+VTgvS2vfw nDwz2HsZlruOSXmLEmKOfn8GSteyzxWoNgAyB+QqsTSU0Ck8/OxKs/F3Y5ZZTfKqdwglfsUNcykG E0RRaVJJ7xDJFby5CyA9KLj5xVhI/uFq2dg5F7Kg9vnnxywrUwcoiR6SZb69sRJ+8GB7sOQZX4w3 SCbnoE8ZKMm1atMbCX+QoIdlSfaBx7GpLz/0/U82ps5zxAJ+h7yqlku+WZj+cg1SGtvRjiUEdy8E 6haw2qedotK/rYxtO1rmdI67VZ0JA3pPsdHZ0RMqfdyKsyNY/IVgsFnoix1Mb17O10YveVaCtV/e vfOJuceOJTuMyM5qkNVXMse4Vxi+C2UmoCCbyKJ2pLXPdtTn4/PV16pE4/5VPVuTWmdcyWmYwSph iIKV7pPCXI893aNNk4xaM3UgwoabXLIFu7Z3efDJGqwmVV3pV+xBboplMoNJAJYEx8FPk/Jxg/ve //Ty8G9rjkysYzsc8HUbNvBmWX2JYNYdwGiR7n82ey8xGD3WCoCp4vKLrvfYI1mB1SDXXAy39T7w 12WutvO6KaA00i6nhHDuisXD66rEv16d7PBJOnAtger867/77Drs6zbw1DoQvC+Tps7Elq5i4nPN cPfM1OfDgtWiqmf5pXUfN/garT7S/LmE9ugBj3/Nma1+WJPXNmYfbDiKGe55U3zNwtP97BfCkJCt xiVkEAxHUd4xte/qt1XvgqzBqoBlfhKui+K8lmyldKCI9WAy9CJqsvHiE60Pw4XwuAfDLWoinuso B7Mv50pdAerwJ0IUI3uV5kUIHCmKswZry+45bzMU/4qAV6qNuJRGFAWgIrAy77FntN9fVNRjjWxG E9O7srLNsQvan4gb/Hq84cfSjh/FLjtYg7b5smna3WQUnRULUh3qs/51S6AiXyj7u2C/skEUxQ0y 3OAyqF/acfbTmtiRCY1QZrPA1D40nxre2OHMturjhliLRT+E+fZSH23/ZaERYbL6meAX/vGPMCMS LSNYdRvqeF/fzFshFN8DF8LjZ7kWueNgiC2xENtQk9fYN9LFTFZ/iIU4QGuJhZwvCyHfK5X9GGzD Ph2JINDcKGIGGe+aD+i7YEvXk0mMMoJ1bf1zi9H9Wwjn5nms86SdonZYnG1EQE3v1lRvFJuvEi88 m593cp3g4mOIVjTCao/qkI+2Db2NYmJk2cOGWLAI5tlZKevRQHVeQNpfRedFsJk8o7iWudNjC6MO O3ZkqoOUPr/KWNvpKrH9L7ZQNwupviEday9i+pYbJ0sBDUKLzCGw4sLWyJKk1T8I1jlR+wr46rdB gEOhnAHLjRrY5N88LE7EG3INKI9M440nQq+F77cEXwtm+QnkWSeoySGl5QYgScBrKR8wI3ZSI3rA orM7rsz3g/7yXU99oLluAkyEViH4XekRxFwEjrRmjWjsJCWgDN8NWN5mKRFtIGml5Rl9YD7B/OUZ 2dA+UVAERN4LGvR44mT+Q/2dhlj8flUOst9Qm0lKYBX/V0ssqL4kObsJPu/ftRJwySsEAEsGgUUG qCkjN4EML/AMnoh8Ssn/HY+zp3KRirKZMymBVbyxIX/GyQ+TEnCseDOdEgkhSihsTmMk2fCBnYUz EE75MNgtkC6rwM5xbqjff+bucCSbF+dynwElYIjwjRBHd0om5B1dyzVfJsEyQ2w5fr+SNF6qH5UQ eEcB5F/b6ic3t+Bcgl4l2rpDS8O/KIjOvKeoZ6v2TjRYEOwBIdkt+Ai7yqsBoSkcyKq/lJ8oPX4u J38u3l3Z1uZU5m1LcpMGC9krQURdroMWwIFJSp6Bdp7ZaYTXtxYVueiez02DFQyy2aCxEpflEmAl BDuw+4/dHX71fAbJow1hKeD4SCE4dgYSikXrUxmhdiwJdp3z0MtU2CxBR0hxC3lROu0nFS1QmWKW UvyVTZvumJSDhqkAyFBzEAWROT5Y5UtxoIHYsDcvCsRl4zxk33il7Ex1MIabnwiHmakctQhONvIh 0o+FVC9Ias9wg5wvzwULhQsg3AFWin1FfqA+imevsWB4Wl4lqEGYii0k7zpVXumDRqkcJG+0mqGC aXmVBIuJmWQxeI7T3OxDB0x5rP318vFKz8t5bh0mgi+yzmrJeSSyWMAwYCFoMd2SCGR3NjQNmEZg GqwREAJyFoditWmZlYolwlfmENpuWmZ5wDKU3Y0vpOeQVieAwNFRak75Re3TrHrGzgpTyvTpVAS1 2yPoKJpV2Id7M6cYjoDX3yxd4e4UxpBZfkBHSAfICxaqPrZnrBzP3fK16UbasNBBfH0fwEL6whmz yj2p50Vwh5ZM4+QiIHpD3VSC9grKFqzU7JJEeBn5TWxlSwXlPE03QTUs0pA7wHnWwNG1hsV1Fv3I Cbgq3D7NikmjFNWkrfjlWKozTWeHlO8A1lzNbNOTLni+0pg2C+YHIxGEY57XaVcp2STEiqCvIjNm 30wn1ucrSAPr1gAU4+gaR9ZbIbf6KVd1oOkKLFRT4ZvbcGKdPw1WAoFoUCLBi7fqlMgUEwLp3PTr pX5Tjr3WLsfRTpJR4c7waTDdH1C2AkGfwnG6tI/nS8HWNwRuzMvx9Y5p+klUKF+JCfPvOC0Mp9pb JLcoPm9wcZ3Z2/2eMb0tx//YI7QLQt0d4MF/oKrMkzao80oNMx/y605UfL41x9c86ul7wEK6TQRF Qfcjw++UNzGVUgYh7LlYjJq4LzStWHFe+ouDzIHuSPdL4LutyJ7xmhHwHamIkTv8dvZCsHqo7aEC ozejqTGo3nCx75jdxUr2ofLrJoAzy3Ps45bF5qNGbnmnKG9AIeSxdNCoHLf3kX9e+fL/ArUHote8 XuZ79U2TfZPR0AztDu9FcvPPIaviyWRU1wfCP1CYwa/gtv3zBrnWm1KJHlu69pjCsd4Hi+NnPv/r 33w0y7sURi1IJvEPM4JFmrEgzjajov4F9zqTlEMeHb6hcllVG3AiP2npr5iVOl/Ev4KIha02DP9s 9Pv6HP/JbzQEPjpjEtc0Ya86a9nvXF9n9BAvPgTquk4Y/nxPHTEBhmtAwJUVlhko6uKlLxXzTh1A PGzMvwiH/3fqawO4QCxMrjLsnrfsj5Rsxz0KOZ0KMKS/93jryWch1+9UjtVL5XKpjcwJ+JNUOXU7 zjy2NMu1ZfRccGc1iDFI9hnSoqleOgi5d7svwO56Wq6lAu+cbUMWlNfOPabeKJrfyvtxyiPl1bqK 3RuaoIgq7qBgl+Bmi5Vv8OKDqLe/DYKtkjhVSzmKXiD9Eh8uD7D4wv2stKGMd07Z4qihdnLY6ntc AeDsDy17RdiRUiSLLCf28yZGkAzT9eolXPFb4IwvwhcUik4KOqIy1Pshp0kuAe+WHWGlzWDbc17x OlISzyrsUhPb1gv6+Q5AeZpulPBqSKKeREqEMPPBm+Q/Djr2J5akyg1EN261pdpMpbkjney57p8V WDRJlKEc5jz6KVRRbYW8svRlOR4hBrNCXwxy9lwSOhShpDn8Q4GRtRlyjq5CyZmWNVgaMPHvQ3GD fR6m/SZcvtNHpbTDV4WmYUp+Jk5IIMbeoZzYb5rlmmW5gtawMit9IRDO0Z7IsgbHiB5FOKcKFAbW 08m62TcdycDfCF4MxbGig5e0lvBOOPFTu40YLFoO3SUTbs1/2ZkbeE06fBHncha+HqKONgMICXaF /JsP92n1fnbhrjJ+cEoDNiI2TF0yWfkopX1sRlyuhXXwJQj5cLbV7clxKMavKIxmLvJJa0uzXX1D Xd2GKZsTNmqwBhZcmdd4UhpsJ4wt3AE2iuEIMMgxw/RdjAraB2743jPva5r1ITqvnHJtFKvzroGK DmCIXg2RhdK7LAWXexWTe4cflISuRKPbkUw/SmzVvexYxwcpzDPV0BozWHCcAzA234mF+dPvf6DF upeyusCQueEWauur7uhqUVyRaffh55S04t3Stp6E0N+GpLH86zdlur7p3MI35jv/cE1UcUCqndzn n6dvZ0tcZ5Co/Ulcs8lQu81tJZiNq+xwGSLfD3N+H7zLNpTu7ZIm6zB56EA0EonT3ckEyURf/Tsa 2McEVh0CfTfsfuYjMBt+DXYScLgJLVzjy1HzIy1Io6P4vA/U8hI0XqcUYm8BZy3hSKFViMq9XZEC +yM5VJo3JrAOvbU6+EYXvxs+422QV7tAPf91uNyPmqnduK3rNVx+2IMddDrml8Z/cMEup22Sb9ke DfUM9TdjAqulpcWIXPoZhF1CMWIh3IFgs4uYMxGXQI/3wkcz3pjAGs0Lc/lvxqwNc3nxI537/wHJ rXS1dKRIbQAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image051.emz" Content-Description: image051.emz Content-Disposition: attachment; filename="image051.emz"; size=2897; creation-date="Wed, 10 Oct 2012 09:43:22 GMT"; modification-date="Wed, 10 Oct 2012 09:43:22 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1aD2yV1RW/3/2+175SS58PysrsSl+hoxSy4dYsNHTwvQJtGX987QpCVCykKiM4 W6ClSKoPNAW0QiVRSRQhC5vVoQSHGVnAlZH5Z7AF0SgRG7os449zA1OiCxTefr/vffe9j7bv8ShU XMJJfj3nnvvvnHvPvfe896oJIZYC3aFQCEzMBSZTsGlwqhAHk4TImTarVAhNHCsQ4ijqdNXA5iba PAlloRRiknZl5WcvuUXxMUNgADEOyAEw3FjN1EQWZA8gPe3H2a3aBtveCwQAts01DXEbZFK2mRKR R2EMpR9vSmssw2oVnOwzkyN1hiki8jDUs08mMAjwAIpSIHiAAHAnkAew7WAhgk65ErpaGEybv7TX DqJFrVSCMGfuFLEQ6/sLsUgsw99vhsy1ReLYE0Wi9uklqSuCReL8/UkVLOdg+sMow9zQPpSr1hSJ aRfSK6hT9awblzQs9Q/Q225Ye0Lf5/wAnrlluktKaejSCEnx99BOgd0I0za7g9Nn1kwRD4hfihWi HmuwClZ0Y77np6RUIJRoy4kJsMO7NLliJnhw98WKGnDaEHANS61pEG6OodaeU8SSvajjXrEN99aO C1kFmVDEAT1A2Ny0kjlz0kpYl2brZoKHY4jaaCwEIOcA9Nc5vg9ljplt6znOGKDM5rHsykU9beSa K596xplTn2+3p92VQC0EyqfRHyxCrVSCblb81TQWie5V4fjb0hCOP5ZzYNM5lOlvJ8qNK8PxR52q Z91Ax18O5nXG370oM/5qwRl/68H7E39qTyT9hB9gEXLsibcKN8HDOBPLsSKzwVeCV4pHoFuIczIw pPYkSyxJ7c+eFCf3vhNo6c+z4ZlHyiTdZbikboQKRKe/UbSrOyFkx6LTZ9GHz4nsCW2oxr3Q807g eqtzEkumGarNQMix5nXqEznbbH/rnCOmbsA7k0hM3TrnV969t855NIfo675wnudYcn/OeSnOfSMG XAow3y0whRgFXSaA1JMpeTCMqJxtulSOI0aYekTuoy+6kqy+ljTWjORHyKeTIn19jjGdeXYiYzrz 7YEe32nPg+M+m2A5hT9hee9BEbx40GnDdbbfu65jWTbB8Q8lt5YYB90lblPoezBnG8DPL7crI8CD Iy6UiT8/VCb++S+LW+VFz5QrzrrghxvKrTbQs2vwXGu0zL52++pDl6x+5NZ4i9KmcxyW28cZ5are GtOel3qhXUlrdF0faoqgB3Mxv92/5q6QD9wNLAJU7sy4I2DRTy3WQ2bcjwYyAb6lpLvW7Le488wM gUaNqfSYKzgX+mqAn704P50fD3D9VhldMsM4CXTJzZJ4XG4DNsss2Wxxyl3SoxEn5U5BHrLK7JOB TyVqrmTM1ZcNmCbo8NGPsk3BiEwfeSargSqAZ9JtatKEXAhwv8HEeoN/QbXvlLIPSXFMM1m1e+q+ CaEMM/y5g100IB9Q6zMKMoE+Mdf8ftROANiXnKS4kFpkLybc91S40v6r1oP91L4pG1Vb1YZ6tWaU JwJu4A7AA6yG8W5diHmQCwFFzNtJSVA0G0n6RuOS3Ij92Gicls3GCbna6JA/QZ0HyMQYH2DweGN4 jSMy1Tgqk42P8WHzUymMTuCknI/+EZ8hh2cNhbDXCGrufwfio0O2IUbarHh5DvHznIw3169R/xp6 7ZLPyN/JDXKPfAJoitjbBluHX8Xe38jBcqtMwihJcj3wGMpNcnhkjDr0b7rKGLWYdxnmb4Adj2Kk IOxqBuL5vBn1TfCzyTorHTgHHTIPZyMPZyOez3lap8zVPpXZ2sdyuHZUDtGOyDTtg4i9r2I5O65i 7zZxQr4gTgNdwCW5TSTpryI61D6nIeCGXiVWhmgZ+nBtiJ6tpeu5Wqqep7mAkOXzeO6pTWqfXSjT P4/m1jMMRCL2XODMx/NVGC58W5GqJxvpeqoxRPcaGXqmMVTnQXMDKra9iMvP4TPXexSgSM2NKlGA uQowJ+fLVw3AVRu4izanpA9xyFhUa+HBWqj1jNXPwN5dEKeArrh7fkGEpFf7XO7CiLuw3l6tG31O Wv3i2XVBXJYG1o1rp+zaDKfUeY5l18vSrbfJy9aZUv14Jh4H4s3XJpfLl+USRPKSuP40o/5FuRbj ZyOOs3EC1uLMhvvFG38d2jRhDsa/sotnDBER164m+LIOPm0GVL8M7P3V1sGHeCswLlv7zxgZ18f+ Yxjs/0npNbplA9o3IAZUnBWjzg0wmcu05RHgPwN+DAwB1Hug7mOogkrme8a4DMdm9K2C2g+1RXD9 inelFOXCJOgAvmFjzfAcbFwAmWPRlp451OAd7rff7P7PpFjtMSfdsCkqD1x7D3zs9DvHv/68NTym M2/9kSm0LHjlsTzzHBBiL7C9BJl5SSJzu01pcD25j+rtx53gKcR309SREs+re9vntMG5f733g30X J2TztdmzuCT+elX96VrWq//rcqUdia/L+gFYl/CYsddlPWLom1iX3nYkvi7h2LzW9qPM6O8yblN3 1WpC1ACMfbBeRN2GwOyytEHfZfqfNr18aiU4MdGNO0qc/qQjBUxbXllWIt74W9YZFIyH/LP8Quze lNq9kAlASm35/OX4TeYgob37SFsNlMenT/VXNS7490cHUoIBzxT/xN/X3zNv/CvvZu1rGuY9XHz2 4qS3Q9/Lrzs/ckzls6FTe0f9dcSZTefLvn93621v7Tn76IxnW2pqlrneD9z9yfNnh75fXvptqhix pdbX1fzm2kNwU0yfNnvqGyXVa/GWmIZb3d9qvQ02cdAdpm4WopwPsE6G6/4IBuwo4b2G+wn5i0tU CBc4frRCmXcVcxq+HwY27b/gfD+cv7dda6wk3v7m3/WGGX0nffDdDSjO94HlGYAJjAcYljkAlsqC B5xEfQAwAZKzzL0j+r67O/0SNZVALQbluDF/5xG9f2d85cPGJTuBLZuLRJO/oW7E/hdnfASZmBFa WbfDXZXX/mRlZvsP24fheTogRJHw/XZVXfGgqrzSOavr9qHdw+DvZayou3PWwhWMBaedLf840zDm 9c4q5oBD5Sm4FUbn0rl5Unwh3tu6xq+JlvQF24+Xz9uE34KAs4ONZVurvqo3v7z0GNwJ0xGHDI1p qwMIuxb0GdP4VT3XgbQD5bKp06dULxjp2w65eP7X9ePW7fa+9M4Deaw/B92leV/XM1aVjuv2BfTu 0UZavLl7/qbAflgY6xxkgnttmXqW7bdcqjbDe7RRnymgtqhnWfXjWFXAUiAFYHwwX/QBym+IEWL9 TMAT0UQ/e8yjXntLa9FatSYYal2w0LkBjp0GcKFoO7+jzLdl+pRry9xnp1wKfSEa5AM988dY+Vf/ 3/ROv/MNvbb74ubmOoYZiYnIPeHD2nHts2w+sPfF4hLGSyUwkPdFZ82Nuy9yYCvPOO+Lv+C+qHlw 6QpC3RdHRhuvxzuz6C5M/gEFEr0vnu59XzC2+7gvBseb+2bfF7wzeKZHAh6AH8a4/z0JrsW8LwKo a0EDxui3+174/831b+69EP480PNeOGe95dh0m1oZJCADz5zzd/q+/jchVh4RtO4Ffs65/jwiB7ao e+FwH/cC8oj6eGeTvpj8AwokeC9M3ZTwvZAeb+7+3gs8z8TtwFjgOwDzgHhnGtUR4rtNCkCTI8Sv +H14f870YcRCOzCwb/2N/ZzqzBNi5SRu0xXje5nob6iJfw+CxQXFylVi25AUw4bo76/XY4PzrnHu vVO28jnYztyPe1xgRr8DtPP7IKoA6zs9S/ZBwTdiEcDcEeFhvSk14Py/URf4XIBvkCrfA3kiMEa8 hr+Kot8T2uOrij55LrScj3FNu5lHeQDaLc1ovoVcVgwFSB6A8v8AVX1fsdgqAAA= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image052.png" Content-Description: image052.png Content-Disposition: inline; filename="image052.png"; size=896; creation-date="Wed, 10 Oct 2012 09:43:22 GMT"; modification-date="Wed, 10 Oct 2012 09:43:22 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAAyCAYAAADLLVz8AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMASURBVGje 7Zq/b9NAFMdvrUBqhzhlicSChIxEJqQUCcVFVNChgqpNy0BoqPoLK1hUUWWqDHZMaZMOdOzIiNSF CcHGVv4BJEaGDIgJdUJCSKYv4nxnc/Gv2E0TveGrKOfz3buP33v3zglpNBoEFV8IAQEiQASIAFEI EAEiQASIQoAIEAEiQBQCRIAIEAEKpetro4pEjgkhtkuScrym66PQxyjJpU6bvHDkvd9QixMSISd8 f749q6imqmRNNrbcnjXUa0FzUi3I5Oi/fl1sOXOALnj/jOfb5JJR6hVgJpP5QsevVpW7kqR8nJ/M vvaO15mDG8P9YOV22TByLltShBi6o+MZIjCalkvCA733MTAMikjOnAKvZGNLJ0XVmOgbQBoe1NMC FxMHoE9Y+s0b1IdehxTRF4DME4KfYk8A/e7xhGcU22j09A2gYZRzMiHtoFBKA6B7froxMFhhbPNL P0Pvgd3CkdoyEB4o2m27AvTJZ0kA5IFQW8LmwCDbz2YXFoCBa04Z0yWkXGGYMEDfXdgpZYLTT6oA vXkIwoGvs/inyxe00O58l6R2FA9kc7LwZIU2A+It8ME2b1sa3pfYScSbW4T9TuE4QCJ4oPh0IfYm cd906j88CyNABIgAUeccoG6al5Y3rY163byMAGNo9unu20J537632vyMAGPo9nLzKwC8+Xj/FwKM IQAHAEEQzggwYv6j8ECabhYQYAQBMB7gypb1EAFGEADjAVY2d54jwAgCYDzAxWe7BwiwBw9c0nZe IMCIgvoP4E0+aX3DMiaGplebnxAgAkSAiQGEQ31121LggP9Ie2neX2++g0Wu1KzKIAKEjQrmmFnf +wDrgZ0f1lerm1cTBbhRsx7cWmr95HfFYRccI8M4RiiA8+qrw8LMlD1CiD2Sr9n5/Dj3m8N1+8qQ QpxT994kAhDOpXOLd95fJOTPhbHx3x1wY1N2HqCeft6otH5ACAya6NseXsVK6zuENbxKCxPKofOF 9x9UABXyBei8vikJ4xh0DXFf2v4F7QSiAoFI1CYAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image053.emz" Content-Description: image053.emz Content-Disposition: attachment; filename="image053.emz"; size=2871; creation-date="Wed, 10 Oct 2012 09:43:23 GMT"; modification-date="Wed, 10 Oct 2012 09:43:23 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1ae1CU1xW/390PWCSrK4piwyCLMCLS1jhMB1Iav0UErI8AQUcnmiCDSeuQBlQQ 62DWtPWJkfJHmzYPbIdGmtg4TtMZp6OGNGlaNVNTdYhp7ECTybQZ2sa0jmR8ZPv7ffvd3Y/HrgtK TGc8Mz/Ouee+zrn33HvP7qIJIWqBa36/H0wsB+6jYNH4BCFOxwqRtmBJsRCaOJ8txBnUOVQDixto 830ocyX6awMrLzzrFAXndYEBRA6QBmC42ZqhiRTIbkC6u95jtyoLbLsKKAPYNt3QxV2QSalGfFDO wBhKP8eQ5li62co3z2PEBet0QwTlKahnn2RgHOAGFMVDcANlwD1AJsC244Xw2eUK6OpgMG3+xFo7 iCa1UgnCnOnzxRqs77dFtViPv58PGU/mi/Pfyxd1e9YlbPTli0sPx5aznIbp30IZ5vqPoly5LV8s uDKhnDpVz7qc2CkJv4XecsPcE/q+7CvwzCknxEgpdYfU/VL8zX9QYDcC1G51sPvMmvlirfiO2Cga sAabYcU1zPej+fHlCCXa0pMHOxJr48oXg/sOXy2vAacNZTFTEmoahZNjqLXnFOHkRNRxr9iGe2vF hayETCjigG4gYK6rcNkyVyHrXJZuMXgghqgNxUIZ5DSA/trH96DMMVMtPceZBZRYPJxd6ainjVxz 5dPgOLPrs6z2tLsCqINA+R/oDxakVipBtyv+apryxbXNgfh7ujEQfyynwaaLKNPfXpSbNgXijzpV z7qxjr80zGuPv1UoM/7qwBl/O8FHE39qTyT9hB9gQbLtSWIlboLHcCY2YEWWgm8CrxCPQ7cG52Rs SO1JiliXMJo9KYgbeifQ0gdS4ZlbylhHjB4jHbo/W/R6m0SXuhP8VizafRbD+BzNntCGKtwLg+8E rrc6J+FkmqHajIUcbl67PpqzzfZ3zjli6ha8M9HE1J1zPvDuvXPOQznEcPeF/TyHk0dzzotx7psw YC3AfDfbECIDumQAqec8/gkgJKcaMSrHEdMNR1Aepi+6ksy+pjTbCOZHyKdjg309tjHteXY0Y9rz 7bEe327PIzkX8kyn8CcgH3mdZbsNN9n+yI6/rk8lOP6puNbChA9jC52GcLyCeToBfn6ZyEkt8k2/ UiJ+/2iJ+LDP5Ga5em+p4qzznd1VaraBnt18F1tDZfa12ledum72IzfHq3Yt5Dgsd+XopareHNOa l3qhDaRtDodjsiF8bszF/PbYtvv9HnAnUA2o3JlxR8Cib5hskMy4nwkkA3xLSfdvO2Zy+5mZBI0a U+kxl2859FUAP3txfjo/B+D6bdb7ZJLeA/TJNkk0yXagTU6W201OuU+6NaJHHhTk/WaZfZL0fqnm isNcw9mAaXw2H70oW+QLyvSRZ7IKqAR4Jp2GJg3IuQD3G0zs1PkXVPdmMfuQFMc081S73avz/ElG 4HMHu2hAFqDWJwMygT5h1/xh1OYB7EtOUlxILbgXeat3Byqtv2o92E/tm7JRtVVtqFdrRvnrgBO4 G3ADW2i8Q4gVYLmAIubtpFgotuOT4VP6ZaAP6JXb9XfkFr1bfg11biAZY5zE4JHGSNRPyAT9lIzT T+PD5lkp9HeBHrkS/YM+Qw7M6vdjrxHU3P9uxEe37ESMdJrxshfxs1dGmusXqH9R7paHEGG/ltvk K3IL0BC0txO2TryBvS/IOPmc9GttwE5gK8rNcmJwjHr0b7jBGHWYdz3mb4Qd34U9Pti1HYjkcxvq m+Fns3lWunEOumUmzkYmzkYknzO1d2W6dlamaqflNO2UnKSdkC7tZNDeX2I5u29gb7t4R/5Y9AJ9 wGXZLvwS/Rxqn10IONcNYmWS5nJM0xIcqVqcI11zODK1z2B7v+nzHO6pRWqfY1Cmf25NOJJ0RCL2 XODMR/JV6J/xCwtHnB7nSNATHIm6y5EM8KA5ARXbiYjL9+Ez1zsDUKTmRpXIxlzZmJPzZakG4KoN 3EWbHulBHDIW1VrA3uB6huunY++uiB6gL+KeXxH9MlF7Xx7CiIew3onapWC/SHaxn45149opu9ro lLVH4ex6XgpHp+w3z5TqxzPBfCXSfJ2yVj4vq3EeqyP6sx31zyDiO+VUxPFUuQtyu9Uv0vg70KYZ czD+lV3NsAkREdGuZviyAz7B9+A6IJZuuA4exJvaf8ZIDqBI7T+H4f4n6pdkI9o3IgZUnBWgzgkw mUu25FTwbwJzgUmAeg/UfQyVT8l8zxiXgdgMvVVQe6E2Ca4PeFeKUc6NhQ7gGzbbCMzBxtmQORZt GZxDje9wHoc6bA6FOemGRSE53Pg3394NH3u99vFvPm8NjGnPW+caQkuBV27TM/drQhwB9hcK8a3C aOZ2GlLnenIf1duP4+XOxXfT1JGiz6uH2me3wb5/Q9eXfWuisnlk9tQURl6vst+NZL1Gvy4D7Yh+ XXaOwboExgy/LjsRQ5/Hugy1I/p1CcTmSNtnGKHfZZyGI6ZOQ9QBjH2wIUTdrrKlJa5xX2L671pY WlQBTtzrxB0lZuwZfxBM21BRUihe/lPKRyjoj3qXeIU4vC/h2homAPF1pSs34DeZ1wntD4931kB5 YWGRt7LpoX+dOxz/Rpl7vnfTv7sP/SBmdl7qpLyrOaUr/nv046ufHt+0/40/7+soXbC1/YO23Cc6 5p2Z/pNV3rnnzhzv+/KCuW0/PJGUMX/16gePP5AxY9oXpeI/r7Zc02b+9MBfik6+VAA/xcIFS4te Lqx6UjgN3anub7XeOlvY6G7DYeSinAWwTgbqXgUDOgp5r+F+Qv4SI8pFDPg8kY4y7yq+aXw/kDOI T8H5fth/bxtprETf/vbf9boReic98N0JKJ5ilReBG8AcgGGZBmCpTLjBSdSXAeqxtJe5d8Twd3ev l3tVAdRhUI4b9nceMfR3xgNnm9YdBJ5uyxfN3sb66ceeWXQOMrHIv6m+w1mZWSV+liy+2jUFz9Nr QuQLz0ub6wvGVWYWL9tSfxTtHgP/Y9LG+nuWrNnIWLDb2fLBR42zftVb+QSMnCz/DrcCaMpbnjlO dGubcbo10TIhfv97pSv24bcgwDlTj3+u8nKD8cn1rXAnQG/bZGjUOpUh7FrQZ1bTZX5sMqkD5ZKi hfOrHprh2Q+5YGV/Q86Ow4nPvrk2kw0uQnd9RX8DY1XpuG7/hP7tmfoLkeYe/JsC+2FhzHOQDJ5o ydSzzPMBkqrNNBTsbdRnCrMV/gwuq34cqxKoBeIBxgfzRQ+g/IYYJNYvBtxBTeizxwrqtd9oLVqr 1gxDzQsWOifAsV0AF4q28zvKLEumT+mWzH22y8XQ56JBFjA4fwyXf43+Te/12t/Qkd0XtzfX0Y1g TATvCQ/WjmufYvGxvS9qChkvFcBY3hfutbfuvkiDrTzjvC+2IFhrHqndSKj74uPx+rpIZxbdR35f 7Bl6XzC2h7kvDkSa+3bfF7wzeKZ5Vt3AfQD3fzDBtbD3RRnqWtCAMfrFvhf+f3P923svBD4PDL4X LppvOTbdolYGCUjHE2b/nX64/00Il0d0mXkEP+fcfB6RBlvUvdA8zL2APOKuSGeTvow0jyjaF/W9 0Blp7tHeCzzPxEQgG5gKFACRzjSqg8R3m1QGTZoQP+f34aM5028hFrqAsX3rb+3nVHueEC4ncRox Yb6XCf2GGv33IFhcULhcJbwNsWFsCP3+ejM22O8a+97bZTOfg+3M/bjH2UboO0Arv/ehCvDxCJmy BwLfiGqAuSPCw3xTasD5f6Mx4MsBvkGq/CDke4FZ4kX8VWSOaRXssqofyNNR5HyMa9rNPMoN0G5p hPIt5LJiMkByA5T/ByWBoTrYKgAA --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image054.png" Content-Description: image054.png Content-Disposition: inline; filename="image054.png"; size=862; creation-date="Wed, 10 Oct 2012 09:43:23 GMT"; modification-date="Wed, 10 Oct 2012 09:43:23 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAAyCAYAAADLLVz8AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALeSURBVGje 7Zq/b9NAFMdvpFMzxIElI0IyEkFMLRKqiygUiQqQSECCEFHRH7KCJRQhgxjuEirqdID/owsjbDC1 IwsSI0P+AOjEaPqinu9szj9rOw284Ssr5/Pd88fvvXtnh/T7fYLKLoSAABEgAkSAKASIABEgAkQh QASIABEgCgEiQASIAJWy7fVZQyN7hBDXJ83YW7ftWehDm3pz3Ka3doPXU3NhXiPkQO4vt9cMk5lG jYmx9dFdap6Pm5OrpZPdv/qF2FI6QB+8I+PlNr1Jm8cFWK1Wv/Hxu13jhqYZn+4t1t4FxxvPIY3h f7D6qE1p3WdLgRATd/Q8QwXGsup5eGDwOgFGQFHJm1PhlWJs7WDBpPMTA8jDg3ta7M1kARgRllHz xvXh5yFFTASg8IT4p3gsgFHXBMIzjW08eiYGkNJ2XSdkFBdKRQD0z88XBgEriW1R6eef98CwcOS2 TIUHqlbbUIAR+SwPgDIQbkvSHBhnezmrsAIMnPPKmJCQ8oVhzgAjV2GvlIlPP4UCDOYhCAe5zpKf rlzQQrv3W9NGaTxQzCnCUxTaAkiwwAfbgm1FeF9uO5FgblH2O4TjAUnhgerdhdqb1H2Lqf9wL4wA ESACLEM2Y2cQYEbdf/b2/Vx7x4UjAsyg60+drwDwSmf4EwFmEIADgCDGWAUBphAA4/BAvdfsIgJM IQAmA9zsDe4gwBQyXwyWZYCrzwebCDCFAJgM8KG1tY0AEWC5i8jVVec7L2NOakF9osuYm2vOZwC4 +GT4A+tABIgAcwPYfTUwQB1r6+Uj6w2zbDY3jQCh1gT7QfyeHMc5lTtAALSysf1RXhVlQZKHm81b fCt3+fHO7yLHV2l5zdlP4hjJ34qsLLkzhLgzjZ7baJyWXplfcM+GGDHtur3hfMjNA2+1ru2PAVaO 4FWW3AZAPTxe6gx/FeEhRas0DwT5/mJx7sGXMnJgGfvtUnKgD6Di2+v/rD/1OqBQ3G/6cgAAAABJ RU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image055.emz" Content-Description: image055.emz Content-Disposition: attachment; filename="image055.emz"; size=2894; creation-date="Wed, 10 Oct 2012 09:43:23 GMT"; modification-date="Wed, 10 Oct 2012 09:43:23 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1afVBU1xW/774HLCK6Ln5gQ5ElUBFta1qmI5XqW1TA+pGVotHmCy3mwzENqCDq kC62gxqpEv5InUkMmYxJiLGxtmbqdDTVOjXJaNVpnIkzxJRONTHTdiRTJ2kUZvv7vX139wnsuqLE dMbD/Pace+7Xufeee+5976EJIVYC3cFgEEwsAqZTsGlYihCnEoXImjWvRAhNnM0X4q/I01UBm5so 8wsoC6QQ07RrMz943iWKzhoCDYhJQBaA5iZqpiYyILsB6T7cwWqVNlj2AcAPsGy2aYihkEmZZnJY zkEbSj/ZlFZbhlUqMN1rJoXzDFOE5dHIZ510YAjgBhQlQ3ADfuAeIBdg2WFCBJxyOXTVMJg2f2rP HUSLWqgEoc/sGWIp5vdxsUyswu+XQ+bGQnH254WieuuKlDWBQnH54cQFTGeh+xNIw9zgQaQrGgvF rCvDF1Cn8pk3KXF0yh+gt4dhrQnHvvBbGJlLDk+QUhq6NIJS/D24R2A1QtRmV3COmTkzxHLxU7FG 1GIO1sGKbvT37IzkBXAl2vK3KbDDszJpwVzwwL6rC6rAaYM/YXRKVZ1wsQ019+wimuxBHteKZbi2 tl/ICsiEIjboBkLmphYvXJhazLxUWzcXPORD1EZ8wQ85C+B4ne17kWabmbae7UwASm0eza5s5NNG zrkaU28/c+rz7PK0uxyohkD5IuqDhamFStDt8r+q+kLRvS7kfzvqQv7HdBZs6kKa4+1Eun5tyP+o U/nMG2z/y0K/Tv97AGn6XzU4/W8z+ED8T62J5DgxDrAwOdbEU4FI8AT2xGrMyHzwteDl4knolmKf DA6pNckQK1IGsiZFSX1jAi39USZG5pYyUU8wEqRuBPNFp69eHFYxIWj7onPMop8xx7MmtKEScaF3 TOB8q30STaYZqsxgyNH6derj2dssf2efw6duwTkTj0/d2efXxt47+zxyh+gvXjj3czR5IPu8BPu+ Hg2uBHjfzTeFyIEuHcDVk1fyQAgROdNMUHccMc7Uw3I/dVGVZNW1pIlm+H6E+3RiuK7X0abznh1P m8779mC377TnkUkfTLEGhZ+QfOCoCFw96rThJssf2HRuVSbB9o8ntRRXft9V7DKFvh99tgN8fhmh jAAPjLtSKv78aKm48E+LW+llvyxTnHmB97aUWWWgZ9VAV0skzbp2+crjPVY9cqu9Zamz2Q7ThycZ ZSrfatPul3qhXUuNuq6PNEXAjb54vz3UeG/QC+4ClgHq7ky/I2DRDyzWS6bfjwfSAZ6lpHsbD1nc uWfSoFFtKj36CiyCvhLgsxf75+AnA5y/dUaXHGWcB7pkqyQaZBvQKsfKJotT7pJujTgv9wjyHivN OqOMHqn6SkJf/dmAbgKOMfqQtikQljlG7slKoALgnnSZmjQhFwBcbzCx2eAvqPpYCeuQFEc301W5 px+cEhxlhp47WEUD8gA1PzmQCdSJOucPI3cKwLrkJMWF1MJrMeXBp0OZ9q+aD9ZT66ZsVGVVGerV nFGeCriAuwA3sAHGJ+pCLIZcACjivZ2UCEWTYejbjKtyG9Zjm/GRbDLOyQ1Gh/we8txAOto4hcZj teExTsoU47RMMs7gYfOsFMaHwHm5BPXDY4Yc6jUYxFrDqbn+HfCPDtkOH2m3/KUV/tMqY/X1MvJ3 yxa5V26Vv5Ob5H7ZCKwP29sOW8dcx95X5FC5UxpoyZCbgaeQbpBjwm3UoP7667RRjX5Xof862LEe 9gTQWhMQa8ytyG+w/rhXOrAPOmQu9kYu9kasMedqH8ps7azM1M7IsdppmaadlKnaqbC9r2E6O65j b5s4J38lPgK6gKuyTRj6a/AOtc6pcDjPdXwlTUvTx2oj9EwtVc/WkvVcTQd6rDFP5prapNY5AWmO z60l6qMMeCLWXGDPxxorzMLbimQ9yUjVU4wRusdI09MNj86N5gKUb3vglxcxZs53DqBI9Y0skY++ 8tEn+8tTBcBVGQwXZS5IL/yQvqjmwo25UPMZrZ6BtbsiLgBdMdf8iuiRHu2i3IsW92K+PdoXqHPe qhfLriuiWxqYN86dsqsVg1L7OZpdL+Dprl12W3tK1eOeaABi9dcua+QL8jH45WMxx9OE/Ofg7e0y A56cIbdAbrPrxWp/E8o0oA/6v7KLNsEjYtrVgLFswphaAVVvFNb+evPghb/lG93W+tNHJvWz/mgG 639eeowvZB3K18EHlJ8VIc8F8DKXbsvjwH8IfBdIA9R5oOIxVAEl8zyjX4Z8M3JWQe2D2iIM/Zpz pQTpgkToAJ5hE81QHyycD5lt0Zbed6hhu1xvvb5797Ro5dEnh2FTRB688m6MsdPnbP/m762hNp33 1u+YQsvAqNzWyNxHhDgAvFiMm3lxPH27TGlwPrmO6uxHTHAX4N00daT479V97XPa4Fy/vuvBupVx 2Xxj9lQWx56vuX+6kfka+Lxca0f887J5EOYl1Gb0edkMH/oy5qWvHfHPS8g3b7R8jhn5LuMy9YRq TYgqgL4P1oeo2+KfX5o65Gu8/qfOLptZDk5MdSFGiYvvn0sG01aXlxaLN05mfIKE8ahvnk+IfdtT upfyApBcXbZkNb7JHCW0t59sr4KyY/ZMX0X9Q/8+cyQ54HfP8E39fe39iye/+nbGwYbRnhNFl65O eyv49byay3dPKH8m+PGBnL+M+2T75dJv3Ncy9M39l9bPeaa5qmpVwrv++95/9tLId8tKvkoZ43ZU e//T9NuNxzFMMXvW/JlvFFduxFliGi4Vv9V8GyzioLtM3SxAOg9gngzl/REM2FXMuIb4hPtLglgg EsDx0QppxireaXh+GFi0/4Lz/HB+b7tRX4m//O2P9YYZOSe9GLsLUJznA9NzABOYDNAtswBMlQU3 OIl6P2ACJGeaa0f0H7s7fRI55UA1GmW7Ub/ziL7fGV99r37FHmBHa6Fo8NXVjDv03JwzkIk5wbU1 u1wVueaxH6f/5puHR+N4OiJEofC+vq6maEhFbsnCDTUHUe4J8HdGram5Z97SNfQFp53N//ikbsKv Oyt+BiNHyo8xrBDK1i/KleIdsWtno08TzcP3t3WULd6Ob0HA6fHGSzsrPqs1P+15CsMJ0WmHDI1p q/1wu2bUmVD/WS3ngbQL6dKZs2dUPnS390XIRUs+r520aZ/n+WPLc5nfBV3P4s9r6atKx3n7F/SX hhk/idV3728KrIeJsfZBOrjHlqln2j7LpSoztlcZ9UwBtUW906oe26oAVgLJAP2D90UvoMYNMUzM nwu4w5rIs8di6rU3tWatRWuAoVaAhc4FsO1UgBNF2/mOMs+WOaZsW+Y6O+US6AtQIA/ofX+Mdv8a +Jne6XOeoTcWL27vXccwwz4RjhNezB3nPsPmgxsvKovpL+XAYMaLrsdvXbzIgq3c44wXryBeVD2y cg2h4oVrvKHF2rOoLkz+gPzxxoutfeMFfbufeFEVq+/bHS8YM7in6WNugDGD69+bMLSo8cKPvGYU oI9+tePC/+9d//bGhdDzQO+40GWd5Vh0m1roJCADx5zzO31//5sQ7R4hvs24wOecm79HZMEWFRfa +4kLuEe8HGtvciwmf0D+OOPCzO1xx4XlsfoeaFzgfiZGABOAMcBUINaeRnaYeG6T/NBkCfES34cP ZE+fgC8cBgb3rL+1z6nOe0K0O4nLTIjyXibyDTX+9yCYXFC0u0p0GxKj2BD5/nozNjhjjXPtnXIJ 7C4AePfjGuebkXeA9v0+gCzAeqdnyV4oeEYsA3h3hHtYZ0oVOP9vNAF8EcAXgip9P2T67wSxG7+K Iu8J7fZVRr88G1r2R7+m3bxHuQHaLc3IfQt3WTESILkByv8DqV4czNgqAAA= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image056.png" Content-Description: image056.png Content-Disposition: inline; filename="image056.png"; size=909; creation-date="Wed, 10 Oct 2012 09:43:24 GMT"; modification-date="Wed, 10 Oct 2012 09:43:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAAyCAYAAADLLVz8AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMNSURBVGje 7Zm/b9NAFMdvpEKiURWnLBGMyCAQQkIpEoobqUJIVFBoykDThl8pWMGiymBQBl9CaJwOwMbIiNSF ETa2/gVILKAOGRirDgiJJeSF2nc2jp1L7KQNb/gq8vl89/y59969c0ilUiGo/oUQECACRIAIEIUA ESACRIAoBIgAESACRCFABIgAEaCndL0wqUhkmxDSckhStgu6Pgl9jKyc7bTJS1vu5w01PSMRssf3 59sTikpVJUHZ2HJzwVBPB81paUkmW//062LL0AE64O0bz7fJWSM7KMB4PP7FGr9YVK5IkvJpcTbx yj1eZw5uDOfCys2cYSQdtkQIseeOtmd4gdG0ZBge6H6OgWFQvGTP6eGVbGxpL60aMyMDaIWH5WmB L9MPQJ+w9Js3qI91H1LESAAyTwhexYEA+j3jCk8R26zoGRlAw8glZUKaQaEUBUDn/NbGwGD1Yptf +hl7D+wWjpYth8IDvXbbrgB98lkYAHkgli295sAg24ezC3uAgXt2GdMlpBxhGDJA313YLmWC00+k AN15CMKBr7P41eULWmi3ryWpKeKBbE4WnqzQZkDcBT7Y5m6LwvtCO4m4c4tnvzYcG4iAB3qfLry9 ybtvNPUfnoURIAJEgKgDDlDTaerqQ/Pzo1L1BgLsQwAvldtszd5t7CDAPpTON34AQJBpmkcQoKAs eKBymZ5EgAICYDzA4vOqggAFBMB4gA9K1TwCFBAA4wEuay8oAhTQqlZ7xgNcVF++RYACKpXpqcur jV2Ad2ll8xfmQKwDESACPGgAdUqPR5mbhgEQztuDFOk9dYJjVH4l8+YYIb+PXljfuXh+epd98T3b OnPf/AZlRtgCcAAQNpMoxs/cM7/yOz3MB4u28HjjPVQBlNJYKADvaLV6an6uNdEGNhGb/gsuNtc6 B23wyxkxTrql1t+FArBT1O4D7MA7sTyWwNzKr9eehpYD9YJyc4qQn2Qq8/1a2yOvr5kfwN3hi8nt JxuvIRceNkEYg/3wHvNr9Y9wDdDgHtShoW4iov/d/i/6A/a1pKGPmM0sAAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image057.emz" Content-Description: image057.emz Content-Disposition: attachment; filename="image057.emz"; size=2879; creation-date="Wed, 10 Oct 2012 09:43:24 GMT"; modification-date="Wed, 10 Oct 2012 09:43:24 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1aD0xV1xk/99zL8yFDXhEUleFDcaBiYzuyQHV6Hyri/AcMjW62IqHWGrqiouIs 42nXFKydrLON3dqoTRMN/slY1q1ZNKNz/ZPNLWqbxmipNIt/2v2zYamLom+/3333vHcF3vOBUrvE j/ze+c53/n3nO9/5zrn3ogkhqoGuQCCARCwGppOxaUiCEMdcQnhnzS8SQhOnJwhxCmW6qmCnJur8 GMI8KcQ07ebCj15xi6mnDYEORC7gBdDdRM3URDp4DyA9bWfZrMIG6y4DSgDWHWMa4mvgSRlmfIjP Qh9KPtmUVl+GVcs/PdMcFCozTBHih6GcbdKAwYAHUBQPxgOUAA8A4wDWHSKE38mXQVYDhanz57bt wFrUTCEIY46ZIVbAvo+LSrEWv18OmVsLxOmnC0TNc6sTav0F4j/LXaXMezH8ceShbuAI8uVbCsSs q0mllKlyluW6hiX8DnJ7GtaacO6L7sfM3DIpTkpp6NIISPFJ4KDAagRpt93AOWeWzBCPih+IWrEe NtgELbow3ksz4kvhStTlXD70SK4eVDoPqb/1WmkVUupQEjcsoWqDcLMPZXsOEYlPRhnXinW4trZf yHLwhCJ26AGC6iYWLlqUWMiyRFs2D2nQhygN+0IJeC/A+Tr7z0SefWbYcvYzHphtp5H0GoNy6kib qzl19zOnPMeuT73LgBow5C+hPZIQNVMIulv+V1VXILo2Bf1v14ag/zHvhU6Xked8O5Cv2xj0P8pU OcsG2v+8GNfpf8uQp//VIKX/NSLtj/+pNZGcJ+aBJESONUkuRyR4AntiHSyyAOlGpGXiSchWYJ8M DKk1SRerE/qzJlMH9YwJ1PS7GZiZR0qXHmfESd0ITBAdvjrRpmJCwPZF55xFL3OOZU2oQwXiQveY QHurfRKJpxqqzkDwkcZ1ymPZ26x/b5/Dp+7AOROLT93b5zfH3nv7PHyH6C1eOPdzJL4/+7wI+74O HVYDvO9OMIXIgiwNwNWTV3J/EGE+w4xTdxwx2tRDfC9t0ZRktbW4iWbofoT7tCvUNtPRp/OeHUuf zvv2QPfv1Gdl7kf51qTwE+L91445dbjN+m8+2742g2D/X5/XXGgccxe6TaH/GmPuB/j8cp9SAql/ 9NXZ4u3HZovzf7dSK1/5fLFKWeZ/v6nYqgM5m/ovN4fzbGvXr/jzdasdU6u/ysQ57If5tlyjWJVb fdrjUi60m2mLrusppvB7MBbvt0e3LAxkInUDlYC6O9PvCGj0bSvpxtPvs4E0gGcpaeGWo1bq3DND IVF9KjnG8i+GvALgsxfH5+QnA7TfZqNTDjcuAJ1ypyQa5F5gp0yXjVZKvlMma8QFeVgwDVh5thmO pxI11iCM1ZsOGMbvmKMPeZv8IZ5z5J6sAMoB7km3qUkTfB7A9UYiGg3+gmreKWIbkkoxzHRVb9vD +YFUM/jcwSYakAMo+2SBJ9Amos2XozQfYFumJJUKqYXWIv/hbcFC+1fZg+3UuikdVV1Vh3JlM/JT ADcwCvAA9VDerQuxBHweoIj3dpILgkbDpTcb12Uz1qPZuCQbjXOy3miX30KZBxiJPk6i82h9pBgn 5BDjlIw3PpSGcQYPnB3ABbkU7UNzBh8cNRDAWgtprX87/KNdtsBHWix/eRH+86KMNtY+lB+SL8hW +bx8QzbJ38qn5W9kfUjfFug64hb67pdD5G7pwtguuQ3YgnyDHBHqYx3a19+ij7UYtxbj10GPp6DP VujVCESb806UN1h/3Cvt2AftMht7Ixt7I9qcs7UOmaWdkV7tQzlKOyVTtRMySTsZ0vcA7Nl+C333 inPyZXEJ6ASuy73CpR+Ad6h1ToLDpdzCV1K1VH2UNlT3akl6lpagZ2txQMCa82TooEitcxwEnF+y 5taHG268heiEXwSizlUacbphJOjxRpI+xBiqpxip+kgjRedGcwPKt1Phl59hzrR3FqBIjY0iMQlj TcKYtG2OqoBU1cF0UeeiHAt/H+7w+WTYQtkzUjsX1q5LXAQ6o655lwjIFO0z2YoeW2HvFK0LbS5Y 7aLp1SVuSBfsRtupNdqJSan9HEmvPdKtt8gb1p5S7bgnGoBo47XIdXKPXA2/XB11Po0ofxXe3iIz 4MkZcjv4vXa7aP03oU4DxqD/K72oU+ct9GrAXJowp52Aajcca38rO4yFv00ybljrTx/J7WX90Q3W /4JMNbpkHerXwQeUn01FmRvgZS7N5kcj/Q7wTWAooM4DFY8h8iue5xn9Muib4bMKYh/EFmHqN50r RcjnuSADeIZNNINjsPIE8OyLuoTuTQ7+V13/mhapPsbkNGwK8wNX34s5dvic/d/+vTXYp/Pe+qAp tHTMymPNzPuWEG8CewpxMy+MZWy3KQ3ak+uozn7EBE8e3k1TRor9Xt1TP6cOzvXruR5suyomnfum z6rC6PYq/0Nf7NV/u9ysR+x2aR4AuwT7jGyXZvjQl2GXnnrEbpegb/a1fpYZ/i7jNvW4Gk2IKoC+ j6QHUdZUsmB24uCRvP4nzimeWYa0FJjiRowSesdKFmjrymYXisN/Tf8UGeMx33yfEK07ErpW8AIQ X1O8dB2+yRwjtHef3F8F4Zk5M33ldY/884PWRL/p0X0P7Vv/w/z0Q9/wdv2s+pNNH1+pfyrwUElH R3bZa8mBv9S8vWv6yd2XFh4/6B1adf7s+Z8kv/zeH48PftB3/0uHPs75adO8r1LBtM3P/Cn14mYP ZynmzFow83BhxVawbtNwq/it7G2wjoNGmbqZh3wOwDIZLPs9EuC1QsY1xCdQHBaBxsVHK/wyVvFO w/PDwKL9FynPD+f3tr76Suz1Gbvubqw3zPA5mYm5uwGV8nxgfi5gApMBWs4LaDY8SEmUlwAmQHLm uXZE77G7wydRUgZwT7HfiN95RM/vjPver1t9ENj1QoGo921YM/roL+Z+AJ6YG9i45nV3+bi2HWVp Je8eGQbN3xKiQGQe2LRm6uDycUWLNq85gnpPIH0vtXbNA/NX1NIXnHpu/9unG8Yf6ijnfStFXsS0 gjixdfG4wSJPW4JNrIntSct3ny1esgPfgoB/DzGWv1r+xXrz8+s/wnSCdMLBQ2La4hK43Xa0GV/3 xXragfQ68rNnzplR8cjYzD3gpy69sj732dbkV955dBzLL0N2fcmV9fRVJaPd/gG5O9u4Gm3s7t8U 2A6GsfZBGtJkm6ecefssl6rOiG511DMFxBZ1z6t27KscqAYY9+gf04BMQM0bbIhYPg/whCThZ48l lGtvaNu1Zq0eiloBFjI3EA8kAjQUdec7yhyb55zG2DzX2ckXQZ6HCjlA9/tjpPtX/8/0Dp/zDO1b vLi7dx3DDPlEKE5kwna0fbqdDmy8WFVIfykDBjJeTH68Da57Z+KFF7pyjzNefA/OWrWyupZQ8eJE tvHzaHsWzYXJH1BJrPHiuZ7xgr7dS7y4Fm3sux0vGDO4v8cC9wF8GOP6dydMLWK8KEHZdlSgj361 48L/713/7saF4PNA97gQ8X8TcMw5v9P39r8Jke4Rv5zEuMDnnNu/R3jpl3ZcWNZLXMA9ojLa3kTz PseFmTtijgtd0cbub1zgfiaSgYlAGsD3RtH2NIpDxHObVAKJFxd7vg/vz54+jnjQBgzsWX9nn1Od 94RIdxK3GRfhvUz4G2rs70FgXFCku0pkHVwRdAh/f70dHZyxxrn2Tr4IeucBvPtxjSeY4XeA9v3e jyLAeqdn8ZkQ8IyoBHh3hHtYZ0oVUv7faBzSxQDPIJX/PvgpwHjRgl9F4feEdv+qoNd0DKQcj35N vXmP8gDUW5rh+xbusiIFIHkA8v8DGe4NGNgqAAA= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image058.png" Content-Description: image058.png Content-Disposition: inline; filename="image058.png"; size=897; creation-date="Wed, 10 Oct 2012 09:43:24 GMT"; modification-date="Wed, 10 Oct 2012 09:43:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAAyCAYAAADLLVz8AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMBSURBVGje 7Zq/b9NAFMdvJGJIhriwRGJBQh4axhYJxUJEUIkKELggQWhV9RdWsIQiZFAGX0LauF0YGRmRusAG G1uZ2JD4AzIwok5MlekLOftszrHPcZq2vOE79HK5e+/j9969c0parRZBpRdCQIAIEAEiQBQCRIAI EAGiECACRIAIEIUAESACRICRsqy1vKaQPUKIG5Ci7a1ZVh7m2Lqq98fUhd3w922jMqsQsh+YPxib 0gxqaFPUX1ft1Wy7lGRPpgWV7P4zL8KWIwcYcGRgPD+m6rY+CsBisfidrV2vazcURfsMczyo3Hr9 Pbg1gpD/gg/YMiaIUpNFjngOmWZp1AgUfccH40MRydtTEJX++sp+xbBnJwaQpQeLtFhnZAEKnE+6 b9wc9jmUiYkA9CMh/immBhiRYoEIFURiEttY9kwMoG3XSiohvbhUGgfA4P7sYPBhJbFtWPk59REY lY7MlhMRgaLTNhLgkJqWBUAeCLMlaQ2Ms/1oTmEBGPjMa2MiUiqQhhkDHHoKe61MfPkZK8BwHYJ0 4Pss/unyDS2Me38rSk8mAv09/fT0m20fSLjZBtvCY1lHX6Y3kXBtEc47BOQBkYhA8e1CHE3iudn3 f3gXRoAIEAGijjlASmlh+Xl7o9GklxBgCj0yO92Z2o5bWdr+iQBTaH69+wkAgixKzyNASV1bdn4w gKZFZxCgpK482fnNAK68aD9EgDI3nsOUZfBAi2bnJQKUEKQsD/DBs603CFBCG432HR7g7XXnAwIc IQLvG5tvEaCk7j7des8AYh+YQveM7jsEiAARYGYAoTerv2prK4320mPzNYUaNbfqfBlXjzZugHBQ wXURfAB/wA/wr9GklzMFCBvBhZ4/Ff8HAdRMAMKT6S86X3VzhLi5csMtl89xvzlMuxdPIUC4i2cC EN7LwU1gTr/+7SwhB7nCAF6h6pYBar56cMvsdOGJnSTdXHW+hqFdXdz+BSkNjXuSFxhSNSP4X1T6 R6gXoGaTXjjOh1GUHMc5w3xI+9L2DyyvodmCj9tvAAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image059.emz" Content-Description: image059.emz Content-Disposition: attachment; filename="image059.emz"; size=2852; creation-date="Wed, 10 Oct 2012 09:43:25 GMT"; modification-date="Wed, 10 Oct 2012 09:43:25 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1aDUyV1xk+3/k+4CJDrxSEqcML4kDEzjZkEcfqByLg/CkwdJr1Bwm1m8EVFBTr HBdnWrAY6UaXdqsRlyYa2tqQzK3ZdLP7sbY2s5kNtbELrE2zNmypZla6Fr17nu9+596Pn3v5UWqX 9E0e3ve85+8973nPe869F00IUQ0M+Hw+MLEOuIuCTVNjhDgXKYRn+epCITRxIVOIv6FOVw1sbqLN XiizJfprgyvfftolci8YAgOILMADYLgFmqmJ2ZDdgHSfushuFTbY9h6gBGDbVNMQX4JMSjajA3Ia xlD6Raa0xjKsVt6lKWZUoM4wRUCegXr2SQKmAG5AUTQEN1AC3AHMA9h2qhBep1wGXQ0Mps2Xbd9B tKiNShDmTF0mNsK/3xeVYiv+fjZk7skRF36cI2oe2xxT580RV+6PLGXZg+lfQxnm+k6gXN6UI5Z/ Mq2UOlXPuqzIGTG/hd5ehrUnXPva27Eyl5wWIaU0dGn4pPiH7zmB3fDTIbuDc82sWSYeED8QdaIe PtgJKwYw38+WRZcilGhLz2LYEVcdVboK3Nv1aWkVOG0oiZgRU7VduDiG8j2nCCXHoY57xTbcWzsu ZDlkQhEHdAN+c2Pz166NzWddrK1bBe6PIWqDsVAC2QNwvc7xU1DmmMm2nuPMB4psHsquVNTTRvpc rWlonDn1GXZ72l0G1ECg/D76gwWojUrQrYq/qoYcMbDTH39PbvfHH8se2HQJZa63F+WGHf74o07V s26y48+DeZ3xdw/KjL8acMZfM/hE4k/tieQ6sQ6wADn2JK4cmWALzsQ2eGQN+A7wMvEQdBtxTiaH 1J7MFptjJrInuVHDcwIt/XYyVuaWMlKPMCKkbvgyRW9egzilcoLPjkXnmsUIax7LntCGCuSFoTmB /lbnJJRMM1SbyZBDzevUj+Vss/0X5xwxdRPumbHE1BfnfHDu/eKcB98QI+UL53kOJU/knBfi3Ddg wGqA791MU4g06JIAPD2X8o8fQTnZjFBvHDHH1APyCH3RlWT1taQFZuB9hPd0ZKBvimNM5zt7LGM6 39uTPb7Tnk1Zby+2FoU/Ttlpww22f/HRv29NJjj+V1a15ce8F5nvMoX+K8x5FODnl+nKCHDvnE+K xF8eLBLv9VncKlfuL1acdd7zLcVWG+jZ1XupLVhmX7t9xdlrVj9ya7zK2BUch+VTWUaxqrfGtOel XmiDqUnX9XhTeN2Yi+/bk013+1LAXUAloN7OjDsCFn3TYkNkxn06kATwLiXd3XTS4s4zcxs0akyl x1zeddBXAPzsxfm5+EUA/bfL6JOJRg/QJ9sl0SAPA+0yXjZbnHKfjNOIHnlMkPdbZfZJNPqlmisK c41kA6bxOtaYh7JN3oDMNfJMVgDlAM+ky9SkCTkb4H6DiWaDf0E1pwvZh6Q4plmq2u27d7EvwfR/ 7mAXDcgAlH/SIBPoE9Ln96N2McC+5CTFhdQCe7H43n3+Svuv8gf7qX1TNqq2qg31ymeUvwG4gFmA G9hN43Uh1oNlA4r4bidFQtGMT4ZtxlWgD+iVzcabcrfRLb+OOjcwE2O8isHDjRFvvCKnGmdltHFO GsZ5fOB8C+iRG9A/sGbI/ll9Puy1kNb+dyM+umUnYqTTipf9iJ/9MtxcR1D/vNwnu+Qj8rhskr+R u+SvZX3A3k7YOn0Ue4/KKHlI+rR2YB/QhHKjnB4YYxv6148yxlbMW4f5G2DHD2HPHtjVDIRbczvq G9Gj0Tor3TgH3TIdZyMdZyPcmtO1t2Sadl56tHNylnZWJmivyGnaqwF7n4U/u0ex97B4Uz4leoE+ 4Ko8LHwS/XS1z9MQcLGjxEqCFqvP0mJ0jxalp2m6nq5dh+391poXwQZFap8joOD64jShJxoC30L0 IS76w65VGtcRQ7oebUTpU40YPd6I1WcCPGguQMV2AuLyHayZ/k4DFKm5USUWYq6FmJO+zVANwFUb LBdteuRcxHuiI+Zhb8CfofpFYu8GRA/QF3bPB0S/jNfekV0YsQv+jteuBPqFs4v9IuE3+k7tUTsX Ze9RKLs6pNA7Zb91plQ/ngm+V8LN1ymrZYesxHmsDLueZtQflA9j/ETEcaJshXzY7hdu/Ba0acQc jH9lVyNs6hvFrkaspQVrwtoDfkAsjeqHuYg3tf+MkSxAkdp/DsP9TzCuyAa0b0AMqDjLRZ0L4GMu yZaTwb8F3AncBqj7QOVjqLxK5n3GuPTHpjcPok1BGUsfdK8UopwdCR3AO2yB6Z+DHTMhcyza4nw3 OeVQ7Xm3oZtNQXny2nuw3t485/g3/m71j+l8t95pCm02VuW2VuZ5SYgXgY58Ib6XP5a5XaY06E/u o7r7cbzc2fhumjrS2N/Vw+1z2uDcv+H7wb5VY7J5fPZU5Yf3V8kfx+OviftlsB1j90vbJPjFP2Zo v7Qhhj4Lvwy3Y+x+8cfmeNunmcHfZVymHlGjIeoAxj7YMKKupWRNUeyUmXz+x64oLigDLwWWuJCj xJkTx18A07aVFeWLY3+d/QEKxoN5q/OE6DoQM7CRD4DomuIN2/CbzJ8I7eWHjlZBeXFFQV55w33/ fqMrdm+Je1nekiMf9W2srXn4595LL1TFnPvP7z9899NuPMuWPh73xMdbHllweqDlekFj5aaIpzwL em7f0X6m4Kub1rVFb+2q/qiwZVXV56Xiz75Fl6MW7itt3vm7961PBiuWryk4ll+xB3eJabhU/lb+ NuAJJ80ydTMbigyAddJf+Qcw4Jf5zGvIT6AIbAKdu1Sk4i9zFe803h8GNu1jcN4fzt/bxhsrY2/P 3HVrc71hBu/JFKzdBSjO+4HllYAJLALoOQ+g2XCDk6gvAdRl6Sxz74iRc3dvHveqDOCZ4rghf+cR w39nPHK+YfNzwJM/yRG787bXzjn5i5VvQCZW+nbUPuMqn9chDie1fe3UDFj+khA5IuXZnbW5U8rn Fa7dVXsC7baAn0moq71j9cY6xoLTztZ3P9g+//necr634uU/sSw/vLvWzZOiQ/MebMrTROu0KYcu Fq8/gN+CAFe6cfVg+dV68/K1H2E5fnrdIUOj/FSCsGtFn/kNV/mxyaJnUC4qWLGs4r65KR2Qczf0 12c92hX39OkH5rHBJeiure+vZ6wqHf32L+hfTzd+Gm7uob8psB8cY52DJPA4W6aeZfsul6rNl4e0 UZ8poLZoaFn141jlQDXAhMj4uAtIAdS6IQaI9asAd0AT/OyxnnrtuNaqtWm7YaiVYKFzAdFALEBH 0XZ+R5lhy1xTqi1zn51yIfTZaJABDH0/hnp/TfxO781z3qHjyxe39q1jmIGYCOSJFPiOvp9t88nN F1X5jJcyYDLzxaWKm5cvPLCVZ5z5Yg/yRdWm6jpC5YsPpxrfCXdm0X38+eKx4fmCsT1CvmgPN/et zhfMGTzfPKvTAeYM7v9QwtJC5osS1LWiAWP0850X/n/f+rc2L/g/DwzNCyH/NwHXnPN3+pH+NyHU O6Lk5RO40vg558bfER7GpZ0X9o6QF/CO+G+4s4nu484LBQfGnBeeCDf3RPMCzzMRB2QCSUAuEO5M ozpAvLdJJdB48LDn9+ETOdOvIR+cAib3rr+5n1Od74RQbxKXGRHie5ngb6hj/x4EzgWFequEtiEy hA3B319vxAZnrnHuvVMuhN3ZAN9+3ONMM/gdoP2+96IK8PIpbskpEHhHVAJ8OyI8rDulCpz/NxoB vg7gHaTK34W8BJgvOvFXkTWmXXDKqn4wT0WR8zGuaTffUW6Adksz+N7CW1bEAyQ3QPl/Wjjmxdgq AAA= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image060.png" Content-Description: image060.png Content-Disposition: inline; filename="image060.png"; size=863; creation-date="Wed, 10 Oct 2012 09:43:25 GMT"; modification-date="Wed, 10 Oct 2012 09:43:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAAyCAYAAADLLVz8AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALfSURBVGje 7Zq/b9NAFMdvpFMyxIUlEgui8tAwpkhVvIQfA7+EUiFBIEMJYEUWKEIWyuBLqKjbf6IjUhdWNpCQ urLwH2RgRJ0QAzJ9Iee7c8+xL7UdBd7wHXJ+uXv3yXvv3lkhw+GQoOYXQkCACBABIkAUAkSACBAB ohAgAkSACBCFABEgAkSAsXLdbskyyBEhJJBkWEdd1y2BjdcyW5Mxc+sw+n3PbmwYhBxL9tOxVcum trVK+bzmuO151TRrMm2Z5PCUXYwvhQOUNjJ1XhwzW17rLAArlco3NnevZ103DOsj2IRQhfkmawhz yJD/gpd8yQmilrFqI+GGHKd61ghUfYeD4VBUCtdURCWf3zhu2N7GwgCy9GCRlrgZXYCKzaddN8mG PYcysRCAPBKSf8W5AcakmBShikhM4xvLnoUB9Lx21SRknJRKeQCU12cHA4eVxrdZ5eefj8C4dGS+ LEUEqk7bWIAzaloWAEUgzJe0NTDJ92JOYQUYeBa2MTEpJaVhxgBnnsJhK5NcfnIFGK1DkA5inyX+ umJDC+PhZ8MY60QgX5OnJ2+2OZBosw2+Rceyjr5MbyLR2qK0OwEUAtGIQPXtQh1Natvs+z+8CyNA BIgAi5BL6QUEOKc6r3Ze1tv7wZ1n/gcEOIcAHAAEUUrLCFBT17b9rwxgf0CvIEBNbT7Z+8EAPu+P 7iJADUHKMnggqIcIUEMnKbsmAnzo7OwiQJ0XF69HN0SA9168e48AEWBx8n3/3M2n/ifhFF5DgJq6 b+8eMIDYSCNABJgZQMel9d6bkQW92SPnLYWCv4wABwN6Efxne4A96V4ZU/dkcC+9+nj/p3gyMsE4 FPys1ejsfWdr5D1/VHCN3O6POpkAZG9F6reawQohwUqtH9Rq54VX5uvBpRhHllkAMdsIvN38NQFY nsIrN4MaQC01f292/S95REmeKiwCmaS/WFx+8DnvGpi3CquBpwDG/Anof9QfKA6gFMAD/yAAAAAA SUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image061.emz" Content-Description: image061.emz Content-Disposition: attachment; filename="image061.emz"; size=2850; creation-date="Wed, 10 Oct 2012 09:43:25 GMT"; modification-date="Wed, 10 Oct 2012 09:43:25 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1afUyV5xU/73tf4Cqit1exOB0ChYloNtzIKtHVF1TA+XVhaDFtLRJsM6srqCDW 0F518aPaSYnpTGrVLG61ztW4aWYWrbg2dQ41zUpbE9tMsj9aq1ZbLa1Wd/f7vfd9Lq/AvV5Rapd4 kh/nPN/nOc95znPuvWgiMh+4FggEvgBmQp4OKOobL7I5TiRl4tQCEU1OZon8C40u1cHmZqzIr1GZ o4s8pN3Y+OFmt4w9aQgmkJFACoDpRmimJkMgewDd03SKw8ptsO+jgA9g3zTTkD6QSclmr5CcjjlU fbapW3MZVi//uFQzLtRmmBKSB6KdY5KA3oAHUNQLggfwAQ8CGQD79hXxO+US1FVBYer8OewGFqIG VoKwZtp4mQP7/lIqZCH+fjtkrsiVkytzpWrdvPjF/ly5/HhsMcspWP4YylA3cADl0uW5MvFqv2LW qXa2jYwdGP831NvbsM6Ee5/xQ+zMrfeL0XXdcOlGQJfWwC7BaQRpqz3AuWe2jJe58itZLDWwwVJo cQ3rvTS+VzFcibr8ezT08M6PK54C7t/zTXElOHXwxQyMr6wVN+dQtucS4WQv2nhW7MOztf1CL4VM KOKEHiCobkL+jBkJ+WxLsOumgAd9iLXtvuCDnAJwv875U1HmnMl2PedhudDm4fRKQzt1pM3Vnjr6 mbM+0+5PvUuAKgiUP8F4sBA1sBJ0t/yvsi5Xri0N+t+m2qD/sZwCnS6izP2eRrluSdD/WKfa2dbT /peCdZ3+9yjK9L8qcPrfGvDu+J86E537xD7AQuQ4E28pIsEC3IlFsMg08CXgJfI06ubgnvQMqTMZ IvPiu3MmY+M6xwRq+otk7Myj67GuGCNGdxmBLDmdVydNKiYEbF907lm62HM0Z0IdyhEXOsYE2lvd k3Ay1VB9ekIOt66zPpq7zf737jl86g68M9H41L17fmPsvXfP23OIruKF8z6Hk7tzzwtw7+sw4XyA +W6WKZKOuiQAqec4/gmiXU42Y1SOI0NNV0juYiyGkqyxljTCDOVHyKdjQ2NTHXM68+xo5nTm2z09 v1OfJ0Z+ONraFP4E5f1vsuzU4Tb771/90cJkgvM3xzXkX1m3ZpzbFNderLMD4OeX+7ioouFXC+XE k4Xy2dkgZ7nihSJRHG3l764tsvqwHrTtYkN7mWPt/uY/r1vjLM75KhImcR6Wm0YZRardmstel/Wi 3UjLXS7XAFP8HqzF/Pbg8umBVHA3UAGo3Jl+R8BffmaxDjL9fhiQBPAtJU1fftDizjvTHzVqTlWP tfwzUV8O8LMXiZvvB9B+S41WSTRagFZp1IkFshVo1HvLKotTbhWPRrTILiE/b5U5JtE4H3rn8bHV 35UOWMbv2GMeyjb5QzL3yDtZDpQCvJNuU9NNyDkAzxtM1hj8C6p6u4BjSIpjmXGq3/OPjQ4kmsHP HRyiAZmAsk86ZAJjwtr8cbSOBjiWnKS46FroLEY/9nyw0f6rbM9x6tyUjqqv6sN6ZTPKYwA3MBjw AMugfBt4GZADKGLeTopFxSrjS/mNcRZoBd5H+TjGHZOfos0DJGGOQ+CR5vAahyTeaJI44y3RjaNw 2BNAi8zCuNCeIQdXDQRw1mjn+TfDP5plB3xkh+UvK+E/KyOu9Xu079T9sltfJn/Rl8hevRp4KqTv DhiC80fS9w/6tcAr+uVAI7AGeBblej0uNEc15njqJnNUYd2FWL8WejwDffzQaxUQac+NaK/HPuut u9KMe9AsGbgbGbgbkfTN0E5ImnZUkrW3ZJDWJP21Q5IAqDN6Dboeu4m+W+W4/FbeB1qBs7JVvpTX 4B1qjgQ4HNwyoh79NZc2CGEqWbsOfa5A70vAeWvP2VhfkTrnGFRwfx6tDWfdZp254M5H2qsYl+BD V+BL1+FTmuY1XFqSoWu8aG5A+bYXfnkSZdo7HVCk1uZ9yMJaWfAzrpepOoCrPi6rz3uSCj+kLypb eGCHZrRFGmfg7K7Ke0BrxDO/KufFq52U3Tih3bC3V/sUY1qscZHmvyrnxIDdaDulVyM2BStG1GuL 3oa7dM66U2oc78SCm4zboc+RLXoZ7mNZxP2sQvvLehXm7wM/7iNrIW+1x0Xaz2r0qcca9H+lVz30 ar2JXvXYy2rsqRFQ4xJx9jezQyr8Lcs4Z50/fWQkoEidP6ZBe4t4jU+lFv1rEfeUn41FmxtgMpdk y//FwJ9D9gIq7sJVQm8YRL+KzYhBUb1bmRik3pUCyDmx8FWAb9gIM9iGasmCTD+nLh1zqL7b3W8c +WJlXrj+UIXbsCkofx14blzP9ffkiWTnO+e//bw1OKczb/2xKdoQ7Mpj7cxzWGQ/sC0fmXlUa7tN 3aA9aX/19iMmeHLw3TTrSNHn1Z31c+7feX6dz4NjN0al863pszE/sr1K/34r9uq+XW7UI3q7rOkB uwTnDG+XNfChb8MunfWI3i4i3bm/6Wb77zJu0xVTpYlUAvR9sE7EurW+aYUJvb/H9D9hUtGEEnBi jBsxSj754KNeYNqiksJ8ef3EkDMoGE/mTc0T2bMh/tocJgC9qopmLcJvMm8S2pGnd1Si8tSkCXml dbPPtxzu5fd5xueN+WvNI2XZrx4ZcqB+oPfY2AvfPPRG4PuZ1ZcfGF7yYuDj/enHh57ZcLnwBw83 9Nm398Izk19cX1m5MOao7+EPXrow4GhRwXepYeimqtRLq/68ggmETJo4bcLr+eUr8JaYhlvFb2Vv vj9OGmy6zBxUZAJs04ONTL+B7fmMa4hPyF8GSLEMAJ8uaSgzVvFN4/th4NC+Buf74fy9red86+7H esNsfydTsXc3oDjfB5YnAyaQDdAtUwCYyoIHnJQI+GyA3VDm2RFdx+7sfJ5VCVCFSTlv2N95pPPv jK++WzdvF7CpMVfq82qrhx58eXILZGJyYEn1dndphn+nfv+2uU0D8TwdFsmV1D8urR7buzSjYMay 6gPotwD8H4mLq0dNnbOYvuDUc/1/ztQO/9Pp0ueg5AD9Y2w/iHL/zIze4pcHcbs1Wd9v35ZTRWUb 8FsQ8M4wY8MrpW015ufXn8V2gvSOQ0aNz64GN9ZjzPC6thragbQd5cIJk8aXz34gdRvksbO+qhm5 eo9389tzM9h+EXXXy76qoa+qOtrtHOov9DV8kdau7OJ3RhjGugdJ4F5b5nws22+5rvoM6tBnMMoe QFHHshrHuUqB+QDjHv2F+eIoQO0bYohgaJkCeEI17Z89yliv7dPWaw1aPRS1Aizq3ADnTgBoKOrO 7ygzbZl7SrNlnrNTLkB9DjpkAh3zx3D5V/ff9Owbcovo48vdz3UMM+QToTiRCtvR9kNs3rPxYuO3 Ei+qKu5cvEiBXXjHGS9y4ayVT8xfTKh44R5mfBbpzmL4rceLdZ3jBX27i3hRHGntux0vGDN4p38C eIDpQFfxAlsLGy98aFuPDvTR73Zc+P/N9e9uXAh+HqBflAAqj7hoveWosKmBTgIy8Mw5f6fv6n8T wuURDT9iXODnnNvPI1Kgi4oLY7qIC8gjGiPdTe7Fxz8gX5R5xIQNUceFkkhrdzcu8D4T9wFjgPuB qUCkO43mEPHdJvlQkyLyO35f3Z07fQy+0AT07Ft/Zz+nOvOEcDmJ24wJ871M+2+o0X8PAuOCnJ/3 o9MhNowO7b+/3o4OzljjPHunXAC9cwDmfjzjLLP9O0A7v/ejCbC+07PkVFTwjagAmDvCPaw3pRK8 4/+NqvIjaJsNDJed+Kuo83eGqqUrnoZKrke/pt7MozwA9dbN9nwLuSw+uQbJY8v/A4dgjdnYKgAA --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image062.png" Content-Description: image062.png Content-Disposition: inline; filename="image062.png"; size=842; creation-date="Wed, 10 Oct 2012 09:43:26 GMT"; modification-date="Wed, 10 Oct 2012 09:43:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAA3CAYAAACb4M1PAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAALKSURBVHja 7Ze/b9NAFMdvZOsSZ4vEiMzC2CKhugxQBiQqNWWA0B9qS7GCRRUhgzKcY9LW7QAjfwJS/wHY2NqR pVJHhvwBqBNj4VWc72wc29fYTdJ8h+/gu/Pdu8+99+4d63Q6bFS18Gr3y3Tj4Hx+IzgeVRtHFh5p bnX/JwEkAeAlJOCR2m3vJgBqiICpAJvvfQsANUTAVIDrLX8FADVEwFSAz50PHgBqaNnpvlMBLto7 nwFQQ47rTd9b3v9F8O6+OPi91fKfAKCmHm0E3wkglTMoYwAQAEsB2Gp7d8YZ4KD25x64tu1vUSlB myJRYhc35P214JT6ipZ4ytFlUsb8D9aDH+pNL/b2zOnurWx33wRBcKMQgE9f735SF5oU5Smdcnvf JALMU7zr5Ipb9LwS7v/45d5XcncKLzop6hs3UWSR/SJ0xd7st/583tw40rfwOAgQABAAARAAIQAE QAAEQAgAARAAARACQAC8rgBdd3PKMtgRY+w8IsM62nTdKRrD62b9os1cOoz/z+3ZGYOxM3W82l61 bM+2qp6c2+wtcPt21ppCSyY7/G9cH1uuHGAE3j/j1TazzuuDAqxUKidi/mbTemgY1rfFuerH+HwX ayhzRA/W7DU4r0VsKRFi7oGhZySBcZxaER4Y/0+CkVCSFK6Z4JVybuNs1uYzQwMowkN4WuZmLgMw JSzT1s0aI/opRQwFoPSE7FMcCGDaP7Hw1LFNRM/QAHLeqJmM9bJCqQyA0fXFxSBh5bEtLf1cew/s F47ClrHwwKTbti/AlHxWBEAViLAlbw7Msv1qbuEEMNQXljF9QioShgUDTL2Fw1ImO/2UCjCehygc 1DpLPV21oKX28NswejoeKNeU4SkLbQkkXuCTbfG2MryvsJdIPLckjvsLJwSi4YHJr4tkb0oeW079 h7cwAAIgAEIACIAACIAACAEgAALgpOoP7lkQhQVx2hQAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image063.emz" Content-Description: image063.emz Content-Disposition: attachment; filename="image063.emz"; size=2873; creation-date="Wed, 10 Oct 2012 09:43:26 GMT"; modification-date="Wed, 10 Oct 2012 09:43:26 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1afVBU1xW/7+4DFunqiqLYMAgIIyLNGIfpQErjW0DA+gUEHZ2oQQaT1iEVVBDr YNa09RMr5Y82baLYDm1oYuM4TWecjhrTpGnVTE3VIaaxA00mkzikjWkdyfiR7e/39t3dx8euC0pM Z3Jmfpxzz/06595z7z27iyaEqAVu+nw+MLEUeIiCRWPjhDgbLUTK3IXFQmjiYpYQ51DnUA0sbqDN D6DMkeiv9a+89KxT5F/UBQYQ2UAKgOFmaoYmkiC7Aek++Q67VVlg2xVAGcC2aYYuvgKZlGzEBuR0 jKH0swxpjqWbrbxzUo2YQJ1uiIA8CfXskwiMAdyAolgIbqAMeADIANh2rBBeu1wBXR0Mps2fWGsH 0aRWKkGYM61QrMb6fkdUi/X4+/mQ8VSeuPj9PFG3Z23cRm+euPpodDnLKZj+DZRhru8YypXb8sTc 6+PKqVP1rMuOnhT3B+gtN8w9oe9L7odnTjkuSkqpO6Tuk+KfvkMCu+GndquD3WfWFIo14rtio2jA GmyGFTcx308KY8sRSrSlOxd2xNfGlC8A9x65UV4DThvKoibF1TQKJ8dQa88pQsnxqONesQ331ooL WQmZUMQB3YDfXFfBkiWuAta5LN0CcH8MURuMhTLIKQD9tY+fijLHTLb0HGcGUGLxUHaloZ42cs2V TwPjzK7PtNrT7gqgDgLlD9EfLECtVILuVfzVNOWJm5v98fd0oz/+WE6BTVdQpr89KDdt8scfdaqe daMdfymY1x5/K1Bm/NWBM/52go8k/tSeSPoJP8ACZNuT+ErcBE/gTGzAiiwC3wReIdZBtxrnZHRI 7UmSWBs3kj3Jjxl8J9DSh5PhmVvKaEeUHiUdui9L9HiaxEl1J/isWLT7LIbwOZI9oQ1VuBcG3glc b3VOQsk0Q7UZDTnUvHZ9JGeb7b8854ipu/DORBJTX57z/nfvl+c8mEMMdV/Yz3MoeSTnvBjnvgkD 1gLMd7MMIdKhSwSQes7hHz+CcrIRpXIcMdVwBOQh+qIryexrSjONQH6EfDo60DfVNqY9z45kTHu+ Pdrj2+15LPtSrukU/vjlo6+ybLfhDtsf3fGP9ckExz8T01oQ9350gdMQjpcwTyfAzy/jOalF3qnX S8SfHi8R7/ea3CxX7y1VnHXe87tKzTbQs5v3SmuwzL5W+6ozt8x+5OZ41a55HIflk9l6qao3x7Tm pV5o/Wmbw+GYaAivG3Mxvz2+bbEvFdwJVAMqd2bcEbDomyYbIDPupwOJAN9S0uJtx01uPzMToFFj Kj3m8i6FvgrgZy/OT+dnAVy/zXqvTNC7gV7ZJokm2Q60yYlyu8kp90q3RnTLQ4K8zyyzT4LeJ9Vc MZhrKBswjdfmowdli7wBmT7yTFYBlQDPpNPQpAE5B+B+g4mdOv+C6l4vZh+S4phmjmq3e2WuL8Hw f+5gFw3IBNT6pEMm0Cfkmj+K2lyAfclJigupBfYid+Vuf6X1V60H+6l9UzaqtqoN9WrNKH8DcAL3 AW5gC413CLEMLAdQxLydFA3Fdnwy/JF+DegFeuR2/S25Re+SX0edG0jEGKcxeLgx4vVTMk4/I2P0 s/iweV4K/W2gWy5H/4DPkP2z+nzYawQ1978L8dElOxEjnWa87EX87JXh5voV6p+Xu+VhRNjv5Db5 ktwCNATs7YSt429j769ljNwvfVobsBPYinKzHB8Yox79G24zRh3mXY/5G2HH92CPF3ZtB8L53Ib6 ZvjZbJ6VLpyDLpmBs5GBsxHO5wztbZmmnZfJ2lk5RTsjJ2inpEs7HbD3N1jOrtvY2y7ekj8VPUAv cE22C59EP4faZxcCznWbWJmguRxTtDhHshbjSNMcjgztM9jeZ/o8i3tqkdrnKJTpn1sTjgQdkYg9 Fzjz4XwV+mf8wsIRo8c44vQ4R7zuciQCPGhOQMV2POLyXfjM9U4HFKm5USWyMFcW5uR8maoBuGoD d9GmW6YiDhmLai1gb2A9Q/XTsXfXRTfQG3bPr4s+Ga+9Kw9jxMNY73jtaqBfOLvYT8e6ce2UXW10 ytqjUHYdkMLRKfvMM6X68UwwXwk3X6eslQdkNc5jdVh/tqP+GUR8p5yMOJ4sd0Fut/qFG38H2jRj Dsa/sqsZNiEiwtrVDF92wCf4HlgHxNJt1yEV8ab2nzGSDShS+89huP/x+lXZiPaNiAEVZ/mocwJM 5hItORn8W8BsYAKg3gN1H0PlVTLfM8alPzaDbxXUHqhNguv93pVilHOioQP4hs00/HOwcRZkjkVb BuZQYzucJ6AOmUNhTrphUVAONf6dt3fDxx6Pffw7z1v9Y9rz1tmG0JLgldv0zP2KEEeBgwVCfLsg krmdhtS5ntxH9fbjeLlz8N00daTI8+rB9tltsO/f4PVl35qIbB6ePTUF4der7I/DWa+Rr0t/OyJf l52jsC7+MUOvy07E0OexLoPtiHxd/LE53PbpRvB3GafhiKrTEHUAYx9sEFG3q2xRiWvMV5n+u+aV FlWAEw86cUeJaXvGHgLTNlSUFIgX/5p0GQX9cc9CjxBH9sXdXM0EILaudPkG/CbzKqH9eV1nDZSX 5hV5KptW/evCkdjXytyFnk3/7jr8w6iZuckTcm9kly7777GPb3x6YtPB1/62r6N07tb299pynuyY c27qz1Z4Zl84d6L3a3Nnt/34VEJ64cqVj5x4OH3alC9KxX9ebrmpTf/5c38vOv1CPvwU8+YuKnqx oOop4TR0p7q/1XrrbGGj+wyHkYNyJsA66a97GQzoKOC9hvsJ+UuUKBdR4HNEGsq8q/im8f1AziA+ Bef7Yf+9bbixEnn7e3/X60bwnUyF705A8SSrPB/cAGYBDMsUAEtlwg1Oor4MUI+lvcy9I4a+u3s8 3KsKoA6DctyQv/OIwb8zPne+ae0h4Om2PNHsaayfevyZ+RcgE/N9m+o7nJUZPdovEo37T07C8/SK EHki9YXN9fljKjOKl2ypP4Z2T4D/JWFj/QMLV29kLNjtbHnvcuOM3/ZUPgkjJ8oP4JYfZeuWZkjx kVixf5tHEy3jqg68U7psH34LAj4eqy/YX3mtwfjk1la446c3bTI0ap3KEHYt6DOj6Ro/NpnUgXJJ 0bzCqlXTUg9Czl/e15C940j8s6+vyWCDK9DdWtbXwFhVOq7bR9A7p+sfhJt74G8K7IeFMc9BIni8 JVPPMs8HSKo2U1Cwt1GfKcxW+DOwrPpxrEqgFogFGB/MF1MB5TfEALF+AeAOaIKfPZZRr/1ea9Fa tWYYal6w0DkBju0CuFC0nd9RZloyfUqzZO6zXS6GPgcNMoGB+WOo/Gvkb3qPx/6GDu++uLe5jm4E YiJwT6Ri7bj2SRYf3fuipoDxUgGM5n2Rsvru3RcpsJVnnPfFKtwXNY/VbiTUffHmdH1HuDOL7sO/ L/YMvi8Y20PcFx+Gm/te3xe8M3imeVbdwEMA938gwbWQ90UZ6lrQgDH6xb4X/n9z/Xt7L/g/Dwy8 F66Ybzk23aJWBglIxxNm/51+qP9NCJVHHFzDe4Gfc+48j0iBLepeqBriXkAesTjc2aQvw80jivZF fC9cDjf3SO8FnmdiPJAFTAbygXBnGtUB4rtNKoMmRYhf8vvwkZzpNxALJ4HRfevv7udUe54QKidx GlEhvpcJ/oYa+fcgWFxQqFwltA3RIWwI/v56JzbY7xr73tvlYtidAzD34x5nGcHvAK383osqwMsj ZMqpEPhGVAPMHREe5ptSA87/G40CXwrwDVLlRyA/CMwQz+OvInNMq2CXVX1/noYi52Nc027mUW6A dksjmG8hlxUTAZIboPw/kGE8mdgqAAA= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image064.emz" Content-Description: image064.emz Content-Disposition: attachment; filename="image064.emz"; size=1745; creation-date="Wed, 10 Oct 2012 09:43:26 GMT"; modification-date="Wed, 10 Oct 2012 09:43:26 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1Ya2xURRQ+e3u33VJa1oK1Qlt2a5uWQkgxNaFJ1bttaWloSVu3CSREWlKqEJDW PokKBf2BkQSCiSERVAyJD5AIfyQGpQ1G+UG0UWMIklhjopL4gISAweL6fXt3dqePrdvCSoyc7Ldz 5szjnjlzzrkz1yEimwBFHjBeVUHZaYqsdYp4ltVViThk1zzIIE/Q+pC1EkVegLDEEHnEMbrx4gGX lJ03BRPIIsADYLqFDsshWeDdgOEe+JbDmkNg3zVAPcC+uZYpM8GTcqzkMJ+HOZS82DKCc0FlUP+j Xisp3GZaEuYz0MoxmcAMwA0oSgbjBjxAAZAPsG8aJtT5RsjaoTB1vhIIBFCEaS+FIDwzt0JaYN8N sk6exv+/Q9bOUjn/fKm0v7Qxpau/VK6uTWxg3YPHn0Md6gZOoe7fUSrLbsxqoEy1s22mmZHyIeSh ZQT3hGtvWoyVuYxZTsMwzATDDBjyfeCoYDdsej00QF8zWypkvTwlXdING2yFFiN43isVyQ1FaMPj vlsKPdI3JTXUouw//mdDK0rqUJyQkdLaIy7OoWzPR0Tj09HGvWIf7m3ILww/eEIRJ3QDtrqp5U1N qeVsSw3JalHaPkSpQGPbF+pDPNerz6/0GesjurwQY5Ruuu/8DAOgKUywcJDulO+09pXKyFbbd/b3 2L7DugdaXUad/jGMel+v7TuUqXa2xdt3PHiu7jtrUKfvtKOk7+xCOR3fUXticJ1YR3ATQn/anqT7 EcWb4c+dsMhKlL0oG2ULZC3w8fiQ2pMs2ZgynT3Jco6PZ2r6WA5W5jaMxASn6TQSzECRDPv6ZEDF cyDki/qaZYI1x7In1MFCTI+NZ9pbxUk0nmqoPreLj/YsXR5LPLP/3diGH92G90IsfnQ3tkfn2/9z bOuxGo2fTgxXIabPOUUGAJ49iyyRPMj4zue5kn82InyO5VTnDZlvJYT5CcZiKCk4NsgttMJnFZxt E8Njvdqc+pk3ljn1s2+859f1aVt0cWlwUfgL8/1/ndF1+Kf+J0Z++zhaf91uOh+//h6fyJBPn//W 98ieU9+jBy1xZMFmbkDEMyjyPiDlOI3E9GyXJWYmBvCMybsUCt7R3CWW7luRe5O+B7odbX68fvr6 Jx97Mg72sueMbq+TU7bX9OwyXo/Y7cIdEZlq/zwrcu91WQ7nRcwxBKj7MthR5EDtxfqV1akz5vJq m1qzvLIRpRfIcSXi/82zvfehcHQ2VpfLsc+zLqFiPuGrw64d35My0oKcJ8nty1d34s57hnB8tuXt Vgiraip9/lXVv37jTZNil+nbtm3tFvdDdXPz2szX1lzLKKrZ/MUNI7s/f3Hivr2fHDFrm43Zpyve yb5wKPvCkoe/LBucjd/LBWkflA2eaCsZWY8ZpWbZyspj5c07wbosw6VyrFqbyT4azbMcVgnqhQDz PQE6bcMsZ6zA50EmFszRucGFu8CtA9T9KzfE877CXG/CaH+gZK7XvydMda9i73/nc4ppRfICnYM2 UiXzEOsrAAsoBugWHgCmCsKNkkQrewDalKTX81AnRHvX2by9fgMtjUA7JuW8Ue/CmF7/prABfd/6 qm/jUWD/vlJ5ztfTMf+jV1d8DZ5YEejtOOzy5w8kHcq0nhzIgIaDIqXiPbK1o2yGP7+q6ZmOU+i3 GeXZe7s6ltS1dNEXdD13/3CpZ8F7w/7tUHKO8ROWT9jklAtiHdzhU/VVe3BfBn5PMysP+q91W1du blNtMqTxECo7eWCq3RizoO9aN+1AOox6dWVNRfPjD3jfAF+2+nr3zGePpx/4dH0+2y9DdnPV9W76 qpLRbr9APlRg7pjs2WPvXRwHwwRjIhNleoinnHXGCshQfe5HRe+Dz4CjvpuNratxnMsfAhMS/YNt 8wG1brBh4vNrAXdYEvxGxO0J1EN2D75A8DsNDUIdeb4rDPEcmxvi2V/nqyAvQYdCgHGux2q093mJ FbbDqG+ORZDTr7k23Wds/r/97jStyJq9WJ0LUGX884L9fqVfNAIqL0T9HgOX1L9NTPQ9JlpeGG5l XuC54dbzgge6MpaZF8qRF1rbNnURKi+4CswfJ4tNDJ9yXri6fXxeoG9PkBd2Tvbs6eYFFdM8S6QA 2SFw78YS1ArGtC5nfJLqIfQAScB0YvocJh8A4hvTt/fcF0vucVkJUc7zkbtlvO+ELsuMokPkTHor Oui5Rt97na+CX5QAzPGx3sW96Mu8tQ7gOwLuEfS/VpQkE/AA7EdinXwOsEDexb+iyB19dJ5X7aPL XFT5PPo19Wa+dAPU27AieRXvLJkDkNwA+b8B9ZS744gbAAA= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image065.png" Content-Description: image065.png Content-Disposition: inline; filename="image065.png"; size=306; creation-date="Wed, 10 Oct 2012 09:43:26 GMT"; modification-date="Wed, 10 Oct 2012 09:43:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAnCAYAAABuf0pMAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAACySURBVFjD 7da9DYMwEAXgtwGV6bLAbUCFlzBdWgov4PLwOgzCIkzABEQpSEiUxpFlK9Errr7vfD8yYoyoGSCA AAII+DmAt+0EYH+EscsYQlMEoHq9CLC+AE7RWj+VAbxVrb7vDLDdEeLUFQecW5P6CtkA6sRVBQyC uVoLjuSQYeYWpN6FbDMQwthYgyV1DrIBvl3F/wE8B9RsvdeuyhaUO0Qfk6dVzg8JAQQQQAABBBxx A7SqNts1nkZrAAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: application/octet-stream; name="image066.emz" Content-Description: image066.emz Content-Disposition: attachment; filename="image066.emz"; size=2875; creation-date="Wed, 10 Oct 2012 09:43:27 GMT"; modification-date="Wed, 10 Oct 2012 09:43:27 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+1aD0xV1xk/99wLPkT0+QShyvShOMA/De3IIur0PlTAiQoMjWb9g4baztAVFBS1 zIfbIiqdzJnGZjVq00SDfxKSdWsWzey6ds3m1K5mMaM6mmmr2ZbRZKlrhbz9fvfd894VeI8HSu0S v+T3zne+8+/7zvnOd86992lCiGqgOxAIIBGrgAVkbBqdKMTFeCG8i5cVCqGJK9OF+DPKdFXBTk3U +RGEeVKI+drdhR++6hLzrhgCHYiZgBdAdzM0UxPp4N2AdJ/rYLNKG6z7BFAKsO4U0xCjwJMmmQkh PhN9KHmuKa2+DKuWf0GGOSJUZpgixI9HOdukASMBN6AoAYwbKAUeA6YBrDtaCL+TL4esBgpT50/t uQNrUSuFIIw5ZaFYi/n9nlgnNuL3yyFzZ7648sN8UbN3Q2KdP1/85+n4Mua9GP488lA3cAb5iqZ8 sfiLMWWUqXKWjTLGJ/4actsMa01o+8pHYZlLjomTUhq6NAJSfBQ4KbAaQTpsN3DazJKF4hnxfVEn 6jEHW6FFN8Z7eWFCGVyJuvxtNvTwVI8oK0Hqb79TVoWUOuTq4xOrNgsX+1BzzyEi8R6Uca1Yh2tr +4WsAE8oYoduIKhuUsHKlUkFLEuyZSVIgz5EadgXSsF7Adrr7D8DefY5yZaznxygyE4j6TUF5dSR c65s6u1nTnm2XZ96lwM1YMjfRHskIWqlEPSg/K+qIV90bw3638HNQf9j3gudupCnvZ3IN2wJ+h9l qpxlw+1/Xozr9L8nkKf/1SCl/zUjHYr/qTWRtBN2IAmRY008FYgEz2NPbMKMLEe6BWm5eAGytdgn w0NqTdLFhsShrEl6XN+YQE2/MwmWuaWM1+OMOKkbgemi09cgzqmYELB90Wmz6MfmWNaEOpiIC71j Audb7ZNIPNVQdYaDjzSuUx7L3mb9h/scPnUfzplYfOrhPr879j7c5+E7RH/xwrmfI/FD2eeF2PcN 6LAa4H13uilEJmRpAK6evJL7gwjzk8w4dccRk009xPfTFk1JVluLm2GG7ke4T8eH2mY4+nTes2Pp 03nfHu7+nfqsn/nhbMso/IR4/523nTrcY/03d13dOIlg/18raS2onOMqcJlC/wXGPA7w+WWsUgKp f/IXReKdZ4vEjX9YqZVf91KxSlnm/2B3sVUHcjb1d7WG82xr16/8Y4/VjqnV37qkJeyH+XMzjWJV bvVpj0u50O6mpiahJZvC78ZYvN+ebVoRyEDqAtYB6u5MvyOg0bespBdPv88C0gCepaQVTWet1Lln xkGi+lRyjOVfBXklwGcvjk/jcwHO33ajS6Ya14EueUASjfIocEA+IputlHyX9GjEdXlaMO2x8myT avRINdYIjNWfDhjG77DRh7xN/hBPG7knK4EKgHvSZWrSBJ8HcL2RiGaDv6CadwvZhqRSDLNA1dvz 5OxAihl87mATDcgG1PxkgifQJuKcP43S2QDbMiWpVEgttBazn9wTLLR/1XywnVo3paOqq+pQruaM /FzABUwE3EAjlI/XhVgNPg9QxHs7KR6CZsPQW407shXr0Wp8LJuNq7LR6JDfRJkbmIA+LqLzaH0k GxfkaOOSTDAuS8O4ggfOa8B1uQbtQzaDD44aCGCthbTWvwP+0SHb4CNtlr/sh//sl9HGOobyU7JV tsu98g25S/5KNslfym0hfduga+oA+h6Xo+RhaWBsQ+4BmpDfIVNDfWxC+20D9LERreowfgP0eBH6 7IRezUA0mw+gfAfs3GHtlQ7sgw6Zhb2Rhb0RzeYs7ZrM1K5Ir3ZZTtQuyRTtghyjXQzpewLz2TGA vkfFVfmK+BjoAu7Io8LQT8A71DqPgcN5BvCVFG2cPlEbq3u1JD1TS9CzNB3osWzOhQ6K1DrHQUD7 PFq8nmrE4y1EF/yiJ6qteFmhG0aCnmAk6aONsXqyMU6fYHh0bjQXoHw7BX55EzZzvjMBRWpsFIlZ GGsWxuTcZqsKSFUdmIs6N+RU+Huqw+c9mAs1n5HaxWPtusUNoCvqmneLHpms3ZTt6LEd852sfY42 16120fTqFt0yHvPGuVNrdABGqf0cSa8jeLprk93WnlLtuCcagWjjtclaeUQ+hz3xXFR7mlF+SPrR fzr8OF22gD9qt4vW/27U2YEx6P9Krx3QqWsAvXbAlt2w6QCg2qVi7Qeah6nwt1lGt7X+9JGZ/aw/ usH6X5cpxueyAfUb4APKz+ahzAXwMpdm85ORfhv4BjAOUOeBiscQ+RXP84x+GfTN8FkFsQ9ii2D6 XedKIfJ58ZABPMNmmMExWHk6ePZFXUL3Jgd/oq1tfqT6GJNm2BTmh6++FzZ2+pz93/u9Ndin8976 uCm0dFjltizzviXEm8CRAtzMC2IZ22VKg/PJdVRnP2KCOw/vpikjxX6v7qufUwfn+vVdD7atjEnn welTWRB9vkp+O5j5Gvq83K1H7PPSOgzzEuwz8ry0woe+jHnpq0fs8xL0zcHWzzTD32Vcph5XowlR BdD3kfQhynaXLi9KGjmB1/+kJcWLypGWAXNdiFFC71zPAm1TeVGBOH0h/RYyxrO+ZT4h2vcldq/l BSChpnjNJnyTeZvQfv/C8SoI/7pkka+i4al/XW5P8ptu3TfnWP222emnvu7t/ln1R1uv3W58MTCn tLMzq/w1T+BPNe8cXPD+4Zsrzp/0jqu60XHjJ55X3vvd+ZGP+x59+dS17J/uLvkqFczf/uM/pHyy 3U0rxZLFyxedLqjcCdZlGi4Vv9V8G6zjoImmbuYhnw2wTAbLfoMEeK2AcQ3xCRSHReDk4qMVfhmr eKfh+WFg0f6LlOeH83vbYH0l9vqMXQ821htm+JzMgO0uQKU8H5hfCphALsCZ8wKaDTdSEuWlgAmQ nHmuHdF/7O70SZSUA9xT7Dfidx7R9zvjsQ8aNpwEDu7PF42+zbWTz/586WXwxNLAltrXXRXTOo2j af73z42H5m8JkS8yTmytnTeyYlrhyu21Z1DveaTvpdTVPrZsbR19walny99vbc451VnB+1ay/ARm BdFZvWraSPEXbTw2sSZaxtw61FG8eh++BQGXsozGQxWf1Zuf9vwA5gTpkoOHxLTFpXC7FrTJafis nvNAeh35okVLFlY+NTXjCPh5a27Xz9zV7nn13WemsbwLsp7Vt+vpq0rGefsn5P8ebZjRxu79TYHt MDHWPkhD6rF5ypm3z3Kp6jzSq456poDYot551Y59VQDVAOMe/WM+kAEou8GGiOUlgDskCT97rKZc e0Nr0Vq1RihqBVjIXEACkARwoqg731Fm2zxtmmLzXGcnXwh5HipkA73vj5HuX0M/0zt9zjN0cPHi wd51DDPkE6E4kYG549yn2+nwxovKAvpLOTCs8WLZGbju/YkXXujKPc54kQZnrVpfXUeoeOHKMq5F 27NoLkz+gEpjjRd7+8YL+nY/8cIXbewHHS8YM7i/6WNjAT5jcv17E0yLGC9KUdaCCvTRr3Zc+P+9 6z/YuBB8HugdFyL+NwHHnPM7fX//TYh0j8jN4T2Czzn3fo/w0i/tuMCnhN5xAfcIf7S9ieaDjguL 9sUcFwqijT3UuMD9THiAHCANmAtE29MoDhHPbVIpJF5c7Pk+fCh7+jziwTlgeM/6+/uc6rwnRLqT uMy4CO9lwt9QY38PgskFRbqrRNYhPoIO4e+v96KDM9Y4197JF0LvPIB3P67xdDP8DtC+3/tRBFjv 9Cw+AwKeEesA3h3hHtaZUoWU/xuNQ7oK4AtBlf8uePpvjmjDr6Lwe0K7f1XQbzoFUo5Hv6bevEe5 AeotzfB9C3dZkQyQ3AD5/wGL1zPt2CoAAA== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image067.png" Content-Description: image067.png Content-Disposition: inline; filename="image067.png"; size=903; creation-date="Wed, 10 Oct 2012 09:43:27 GMT"; modification-date="Wed, 10 Oct 2012 09:43:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAFAAAAAyCAYAAADLLVz8AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMHSURBVGje 7Zm/b9NAFMdvpAKpAcWFJaIj8kBgo0gohqq0DBUDcgVSA6FKWzCRIaqqgDLYMZHiduFPYK+QOsLG VkYWdoYMDEyduoBCXsjZZ3OOfc4lodEbvqp6vty9++T9Ooc0Gg2CSi+EgAARIAJEgCgEiAARIAJE IUAEiAARIAoBIkAEiAAjVattzWoKOSKEdAJStKOtWm0W5li6qvfG1LWD8Octo7CgEHIcmN8fm9MM 29DmbH9dtV20rFySPanWVHLwz7wIW8YOMHCQvvHsmKpb+jAAs9nsN7p2paItK4r2CeZ4UJn1ensw awQh/wUfsGVEEIUm8w7iHcg0c8N6IO8zPhgfCk/enhyv9NdXjguGtTAxgDQ8qKfFHkYUIOfwSfeN m0OfQ5qYCEDfE+K/xdQAI0Is4KEcT0xiG42eiQG0rGJOJaQdF0qjABjcnxYGH1YS2waln6n3wKhw pLacCg/kVdtIgANymgyALBBqS9IcGGf7eKowBww889qYiJAKhKFkgAOrsNfKxKefkQIM5yEIB7bP Yr9dtqGFce9/RWmLeKC/px+efrPtAwk322BbeEy290m9iYRzC3deF5AHRMAD+bcLvjfx58rv//Au jAARIAJE/ecAd+r2ldXt1seNqvMMAabQA6P1/kZxv3Pz8f6J67pnEKCgVjbdLwAQBN6IAAV1++ne dwqw8sbREKCgKDxQeccpIUAB1ev2PAtw3XxrI0ABQciyAKGgIEABlXedhyxAaGcQoMhLC9u+xBYR AIoAU/aBIGykESAClA7Qtu0MVMtRXbPGAbB7w7k2zC0n8US40OuPFg/PEfLr7PXqz3z+IvPG9+rv Wy+b76BXk6m7Zfcr2wfKFlR2ttIXSns/7m26n+9vu4fwHAqZFIAAr7fJ6lJnpgtsJtOHl1nq5GEM /jKGTIvgLi4FoLHrrMAbEQqwB+/y+tQBCytJ8y7Ul5kb2ovzhJyQC3fai89bH8Ddwe1hI8iFp02l avMV9JrgaXAWCNsnZvM1PIPcKL2IpPn9dtr1B5THpFM2o8/sAAAAAElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image068.png" Content-Description: image068.png Content-Disposition: inline; filename="image068.png"; size=7538; creation-date="Wed, 10 Oct 2012 09:43:27 GMT"; modification-date="Wed, 10 Oct 2012 09:43:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZYAAAEyCAYAAADZdfZuAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAB0HSURBVHhe7d0tlBPLtgDgyCNHIkcikUgkcuSR SCQSOQ6JRCKRSGRwI5FI5Egk7vBqNxVemDtMV/8l1dXfXYv13jqTdO/6qpOd+t/t/I8AAQIECGxR 4Od+989/+92rLZZdmQkQIEBgAYGUWK5/ft79/O/z7v0Cl3dJAgQIENiSQLRWIqkc/kkuW6p9ZSVA gMACAqkL7OlxYrnbckmJ59kCt3VJAgQIEGhVICWW53cTy3FySS2YN+k1L1stv3IRIECAwMwCqUXy 6L7EckguKbHc5v//zcy3djkCBAgQaFXgkDz+lmCOx19iTKZVB+UiQIAAgZkEoqurL6kcJZeblFwu Z7q1yxAgQIBAqwKp1fJpQHL5HmMzrVooFwECBAjMIJBaIRcpuXwpTS7GXWZAdwkCBAi0LjAyuega a/3BUD4CBAhMEcjJZT+w5RJdY/9Oua/3EiBAgEDDAt3eYZ9374Ykl8P05EhMDdMoGgECBAhMEUhJ 4kVKMD+GJJj0+q+xmn/Kfb2XAAECBBoWSMnlcSSLIcmle23a2LJhFkUjQIAAgSkCedzlw9DkkhJS DOw/nnJv7yVAgACBhgViIeWIrrEf9hpr+KFQNAIECEwVGNs1Ftvx2w5mqr73EyBAoFGBCbPGvuga a/ShUCwCBAjMIZCSxFVqiXwfMvbSvT69b477uwYBAgQINCgQ2+4P2Wfs92aW+92rBjkUiQABAgTm EkgD9K9GDOw742WuCnAdAgQItCiQB/aHbmT5vkULZSJAgACBmQTGDOzHjLGZbu8yBAgQINCqwNA1 Lym5vG3VQrkIECBAYCaB1Hp5khLGt+JZY7aBmUneZQgQINCwQN4O5kZyabiSFY0AAQKnFsjjLsVH H8euyqeO0f0IECBAYGUCksvKKky4BAgQWIPA0OTiVMo11KoYCRAgcGaBPOZStNYlFlym5PL8zCG7 PQECBAjULjAiuTiRsvZKFR8BAgTOLZCTS9HJlKnlcptef3numN2fAAECBCoXiGRRus4lvS623P+n 8iIJjwABAgTOLTAwudj65dwV5v4ECBBYg0DevLLsXBdnuayhSsVIgACB8wvk7V96k0s+KOzR+SMW AQECBAhULxBTi0vOdLFhZfVVKUACBAjUIxDbufTtK9Yln3RyZT1Ri4QAAQIEqhaI81kKkott9quu RcERIECgIoG89cuD2+3nVovpxxXVm1AIECBQtUBKLld9rZb0mmdVF0JwBAgQIFCXQGqVPLwyf797 XVfE9UUT64QiAd/z7zr9t+J/qS7epH/7Bf69/1scaTLHqztxG1er7xETEYF1CcTsrwdbLRs5cTK6 Bu98wb4+fBkno49HX/blp3V+3v3sbRFW/po7Se53gopdscMr/V97zK3rIy9aAssLpC+Ody0nltgv 7ZAw8q/z6yjz0Rfmj7V/+dcSf2wddHD9nZT3u5fZX0to+Y+zOxA4v0BeMPnwF2vlJ00eEkf+BR1J 40P+crut5QtXHP/fcov96KJ+cuKJVmF0IT4+/6dBBAQITBYoXYUfr5t8s4kXOEoe8es3ksen7sup 8m4k8Q3rCozxvqOkcyXhTPzgeDuBUwpEl1Dh6vtvp4wr7pV/wb44GsjW8thwAo3nNLdA38bCXmM6 p/5Euh+BHoH4BRi/9kt/SS95bHG0QmJ7maMWyKYGxUvrwOvub/Wk5/imGx+MXSScI+S7j8DpBdIH 71Hv7K87v4qjL3zOSHNL5HUeA5FENtwKWSJZ5okDMWtNopnzg+taBO4KHBJKSbfX8Ye9e/2EsZU8 JnKVZ199WeKLpJZrpjLe3pmS261DOcyK6vu/h2m7d6Y637cmZvR/S/foxqbu+3dnhlzE3kTXY66X D7nsJgf4eiQwVWBsQokv665PO3VRDY0hvhjzuMhNLV/6Q+I46su/LzHEQPLhi31T02ZjTONQ9kPX Ze6+PMy+W0V9x8SAnFglmaEfbq/ftkD0NedfoKPWZgxJKt29fk0CiBlao+435It/ymujWy+3Kj4c /WrfZKJY8hMSY3jdD4w8dpYTULe4dEr9zf3eSDJ5TdPlkh6uTWDVAjmh9O5W/NAHNL58+6Z3di2h 1K1S4RfFYWFezByKLp9IGk9WXakNBp+7SKNuYhwkpo2fPel0Pzp+dRVuqiXa4OOlSHMJzJFQcvfX m3Ste3cxzl8GMf3349y/HIdc72gsI2KVPOZ6iCq5ziHp5FZwtzPCkOdjjtd2z/ivpGdH70qeC2Gc UGDGhBKDzPf+so/WS/qgvT91N9dxAsm/JOMXrg/6CZ+vmm4Vz+fRrgonmVyQx9vejxlrrMlOLASK BLquqL5NIwumsaZrfEvXurp70/gCj19s6e8nGZDt+rrTFizpnoetPSSQoidh2y+Kz0E8v/FZ6Abl C575sa/JP3Sii9Wg/7Yfu/ZKn7sJok960iB5Tigv7kkoMegfW7Z/H/sB7Htf/oBGV8OhG+uivZpS onMI5LG/f9MzFl1oi62ROhr0Nx5zjop2z3kEcgsiFhVO+sL/W0KJpv5SYycRc26NWLA2z+PgKoUC 0VWcW97RlTvps/O3H0zpup+W3JmisKheRmCYQP5gTFqs1nUT3NmdOFo/eYB09l923YDrr26te8dt hgl4NYF5BHK32SJJJrfEY0KJrrJ5qstVlhDIH4JJ/cbpYY+pw3+MoeTB+OgqmNSddvcXXLR48uCq 8ZElHgjXnFVg4SRzY1bZrNXlYlMF0gMZK9cnbX/yl4QSg5yzTt3MLZPo4jJOMrXivf8sAtHNHD+I lugKzt3AMeB/eZbCuSmBnFAmffHfTSj5QxMLGWfr7opr5dXKBi49tk0J5MH/+LxM+mF333iMsZim HpX6CzNTQolpwy8Opc3TMGP22GwDljEAbz5//c+TCOcRyF3GMY150vjmPV3GsVlpjMVoxcxTVa5y LDBTQrm9k1BiuvBsixmPBiS1Tjy+mxXIsyZn+1wdko0fa5t9pOYv+EwJ5XvujuoGyuPXTySUvjUk pX/XbJ+/3l1x/QJ52n8sHC4+JK/kM5e7sH/3OKxfSglOJjBTQonjWWMw8CInlCdzDToetU400U/2 VLjRWgXix1xMqZ95/PI2/2DsPt/+R+CvAnMklLxBZJyK133px/qQGRNKTEm24Z5nmMBIgdxV9qGk dVLymqPZZLqgR9ZJs2+bMaHE9ieHhBIbQs6yu3Du333abAUoGIETC+RJM3O3YuIH5ZMTF8XtahOY OaF0D1Q3DTLtf1Tya6fnrJXoSntnRkptT414WhNYoBUTPzAlmNYelL7yLJRQYpfhydOGuymTv7ZY uegrh78TIDCfQJ5YExu7zjJtueuxsG3MfBVU65WWSChR1nxC46SHMT2E3R5hMZulVj9xEdiKQHwW 02dylqMoulmg1sK09+gsmFBip+HZ9whrrwaUiMA6BfLkm1mWB0gw63wG/ifqpRJKfthm3dKlEXLF INCkQB47jdX9k3fIOF6G0CRWq4VaMKHEwPykXy95gdVVq/bKRaBlgRj7zEdYTO36/mPhdMtmqy/b ggnlIg/Mj96+XkJZ/eOlAAT+EMjjMJM2wewWbd5z5DjqCgTm6JrKCxv/mCYYv06mzvSKB8epdRU8 JEIgsJBAJIbuh+Pn3c+x/9L79+l7wlq1hepo0GVzQpm8CDFPC3xyuHnMzIopv1P6U7ttV/a7V4MK 5MUECKxWYKYEEzPIrOI/x1OQ55vPnlCiLFP7T1NCiYWNsdX2xTls3JMAgfMK5AQzerZot03Mfvfy vKXY0N1zQpk0eH5fl1cQ5v7SSYdsxdYrfm1s6IFUVAIPCEz9Tol1NLrHFnzEDlP9xvZfHp2psI8B /uNQZ2q+6h9dsP5dmsCaBaYuoM5bO+kBmeshOBo8Hz0bK7dQ7ksoi5xXP1fZXYcAgXYEpn6XdeO9 RyfPtiNz4pLkZuTUueL3JZTYdXjS4T95iuCLE5O4HQECKxfIvS+jN6ntvrsM7g9/ChJafPFP2qMn pu7d0+V10Q2qT5sSGDO9DKoNr1bvIEDgSCB/z42agKT1MuBROpriO7rb676EEiFMbf0cpg5HjAOK 5KUECBB4UCBv2T9qBpnWS8/DNbWVkle1P7t7m5hRMaX1k38ZXJs67NuBAIGlBPKP6jhyY/CPaq2X v9RKrEofA5oH5eOo3qu7l879mKOPH81rUeK8eguVlvo0uS4BAn8I5OUUo8Z/tV7+7Gd8PWbMIyHG 2SX3JZQ59vRydoIPPAECZxPISyAGT1zKCyufny3wGm4c4x5Dk0oe67h38HyGFfOOE63hwRADAQIx Ljx6slFe97K98eDoU4wkUZpYHtomZYbtE6I77X/GZzzbBAgQOLdAHicePLife3WenDv+k94/xlUG JJWbGNw/DjAvNoqjQweDH63CN3X4pLXuZgQIjBHIP8QHL5Xoxq7TZrpj7rnK96QCF+331b0utSby vzgPPmZOjBrcOkooNolc5VMjaALbFpjQeolu/va7xrr1JhMWKo59b5458UfrZ9uPqtITILAmgQmt l+jyv1xTWQfHOrXVMTSxxDqXWIg0OFBvIECAQIUCeWFl8Th1Xp4R2/G3e5hYbIsyNDmMef1Ds8gq fFaERIAAgWKBPHNs0NBANxGq1W2phs4KG5pU8qBVrJhvv1+x+DH0QgIEWhTI2/IPWrWfviPftmgR 87SfdNsRzDzWkgf8rZhv8qlRKAIE7hPI22J9GfJ9msec2/vxnZPLpFMbc99hzPR61/zglM8UAQIE /iKQe4LeDkwusZzjojnUDiP1+XUbSQ5svUTG7cZrWoRprqYViACBUwjEriZD9l/svntb/g7NCx+v Yr1KXrOyj6nJ+V/Mxb6OrVvyupb2suwpnjr3IECgeYG85qV41lj6jv2mx6f5x0IBCRAgME0gEsWQ nqCcXKzzm8bu3QQIEGhbII+7FB8h0k2oShOr2lZROgIECBCYLJASRvFeY5LLZG4XIECAwDYEhixM z8nlchsySkmAAAECowVixljp7FsD+qOZvZEAAQLbEsj7jBWt1JdctvVsKC0BAgRGC+TkUrTzieQy mtkbCRAgsC2BIdtqpeTytelFlNuqeqUlQIDAcgJ5IWVpt9jexr7L1YUrEyBAoBmBgWMuH5opuIIQ IECAwHICkVwGzBZ7s1wkrkyAAAECzQgMmorc6mFhzdSmghAgQKASgUGLKB33XkmtCYMAAQKVC5Ru /5JX59u0svL6FB4BAgSqEEhJo2jjyjwNub1TKKuoBUEQIECgIYG8K/K+ZEA/JZePDRVdUQgQIEBg KYFYENmtui852Xe/e71UHK5LgAABAg0J5MPCirZ+iZN9Gyq6ohAgQIDAUgKRMFLLpXd1vq32l6oB 1yVAgECDAmka8quSLrGUXG5s+9LgA6BIBAgQWEIgJY33hcnl7RL3d00CBAgQaEwgzxS7KUku6bVX jRVfcQgQIEBgCYE8mH/bl1yMtyyh75oECBBoVCAG8/sSS/zdeEujD4BiESBAYAmBlFyuC5OL8ZYl KsA1CRAg0KJAapEUrcw33tJi7SsTAQIEFhBICeNRSi7GWxawdUkCBAhsVsB4y2arXsEJECCwnIDx luVsXZkAAQKbFTDestmqV3ACBAgsIzBgvOU2XrtMFK5KgAABAk0JDBhv2TdVcIUhQIAAgeUEisdb 0qaWy0XhygQIECDQlEDJeEu3Df9+96SpgisMAQIECCwjMGC85ast9pepA1clQIBAcwKx2r5wy5f3 zRVegQgQIEBgGYHU3fWuJLnY8mUZf1clQIBAcwL5/Javfcklb7FvCnJzT4ACESBAYAGBGKDvBurT NvoP/YsB/wVu75IECBAg0KLAf2lqcV9i6f6+371usfzKRIAAAQILCJiCvACqSxIgQGDLAgOmIH/Z spOyEyBAgMAAgdIpyLrEBqB6KQECBLYuUDIFOa/Kf7x1K+UnQIAAgQKBAVOQzRIr8PQSAgQIEEgC aZbY05JZYul1L4ERIECAAIEigdTd9aYvuaTXOLulSNOLCBAgQGA3oEvsLS4CBAgQIFAkUNolZnv9 Ik4vIkCAAIEQSN1dbwu6xAzke1wIECBAoEwgd4nd9iUXOyCXeXoVAQIECCSBlDRe9CWW1LKxIt/T QoAAAQLlApE4+pKLVku5p1cSIEBg8wIxQN+XWLRaNv+YACBAgMAwgZQ43vclF62WYaZeTYAAgU0L 5B2QHzwUTKtl04+IwhMgQGC4QMn0Y62W4a7eQYAAgc0KFLZabjYLpOAECBAgMFygsNXyZPiVvYMA AQIENilQ2Gp5t0kchSZAgACBcQJ9M8TyYWD/jLu6dxEgQIDA5gRKNqhMr3m1ORgFJkCAAIHxAn2r 8dPfDeKP5/VOAgQIbE8gWiQFCyYfbU9GiQkQIEBglEAaxL/oxlI+737+9V/awHLUxb2JAAECBLYp UDCI/2GbMkpNgAABAqME+rbUT4nn+6gLexMBAgQIbFMgusMKxlmebVNHqQkQIEBglEDM/uoZZ7ke dWFvIkCAAIFtCqRWy/VDiSUlnk/blFFqAgQIEBgl0LdYMiWW21EX9iYCBAgQ2KZAarH8UzDOcrFN HaUmQIAAgVECqVXy9cHusP3u6agLexMBAgQIbFMgxlF6EsvLbcooNQECBAiMEug7oyX+PurC3kSA AAEC2xRIA/gvzQzbZt0rNQECBBYRSInleU9i2S9yYxclQIAAgTYFCqYc20K/zapXKgIECCwjkKYc X/a0WL4tc2dXJUCAAIEmBVJieSSxNFm1CkWAAIHzCfQklh/ni8ydCRAgQGCVAn2r71dZKEETIECA wPkE0lqVbw8ll/NF5s4ECBAgsEoBiWWV1SZoAgQI1CsgsdRbNyIjQIDAKgVie3xdYausOkETIECg TgGD93XWi6gIECCwWgGJZbVVJ3ACBAjUKSCx1FkvoiJAgMBqBSSW1VadwAkQIFCfQMnxxPVFLSIC BAgQqFbAJpTVVo3ACBAgsE6Bgm3zv6yzZKImQIAAgbMIFBz09eksgbkpAQIECKxTIHWFvejZ3fj9 OksmagIECBA4i0BKLK97EsubswTmpgQIECCwToG0ncubB6cbp8SzzpKJmgABAgTOIpASy/uexPLi LIG5KQECBAisUyAllk8PdoXtd8/XWTJREyBAgMBZBFJi+dKTWJ6eJTA3JUCAAIF1CqTE8qOnK+xi nSUTNQECBAicXCDNCHvUMyPs+8mDckMCBAgQWK9ASizPehKLVffrrV6REyBA4PQCadX9y57E8uH0 UbkjAQIECKxWoG8NS/x9tYUTOAECBAicXiAljo89M8Jenj4qdyRAgACB1Qr0TTWOMZjVFk7gBAgQ IHB6gYKpxpenj8odCRAgQGCVAqk18qRn4P7HKgsmaAIECBA4j0DBdvk354nMXQkQIEBglQKpG+xt T4vl7SoLJmgCBAgQOI9A38B9WuPy73kic1cCBAgQWJ1A6gb7p2Dg/vHqCiZgAgQIEDiPQMHAvT3C zlM17kqAAIF1ChRs5bJfZ8lETYAAAQJnEeg7NdJWLmepFjclQIDAegVS4vjWcwbL1XpLJ3ICBAgQ OKlA3/hKl3D2u4uTBuVmBAgQILBegZQ0XjuDZb31J3ICBAhUJ5C6wfY9icVW+dXVmoAIECBQqUDh +pVnlYYvLAIECBCoTSAllqu+jScj+dQWt3gIECBAoFKB1A32riexfKw0dGERIECAQG0CuRvse8+J ka9qi1s8BAgQIFCpQF83WJ5mbH+wSutPWAQIEKhOoPd8+8+7L9UFLSACBAgQqFMgtVYuH1xp/2tR 5Os6oxcVAQIECFQn0HeoV+4Gu6wucAERIECAQH0CqSXyqO/slfT3T/VFLiICBAgQqFKgsLVyVWXw giJAgACBugQKWysG7euqNtEQIECgXoG+fcFibCUd+vWq3hKIjAABAgSqEeg7JbJLKp93t7ZwqabK BEKAAIF6BfIq+9u+KcZaK/XWocgIECBQlUAkjN6kkhZEaq1UVW2CIUCAQJ0CJa2VbvrxfvekzhKI igABAgSqEihpraSkcl1V0IIhQIAAgToFClsrBuzrrD5RESBAoD6B1MX1pndsxfTi+ipORAQIEKhR oHAxZIytPKoxfjERIECAQGUCqbXyobe1klo0lYUtHAIECBCoUSAN2D8tSCrGVmqsPDERIECgRoHU WvnSm1iMrdRYdWIiQIBAfQIl04tT4vlqMWR9dSciAgQIVCcQJ0P2nbWSD/G6qi54AREgQIBAfQJF uxc7xKu+ihMRAQIEahSIM+p7x1V+bd3yuMb4xUSAAAECFQmkZPGspAssFkxWFLZQCBAgQKBGgTyu 0r8lvgH7GqtPTAQIEKhLIO8F1j+12O7FdVWcaAgQIFCrQMnq+jwL7LrWMoiLAAECBCoRKDlqOB83 fGPNSiWVJgwCBAjUKhAzuwoH62PbFptM1lqR4iJAgEANAgPHVZ7VELMYCBAgQKBigZIzVrouMHuB VVyLQiNAgEAlAnEufWEX2LtKQhYGAQIECNQsULRr8eedwfqaK1FsBAgQqEUgdW39W7hly2UtMYuD AAECBCoVyAP2vavr0+teVFoEYREgQIBATQKFG0x+qilmsRAgQIBApQKxDqVvwL77u/UqldagsAgQ IFCZQEoabwvGVt5WFrZwCBAgQKBGgcLWSqyuv6gxfjERIECAQGUCRa0VCyErqzXhECBAoFKBWAxZ 0AUWrZV/Ki2CsAgQIECgJoHUWvnUm1i0VmqqMrEQIECgXoHUCrnuTSqfd1+0VuqtQ5ERIECgGoGU LK76kko+vOuqmqAFQoAAAQJ1CqRtW573rVnJh3d9qbMEoiJAgACBagRKk0purTypJnCBECBAgEB9 AqXHDOfWisWQ9VWhiAgQIFCPQOnBXTmp7OuJXCQECBAgUJVArJZPSWVfNFAfJ0J+3n2zwr6qKhQM AQIE6hFIXV9PU6Lo3wY/JZTcUomkcllPCURCgAABAtUIxFn0JTO/Di2Z9NrvsQq/mgIIhAABAgTq EMhdXx9Lu75ySyW2bJFU6qhCURAgQKAegdz19XVgUomV9Y/qKYVICBAgQGAWge5Y4HTe/NiLxemP Q7q+ckvlo+1axop7HwECBCoXiK6o2BByaJj5LJXejST/pxWTEtHQe3k9AQIECKxIIBYv5qN/L0rD zqvovw/s+rqNLrPSe3gdAQIECKxU4PdhW/vdi74idN1mBUcJ30043XoWp0D28fo7AQIE2hBIX/o3 JaveU2J4nF77ZUgrJe/7dd2GlFIQIECAQJFAt44kL1T82yyt9N9fjBigj6nEz4qC8CICBAgQaEMg WiHHLZAYbzkuWV6b8mFoK6U7HdJU4jYeEqUgQIDAEIG7h25Ft9jh/XltyrchSSVPAjDra0gleC0B AgRaErh35+G0Z1dsyzIkoeQxmq9mfbX0dCgLAQIERgh0XVaH8ZXjDSHv/Le+JJOu896srxEV4C0E CBBoTWDIDsT3JZe8geSL1lyUhwABAgRGCMTgel9L5KG/d1OP0+D/iFt7CwECBAi0KBCr58cmlm6R ZFos2aKLMhEgQIDASIHYPPJvieWhNSuRVEbe0tsIECBAoGWBlCAGnZ3S0y12E9u2dLPJtGRafmyU jQABAn8XSIlg0PkpPYnlgwO7PG0ECBDYsEBMDR47vvLHSv1f04wvN0yp6AQIECAQArGQcUpiyetW JBSPEwECBAj8Ehi5sv6HhOIJIkCAAIF7BVKCeFfaYokZYnl6sfPpPU8ECBAgcL9AybkqEoqnhwAB AgSKBPIpkD8eWMPyXQuliNKLCBAgQCAEYlrwA/t+XdtM0nNCgAABAoME4jTIO1OGv6f/JqEMUvRi AgQIEPgt0HVzpW3xu52NJRRPBgECBAhMFUgJ5YOtV6Yqej8BAgQIECBAgAABAgTOJfB/ODjqPDRo rdUAAAAASUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image069.png" Content-Description: image069.png Content-Disposition: inline; filename="image069.png"; size=8965; creation-date="Wed, 10 Oct 2012 09:43:28 GMT"; modification-date="Wed, 10 Oct 2012 09:43:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAdQAAAEUCAYAAACSz8fYAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAACKaSURBVHhe7Z0hdNy6EoYLCxcWBhYGFgYWBgYG BgYWlgUGBgYGBgbmscLAwsLCwML75u8b921zd62RJduy/d1z9rx372pt6dNEv2c0Gr97xz/NEXh+ 9+6Tfc7t81Wf/7x792Sf5wOfJ29zZf97Zp9dc4OhQxCAAAQgAIEpCLgQdqL5w0Tzn8LPi/3+1gX5 /ZhjsPs82n0uxrwH14YABCAAAQgcJCDv04Toxj7fCoUzIry/7B73Eu3a02HXvNzr/7cx7lG7z1wP AhCAAAQWTMCE5oOLz4MJ0OsEInpMaH94ePhDKU67znsbx88DY5HHelJ6fX4PAQhAAAIQ+E1gzwtV +DXiSU7ZRl6rQsKDhdU97GN97q6/wxwgAAEIQAAC2QTkmbnQ1NgHnUpgFQ7O8iglxDZOiWaqj6/y zLNB8gMIQAACENgeAWXVejh3iv3QlICVfC+PNeRRmpAqdJ1zL2UiD/aGt2dVjBgCEIDAhgi4N3pn wjLnnmiOqEXaJj1KG/dppph2901ee0Pmw1AhAAEIQMAE5bMJis6ERgSqpI2EWudO5TnqLKrOpOqc 6dvPtb73tpEwbKRPRz1KebHqk32G3gtvlT8jCEAAAlsm4GHdMfdGn104P5eER5UMZZ9rE7zSZCh5 lOfH5tw99MeBDxY/9WCyZXti7BCAAAQ2R2BEIZXg3UgAx4Iq0XPvteRBQB7y0eIQ8phtHEP3j5UQ NWrhibHYcl0IQAACEAgSsIX+woSiRIjehlYVwn2QQJd4oMHu/6uZPxgM9VpVtOGk794FvF7m4DGU I7+DAAQgAIEgAVvcPxZ4XG9FVII8qhcaHNafZgrjWp+GCGtvCFg3kLep8donsk+730Yh4NE89VxG tIcABCAAgQICnmwzRAwOeaIKZTYtEO5RHqp0lBLDmxRmjd1E9XumsP6y312lrs33EIAABCDQMIEC cdkXH4UuFc5dzJ5gwUOEEqh2fVNa4K3eNWwqdA0CEIAABA4RcEEZmqnaian2RZv2RlOzP9CjVF3g j4FrK2kp1xNOCnbqvnwPAQhAAAITETAx0HnS3IW+E9GuVu3JRN0d/TbuUapQRSrku/+99lWTx1/8 weU+89ry+FfDd/QJ5AYQgAAEpibgwpG7uL8V0tWW0fNs4KyiDfab68g8ao/URDXn2vKCEdUIXNpA AAIQmJKALc4qm5ebLNOJadHbWaYcZ+m9PNM5l9NdZP/Yw8s5kQGJ6mnpmPg9BCAAAQhUImCLso6L 5HhHnZDqDGZyr7BSN5u5jIdpc4vgh/Y+5XXaXOQc3VFoGVFtxjroCAQgsFkCthir1m3O3qDa6mzk 5Wah+cAVzs1kF9r79NB7jmCH9mu3Pl+MHwIQgMAoBAqyeBW+3I3SqQVedIB3Hw7TZgq2zqomk6AW iJguQwACEGiXgIcVc/cBKdp+ZEp9/zln71Me5VnEQjIToRDVCFTaQAACEKhBwMU0tw6vzpPilfZM wIC9T4lfKGwuz9NCy9E9bkS1xh8K14AABCDQR2CgJxVa9CH/u16v3oeaVQzDfvMlwk4erV1bLxGI 7HcjqhGotIEABCAwhICLaXRB1qL9fYsZvEPYvv2NsbsNCl8njqGSgplziKjWmEyuAQEIQGCfgIcM c8T0kRBvmQ0ZPxVqiHiTXRsxT9Y61kOOXTcaspeonpWNhF9DAAIQgMBvApn7b1rcb0FXh8CADGCd 692l7p65D64EqM2dFU4x5HsIQAACWQQGhAgvsm5A4ySBAfvWoZKCmaKqayaFOjkYGkAAAhDYIgFf cKNhXvbbRjSSARnAoepHmaIq7zcZUh4RA5eGAAQgsDwCmQstYjrBFHsG8LOF1KP7qqF5yZzrxwmG yi0gAAEIrIOAL9zRWrDhAgProDPvKOQhmqBmvc1HyU2pXmeK6k3qenwPAQhAYPMEfMHOEdPTzUOb AYCJ6k2GpyqPNimCvlcbKv5gbdkrn2HeuSUEILAgArbwRosKhPboFjT0xXXVRC23sP59ag/UM7oj IWWFkz8tDhodhgAEIDAFgQyvJ7Q3N0Wft34PE7VLm7eQV+kebfIVcAoRB71f1WY+2focMH4IQAAC fxHIWEQR08Zsx73KaDa2vM/kK+CsTbRSk65F5m9jNkF3IACBmQj4ghzycuQRzdRNbttDIPO8cPc+ 2t6QrYlqNPx/z+RAAAIQ2DwBW4hVhi7k3SCmbZuLZ+rmvFJP0YajyUU5CWraz22bDr2DAAQgMCIB WwQ/mJhGa7oms0RH7CqXDhIYcFa1t1Ski3TkPa0kKQXniGYQgMAKCZiYRosEcJh/QfM/5KyqbEFi fGiY9t/12rfIlsDLgjDRVQhAAAJ1CNgi+dUWycjxCJJO6iCf/Co2v7lnVfW6vdMjohrK/GVbYPJp 5oYQgMCcBGzROw+KqQqif5izr9y7jMCAYzUK3R6srGQ2E6nQpKM0ZP2WTRu/hgAElkDA98QiSUha WA96K0sYJ338PwEP2UbmfD9ioUL4Z/scPZT8LfUwpqxx+EMAAhBYNYHogqgFU17sqmFsbHADMoA7 cZWw/rEFv05qP/V2Y3gZLgQgsDUCwZBdqO7r1titYbyeARw9W/p2f12ZvipdqL33VDKbNeMfCEAA Aisl4HtpkSQkFsOV2kA3LBPEaBWkiL0caoMNrdyGGB4ENkvAVjcVb0iF6bQwkoS0ESsxm7gI2sQQ UX3aCEaGCQEIbIlAxr4pB/O3ZBg2Vn/Qir6qLyysCgtvDCXDhQAEtkAgGt6zRfB6CzwY498E/IFL 51UjEYyIqOrBjKNWGBoEILAuAhnnTR/WNXJGk0vAvdUnE9aIaB5tc+wMa25/aA8BCECgGQLyEmxx jNRgVXUcDuI3M3PzdsRs4ZPZzdBMYI7LzDt93B0CEBiDgC2KqaMN8jIo3jAG/BVc08+bKhQc2WNV ecrzFQybIUAAAhD4m4D2QyOhO/ZNsZwIAZ1fVVawko3efK4UKo5cgzYQgAAEFkcg44jM4+IGR4ch AAEIQAACUxEwzzRZa9Xa6Lzpbqo+cR8IQAACEIDAogh4WbhUlibnTRc1q3QWAhCAAAQmJWBiemqe Z/IsobX7MmnHuBkEIAABCEBgKQT8cH4kG/PbUsZEPyEAAQhAAAKTE8gI9ZKROfnscEMIQAACEFgE gYxQ79UiBkQnIQABCEAAAnMQsH3TSFav6S7/QAACEIAABCBwkECwgMOrqt6AEAIQgAAEIACBAwS8 NFwkq/cSgBCAAAQgAAEIHCFgod7Im0EI9WJBEIAABCAAgWMEVFfVBDVSwIGsXswIAhCAAAQgcIiA nzlNvpaNAg7YDwQgAAEIQKCHgHmmeqVWyjvV67R4xymWBAEIQAACEDjinX40MY0kIn2CIAQgAAEI QAACRwiYmD4GvNM7AEIAAhCAAAQgcISAhXDPA2L609p9ACIEIAABCEAAAse902TxexV6ACAEIAAB CEAAAmXe6QsAIQABCEAAAhA4LqbvLdQbOSbzGYgQgAAEIAABCBwX1GsT1NQxmUcAQgACEIAABCBQ 5p3+ovg9JgQBCEAAAhDoIRB8m8wtECEAAQhAAAIQ6CFgod7U3qm8U47JYEUQgAAEIACBYwSC507x TjEhCEAAAhCAQB8B805Tr2fDO8WEIAABCEAAAn0EzDs9NUFNZfbinWJGEIAABCAAgYR3epsQVLxT TAgCEIAABCCQ8E53JqapN8pw7hQzggAEIAABCCQE9TIV7rWQMK9nw4wgAAEIQAACiXDvc0JQqdmL CUEAAhCAAAQS3umHgHd6CUUIQAACEIAABHoIWCj3S0JQlYz0HogQgAAEIAABCPQQMDH9nhDUBwBC AAIQgAAEINDvnX4MhHvPgQgBCEAAAhCAQL+gfk0I6ivhXkwIAhCAAAQgkCBgYvotIaj3QIQABCAA AQhAoN87PQmEez8DEQIQgAAEIACBfkG9Sggq2b1YEAQgAAEIQCBFwMQ09WYZsntTEPkeAhCAAAS2 TUCJRiaovbV7rc3ltikxeghAAAIQgECCQORVbdZmB0gIQAACEIAABHoImFhem4fa9+5TavdiQRCA AAQgAIEUARPTx4Sg8iLxFES+hwAEIAABCJiYvvYJqnmw51CCAAQgAAEIQKA/3Hua8E7/Yf8UE4IA BCAAAQgkCJhYps6fsn+KFUEAAhCAAARSBMw7vU94qHepa/A9BCAAAQhAYPMETEx/9Akq5083byIA gAAEIACBFAETy0j93pPUdfgeAhCAAAQgsGkCJqgXiXDvj00DYvAQgAAEIACBCAET09uEoPK6tghI 2kAAAhCAwLYJmJg+9wmqKihtmxCjhwAEIAABCAQImJimCjp8ClyGJhCAAAQgAIHtEggmJL3fLiFG DgEIQAACEAgQUDnBvnCvfUdBhwBHmkAAAhCAwMYJmGDeJASVhKSN2wjDhwAEIACBAAET06c+QSUh KQCRJhCAAAQgAAETUxKSMAMIQAACEIBACQESkkro8VsIQAACEICAEyAhCVOAAAQgAAEIVCBg4V4q JFXgyCUgAAEIQGDjBExQv9nnn2Mf3jCzcQNh+BCAAAQgkCZgYvnehPRXQlBP01eiBQQgAAEIQGDD BExQP/WJqX33umE8DB0CEIAABCAQI6DzpQlBfYpdiVYQgAAEIACBDRMwMX1MhHu/bhgPQ4cABCAA AQjECJiY/kgI6nnsSrSCAAQgAAEIbJRAsKDDbqN4GDYEIAABCEAgRsAE9aLPO7XvvseuRCsIQAAC EIDAhgmYYFLQYcPzz9AhAAEIQKASARPUlz4P1TzYq0q34jIQgAAEIACBdRLwgg5HqyNJaK3N6TpH z6ggAAEIQAAClQhILPu8U/uOgg6VWHMZCEAAAhBYMYFAQtK3FQ+foUEAAhCAAATqEDAP9Cbhod7V uRNXgQAEIAABCKyYgInpfZ+gqiThiofP0CAAAQhAAAJ1CJiYPicE9XOdO3EVCEAgQsAeYj/Y5+zN 58r+/euxj/8d62+52ufIvfb79TEyHtpAYDMEAoJ6thkYDBQCFQko4W9PFK87gbK/ubs3wvez76F2 Id9pDJ2Y3/hY9RAgAUZ4K9oVl2qYgP0RpGr4njTcfboGgVkI7InlF4mH/R09uKB8X4gA9h6VG2kM WmskurcuuBJb1pdZLJibjkIAQR0FKxddOAFb6HfuXV24YCrXQGKwBm9yDjHtu+cvZ3unnA29m3nh 5kP3t0rADPlb39Moxr1Vy9jOuF04r+Q5+cKuBb410dlafzQHT50nux1rZKSLJiCjTQgqSUmLnmE6 3xFQeNE+n93j1Pt/Cc8u68Hh2QVWc/gey4ZAcwRsUUkdm/nSXKfpEAQCBNzz/GI2LvEkVLss8Yx4 5IquKQHqNGAONIHA+ATMGLXg9BmvNeEfCLRNwL1PvYZQYdvebYyEvUcWctq0J856YNIe7Hnblkrv Vk1AT/GJBeYX4ZVVm8AiB2c2qbOaElAdQenNVF+ggL49S/rQHbk58L9Kmnp7ZrXmv/919tVYdslZ XR9bfLjQ/quYic1ukQZOp5dJQGJpxvfat+go826Zo6PXayHgWbfn7oEuZe9Tr0XshKc7KiKBOt8X wTXMkT/gdEL+W4Qlaj7+3vVlggceJTfpTOyHNbBmDI0TMIPWHlNvWjvG2PgkrrB7Hj1RrekWQ7jd UY9H9xp13OO3oKxwKqoMyfnoYaITWz1wTO3hSlwvibpVmVIucoiADCxg2A/Qg8CYBMwOPyoa4g94 LRxdkWclD/PeRbMLr5JhWtEQjK0qSil8P+XDk+ZW88oDUMW55FJGwMO+ySxIa0fGLxZTjYB7LBJQ 7csl7S/w0DfU2+m8TYVlO09zV22gXCiLgNYjtw15snqgGTqv0d9pD17ZwpRIzJopGh8l4J5B0gC1 /wNGCOQQ2FsglVGufbU5Qn2dbWv/VZ6JSgYqRMu+Ws5kztR2T2B1bn7M6MWL77fyQDXTXK/itlEv VcaMqK5iykcbhETKtxEknnMnEMnDkfehvTvEc7RZn/bCNpefbF51RGqsDG+Jth68KIM47dSu527B vdTfT/ryaNczckZSSsAXOO2Bzel9Kmys4xLUgy2d0AX9XqFa7XGPaHvf8VoXZBAtdVULkgQz+Llt qe/0ZToCtsCojJ/q3ypDfMwQXJ8tdgKqIxHsf003/c3eye1S+/JjZIZ3Xiu21qwFNNYxD/3mGKPS 0HeNDYPujEBA8+wiOpcXioCOMK9rvaRvPeihb4zEpm+K6Gm9XCs/xlWJgAzRjDBnb+Kn/YYi+pX4 t3YZ7T9mRi6iEY5UO3kEemBTCPe0NS70ZzkE3HNVWDhnXUvZp77X8RuVPMRrXY45TN9TLWBuLBGj 6too+YMntumnq/odtUBoobDP1MdZ5P3KjnhAqz6rXFAEfL9fti0xzFnfUm3xWjGx4wRcVHMXVKWd kxm3QMPSw5CHdKfKzJVtde+81Cu5dgvERpcXSsDtXQUllAeQEsuc7/FaF2oTo3dboRIztiELrLwM FsjRZ6j8Bj7HOoJQ+4l9fxFSqK0r06fzn9hG+dRxhUoEfL9V56Rrh4TltV5U6iaXWQMBLX5maEM2 9tlbbdgAFFYd4em8E1GJs46wKHGD858N2wFd+5uA/13cm/3WzF5XNEZOxgm8IdCVJ5SR5YQ+urYK 62FIDdjRyGHdbv+TkH8Dc00XygjIkRhpC0QPmmdlvePXqyDgT2+5+6oSVlVY0mudSFqawRJ8cVCW Y+2wLl7oDPPJLacl4IlMtb1WFYzg6M20U9ne3RTCs4VZNTWHeKsKA7OnMNG0+lypglFNIdW+kIop 7CYaBreBQBMERvJa9bdJOLiJGZ6xEx4OGbrP8Gy/P52x+6u+tQupEo2Gzs/bhyU9Taug/MmqwTE4 CAQJuNeaU1ku4oAQDg7yX2UzMyqdVxzqrcrAZEAs0pWsQyyN6dC97rd/8F36Pw8+leaHy6yPgB5e 9bBpf3c1M4QJB6/PVOIj0l5AQVhRXhTHbOK4/9VyzyONPAWn2nTFwNnvLpgTfro9Ap5j8mjrWepv LPq9tshUKYy/xa2Zky/qJcb0ivHkWU3lZCOdE6VCUd4U0BoChx5wFSlS7sKQBM5DYith1ZbLDtwb I+BPaSXhDxnP5cawZQ1XT6x6+KjwB6uw7i1h9yz8NIZAmICSMO1vLOeFI33eq5wOnZZAWMMzsIKG vuBrX6Eku1RlDPGY3tiDMVGx+pIHFv3BEkpawd8ZQ1gOASVh2t9draM32ibTgzBFU5ZjAuU91ZOU Jt4+0T2DQ+3ICLap8D/I50KWP+w6OvLCnky5eXMFCGQT8G2aWklMnbCeZHeEHyyXgBlRaTbwZjOC fW9ab8coeSiRkF4u14LoOQTWR8DDwSWnJPbXhHu2btZnI70jsgk/M2F4KRQHGc4m3j+oRARjVRI2 R0g39jfGcJdHwB0OPTTXODdOKHh5JlDWY3lLZjylGXCrzUo1Pp8KHzxI7CozUX4NgckJeDi4RonQ rtTrbvJBcMN5CHjiUg3jkQcnr/V86Zv0YmJjUbr90PCusgCVXs8e6TxmzV0hUEzA18YqWfysB8XT sawL+B5haeLSvgDJ81Uik9LLVXz6bAlECrN3KY6xhEmmjxDIIODCemXrWZWs/oxb03TpBLShboZT Uhgi5dUpQ1YVmU5bYuXh3ZLsXZVvJH2+pUmlLxCoTMC3yUqFVTkVvJyk8tw0fbkKApMSVn0vw5r1 gLQ/QJQU19ZbX3j3aNPWTOcgUJeABNHWr9LETp3xP6/bM67WNAEPgX4344kI5NA2St6ZVJSUeCBP 2T5DM/rU56umJ4/OQQACoxLw9bFUWDnjP+osNXhxD3WUGk6f4CojbvSKTO6Raq+45BgMLxFo0Ebp EgTmIlDJ8bhj22iuGZzpvhI9E6OSvcY+UVV27CiZsR7CLgntqt+Ed2eyO24LgSUQcMej5CgiJwSW MNG1+6gnKYU8a4tr7T0F3+soLYr9+w08tRlyPQhAYH0EPCtYx21KomB6fePoEbv10V/BiFxcVSRC VUZKw8K3pUj2DLo0G09eKRVPSieE30NggwQq5Glo/Xmy62yiIt0GTSQ2ZBe0M3l1LrI5IeL72F3+ 3UoGbB8VqSgJuXQhaQx56ETwOwhA4A8BORy+Dg5N2uwe7HdghcC+YamGcCqrNttD3RPSkhBLZ+xK ZT9j2iAAAQjUJOAJkSVn/Nl6qjkhS7+WiWkyKUj7stFxVhZS6u5GwdMOAhAYTMATJEvyOpQceTq4 A/xw+QRMTO/tkwp56OhMqNqQkpfsejVCuyoucT1WdvHyZ44RQAACYxDwhMmSNYzje2NMTOvXDIqp xPYxNRbf6K/x7kI95VH+KwWc7yEAgdEIeL6J8j5SW2HHnBFF1sgGHm2GGrqwjCUS5nXPVd5pbxhD 2W7WtjRzVzV3J63K1NCU0BUIQKBBAhUSl5REGYruNTh8upQikOtJWvvLvmv6vsPQpCP9TsdfTlL9 5nsIQAACcxGQU2FrVc6piH3PVU7Jl7n6zn1HIuBimnMe9T4hpqrONCQk0u2P7kYaKpeFAAQgUJ2A 54gMjcapKARRuOqzMsMFPTU8xxAUqjhabtCf2HI9Uwlpr8c7AxpuCQEIQCBMwPdXvwx0JuS5Kmlp lFKu4UHQcDgBmzydM80Rv5SYas8053ocfRk+ffwSAhBokIDnjgxNxMRbbXBOk12SR5j5JJUSU73o PMfTvVeoOdlRGkAAAhBYIIHCYzZ4q0uZcxO+W/ukzpjufy/x6wvz5oipqoecL4UV/YQABCAwlIDn p6hmes5627XFWx0Kforf+bGY3FJaN319y9yD1V4phaOnmGzuAQEINEPATz18HyCsZAI3M4t7HXHh y8nk/cd+01tWMFNM5ZmetMiGPkEAAhCYgoCOyZioDjkBocI2nFudYpJS9/Cno5ySWRK/3moeA8T0 NNVPvocABCCwdgK+dg5JWmK7bG7jkDBmPhEpLNsrfpliqpDF2dwcuD8EIACBlgh4YmjOqYhub/WO 4zUzzKRPWM5meDKsMEBMqVs5w9xzSwhAoH0CCuOawzPEW9VrK8lHmWqKDbYKOOeIqWrm9h4qRkyn mj3uAwEIbImAra3XmZFEre2EgKcwEgN9kymmvZm86rPCwHbN6D6swrx4plNMNveAAARWQUAep62x Q967ersKAC0OwrPIop6phC/5SjQX02isHzFt0TDoEwQgsAgCA6KLWu9VeGe3iAEupZOZe6YKFyQL MnuGcFRMddQGz3QpBkM/IQCBJgn4upt7blWFIE6aHNDSOmUgzzPCvMrkTYLPzRCWoC+NG/2FAAQg 0CIBeZy2pt9nrOvdvuppi+NZTJ88UyzqRSo7LCKmEujwAWTEdDHmQkchAIEFEfDIY3R9R1RL59aE L5p2LTHdpe6XGTpWmBfPNAWV7yEAAQgMJOAJSzkhYG3p4anm8jZoegVbJAkpKqZK345cT21IQMqd MNpDAAIQGEDAQ8APGeszoprL2eBGYuzaM+31TO3798FrdWKLmOZOFu0hAAEIFBLIPMmBqObwNhFM nQ1NJiD5k0/O+adkrd+cMdAWAhCAAATiBHTcURHCoLeKqEbRBoFKLG9tEq4VIpY32l3f07NzXgzO 5EQnh3YQgAAERiLg233RZCXW7cg8BAX10J6oNrgVj48+5egaSW830mfaQAACEIBAOQElHtm6nCOq J+V3XfEVDGZOqDaabHSonZKaeB/fim2JoUEAAssjkCmqOEV9U5xZ0GGooD6nkpqWZ4b0GAIQgMA6 CCCqFedxZC/1fn/PtWK3uRQEIAABCFQigKjWA6kSVdVDv0rPrtRFLgMBCEAAAiMTQFQrAvbzSalj NJGwb+gtNBW7zqUgAAEIQKACAUS1AsTuEgrPeulAlSPMyeDthFZvLOBN8BXnhEtBAAIQmJKAH6mJ rv8kKkUnR08rOgRsn68msBLZY2dOBf+G/dIoWdpBAAIQaJeAreWfM5wqRHXoVMoDdYFV9u5X+1yR xTuUJr+DAAQg0CYBRLXNeaFXEIAABCCwQAKI6gInjS5DAAIQgECbBAaIKkV82pxKegUBCEAAAnMT yBRVVcb7U/N97r5zfwhAAAIQgEBTBJSg+p/4+66fmuo8nYEABCAAAQi0RMCPVUbqEajNXUt9py8Q gAAEIACBpgjkiCoV85qaOjoDAQhAAAKtEcgU1YvW+k9/IAABCEAAAs0QMFG9trBuJPyrcrRnzXSc jkAAAhCAAARaI2CCehsU1VfK0rY2e/QHAhCAAASaImCC+hAUVdV65zhNU7NHZyAAAQhAoBkCEkkT 1OegqN4303E6AgEIQAACEGiNgOq5m6C+RERVCU2t9Z/+QAACEIAABJohYEJ5YoJ67I1k+8lLSlI6 aabjdAQCEIAABCDQGgG98tNE9TXgqVJJqbXJoz8QgAAEINAWgWiJQmt33lbP6Q0EIAABCECgMQLm od4HvNSfZP02NnF0BwIQgAAE2iLgmb/fU6Kq4hBt9ZzeQAACEIAABBojYGL5KSWo9j1eamPzRncg AAEIQKBBAiaYdylRxUttcOLoEgQgAAEItEXAxPKDvNCEqL601Wt6AwEIQAACEGiQQKSIvsLDDXad LkEAAhCAAATaIeAJSikv9badHtMTCEAAAhCAQKMELOSb2kv90WjX6RYEIAABCECgHQJ6H6qJau+7 U3m9WzvzRU8gAAEIQKBhAiaovSUJTVC/NNx9ugYBCEAAAhBog4AJaqp6kmkq/0AAAhCAAAQg0Esg UuNXr4EDIwQgAAEIQAACPQT8nam/zFM9updKwXxMCAIQgAAEIBAgYGL63Ceo9h3HZwIcaQIBCEAA AhsnECjywD7qxm2E4UMAAhCAQIBAoGD+L17pFgBJEwhAAAIQ2DYBr5qU2kelDOG2zYTRQwACEIBA hEBqH5W3z0Qo0gYCEIAABDZPwAT11j59VZMeNw8JABCAAAQgAIEUAR2NSQgqdX1TEPkeAhCAAAQg 4O9ITdX13UEKAhCAAAQgAIEEAfNQe1/nZqL7+dgl7LtLAEMAAhCAAAQgYARMUB/7wr7HCuXbf/9q v6P4A1YEAQhAAAIQEAEJZp+gSnDfkpJnqt/goWJDEIAABCAAASegkG5CUP9KTNpvb///BJAQgAAE IAABCPzPQ90lBFWe6M692U/WtisG8QpACEAAAhCAwGYIRF7DZiL5vU9U5ZXa59Ta7L+YnDOqm7Ei BgoBCEAAAr8JmBDqheJ3qt97CIl995DwUu/s+x/7baiihHFBAAIQgMDmCHhY98UF8YcydO3zsQMh cUwI6r/OqtpvzjYHkgFDAAIQgAAElEBkovn2zOmL/fcr+1xkCipvosGkIAABCEBguwR8H7T3DTNB YX3ZLkVGDgEIQAACEDACJqqp+r29pQhdcCnogDVBAAIQgAAEhuyZ7nuuChFDEQIQgAAEIAABI2AC qczdiDd6KCHpBIgQgAAEIAABCPwv9PveBPVpgKj+VTkJmBCAAAQgAIHNE/DjNL1FHQ4ILgUdNm85 AIAABCAAgX8ROHKc5mgomIIOGBEEIAABCEDgCAFVUDJPNHSc5li1JeBCAAIQgAAEIGAEgsdpKOiA tUAAAhCAAARSBExUU+9G/Za6Bt9DAAIQgAAEIGAELPTbd5yGgg5YCQQgAAEIQCBCoO84jcLCkWvQ BgIQgAAEIAABI3DsOI399w8AggAEIAABCEAgg8CB4zQUdMjgR1MIQAACEIDAHwJvjtM8gAYCEIAA BCAAgYEEuuM0FHQYCJCfQQACEIAABDoCOk6jd6lCBAIQgAAEIAABCEAAAhCAAAQg0D6B/wLDt1WN M+VE7gAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image070.png" Content-Description: image070.png Content-Disposition: inline; filename="image070.png"; size=2758; creation-date="Wed, 10 Oct 2012 09:43:28 GMT"; modification-date="Wed, 10 Oct 2012 09:43:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAD8AAABFCAYAAAD95j54AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAApbSURBVHhezZrb51VpGMc3Y0j8RCRGJBKRIUMi MiQSiWEu0kV0MbqILiIiuoiILiKipsN0PkmnqTn8b3P4fp75Psu7d2sf1v69a8/68Vj7t/da7/sc v8/hXaPRwP/+GY02/D0a7RZtGTirddmT4F9J6EO6/qjr0bqrD3w1CbxHdEJ0VfTD4NiVVTbZLddq MoebI7DolujmIIUv3PIYiqihAK3zNW4uuvjXaPTnoIUXc5dF50RVFKB19otOSfCPFv4elgf8aii3 2hpm9KKun2soQGtst7s/luCfRW8l9C8WfmM1xmssJKb2is7aQqmA4/pua9f1JeRGPcezV1lPhNBv hiz8LrsozP5qJeAJnRRAWhN9r+fOeI2X+nx76MJvwyXN8FN9frmMAvTcbvK5nn1DrFtwhH85ZMtn SnoHo2a6kwL0zGbH+U0J/rsIgEPwYQvvOCUfA1BvSqYX8QCntSN67kLhPSn4sIUH1Gy122L+fSF8 MD5PARL+O9130mntw8TzsYboGXvUqiO6AvHM+8UYBcl1CfCpjflSAZMC6P5jIooZYh3QJGO81vVh EUJ4FN41vObGKH2ZeC2F1/939f9bC0+ZigA7Sk3qf7IFmQHL/qTrNd3/yoog/sn1wxVeDO/LmBWj P4vu2OX/sMuetXDfkdIm3cjd2zaHAJ6Akk6JLoP0Qxf+WzGa+fm5mP3N6eqSBTmEy4rWsLyFPGiP QVAEPiiib//GxJoAIb/T2R1ftrz1TID9Y/3aMb8TS9lVaUSum2GE4rcdhSAn9fm8iDa1JBR1xsIi KEC45q6R0Jgb7/YghGQ/lIdCI6RM7E141SuTtWAUOi5GTnsjNkfwoxQvuoIJGcsA2yfRh4L+MDYA eLSwuc4+0mFLqNBKsy/WPFAoFz7Yj1Cj4bpuvsreo16DZLfKWEXbW80QGr/iNEb8g+iPwAV9LnN5 fNb390XPDHJ4EMUO1iKbbE4FWOCwpkHygj5fTXxID9QVhRKCrIVn4QVzPahzWGhR4nmz3RRFYDkK HzYmdYH8Xwg87TsrCe+g1KVdbnoFfUbBURQVRF/xVt9TWzwU3fMVpV9DUaLtnQVb9IFCcJglRcE8 ndnCQpf32kMi/+v7bJaI6Z127XcWeJoXZepF8N2LyjHzPgu5pYxFWx6Lh+AimCblLSX4xHNZKQKU MTDRlVAAR3DtMa9CaYQOnoeSAM+pAhEHIhAS8EjCtZIO220SNfOKK66xsNMWIBOCVxK6VNxr1naM wxdgSgrEw/gtceOOMQYe+P1AW20RynBKKcEDASAsWKaimwBKkn6ji+M58nLjhvpM3NWwdpsrU/s/ 9r4YC+VTVgNq6WVUlOAERdLhtkzReIFuoDoDUQOcWgi3alISVmUzXWOiaheEiRv6nnK0E7B1UZTW fuD4B90pgEin8I63PReFd4ioF0ixs/M5mtGN+w0gCIACprqt4wkEJf5wv724oplimNGL1XNdeBO9 svXJ82n9rBNQDEXSpoUBTg8Q67gxDxNHWLstHyMgsUchwaECmzOEaOvoqiuC7GFFn3HIYv2oLnW9 Yhk6zw/py4lf0BRLomGU8KC0pv4npmOULJp0u+rCtnmSFX0jLVwYDZ52LmzxlrKRCSqNyAlXTLh4 uDOgQlzrMzkXMGHgeEnf4XKtVVsb8xW+Y8CRgEs1CfKTZnctLXg+SGrQQgAhmqS/ThzIig2QSZfH 2r0h/BRFBR8OveUtPUtT1igKOE/6wML6nKkGbTO1BRyxxEpc3h5ID4DwDD/2rtva0xbQ4hRAVFOn jbKACv9zsnLCQINCVia8FQDAnZ1ZvdXQijbY4PimYjpplCU7xEmNqBw1r0QJVnr/wrsSBAdwdWoC aoPBCC9e6CgBPKjupKbNe/5P4V1o4fZUchRZTH34nGOzOh3cDCwA7WNuN1kL9B3/2o9+HeEJw5gW iSIr6XrDWSA8tEbYf7GGNqGxCMATPelb4In1GZJmidtkHWck6hAAmHRMN7pWTQHElGOe4oI0WJ7R rQTstCd1RZ4DUGWSiTACIzLSIKU2fBEKlN/b1qUACh8jPgJT3VEJ8hmkX1mRI8Huut44b36wLnNC qsxoa11t5mEJQ8woxZdWgB7mVRFcCevGyYuIMpijppWVt9rrBVYtGquYGuv7NgPkBOiW7+esoBsO aLM9fpjJKqBCO4vgOcSgAeIwsVe3x7IiZgkMWaKWxyDmqbWdNjiCA/DHgIM5QDMJnukNtjCWxp0Y VjAliVNT/9Y2TelFCdqbYQWxjAfmoUS8sWVXh8ec2pIRIDwlD0HLSfBsHNBDCWqMinBtACWnKWn9 sq3trcbXvtnHM2+IKY0NgMBtE6jmO8IiSc8AlCjvyFSrMwmxazEhZaHSrYmvtD41fjlJHev/a4SC rcl4KhF+q/mLQxERoJazR65xLDWD8Nb2bpBa3rFxzoI301G7f1qfjcrYx+WI/2q1fiE4ymbG0Iyh XdmVU2ZAuZxAM+aiMQuai/bu5XnZl3Yx3oNrs55jP5GfGT4lJhVXHjfdX6/V7epYPAQXTR9Dz5Vs gRvYQAQqchpCD98cPBhteWOCCus9XmElUUrS+PAsTDJsaCZASyqBPVgDL1qJ4IBXWg+AQ+PkSoaZ ceBn+giA6DeOopnvB3hYAeRShps5AeLZRx0U8FT3U6Fh8SxQUC4Ah0vXn9ywqCgqthI9saKIGT25 dRJMAA5ibixv6n/yL2txf64XJyuiJ6JMQ3nluxyYUkewH97H+qwF5eFnHJQs4MSL3eJanY1IIwhJ 6UjMN4jpUpK5HtonxmeecaMQK4Y1ECTOydvSkn7Dyrg3yJ1IzV4YhKIEbyTdohjWqtuyakFQG0bZ jNhFSN6T2bSYCv+7S89k8cEVBfB2BWCY5/d5ph6paULJR3xveb5Pjw7+5KFEzOu78LSSe50iY+Ap 4nyez5wDIDxph4kLZwNlOkolMypjQpRTYTqyPEIjJGhosDzeeWAlAnXZJKuuwr2Z7AKK8TaWiVzM S0ljDYYFx+tw+1sJrKQ7/R/lMjWEroDg4S58reTeCeFB+QbEXBcAZFiOGKaWaF5Ls0dkh0ZWoSYf 6xG8Bso8thKBumxSCi8Gm8NOMc2A4QUpzK4LqB4v187iyorJQmmsUtSzzRBj0nO68Nnbvbi2a4Cx k14xHi8NEMd2/y8Q264fR2WiNgVQZufza70JsezC04TX93R8xOwp0ua09ecogDP45oxuWR57e65N eEDL7n6ReCU8ZjEwQwF5VhizhN6EWHZhuzRVXTREuubLQdmObl9k7SkKoBLsp9BZhKl591h4Xlbg /RnQmtjHVYnjffOenwBB8n42S2AAk6TVnNF1YTTvLYV3HR/Miqjeug0PtaizQKmALHQOLsNfr88U wpPWGBxe83fzhwlTOJtUgNajBxheoSOmGGnh9ljomRiPd3fWq/EJBQCcY3XCetev8jzujfBOa6dJ a2Ult55NCgWA9oN0+xQ+33KuXoxI8LFXX9ej0KrP2vJ0dcPMxVWlnViMdGbB9/e5z2DXxi0Hy1zB 2L/FyGOPCfS9fwAAAABJRU5ErkJggg== --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image071.png" Content-Description: image071.png Content-Disposition: inline; filename="image071.png"; size=3998; creation-date="Wed, 10 Oct 2012 09:43:29 GMT"; modification-date="Wed, 10 Oct 2012 09:43:29 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJsAAAEWCAYAAABxOOU+AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA8zSURBVHhe7V0hcBxJDDQMNAw8aGhoaBh4MNDQ 0NAwLDDQMNDQMDDQMDDQ8OHDsP9XV+m+Ls55R7O3u9fS9ldd+f9vb7fV6tLMSJrZs7NE//x7drb5 5+zsm/29TgRbULMxYAK7N6H9sr//2t8X+3uezQbhJWfAhHVlnx8Q2f7HI9w7cviCl4EBE9Y7E9Tn 1yJ7JbjHDLYIIzkDJrTHIaHtvrPrvpKbInjsDJiYLnZztJboJDh2bybAZyL62BKaIlwCR2aBaGL6 1CE4DL1aNGRxLiNOi3APHYJDHk6CY3RkFkyYl0lwWbxVAGd0heqJX+TmlPgt4PeTmdAZ4SS4k3mq yINHCO59EdNlxikY6BQcaqmbU+DUM4swYIL70rFokOCK+P1kZnTm4SS4k3mqyIMluCKOzGLGCMFp 0ZDFuYw4bQ531zGHU1qE0YmZMJnYbjoE96zSVibvEmLtFJxqqYQ+TAXJBLft6IdTx28q7xKCNbF9 6BDcHaEJgpSJgWgDJkSJzTWZbBNWQgaiq1TfIqiUCKEPU0GKlrbsuu+pDBNYTgai/XCIhJwWCFUa Bnwv6h8bnl/n5Uxsf9n/03CaxrOkQNFqZGL6u5X4xbBLaoJgZWIAObiA2HCuyCaTXcJKykDraAff x/BECl+wMjHg8zfMzX47sObAfyu6ZXIsK9bIcIrWJVb8wpWMgUPHce1HNyR6k5kkuKwMBKPbNSt+ 4UrEQGTuplOSEjmUHWqrlIW8HLsNwpeEAYtul61VqTpCkjgzA0wT08+G4LQqzeDIDBhbSV77/jmD HcKYgAGLatetodS+P09giiCyM+Cr0sECPdrM2e0QviQMmJiehqKb+tySODIDTBPafUNsXzPYIYwJ GGhVE1DaSmCGIGZgwMR20YhsvzLYIYxJGAjsM90kMUUw2RlodYEgRcJug/AlYSCwIv2YxBTBZGfA xDb4gg+lP9g9mAhfIP3xJZE5gsrMgIlt8Hw39bYxey8ZNoktmcMyw5XYMnsvGXaJLZnDMsOV2DJ7 Lxl2iS2ZwzLDtdXmbaM++pDZPmEnYgA74LUXgcghlaEEKgi3le2XbQsyoNrogmSv/VF+iPObJxtp /+jaFTKR/TZX2wR2WL2b6HG6zZoZUFv4mr2/sO0osivtsTDpa3wcNiC3WsKRg1sjN7J5YgZayVyP eBcTP1a3WxsDvht+8GAZbeNbmypmsreVyEVU0xA6E/lrum2r8O5CwzsRlPJYkzCmtrV1TNZuZYqT Kad+tu63EgZMRO9bZak9oSGq6T1WK9HGZGZiKMTuKZyRG6gU7EpWN5MB0I3WwQDmZq2652sBIvqt gx1ZeTQDntK47RWZLwpeNHwe7YL6N4BI0ARpIou8m+qPDg8X56Y+U7JwNAMmsAvUN1tlp0b98ztK V6NB6Ie1GTBxXEZXl61Cu/JptbUy2roJRfaXiVWnE432ROEfeofGYDtQJLXhwy02uKg6UFgvo03z FEZPnuzQAuCX965pETDaE4V/6Fn/b5GI9dY1SOZ6iUoVgcJaOcq0Y6MZUiA4xE+rzKPcUP/HKIKP jWb2W/SoqdxUXybHWeiLAOS83txWNzBc/rDvtsch0K9XwYCnNFAu6hIaumklslVIZBojTTAfeisA Plwqkk3jgnXcZaTQPitPtg59TGYlMvg9Ec2ufbbP1WQAdKN1MOBpifD8zK7XGWnrkMa0Vkb3AewW C3a9NgpP64J13M1LRqGI5tl/vcl4HdKYzkrvoA2XnryZUbvRp3PBOu7kydrnaA5NXbPr0MXkVprA Np54jQ6dSNKqaD65J4rf0IUWrgogtaHCeXFRzGGel5/CPWgmNMzn1NA4hzMq39OrAj1CQweuhFZZ FHPYNqIq8HkOHLpncQaQfI2uOHEdqgjFKZF5czBg4mm9JeX/1ajXQ2/mwKF7FmdAVYHiDmYxr1do WKWyYBeORAx0Cg35NgktkX8poHqdM7xhWOUnCrflAzGioK7yUz43nx7xCKGp/HR6t+VDMEJoKj/l czMHYpt3PUUTtqpzcvgsJQoTT3iHOlaoKY0U6NMzYNHsviOiSWind1lOBCiqS2g5fZcKdefm4U+p jBNYHgY6Gx8lNB7X5UKC/n+LaqHj3bUYyOVbOrQmoNCRVUpv0LkuF6BoisN3S6mNO5d7edDijLPI ytOL6tpqx+O6XEii8zQch2DXapd6LvdyofX51+AmYrRy20fHVXG5Lhea6CYVbU7J5Vc6tN7J0Uxz oAhPB16AcjGAaNVaFHjO7TyXZUJLxQDO1Agmb6+pgAtMPgYiczXk3fJZJsR0DJiQBs9L86inxC2d 55IBQq4sMFe7S2aW4DIy0FoYIKemU4UYPZcQU6sGqm6OhE5lhdyqGGDxwIpduJIx4MX0ofKU0h3J fEoLN9CzJrHRei8ZMBPb49Bq1L7XaZDJfEoLN7BAQL1UPWu0HkwEzMT2IZBnw4Ew54nMElRWBiJ1 UW//VoRjdWIWXK3E7i7yQZSIhFnsEk5CBryXreftK9h1pVUqoS9TQIJ4WnO3199jaLXPxxQGCiQX Az0Hx+wLz4dXvKt9w2WR0FAzYIIJv8PgUCT08teNivfUbuYBF10wNJLBf9t9HjS34/ErLRITylWg bhp9byhWsRIerbcJgPnehPBJk5EFhs/vJDwC/1JCQDdvqxUpIrQDq1lFPEqPE4AysVyimXKMsFq/ wZDtddpLAlMFgYUBpDjQDTLVnO5AxPvpq2KdJcLidAYcKF8h2tkHexVCC4ae6+y+2PmlVAqDs1kw +GLi1sUxh+h2qRRFOxanM+DwYfbOO0XmEJ6iHYOj2TDMKTwTs6Idm8NZ8EB4qL+aSLAAmDTi+fC9 ZbFVOIgY8Nzdl6lXtC7kGyJTBYWJAdRPUc5CdWGqiOd5OxwDpjNKmJzNhMXEsZ0yleICRifLOZOd wkLEwF4qZZL5nS8mUOfVPgoiP9NB8Q6USRLHSD57WUyRjs7TRICmjHaIdFgZa05H5GBWKLtod+yC wlfDSpmwOpoJF+ZgGBaPrc3a77Fj7JLJNmEhZQBDLDpFfHgcnTBGCkaLCFIns8HCHMwEg7rs6Jyd R0mkS5SjY3MwKx60Jh1ToYBg7aMTAFgdzIjLE8Wj83VIMispzOhZYkw+vCLl0T2nU5QjdiwrNM/V jd4xpijH6lliXN518k1RjthJ1aBhAWAfHHY4ZmjVXK6aIJawxwSH/RPd6RLN5ZbwTsFn+HwOpzGN jXLKyxXUxawmed21O1Xiw7F2f83qnYI39yjXvfvfy2Uq7BfUxOwm+QKiey6HOu3s4PSAegwcEeWe VHmop4dFLBoT5bw2e7kIQD2kFgNjopy3ouug61pSWM4az8t1HaaDJs/lEOpJpRhAZ29vC5Ndj3mc 8nGllLCQMT6soqU8nAg2weFgnPOFIOox1RjAENkpOCSNN9V4kD0LMeBNmuF+Oa1UF3JM1cd461K4 1OUVh+uqfMiumRnweRwWAqF5nG+w2c4MS7evzMCIedxtZT5k28wMYN9DNML5dZ9mhqTbV2bABPfR h8rQsKoifmU1LGCbCQgHHoZXqhLcAk6p/AivOPS0K2lIrSyIuW1DItciXDg1ogg3t0eK399TIyhZ aQ5X3NcU5qEYbxGuZ9+qhlQKzyUFIcEldVxW2CMEd5/VVuEmYKBXcMjbEcAWhKwM+KIhdAyEJ4iv s9oq3AQMdAoOCWJtiCbwW1oInYJ7sev1EpG03iYA3ik4DL3a00Dgt7QQELGim2mQr0trqIBzMOBd v6HivQnugQO1UKRlwLtFQvtT0TuX1lAB52AAebVIHdV33l9xoBaKtAyY2PBSt2bhHidhaoWa1s08 wE1IofPi7DpsmtYKlcd1+ZD0lLV0rkg+/9Ih9hxctPlyS2eAAOViwLt9mykRr6GqpJXLvXxoTXDb 4IIBUfCczwIhSsUA9icEBfeYyjCB5WSgo7X8htMCoUrDgC8Y0P0xmIPT/C2NS7mBmtBwAmazpOWH ECr/xu1OfnQmuJtWdMP3JrjP/NYIIT0D0QoDivv0xgggNwNeYWgmfFU/5fZjGnQmpKvg/O0pjVEC ystANP+GxDCvFUKWhgHv/GilQ36kMUhAeRnoqJ9+4LVCyNIwEOnwtWs0d0vjUXKgEFMg/3ZJbobg ZWAA1YWW2JCfy2CLMCZgoFWs91SJdtYn8CU9xEjvm8pY9G7MA9DENHhCklcVVKTP41JepJFCvQlO b5jhdWEeZF43HTwWH9Evj0VCSs2ACa650dkEpyQvtReTgDOx4WSkwSZLJXmTODMDTGxebuXd7Htt /8vgTHaMwSTvF3Y7hC8JA60Slg+150nMEUxmBrAIaA2lds0dsw3CloiBSJI3kTmCysxAJMmrTl5m DybCpiRvImdVgBrcq3BdwVbZcGIGlOQ9sQPW9nhbKDy0VqbIza2NF9k7AwNK8s5Aqm75NgPBTl4l eSWi4xkIdvIqyXs81boDGAgkeV/ElBiYhAGUpwILhe0kD9NN1s1AMMmrDc3rlsl01gd73TbTPVF3 Wi0DSPK2hlIIcrUEyfBpGQj0umHTjLb8TUv7Ou8WSYOoG2Sd2pjFat+w/ObZbtoUMwvt67wpjmIY mrvpbJB16mIWq01om8BCoVlR8PZzHVgzi5cK3TRQLx3cPY8ksX2eC1EiU45lwKPYH6tLE0rkvfSX r5/vyeFd29LNsfj0+0IMuDh+vD5UJlhR+O1tMfabc0QzDME+r1OKpJBWJjFlt7XP/r4gou1u2qoo 4PrdteiLw3/v5nr2718nAaeb1GPAxPG4JxREOuwtbR6R6tdsPZLtp0uu67EkiyZhwPcj/PYqcBPQ 9wMi+i3/dqg1aT/iTQJON6nHgAku9Ga/VlrEvv9Ujx1ZNDkDiGYBMQ2+OQYr3MmB6Yb1GDChXLSG zkZ14Xs9VmTRbAyYmJonVL4luP3V7GwAdeM6DOxyb73DqQkNCwzl1upIYRlLTDhXI8T2sAw6PaUc A62k7msxQqDlSJBByzAQKVntJYJ/LoNKTynLgIlpGxxO78uSIMOWY2C/lDUgPPWtLeeSuk86VMra F52J8amu9bJscQbQgjQQ1baLA9IDazNwqJRl/09b+2q7/TTWHSplIT1yGjR6ankG0NHxaji9LG+0 DDwNA/ulLPSynQaFnroaBnalLPt7txqjZejpGPBSlnJrp3OBniwGxAAFA/8BTUcK+ry74H8AAAAA SUVORK5CYII= --_053_6774667080697367696578677167697876667775686673747865687_ Content-Type: image/png; name="image072.png" Content-Description: image072.png Content-Disposition: inline; filename="image072.png"; size=2631; creation-date="Wed, 10 Oct 2012 09:43:29 GMT"; modification-date="Wed, 10 Oct 2012 09:43:29 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAADoAAABFCAYAAAAbz/U8AAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAncSURBVGhDzZrbhx1ZFMYPY4gQYYghQoQITTQR IjQtRBghQshD5CHkYfRDmIcmDCEPoWnyEELIdSbppDNJRC4zucz8b3P5ftu3yj7V55za1aeqp5qt 6vSps/f69lrrW5ddo9FA//4Zjb7XOPLvaPTtQEWcXywB/E7jgseR+Wcc4AzS4DcCeEbjusYVjYUB ijm/SAJ2VOOyxvtBAZUwhzV+wKfmhZmZ7L2/R6O/hgb0vAXium2wuckCcohAzwngXY2fNc5L4L3b 0WxusgL5aYhAMdt1jc8aP2kAfE8bsDWT/aLPG4MDKg2ekmBrFgyw1/BZ/X93CdgJJvtMcz31fJDS MFhXgixjtvard7r+LuF/NNjGYF9j2bf6fD8DSiw9WLJhvT8jUMclzHUDfaTrB8CaoE7PymzqJqvf PRwsUAl2DHM10Me6PtD4QwPtEPCXMc/6jk8yWUAOGegCpmqgv1jQh4DV/abGJY2lOtBJJhtAMzIa julKKBKGKwb6NNMK2oWcNrURF9F8Dlafz2rcjJip60d9fqnrY11fmIwGBfQgQCzw80wrmOEbC0z4 uZD7q32b/7EJ5LV38W3P83WIQCmnLliwFzbdJyYkNHrLII9P8NPdtgiYO6oVwtNt+/i2NaoN3KV5 WsXzmcytyfYZKOTzSgL+pvGn7jFByIgEAq0HqCV9BliME7pf0GDDDmrwmXQSkGRau0pCBxmZnj/k 35PExMbtK/l94zMGgEZfA9CaJB1kIUCx+Gl/JgHgu7VsoEH+z/OUZ2wKpdq+aelkfO8NYo3YGObB DW5rrNstuonDNhF87VdNjhZZ7Jx9MEwScCmtqw02Jv73mk2wcGfqIAGusehMLGnLickN3VPtvI25 9JkSDzmWGzXV5gHv6EqmxUXfk0iEAO/0P9j0ka4pXjIcd5/pPj1nIdEyWjqAHID2BvB/rIEN/Wxg bBaM/UqDNeAFZCENbczM2uAcaVJ8C+0lH7NQsCiCAwDBKnDT7r0JpJH87qY364Cue3y/qe9gZAAR irCiepKBhrddRRUB1wInNUgQMFN2uh5uGsFacEAEWDRLDwk/v+F561ZBzKbqoVzcNlOXgiQVBCS7 jlmlLGmOEWAp/UguDttSMM2XmSZJOcmtN/z9YpHAkx7C1jURZMA4okE4YKQ4lQnBzmJaT+YAmPsv Ieu9AbAuoeqO5v+UzZ+e0ZiaV1eYDGR/BiBiHTsZ8SiuaA1SiIkJzJgXQR5zrfxmXrAmKkwSAkKW Y1leTd1KLh018NnGmKuHiV8AQXhArHryxHCEjpy+7T88AwGdNM2PmdS8ILPfY6bMzQaTTCAnHECF RGICaSU/bjRZgFrY96bsiG3knlB3lfXo/g0L25zSwt4IFn7QIcA8/ACIGHvKcTQV+vrfPQM/1AjS cYr0DK2iUcjkyzQyMbUTLthZNLriRTe6Bhnzaf4PGahESmyur1ty6Jmg7acIjolAKuzimPD2ma/s rgbEgMmQlVB7zsOwM3+LL5pZU+jQIBkALBreUtQ3apcfOXVjQtgN88ipHALgf6RXgOTal2/m7AtH xLoU+ljgobkzH03CsQBgU2GsK35JuoavomW+Q6MRwFOvp6+hdbEw5FhBEY0aa/OATQStUQ2gNVKz qC+h+tS4Nln1BjI2z0CRZbkNjqJnNSkJAoAgnFT96/5qVBD6TMWRtN336BWosx4SagpZGDnYlrBy qW+2zTfPa13DdO2jpJz7izRW+hBOH1o0aIrpLQ2xvrSa+WgCqnVI8K9qwBXdHhTDyJgyaRaT7zDQ YN2x7Egy3AGstdw+zDRpWpOT0O+YRrUWlQyMH+2Zy5HB2Z3YABrlnRfaeS+X7kDfZEShnWpNu1CE NeI6CQzJPRxCKlt0uNWkzPQ9JMCi3lUW6Q2oszEqGDoHUU0RV8nBie3cU7ZRznG4RRWztwjIlJqU bIQOAmxXtTi1SK/hRfPTpYjqhXwcM6WwrzZY9xyBfHSaSKFO/G/PyCYiFiEzobOO6Uaem3a2ryHh SegxW9aDbePkbqwPheb1XTTY0D7+fLiVZvUD4iY+QCW/aj/Jz0V7SQElfMqtbZLRvyUbGysibN4c HjMoF0ls6O0CdrEILLtiLcZxe0oaHM8iaUhHEV0OC4/JRs1Jd4EzHjI0ykhMNVqeVb8Ys9ZzlHB0 OjBjZJ3d7ddDyRc1qGQo26JhRbDGX6OF0kfRzQEVTS8qJNaiV0z6GSCi20+ng65IJBD11s+JpvoU 8oHloHJMIQ6QYDjMApAQUx+lWhwbksSn8xddqUPrIPBZXAjXIraTyKQmXlFMhXzsh3S8MZ+cWalP ozPH5ABeR+MaczfG7JdYz7qBpW591gnp5tDIE5JPkn3AYvhC1QsylSMIu82OsovsdGoiaxR15fX8 JJ9OjW99F43obvPY3Ia1SNWTseBjXXEENOVHAU4XPVUzGtFvqk6+pwCaBJIjR1wkNAn57O400wmg WgShx3q01iA0Dzmg3fz0K70H5Dgb/aZ4j4/nS7SLP8KeEA9WgnXQ4YguB/2h7hJ2OzzkEwEZM0yv qnmn0SC7DcvFeSZFeeqnGizkhKAQWJyipZMufX6ukWKdPgOOjgVmCgcwLxbBfAAkOWGNVJ1odOqX dNTIFWN30QbH8lB3sB2CELgTu02ibf2f06/ISdkU4uDY2ajBYb50E6PRBsDYKPq20dHo7tCIJNhg CLB5PKIagJgotPfMikcGiK/i44QmAOfvJtRDA5/RHABTC9OgUyMs3MTJSlmDuikFcjgBEIKx8P7G bCKblJil3+DbaB8TDBD4L4e4bCTACUdciXMQDZ0L1uX50CLuQqEdxTap5zDeB7QG42iC3JR4ypkI QgICbcGie2sMjxtguqFFCCyFMogMzdqdFpuUtSPf14CScCeiMYlRTq1ZYLReuYDulzJeoErJm9aU XoSb1CfaESBNi+RAJVi8oYlmYOo4qo/+TpVg+3cQF9wACabfxjBQQs6WV+yaZOrl+wAqwXgFp16I E2bemlSO1gWw/8Lmqwb2KgNKZwFmXu5F8LaTZkDT8WImaJzVQFIw+MTAr+8iUYn3flP3gEQCs8fH 28rUy/OTgEpIfAyNRNCfeVCr53hzDB++Zc2SVJBskEyc7UXwtpNCMBo0y3KNzjTZKclGlGJRDVVv mrSVqZfnBbL+PmCRyU4BS3JCSIr3lCCnsTdDewFRMmkNKLGw2GSngCWxAOx9x2SAdtevLQE1RbC8 /Un8nMqypWsIJO/90XGMJlfzyxilk2/3udCorqlZpetMli1dJ0sPB6dRQBaxbAlYwpHmw2fbN6NL Fmj7TO6j0xKDtnMO8nnHQMijE5MdJEiEcsIQr+P8/6TR504Z7MzivM/1m+b+Dxj1TFz8khAPAAAA AElFTkSuQmCC --_053_6774667080697367696578677167697876667775686673747865687_-- --_002_E045AECD98228444A58C61C200AE1BD8221C21C0xmbrcdx01ciscoc_-- From abdussalambaryun@gmail.com Sun Oct 14 01:32: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 17F4321F8574 for ; Sun, 14 Oct 2012 01:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 j6GDYiirXNiW for ; Sun, 14 Oct 2012 01:32:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1B21F856D for ; Sun, 14 Oct 2012 01:32:34 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4797109vbb.31 for ; Sun, 14 Oct 2012 01:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=kzeSMNrV6y6tGwMilHv/U/e4H9/U6gz6HbPF0MiiGuc=; b=YpXl7IKX41rPPNtL0E16157FfdIeNZBYl0TmxHq4Tc0ugMiZrkj1OgKvyDHdcMn01y fZZ0reUmzx6fIW/oogl5/3x2vn5GdS41xlPg3Mc7faobJKWa3EwBa3yTh15CjkyVD7pJ MDxaNdt2Xe7hakLWAEM9YW2tiMrjEnkxNVdz6n8yfoWVwEaE+3Lbedl/jKmtnNHYXm8a TnFiTCm392nDjVJXE+qbgH4ZO3Yp2Mnbvlb6De2WyNxfqaV7Iikx/x+pCgFQdL02wLiF mnDvL2HY73SOx95oR3G1Faqcavx5IzcyJ33m0HRcajJlnJibeGTjSRytRezdfRf1eglP 30tA== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr4139307vdi.55.1350203553928; Sun, 14 Oct 2012 01:32:33 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sun, 14 Oct 2012 01:32:33 -0700 (PDT) Date: Sun, 14 Oct 2012 10:32:33 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: [Roll] Is there comparisons reported between RPL and LOADng 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, 14 Oct 2012 08:32:35 -0000 Hi Henning, Related to discussion in MANET WG list> Sub: Re: [manet] MANET meeting at IETF85. Read in line >On 10/14/12, Henning Rogge wrote: >>On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun wrote: >> It is not right to think that >> authors just will change words from LLN to be replaced by MANET as if >> they are the same networks. > >> Also we should notice that LOADng is not >> better performance than RPL for specific networks as *LLNs*. If it is >> we report the facts. > > Are you aware of some comparison between RPL and LOADng based on > testing? If not, this makes absolutely no sense. > I already listened to many discussions in ROLL WG and with results presented in the IETF meeting regarding RPL performance. Please note that I have not seen any LOADng results presented, I already called for it but no respond within the IETF. Yes I agree we base things on testing but only testing that are translated in engineering documents/reports to make sense. Do you have a pointer to a LOADng report for LLN tests? please help or respond because I am interested to make things make sense in IETF. AB > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From jvasseur@cisco.com Sun Oct 14 04:54: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 AA64121F8495 for ; Sun, 14 Oct 2012 04:54:26 -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 CHV-lfOz7kio for ; Sun, 14 Oct 2012 04:54:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2521F8491 for ; Sun, 14 Oct 2012 04:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1736; q=dns/txt; s=iport; t=1350215655; x=1351425255; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vZSJqLSsmS6y/Ux0k+olmZVSEcOryuj0NSmUCC8C2bs=; b=cdxj1OaPfzIdZO0xONQ0WC9fz2nYZaAJjAHukurxFyYAKY14nx2jfcq5 SFpPpdhUOF5T8gjigvCFlXuPMeA4jVIXK1HXjA18/g5WCOngA9kEUy8+s XhastcKWUDMGHCx+Gepxcc78m3ah2ELP7dJlsJGa0LPPtak14ZvVhl5Kj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADCnelCtJV2a/2dsb2JhbABFv3GBCIIgAQEBAwESAWYFCwIBCBgKJDIlAgQOBQgah1ADCQadHo1phywNiVSKc2aFXWADiCOOXo0wgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208";a="131379285" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 14 Oct 2012 11:54:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9EBsEO7021449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 11:54:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 06:54:14 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: Is there comparisons reported between RPL and LOADng Thread-Index: AQHNqgKhFMpd1MMPX0uVDnyI1qclXA== Date: Sun, 14 Oct 2012 11:54:13 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--35.540100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F8394898763314EB6DE9E081FAD4E61@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Henning Rogge , roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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, 14 Oct 2012 11:54:26 -0000 Note that we are chartered for one routing protocol, RPL.=20 I am aware of a number of comparisons, and would enrage the authors to get = back to you. Thanks. JP. On Oct 14, 2012, at 10:32 AM, Abdussalam Baryun wrote: > Hi Henning, >=20 > Related to discussion in MANET WG list> Sub: Re: [manet] MANET meeting > at IETF85. >=20 > Read in line >> On 10/14/12, Henning Rogge wrote: >>> On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun > wrote: >>> It is not right to think that >>> authors just will change words from LLN to be replaced by MANET as if >>> they are the same networks. >>=20 >>> Also we should notice that LOADng is not >>> better performance than RPL for specific networks as *LLNs*. If it is >>> we report the facts. >>=20 >> Are you aware of some comparison between RPL and LOADng based on >> testing? If not, this makes absolutely no sense. >>=20 >=20 > I already listened to many discussions in ROLL WG and with results > presented in the IETF meeting regarding RPL performance. Please note > that I have not seen any LOADng results presented, I already called > for it but no respond within the IETF. Yes I agree we base things on > testing but only testing that are translated in engineering > documents/reports to make sense. Do you have a pointer to a LOADng > report for LLN tests? please help or respond because I am interested > to make things make sense in IETF. >=20 > AB >=20 >=20 >> Henning Rogge >>=20 >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >>=20 From abdussalambaryun@gmail.com Sun Oct 14 05:07: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 92FBA21F84FA for ; Sun, 14 Oct 2012 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 v1ijFu1F64-e for ; Sun, 14 Oct 2012 05:07:03 -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 D5CD821F84F8 for ; Sun, 14 Oct 2012 05:07:02 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7716123iec.31 for ; Sun, 14 Oct 2012 05:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PRYq1Y94x2/gi9pb3zMNNTzItdV4l4uRiyg4EDSDdhk=; b=iy5zPodS3US3q60iF/0MwjbQyTqCPn0pc7XUxMPYDwdUCO8NoKOmNwmLxO1AVypMZL +XHdOCCYL7FFCiGmbBWj/aVQztml98P9qosc6KvQDL0/Fj+SjcYRqo2aq1xsx5+X66Up 1vwH3lGeUpKmooaXIwXwRAXUNtLwDXR7CEkVenCIjGpAIj6IszHEKwFdSn8eL1V+id5R F2ubTEqCN2HQr3V7G9UkVN8OennpjtthBeLnIDCkqcKr/q02NiA8TUDLz4w6BZj05Us1 x6yCOFN3jCDdf0f8suQOUixpgS9I0kkxrpCY88MtMMfSNxLwAgwRExeE/uP25ydQFjhd T7lA== MIME-Version: 1.0 Received: by 10.50.181.202 with SMTP id dy10mr6395877igc.14.1350216422344; Sun, 14 Oct 2012 05:07:02 -0700 (PDT) Received: by 10.64.25.46 with HTTP; Sun, 14 Oct 2012 05:07:02 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> Date: Sun, 14 Oct 2012 13:07:02 +0100 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=14dae934038f39471804cc03c228 Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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, 14 Oct 2012 12:07:03 -0000 --14dae934038f39471804cc03c228 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, Do you mean that IETF ROLL WG is not allowed to have another routing protocol for LLN. Why is the WG constrained to that, while the Internet industry are more free/flexible? Not forgetting that we get answers from participants in the WG that companies are not allowed to show their testing-results of our RPL in the IETF. AB On Sun, Oct 14, 2012 at 12:54 PM, JP Vasseur (jvasseur) wrote: > Note that we are chartered for one routing protocol, RPL. > I am aware of a number of comparisons, and would enrage the authors to get > back to you. > Thanks. > > JP. > > On Oct 14, 2012, at 10:32 AM, Abdussalam Baryun wrote: > > > Hi Henning, > > > > Related to discussion in MANET WG list> Sub: Re: [manet] MANET meeting > > at IETF85. > > > > Read in line > >> On 10/14/12, Henning Rogge wrote: > >>> On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun > > wrote: > >>> It is not right to think that > >>> authors just will change words from LLN to be replaced by MANET as if > >>> they are the same networks. > >> > >>> Also we should notice that LOADng is not > >>> better performance than RPL for specific networks as *LLNs*. If it is > >>> we report the facts. > >> > >> Are you aware of some comparison between RPL and LOADng based on > >> testing? If not, this makes absolutely no sense. > >> > > > > I already listened to many discussions in ROLL WG and with results > > presented in the IETF meeting regarding RPL performance. Please note > > that I have not seen any LOADng results presented, I already called > > for it but no respond within the IETF. Yes I agree we base things on > > testing but only testing that are translated in engineering > > documents/reports to make sense. Do you have a pointer to a LOADng > > report for LLN tests? please help or respond because I am interested > > to make things make sense in IETF. > > > > AB > > > > > >> Henning Rogge > >> > >> -- > >> Steven Hawkings about cosmic inflation: "An increase of billions of > >> billions of percent in a tiny fraction of a second. Of course, that > >> was before the present government." > >> > > --14dae934038f39471804cc03c228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi JP,
=A0
Do you mean that IETF ROLL WG is not al= lowed to have another routing protocol for LLN. Why is the WG constrained t= o that, while the Internet=A0industry are more free/flexible? Not forgettin= g that=A0we get answers from participants in=A0the WG that companies are no= t allowed to show their testing-results of our RPL in the IETF.
=A0
AB
On Sun, Oct 14, 2= 012 at 12:54 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com>= wrote:
Note that we are chartered for one routing protocol, RPL.<= br> I am aware of a number of comparisons, and would enrage the authors to get = back to you.
Thanks.

JP.

On Oct 14, 2012, at 10:32 AM, Abdussalam Baryun wrote:

> Hi Henning,
>
> Related to discussion in MANET WG list> Sub: Re: [manet] MANET meet= ing
> at IETF85.
>
> Read in line
>> On 10/14/12, Henning Rogge <hrogge@googlemail.com> wrote:
>>> On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun
> <abdussalambaryun at gmail.com> wrote:
>>> It is not right to think that
>>> authors just will change words from LLN to be replaced by MANE= T as if
>>> they are the same networks.
>>
>>> Also we should notice that LOADng is not
>>> better performance than RPL for specific networks as *LLNs*. I= f it is
>>> we report the facts.
>>
>> Are you aware of some comparison between RPL and LOADng based on >> testing? If not, this makes absolutely no sense.
>>
>
> I already listened to many discussions in ROLL WG and with results
> presented in the IETF meeting regarding RPL performance. Please note > that I have not seen any LOADng results presented, I already called > for it but no respond within the IETF. Yes I agree we base things on > testing but only testing that are translated in engineering
> documents/reports to make sense. Do you have a pointer to a LOADng
> report for LLN tests? please help or respond because I am interested > to make things make sense in IETF.
>
> AB
>
>
>> Henning Rogge
>>
>> --
>> Steven Hawkings about cosmic inflation: "An increase of billi= ons of
>> billions of percent in a tiny fraction of a second. Of course, tha= t
>> was before the present government."
>>


--14dae934038f39471804cc03c228-- From jvasseur@cisco.com Sun Oct 14 09:17: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 4B29521F8441 for ; Sun, 14 Oct 2012 09:17:10 -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 MNQ1+h4-HGlj for ; Sun, 14 Oct 2012 09:17:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB121F842B for ; Sun, 14 Oct 2012 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7897; q=dns/txt; s=iport; t=1350231429; x=1351441029; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xa02+tOXo9NGit7RCnDCLte4dJYGFj06Jr2FWcwh6S0=; b=VE0mEa418xMulHa/oOncxPEQV6SNVzJ8Xm5S0LnJ3mllewjLGxjv5Qpr +kxCNzf/fiWT6emrfKXy+6XeGWB2AE7UO9DbxIkSaaE+zEruPq72MyBVZ c92e8TOwZNbtOpIXD/xQ/G9G1LyOT4Dj4QD5upfRkukfUicYVF4RO0QLG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGTkelCtJV2a/2dsb2JhbABEtxKIX4EIgiABAQEDAQEBAQ8BWwsFCwIBCBgKHQcnCxQRAgQOBQgah1ADCQYLnQuNaYclDYlUinNmhV1gA4gjjl6NMIFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208,217";a="131444185" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 14 Oct 2012 16:17:08 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9EGH8uu008382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 16:17:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 11:17:08 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [Roll] Is there comparisons reported between RPL and LOADng Thread-Index: AQHNqgKhFMpd1MMPX0uVDnyI1qclXA== Date: Sun, 14 Oct 2012 16:17:07 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FDC392@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--40.972000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FDC392xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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, 14 Oct 2012 16:17:10 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FDC392xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi AB, On Oct 14, 2012, at 2:07 PM, Abdussalam Baryun wrote: Hi JP, Do you mean that IETF ROLL WG is not allowed to have another routing protoc= ol for LLN. Why is the WG constrained to that, while the Internet industry = are more free/flexible? JP> Happy to explain: ROLL was chartered for ONE protocol. Actually we were= initially chartered t without protocol (show first that a new protocol was= needed). Then we came up with RPL (RFC6550 and companion documents). ROLL may at som= e point design another routing protocol, after re-chartering if agreed by t= he IESG, if we need to. Not forgetting that we get answers from participants in the WG that compani= es are not allowed to show their testing-results of our RPL in the IETF. JP> This is the contrary ! Please share your results, they are VERY welcome= ! Thanks. JP. AB On Sun, Oct 14, 2012 at 12:54 PM, JP Vasseur (jvasseur) > wrote: Note that we are chartered for one routing protocol, RPL. I am aware of a number of comparisons, and would enrage the authors to get = back to you. Thanks. JP. On Oct 14, 2012, at 10:32 AM, Abdussalam Baryun wrote: > Hi Henning, > > Related to discussion in MANET WG list> Sub: Re: [manet] MANET meeting > at IETF85. > > Read in line >> On 10/14/12, Henning Rogge > wrote: >>> On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun > > wrote: >>> It is not right to think that >>> authors just will change words from LLN to be replaced by MANET as if >>> they are the same networks. >> >>> Also we should notice that LOADng is not >>> better performance than RPL for specific networks as *LLNs*. If it is >>> we report the facts. >> >> Are you aware of some comparison between RPL and LOADng based on >> testing? If not, this makes absolutely no sense. >> > > I already listened to many discussions in ROLL WG and with results > presented in the IETF meeting regarding RPL performance. Please note > that I have not seen any LOADng results presented, I already called > for it but no respond within the IETF. Yes I agree we base things on > testing but only testing that are translated in engineering > documents/reports to make sense. Do you have a pointer to a LOADng > report for LLN tests? please help or respond because I am interested > to make things make sense in IETF. > > AB > > >> Henning Rogge >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_03B78081B371D44390ED6E7BADBB4A7721FDC392xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2F2B649CD519134DB6101564F1306171@cisco.com> Content-Transfer-Encoding: quoted-printable Hi AB,

On Oct 14, 2012, at 2:07 PM, Abdussalam Baryun wrote:

Hi JP,
 
Do you mean that IETF ROLL WG is not allowed to have another routing p= rotocol for LLN. Why is the WG constrained to that, while the Internet = ;industry are more free/flexible?

JP> Happy to explain: ROLL was chartered for ONE protocol. Actually= we were initially chartered t without protocol (show first that a new prot= ocol was needed).
Then we came up with RPL (RFC6550 and companion documents). ROLL may a= t some point design another routing protocol, after re-chartering if agreed= by the
IESG, if we need to.

Not forgetting that we get answers from participants in the = WG that companies are not allowed to show their testing-results of our RPL = in the IETF.
 

JP> This is the contrary ! Please share your results, they are VERY= welcome !

Thanks.

JP.

AB
On Sun, Oct 14, 2012 at 12:54 PM, JP Vasseur (jv= asseur) <jvasseur@cisco.= com> wrote:
Note that we are chartered for one routing protocol, RPL.
I am aware of a number of comparisons, and would enrage the authors to get = back to you.
Thanks.

JP.

On Oct 14, 2012, at 10:32 AM, Abdussalam Baryun wrote:

> Hi Henning,
>
> Related to discussion in MANET WG list> Sub: Re: [manet] MANET meet= ing
> at IETF85.
>
> Read in line
>> On 10/14/12, Henning Rogge <hrogge@googlemail.com> wrote:
>>> On Sun, Oct 14, 2012 at 10:00 AM, Abdussalam Baryun
> <abdussalambaryun at gmail.com> wrote:
>>> It is not right to think that
>>> authors just will change words from LLN to be replaced by MANE= T as if
>>> they are the same networks.
>>
>>> Also we should notice that LOADng is not
>>> better performance than RPL for specific networks as *LLNs*. I= f it is
>>> we report the facts.
>>
>> Are you aware of some comparison between RPL and LOADng based on >> testing? If not, this makes absolutely no sense.
>>
>
> I already listened to many discussions in ROLL WG and with results
> presented in the IETF meeting regarding RPL performance. Please note > that I have not seen any LOADng results presented, I already called > for it but no respond within the IETF. Yes I agree we base things on > testing but only testing that are translated in engineering
> documents/reports to make sense. Do you have a pointer to a LOADng
> report for LLN tests? please help or respond because I am interested > to make things make sense in IETF.
>
> AB
>
>
>> Henning Rogge
>>
>> --
>> Steven Hawkings about cosmic inflation: "An increase of billi= ons of
>> billions of percent in a tiny fraction of a second. Of course, tha= t
>> was before the present government."
>>


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

--_000_03B78081B371D44390ED6E7BADBB4A7721FDC392xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Mon Oct 15 03:01: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 827CC21F86DD for ; Mon, 15 Oct 2012 03:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWOM+3iH05vb for ; Mon, 15 Oct 2012 03:01:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D64AD21F86DC for ; Mon, 15 Oct 2012 03:01:46 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so5611169vbb.31 for ; Mon, 15 Oct 2012 03:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nx5+rBFSOFVIIe1fKf3pT3q7HRvHrdpKjlQlz+5et+8=; b=WzT7PqM5eXW4xwCirdIrhhOlrRCOf+Y0fTZpMkwDS16Gaq8VMZVpduuGIQ6c90jHSo UHDrf7o0VAK+5zH0aP4imxW6z8yp6TbIEOQ6f/OUCvHipH3CHwhrxFsFLc8kGqvpM5Vm Rk9t9RNuKVtMFJOb91nuxcFV22gxmcprZANNcRCBWUTNyhalwxXWiUxd56dqK3AyvWdS LtED0vpHd4tLkZBwJNDfR7qBpYACC/waM+R1tKz+GAi+v2Z5MqUr3h1/SlM44DINY0W9 t1ERiGpLZ8dRjUWYfCThrWzXMKpy6aq8+t+GGsFF6Yc1W39JY24b9dkZStuKvxX/8L6J WBfA== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr6474322vec.51.1350295306332; Mon, 15 Oct 2012 03:01:46 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Mon, 15 Oct 2012 03:01:45 -0700 (PDT) In-Reply-To: <17220.1350244450@obiwan.sandelman.ca> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> <17220.1350244450@obiwan.sandelman.ca> Date: Mon, 15 Oct 2012 12:01:45 +0200 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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, 15 Oct 2012 10:01:47 -0000 Hi Michael, I support the decision to have one for now, and others after we complete the milestones and recharter, but don't want to think that we are unable to discuss how to improve that one protocol, or think we are unable to show its testing-results. IF we are unable to show results we will never progress in IETF, and only Industry Organisations can progress because they have no regulation to stop new protocol ideas and discussions. I am happy to show my results when ready, and I am doing my investigation when completed I will present the results within IETF (not only outside) so we can go in progress. Please note that there was discussions in IETF WG meetings about RPL results and I like to clear that noise with more results in IETF. I seen so far good results in IETF ROLL WG but would like to see more scalable ones if possible. IF the claims are true that RPL is not scalable THEN we need to look into this matter. Thanks AB On 10/14/12, Michael Richardson wrote: > >>>>>> "Abdussalam" == Abdussalam Baryun >>>>>> writes: > Abdussalam> Do you mean that IETF ROLL WG is not allowed to have > Abdussalam> another routing > Abdussalam> protocol for LLN. Why is the WG constrained to that, while > the > Abdussalam> Internet industry are more free/flexible? Not forgetting > Abdussalam> that we get > > That's correct: we are not allowed to consider other protocols anymore. > There was a time and a place for that, and it's over. > > If you try to do everything, you wind up doing nothing, > So, IETF working groups have a charter of what is in scope and what is not: > http://datatracker.ietf.org/wg/roll/charter/ > > Back in 2008, the WG adopted a specific proposal. > > Anyone else who has results that they want to publish are encouraged to > do so in appropriate place, and send a link to this mailing list. > > End of thread. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From jvasseur@cisco.com Mon Oct 15 03:46: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 AA56221F86DD for ; Mon, 15 Oct 2012 03:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 oQWXvpy7ZUkk for ; Mon, 15 Oct 2012 03:46:43 -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 A243421F86A3 for ; Mon, 15 Oct 2012 03:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2643; q=dns/txt; s=iport; t=1350298000; x=1351507600; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YP/Ph3EMT4YhwjjZ7dRlctp8f1WChZnMjXWsJldnAF8=; b=Zsnur6nCsPKPa9kA8YTHpgq+IoGRH+2r7aLhrZ0+bxrTzfBRG9Y4F/vl fe7mfPXSTlMx3cbykHDVR+wDypaS6Fh+v/QQuOBHcEh66WECWOy07fV9+ Q+FNwIRqXGR9I6FaCM5kw5oWqgu+xW/DhpBdplrtMsVOwTJBSn5Guhs4/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADDoe1CtJXHA/2dsb2JhbABFv3aBCIIgAQEBAwEBAQEPASc0CwULAgEIGAoUECEGCyUCBA4FCBqHUAMJBgudVI1ph3UNiVSKc2aFXWADlBeCaooOgyKBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131612706" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2012 10:46:40 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9FAkeYF004679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 10:46:40 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 05:46:39 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [Roll] Is there comparisons reported between RPL and LOADng Thread-Index: AQHNqgKhFMpd1MMPX0uVDnyI1qclXA== Date: Mon, 15 Oct 2012 10:46:39 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE1C55@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> <17220.1350244450@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--42.312400-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: <0ED5C18A046FA640A38109984934CB35@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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, 15 Oct 2012 10:46:44 -0000 Dear AB, On Oct 15, 2012, at 12:01 PM, Abdussalam Baryun wrote: > Hi Michael, >=20 > I support the decision to have one for now, and others after we > complete the milestones and recharter, but don't want to think that we > are unable to discuss how to improve that one protocol, or think we > are unable to show its testing-results. IF we are unable to show > results we will never progress in IETF, and only Industry > Organisations can progress because they have no regulation to stop new > protocol ideas and discussions. JP> As pointed out by Michael and I, the ROLL WG can definitely improve=20 the protocol *and* results are very welcome ! >=20 > I am happy to show my results when ready, and I am doing my > investigation when completed I will present the results within IETF > (not only outside) so we can go in progress. Please note that there > was discussions in IETF WG meetings about RPL results and I like to > clear that noise with more results in IETF. I seen so far good results > in IETF ROLL WG but would like to see more scalable ones if possible. > IF the claims are true that RPL is not scalable THEN we need to look > into this matter. JP> Definitely. Thanks for your participation. JP. >=20 > Thanks > AB >=20 > On 10/14/12, Michael Richardson wrote: >>=20 >>>>>>> "Abdussalam" =3D=3D Abdussalam Baryun >>>>>>> writes: >> Abdussalam> Do you mean that IETF ROLL WG is not allowed to have >> Abdussalam> another routing >> Abdussalam> protocol for LLN. Why is the WG constrained to that, whil= e >> the >> Abdussalam> Internet industry are more free/flexible? Not forgetting >> Abdussalam> that we get >>=20 >> That's correct: we are not allowed to consider other protocols anymore. >> There was a time and a place for that, and it's over. >>=20 >> If you try to do everything, you wind up doing nothing, >> So, IETF working groups have a charter of what is in scope and what is n= ot: >> http://datatracker.ietf.org/wg/roll/charter/ >>=20 >> Back in 2008, the WG adopted a specific proposal. >>=20 >> Anyone else who has results that they want to publish are encouraged to >> do so in appropriate place, and send a link to this mailing list. >>=20 >> End of thread. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>=20 >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From esko.dijk@philips.com Mon Oct 15 06:49: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 EFBE221F867F for ; Mon, 15 Oct 2012 06:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 jkDfcgX13R40 for ; Mon, 15 Oct 2012 06:49:53 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id CE3D421F8679 for ; Mon, 15 Oct 2012 06:49:52 -0700 (PDT) Received: from mail107-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Oct 2012 13:49:51 +0000 Received: from mail107-db3 (localhost [127.0.0.1]) by mail107-db3-R.bigfish.com (Postfix) with ESMTP id 5DE481A01B9; Mon, 15 Oct 2012 13:49:51 +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: -42 X-BigFish: VPS-42(zzbb2dI217bL98dI15d6O9371I9251Jd6eah542M1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail107-db3 (localhost.localdomain [127.0.0.1]) by mail107-db3 (MessageSwitch) id 1350308989454187_22072; Mon, 15 Oct 2012 13:49:49 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.243]) by mail107-db3.bigfish.com (Postfix) with ESMTP id 6C00DE0058; Mon, 15 Oct 2012 13:49:49 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Oct 2012 13:49:47 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 15 Oct 2012 14:49:47 +0100 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.02.0309.003; Mon, 15 Oct 2012 14:49:47 +0100 From: "Dijk, Esko" To: "JP Vasseur (jvasseur)" , Abdussalam Baryun Thread-Topic: [Roll] Is there comparisons reported between RPL and LOADng Thread-Index: AQHNqrwV3cp5ySJko0uuh07oU1TzW5e6HnqAgABDM/A= Date: Mon, 15 Oct 2012 13:49:46 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF5373@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> <17220.1350244450@obiwan.sandelman.ca> <03B78081B371D44390ED6E7BADBB4A7721FE1C55@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE1C55@xmb-rcd-x02.cisco.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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, 15 Oct 2012 13:49:54 -0000 Hi AB, JP, I'm confused on this discussion - just wondering whether draft-ietf-roll-tr= ickle-mcast-01 counts as a second routing protocol then? It is not part of RPL in any way but still an accepted WG draft. regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur (jvasseur) Sent: Monday 15 October 2012 12:47 To: Abdussalam Baryun Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng Dear AB, On Oct 15, 2012, at 12:01 PM, Abdussalam Baryun wrote: > Hi Michael, > > I support the decision to have one for now, and others after we > complete the milestones and recharter, but don't want to think that we > are unable to discuss how to improve that one protocol, or think we > are unable to show its testing-results. IF we are unable to show > results we will never progress in IETF, and only Industry > Organisations can progress because they have no regulation to stop new > protocol ideas and discussions. JP> As pointed out by Michael and I, the ROLL WG can definitely improve the protocol *and* results are very welcome ! > > I am happy to show my results when ready, and I am doing my > investigation when completed I will present the results within IETF > (not only outside) so we can go in progress. Please note that there > was discussions in IETF WG meetings about RPL results and I like to > clear that noise with more results in IETF. I seen so far good results > in IETF ROLL WG but would like to see more scalable ones if possible. > IF the claims are true that RPL is not scalable THEN we need to look > into this matter. JP> Definitely. Thanks for your participation. JP. > > Thanks > AB > > On 10/14/12, Michael Richardson wrote: >> >>>>>>> "Abdussalam" =3D=3D Abdussalam Baryun >>>>>>> writes: >> Abdussalam> Do you mean that IETF ROLL WG is not allowed to have >> Abdussalam> another routing >> Abdussalam> protocol for LLN. Why is the WG constrained to that, whil= e >> the >> Abdussalam> Internet industry are more free/flexible? Not forgetting >> Abdussalam> that we get >> >> That's correct: we are not allowed to consider other protocols anymore. >> There was a time and a place for that, and it's over. >> >> If you try to do everything, you wind up doing nothing, >> So, IETF working groups have a charter of what is in scope and what is n= ot: >> http://datatracker.ietf.org/wg/roll/charter/ >> >> Back in 2008, the WG adopted a specific proposal. >> >> Anyone else who has results that they want to publish are encouraged to >> do so in appropriate place, and send a link to this mailing list. >> >> End of thread. >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> > _______________________________________________ > Roll mailing 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. From abdussalambaryun@gmail.com Tue Oct 16 03:21: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 6E2EF21F881F for ; Tue, 16 Oct 2012 03:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 bKN5AV98B4ym for ; Tue, 16 Oct 2012 03:21:49 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3670F21F881C for ; Tue, 16 Oct 2012 03:21:49 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7015741vbb.31 for ; Tue, 16 Oct 2012 03:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6Y1+DewzlzQ2Et0oYw77TOPhzPwGVZnaFYNQvS32lYk=; b=e85V4fjkQoSbLF8kRuoxBu2GWXAHJOs7mFHFKF6vv0NFKuKjfrTVvxMCyBJ5fZQzdY cra4omwsPHybrl66b91TfTcj0x8HbHOG18Tyb/G5LCot+rph2ayU329+9wOb2JWu6b+a uk43QMwPfPDB1okMz0xgHVmN2gYrLdS4NA1BOFklfFbgaGQWEaOOUm88BHAdG4oLRJp5 9UFQTwiWnEbPIxpqXHZ3x5t4B8fE0CsElRcMo/K9xXapSI7lGBYdzLgzK8MtDhVIOix2 tQhyoslFPveQ/K/E2BZ0FD1lD7xyMYI2cc99PsnJOgEqH4RKS50OJCRFUA1AOqZ7/jFw Dl7A== MIME-Version: 1.0 Received: by 10.220.154.17 with SMTP id m17mr8402444vcw.31.1350382908573; Tue, 16 Oct 2012 03:21:48 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 03:21:48 -0700 (PDT) Date: Tue, 16 Oct 2012 12:21:48 +0200 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: [Roll] Zigbee protocols and IETF protocols 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: Tue, 16 Oct 2012 10:21:50 -0000 Hi JP, I am not much familiar with Zigbee standards but do you mean they are using IETF standards into their standards, or do you mean the technology using IETF standards? AB On 10/16/12, JP Vasseur (jvasseur) wrote: > > On Oct 16, 2012, at 11:55 AM, Abdussalam Baryun wrote: > >> I understand you ment that ROLL looks also in similar applications of >> Zigbee as Home Networks. However, Zigbee is standard for another >> organisation, but IETF does not standard that, IMHO, we don't discuss >> *Zigbee standards* in IETF WGs, but we may discuss how to interoperate >> MANETs or LLNs with Zigbee-Internet technologies. > > Not even so, Zigbee chose several IETF protocols. > >> From abdussalambaryun@gmail.com Tue Oct 16 03:38: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 709EE21F882D for ; Tue, 16 Oct 2012 03:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 LIWJhVMUNTsb for ; Tue, 16 Oct 2012 03:38:17 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 811A721F8814 for ; Tue, 16 Oct 2012 03:38:17 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so7608636vcb.31 for ; Tue, 16 Oct 2012 03:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dlrNgZoPBUz+1W/VooooRRhFItU1OLJT5q32K7KqHoM=; b=YTxKMENkxRrczcPrjKzaa0U959XKEy+6YHRZ+lqE5Pt8nuOfPXmwFvSibcyN8FS4Ib Emi20H7ZYPAOON405Nga/1+lqTHXjy7ZKJL05/GxytEFBDtCz3DfDwlJL5WaIfHYCDSe esYPU/CIV3o15dKch2DFtgNwwxBL4bjGXlsyizw/79s06D06Aj1pRx7GrzEh0UPRuMVF 8vIcXtmspwC3bR+VO33IjH6iscR4wX11ucmDE+jcLGn0dQIYJJuIo6FwU9aKoEeAB83v 5rrw8GMqTuiP9s9cjAxvIIqEouoQ65ZASoEUMxn1lsNQUF9ZsUVAm6FpE3VdM1xepQDx nXQA== MIME-Version: 1.0 Received: by 10.58.252.67 with SMTP id zq3mr8703536vec.43.1350383896709; Tue, 16 Oct 2012 03:38:16 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 03:38:16 -0700 (PDT) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AF5373@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> <17220.1350244450@obiwan.sandelman.ca> <03B78081B371D44390ED6E7BADBB4A7721FE1C55@xmb-rcd-x02.cisco.com> <031DD135F9160444ABBE3B0C36CED618AF5373@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Tue, 16 Oct 2012 12:38:16 +0200 Message-ID: From: Abdussalam Baryun To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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: Tue, 16 Oct 2012 10:38:18 -0000 Hi Esko, It is a protocol technique not a routing protocol, So the one Router for LLNs which is RPL. IMO, Trickle is needed in LLNs. AB On 10/15/12, Dijk, Esko wrote: > Hi AB, JP, > > I'm confused on this discussion - just wondering whether > draft-ietf-roll-trickle-mcast-01 counts as a second routing protocol then? > It is not part of RPL in any way but still an accepted WG draft. > > regards, > Esko > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur (jvasseur) > Sent: Monday 15 October 2012 12:47 > To: Abdussalam Baryun > Cc: roll > Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng > > Dear AB, > > On Oct 15, 2012, at 12:01 PM, Abdussalam Baryun wrote: > >> Hi Michael, >> >> I support the decision to have one for now, and others after we >> complete the milestones and recharter, but don't want to think that we >> are unable to discuss how to improve that one protocol, or think we >> are unable to show its testing-results. IF we are unable to show >> results we will never progress in IETF, and only Industry >> Organisations can progress because they have no regulation to stop new >> protocol ideas and discussions. > > JP> As pointed out by Michael and I, the ROLL WG can definitely improve > the protocol *and* results are very welcome ! > >> >> I am happy to show my results when ready, and I am doing my >> investigation when completed I will present the results within IETF >> (not only outside) so we can go in progress. Please note that there >> was discussions in IETF WG meetings about RPL results and I like to >> clear that noise with more results in IETF. I seen so far good results >> in IETF ROLL WG but would like to see more scalable ones if possible. >> IF the claims are true that RPL is not scalable THEN we need to look >> into this matter. > > JP> Definitely. > > Thanks for your participation. > > JP. > >> >> Thanks >> AB >> >> On 10/14/12, Michael Richardson wrote: >>> >>>>>>>> "Abdussalam" == Abdussalam Baryun >>>>>>>> writes: >>> Abdussalam> Do you mean that IETF ROLL WG is not allowed to have >>> Abdussalam> another routing >>> Abdussalam> protocol for LLN. Why is the WG constrained to that, >>> while >>> the >>> Abdussalam> Internet industry are more free/flexible? Not forgetting >>> Abdussalam> that we get >>> >>> That's correct: we are not allowed to consider other protocols anymore. >>> There was a time and a place for that, and it's over. >>> >>> If you try to do everything, you wind up doing nothing, >>> So, IETF working groups have a charter of what is in scope and what is >>> not: >>> http://datatracker.ietf.org/wg/roll/charter/ >>> >>> Back in 2008, the WG adopted a specific proposal. >>> >>> Anyone else who has results that they want to publish are encouraged to >>> do so in appropriate place, and send a link to this mailing list. >>> >>> End of thread. >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>> >>> >> _______________________________________________ >> Roll mailing 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 > 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 Tue Oct 16 03:48:16 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 ADA2D21F8897 for ; Tue, 16 Oct 2012 03:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.872 X-Spam-Level: X-Spam-Status: No, score=-3.872 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 E2a28nzk8Fk9 for ; Tue, 16 Oct 2012 03:48:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id CDBEC21F8895 for ; Tue, 16 Oct 2012 03:48:15 -0700 (PDT) Received: from mail152-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 10:48:14 +0000 Received: from mail152-ch1 (localhost [127.0.0.1]) by mail152-ch1-R.bigfish.com (Postfix) with ESMTP id 9A18460101; Tue, 16 Oct 2012 10:48: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: -42 X-BigFish: VPS-42(zzbb2dI217bL98dI15d6O9371I9251Jd6eah542M1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1 (MessageSwitch) id 1350384492386103_25127; Tue, 16 Oct 2012 10:48:12 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail152-ch1.bigfish.com (Postfix) with ESMTP id 5C99F34008F; Tue, 16 Oct 2012 10:48:12 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 10:48:11 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.02.0309.003; Tue, 16 Oct 2012 11:47:57 +0100 From: "Dijk, Esko" To: Abdussalam Baryun Thread-Topic: [Roll] Is there comparisons reported between RPL and LOADng Thread-Index: AQHNqrwV3cp5ySJko0uuh07oU1TzW5e6HnqAgABDM/CAAUzKAIAAEnZw Date: Tue, 16 Oct 2012 10:47:56 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AF588C@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> <17220.1350244450@obiwan.sandelman.ca> <03B78081B371D44390ED6E7BADBB4A7721FE1C55@xmb-rcd-x02.cisco.com> <031DD135F9160444ABBE3B0C36CED618AF5373@011-DB3MPN2-083.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 Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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: Tue, 16 Oct 2012 10:48:16 -0000 Hi, Ok, I agree that Trickle Multicast Forwarding does not do any routing in th= e sense of route selection or route maintenance. The document itself calls = it "forwarding" which is implemented by "forwarders", which are also define= d to be IPv6 routers. (It's also called flooding at some points in the draf= t.) So there should be room for a flooding/forwarding technique in ROLL, then := ) Esko -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Tuesday 16 October 2012 12:38 To: Dijk, Esko Cc: JP Vasseur (jvasseur); roll Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng Hi Esko, It is a protocol technique not a routing protocol, So the one Router for LLNs which is RPL. IMO, Trickle is needed in LLNs. AB On 10/15/12, Dijk, Esko wrote: > Hi AB, JP, > > I'm confused on this discussion - just wondering whether > draft-ietf-roll-trickle-mcast-01 counts as a second routing protocol then= ? > It is not part of RPL in any way but still an accepted WG draft. > > regards, > Esko > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of J= P > Vasseur (jvasseur) > Sent: Monday 15 October 2012 12:47 > To: Abdussalam Baryun > Cc: roll > Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng > > Dear AB, > > On Oct 15, 2012, at 12:01 PM, Abdussalam Baryun wrote: > >> Hi Michael, >> >> I support the decision to have one for now, and others after we >> complete the milestones and recharter, but don't want to think that we >> are unable to discuss how to improve that one protocol, or think we >> are unable to show its testing-results. IF we are unable to show >> results we will never progress in IETF, and only Industry >> Organisations can progress because they have no regulation to stop new >> protocol ideas and discussions. > > JP> As pointed out by Michael and I, the ROLL WG can definitely improve > the protocol *and* results are very welcome ! > >> >> I am happy to show my results when ready, and I am doing my >> investigation when completed I will present the results within IETF >> (not only outside) so we can go in progress. Please note that there >> was discussions in IETF WG meetings about RPL results and I like to >> clear that noise with more results in IETF. I seen so far good results >> in IETF ROLL WG but would like to see more scalable ones if possible. >> IF the claims are true that RPL is not scalable THEN we need to look >> into this matter. > > JP> Definitely. > > Thanks for your participation. > > JP. > >> >> Thanks >> AB >> >> On 10/14/12, Michael Richardson wrote: >>> >>>>>>>> "Abdussalam" =3D=3D Abdussalam Baryun >>>>>>>> writes: >>> Abdussalam> Do you mean that IETF ROLL WG is not allowed to have >>> Abdussalam> another routing >>> Abdussalam> protocol for LLN. Why is the WG constrained to that, >>> while >>> the >>> Abdussalam> Internet industry are more free/flexible? Not forgetting >>> Abdussalam> that we get >>> >>> That's correct: we are not allowed to consider other protocols anymore. >>> There was a time and a place for that, and it's over. >>> >>> If you try to do everything, you wind up doing nothing, >>> So, IETF working groups have a charter of what is in scope and what is >>> not: >>> http://datatracker.ietf.org/wg/roll/charter/ >>> >>> Back in 2008, the WG adopted a specific proposal. >>> >>> Anyone else who has results that they want to publish are encouraged to >>> do so in appropriate place, and send a link to this mailing list. >>> >>> End of thread. >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>> >>> >> _______________________________________________ >> Roll mailing 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 > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notif= ied > 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 cop= ies > of the original message. > > ________________________________ 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 jvasseur@cisco.com Tue Oct 16 03:52:48 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 81E1A21F87B5 for ; Tue, 16 Oct 2012 03:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 adhYZFIkh9iG for ; Tue, 16 Oct 2012 03:52:48 -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 DF30D21F8946 for ; Tue, 16 Oct 2012 03:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1055; q=dns/txt; s=iport; t=1350384768; x=1351594368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xkelA6upWGDLXPqnnEqyebckIcEBQdhuv6dUk8MY+d4=; b=Ik18phNjfF/Cp9Rj2aRYrs/N9Qq9RMtpbvR8YvLcAt0I5tUOT6CUrVvr VEJLSSYKQPpkPfelxIRDGCxLIBtPd8GvJcNxJbFY3rTAGikyOXG7kgY5I ySlmIZdJg5iSBZQ+upWpPOG/TXuoMoOAeMIVe27/DTr+5lPfDdpqTKQdo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL47fVCtJXHA/2dsb2JhbABFwAqBCIIgAQEBAwEBAQEPASc0CwULAgEIGAoUECcLJQIEDgUIEweHXAYLm02PWpBVBItHhV1gA6QwgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="132035303" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 16 Oct 2012 10:52:47 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9GAqlXf014509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 10:52:47 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 05:52:46 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [Roll] Zigbee protocols and IETF protocols Thread-Index: AQHNq4xgyjOYqjiD6UeyAlgLFikjHg== Date: Tue, 16 Oct 2012 10:52:46 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE8869@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--35.934900-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 Subject: Re: [Roll] Zigbee protocols and IETF protocols 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: Tue, 16 Oct 2012 10:52:48 -0000 Hi, On Oct 16, 2012, at 12:21 PM, Abdussalam Baryun wrote: > Hi JP, >=20 > I am not much familiar with Zigbee standards but do you mean they are > using IETF standards into their standards, They are using IETF protocol in their solution indeed. Thanks. JP. > or do you mean the > technology using IETF standards? >=20 > AB >=20 > On 10/16/12, JP Vasseur (jvasseur) wrote: >>=20 >> On Oct 16, 2012, at 11:55 AM, Abdussalam Baryun wrote: >>=20 >>> I understand you ment that ROLL looks also in similar applications of >>> Zigbee as Home Networks. However, Zigbee is standard for another >>> organisation, but IETF does not standard that, IMHO, we don't discuss >>> *Zigbee standards* in IETF WGs, but we may discuss how to interoperate >>> MANETs or LLNs with Zigbee-Internet technologies. >>=20 >> Not even so, Zigbee chose several IETF protocols. >>=20 >>>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Oct 16 04:14: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 B2EE321F880C for ; Tue, 16 Oct 2012 04:14: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 p7S4dnnyCiZg for ; Tue, 16 Oct 2012 04:14: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 9F75621F8794 for ; Tue, 16 Oct 2012 04:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5805; q=dns/txt; s=iport; t=1350386064; x=1351595664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=65uZSFUhnmUn4VniUqst7FAC592IcXN59cD4kM0ek8A=; b=UsbGsuiCEj1qoqKuTY9oBTuJQL1L1Kg/lJBwSKUxFZckM0TIGWqN4kG1 FaPdDWGZIsi8Xw7bSjlLp2CwMNMT/es30KRFlqyIkXFW0LZ6Zj3YR5T27 VVP6ZZwXKDvs6FNNWJMLdehkeYYdCPEbT/WFnBZEy2QljqBi9GCh6kvAx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFBBfVCtJXHB/2dsb2JhbABFwAqBCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBChQJByEGCxQJCAIEDgUIGodQAwkGC5tKjWmBcYZ3DYlUimFmGoVDYAOUFoJqig6DIoFrgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="132040234" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 16 Oct 2012 11:14:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9GBEOPm010422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 11:14:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 06:14:23 -0500 From: "JP Vasseur (jvasseur)" To: "Dijk, Esko" Thread-Topic: [Roll] Is there comparisons reported between RPL and LOADng Thread-Index: AQHNqgKhFMpd1MMPX0uVDnyI1qclXA== Date: Tue, 16 Oct 2012 11:14:23 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE89DD@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FDAF38@xmb-rcd-x02.cisco.com> <17220.1350244450@obiwan.sandelman.ca> <03B78081B371D44390ED6E7BADBB4A7721FE1C55@xmb-rcd-x02.cisco.com> <031DD135F9160444ABBE3B0C36CED618AF5373@011-DB3MPN2-083.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618AF588C@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AF588C@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--50.868500-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 Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng 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: Tue, 16 Oct 2012 11:14:25 -0000 THis is indeed the case. Thanks. JP. On Oct 16, 2012, at 12:47 PM, Dijk, Esko wrote: > Hi, >=20 > Ok, I agree that Trickle Multicast Forwarding does not do any routing in = the sense of route selection or route maintenance. The document itself call= s it "forwarding" which is implemented by "forwarders", which are also defi= ned to be IPv6 routers. (It's also called flooding at some points in the dr= aft.) >=20 > So there should be room for a flooding/forwarding technique in ROLL, then= :) >=20 > Esko >=20 > -----Original Message----- > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: Tuesday 16 October 2012 12:38 > To: Dijk, Esko > Cc: JP Vasseur (jvasseur); roll > Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng >=20 > Hi Esko, >=20 > It is a protocol technique not a routing protocol, So the one Router > for LLNs which is RPL. IMO, Trickle is needed in LLNs. >=20 > AB >=20 > On 10/15/12, Dijk, Esko wrote: >> Hi AB, JP, >>=20 >> I'm confused on this discussion - just wondering whether >> draft-ietf-roll-trickle-mcast-01 counts as a second routing protocol the= n? >> It is not part of RPL in any way but still an accepted WG draft. >>=20 >> regards, >> Esko >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP >> Vasseur (jvasseur) >> Sent: Monday 15 October 2012 12:47 >> To: Abdussalam Baryun >> Cc: roll >> Subject: Re: [Roll] Is there comparisons reported between RPL and LOADng >>=20 >> Dear AB, >>=20 >> On Oct 15, 2012, at 12:01 PM, Abdussalam Baryun wrote: >>=20 >>> Hi Michael, >>>=20 >>> I support the decision to have one for now, and others after we >>> complete the milestones and recharter, but don't want to think that we >>> are unable to discuss how to improve that one protocol, or think we >>> are unable to show its testing-results. IF we are unable to show >>> results we will never progress in IETF, and only Industry >>> Organisations can progress because they have no regulation to stop new >>> protocol ideas and discussions. >>=20 >> JP> As pointed out by Michael and I, the ROLL WG can definitely improve >> the protocol *and* results are very welcome ! >>=20 >>>=20 >>> I am happy to show my results when ready, and I am doing my >>> investigation when completed I will present the results within IETF >>> (not only outside) so we can go in progress. Please note that there >>> was discussions in IETF WG meetings about RPL results and I like to >>> clear that noise with more results in IETF. I seen so far good results >>> in IETF ROLL WG but would like to see more scalable ones if possible. >>> IF the claims are true that RPL is not scalable THEN we need to look >>> into this matter. >>=20 >> JP> Definitely. >>=20 >> Thanks for your participation. >>=20 >> JP. >>=20 >>>=20 >>> Thanks >>> AB >>>=20 >>> On 10/14/12, Michael Richardson wrote: >>>>=20 >>>>>>>>> "Abdussalam" =3D=3D Abdussalam Baryun >>>>>>>>> writes: >>>> Abdussalam> Do you mean that IETF ROLL WG is not allowed to have >>>> Abdussalam> another routing >>>> Abdussalam> protocol for LLN. Why is the WG constrained to that, >>>> while >>>> the >>>> Abdussalam> Internet industry are more free/flexible? Not forgetting >>>> Abdussalam> that we get >>>>=20 >>>> That's correct: we are not allowed to consider other protocols anymore= . >>>> There was a time and a place for that, and it's over. >>>>=20 >>>> If you try to do everything, you wind up doing nothing, >>>> So, IETF working groups have a charter of what is in scope and what is >>>> not: >>>> http://datatracker.ietf.org/wg/roll/charter/ >>>>=20 >>>> Back in 2008, the WG adopted a specific proposal. >>>>=20 >>>> Anyone else who has results that they want to publish are encouraged t= o >>>> do so in appropriate place, and send a link to this mailing list. >>>>=20 >>>> End of thread. >>>>=20 >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>>=20 >>>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >> ________________________________ >> The information contained in this message may be confidential and legall= y >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby noti= fied >> 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 co= pies >> of the original message. >>=20 >>=20 >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Tue Oct 16 04:19: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 4C8AF21F8793 for ; Tue, 16 Oct 2012 04:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 OBYKoJrVuEkn for ; Tue, 16 Oct 2012 04:19:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9321F8758 for ; Tue, 16 Oct 2012 04:19:04 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so7651584vcb.31 for ; Tue, 16 Oct 2012 04:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=TVTbkUWejqGmXIay0SgOI9Y1jIphoDvJq8aBNMQKuS4=; b=nzpFOR0Ca/BU4JySpa6l5Y6UQR6uj1ZkXOJnK64biPmcMWTyRDImTH9JMhOd5RcTys Rh9azJ7iR7kvBHg9p72kniL70ln6eo6ox9AY+WPvjGv7iYj5BocmxY/jxjmGzA3cI5nu SM+KdpqVILDhD62iZiUVVxZhaeC0RTraqYROWKzQKfzcJpWPmoMSnXrjRT/jCnOd3k4+ 1KXPMhf5QHwg1w3Qqq2pbUaFoJWcrkgguSpyk8OKxpeAHchefiWuiEWK3uF4xA4eQ4Lz b/uWFrTIzlckYbkT3jSBfBpyR9HVMUthRJKTtQxTDwWWX19PosaK0XkugEnZ9cHx682z yaZg== MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr8503488vec.51.1350386343717; Tue, 16 Oct 2012 04:19:03 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 04:19:03 -0700 (PDT) Date: Tue, 16 Oct 2012 13:19:03 +0200 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Comments For ROLL terminology-06 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: Tue, 16 Oct 2012 11:19:05 -0000 Hi JP, Will we see a renew for the terminology draft-06 before next 85 meeting, please advise, AB On Sat, Aug 4, 2012 at 2:55 PM, JP Vasseur (jvasseur) cisco.com> wrote: > > A new version of the document will be posted, thanks for the comments! > Just note that some of these terms are not > related to RPL but to LLNs in general though. > Thanks. > > JP. > > > On Aug 3, 2012, at 10:46 PM, Abdussalam Baryun wrote: > >> Hi JP and All, >> >> I need your comments/feedback on the below, and want to know if there >> will be update to the expired document. >> >> Regards >> AB > From jvasseur@cisco.com Tue Oct 16 04:23: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 8546F21F895C for ; Tue, 16 Oct 2012 04:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 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 g+II-KkygZS3 for ; Tue, 16 Oct 2012 04:23:26 -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 D5D6121F88AD for ; Tue, 16 Oct 2012 04:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=991; q=dns/txt; s=iport; t=1350386606; x=1351596206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=38OMQHhZgWFFsmeh4tQHMcRk1wkBWTgsnw/pNDfHRsQ=; b=mWtjYkBVe4Is0CdoZRsMIthnXzfohP+ZfeQVkFNCIi7QM/Ne9DDIml2q 4al1GzETbd4C8NOWuIVQYli3RiVKz3i+Y5I5UuCJViUqTyhK1Y7twWAUI mByzCua4YFO7quHohcBAwZV4mfcaKJyLhuXWZeD56JqxY+zH7F8XkGBbP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAJVCfVCtJV2c/2dsb2JhbABFhUu6P4EIgiABAQEDAQEBAQ8BJzQLBQsCAQgYChQQJwslAgQOBQgah1wGC5tKj1qQVYtHhV1gA5cAjTCBa4JtgVoHNg X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="131823513" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 16 Oct 2012 11:23:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9GBNQLh030052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 11:23:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 06:23:26 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [Roll] Comments For ROLL terminology-06 Thread-Index: AQHNq5CoTUXDK0a+5USF7Lfa0loltA== Date: Tue, 16 Oct 2012 11:23:26 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE8A9E@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--42.791600-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 Subject: Re: [Roll] Comments For ROLL terminology-06 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: Tue, 16 Oct 2012 11:23:27 -0000 No plan, feel fee to send your comments though. At this point, I was planin= g to request a WG last call. On Oct 16, 2012, at 1:19 PM, Abdussalam Baryun wrote: > Hi JP, >=20 > Will we see a renew for the terminology draft-06 before next 85 > meeting, please advise, >=20 > AB >=20 > On Sat, Aug 4, 2012 at 2:55 PM, JP Vasseur (jvasseur) > cisco.com> wrote: >>=20 >> A new version of the document will be posted, thanks for the comments! >> Just note that some of these terms are not >> related to RPL but to LLNs in general though. >> Thanks. >>=20 >> JP. >>=20 >>=20 >> On Aug 3, 2012, at 10:46 PM, Abdussalam Baryun wrote: >>=20 >>> Hi JP and All, >>>=20 >>> I need your comments/feedback on the below, and want to know if there >>> will be update to the expired document. >>>=20 >>> Regards >>> AB >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From xspikeanand@gmail.com Tue Oct 16 06:12: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 B867E21F897A for ; Tue, 16 Oct 2012 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBxtEzEoNI1D for ; Tue, 16 Oct 2012 06:12:08 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E61A921F8979 for ; Tue, 16 Oct 2012 06:12:07 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so2854465bkc.31 for ; Tue, 16 Oct 2012 06:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mr8xij2uiIqiRtGCnuCrgw5OG1MQYH2maFdE2ivr1K4=; b=gRuI7Yq+qReXwaKJ7CM/gwc+2qfbzq/CwZffslrroifNvyOAIbXJXqgm59CPxUfZ7/ F08l1wmRzsE7KnjEERHsNaDx+WfshkCsISU5VGegxk3Lr8foJtDa/yuxV214ErTR4KT4 eN09Lah+ppDGpLakqyBkpZ9jjMaxHTwFzKYViI81Ezf5RQUD4ni0mzxnt+Z8XJlLrbNW VOHeCo57rXsqT1vxgsxQrtSikH6A2gSQIeEkTH0CijqoaWQaLz6fYv9Pk90vgJfwq2m9 iWv8sfFqYLDqTUMyGQHvHswzX3abqbiv+8kmOt9hl/UG2CwCEUzse0Q0HwTOaXbTc6JM qvog== MIME-Version: 1.0 Received: by 10.204.129.23 with SMTP id m23mr1238571bks.20.1350393126753; Tue, 16 Oct 2012 06:12:06 -0700 (PDT) Received: by 10.204.19.10 with HTTP; Tue, 16 Oct 2012 06:12:06 -0700 (PDT) Date: Tue, 16 Oct 2012 18:42:06 +0530 Message-ID: From: Anandghan W To: roll@ietf.org Content-Type: multipart/alternative; boundary=001517447feca0969104cc2ce6ca Subject: [Roll] Time Synchronized Routing Protocol 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: Tue, 16 Oct 2012 13:13:42 -0000 --001517447feca0969104cc2ce6ca Content-Type: text/plain; charset=ISO-8859-1 Hi, I have got a project to develop Time Synchronized Routing Protocol for 6LoWPAN . Can anyone please give me some initial leads ? Thanx. Regards, Anandghan --001517447feca0969104cc2ce6ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0=A0=A0=A0=A0=A0=A0 I have got a project to develop Time Synchr= onized Routing Protocol for 6LoWPAN . Can anyone please give me some initia= l leads ?
Thanx.

Regards,
Anandghan
--001517447feca0969104cc2ce6ca-- From dat@exegin.com Tue Oct 16 09:29: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 0D80C21F880D for ; Tue, 16 Oct 2012 09:29:03 -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 m7sxwWQ7HA1d for ; Tue, 16 Oct 2012 09:29:01 -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 5DDF121F87EF for ; Tue, 16 Oct 2012 09:29:01 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so6001704pad.31 for ; Tue, 16 Oct 2012 09:29:01 -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:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=C5HfA+lrzCcQtvIaViiZvmXFuO0pZ8PBy+gvcVPCwUA=; b=m4HNz8S1BLHWQ38HmUsr+aG49BZJVrMJMDzv8bl0WGq1Zk0/7PJPuzPegoj/ogW25d Du8QZKpHKeIk+yM49uhy0Qfz2+JZ/VVPVz1lbIyCwk283YqbJgf8YptSVRTDMD3o/p0R zSXxTbCWnWW393l6IEpGLJAyuaX5Z2FzJtEnVWsbhQps2TG8pN5V+B/SKhNG+qoAWVwM 5LW+DLqexiAY+RzDy7TGzTuspJcqKU9poED8hotxOVwqsFFD76KAiC6nFB/SD/Td+0W8 tRcmH0fhgpDe7AwgpItS1I6hbyjtoJqWUg3u7SyytNvywPWDlQSJDECh+c61q3Pbt9nk v/xg== Received: by 10.68.222.37 with SMTP id qj5mr47638740pbc.132.1350404941024; Tue, 16 Oct 2012 09:29:01 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id a10sm6324726paz.35.2012.10.16.09.28.59 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 09:28:59 -0700 (PDT) Message-ID: <507D8B43.9000008@exegin.com> Date: Tue, 16 Oct 2012 09:28: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: "roll@ietf.org" References: <50747202.8020702@exegin.com> In-Reply-To: <50747202.8020702@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnyzRtwvasWAYFZp86P0WTUNOHRJQs/mrqSDWBPxdlEI/smt35xUfN+w8GAb1i0mSpzhOwT Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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: Tue, 16 Oct 2012 16:29:03 -0000 Can anyone clarify this for me or at least indicate if it has already been discussed some time in the past. - Dario On 09/10/2012 11:50 AM, Dario Tedeschi wrote: > > While writing ZigBee-IP test procedures for RPL and discussing with > other ZigBee-IP members, it appears there may be an error in RFC 6550. > > RFC 6550 says: > > SenderRank: 16-bit field set to zero by the source and to > DAGRank(rank) by a router that forwards inside the RPL network. > > Firstly, it seems wrong that the source of a datagram would set its > SenderRank to zero. If this packet were moving up the DAG the first > forwarder would set the Rank-Error bit to 1, because the SenderRank > field in the HbH option would be lower than its own rank. Similarly, > if the datagram were mistakenly moving down the DAG, where the > source's real rank was higher than the forwarder's rank a potential > routing loop could be missed. > > Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank > is a 16bit field. Wouldn't doing this allow for potential routing > loops to be missed? > > Could someone (preferably one of the RPL authors) please clarify. > > - Dario > From abdussalambaryun@gmail.com Tue Oct 16 09:30: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 07E2021F8829 for ; Tue, 16 Oct 2012 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, 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 pRMckdw9wHkX for ; Tue, 16 Oct 2012 09:30:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2C21F882C for ; Tue, 16 Oct 2012 09:30:58 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so8104878vcb.31 for ; Tue, 16 Oct 2012 09:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2cfc/wvj4+hmEOxQ0LVBw0zZpXr94lOTudMtwQzJ/sk=; b=RiRYxEZKvRaSKL1h/IR9PJuItwBVsR9XXAfENC7Rpm3PQyebJbcyKUM9KNvWURCqBu jlTR8q1cxG6/A/ivS3XKm/ja5AqUHrUgp02S9m8tmo6mpW0TxOSbc1O5PAeFfK2zuDmN 8Toi/UF4gFe6st2qbluB3LvzOanUhN/dqxtMz6ydAYENJE9xfUekZw2HSnFwFq3YMa2r Ws2v7+1MpF9g7U2saIaypZiWBF5IKTambKfCd0xGLoUtIeq217XkKyg9XQ+U+pb5Nz6a AhFIRkOadaNYDldtDu4ATdBdy631POWbFfPqqSbWkXsOdC+ZkC+k2FDkYpjrgkdu7Dlj fkKg== MIME-Version: 1.0 Received: by 10.220.240.135 with SMTP id la7mr8873723vcb.44.1350405057637; Tue, 16 Oct 2012 09:30:57 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Tue, 16 Oct 2012 09:30:57 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FE8A9E@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FE8A9E@xmb-rcd-x02.cisco.com> Date: Tue, 16 Oct 2012 17:30:57 +0100 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: multipart/alternative; boundary=14dae9cfc73ac36d1204cc2fad50 Cc: roll Subject: Re: [Roll] Comments For ROLL terminology-06 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: Tue, 16 Oct 2012 16:30:59 -0000 --14dae9cfc73ac36d1204cc2fad50 Content-Type: text/plain; charset=ISO-8859-1 I gave some comments before, but not sure what you will do with it, also I support the last call to be announced to see the WG decision. Thanking you AB On Tue, Oct 16, 2012 at 12:23 PM, JP Vasseur (jvasseur) wrote: > No plan, feel fee to send your comments though. At this point, I was > planing to request a WG last call. > > On Oct 16, 2012, at 1:19 PM, Abdussalam Baryun wrote: > > > Hi JP, > > > > Will we see a renew for the terminology draft-06 before next 85 > > meeting, please advise, > > > > AB > > > > On Sat, Aug 4, 2012 at 2:55 PM, JP Vasseur (jvasseur) >> cisco.com> wrote: > >> > >> A new version of the document will be posted, thanks for the comments! > >> Just note that some of these terms are not > >> related to RPL but to LLNs in general though. > >> Thanks. > >> > >> JP. > >> > >> > >> On Aug 3, 2012, at 10:46 PM, Abdussalam Baryun wrote: > >> > >>> Hi JP and All, > >>> > >>> I need your comments/feedback on the below, and want to know if there > >>> will be update to the expired document. > >>> > >>> Regards > >>> AB > >> > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > --14dae9cfc73ac36d1204cc2fad50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I gave some comments before, but not sure what you will do with it, al= so I support the last call to be announced to see the WG decision. Thanking= you
=A0
AB

On = Tue, Oct 16, 2012 at 12:23 PM, JP Vasseur (jvasseur) <= jvasseur@cisco.com<= /a>> wrote:
No plan, feel fee to send your comments though. At this po= int, I was planing to request a WG last call.

On Oct 16, 2012, at 1:19 PM, Abdussalam Baryun wrote:

> Hi JP,
>
> Will we see a renew for the terminology draft-06 before next 85
> meeting, please advise,
>
> AB
>
> On Sat, Aug 4, 2012 at 2:55 PM, JP Vasseur (jvasseur) <jvasseur at<= br> >> cisco.com> w= rote:
>>
>> A new version of the document will be posted, thanks for the comme= nts!
>> Just note that some of these terms are not
>> related to RPL but to LLNs in general though.
>> Thanks.
>>
>> JP.
>>
>>
>> On Aug 3, 2012, at 10:46 PM, Abdussalam Baryun wrote:
>>
>>> Hi JP and All,
>>>
>>> I need your comments/feedback on the below, and want to know i= f there
>>> will be update to the expired document.
>>>
>>> Regards
>>> AB
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


--14dae9cfc73ac36d1204cc2fad50-- From internet-drafts@ietf.org Wed Oct 17 01: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 DF72321F87E1; Wed, 17 Oct 2012 01:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 twSfXXPY-MXb; Wed, 17 Oct 2012 01:47:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FEF21F87DC; Wed, 17 Oct 2012 01:47:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017084729.22423.91140.idtracker@ietfa.amsl.com> Date: Wed, 17 Oct 2012 01:47:29 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-14.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: Wed, 17 Oct 2012 08:47:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-14.txt Pages : 36 Date : 2012-10-17 Abstract: This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-rpl-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=630ae403b=mukul@uwm.edu Wed Oct 17 01:49: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 7606621F87D6 for ; Wed, 17 Oct 2012 01:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PizHdJno1kTk for ; Wed, 17 Oct 2012 01:49:12 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id B974521F87B1 for ; Wed, 17 Oct 2012 01:49:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAP5vflB/AAAB/2dsb2JhbABFhhG9LgEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJh3sLmhCOTIRLhSuJCIEhii4bhROBEgOIWI0TgRWPHYJgK4F5 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 346632A0A76 for ; Wed, 17 Oct 2012 03:49:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCxe8eett7qC for ; Wed, 17 Oct 2012 03:49:09 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id EB7CC2A0A5C for ; Wed, 17 Oct 2012 03:49:09 -0500 (CDT) Date: Wed, 17 Oct 2012 03:49:09 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <291505611.51568.1350463749567.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20121017084729.22423.91140.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-14.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: Wed, 17 Oct 2012 08:49:13 -0000 This new version has minor IANA related changes. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Wednesday, October 17, 2012 3:47:29 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-14.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-14.txt Pages : 36 Date : 2012-10-17 Abstract: This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-rpl-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Oct 17 01:49: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 81E5B21F8510 for ; Wed, 17 Oct 2012 01:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.093, 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 u8FNJY4gOFBA for ; Wed, 17 Oct 2012 01:49:42 -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 EE24C21F87E0 for ; Wed, 17 Oct 2012 01:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8070; q=dns/txt; s=iport; t=1350463777; x=1351673377; h=from:to:subject:date:message-id:references:mime-version; bh=7PBjhKb7Mhvp+ynl4TIiF3JCDP6aLjWWaNEPmLK8Ly4=; b=UQ3Iaha+IUPh8KVRrEoLaC7aAOxyMfJp1NrvOEaTGrBRnDK2J9eu3YPs 1c/I1jKLw/bO/Jqk/r8XEFepgD97OnM0biwoTWOaPo3vU4p5dKSK+8EgE A9yCwFyBmcHBGUHXoSm0FBFegJ6ydmrAFzMYU3uH0tasRBTg6goGpHr5g w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALBwflCtJV2a/2dsb2JhbABFwBeBCIIcBAEBAQQBAQEPAVsbAgEZAwECCx0HJwsUBwIIAgQTCAEZhScHghgcC5syoB+LTxuFRWADlwCKEoMggWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208,217";a="132244056" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2012 08:49:36 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9H8naJw029823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Oct 2012 08:49:36 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 03:49:36 -0500 From: "JP Vasseur (jvasseur)" To: roll WG Thread-Topic: I-D Action: draft-ietf-roll-p2p-rpl-14.txt Thread-Index: AQHNrERVzjdFY0Usd02uQHRl0fgsbA== Date: Wed, 17 Oct 2012 08:49:35 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FEEB7C@xmb-rcd-x02.cisco.com> References: <20121017084729.22423.91140.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--42.211300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FEEB7Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-14.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: Wed, 17 Oct 2012 08:49:43 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FEEB7Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just minor update on IANA prior to publication request. Begin forwarded message: From: > Subject: I-D Action: draft-ietf-roll-p2p-rpl-14.txt Date: October 17, 2012 10:47:29 AM GMT+02:00 To: > Cc: > Reply-To: > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power = and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-14.txt Pages : 36 Date : 2012-10-17 Abstract: This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-rpl-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_03B78081B371D44390ED6E7BADBB4A7721FEEB7Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Just minor update on IANA prior to publication request.


Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: I-= D Action: draft-ietf-roll-p2p-rpl-14.txt
Date: Octob= er 17, 2012 10:47:29 AM GMT+02:00
To: <<= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org>
Cc: <<= a href=3D"mailto:roll@ietf.org">roll@ietf.org>
Reply-To: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=


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

Title  = ;         : Reactive Discovery= of Point-to-Point Routes in Low Power and Lossy Networks
Author(s) &= nbsp;     : Mukul Goyal
            &nb= sp;            = Emmanuel Baccelli
            &nb= sp;            = Matthias Philipp
            &nb= sp;            = Anders Brandt
            &nb= sp;            = Jerald Martocci
Filename &n= bsp;      : draft-ietf-roll-p2p-rpl-14.txt Pages  = ;         : 36
Date  =           : 2012-10-17
Abstract:
  This document specifies a point-to-point route discovery mechan= ism,
  complementary to the RPL core functionality.  This mechani= sm allows
  an IPv6 router to discover "on demand" routes to one = or more IPv6
  routers in the LLN such that the discovered routes meet specifi= ed
  metrics constraints.


The IETF datatracker status page for this draft is:
https:= //datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-rpl-14


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--_000_03B78081B371D44390ED6E7BADBB4A7721FEEB7Cxmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Wed Oct 17 02:17: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 4F00F21F882C for ; Wed, 17 Oct 2012 02:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 EYjaNWF2J8e2 for ; Wed, 17 Oct 2012 02:17:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6B6C21F8826 for ; Wed, 17 Oct 2012 02:17:36 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7893946vbb.31 for ; Wed, 17 Oct 2012 02:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yAfAIcxG+ECJEaG7dkdCmlOrCEoB+bc3SiyPxW9bqWc=; b=lkhjMX3Pon58d1PfQ0o5zu4CWugKjfRVRCTw8hTByRQ1Z3KvXCAxcwJD3iQIDR2828 VqgMkfRh70WjkTdNuggIU7It5xX4LJOMWsP9uGO+RDLEt8/Zg+LGIq8ryrgHU+rECzsL 9grNX7wujTeaEIQ0OU6+aEEXBTLx8j4MHp11Q4nrCks5uCGUcsauqfKpbpwGW5/Lni8h YQA+m49pch3ddhIKCR7nVGXke1n5xfVhbBGCcRJe9h8xWfhuTxJXVwRH6vG27plL44Oa UcODz4sqiMy4BnygQoiw+ucj4yjI3ZSU/i/ciFG+U/2o+yAu+dWMdeoXlTy2c33ueZYz MBWw== MIME-Version: 1.0 Received: by 10.52.90.99 with SMTP id bv3mr7961918vdb.125.1350465456107; Wed, 17 Oct 2012 02:17:36 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Wed, 17 Oct 2012 02:17:35 -0700 (PDT) In-Reply-To: <291505611.51568.1350463749567.JavaMail.root@mail17.pantherlink.uwm.edu> References: <20121017084729.22423.91140.idtracker@ietfa.amsl.com> <291505611.51568.1350463749567.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 17 Oct 2012 11:17:35 +0200 Message-ID: From: Abdussalam Baryun To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-14.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: Wed, 17 Oct 2012 09:17:37 -0000 Thanks, after my review, I have no comments, I think it is ready to WGLC if the authors agree. AB On 10/17/12, Mukul Goyal wrote: > This new version has minor IANA related changes. > > Thanks > Mukul > > ----- Original Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Sent: Wednesday, October 17, 2012 3:47:29 AM > Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-14.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy networks > Working Group of the IETF. > > Title : Reactive Discovery of Point-to-Point Routes in Low Power > and Lossy Networks > Author(s) : Mukul Goyal > Emmanuel Baccelli > Matthias Philipp > Anders Brandt > Jerald Martocci > Filename : draft-ietf-roll-p2p-rpl-14.txt > Pages : 36 > Date : 2012-10-17 > > Abstract: > This document specifies a point-to-point route discovery mechanism, > complementary to the RPL core functionality. This mechanism allows > an IPv6 router to discover "on demand" routes to one or more IPv6 > routers in the LLN such that the discovered routes meet specified > metrics constraints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-rpl-14 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Roll mailing 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 antoniocojr@gmail.com Wed Oct 17 05:24: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 7E07021F8622 for ; Wed, 17 Oct 2012 05:24:24 -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 Z6qLtzbLDIwx for ; Wed, 17 Oct 2012 05:24:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2568A21F861F for ; Wed, 17 Oct 2012 05:24:23 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so8707782vcb.31 for ; Wed, 17 Oct 2012 05:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=erdH0ulIn60AXoNyA1f9Ymhy8Ivqg2P8yya9W4dCaNc=; b=x6q0/0Nt/oUsO/FHlmPzZ/Cqmh9rO9pqV3080apEE6ew9KEvjxeSUVap3W0BeKr7qk nhzuK8CzUYGcAdLVxCmpNr2FYM8W8gNpvX98v8FDfau8fTzW1GRWZ1nvo5KEOW1zzSgT ej3S0q1D4g6k7SnWxXsx2VaRoQ2knf2BQQMNwErcRj6hSvP5N1ntUJBk02bReoIWTEPZ YNfdUpNBDid3yCxwR9WMpb4/Kn+DUDcn+MPkMgFfgLah4MRcuAUhWZ+9HEIKGIbBSOOU C7Hp5hZg+eb+ntAZ3aBsqN5vibVObqc8uD0JSLlOl06h6DkQrsaGIFCHo1Bgv4D+wkCW 6eBQ== MIME-Version: 1.0 Received: by 10.52.100.6 with SMTP id eu6mr8143936vdb.59.1350476662525; Wed, 17 Oct 2012 05:24:22 -0700 (PDT) Received: by 10.220.208.132 with HTTP; Wed, 17 Oct 2012 05:24:22 -0700 (PDT) Date: Wed, 17 Oct 2012 13:24:22 +0100 Message-ID: From: Antonio Oliveira Junior To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 17 Oct 2012 12:24:24 -0000 Dear All, We submitted a new Internet-draft "Energy-awareness metrics global applicability guidelines". http://tools.ietf.org/html/draft-ajunior-energy-awareness-00 Abstract: This document describes a new set of energy-awareness metrics which have been devised to be applicable to any multihop routing protocol, including the Routing for Low Power and Lossy Networks (RPL) protocol. We appreciate your comments, Sincerely, -- Antonio C. Oliveira Junior, PhD Student Computer Science MAP-i Doctoral Programme (www.map.edu.pt/i) Researcher at IAN/SITI (http://siti.ulusofona.pt/) From abdussalambaryun@gmail.com Wed Oct 17 07:09: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 AE7C021F842C for ; Wed, 17 Oct 2012 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, 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 K-uEYmuwaNB8 for ; Wed, 17 Oct 2012 07:09:05 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A29CE21F856D for ; Wed, 17 Oct 2012 07:09:05 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so8224614vbb.31 for ; Wed, 17 Oct 2012 07:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g0WZBkhifCA5XAZWKJaaqsILSBng6MNqN7lu8qfnm1o=; b=N43bP5PJmPzAKGMSO6uk4IgBFmC1wLltHbHYHZjUelH1Ra+PgFf73y0Vs6Vxs09RMD 9thFY0DQP+CS8NBFalptExFARGVrZLoF0KZjdUb2PnTiTTJ7CKrTzOIjqz7WqW8p13ZM trpe5h3aJ37OYlGVK6e+CQc802MyvrOlhB6qWkybYYRUSTYsJJ1Alw0PT7RmOIGS1qVJ hO+6ba7LyRqlsV/WCtD9r0pnLAAw7HSdUw/OaVGJp1z1l+IZJkFWc5zNMtwHF0jvE0Ge pmS9X9wBMpwnMRQswEJXNVBPvV5lUEYPBBTeTcAq1d7hruS/PjpS9tL8ujy6+fhp3tva Fstw== MIME-Version: 1.0 Received: by 10.220.240.135 with SMTP id la7mr686443vcb.44.1350482945018; Wed, 17 Oct 2012 07:09:05 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Wed, 17 Oct 2012 07:09:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 15:09:04 +0100 Message-ID: From: Abdussalam Baryun To: Antonio Oliveira Junior Content-Type: multipart/alternative; boundary=14dae9cfc73a3689ff04cc41d06a Cc: roll@ietf.org Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 17 Oct 2012 14:09:06 -0000 --14dae9cfc73a3689ff04cc41d06a Content-Type: text/plain; charset=ISO-8859-1 *Hi Antonio,* If this draft is for all wireless multihop routings, then I suggest it to be posted also to MANET list, so you can get feedback also, AB On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveira Junior < antoniocojr@gmail.com> wrote: > Dear All, > > We submitted a new Internet-draft "Energy-awareness metrics global > applicability guidelines". > > http://tools.ietf.org/html/draft-ajunior-energy-awareness-00 > > Abstract: This document describes a new set of energy-awareness > metrics which have been devised to be applicable to any multihop > routing protocol, including the Routing for Low Power and Lossy > Networks (RPL) protocol. > > We appreciate your comments, > > Sincerely, > > -- > Antonio C. Oliveira Junior, PhD Student Computer Science > MAP-i Doctoral Programme (www.map.edu.pt/i) > Researcher at IAN/SITI (http://siti.ulusofona.pt/) > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --14dae9cfc73a3689ff04cc41d06a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Antonio,
=A0
If this draft is for all wireless multihop routings, then I suggest it= to be posted also=A0to MANET list, so you can get feedback also,
=A0
AB

On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveir= a Junior <antoniocojr@gmail.com> wrote:
Dear All,

We submitted a new I= nternet-draft "Energy-awareness metrics global
applicability guidel= ines".

http://tools.ietf.org/html/draft-ajunior-energy-awarene= ss-00

Abstract: This document describes a new set of energy-awar= eness
metrics which have been devised to be applicable to any multihop
routing= protocol, including the Routing for Low Power and Lossy
Networks (RPL) = protocol.

We appreciate your comments,

Sincerely,

--
Antonio C. Oliveira Junior, PhD Student Computer Science
MAP-i Doc= toral Programme (www.= map.edu.pt/i)
Researcher at IAN/SITI (http://siti.ulusofona.pt/)
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailm= an/listinfo/roll

--14dae9cfc73a3689ff04cc41d06a-- From antoniocojr@gmail.com Wed Oct 17 07:12:30 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 D8EE521F857A for ; Wed, 17 Oct 2012 07:12:30 -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 064EhT-KxhrD for ; Wed, 17 Oct 2012 07:12:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3F1921F85B4 for ; Wed, 17 Oct 2012 07:12:29 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so8862618vcb.31 for ; Wed, 17 Oct 2012 07:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z3Fv0U+l1O56BgOrpROUu5lkvsQMB2pblLBEtFeYeYM=; b=cWYZ9hNKMMz6G1hptV6qVE+5tgI2dVUwETilCm1BpgufDDH5ltVdXrapnl9plU2FNE 2ANADrwbP7x62ScGq1HRobjQ/9ApB3knURnd38+4ktATENa0qjTISpO7UTi+OdFhUxKx rypbZg3gmnBYfPzua7ZWEuO3IJJxtTt5PBclg3n/kSRt50DidOscVRc2v2bX9xMjEq53 cEiEh2StrMKgn7YV4yjYjbYsZYYB1PpmWfNMsF3P/a2USlxnkqfh1tOosv9r4zuG+AQ3 QKqV5breiJx9ZVaPIAUTF78Z8tfgYovrLooVDm7O5/YGSCBiuJRZ0ZJNypqxmGQzuwj9 fM3A== MIME-Version: 1.0 Received: by 10.58.187.234 with SMTP id fv10mr10422400vec.8.1350483147817; Wed, 17 Oct 2012 07:12:27 -0700 (PDT) Received: by 10.220.208.132 with HTTP; Wed, 17 Oct 2012 07:12:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 15:12:27 +0100 Message-ID: From: Antonio Oliveira Junior To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 17 Oct 2012 14:12:31 -0000 Hi AB, Thanks for advice. Antonio On 17 October 2012 15:09, Abdussalam Baryun wrote: > Hi Antonio, > > If this draft is for all wireless multihop routings, then I suggest it to be > posted also to MANET list, so you can get feedback also, > > AB > > On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveira Junior > wrote: >> >> Dear All, >> >> We submitted a new Internet-draft "Energy-awareness metrics global >> applicability guidelines". >> >> http://tools.ietf.org/html/draft-ajunior-energy-awareness-00 >> >> Abstract: This document describes a new set of energy-awareness >> metrics which have been devised to be applicable to any multihop >> routing protocol, including the Routing for Low Power and Lossy >> Networks (RPL) protocol. >> >> We appreciate your comments, >> >> Sincerely, >> >> -- >> Antonio C. Oliveira Junior, PhD Student Computer Science >> MAP-i Doctoral Programme (www.map.edu.pt/i) >> Researcher at IAN/SITI (http://siti.ulusofona.pt/) >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > -- Antonio C. Oliveira Junior, PhD Student Computer Science MAP-i Doctoral Programme (www.map.edu.pt/i) Researcher at IAN/SITI (http://siti.ulusofona.pt/) From rute.sofia@ulusofona.pt Wed Oct 17 09:03:30 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 C82B521F8628 for ; Wed, 17 Oct 2012 09:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMTX1t3rGgxI for ; Wed, 17 Oct 2012 09:03:29 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51B9121F8606 for ; Wed, 17 Oct 2012 09:03:29 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so3516386bkc.31 for ; Wed, 17 Oct 2012 09:03:28 -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=XfrLqepPQ7Whrla4cpg+utF5+oF6pEBPU1YaE61t6ko=; b=A/xJIXNpMA1H1QHbSoNLPbl+7mh5lJbo+Spu3Sn+MbyJVhAMR3eCXtsg4I5ZTFlGuf WDZWW65Y945GILx6tZJBRFi2/QmD+OSJXDsQL/4RlTeKn3fogccfEO3j1kwS4Fq5devR jmxdzcFNnHozAto7uguLsdG4Hxks0mTPAMTHWeuzQa5AIm8/g7gA4nMBlQ+Dm+VmT1eA 4IPOxYSQS+seJkWOuz5MMLNMf8LvqP2/akiRTromZhsS+iRnWPTnmQQ5LIARLfEzkg6S yCTqHXnYPLsmY90eEYpebQ2NO+sJ0Tksrw6LYqJGK8/UQDH+XVaQOjWv4vZ0gjaLnI1m hzWQ== Received: by 10.204.146.83 with SMTP id g19mr5581514bkv.33.1350489808276; Wed, 17 Oct 2012 09:03:28 -0700 (PDT) Received: from linux-phf7.site ([89.181.195.175]) by mx.google.com with ESMTPS id e3sm13326053bks.7.2012.10.17.09.03.26 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 09:03:27 -0700 (PDT) Message-ID: <507ED5CF.7040507@ulusofona.pt> Date: Wed, 17 Oct 2012 16:59:11 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070905000305010101020309" X-Gm-Message-State: ALoCoQkCRFoXyW+ca3OiHpW3t0Tr/2noeQbGQdGyJi8UzWANK5u9ik2XU4p5GpDxF0VccWcfkTT2 Cc: roll@ietf.org Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 17 Oct 2012 16:03:30 -0000 This is a multi-part message in MIME format. --------------070905000305010101020309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam thanks for the input but we are not going to submit this draft to MANET, as the intention is to describe energy-aware metrics. The scenarios described relate to LLNs, and the intention is to test in the future the performance of the metrics with RPL. Currently, this was tested only with AODV and OLSR as we did not have RPL available for ns2. The metrics are agnostic to the protocols. So the draft does not intend to create an extension of AODV, nor of OLSR. Anyway, we appreciate any feedback and would very much like contributions from ROLL involved elements. BR Rute Sofia On 10/17/2012 03:09 PM, Abdussalam Baryun wrote: > *Hi Antonio,* > If this draft is for all wireless multihop routings, then I suggest it > to be posted also to MANET list, so you can get feedback also, > AB > > On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveira Junior > > wrote: > > Dear All, > > We submitted a new Internet-draft "Energy-awareness metrics global > applicability guidelines". > > http://tools.ietf.org/html/draft-ajunior-energy-awareness-00 > > Abstract: This document describes a new set of energy-awareness > metrics which have been devised to be applicable to any multihop > routing protocol, including the Routing for Low Power and Lossy > Networks (RPL) protocol. > > We appreciate your comments, > > Sincerely, > > -- > Antonio C. Oliveira Junior, PhD Student Computer Science > MAP-i Doctoral Programme (www.map.edu.pt/i ) > Researcher at IAN/SITI (http://siti.ulusofona.pt/) > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for Technology Research Unit in Informatics Systems and Technologies (SITI) Coordinator of the Internet Architecture and Networking Lab (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: 217 515 500 Fax: 21 757 7006 ....................................................... --------------070905000305010101020309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Abdussalam

thanks for the input but we are not going to submit this draft to MANET, as the intention is to describe energy-aware metrics. The scenarios described relate to LLNs, and the intention is to test in the future the performance of the metrics with RPL. Currently, this was tested only with AODV and OLSR as we did not have RPL available for ns2.

The metrics are agnostic to the protocols. So the draft does not intend to create an extension of AODV, nor of OLSR.

Anyway, we appreciate any feedback and would very much like contributions from ROLL involved elements.

BR
Rute Sofia

On 10/17/2012 03:09 PM, Abdussalam Baryun wrote:
Hi Antonio,
 
If this draft is for all wireless multihop routings, then I suggest it to be posted also to MANET list, so you can get feedback also,
 
AB

On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveira Junior <antoniocojr@gmail.com> wrote:
Dear All,

We submitted a new Internet-draft "Energy-awareness metrics global
applicability guidelines".

http://tools.ietf.org/html/draft-ajunior-energy-awareness-00

Abstract: This document describes a new set of energy-awareness
metrics which have been devised to be applicable to any multihop
routing protocol, including the Routing for Low Power and Lossy
Networks (RPL) protocol.

We appreciate your comments,

Sincerely,

--
Antonio C. Oliveira Junior, PhD Student Computer Science
MAP-i Doctoral Programme (www.map.edu.pt/i)
Researcher at IAN/SITI (http://siti.ulusofona.pt/)
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll



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



-- 
Rute Sofia, PhD (rute.sofia@ulusofona.pt)
Scientific Director for Technology
Research Unit in Informatics Systems and Technologies (SITI)
Coordinator of the Internet Architecture and Networking Lab (IAN Lab)
University Lusofona, Portugal
rute.sofia@ulusofona.pt

http://siti.ulusofona.pt
Tel.: 217 515 500 Fax: 21 757 7006
.......................................................
--------------070905000305010101020309-- From pthubert@cisco.com Wed Oct 17 10:22: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 B611021F867A for ; Wed, 17 Oct 2012 10:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 YL0cYW83+Y19 for ; Wed, 17 Oct 2012 10:22:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4E21F8673 for ; Wed, 17 Oct 2012 10:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2734; q=dns/txt; s=iport; t=1350494548; x=1351704148; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jzW2s242OwjKWjOCEroLDWIrq98E1hiD5yUlvNh4TlE=; b=Nw7F9XWvSHIvbSJiWJdr51zclNTrNXOoqTybe9v62QBl+DL1yPkaB/9M 2pGPFpXpeH6lvbcHtPhj1nAmMM6uWBZjG8869sutJkK1Ezk+eumuWiXIU cX+mwqzBiB4i0zKMc2KeVNq/I+BqUw92UXkGBkETJAc0iAgy12yr5Rqhk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMfoflCtJXHA/2dsb2JhbABFwCCBCIIgAQEBBAEBAQ8BJy0HFwQCAQgOAwQBAQEKFAkHJwsUCQgCBAESCBqHYgubM6ApBIJFiROFYmADpDSBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132652606" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 17 Oct 2012 17:22:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9HHMRE5005203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 17:22:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 12:22:27 -0500 From: "Pascal Thubert (pthubert)" To: Dario Tedeschi , "roll@ietf.org" Thread-Topic: [Roll] Clarification on SenderRank in RPL HbH option Thread-Index: AQHNq7tg9fxdkmlimEOnnaJJGKaa5Je9uw3A Date: Wed, 17 Oct 2012 17:22:26 +0000 Deferred-Delivery: Wed, 17 Oct 2012 17:22:00 +0000 Message-ID: References: <50747202.8020702@exegin.com> <507D8B43.9000008@exegin.com> In-Reply-To: <507D8B43.9000008@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--40.789900-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 Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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, 17 Oct 2012 17:22:34 -0000 Hello Dario: One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" =3D=3D1 whi= ch means that zero is non sensical as a Rank. Instead, RPL allows a node that is not a router for this instance and this = DODAG Version to set the Rank to zero meaning 'I do not have a Rank in that= Version, I'm a dumb leaf' In that case the packet is injected by the first router in the RPL domain a= nd that router is responsible for setting the initial RANK. Till then the Rank is non-sensical and cannot be used. In particular, that = is a way for us to support non-RPL nodes at the edge of the RPL network, an= d it is compatible with the RPL information carried in the flow label. One might envision a mote as a collapsed dumb host and router, and virtuall= y one can figure that both operations happen inside the mote between the tw= o, so the packet is emitted over the radio by the router piece with a corre= ct Rank. For the second point, DAGRank(Rank) must be strictly monotonical. In the ca= se above that is the floor of the Rank of the router. How exactly can that = miss a loop? Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dar= io Tedeschi Sent: mardi 16 octobre 2012 18:29 To: roll@ietf.org Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option Can anyone clarify this for me or at least indicate if it has already been = discussed some time in the past. - Dario On 09/10/2012 11:50 AM, Dario Tedeschi wrote: > > While writing ZigBee-IP test procedures for RPL and discussing with=20 > other ZigBee-IP members, it appears there may be an error in RFC 6550. > > RFC 6550 says: > > SenderRank: 16-bit field set to zero by the source and to > DAGRank(rank) by a router that forwards inside the RPL network. > > Firstly, it seems wrong that the source of a datagram would set its=20 > SenderRank to zero. If this packet were moving up the DAG the first=20 > forwarder would set the Rank-Error bit to 1, because the SenderRank=20 > field in the HbH option would be lower than its own rank. Similarly,=20 > if the datagram were mistakenly moving down the DAG, where the=20 > source's real rank was higher than the forwarder's rank a potential=20 > routing loop could be missed. > > Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank=20 > is a 16bit field. Wouldn't doing this allow for potential routing=20 > loops to be missed? > > Could someone (preferably one of the RPL authors) please clarify. > > - Dario > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From xspikeanand@gmail.com Wed Oct 17 10:26: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 D7AFB21F867A for ; Wed, 17 Oct 2012 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 by7pxQzAi8PA for ; Wed, 17 Oct 2012 10:26:22 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 277E121F8630 for ; Wed, 17 Oct 2012 10:26:21 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so3556145bkc.31 for ; Wed, 17 Oct 2012 10:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9W+jlWbgPN5vuOGNdOnX97wwHVu7eP0VRdc7Q7ceE4M=; b=dKXv2lX54KuADQ1K6KtpzxAKpE7jJq6D8jsObfwKHrQ971nfXsIk/rJMOK8lo4Jz4c qx9tm5um+iGNSw4BFLbon2+PPvx+P9FiNsYVejG9Fbap999kRB3+yGsgEchKrqlbOlPQ N8RGmnJy6yHu4V4m+H92xigOR0v8zUqr4R2tvUpd4eDCU0EkwrqKTuw2DGl66u2yuwCD 9Ex+lef5q4qnalNwWZwy7VveQsbDITNypRc74ye/efMA15ocbLbDPV0EAN8oh0woM1QY nZgdPX579RD6rykPX5ensTLessFGOPNfYutsY9eJEqx4jn6JEObVAK3yuMrPiNRrG5J/ Qb7g== MIME-Version: 1.0 Received: by 10.204.130.21 with SMTP id q21mr5505489bks.5.1350494781214; Wed, 17 Oct 2012 10:26:21 -0700 (PDT) Received: by 10.204.19.10 with HTTP; Wed, 17 Oct 2012 10:26:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 22:56:21 +0530 Message-ID: From: Anandghan W To: roll@ietf.org Content-Type: multipart/alternative; boundary=0015173fe53ab48ee704cc4491f6 Subject: [Roll] Time Synchronized Routing Protocol 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, 17 Oct 2012 17:26:22 -0000 --0015173fe53ab48ee704cc4491f6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have got a project to develop Time Synchronized Routing Protocol for 6LoWPAN . Can anyone please give me some initial leads ? Please Respond . Thanx. Regards, Anandghan --0015173fe53ab48ee704cc4491f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0=A0=A0=A0=A0=A0=A0=A0 I have got a= project to develop Time Synchronized Routing Protocol for 6LoWPAN . Can an= yone please give me some initial leads ? Please Respond .
Thanx.
Regards,
Anandghan

--0015173fe53ab48ee704cc4491f6-- From dat@exegin.com Wed Oct 17 12:14:39 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 BB8E221F867E for ; Wed, 17 Oct 2012 12:14:39 -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 JS9pQwgso+gL for ; Wed, 17 Oct 2012 12:14:37 -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 E239A21F867C for ; Wed, 17 Oct 2012 12:14:37 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so7469063pbb.31 for ; Wed, 17 Oct 2012 12:14:37 -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=9GyUrIpnU3BIdPmOwleHgbBeS2yURv/pWN2psSrXp+Q=; b=Xrt1nqrurX+bbmb6mb4W39lSw1BeGeD4iKvwnFPGwxoRWVZHOd8Yxm69yLDuecxOiP n5r8c7fJMvSE9Ck+TRVfljr6O5x/r4Ld30qW3PZos07w86XJKg4kBHB13oCA0lEWg5oy /i9j6RJYqNJYfXJzdOq8ViPR/wD8pNwoxv4VM+FAPvuflYnmSN5G1U6aQyxOyhyxMDxX 2rOJlyacMKf+O/AbqMwi1PDC7dvrQQvHF2ET+fiUJkTRGReV3S3zeGz1rEiSLQTaE2OS 5zK9noiJgK36OIomcR6WpBoFewOzlg0bWYn/PB69Ppnok8BgUvNJwqJXyDOQwvm15XRX iL2g== Received: by 10.68.232.163 with SMTP id tp3mr59368295pbc.44.1350501277620; Wed, 17 Oct 2012 12:14:37 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id nu8sm12901364pbc.45.2012.10.17.12.14.36 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 12:14:36 -0700 (PDT) Message-ID: <507F039F.1070300@exegin.com> Date: Wed, 17 Oct 2012 12:14:39 -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: "Pascal Thubert (pthubert)" References: <50747202.8020702@exegin.com> <507D8B43.9000008@exegin.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmU6ptzHViRHV+Tk0v8VSRM0lSGI6Snbl2QERk0hTt8O6BZ8pXR7/ghuegdnwU/x0tRTjM5 Cc: "roll@ietf.org" Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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, 17 Oct 2012 19:14:39 -0000 Hi Pascal Thanks for the response. Please see my comments in line. Regards Dario On 17/10/2012 10:22 AM, Pascal Thubert (pthubert) wrote: > Hello Dario: > > One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" ==1 which means that zero is non sensical as a Rank. > > Instead, RPL allows a node that is not a router for this instance and this DODAG Version to set the Rank to zero meaning 'I do not have a Rank in that Version, I'm a dumb leaf' > In that case the packet is injected by the first router in the RPL domain and that router is responsible for setting the initial RANK. > Till then the Rank is non-sensical and cannot be used. In particular, that is a way for us to support non-RPL nodes at the edge of the RPL network, and it is compatible with the RPL information carried in the flow label. > > One might envision a mote as a collapsed dumb host and router, and virtually one can figure that both operations happen inside the mote between the two, so the packet is emitted over the radio by the router piece with a correct Rank. So if a node is *not* acting as a leaf node and it originates a packet, should it set the SenderRank field to its real integer rank (i.e. DAGRank(Rank) or zero? > For the second point, DAGRank(Rank) must be strictly monotonical. In the case above that is the floor of the Rank of the router. How exactly can that miss a loop? I admit that, after running through several scenarios on paper, it does appear highly unlikely. I was just concerned that DAGRank() truncates rank information that might be needed for loop detection, but I can't qualify that or come up with any good examples. > Cheers, > > Pascal > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dario Tedeschi > Sent: mardi 16 octobre 2012 18:29 > To: roll@ietf.org > Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option > > > Can anyone clarify this for me or at least indicate if it has already been discussed some time in the past. > > - Dario > > On 09/10/2012 11:50 AM, Dario Tedeschi wrote: >> While writing ZigBee-IP test procedures for RPL and discussing with >> other ZigBee-IP members, it appears there may be an error in RFC 6550. >> >> RFC 6550 says: >> >> SenderRank: 16-bit field set to zero by the source and to >> DAGRank(rank) by a router that forwards inside the RPL network. >> >> Firstly, it seems wrong that the source of a datagram would set its >> SenderRank to zero. If this packet were moving up the DAG the first >> forwarder would set the Rank-Error bit to 1, because the SenderRank >> field in the HbH option would be lower than its own rank. Similarly, >> if the datagram were mistakenly moving down the DAG, where the >> source's real rank was higher than the forwarder's rank a potential >> routing loop could be missed. >> >> Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank >> is a 16bit field. Wouldn't doing this allow for potential routing >> loops to be missed? >> >> Could someone (preferably one of the RPL authors) please clarify. >> >> - Dario >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert_cisco@yahoo.fr Wed Oct 17 13:01: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 3100F21F86B6 for ; Wed, 17 Oct 2012 13:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VhFnryAuj5s4 for ; Wed, 17 Oct 2012 13:01:18 -0700 (PDT) Received: from nm12.bullet.mail.ird.yahoo.com (nm12.bullet.mail.ird.yahoo.com [77.238.189.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3202621F8698 for ; Wed, 17 Oct 2012 13:01:18 -0700 (PDT) Received: from [77.238.189.52] by nm12.bullet.mail.ird.yahoo.com with NNFMP; 17 Oct 2012 20:01:11 -0000 Received: from [217.146.189.73] by tm5.bullet.mail.ird.yahoo.com with NNFMP; 17 Oct 2012 20:01:11 -0000 Received: from [127.0.0.1] by smtp114-mob.biz.mail.ird.yahoo.com with NNFMP; 17 Oct 2012 20:01:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1350504071; bh=QwmOFmkOGUjWX7GS4gBtbtS0MoHoy9OfzAhRo3EqxDo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=VMCGOTqCUnTgDvQzAauvLNwHuCy3aiW9VTaxg24UNaZduGeYM5W21bdwKnOut6l5dth8Jg6OM6/WaFjgDI0/EdC1CzeEv0vearlD3M5oFmc2kIBkkY7WMWxpjlfZffJZTqZj5feicrtx03AXnVc4wDtB07Kko02Cn3IDcYVa9LI= X-Yahoo-Newman-Id: 790154.69768.bm@smtp114-mob.biz.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: iZoaI_UVM1k2bnjcTfpWLu47uadhwzbEf7a9lqPMJtXid0C 7LHEyCBQkzsdvDPH508GeeSdHg1cU21YqH6C_ySGz92Ks.1cye6k5pdQT9rp NN1Vme4gIgokfxuK2HqKphHymVfKU07_2U0MbgUbkzfGYUvhE0QBrCqF7MEs CCYM5N3JETIMr09GjsYvjgiOsVcowk41cpaflCUJT0NlAgFmph2omoUCj55E S91.497bi.9Lj3NSfHMOV3FN0vH8JdPRVuk3MexRUmCrPl_aImuzbadnoFCs HuOND2cLxWsPWb.YSrvY4auHYy04cMYoaDwBW7rH2WPmnrzmEyDpQHfq56Ym wooV2sJ_BwpxPOz9D9SvdmMnhMR2y99kkoBSPcM4OSJA6QyonfBBhPwwO4WU 5b6ssqE4TQT4A.ZqgzKTmmcT4O8VF_p.F_y74_.iirpHxZc0- X-Yahoo-SMTP: 4yMEliGswBAasvpyZFHmebLo1Uyca4YzEGiW Received: from [192.168.122.224] (pthubert_cisco@78.231.82.172 with xymcookie) by smtp114-mob.biz.mail.ird.yahoo.com with SMTP; 17 Oct 2012 20:01:11 +0000 UTC References: <50747202.8020702@exegin.com> <507D8B43.9000008@exegin.com> <507F039F.1070300@exegin.com> Mime-Version: 1.0 (1.0) In-Reply-To: <507F039F.1070300@exegin.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1C9BF5D8-2BFC-42CA-8541-C7A5C1330D4A@yahoo.fr> X-Mailer: iPhone Mail (10A405) From: Pascal Thubert Date: Wed, 17 Oct 2012 22:01:08 +0200 To: Dario Tedeschi Cc: "roll@ietf.org" Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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, 17 Oct 2012 20:01:19 -0000 Hi Dario; A node that is not a leaf and participates to RPL is a router and therefore m= ust advertize its real nonZero Rank... Cheers, Pascal Le 17 oct. 2012 =C3=A0 21:14, Dario Tedeschi a =C3=A9crit := > Hi Pascal >=20 > Thanks for the response. Please see my comments in line. >=20 > Regards > Dario >=20 > On 17/10/2012 10:22 AM, Pascal Thubert (pthubert) wrote: >> Hello Dario: >>=20 >> One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" =3D=3D1 w= hich means that zero is non sensical as a Rank. >>=20 >> Instead, RPL allows a node that is not a router for this instance and thi= s DODAG Version to set the Rank to zero meaning 'I do not have a Rank in tha= t Version, I'm a dumb leaf' >=20 >> In that case the packet is injected by the first router in the RPL domain= and that router is responsible for setting the initial RANK. >> Till then the Rank is non-sensical and cannot be used. In particular, tha= t is a way for us to support non-RPL nodes at the edge of the RPL network, a= nd it is compatible with the RPL information carried in the flow label. >>=20 >> One might envision a mote as a collapsed dumb host and router, and virtua= lly one can figure that both operations happen inside the mote between the t= wo, so the packet is emitted over the radio by the router piece with a corre= ct Rank. >=20 > So if a node is *not* acting as a leaf node and it originates a packet, sh= ould it set the SenderRank field to its real integer rank (i.e. DAGRank(Rank= ) or zero? >=20 >=20 >> For the second point, DAGRank(Rank) must be strictly monotonical. In the c= ase above that is the floor of the Rank of the router. How exactly can that m= iss a loop? >=20 > I admit that, after running through several scenarios on paper, it does ap= pear highly unlikely. I was just concerned that DAGRank() truncates rank inf= ormation that might be needed for loop detection, but I can't qualify that o= r come up with any good examples. >=20 >> Cheers, >>=20 >> Pascal >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of D= ario Tedeschi >> Sent: mardi 16 octobre 2012 18:29 >> To: roll@ietf.org >> Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option >>=20 >>=20 >> Can anyone clarify this for me or at least indicate if it has already bee= n discussed some time in the past. >>=20 >> - Dario >>=20 >> On 09/10/2012 11:50 AM, Dario Tedeschi wrote: >>> While writing ZigBee-IP test procedures for RPL and discussing with >>> other ZigBee-IP members, it appears there may be an error in RFC 6550. >>>=20 >>> RFC 6550 says: >>>=20 >>> SenderRank: 16-bit field set to zero by the source and to >>> DAGRank(rank) by a router that forwards inside the RPL network.= >>>=20 >>> Firstly, it seems wrong that the source of a datagram would set its >>> SenderRank to zero. If this packet were moving up the DAG the first >>> forwarder would set the Rank-Error bit to 1, because the SenderRank >>> field in the HbH option would be lower than its own rank. Similarly, >>> if the datagram were mistakenly moving down the DAG, where the >>> source's real rank was higher than the forwarder's rank a potential >>> routing loop could be missed. >>>=20 >>> Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank >>> is a 16bit field. Wouldn't doing this allow for potential routing >>> loops to be missed? >>>=20 >>> Could someone (preferably one of the RPL authors) please clarify. >>>=20 >>> - Dario >>>=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 dat@exegin.com Wed Oct 17 14:12: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 D3EDC21F86F5 for ; Wed, 17 Oct 2012 14:12:06 -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 Th5EYT9KmFMh for ; Wed, 17 Oct 2012 14:12:06 -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 3072521F8672 for ; Wed, 17 Oct 2012 14:12:06 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so7566456pbb.31 for ; Wed, 17 Oct 2012 14:12:06 -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=WsO+bP09bDy32tqsSoDjyxquTc04pX+D2Ob9l8EWt6k=; b=Y5Jy7QgByoS1khMvnXr0rBTS4pBD9IgA3zTBBGQmLBp+qYHQkh2U7MALnzy6b1kxWq DT2VyMEvdLwUisE7RBmyjUNRVsLGKdbpRwTSVOoptFQEQLJ+miDKda5yZu+MmU/DJgwX J7cpufPSksMSIix1Mj52pac15KlvtFGMksssTDrm+18ViLMe7B1vKvqMEbPwSMFBCzaO Wyii17oQ+nbsChL4sitpVAlozGseGBdRCeBui0gOLvCtvaERvmkBvkxBhx+2H9KjvLWx 04bVTDP1ApKGbNGWwhpCpu6wAJ6lftZHwuXxuZXufu1HzgRv6O0wJ9+Ysqjzrlskya7O fu+Q== Received: by 10.68.248.74 with SMTP id yk10mr55748272pbc.86.1350508325902; Wed, 17 Oct 2012 14:12:05 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id to8sm13032255pbc.11.2012.10.17.14.12.04 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 14:12:05 -0700 (PDT) Message-ID: <507F1F27.4030001@exegin.com> Date: Wed, 17 Oct 2012 14:12: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: Pascal Thubert References: <50747202.8020702@exegin.com> <507D8B43.9000008@exegin.com> <507F039F.1070300@exegin.com> <1C9BF5D8-2BFC-42CA-8541-C7A5C1330D4A@yahoo.fr> In-Reply-To: <1C9BF5D8-2BFC-42CA-8541-C7A5C1330D4A@yahoo.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnkXdeBPb5Aj4Fc6gPWDZh7TcNDX658dH5/pFY6ico8Z8Qxzt7PAxapoDgYezgaHwgqBTcm Cc: "roll@ietf.org" Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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, 17 Oct 2012 21:12:06 -0000 Ok, then I think the following text in RFC 6550 is misleading: """ SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network. """ It should be something like: SenderRank: 16-bit field set to DAGRank(rank) by a RPL router or to zero by a source that is only acting as leaf node inside a RPL network. What do you think? - Dario On 17/10/2012 1:01 PM, Pascal Thubert wrote: > Hi Dario; > > A node that is not a leaf and participates to RPL is a router and therefore must advertize its real nonZero Rank... > > Cheers, > > Pascal > > Le 17 oct. 2012 à 21:14, Dario Tedeschi a écrit : > >> Hi Pascal >> >> Thanks for the response. Please see my comments in line. >> >> Regards >> Dario >> >> On 17/10/2012 10:22 AM, Pascal Thubert (pthubert) wrote: >>> Hello Dario: >>> >>> One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" ==1 which means that zero is non sensical as a Rank. >>> >>> Instead, RPL allows a node that is not a router for this instance and this DODAG Version to set the Rank to zero meaning 'I do not have a Rank in that Version, I'm a dumb leaf' >>> In that case the packet is injected by the first router in the RPL domain and that router is responsible for setting the initial RANK. >>> Till then the Rank is non-sensical and cannot be used. In particular, that is a way for us to support non-RPL nodes at the edge of the RPL network, and it is compatible with the RPL information carried in the flow label. >>> >>> One might envision a mote as a collapsed dumb host and router, and virtually one can figure that both operations happen inside the mote between the two, so the packet is emitted over the radio by the router piece with a correct Rank. >> So if a node is *not* acting as a leaf node and it originates a packet, should it set the SenderRank field to its real integer rank (i.e. DAGRank(Rank) or zero? >> >> >>> For the second point, DAGRank(Rank) must be strictly monotonical. In the case above that is the floor of the Rank of the router. How exactly can that miss a loop? >> I admit that, after running through several scenarios on paper, it does appear highly unlikely. I was just concerned that DAGRank() truncates rank information that might be needed for loop detection, but I can't qualify that or come up with any good examples. >> >>> Cheers, >>> >>> Pascal >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dario Tedeschi >>> Sent: mardi 16 octobre 2012 18:29 >>> To: roll@ietf.org >>> Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option >>> >>> >>> Can anyone clarify this for me or at least indicate if it has already been discussed some time in the past. >>> >>> - Dario >>> >>> On 09/10/2012 11:50 AM, Dario Tedeschi wrote: >>>> While writing ZigBee-IP test procedures for RPL and discussing with >>>> other ZigBee-IP members, it appears there may be an error in RFC 6550. >>>> >>>> RFC 6550 says: >>>> >>>> SenderRank: 16-bit field set to zero by the source and to >>>> DAGRank(rank) by a router that forwards inside the RPL network. >>>> >>>> Firstly, it seems wrong that the source of a datagram would set its >>>> SenderRank to zero. If this packet were moving up the DAG the first >>>> forwarder would set the Rank-Error bit to 1, because the SenderRank >>>> field in the HbH option would be lower than its own rank. Similarly, >>>> if the datagram were mistakenly moving down the DAG, where the >>>> source's real rank was higher than the forwarder's rank a potential >>>> routing loop could be missed. >>>> >>>> Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRank >>>> is a 16bit field. Wouldn't doing this allow for potential routing >>>> loops to be missed? >>>> >>>> Could someone (preferably one of the RPL authors) please clarify. >>>> >>>> - Dario >>>> >>> _______________________________________________ >>> Roll mailing 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 rute.sofia@ulusofona.pt Wed Oct 17 14:53: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 9B6A321F866C for ; Wed, 17 Oct 2012 14:53:25 -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=[AWL=0.001, 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 ayjUBE8r0mqr for ; Wed, 17 Oct 2012 14:53:24 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 980B521F871C for ; Wed, 17 Oct 2012 14:53:22 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2115731eaa.31 for ; Wed, 17 Oct 2012 14:53: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=L3nto9WFGO5vlDSq6Sb8U2GT/iFfbkElsBxEYu1wwG8=; b=cHT1+YZLD4aLpLm+5fw38MzlnPTvh+AEwgfxtmtTNTha+sl/io1Z9AQ4JizIIW+Haz +XK4jZmTpwo6Zai5hhyTmHF9sKDoyfqXzmEPV7MVyGTSBm6JxBjG53glMoq6beC/Jqbp LzndVeIUcBHt9UShzYNbQ3WKxExTADA588kGHMHjeVIxCZZhowPQLEDI/+TJracTijiA rYoXir9Wzw3dGec1WYS6XCWRtMWDQEsD6vWL2DVqyx+7b/PxUAyQo7aX7rx58cGLEotX VuNlkifjpLXkQCi5hPYO2p8tmlMGcKg1tjUjZTJdg8KU3/w46eFWjNjffJZf0NzOnWE9 +LGw== Received: by 10.14.200.134 with SMTP id z6mr28856271een.33.1350510801427; Wed, 17 Oct 2012 14:53:21 -0700 (PDT) Received: from linux-phf7.site ([89.181.195.175]) by mx.google.com with ESMTPS id v3sm37042537een.1.2012.10.17.14.53.19 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 14:53:20 -0700 (PDT) Message-ID: <507F27CF.1080205@ulusofona.pt> Date: Wed, 17 Oct 2012 22:49:03 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Michael Richardson References: <507ED5CF.7040507@ulusofona.pt> <21203.1350504863@obiwan.sandelman.ca> In-Reply-To: <21203.1350504863@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnMlmFgsmQ2r1VpmWeS82M6yrzvi0LHwcI8StLJQT8kgZIYxCuwZ6dU3QEafcoCkF0Ot+jQ Cc: roll@ietf.org Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 17 Oct 2012 21:53:25 -0000 Hello Michael, inline. On 10/17/2012 09:14 PM, Michael Richardson wrote: >>>>>> "Rute" == Rute Sofia writes: > Rute> thanks for the input but we are not going to submit this draft > Rute> to MANET, as the intention is to describe energy-aware > Rute> metrics. The scenarios described relate to LLNs, and the > Rute> intention is to test in the future the performance of the > Rute> metrics with RPL. Currently, this was tested only with AODV > Rute> and OLSR as we did not have RPL available for ns2. > > okay. > I see that you have a section "RPL Applicability Guidelines". > Could you change this something like "Using Energy Aware Metric with RPL"? Yes, of course. > It seems that you have a rather straightforward metric calculation, > backed up some other papers, and you are basically just explaining how > to fit this into several protocols. > > Wouldn't three documents make more sense? (Certainly ROLL couldn't > publish a document about AODV and vv) Hum, that was never an intention but we can indeed consider deepening ROLL's part. The metrics have indeed been validated by scientific publications. Otherwise, we could not understand whether or not the performance improvement was reasonable enough to consider operational aspects, and implementation. However: we have analysed ROLL's drafts (there is a report available here: http://siti.ulusofona.pt/aigaion/index.php/publications/show/333) and realized that the metrics could be an interesting contribution as they have been devised to be independent of the protocolar operation, and were thought having in mind a subset of LLNs (what we name as user-centric networks, which are basically networks composed of end-user, portable equipment, that becomes part of the network because the user wants to share some networking service or resources). So: it is not our intention to release 3 documents... The metrics do not reflect the need to create any new extension specifically for AODV nor for OLSR. Instead, we believe that these metrics are useful to ROLL, as they improve network robustness based on the notion of increasing network lifetime. Which is something relevant in LLNs. Of course, we will assist (if code is available) any validation in RPL. Which may help in understanding implications, pros and cons. > While we have a nice metric container to hold the values, it would be > important to explain that the metric to use is a provisioned parameter, > and does not need to be signaled in the protocol anywhere. As said, we can indeed deepen the implications of applying the metrics in ROLL and we will consider these comments for the next draft version... BR, Rute > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > -- Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for Technology Research Unit in Informatics Systems and Technologies (SITI) Coordinator of the Internet Architecture and Networking Lab (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: 217 515 500 Fax: 21 757 7006 ....................................................... From jvasseur@cisco.com Wed Oct 17 22:16: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 6951E21F85E6 for ; Wed, 17 Oct 2012 22:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 2Q5uM8yaxuHM for ; Wed, 17 Oct 2012 22:16:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CDCCF21F85FF for ; Wed, 17 Oct 2012 22:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3761; q=dns/txt; s=iport; t=1350537385; x=1351746985; h=from:to:subject:date:message-id:mime-version; bh=tCCeq2tv/bjRx9d5Rst4y8PEfC5i0MX+/m+JW+5yGss=; b=TLzoCcJsa2HQh5xTYcVps3TIu+Rg+QQU6YthhZFk4lUbaRdKTB92VmeU WAombiLxw+2TScI4m4rPT3JYERlcX8eXQNHOkd9QKN3r+rvY0ymPImD01 jrX2L1X/pupWQqqyQLU0j7AfOTO5VZKZSF30Z+j2UXgLvqcPLvNMe2F5y Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEmPf1CtJV2b/2dsb2JhbABFgkq9d4EIgiIBBBIBWx0BDB5WJwQbEweHYppdgSugGotYhWJgA6Q0gWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,604,1344211200"; d="scan'208,217";a="132850856" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2012 05:16:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9I5GPgP032116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 05:16:25 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 00:16:25 -0500 From: "JP Vasseur (jvasseur)" To: roll WG Thread-Topic: WG Last Call draft-ietf-roll-security-threats Thread-Index: AQHNrO+4vJffuTmqFkeNA/oIwWSGlg== Date: Thu, 18 Oct 2012 05:16:24 +0000 Message-ID: <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.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--30.295500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FF384Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [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: Thu, 18 Oct 2012 05:16:27 -0000 --_000_03B78081B371D44390ED6E7BADBB4A7721FF384Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. --_000_03B78081B371D44390ED6E7BADBB4A7721FF384Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 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.
--_000_03B78081B371D44390ED6E7BADBB4A7721FF384Dxmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Oct 18 00:48:31 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 37BA221F85DA for ; Thu, 18 Oct 2012 00:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 caKolRFZExAt for ; Thu, 18 Oct 2012 00:48:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2938921F85B4 for ; Thu, 18 Oct 2012 00:48:30 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9317322vbb.31 for ; Thu, 18 Oct 2012 00:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K6qyG4D+OcR81DSZoOrodJc/SMEFXKXi8+76r5Q1JZw=; b=jAyyRmkHg7DCbWCqXnHvDi76yvy6Ml5vT3cF+9mMQhQ9cjl1+eSMZ2+LlkXQx1+cke djqgTGPd7tuMwbp4m4n/Ct4JVrRDwJDUAG8AiAVq5N+EFP9d4ufiiv07aVlz1jDiGa8W dmqf6P5gJIKDevqEKQKzVIw5UGh2r68jt/OKoBT3JdmBhxit+rCjLwpwtM9ljR8hU7Pc RrDXilmBvK0SlxvOGZFOR/6Z2VEG3Ff5esvMIjYc+uK7wSNidw3gbXXndyR3iRJB+dy7 yOAH72Caf9pbO4ootO/0GLUGmASVJmuCLoJBNVLP3lxGt6aBYWfmoc1zGQRzlyEp/e5y hG2g== MIME-Version: 1.0 Received: by 10.58.32.233 with SMTP id m9mr14030966vei.23.1350546509536; Thu, 18 Oct 2012 00:48:29 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 18 Oct 2012 00:48:29 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FF384D@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FF384D@xmb-rcd-x02.cisco.com> Date: Thu, 18 Oct 2012 09:48:29 +0200 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG 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: Thu, 18 Oct 2012 07:48:31 -0000 Hi JP, Why there is WGLC for this initial draft-00, I recommend we check why the return draft and see if the new one is representing all thoes reasons (which I disagreed with IESG). I hope we agree in the coming meeting to comments and WGLC for draft-01, so this can go forward. Was there any other changes than just deleting a section and changing a title (don't think that was the IESG concerns, if it was I am worried)? AB On 10/18/12, 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-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 > 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 your > questions and comments to the authors, copying > the mailing list. > > Thanks. > > JP. > From abdussalambaryun@gmail.com Thu Oct 18 00:52: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 CA65621F85F7 for ; Thu, 18 Oct 2012 00:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 8FhCftoMDMw5 for ; Thu, 18 Oct 2012 00:52:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10EAE21F85F3 for ; Thu, 18 Oct 2012 00:52:06 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so10003463vcb.31 for ; Thu, 18 Oct 2012 00:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KuJPYhYiUyqlu1VlvD598xjSlOLS4vBkogNkBlXfJEE=; b=nIsdrJanYTNs1bNH10jQPYZNz2TkXXBvIgz0VhIMJrc1dqyqWT3zZVUFGL66GjYD9a WFSqMl7BbyQ0y+kxpQWq9Y1sV4CPbOyAsD4vbqWltu9orS42GuoH4h/hafkxfP4EjdNE rwIkMKfmDKS4khxsKLTaN/yKcvkIlkl8voTnpxfIdcGDNtn7D3yawlZbpBqk04smA2Mj mhpRyLp2fKpZGpibtVvv8LvirKiSt84ihSIyCvH+783IohCr2UnW875XxQY4WrJESHNJ zCv38OgVBfiJvNZr1hLtW3IUdd3aje4lHoj0bxmctG5n2B+GQxp/ZbPl3qKpjyPcsJBP 5ZJg== MIME-Version: 1.0 Received: by 10.220.142.8 with SMTP id o8mr4000413vcu.23.1350546725020; Thu, 18 Oct 2012 00:52:05 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 18 Oct 2012 00:52:04 -0700 (PDT) In-Reply-To: <507ED5CF.7040507@ulusofona.pt> References: <507ED5CF.7040507@ulusofona.pt> Date: Thu, 18 Oct 2012 09:52:04 +0200 Message-ID: From: Abdussalam Baryun To: Rute Sofia Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org, Antonio Oliveira Junior Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 18 Oct 2012 07:52:08 -0000 Hi Rute, If you want in for LLN, please than just state that in the Abstract. Your reply to me has strong abstract statements which I don't see in your draft. I really prefered that the abstract to be clear in which network it is for MANETs of LLNs. In IETF there is a different between the two networks now, before 2009 there was no different. AB On 10/17/12, Rute Sofia wrote: > Hello Abdussalam > > thanks for the input but we are not going to submit this draft to MANET, > as the intention is to describe energy-aware metrics. The scenarios > described relate to LLNs, and the intention is to test in the future the > performance of the metrics with RPL. Currently, this was tested only > with AODV and OLSR as we did not have RPL available for ns2. > > The metrics are agnostic to the protocols. So the draft does not intend > to create an extension of AODV, nor of OLSR. > > Anyway, we appreciate any feedback and would very much like > contributions from ROLL involved elements. > > BR > Rute Sofia > > On 10/17/2012 03:09 PM, Abdussalam Baryun wrote: >> *Hi Antonio,* >> If this draft is for all wireless multihop routings, then I suggest it >> to be posted also to MANET list, so you can get feedback also, >> AB >> >> On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveira Junior >> > wrote: >> >> Dear All, >> >> We submitted a new Internet-draft "Energy-awareness metrics global >> applicability guidelines". >> >> http://tools.ietf.org/html/draft-ajunior-energy-awareness-00 >> >> Abstract: This document describes a new set of energy-awareness >> metrics which have been devised to be applicable to any multihop >> routing protocol, including the Routing for Low Power and Lossy >> Networks (RPL) protocol. >> >> We appreciate your comments, >> >> Sincerely, >> >> -- >> Antonio C. Oliveira Junior, PhD Student Computer Science >> MAP-i Doctoral Programme (www.map.edu.pt/i ) >> Researcher at IAN/SITI (http://siti.ulusofona.pt/) >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > -- > Rute Sofia, PhD (rute.sofia@ulusofona.pt) > Scientific Director for Technology > Research Unit in Informatics Systems and Technologies (SITI) > Coordinator of the Internet Architecture and Networking Lab (IAN Lab) > University Lusofona, Portugal > rute.sofia@ulusofona.pt > > http://siti.ulusofona.pt > Tel.: 217 515 500 Fax: 21 757 7006 > ....................................................... > > From jvasseur@cisco.com Thu Oct 18 01:14:14 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 B330F21F8552 for ; Thu, 18 Oct 2012 01:14:13 -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 JxT+WIQHWlpM for ; Thu, 18 Oct 2012 01:14:13 -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 C73D621F853B for ; Thu, 18 Oct 2012 01:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2246; q=dns/txt; s=iport; t=1350548053; x=1351757653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lcbKM5w8jLXnEn1ENFCpe4zhfr84vvRx9HopEp1/EpE=; b=YiJEceWyB85PehY+8c+U63+vjBi6V0ckQwJ81tiMI1o2eB3RTSUexBEe GAzMEQtN3PKvVA1POj6Jnr9OPhPLctgBHQBCQiBEGYAEJFmVYGyYJDBg2 59j1UGA4BlVXW641UtRj5fPilsGGHG3g7n+l+kvT/B46PKNPqHnChstXU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADa5f1CtJXHB/2dsb2JhbABFwDyBCIIgAQEBAwESAVsLBQsCAQgYCiQyJQIEDgUIEweHXAacBqAmi1iFYmADiCOcEYFrgm+BYzQ X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132949982" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 18 Oct 2012 08:14:12 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9I8ECwG024174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 08:14:12 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 03:14:11 -0500 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [Roll] WG Last Call draft-ietf-roll-security-threats Thread-Index: AQHNrO+4vJffuTmqFkeNA/oIwWSGlg== Date: Thu, 18 Oct 2012 08:14:11 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FF44ED@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FF384D@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--51.093600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll WG 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: Thu, 18 Oct 2012 08:14:14 -0000 Hi AB, Jut to shed some light here; as pointed out in the email below, this is not= a -00 draft per say, but the continuation of an effort that started a long time ago. The documen= t used to be=20 draft-ietf-roll-security-framework-07, the name was changed to reflect more= accurately the content. Feel free to send your comments on the content of the document during the n= ext two weeks. Thanks. JP. On Oct 18, 2012, at 9:48 AM, Abdussalam Baryun wrote: > Hi JP, >=20 > Why there is WGLC for this initial draft-00, I recommend we check why > the return draft and see if the new one is representing all thoes > reasons (which I disagreed with IESG). I hope we agree in the coming > meeting to comments and WGLC for draft-01, so this can go forward. Was > there any other changes than just deleting a section and changing a > title (don't think that was the IESG concerns, if it was I am > worried)? >=20 > AB >=20 > On 10/18/12, JP Vasseur (jvasseur) wrote: >> Dear all, >>=20 >> As you know, we have been discussing security framework document in the = WG, >> which is one of our WG item. >>=20 >> draft-ietf-roll-security-threats-00 is a revision of >> draft-ietf-roll-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: >>=20 >> Sep 2012 Submit first draft of RPL threat analysis to the IESG to= be >> considered as an Informational RFC >>=20 >> Section 7 was removed: this is the result of negotiation with the IESG o= n >> where and how security issues will be addressed. >>=20 >> The goal of this new document is to outline threats with the expectation >> 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. >>=20 >> This starts a WG Last call, ending on Nov 9, at noon ET. Please send you= r >> questions and comments to the authors, copying >> the mailing list. >>=20 >> Thanks. >>=20 >> JP. >>=20 From pthubert@cisco.com Thu Oct 18 01:34: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 9F51021F84DF for ; Thu, 18 Oct 2012 01:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 lYJY6QeDEYS5 for ; Thu, 18 Oct 2012 01:34:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8958721F84DE for ; Thu, 18 Oct 2012 01:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6996; q=dns/txt; s=iport; t=1350549267; x=1351758867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c47CSqNs5z0+d3nyu0Q+IqKtljlJia+QUWVhvPe98kM=; b=Kpl+iXn1XJcTNbyk/rqgr0CKp76GaPsawQqj2lCtzz9iD8eMv/FbLTvf EoKhQ62XyClIL/y+1ZCRCvDBpl96uA+WTNC3oxhjhadA4una4utiIPPEl hOVnQt9mGjgkP8NhqtUfIPHNTSrFSnmn+CHiwb3N4ZbQTCcCm/UoPUvAE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFi+f1CtJXG9/2dsb2JhbABFhhK5NnSBCIIgAQEBBAEBAQ8BEBEzBwsMBAIBCA4DBAEBAQICBh0DAgICJQsUAQgIAgQOBQgah2ILnAGNIZMABIEhgSSJE4UwMmADpDSBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132896738" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2012 08:34:27 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9I8YRbd030933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 08:34:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 03:34:26 -0500 From: "Pascal Thubert (pthubert)" To: Dario Tedeschi Thread-Topic: [Roll] Clarification on SenderRank in RPL HbH option Thread-Index: AQHNrJum0xGU1DmLb0+HHBSvu80GDpe+PuUAgAAT1YCAAGlcUA== Date: Thu, 18 Oct 2012 08:34:25 +0000 Deferred-Delivery: Thu, 18 Oct 2012 08:34:00 +0000 Message-ID: References: <50747202.8020702@exegin.com> <507D8B43.9000008@exegin.com> <507F039F.1070300@exegin.com> <1C9BF5D8-2BFC-42CA-8541-C7A5C1330D4A@yahoo.fr> <507F1F27.4030001@exegin.com> In-Reply-To: <507F1F27.4030001@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--46.174300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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, 18 Oct 2012 08:34:28 -0000 SGkgRGFyaW86DQoNCkl0J3MgcHJvYmFibHkgIGEgYml0IGxhdGUgdG8gY2hhbmdlIGFueXRoaW5n IGhlcmUuLi4gSW4gYW55IGNhc2UgSSB0aGluayB0aGF0IHNldCANCicgdG8gIERBR1JhbmsocmFu aykgYnkgYSByb3V0ZXIgdGhhdCBmb3J3YXJkcyBpbnNpZGUgdGhlIFJQTCBuZXR3b3JrJyBpcyB2 ZXJ5IGNsZWFyLg0KDQpOb3RlIHRoYXQgYSBSUEwgcm91dGVyIG1heSBmb3J3YXJkIHRoZSBwYWNr ZXQgb3V0c2lkZSB0aGUgUlBMIGRvbWFpbi4gSW4gd2hpY2ggY2FzZSB5b3VyIHByb3Bvc2FsIGZh aWxzLg0KQWxzbywgdGhlIHRlcm0gc291cmNlIGFsbG93cyBmb3IgYSBob3N0IHRoYXQgaXMgbm90 IGV2ZW4gYSBSUEwgbGVhZiwgYW5kIHRoYXQncyBhbiBpbXBvcnRhbnQgdXNlIGNhc2UgZm9yIHVz LiANCg0KQWxsIGluIGFsbCwgZXZlcnkgc2VudGVuY2UgaXMgdG91Y2h5LCB3YXMgaGFyZCB0byBh Z3JlZSB1cG9uLCBhbmQgYXQgbGVhc3QgdGhhdCBvbmUgZG9lcyBub3Qgc2F5IGFueXRoaW5nIHdy b25nLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBEYXJpbyBUZWRlc2NoaSBbbWFpbHRvOmRhdEBleGVnaW4uY29tXSANClNlbnQ6IG1l cmNyZWRpIDE3IG9jdG9icmUgMjAxMiAyMzoxMg0KVG86IFBhc2NhbCBUaHViZXJ0DQpDYzogUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgcm9sbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtSb2xs XSBDbGFyaWZpY2F0aW9uIG9uIFNlbmRlclJhbmsgaW4gUlBMIEhiSCBvcHRpb24NCg0KT2ssIHRo ZW4gSSB0aGluayB0aGUgZm9sbG93aW5nIHRleHQgaW4gUkZDIDY1NTAgaXMgbWlzbGVhZGluZzoN Cg0KIiIiDQogICBTZW5kZXJSYW5rOiAxNi1iaXQgZmllbGQgc2V0IHRvIHplcm8gYnkgdGhlIHNv dXJjZSBhbmQgdG8NCiAgICAgICAgICBEQUdSYW5rKHJhbmspIGJ5IGEgcm91dGVyIHRoYXQgZm9y d2FyZHMgaW5zaWRlIHRoZSBSUEwgbmV0d29yay4NCiIiIg0KDQpJdCBzaG91bGQgYmUgc29tZXRo aW5nIGxpa2U6DQoNCiAgIFNlbmRlclJhbms6IDE2LWJpdCBmaWVsZCBzZXQgdG8gREFHUmFuayhy YW5rKSBieSBhIFJQTCByb3V0ZXIgb3IgdG8gemVybw0KICAgICAgICAgICBieSBhIHNvdXJjZSB0 aGF0IGlzIG9ubHkgYWN0aW5nIGFzIGxlYWYgbm9kZSBpbnNpZGUgYSBSUEwgbmV0d29yay4NCg0K DQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KLSBEYXJpbw0KDQoNCk9uIDE3LzEwLzIwMTIgMTowMSBQ TSwgUGFzY2FsIFRodWJlcnQgd3JvdGU6DQo+IEhpIERhcmlvOw0KPg0KPiBBIG5vZGUgdGhhdCBp cyBub3QgYSBsZWFmIGFuZCBwYXJ0aWNpcGF0ZXMgdG8gUlBMIGlzIGEgcm91dGVyIGFuZCB0aGVy ZWZvcmUgbXVzdCBhZHZlcnRpemUgaXRzIHJlYWwgbm9uWmVybyBSYW5rLi4uDQo+DQo+IENoZWVy cywNCj4NCj4gUGFzY2FsDQo+DQo+IExlIDE3IG9jdC4gMjAxMiDDoCAyMToxNCwgRGFyaW8gVGVk ZXNjaGk8ZGF0QGV4ZWdpbi5jb20+ICBhIMOpY3JpdCA6DQo+DQo+PiBIaSBQYXNjYWwNCj4+DQo+ PiBUaGFua3MgZm9yIHRoZSByZXNwb25zZS4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbiBsaW5l Lg0KPj4NCj4+IFJlZ2FyZHMNCj4+IERhcmlvDQo+Pg0KPj4gT24gMTcvMTAvMjAxMiAxMDoyMiBB TSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4+PiBIZWxsbyBEYXJpbzoNCj4+ Pg0KPj4+IE9uZSB0aGluZyBpcyAiQSBET0RBRyByb290IE1VU1QgYWR2ZXJ0aXNlIGEgUmFuayBv ZiBST09UX1JBTksiID09MSAgd2hpY2ggbWVhbnMgdGhhdCB6ZXJvIGlzIG5vbiBzZW5zaWNhbCBh cyBhIFJhbmsuDQo+Pj4NCj4+PiBJbnN0ZWFkLCBSUEwgYWxsb3dzIGEgbm9kZSB0aGF0IGlzIG5v dCBhIHJvdXRlciBmb3IgdGhpcyBpbnN0YW5jZSBhbmQgdGhpcyBET0RBRyBWZXJzaW9uIHRvIHNl dCB0aGUgUmFuayB0byB6ZXJvIG1lYW5pbmcgJ0kgZG8gbm90IGhhdmUgYSBSYW5rIGluIHRoYXQg VmVyc2lvbiwgSSdtIGEgZHVtYiBsZWFmJw0KPj4+IEluIHRoYXQgY2FzZSB0aGUgcGFja2V0IGlz IGluamVjdGVkIGJ5IHRoZSBmaXJzdCByb3V0ZXIgaW4gdGhlIFJQTCBkb21haW4gYW5kIHRoYXQg cm91dGVyIGlzIHJlc3BvbnNpYmxlIGZvciBzZXR0aW5nIHRoZSBpbml0aWFsIFJBTksuDQo+Pj4g VGlsbCB0aGVuIHRoZSBSYW5rIGlzIG5vbi1zZW5zaWNhbCBhbmQgY2Fubm90IGJlIHVzZWQuIElu IHBhcnRpY3VsYXIsIHRoYXQgaXMgYSB3YXkgZm9yIHVzIHRvIHN1cHBvcnQgbm9uLVJQTCBub2Rl cyBhdCB0aGUgZWRnZSBvZiB0aGUgUlBMIG5ldHdvcmssIGFuZCBpdCBpcyBjb21wYXRpYmxlIHdp dGggdGhlIFJQTCBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIHRoZSBmbG93IGxhYmVsLg0KPj4+DQo+ Pj4gT25lIG1pZ2h0IGVudmlzaW9uIGEgbW90ZSBhcyBhIGNvbGxhcHNlZCBkdW1iIGhvc3QgYW5k IHJvdXRlciwgYW5kIHZpcnR1YWxseSBvbmUgY2FuIGZpZ3VyZSB0aGF0IGJvdGggb3BlcmF0aW9u cyBoYXBwZW4gaW5zaWRlIHRoZSBtb3RlIGJldHdlZW4gdGhlIHR3bywgc28gdGhlIHBhY2tldCBp cyBlbWl0dGVkIG92ZXIgdGhlIHJhZGlvIGJ5IHRoZSByb3V0ZXIgcGllY2Ugd2l0aCBhIGNvcnJl Y3QgUmFuay4NCj4+IFNvIGlmIGEgbm9kZSBpcyAqbm90KiBhY3RpbmcgYXMgYSBsZWFmIG5vZGUg YW5kIGl0IG9yaWdpbmF0ZXMgYSBwYWNrZXQsIHNob3VsZCBpdCBzZXQgdGhlIFNlbmRlclJhbmsg ZmllbGQgdG8gaXRzIHJlYWwgaW50ZWdlciByYW5rIChpLmUuIERBR1JhbmsoUmFuaykgb3IgemVy bz8NCj4+DQo+Pg0KPj4+IEZvciB0aGUgc2Vjb25kIHBvaW50LCBEQUdSYW5rKFJhbmspIG11c3Qg YmUgc3RyaWN0bHkgbW9ub3RvbmljYWwuIEluIHRoZSBjYXNlIGFib3ZlIHRoYXQgaXMgdGhlIGZs b29yIG9mIHRoZSBSYW5rIG9mIHRoZSByb3V0ZXIuIEhvdyBleGFjdGx5IGNhbiB0aGF0IG1pc3Mg YSBsb29wPw0KPj4gSSBhZG1pdCB0aGF0LCBhZnRlciBydW5uaW5nIHRocm91Z2ggc2V2ZXJhbCBz Y2VuYXJpb3Mgb24gcGFwZXIsIGl0IGRvZXMgYXBwZWFyIGhpZ2hseSB1bmxpa2VseS4gSSB3YXMg anVzdCBjb25jZXJuZWQgdGhhdCBEQUdSYW5rKCkgdHJ1bmNhdGVzIHJhbmsgaW5mb3JtYXRpb24g dGhhdCBtaWdodCBiZSBuZWVkZWQgZm9yIGxvb3AgZGV0ZWN0aW9uLCBidXQgSSBjYW4ndCBxdWFs aWZ5IHRoYXQgb3IgY29tZSB1cCB3aXRoIGFueSBnb29kIGV4YW1wbGVzLg0KPj4NCj4+PiBDaGVl cnMsDQo+Pj4NCj4+PiBQYXNjYWwNCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRGFyaW8gVGVkZXNjaGkNCj4+PiBTZW50OiBtYXJkaSAxNiBv Y3RvYnJlIDIwMTIgMTg6MjkNCj4+PiBUbzogcm9sbEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJl OiBbUm9sbF0gQ2xhcmlmaWNhdGlvbiBvbiBTZW5kZXJSYW5rIGluIFJQTCBIYkggb3B0aW9uDQo+ Pj4NCj4+Pg0KPj4+IENhbiBhbnlvbmUgY2xhcmlmeSB0aGlzIGZvciBtZSBvciBhdCBsZWFzdCBp bmRpY2F0ZSBpZiBpdCBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBzb21lIHRpbWUgaW4gdGhl IHBhc3QuDQo+Pj4NCj4+PiAtIERhcmlvDQo+Pj4NCj4+PiBPbiAwOS8xMC8yMDEyIDExOjUwIEFN LCBEYXJpbyBUZWRlc2NoaSB3cm90ZToNCj4+Pj4gV2hpbGUgd3JpdGluZyBaaWdCZWUtSVAgdGVz dCBwcm9jZWR1cmVzIGZvciBSUEwgYW5kIGRpc2N1c3Npbmcgd2l0aA0KPj4+PiBvdGhlciBaaWdC ZWUtSVAgbWVtYmVycywgaXQgYXBwZWFycyB0aGVyZSBtYXkgYmUgYW4gZXJyb3IgaW4gUkZDIDY1 NTAuDQo+Pj4+DQo+Pj4+IFJGQyA2NTUwIHNheXM6DQo+Pj4+DQo+Pj4+ICAgIFNlbmRlclJhbms6 IDE2LWJpdCBmaWVsZCBzZXQgdG8gemVybyBieSB0aGUgc291cmNlIGFuZCB0bw0KPj4+PiAgICAg ICAgICAgREFHUmFuayhyYW5rKSBieSBhIHJvdXRlciB0aGF0IGZvcndhcmRzIGluc2lkZSB0aGUg UlBMIG5ldHdvcmsuDQo+Pj4+DQo+Pj4+IEZpcnN0bHksIGl0IHNlZW1zIHdyb25nIHRoYXQgdGhl IHNvdXJjZSBvZiBhIGRhdGFncmFtIHdvdWxkIHNldCBpdHMNCj4+Pj4gU2VuZGVyUmFuayB0byB6 ZXJvLiBJZiB0aGlzIHBhY2tldCB3ZXJlIG1vdmluZyB1cCB0aGUgREFHIHRoZSBmaXJzdA0KPj4+ PiBmb3J3YXJkZXIgd291bGQgc2V0IHRoZSBSYW5rLUVycm9yIGJpdCB0byAxLCBiZWNhdXNlIHRo ZSBTZW5kZXJSYW5rDQo+Pj4+IGZpZWxkIGluIHRoZSBIYkggb3B0aW9uIHdvdWxkIGJlIGxvd2Vy IHRoYW4gaXRzIG93biByYW5rLiBTaW1pbGFybHksDQo+Pj4+IGlmIHRoZSBkYXRhZ3JhbSB3ZXJl IG1pc3Rha2VubHkgbW92aW5nIGRvd24gdGhlIERBRywgd2hlcmUgdGhlDQo+Pj4+IHNvdXJjZSdz IHJlYWwgcmFuayB3YXMgaGlnaGVyIHRoYW4gdGhlIGZvcndhcmRlcidzIHJhbmsgYSBwb3RlbnRp YWwNCj4+Pj4gcm91dGluZyBsb29wIGNvdWxkIGJlIG1pc3NlZC4NCj4+Pj4NCj4+Pj4gU2Vjb25k bHksIHdoeSBpcyBEQUdSYW5rKHJhbmspIHVzZWQgdG8gc2V0IFNlbmRlclJhbmssIHdoZW4gU2Vu ZGVyUmFuaw0KPj4+PiBpcyBhIDE2Yml0IGZpZWxkLiBXb3VsZG4ndCBkb2luZyB0aGlzIGFsbG93 IGZvciBwb3RlbnRpYWwgcm91dGluZw0KPj4+PiBsb29wcyB0byBiZSBtaXNzZWQ/DQo+Pj4+DQo+ Pj4+IENvdWxkIHNvbWVvbmUgKHByZWZlcmFibHkgb25lIG9mIHRoZSBSUEwgYXV0aG9ycykgcGxl YXNlIGNsYXJpZnkuDQo+Pj4+DQo+Pj4+IC0gRGFyaW8NCj4+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFJvbGwgbWFpbGluZyBsaXN0 DQo+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+PiBSb2xsQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0K From abdussalambaryun@gmail.com Thu Oct 18 01:40: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 91FE121F8569 for ; Thu, 18 Oct 2012 01:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Bz5vqosry88l for ; Thu, 18 Oct 2012 01:40:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D14A121F8532 for ; Thu, 18 Oct 2012 01:40:07 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9373299vbb.31 for ; Thu, 18 Oct 2012 01:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZtcKDVr0Q6+1P3338Rd11HXH/or5ejIg/qntsyrNIKk=; b=VLO7ltTHf2+xNJsbN5rkvKo12U9eqByl4I9MjUO0nY3V+TUDYHEjXxX0eYFmgqhEIk 3mQyXbnxqKo4HBcWGrMN+bP5OLM97tC/1K/nbp0ZgHmxJxckdS9W6sJIU7lMrSG7/EhJ rgabFIXlljXJ3x+iijWNJJLDlz1jhK6wJCpKI7px1wWF+AyGGVgWyNrvs3A50aqqsBnR YAciJQnSX69iEEhBlaGO3nPf/tOVmWuJdIUhZQRgQfyWi+LqJgV+7Z3mt1Zgne1+eDo4 TEy9u/D6yEaN6kCyY2hVcqC4SRoNnCje/acKKp4ATqsp+21jPkZgefnV674jmiiy1C4n YP9g== MIME-Version: 1.0 Received: by 10.52.35.82 with SMTP id f18mr10997754vdj.99.1350549607350; Thu, 18 Oct 2012 01:40:07 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 18 Oct 2012 01:40:07 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7721FF44ED@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A7721FF384D@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A7721FF44ED@xmb-rcd-x02.cisco.com> Date: Thu, 18 Oct 2012 10:40:07 +0200 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG 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: Thu, 18 Oct 2012 08:40:08 -0000 Hi JP Yes I have questions, there was comments from IESG on that draft if I am not mistaken, so does the new draft with new name represent the comments that was given on the framework draft. I suggested before to do like MANET WG drafts related to security documents (draft-SEC and draft-threats), because we are not in Security Area we are in Routing Area. So do I now understand that we have a draft for *threats* and not *threats-analysis*. I beleive they are two different. ------------------------------------------------------------------------------------------------ Our AD send written on Sat, 18 Aug 2012: What we need to do is develop and publish text to address all of these things. There were, thus, two options for this document: 1) Add substantial text to answer the how and why 2) Re-shape it as just a Security Threat Analysis ------------------------------------------------------------------------------------------------ This is my comment/questions for now, before my review, I don't agree for the WGLC. please read the discussion in the link below as well: http://www.ietf.org/mail-archive/web/roll/current/msg07261.html http://www.ietf.org/mail-archive/web/roll/current/msg07269.html http://www.ietf.org/mail-archive/web/roll/current/msg07283.html Finally, I agree that we don't do *threat analysis docs*, but we do only threats docs similar to what the returned draft was doing, because I disagreed with the IESG discuss positions on the return. My worries, will this new draft be ok for the IESG, please explain if you had discussion about this matter which I am not aware of. Regards AB ++++++++++++++++++ On 10/18/12, JP Vasseur (jvasseur) wrote: > Hi AB, > > Jut to shed some light here; as pointed out in the email below, this is not > a -00 draft per say, > but the continuation of an effort that started a long time ago. The document > used to be > draft-ietf-roll-security-framework-07, the name was changed to reflect more > accurately the > content. > > Feel free to send your comments on the content of the document during the > next two weeks. > > Thanks. > > JP. > > On Oct 18, 2012, at 9:48 AM, Abdussalam Baryun wrote: > >> Hi JP, >> >> Why there is WGLC for this initial draft-00, I recommend we check why >> the return draft and see if the new one is representing all thoes >> reasons (which I disagreed with IESG). I hope we agree in the coming >> meeting to comments and WGLC for draft-01, so this can go forward. Was >> there any other changes than just deleting a section and changing a >> title (don't think that was the IESG concerns, if it was I am >> worried)? >> >> AB >> >> On 10/18/12, 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-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 >>> 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 >>> your >>> questions and comments to the authors, copying >>> the mailing list. >>> >>> Thanks. >>> >>> JP. >>> > > From abdussalambaryun@gmail.com Thu Oct 18 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 F153021F8619 for ; Thu, 18 Oct 2012 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 BYivVE3Iq2lz for ; Thu, 18 Oct 2012 01:48:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1B4721F8618 for ; Thu, 18 Oct 2012 01:47:59 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9381645vbb.31 for ; Thu, 18 Oct 2012 01:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hgK+e1fuGODya5xt7hR+U+MvKxoaGpUqImDK+UoBukQ=; b=w6RaWQ+EK1Dhsz9SygLJuKNOsd+4wZN+jbsFATdoCJQXCZks7rMt4YvnywZEZjEZNF 4Vkx46gJPR0EJgzs/LmNeWvQz01jnyQGmTY4qNflAKodwutErbWNq1jjs3lK/03WqQ9Z zthODeeLFHIYHBbjLxDNLeT+J0FKk7XxTJh5iESHFU+hOosO+G3nRp51qWdU5sTXY3gm 9O2zJvpe7AD4pDy+wf6UAyFvrdR+deGTOD5o84FhpSgZ8xVHkdVhkH8p/ZmNTuaNgArm dOguwiy9v0jweJRLCbhVdhmZdXpnj3cAlxoYfQbScipuU97mTuPmKrg4inKaK+8CDMX+ ACkw== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr11236547vdv.20.1350550079450; Thu, 18 Oct 2012 01:47:59 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Thu, 18 Oct 2012 01:47:59 -0700 (PDT) In-Reply-To: References: <50747202.8020702@exegin.com> <507D8B43.9000008@exegin.com> <507F039F.1070300@exegin.com> <1C9BF5D8-2BFC-42CA-8541-C7A5C1330D4A@yahoo.fr> <507F1F27.4030001@exegin.com> Date: Thu, 18 Oct 2012 10:47:59 +0200 Message-ID: From: Abdussalam Baryun To: "Pascal Thubert (pthubert)" , Dario Tedeschi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "roll@ietf.org" Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option 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, 18 Oct 2012 08:48:01 -0000 Hi Dario and Pascal I think we can errata it as it can reduce any doubts, if the WG agrees to such comment. For me I agree your comment, and recommend to discuss errata further. AB On 10/18/12, Pascal Thubert (pthubert) wrote: > Hi Dario: > > It's probably a bit late to change anything here... In any case I think > that set > ' to DAGRank(rank) by a router that forwards inside the RPL network' is > very clear. > > Note that a RPL router may forward the packet outside the RPL domain. In > which case your proposal fails. > Also, the term source allows for a host that is not even a RPL leaf, and > that's an important use case for us. > > All in all, every sentence is touchy, was hard to agree upon, and at leas= t > that one does not say anything wrong. > > Cheers, > > Pascal > > > -----Original Message----- > From: Dario Tedeschi [mailto:dat@exegin.com] > Sent: mercredi 17 octobre 2012 23:12 > To: Pascal Thubert > Cc: Pascal Thubert (pthubert); roll@ietf.org > Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option > > Ok, then I think the following text in RFC 6550 is misleading: > > """ > SenderRank: 16-bit field set to zero by the source and to > DAGRank(rank) by a router that forwards inside the RPL network. > """ > > It should be something like: > > SenderRank: 16-bit field set to DAGRank(rank) by a RPL router or to ze= ro > by a source that is only acting as leaf node inside a RPL > network. > > > What do you think? > > - Dario > > > On 17/10/2012 1:01 PM, Pascal Thubert wrote: >> Hi Dario; >> >> A node that is not a leaf and participates to RPL is a router and >> therefore must advertize its real nonZero Rank... >> >> Cheers, >> >> Pascal >> >> Le 17 oct. 2012 =E0 21:14, Dario Tedeschi a =E9crit : >> >>> Hi Pascal >>> >>> Thanks for the response. Please see my comments in line. >>> >>> Regards >>> Dario >>> >>> On 17/10/2012 10:22 AM, Pascal Thubert (pthubert) wrote: >>>> Hello Dario: >>>> >>>> One thing is "A DODAG root MUST advertise a Rank of ROOT_RANK" =3D=3D1 >>>> which means that zero is non sensical as a Rank. >>>> >>>> Instead, RPL allows a node that is not a router for this instance and >>>> this DODAG Version to set the Rank to zero meaning 'I do not have a Ra= nk >>>> in that Version, I'm a dumb leaf' >>>> In that case the packet is injected by the first router in the RPL >>>> domain and that router is responsible for setting the initial RANK. >>>> Till then the Rank is non-sensical and cannot be used. In particular, >>>> that is a way for us to support non-RPL nodes at the edge of the RPL >>>> network, and it is compatible with the RPL information carried in the >>>> flow label. >>>> >>>> One might envision a mote as a collapsed dumb host and router, and >>>> virtually one can figure that both operations happen inside the mote >>>> between the two, so the packet is emitted over the radio by the router >>>> piece with a correct Rank. >>> So if a node is *not* acting as a leaf node and it originates a packet, >>> should it set the SenderRank field to its real integer rank (i.e. >>> DAGRank(Rank) or zero? >>> >>> >>>> For the second point, DAGRank(Rank) must be strictly monotonical. In t= he >>>> case above that is the floor of the Rank of the router. How exactly ca= n >>>> that miss a loop? >>> I admit that, after running through several scenarios on paper, it does >>> appear highly unlikely. I was just concerned that DAGRank() truncates >>> rank information that might be needed for loop detection, but I can't >>> qualify that or come up with any good examples. >>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf O= f >>>> Dario Tedeschi >>>> Sent: mardi 16 octobre 2012 18:29 >>>> To: roll@ietf.org >>>> Subject: Re: [Roll] Clarification on SenderRank in RPL HbH option >>>> >>>> >>>> Can anyone clarify this for me or at least indicate if it has already >>>> been discussed some time in the past. >>>> >>>> - Dario >>>> >>>> On 09/10/2012 11:50 AM, Dario Tedeschi wrote: >>>>> While writing ZigBee-IP test procedures for RPL and discussing with >>>>> other ZigBee-IP members, it appears there may be an error in RFC 6550= . >>>>> >>>>> RFC 6550 says: >>>>> >>>>> SenderRank: 16-bit field set to zero by the source and to >>>>> DAGRank(rank) by a router that forwards inside the RPL >>>>> network. >>>>> >>>>> Firstly, it seems wrong that the source of a datagram would set its >>>>> SenderRank to zero. If this packet were moving up the DAG the first >>>>> forwarder would set the Rank-Error bit to 1, because the SenderRank >>>>> field in the HbH option would be lower than its own rank. Similarly, >>>>> if the datagram were mistakenly moving down the DAG, where the >>>>> source's real rank was higher than the forwarder's rank a potential >>>>> routing loop could be missed. >>>>> >>>>> Secondly, why is DAGRank(rank) used to set SenderRank, when SenderRan= k >>>>> is a 16bit field. Wouldn't doing this allow for potential routing >>>>> loops to be missed? >>>>> >>>>> Could someone (preferably one of the RPL authors) please clarify. >>>>> >>>>> - Dario >>>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Thu Oct 18 01:49: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 9B0DE21F8507 for ; Thu, 18 Oct 2012 01:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.898 X-Spam-Level: X-Spam-Status: No, score=-9.898 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 3YnzymzHJ+3w for ; Thu, 18 Oct 2012 01:49:14 -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 1198B21F8501 for ; Thu, 18 Oct 2012 01:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38000; q=dns/txt; s=iport; t=1350550147; x=1351759747; h=from:to:subject:date:message-id:mime-version; bh=tgR8NLIxmsbtlpq8OuOUzqYHKxZQ43pBiz4URfcuMyo=; b=LanbbmPYh8aahncEIlIP/+A5sFFOvK6YZ3xOfl4uNnpJ3DW1zAb60ktA wUXsb/kMRqS7OBzP2o494KTiu9Xq7fNn0LYBlYwMKLxW+yzzsXgdT1Byp zO4kRxKWDwVEqH9PKvR3aX2fIQWXKvxhLYtjHH7Tu2jlXM2SkQZMCZCqz M=; X-Files: image001.jpg : 20186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK/Bf1CtJXG+/2dsb2JhbABFgkq9coEIgiIBBAUNARIIATsBHQQBJQEBAQIIFQkFEAEDCQIMFBIBBBIBBgIGDQeHYguaV4EroCUEi26FSGADkA0BUYYhgiiLDIFrgm+BYzQ X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="jpg'145?scan'145,208,217,145";a="132698566" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 Oct 2012 08:49:05 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9I8n4be001771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 08:49:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 03:49:04 -0500 From: "Pascal Thubert (pthubert)" To: "roll@ietf.org" Thread-Topic: Forwarding fragments Thread-Index: Ac2tDV5pdcEMTaBZTASBGYvcxqF0fw== Date: Thu, 18 Oct 2012 08:49:03 +0000 Deferred-Delivery: Thu, 18 Oct 2012 08:49:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--47.708100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [Roll] Forwarding fragments 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, 18 Oct 2012 08:49:15 -0000 --_004_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_ Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_" --_000_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: I was asked by a number of people ( you guys ! ) at a recent IETF meeting t= o publish the state of the (ex 6LoWPAN) fragment forwarding draft at ROLL. The problem is this with large IP packets: in a multiple hop mesh environme= nt with small MTU such as classical 802.15.4, the packet must be fragmented= and recomposed at each hop so it can be routed to the next hop. Current solutions avoid either condition: - avoid IP with mesh under - avoid large packets with small TCP MSS - avoid small MTU with 802.15.4G - avoid meshing with a federating backbone ala 802.11 ESS The draft allows to safely forward fragments over a multihop route over ne= twork. If you think that is desirable please shime in and I'll ask for a slot at t= he next meeting. Cheers, Pascal Thubert IPv6 Engineering pthubert@cisco.com Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille 06410 Biot - Sophia Antipolis France Cisco.com [Description: Description: Description: http://www.cisco.com/web/europe/ima= ges/email/signature/vertical04.jpg] For corporate legal information go to: http://www.cisco.com/web/about/doing= _business/legal/cri/index.html This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. --_000_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

I was asked by a number of people ( you guys ! ) at = a recent IETF meeting to publish the state of the (ex 6LoWPAN) fragment for= warding draft at ROLL.

 

The problem is this with large IP packets: in a mult= iple hop mesh environment with small MTU such as classical 802.15.4, the pa= cket must be fragmented and recomposed at each hop so it can be routed to t= he next hop.

 

Current solutions avoid either condition:=

- avoid IP with mesh under

- avoid large packets with small TCP MSS<= /p>

- avoid small MTU with 802.15.4G

- avoid meshing with a federating backbone ala 802.1= 1 ESS

 

The draft allows to safely forward fragments over&nb= sp; a multihop route over network.

 

If you think that is desirable please shime in and I= ’ll ask for a slot at the next meeting.

 

Cheers,

 

 


Pascal Thubert
IPv6 Engineering

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


Cisco Systems
Village d'Entreprises Green Side bat. T3
400, Avenue Roumanille
06410 Biot - Sophia Antipolis 
France

Cisco.com

3D"Description:

For corporate legal information go to: http://www.cisco.com/web/about/doing_business= /legal/cri/index.html

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

 

 

--_000_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_-- --_004_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20186; creation-date="Thu, 18 Oct 2012 08:49:03 GMT"; modification-date="Thu, 18 Oct 2012 08:49:03 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAASjAAAKQYAADhnAABO2P/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IAEQgAtQDIAwERAAIR AQMRAf/EASsAAQACAwEBAQEAAAAAAAAAAAAHCAQFBgEDAgkBAQACAwEBAQEAAAAAAAAAAAAFBgME BwECCAkQAAEDBAACCAUEAgMBAAAAAAARBAUBAgMGITUQEhMUNBUlJiAxMhYHMCMzF0A2IiQnKBEA AQIEAgMGEQYMBAcBAAAAAQIDEQQFBgASITETEEFRIrV2IDBhcbEycrIjc7MUdNQVNpaBkUJSNdZA ocFigpLCM4OVFtfDNCV10aLSQ1MkJgcSAAAEAgMIDggFAwMFAAAAAAABAgMRBCESshAxQXHRE3N0 IDBRYYGxwSJykjOT0zRAkaEyIyTUBfDC0hSUQlOz8VIVYmPDRGQTAQACAQIFBAIDAQEAAAAAAAEA ESExcRDwQVFhIIGRobHBMNHh8UD/2gAMAwEAAhEDEQAAAZ7/AFp/PaOrDT4Q1On6P4lLEbvHua+J usUf2/8AL6Dw9T5ucmkrYpXpU2N7/qvjfepu2+Yyxs8/FXY7unN/E0Oh+4e8MdQI9n6bHs/U4C0+ s9TkgpU2KGKdRn6M+TJIman8Hhtem+ZGxO7x2UtiiincZ+jNR8yGd7qzrt8sljZoAqZHfoDl8c4J j2uc26i6rxGGzx1PVWvOp2CadjmknZ6P6VGj/wBCT9t8l7vLVea+JqtOl2uXtjnkubHPfj5lqDof ofsvut2P3eNft8D0qro955n4m/SYtjnNr4quVQ0e/RHNwonbZ5XJOWliqmn3qxezxzoPuIA5/wCJ aL8V65n4m9V878v7HO5My0kAVi1O4c78TAlvPz61ERBRJg6DGc5Wovx3mZ83NpCyVB4rHr9vn/Py Xe/UUA8QVh6nvPYuWMtA9HoB4rhg7NoPmWEp5KJaCIh8bHnjidq8Q/HQ+j9hu7+qqK64uxThk5fu vY0AAAAAQBj61o/JU8kr6pdmIWNxfjPG85WI0XXcI7s/a2MDzazmr6PTwHoPAegHiEHT9MkRIKo2 Pg9TF+M8azlZ4D6tu0aPV/MAAAAAAAPTwiL76Hqvd8dt81iw0DixPjYjSbrXGZbJsPnT6P4hj0Hh 6P14/PoHn689/PvgPQI02Lrg+7W8xxe++YqaoHfxMexGc3WtFllcnzBtMeiABIsPYLXUPqdUL7yy O5evyLD2G1tD6lVK+csjqYr4A4bctO4xR3Q4IcSZCWXF+M8YzVcHh6eAFuKF1Lv4mdyPnJjfePgZ WC7+Kncj4yY/3jj+VgqkX3lvp4c7vTO019HPw6gk6FseHj2Iwmq6AAAPp59SrB2WJp2sfTz6EqQd liucrXz9+QAABKELYsT42Itma8AAAP6+cJ/TUHWOpfn3z5+/E7Vq4wzYKrM9ftf8lO4/mvXZcAAA Eow1h+u/8RHuw3xwZB4egAv5zPsUUTVd0WzqdDq7sywNogeyVCd63bv559Q4v5754egA8JUhrB0N hh4VzaGojZAAAAAAAAAAASpDz/b2WsQVkwc7FTAAAAAAAAAAAlaHnpMtVIr779cnEWAbTb0P0+dT qSIAB4egAHh6O/sFS5qMmtLpSQnTW2JEsFPrl5s8RDWh4ly1891mtvRtXboAAAAAAJzu3LcfHm4G Cte73IyfMP3le4Kz/EjH0HbxNlu5jqdaQims356A8PQAAACxF649kZMIeJJgrPk+4Ku4ZmNIC7Hk +3Lk2l1ZOHKv0cAd1L1XBxbXJxtgB4egHh7Zy/8AD8vJg8PSRoC0ZX1hqlrT8V1++ixl143o9SUg +q9QG924rspOtyFNVDQaUvBtU6iAOwkq7qNaQ02tJfb7xWx6FwH6fXwBI0Dasj3BUrUs8Q13oYs5 eeIfb6xVfovcv08tLfOEx1DXGG630jf7cTPFs5TEFc6Jw8XaBaS98Ky8mvENd6H3ktVJCmKgAJEg bVKVetlSsc3FEBfj2yNz4v2EjXY+iLd9fr47uVqldad2PiYyznltOgfn+HK50eLoK9eFmbtxLqN+ CeA9ACS65cP/2gAIAQEAAQUC27b9n+5/u3aja943Rvngdp3yTcU2zabaSk/t7vBXf9+tr/YG+n9g b6f2Bvp/YG+mrbpuOdh927Ufdu1D7ft7te/2Bvp/YG+mqbtuTjD927Ufdu1Evvu845P+wN9P7A30 i9x3+SeaXtOy4dj22vutTb7qVdaj4BRR/wCOatHD3LTUn1bHjB0wvNS5copIePMTVznNUw5sGBRS a5r0afbTttSr7r2udYfeLmfjW9j53kfudV8Aoo/8drzWxtHKSzSj1jRi8upq2fqWKZctmHHnv7bP ARtj9zbS2yiiikxzTo1HhfqNfde//wC+IIaxwYqKPvGxVfTlFFH7Xt8ePZ3ltr+WeSFMTF5mprbf O3xqKKKS/MkENV4X6hX3ZuMBXPuzjW6dW/Hfiv1vgyUUeeLjK+nqKKKXQT/Jmj4G/HnVBRRRRSV5 gghrPC/T6+7dxr7uU2DHbRzr/Booo7p/2o6v/RUUUUUUUUUUUUkvHoIa7wu06vu7cq+71J3jlg+D VRTu7alyiiiiiiiiiiiikh41BCB4XabX3fudfeCkzxyRHBuoooooooooooooooo98WghDcK6ZX3h ulfeKkpxvjOGBRRRRRTiiiinFFFFFFHfibbK3Vtjc1aMm17aul1947rX3ko7w35qtbLsWPrCiiim bV5pvrbizH/QdNXmq62ph1eaca3q9mOv4OYavNSUGoooo4p+8xspSiimlV95btX3n1hRRRRRSd1/ X2n4nls2P+gs9f8A5/w58VPwFg1/X7vxBE5sX9BarX/wnSc2K38O6dr+vyWgqKKZbLq5G/8AxsUU 0mvvPd6+9FFFFFFFFLetfW/dJe/UVLqX47raXXDHdJeO1W7rWiiiiinWOsdY0ivvTeK+9VFFFFFF FNr2TD+For8Oy107+U/xPIa2x338txm6PJbdt4x/iHJ+JWkRKO9P3Vt+Yr3eHujvrCinWFFOsaPX 3rvGNd0vpWwUUUUUUUiPzPG54PWPyGx1redZ2nVWMlv/AOS7dsat/wA2QkrH6l+SXen7K+/N0Uxj a3KKKKKKKKaNX3tu1PebvhVRRRRRRRRRRRRRRRRRRRRRTRa+991p7ykOFyiiiiiiiiiiiiiiiiii iiimiV98bpT3jK8L1FMTRxmtztMrexRRRRRRRRRRRRRSkbgusetu63qKaMwc2brudPeE1wvUUjKK ymuGBRRRRRRRRRRRRRTFT9ty1sc474h3SrSJ7O7TKe8Nyp7vn+GRRSJ4sJ7g2UUUUUUUUUUUUUUw 0/aQQQ02nu/cae7tk4ZVFIXjG7HwaqKKKNIPO6wSkd5cKKKKKKKKYKfsoIIadT3duFPdu08MyikF xi9o4NFFGsc9e2M9bcXXVlYvBWcxWvmKiiijeEfusD1k4YZFMdt2XJZZ1LUEENPp7t2+nuzbeGZR TX+UzTG58xqttbaXX1iGVWLHaJDJbepHP8jBzn1+NdVnY/DGuFFIPlUjGYZHFfqr+l0Vr+Nheggg hqFPdm44dQv2nammk1zdy0I7loRAtdPpFd21MlG34z68W2/GnW7tqZsLPR6ynctCO5aEN22pd32l ppNXXctCO5aEQrXT6RfdtTO7amd21M7tqZ3bUzu2pndtTNOw6hZtP//aAAgBAgABBQKKio3y3yuL MkXGlkVG3HlUWXRMZU8sjTyyNPLI08sjTyyNMcXGJ5XFnlUWVjI1fLI08sjTHFxh5XFnlUWXRkb1 vLI08sjS2Ljq1lYmN8tiuWGT54/l0V+dKKdnUrStOjH8uivz6MfTd9XRjJXlkXdTyzrUK1Us+XRX 52/Iu40SpZ8FtF+G759FhKcsjOW9Fvy6K/Ony6anXqVrWohb8Nfn0WEpyyLp6b1ei34KfCgnx1+f RaSnLIzlpUp/iUJPlsZy3/Hk+WxnLShX/EqSfLY3lxaXfGv6VOjrUK1JLl0by4trQuqvxWv29zy2 tfuvvzfvhc/bWvH11fufK/bYXXwU+V/TJcujeXfG2eOr53BSv3Vb/td1K/dVzt15/npX7qff7PJU rXYZB47wynTbWiX149Ely6O5f+gqFI/BR+UrSotDJH4Mr1V/RkeXx3L/ANBk1u2DNPYaN4Wbxu8k ZB5o/Hgj46s7ScyZ8ON9H3QNLL+vZ8cjy+Ow0rG32Vs/QzQOW1w7jMjuOdtHmTFGRXcr7oBxhyvY qx80x6/myZf0JHl8Xyxz8/8AGkPARfLHXz/xpDwEXyx38+i3Fkvpfiux0/Wo2x1pmxdlXokW+Skd F8sefPobfwvPo/Wt+nJjpktq0ymJr1aynLIvlj359Db+F79H61v09MpyyL5Y++roa/wPv4/gxtLs lrjB2P6Nv09MryyK5Y/+roafwP8A+Posw5MlMbK9e8YLR1SmXF8FjXLfblxX4alKdatKJTpleWRX LJD6uhn4dzi7XEfMb4+yxPs1VMOWuK+9pgvHWG3Dd0NfD5sNua2rDKuBpTFX4JXlcTfK0jX98h1u s9Os9Gl8l2HaShnyOFwZHJ2kmO73/b9Z6dZ6WZJPqvr5Dr9Z6dZ6Nskl2HaSh2kmdpKHaSZ2kodp KHaShLXytY3/2gAIAQMAAQUC2Cfm/O/Pp0gJeWzYpXYZBjirPz1asdomW+Wkk/rTzGQPMZA8wkDz GQJ2ZmMTvz6dPPp0ayUjc28xkDzGQJ+Yl8OXz6dPPp0jpOSvZeYyB5jID6cfMm8Jsc5knZ7nhrtK 9hsHi06Gnhc7jC2srsDXrNneB3abB4xOhp4Uvz4cRP5MeXKnRG+A6Nir+3A882CLd+cYYl5luat7 GuGe8WINPCzGe7M8Qj89WrqrptQncXWuQsx3ZL8VvZ4pZ7c1w1rW6qCCEd4Ho2H6YHnkjzDonPFI INfDP/GIIINM/ZX3wbe6rWPbtC903xVmsuLNeggghH+C6J76YLnc5LdlKYZqq23232zPiUEG3h3v i0EEEKSjWzG7lrb8Qgggggw8H0Tf0wdPW5ynrSERfXsZfxCCDf8AgeeKQQQQQQQQQQQQZeFFJjjS Dp61N09ZQiuFkp/Ogh22bqiCCCCCCCCCCCDTwyikrxpCU9ZmqesoR3CyR45kEEEEEEEEEEEEEEEG 3h1FJLjSFp6zNU9YQY8LXvHKgggggggggh1RBBBBDB/DW6lKVe46DnNbmIWnrEzT1dBvktx0z3Uy XoIIIIXxTyyOvst+xfK3nlyFkU8vjoyy37KwRTxwyQQQQw/xurq1EEIanq8xT1dBBBBBBB7HscWs Oq2/Y9/+i2XW/Y9kexrqjWtv2PGf6VD1tpqcTHsXEGgghZdSlmbjcghD09Xl6erIIIIIIIIUtrUr KOqxaFba0rS2tTDKOsEb1a0EEEEEEEEIinq0tT1VBBBBBBBCRfW6q31hxV3sWt5WOGZ2VtK5XMrL U1mut4W2fLGSlmz1yY+zyIIIIIIIRNPVZa9Ja2vWEEEEEEEG2zYb2rCYxMZZi+j8WeYm/Mcdm0NX GGOm8kY+y7TgxYBBBBBBBCJp6pMV9Xb8aIIIIIIIIIIIIIIIIIIIIIIRVPVJmvq7PjRBBBBBBBBB BBBBBBBBBBBBCLp6nNV9YYcbUEL3GHHdiz2ZrkEEEEEEEEEEEEEKvctLm2bt7UEIl3hulZqvrMZx tQQe+JjeOVBBBBBBBBBBBBBC+v8Azw57sN9sjgrRw/69IWvrM3X1mJ42IISHi4njmQQQQQQQQQQQ QQQyV/cUUUhK+szlfWoXjYghJeNhv50EEEHEpiwZWLzvgggggggghlr+4oopB19anK+twXHGghK+ Og+LhBDO8bNrnEzhpbRg+ykXfVq6QQQQzSbXBlbOcLuxC+6mOy67rXKKKQdfW53nev8A8aCEvzCM dUauqJWlUtpIOaOnUG0trag8aWO8OKXe4KRbzI9xIISnj2b3IzyWzzStr+WvdWqKKKQXO5/HBXTU DjiqY+owOowJXFD9/wCxhBjhxdV9hwp2MIRGOMox6jA6jAzYoTtYLHF0wdRgdRgSWKG792MIdjCH Ywh2MIdjCHYwh2MIQGOCtmv/2gAIAQICBj8CYUphpS1NJUZqSRnEyidJjyzHdpyDy7HUTkHl2YdB OQeWY7tOQUS7EegnIPLs9ROQeXY6icg8ux1E5B5dnqJyDy7HUTkHl2OonIPLMd2nIPLMd2nIPLsd ROQeXY6icg8ux1E5B5djqJyDyzHdpyDyzHdpyDy7HUTkHl2OonIPLsdROQQ/bs9ROQPqSw0laWlK IySRHEiiVJCX0DdkvSJjQOWTEvoEWSuR2mG2zGgcsmJfQIsl6RMaBdkxL6BFkvSJjQLsmJfQIsl6 RMaBdkxL6BFkvSJjQLsmJfQIsl6RMaBdkxL6FFkvSJjQrsmGNCiyW0qkCP5lKYn7MpBW5mvykP2E fmasbiZAz+ZUmJe3IYltzNeIESaz+O5e2ULr+hXZMMaFFktoflVn8sluJFDo5TDx4M0VlAVovykE ngzX5TCZSPyubjCG8dPrDJ4M0dlYltF4glD3uUxKsMn8FZ84oX/9C2h/QrsmGNCiyW00j/kednzT DeuRK8KQifVWzzZQLcw5dqf0K7JhjQosltLsxNuKJKToIsEeIuMIlyOJIUkvYYZKXJRtwKsRYuIP HJ5wnCKKkq3o3oBc5OuqrVoUYo+qm8Jb7YyuqS+aZ4oF6t0Nzko6qtWgZHhw+reBL3S2h/QrsmJc y/sIsltKpj7c8bVa+VPJxBEkpz4iYRUdMYcIbRKPZtSCp37wW++vOTDl/wDG+FK+3TCmm1YKeQIY dV8ZsqFcFPrCVfcHzdbReKnl2l/QrsmJfQIskC9Hf0K7JiX0DdkgXo7+hXZMS+gbskCuxK8Iq2/C KL119X/ZXZMS+gbskCukCx7eWIVTFEBWWJjQOWTEvoG7JArpAse3li2ExoHLJiX0Ddkgm6QLHsa8 YAqYx2ksWwmNA5ZMS2gbskE4rpAsd2KCoEXaEirEhXbphsa6YQMVV3KpXxDYTOgcsmJbQN2SCcV0 hAveuUXwSTvjNFew3IleEb2IESb0LqRBQoMoCsqlexmdA5ZMMlm2FJzSYfEUnmw5sSzSqYb4TWaZ 71XhEOza7xXhjs2u8PwwVVpiGlV4I7FjvleAPisy1bTLj/gHwWZatplx/wAA7FjvleADrNtR0ivC HZtd4fhjs2u8PwwXwWL391XgAqzbN7+4rwiHZtd4rwx2bXeK8MJg0xDSq8Edix3yvAHYsd8rwB2L HfK8Adix3yvAHYsd8rwB2LHfK8Adix3yvAD5ZthKc0qPxFK5sOdAs0mmF6kf/9oACAEDAgY/AppC Jp9DaH1oIkLUkiJKjSVCTIrxcI87N985+oOG9MzCjrFfcWfKCJt93Pqvc9VG/fEf3s13q8oLPTMw tk78VqP1UiJPvQ6aso7d7rqyjt3uurKO3e66so7d7rqygktTcylNTA4ssJ7487N985+oedm+9c/U G1KfeM6hf1q3MY7d7rqyjt3uurKGyZmplJQO84suUedm+9c/UPOzfeufqDalzD5qNP8AvVlHbvdd WUdu911ZQbxvPGeDnqv+sS2cmXVIcfQk0mozTBSiSfNOi8dB3yE7rbv+RVxw8FbkCdHyndb6CeIZ x44JECSurwCsyceO4nR8p3W+gniufEUlOMw3m1ErmneutdG62nBExJa21/kSJp1sq6FTDh0b6zED TVTumCZReIJ6HKd1voFxA0/0IoLluJc/pjA8QgbiI4yCJlNLcIXCQj3jCW9wiIVWu1X7BWVSewb6 N1rGrkEnrTVtIf0y7R3U9DlO630C4g50j2FRymXV7xfjcEUKUSfWKyKXN0xVcWkjxhGaUSoEd7Yt 9G63w8gk9aatpEy00mJk+u/0jEH00bwrppSYLocp3UdAuIOdLYpKJmqG4KktGseHZt9G63w8gk9a atpE5rTts7hoO8RgujyndR0S4gvpbajo3UcPIJPWmrZCb1p22dxWMF0ct2rWOqW3IxXUcIlNZatk JvWXbZ3FYwXR9BTiup4RKay1bITesu2zuKBYvQU4hE7woiYKrgEprLVshNay5bO4ZKES3Nkn7opP ya1VSOOGnBwGEUU5/wDMY/5Sr8nXqxjybmC4r7olPyaFVTOOLBwkJ04U57wg59waTGWa96nk2JAk 4LsrrLdshNaw5bPaJaeaIv3q3YKON8ufgvUQLAJZMac+dpwI035zCkxpz/5iMLn4F++J6EY75UQx UiZTEo58rTYnNN4QnyMyjW4yTATs1MF8w2XNON6ij1nsC2ErrDdshNaw5bPaaAX2jm/tiXWvc7Fi jvR37kDvigOfa0Vf2zqonRTgvdUsAp2mV1hu2QmdYctntLMpININaipUeGGK+dO7QHZoygbiFnDG ZCYObNKXjM6hqvRrHHhEuX3DNG0pVVK0RL3oX4n+N0Nfb/tzKKlSsZnjMsF86KTMTf3mZbrKaiok 379ZRw36IEHft8+wmrUiRlgphh/qpoP2BTe4cNoltYbtkJrWHLZ7SmV+7S5P1Lx0cRlf38Ic+4oa +EutBBHCETLewB5yfl88hw4l/wBNJ5Q1LS7eZlWrxR4CxQCUfdpVLzyMNHEZUb+AOTLKC/bunSje jEob5YuALR9qlksPOX1UchUnubm0y2sN2iE1rDlswfo8tp27RCa1ly2YP0eX06LRCb1l22YVdqqP nCqiO3mVF8U+8V2XQUY/uG7RCb1l22YVjuq/GAH0dvPGKyRzokYqNXhKay1bITesu2zC8d1XBxBX R288ewlNZatkJzWnbZheMrq+DiCuhylsTaqmZkFc2FXaVYz2EprTVshOa07bUHMZXV8HEQV0OUrp IeVBRirLRU57BnKh0g2Xyq1yw7uxNpcaxbwrtXrhrV7pEDVu7CT1pq2kTmtO21BzGV1fBxECUvsz oMRK8KyrwU4n3LxYgc2v3owLLcNCvfwHuGKkSURboUp2FYlYLrmPkFdFJHfLdHOSslDNNlVZ9p7G T1pq2kTJk9NIVnl1izKFlXrHWgefRRWjDm3g5mnpg6SvsoL/AM6h2jvdp8Udo73afFC678ySqLzC DwF/9BcQ8xNfx2/qh8pMTub1duHtmuIfOTE7m9Xbh7JqA8xNfx2/qgnNuvmmJ32klh0x8Y7R3u0+ KO0d7tPihXzE17x/+uj6kLzTz5lWwspLBp1DtHe7T4o7R3u0+KHK78ySo4GEHg1kuIeYmv46Pqh5 ia/jo+qHmJr+Oj6oeYmv46Pqh5ia/jo+qHmJr+O39UPMTX8dH1QljN6aWrPIqlmUIKvWKrE8+uit CPNvD//aAAgBAQEGPwKvNNV6qyrMrVp+TYYk5+alGG2JSadl2QGZd1tvNs2xEwio6Tj3muD+c1H1 nEoJe77oYCmnCoM1+qtBRziBOSbEcKL173gJViBdhctZBWo9q0D55ojDT1MAC5rh0aONW6mo/KpU 0VHCvNrwumWmUglss3DV20KI+g4hM2EwVw6xgg3td4IMCP6krOgjWP8AOY99ru+JKz67j33u74kr PrmPfa7viSs+uY99ru+JKz65h1b92XK+sTS0hT1dqjiobNowzLmiYace81wfzmo+sY95bg/nNR9Z xNpTet2pSmZfCUpuOsBKUh1QAAE5AADHvtd3xJWfXce+13fElZ9dxNmYu25nyl1sJL1eqjpSMp0D PNGGPea4P5zUfWce81wfzmo+s4nUN3ndjaEvqCUIuKrpSkaNCUpnAAMe+13fElZ9cx77Xd8SVn13 DcsL4u9KTFbq/wCpKzxGk9sf85rOodU4t+WXcFbnWJiq0+SfbqVUnqkh1mbmmpd7OicfeSVltwwM OKdIhi5ucFZ5RmdyUTvhhZPWU5o73D/CZtX4mmt2c9KmPKqwGZZouL34aAkfWWo6EjES/LBf1IuH /myY2cy0UR7VWtC+5UNB7O476WvyTO7O+lTHlVbkWZd50cLbS1j50g4m9s041mdRDaIUgmCDGAUB qjuz3j1fk3Z1e+lppI6y1KJ7zFs84aNyjLYu5h1zzdxi56+ydr2qtnVZtGZK+1gYb+CQ+H1bzbHH JPddon58OTLugr7VI1IQO1QOsMO+lL8k1uznpT/lVYbcA8JM+FcVvw07NPWSn8Z3H2ssXAkuM8Id QIph3Wr5cRTKTJHCGXP+nEzJLih1Lm3CVDKopKUoVoOnilI+fcW64oJQ2kqUTvAYee1bV1xz9dRV +XClPiLEuEqUn/yLVHIg/m6CTgJQkJSnQEpAAA6gGgdBO+PV+Tdnu5l+y7i2OcNF5SlsXtzuuTlm c3XfSleTa3Zv0l/yisSfo6Ox0BcZ8HONAql306FhQ+gTvoc1EHRjK6wy4ofT4yPnAiOxjI6oIajH ZN6Ek/nRJUqGMzUs84n6yW1ZfkMIHE1tmnGszjcNokpJypVGEev0M545W7O9yx2XcWvziovKUti8 nph7Ily67iWhDYirKqrzhSSo6BEdfBMs+SofQeA436aYQ+bCm3ElK0GCknWDh30lXk292a9Ie8or Ep4hHY6F0hDaE7ReUrcGkZjAjLmOrG0ndmpCNKW0nMFq3s2gcUfj6Ob8cfybs53LPZcxa/OKicpS 2Lp5x1vlOZ3GnBrca43VKDAH5sOekK7xvdmfHu+UViV8SjsdNmvGndmu5Z7LmLW5x0TlOWxdXOSu cpzW4x3Cu+wvx6u8RuqXsGs6jFSsgJJ4dPTpnxh3ZnrNdleLV5yUPlOVxdfOSu8qTW4z3CuyML8c e9R+Av8AjDuv9Zv9vFqc5aFypK4uznLXeVJrca7lXZwrxh71PRxhojCO9Hgjw9BGBgIAneiYwHXM Oie7s4CUiJOoDGlSE9SJPYGHM5TxssMsd6PUHDi0+ctC5UlcXbzmr3Kk1uIKNMARrhgpVoJVH8Q/ 4dFKXY5LoFFnptclLv7ZouKdbU+2SWAraJbLkq4mPCnqiMivIjMK+tYVlGYL9ozbWcGEc2z4seDR hV2CXSaKmd8xU/tm9oHYhOcsxz7LaqCI/W3Jy7G5dBosjNok5h8vtBwOuLYbBSwVbRbYdmm0xA1q 6hhfCyhBV7c7YpBV4NNuFvTr4hWYcEcVS4pSXQul0daUTrpfaS4lSshVs2VK2jgbS6kq6h6FzusK c3+1HW1n5920uc1B5UlcXdznr3Ks10i07glWGxXKhWHJecmhMuLceZHtnatljallIZVLMjQkFPy6 bXRtEZ/b8ynJnTmzCpXA4U5YxiG1g9Y4kv8AfVcqzeJtBcRnVcCWwjMMxX7RlXsgGvNshm62J24y w2qvN11Esma84c2jaDMSzfmoYDgagZZRXpSVaY4uhG0bz+35ZGTOnPmNSt9wJyxjmLaSrrCOL5/3 1Xk7Zx/+hhTjaVCa1KWkHw0vINs6Cf8AuuAhPCcX5V6kwhdTpTSDTpgzDja5ZewU4yEtpcS2rziY GXjJObUOgXoOvgxA6OMfybtpc56DyrK4u/nPX+VZvpMEpKjAmCQToSIqOjeAw1ZZTJ+yWZ4z6XAy vz4rK1u7FT222Ww2zhV+7zx+lDRuFC0qQoa0rBSodcHSMKypUrKkrVlBOVI1qVDUkR14qtoMJkzS qxNJnJlbjK1TiHR5oFBh0PJbSh0STccyFatEMDMlScwCkxBEUnUoR1pPSbQ5z0DlWUxd/Oi4OVpv pNvUO26HIvzE9LLdnKjNocCJpcpsUPOOLYLTs1NPOPE6VwZTlAECAKxWHGUS66nTqvOrYbJU20t+ cknFIQTAlIJxc6q29JSs+4/Nook1UMiWGn/aD3nCG3HVJbbmnUlGXSlRAUkHTpthu53KI9JTU2qn 0yrUZp9hs+fOyudE41NPuFtbaU50acpEeMd6jWta1vyGwVTm555+b2sHkmYeloFTCmXHp1RllKcc WVdunRi+r9qtNTOOUbb1STpoQl9DTkyKjUXyy24nK7MoSwG2SRxSY64Qrdr3Lbsm2yinuzspNS2Z 1UqgvMyvFdfSss1BBmEqQ4jKFZDxYYmZUrDhlph6XLie1XsXFN50/mqy9ItDnRb/ACtKYu8gw/8A qK/yrN9Jk6LfNqS1z+zQhMpOLEqtSktp2bZel5phSUTCWhlLqFeEGsayatdbFD/9GfRUGpakS7zM qmTanJhl5ttCkS5ayMJZhBKAMV6bue1/b8vVXtvKNbZCXJBZmJl5YSshBO0S8AYEdrijUikUkUGi UIhUlLpf2jxcbaDEuqLaW0MJlmRBCRmOknNiSYvmy5O4Z+npg1PZZNxLpgApxTE3Lr83W7lG0CVF CzpyjQMVasU+QaXS6zMPrm6Kpeyb83VNOvyyWXW28rT0kl5SEHIUZVHi8E/LWRZ8rblQqkfOqgkS jezWQobZDMnLt+cPt7RWzK1BKDpynViJ0k6ST0iz+dNv8rSmLt5z17lWawjrH8Hs7nVb3K0pi7ec 1e5UmsN9Y9kfg9m867e5Xk8XZzlrvKk1hnuVdkbudtEUnUcyRq0b5wlbhTxjlgDEgwjwQ6egxWCU pJgRwdUHCYElCxoJ4RrG7ZrhCYC6beUoZtKQKtKExj1MXXzkrvKk1hjuF9kbrP6flFYa8d+wrp7f cJ70Y2a9G+lQ1pPDjiltY4c2X5wcBx9QUpOlKE9qDwqJ14tTnLQuVJXF1c5K5ynNYl+4X3w3WP0/ KKwz4/8AYX09rxaO9HQWrzkofKcri6ecdb5TmcSvi3O+Tuy/8Tyq8M+kf4a+hQ/tUNpc0pBCirLv HeGnDHhS7tQuPFywKMurSdBzdJZ8U33o6C1ucdE5TlsXTzirfKUziU8W53yd2W/i+Wcwx6T/AIbm 6pyWZ2iUKyk5kJ40IwGZQjoOAudUlloaVISrM4ocERxEDqxwGfOmhk4oCApaUhOiGZCVJ0YRMyik v+bqKjszm8GocfVvpgD1uhbmGg3kcjli5BUASmJENURgNTAAKk5klJilQ6h0ajuIaRpU4tKEjqqM BhKfqpCfmEOgtfnFROUpbF0c4q1ylM4k/FO98ndlf4vlnMONtiLrZDzQ+spEYp/SST8uCFAgjQQd BBGsEcOAlAKlKMEpSIkk6gBvnDTK/wB6YuO9Ra/o/oiA+TCJBtRSjIHH4fTzE5UH80AR3EOpUdmS A839Fbf0ojhA1Y2oQpor40WFZEmOmOQhSRHqYabYU4UuNZ/CEEghRTrAHBuyfi1eUXjZuxSpOlt1 PbIJ19dJ3xiCHZdaPrFS0H5U5Fdk4D7y9vMDtICDbcdBKY6VK6vQ2vzionKUtivKFTuCWc9qz/nT SKHITrYnvOXfPdjMOXDT1qZMzmyRaEE8OJTb3BdLZ2bmXY2fSXweMnWV3zL5fx495bv+B6N/cLHv Ld/wPRv7hYltlXblWjwsFOWpS2lnwy4xQm83gNP5xx9tXD8MU373Y/1CtVrbQ05LYkNv1M2wu7P+ tj/Tq1WdtDftiQ2/Vht7u2nzY+2rh+GKb97sP7a4rsQvKzxW7MpDqP3SYQWq/GSf1ce8t3/A9G/u Fj3lu/4Ho39wsMQrdxEbFuBNr00HtBrH9YGBxLbe4LpbOwMAzZ1JfBG0VrK76l4H5Dj3lu/4Ho39 wse8t3/A9G/uFiU2dcuRaMisqnLUpjaz4RetCbydCf1jj7auH4Ypv3ux9tXD8MU373Y+2rh+GKb9 7sfbVw/DFN+92Ptq4fhim/e7H21cPwxTfvdj7auH4Ypv3uxQVGp3BMue1ZHzVpdDkJJsz3nLXmW2 mG7hqC0siZy54NGKeDH/2gAIAQEDAT8h3AIZonoDRFV4QikgBgAQoO8NYN6lel4SjIOijGKQAaGd wPlViyWzXrEfoYWZ8LBjIFRSGlH03Jt26LKAqJiCKmtM8YdQ3zcEF6AoDAcblxvOIIOq8L24xohZ zF8KeAMHG7cCEgCNGkxWToUTrpVHjvSBq7QcZ4QnGXZAvdUANWBXqlH4viEDCgqOhFYHzgtasA/d ZiH9lRsmo+yQ+otWhzVvUdTR1OCr0qAsBFtQCtbCGXA9PrLBEXEcm7cVj8zH9TwlkVdTYx5R1OqJ 9ygJ3pCwIwd1imhQIU2ruprPVtjrjyCKlIrxMkiz4vc4Oh1ItoXa5vxFei1TMa5gg9kdgIxa44Cg iewO3d7HVmGNA9sZ7R0ZmGIDNfdFV1hXOBDtAQB6AbXkqKlcTuoPEEdPi2IVQfoXu9j0jrxcbUMt JooNqVOrrdoEA+DTNFoei2jtLX7oiuUVCd2pyqQIoVzp6dF89g9JME1LTkHzkul1UCLwpUeANu9I 4BJOB0ecxcQuZ9QPpXopbgR0Djq6hDBZ9vW1w69dXiAAAAFAYANAOx6vi35a4j3j0KNjsCKqV6ij zcNiLiy7pZQPb+Wf/m/J+E4nvfoBdBvM/RFR4jhLYmKrmwaVcwAAUBgDAHQAx/L/APi05qOJ7r6Z VkiLOl/4W/8A/NryY4/v/wCbgQKeBn2T8SKj65/vUrrC4AXoUH0e7MyoWgpnQB13p9XxacmIvHGB ay1N9yDw2H2xhRjsXfW6PQDkORRaCmpE1qGiI1EcU6mL9R5Cwy2sQZDO/QsKSzndLk0PzPFAZyEr tGfSG7aVnhME7x5hMIjo2LGFqS2Z0zV/edasF+7RCsCMg7Foh6PsfuoyjNs7AKNz9fyaGivzDOkg s10pjFtuGkcpCFoCljNa3RJm4xWbSrqLOF6a1vSM4JtKLAX5S16Cv1tYE0mGt2gmQiVjwJHngEe1 WhaTGwnvgGs5n0Low12wnWFrGyU4xX9PRqtP8JX+Kiy0oxoFp2vQglGaJHxMC0MBwVgbhjRsBmBu dzTFcFI3BawXDHBklDQWKS10rB54K34IwMJh/wDH8JWx/vp1YtZVxTajInd7GChqerzHcT8hEAoH UxNYwwC9E9bFCbp0muLrvxn3MrhMZdoHSRWRYpnlwBIEkNWTOjVS2pko6lmbbHh/hbbGdAp3JKAo 2Xj+D/SuHx3XLYl6vDgnINRS9FzbFVCp3cs4JHffrh6ZsOukIPjIrFgCO4aVZqQge4IJuPmkp/x0 MOsggEXf1tRAoeoYVKKFBVVtVcqv8X/XVfdvyE3/APo//wD/AKaH7/8A+jP/AP8A/Uykz3zjmFup Es2tgGhJ1mlKwC8NB0/n/wD+5KIylCtUsyg3Zo2NToA1Y+/HrEZmiOAFOxZbCPf+J9g7w5LuP/A/ /wC2JrFfQj0dzudSUu54KVeDj2WXfYWSHQIa9qrgoWxL3/jubU+c8P8A0X/+WdWHYDFiY+zel+mf XN1Ra6GzOkHAixT2qP6z/wCL+I+OlYNm1ALfhxljgnTQ1FgXWlxDFhEDKr0dbHxMeiC1lKoAVrAa yo70es2oNQPp1gO8CzElBJ1uajmvtRwZBSa8JuUgZsn3MEfIVsX6ejZP03T2cbebxkEkAfJxslwj o6gpCkD0gHaMF1BWow7apZnDXDCnEjNXVFAcdxGjZ24M5oey2horrXR95r08HuY06CWyDhElWDTs 4gt4Aex0wRqwcVfJXRzL+84NDvjvaABQJZoqDKjVqo6dfUpG4o1a4lanwmgvU1rqsIZlih0AtxdO gkHs8E73B8cHtx7aJ9O0ig1RWj14XWujg9Ssrj4678a4U99eLp11QRPmFEUNS2u8fR/WiIou6G5x dOgE7UGajqvt/APXr169evTlG/HErU+E2F6j/9oACAECAwE/Ib5AQ4eAXVwaBgxwlhSimQzwWFBY XqYcGDDgyM9fjpYu47nHBgzBvjaWLvK9BgwZxwSQosvADqZLpMOOLvQn5eFzW3iKibEUzw/LLlzX 34AukCDfHU3463g7rPWMnLFp+bhc1N4a82XBgngY68pcui45bhrOnC5cuavHrj9PQauXNSaUuXLm RjXgbJLMuXcvhcua3Hqj4LM3hw0S5cdZoly5cuXuGeZcuXLly/SFFnJr4ly46w0ly5cuXLly5cuX Ljr6WZwa+Ny+Fy5cuXLly5cuXLl+lwZQa5lMJcuXLly5cuXLly5cuXLhp6Cgzl1zRNUuXLly5cpd dZcuXLLrrLly5cuaOIDHLnHrgtYCxLly5cuJzpFTVNtdLpK871XbdH2sr5zvEzbbDTVb6XWdpcRn aKmqLa6XSe21hMX+zL5ouILAs0111dC6aly5cuacWYuXHHlHLly5cuXLjdq1JQ6W6vPdz7THb/Qf yVwiXRaX9qPzjeHKrvApyZVfQa10mO3qPZ/ON4ud3gYDX6q/BrGKDsB1U5q+phxrLly5Q2kLT2ly 4o45xcuXLly5cuIGVESdi7OkLqruita8XmXBLBhLVrOl+o5HcVdl9E83A6OkuXLly5cuXHPHILly 5cuXLlyluWl1KC7ADtlat6soBl1aGEgaa1K1YZRm9TRTEECxyLjRQLvR66YOuYZyUxh1WGIAGjmY AT0KlO00yvu00u2jEcBodBriirqzMxdVTW5cuXLly5cuOYMhSxmQW7ly5cuXLlzxMeNctK0vqMdH tmFDA2BF6s33mK9irGIMeK86xetN1RS263dtX6msgPFXi1mullh1dY2gB1W6FhclBc3YZncTUr8W mhoui3uTwS5cuXLly4uABb6EuXLly5cuXLly5cuXLly5cuXLlx8IKX02XLly5cuXLly5cuXLly5c uXLly4+EFr6bLlys/wBIfqyy5cuXLly5cuXLly5cEuDUqdTJfBsVV23A9Y7bLlz8n8s5Twy5cuXL ly5cuXLly5c+gn2Z7QjqEqFFOnH37+uy5c/P/LOV8MuXLly5cuXLly5cuXPrPV79/UZcufm/lnJ+ GXLly4VoDA84ly5cuXLly59Z6nar7jhc/L/LOX8MuXH14PiOsHY6/wCR7Ndsn1DbFvTt1ly5cuB/ cE6hElxh1DUoOw9StX95Llz8n8sZdNk9o2NOsLVZQ/lF3YUPVL/pwPb07kVxU7PqXc2tmXLn0P2z R0mj2gaN9x+pfrsdj1C2dkCow4AmG87e2kXRMOifnjYcY71lqfV6X/PAVyUDx+UscgO9uCptDoaN 071/HHHjwamkzq89jdfPGw4Q2anU+va/5/gFKhSoUKFEzIERlyBcujT30n//2gAIAQMDAT8h6of7 e5hRbVrLa8IAAdRjMdLcahtywDWn087RUrXsZ8FYAO2Dx5TbHbR+4CSXpAABAAU6laMvUoOeOBI1 Guq6tMvEAAJBV2cya0eMSIFxtq67rxAAGgdI1FoeHV8EN3r1Tix1mCzI3mGSVBJ1H6/1Lo9AcBUS u6/qSgv73wGqwFj7/wClyi8GpoNzk4C9hwVTn3ZwapzwH5ZhgrLD18cFT6ni/fm+A/thkgvJTxZp NevS4WT1sNe2r8Tyfj3XV56YhvYwrgXL9ETb0L8t1+g4LTU/ctfjX2iNJyusbMzOZLFT5t+OAsre g8z/AIxhUDpTIPYau+QPnpGiK6rl9Ax2cuXMpAR5zC5cF7XiC5Hogz+iFFk1Lonfw6hMyy9dMfB/ 7G6XcH26E8cLRfxKRK1a9U9IfRS5cz3ZGfDWX1wLCaNX6iKk7+n2f7hpQFjM9txBc70Q3vfSDwpN 0sNeamIHWRVHjy/W8RW3X1AVbCXLme56KGIye2P3Jlt+ILmuiC18v5QAFU18HzfoiOzfBvxBex/P EKDHKC2JeX+UAB0HGfNfp6LuLfEvxOQd3/wgAA64s+R/T0RZG+QIeR6vrAvV9PQLVfT1AdBFqaEa oBDSHVr5r0AJqwgWw5p+pAFlmguiPILK+55LY9KN0613vWNsQZEU0C70vqy1d/GeAFlOgu1Hkllf nw0hg7tdivxbXa2AqWCoPTTU0Iu/pBUfiMD5fyBrGgLLJWS6ky6Hix11yqo6S86/4R2YcHnEDhel X1xvjO2YkGDnWFOtWt0X1udFCVebv/Au2YMPn+JNA8nYfJwd3SBJTZgvKhdOhkb0PQChTSUvO38p OxoBhArFQa4tla5XWS/wMcFKU8paUWi/aGNmZVXvXVOS14qOgVZf/jAI2xAE+rTtOoq0XbZoaApA IG6jQV0QMkdamAFwLFZFLBzlEqooZXClJqdKvLpiqmxzsDlKHUxC0Yj0HAHUbHXWqHRKzlaarUKI VdOiXwivbvTV/wAIixrDNAWfwAMNn320wX0DCHyNVwqQAUsAqlUqgJiSAWWrHPnVVaQ/MbjYdCgD QL73AEZjPfm1Z7FT0NI1wnPRkBBi1BwpdmlkArT3AqLcmlmmVeXX+IARjvyH/pAAAALNfkz/ANIA AAXxD8wcTEsPDHukLz/OAAUIRbpLhAJxEssAxh4cX8G4jotvwnNu5/OAAfNvzNbXc7ksnsl/iWoo 9V19u3GLO/iH4eIqHlhOS9z+cAA+R/n1A7I+TujxHQcsJl6cBoYOogX2i5Rcdb1vbt/CAcldfUBO G5i6PEVF6FYKiUvRcewx0KNFKHs5dqgbf1W0LfhRi9nR0YafOTevSCT9fVjS44do0jhODFEpfaWh ql+fSIZT7PnsPEVDEt1DtD19mva5RJajYgEtXpNMn8Dr7tvvC4v2Gtd3TxXARRh5uh/viXDgGNp7 4flYVRpdGKvu8RUfj+Ew51Rp/ROjLh2hQ/dn4JlWtf2djx9+kFPsUgwBqKq9QKoZ1lJTm7S6Vd9c Xjxq69A28u/Dg8+4/wCPijkW/MeDwj1SraugfE8eZXZ9i+P4nWg3tboWfJxeHGNTVg2jRUfh/A+f Pnz54+zSDCGgqnSFdjGs/9oADAMBAAIRAxEAABCmRAgIekIC1gl6QyeBOyJ/SBsZs6hQRuK8WiQD hvCTCLpaCSRs+fyLAEL/ALEOnbr2yj822W2UhTT6bA/wWAyEiX77rEkkkktsoiCjsfulm8l9ukJ5 uetZ7Zp15N8juJfPtvQZB3PSJPbcZbCcuDJZZLPv/vr0beFvttuxfJJfHgiPJJqKvJMttptMttvm ACgCABDDADbieSnCSTCSTASL7oRyyeyT22wH7dAtQAoAAABMmNmvy2XiXS3VEHHQzANqQaDFdNFE gtZ8U2jZL9dDKaw5RwW1/tt3/9oACAEBAwE/ECHLOd5XPX5sjmLeFTfOhR1yCFCKhxKnwL6FcBRH mnJgUL0mqjqxcj2fCXWUJQWQYLex2XYXDRHrwPdSPxczpPa5v7wVcYPwziA0U6rxm2jXDfxDTwAA BgntXK8B4T1j4dbcKUFJzJfBqdqRS6EQvACdLzc74WrW7DFDVQU9QxcCmFe4U88AywBUN6H8S36s GK2xMwx0+rgfB2RBV6ltbzn8TdX/ADHWGKEAYMYdKhQoqwESTTorWi1BtpGobSmeE6edLCCmmww9 kUq0oslOdZX9M3PrpOf9Tf3mS+//AG7yudsS6gIsgUCIDhYN0D7AWDwFCs10m/rzpK/qZt3+zrSt cc57xH4jSMlIYLL1L+DCQ7j9X3A1kyUrdFCxeqkLCHtkzzErOhIaC4hTWBRNAHoAXoCsq/dvontx 1m/ndl7d1+c00DAVS211RNAnrN8q+aZYKlLQ7po1suBvoUYp8kPmoLCdKThLA9mb+fvMH41QSvnU CtRAMsvJq81eb6x0cdo9W7dFxqwkDYKwmC0y+xXRoQATfOnn91U3/cxVdpyVOf7nPnzNofo/tlo9 x+Z3tX+vu9Zs/PB0Atfr08VHym6Xr3j5m05YTdX9afrg3c/cGgBqs6BIDdBfIIfBd7X8W4uZqPBB 5GL+bdaZF9kDmE84PZ1VXkwfRNZAZLhQsuHWH9py056zffnabvHO8sFawdHvOXOsdrS/pxy8L1+3 9MfLcH41xnSwOUbJfCIBAUOVSi1OqGZWN54vT0HuIoKRRJQu6/X0m774L27/AGe7Om1FG7p3Zunl +eAVjTKBICE/AgnDyDODT5Z3gEyEgzjwIAAAAAGAlM5m74/qfKYXnn+rm6YU1WGxxzpPI/fLmPIx +HO83qeJUheg/T+p/wBc9bhh7EFeZUrXsypd1+f659tJu51ljrV+zlN42m6HTFa+puqvfnE3HzN1 n+bTdz2n/XO83dObm7Pe5vef8m7/AJpmcufabts+Zu5/qX/uv9Zt7Svbk/Ud3J+B/bLCvKPtXUpO 9A+P0Tn8zO1ocfJyfX+pu5+po/2McPfxLNpGlW5YaYAAAdAAD4nde/PtOXtmZ9Zu0mnnzKHWd18/ jrN03bTfpz1xOXJPZ8zzw/ykz6dOdpt3ma093hb+GIleodtQlA9i9qZvzpMq00V/unS609vxzd/2 bvbWGes68/fWZ9Z+0386/ucz3+5v8TfPbz1nPOO03zfzqzfnPv2/Mz6/fmeeE+v6TZ7c9YeHPLPB 0fhv3LBvUPkZQb0Dn6Tf9wW+w++BpVv40pv5x5m+b5v/AM+Jvrab/uImqAoMiUsEpdgj2nPbhD35 P3BTIFEORlywthjRrfz2m/5Z4vDv3vnrPLCfUJAnJF2AvAauAPECOn3qDXaFE35ajVmWrRvLSvUI 0Beh/H9U3/v4lsnaUWAuEaYXgNRUW1bFdZur3++H/Oeek3zfW+8EU4oIML+y2kATXmCU4LVhG8tM IBJKZjv7RgTPw6/80NE608FSK1b/AClCl2Z6ztG6upnrDhhBhHJvm/l1Cc/M58+Ji3V/gh2Gzgu4 jKURjfz/AJN/PJLgvUt8UqC9B+ufh7Tntib+fab5v57Tf/X+Tf8At5zH7w73FabpQLvGGlFw0oEL RMtNHg0Qe655aL4H5VdUEO5MzKvonAOk6SqWVM3TBNji5Lux533ieULbAWiFmtYJm3aTh6UAIWg3 L9+am/npN8EPuEJKUiCMSpARUo7pDqt5/wBzf94+pcN6n8xrHY9exbTnz4nTrDzL9/7ud63+f1oz fX+e/ab6Pj9vaeb2+/zN/PLHB6qMAZZ0QK4IC8EpREsgzZYXv+Y4qwKIZkSAhhHrB0c5Gw1IxQYW 5IU6bIqO4Iplp9onERheVRhnfcPv/wBZvxL8/mb/ADf+5ubpu3Ju69WXBev3wpO9C+Bm+b5z50mv X7m+fXr4m/t9/wDZv4aYGjif2K88BeGv678SZw1tyslpnxpMxowiTPuOWY9tR7BJpgwJA6ZyKQsM uHpsH6UAdnByonMd5u2apgBJJW7shA2U2G+2ibudpz56zfN034m+eTz2xLDvUvkIbQlWZG5MiXcv XkGxpRkd5vzz1xPnvOvPJ7azfj8eKmnXtz7Tn7z685h4Y6Oe7OVxQuZf+XeT53EIFDRqW3hyD1bE mbiaNxo11qjsjFZUK24EQk1fHIBEes35+GDtPR4bpgYisxE00HMnsAD5WUFq5WeLfPib+dZv57+0 31++bm+v1N/3N+vP5lh3qXyEuWtV+frjpaWfjp7cb23z31m+b+f8nbfPb6m+u03895v08/meLN/3 z1m/n7ni9pv05qb+dZ0znzvN/wB/8mfXnv3n1w9pvJv/AMlh3qfyfvLlrWU6Hd/Hyazfz8zf9zn0 m/8AE3k38/qdt8/qV7/vm5v+5v8Aub+m039Cb+/4/ub6/E38/ib/AOpv+Obn/ef6udt/1N/3PN9p vlg3qOt6yuEa/Y/bzHS7jxj++b+fedOa2h+Rti6otWLqrGpVqabQR2BXU1N/3Px5Pib5vm9/E3f1 w75vm/n9zn2m/npN87bl4OCxr4IV0UQleF4uQKAGDHhOuCXGVQAyq/cccpqVaLM2IsqWPu3zDFdx 8Q3c5m/nrOZWgg8cPGt02n/PLgm/n6m6b+fib5v5eDn+Ju5/c6c89Jv/AMm+b5vlz938amIpggYJ yANDDWATUaRUqe4AFV3NzEsYK2bYa8gFjKmJQlaJp2WXKtV3VPiYnSz06D+5u+57Jja7/Ef1D0Sw fmubvaX7/f3N03c6zdz8TfN03zdzn8Toz/c3fc3S2l+0/wAYlrnVMeZ7JTt153my5Q3b8xcvetej 3eY7S/p3u83VXNzdjnbtOqdlvYfmWXuPTv8A3Uy69+0bGs5fNs3dvvH7jawQOlWkU9SGy6lHccIZ ZQIYC2bp2Xz2n+vzMOdpu7nTtN34+n2m7+t7mrUfPPmb+dIKnRT/AIVPAqPhNn+V0lb1ovx4SXpW r6e99x1e/wBcd3P6m6eUjLYJR2LHO/N+J+3PfEyCDD0k2JGQA7yzlI/VLBGgi6DkqiB1Y1k5ppqp Xwf5o4MWrpAmJum7rw7ud5U3etPFFQqSM1DhCauZLs4gDTVIvujyxsKDFHSn2mQsd3EvXUnRpOrH Pz14a+yfn8y1aW3+YYTS1rb+6bqnPSYc1Hp2+eU0vILUkpWadKtiBuNR+Eo0igRMwjq5NRWpAAKs OwB0BSjZWEUWw1UY8Go2OC9e7dB5w80pJH6kgr2ZWELcKGECpoZbDbtzHVPrv0fTGlI3mqDf/b3+ 5zZj7VPg/eN+TqsBhPAqFCIAxHZ3VIFdN5GjfDOieqQMo0WOfLtNk2/ibOSVPWjfsh8HDNJw8rM6 EkcOVt4awADqs0e97vZ+05l6kHnjOGW0JEKoBaWnMP8AW50aDsF/g1Wk5XRsg2bXE/2I0aKuDisG 9CKINLfua7sfU/DBRKCBM88WAastrAR9XhJz7ZUVnsOZe8afI72hHYrSci4aAFAbLo5l6ZnmXvH+ Z2YOZfeTnH6jafNM/wCRTp0k2A7vk4eFGNGX/9oACAECAwE/ELktmPs0+/JhAAOEIuuh0KdG1r1P EgYg8JIYopqab/SQIGSBfLm2r9DjhChmEW+TjggbWrZq3545QoIiL6cbBgjxT1elLsEjt8U2vqEC kiqZXHYda/cYLloS+nB9p+ZRm2YcofeVI1+J4jy5aHB9J9l+eGXK7EDilprLl9ZnxQLOtEVxK4Wg cTbu3sRn6n0R0x5US+D7j8wyTuPALrXpLi/oZSVjVGE2NCOzubnYLBAo0Jq4mW9w6R07D9+iTi1H TrvxB8jFTeJlxDkwOj1/5ACkL+JjWvAgKwWAdC+C+DCarrfHB9n7mhT7FXDFRWWYiNOsVM88P0hz rvFjtwd3Wd3BauhcqtWuD7ekMlvxxv24BpR2lzJvxEBRxMlHQ9INo8R9OJ4TNbypTMbj4+mq1l1j iWazun29A8plPpw4cTRHMqVLrga4LgJUYrcGUf4wAPC1TIPSfmeYqr0StSVreJCeJqnb6U6iYaeP ROsFjTrirfaz5ODs9BpXaNBbpEHFsramKk4PgI1HVwa5leg24ExKAwKgZYKB0wtBBi3Ai2nQmldD TVrFgFHnMmiuia9jm8S0NMsDIqElEILpllEANdAWshhpgHcAOhGRCAyChSWILOpmhFw9Az2IoBv6 A5xMPDifeYcZt+sIvEzaplmVFCiuza6aqg3VVYHuJqMWXwiULommjJ32uW2awfNZmBYXXBhGBS1u q8+waoU3pVi3cGrMx4RaX64Kdah1B7BFoYBEAACtqQs0HU9BHUGuqRGQQGnvM5fjZ0/b143h6J4S +BYGUMrQe7p3gDaB6IUPTbJ1t4QDUNEbH3JU0FqLQtdAvV8axig0hGYrJIoiyUASyuNqaRpOj2fH Do4K8FOC0xXpMeGifSW9+IazSyTaSoUw2qAsCqaoAMUMWh0xLdR6ubwKFhQK4WCz16WwJEtgB6oY ouGZjLVEr7FJFhZNrA7LRZjgCcEVa2MC1yg5crAu2ACjbtSij5Lp4nZDg+HBZD1VOXqK2+SEmo6T 6cT7cGiUl0JqdAqgVXkKH0KIz9UKNwIs7Wt73NVFUIZjILNBNTJ1SwJFzQdJOlSigAZVQgXYwuwH rZuGNYqIrGZgpXCwa2Gluq71rUEbYbBYcYhggFAacNvfi/b0AsZfhvvycTu4PLg8Nf4yAPlPpxO6 XSYTt1yGT0Dw9QKcTTwHEeU7uIcAAJm65DJxB19uFRda6seutFCqNX2rp04CNX8gALFoF0mVPIwh Jtha1NTFHUffgu8QCa1F5A7dhkOhcMTXLtTiUU8QYL6IMPWB9uDT5n0h5joR/gdQarv/AGdfiUJ9 3dfIn9yyYrBoOtq612qt+FIxJVz2Ti5tE69WAaP4QAavIEqV8caRmSrkskOBk82Ha4QZTVwLbOwR Wuj0M9DtKEKi2KpK0y63O7gy9QDfKYJUqV8wRISN1zmSXwZvMq4mMXCHIzV0Wl+YCA8oRXizG61O 0XKwAqwBgLCY3hoFFsOR2dShToX6QBxXVdGhS69t/EAgFgRsTTDjI6n+cGaQQ3WiEJoB8ErMqVNF CEqVcpk4mTzFpah93Ue4oealkaBpHCPk8QlJRoDKvajvDzzv8J7FHtGZUaOt6LwBadbO0vtF+cg6 XUs7hkejKXzDKjebsIX4CKU9UC3aagcTPdwzsyh1X7HqdcdZ5wAqe5b6WFTl0FdxLyvlqjQ6ypUq VBCgty1bghApYFqFqWFeLN5NWk+zxk6xHQNQ8wE+XfGnCF9ZPyM0U+kYvA61pO9cNTnpdB01SV+F PfXhLzxeVjCs2qNS1fLvGi36D6tq0nxTvx06SK66UHLUCfKd63gtXe4C1PGVChJDlK3UkClIUqUt /9oACAEDAwE/EKLIGNoeSBq6FjgBIiRC1EwF6EekIuTUOrVgXCrbEJFqW6k7BB4ADoQ4QQn3C3Lq zosoaABgEStEsTzM+ksXvl2ORychUMoAuroO3ExcUTaADKLVXKqq54liyiFgOipF5DAunF48V+Qu VuUVfKrxLFirhHnnWdqnqWVmpk9ddbXQsCoEJxMkUKDHu2PxSNI6Qdrv+aOKwFq6b8uwXanZX4AN atFsy8jpDuPTuj4iGul2S6D5OtOVTS16ZM6OXcONugu+wMQiLgUs1akFpxxcT5reGJR2v9zn1LLR KxKDnkG6jC6GrxdFvRdDHXLN2DchmXsIKmHOXd0OgLYli4/UFGU9f2AgNHkl9h04MMedhcLfA+RD aJ0QYc0urAZDLMKK7uBR5JNVNH+vQy4lZt5zvXb3qdfwBoiv5BorqhuZ2hRdVW1d/QHT5LeJyp0m l51Acf7pFOBUU6/mV+gKLpbNY1U6qqixV0zVgjSB2Smu128sevRV4I6gAF60WmFTEqIuoA3tZ7hF +wAAMC0ulpw59KOi5reOK/PU0tCtgt5AcDAIlr4CZglIcs35LNneg9h0hWyA0R6/5qOGG7xkqHtA vfLfpAeaMMQAi0Xd3Sxq+PAfXxV6Vmi0cEVIqbV1Xu+oFA5LeP7b+KallZDg5HL9iCUPFi7rBc4w 1nMPu35/5dEKn2H743tf4oqSPY/BeJ57Sz8SU3hgIA0KE06XoRU2K6rr/L0fsN/fE9h/HNDTbuCP Ed/yILfhx/Tw4/yf/qPYfvgY9r/BNTwbU4TxXf8AEywePrP+kudXWL7X39HsRGqC1gW6L7tNbPbj 7eP4mEbE1SuCeUuAA7Wj8hCscjQPAUt6Shpdz8Htg0EwvTxGBUgyJm167+p4Ctslo1LdLRq2AsMW mDSzDmrOr18GIqBa4O5ZbUmC7mOBbVYQkmjajYNcRFhjV6wvMzq8k7iFWxPkxFUTcgtgaYWiHo/w sYpTQt5Ww+Kfnj1PHsX+Cv5zQcNM+0CtBhFbgCqBwZDyruyg1odEeCDC5CKLdAXd1a606Mw4oB36 oBq0C3biCj5pwjIcq7tIKujoFlMw9G4KB6OXpPZEslR8fy3wITVm3ZleOZElNSK3iBMbvHpSda3E P6+r6NIC0CtBa46BlehDsHk2FZdecTbHBWxHqBE3HJLNeCoWhVrWgWZcRXwzgXIEkRCSm6WVllAW JY6Jeo99OP8Af1fqaBevoz6fT4exsLCo5MBbMg2bGVUyOUFxeZSAoVlUQeroBiyGwp1yUdAFavoi TbH8AS0VTL4uNiUGGYBXAowVCygyRaGbtphknUXy6EUVFw0tUeGrP4O9SzKB2Hgg+BKf4P8AR2gA yGxoBidGL4MVC9aiFqVBZxQQqWDciiQLQCWjY4oISRLBKWLDLi1TsCliJwHQKwBE5iqAMCTTKVpC 3ZUuRBQ6a1gJrQBEjVJFpsU5e/n+D/Q8aoJQtdh+Gbf/ABf/AP8AH0epJVRxxs/xP/n/AP8A/wCh Y9ASxb7fieO0pgUEqyzIJaQdLZwASwxldU1D+f8A/wCpigWsAoaJ9xaaIhdI5GlXua9OFAZ0lpgE 5CRSK0vVCVDBzfb8Lx/HUio9v51/v1B2/OgqsVSadh7dx6PcsasU9MHsrPuEI1WqQh1ALl1VutA1 lwwaim+1+jCwqj5fz+bVVyuXoFxd5tARc16AAG6nl6QBGs0AAuVuLpaw2ViXIGjSsdbGR2FN+P4Q BAua3oFhx6g9NEgVFR8+MDlox1xLcQUQvWmABClUOLwP2oF1aw30SWqytbQq3pmHGgQOZevFBBMK F+kDzqcixFBG1pLwF9YhJTi1VlluEbEUdxCEtEF2Ar9EbEPkhf36FiZVZQvZPRxNLIgL3Im0U+xE BhCIiI5ETCOokVg5AAGVVwAaseK6l74TwuE1CjmH7J25CCo7lo6hVrwUnRPQBkOtLQNHyBNDsBim KqrWwlVcVCFDIchdXeSuuvEgFtSQOaDJkzkUXVoiKNI2NI17GVu7EdpRrbpbBGLC6XaFox6QvgSj LV0LN+gKURZYlV3lRwAzBqrTs8ZMlUSxB6FXQUt0Nmatiio1nHvP2vylzrea6nF/E1cFGCkhDc9m KcGVlNGhwkyVMfMBwcwKyHRRZmjSC782XHQBhXVS8V14ydLq5UBeikqsuTFYt9YpUKVChAoRluyF k9LCkAb0/9k= --_004_E045AECD98228444A58C61C200AE1BD8221CA8E2xmbrcdx01ciscoc_-- From rute.sofia@ulusofona.pt Thu Oct 18 02:29:04 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 63A3421F8534 for ; Thu, 18 Oct 2012 02:29:04 -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 X3YnEBotmiD2 for ; Thu, 18 Oct 2012 02:29:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3E21F84B5 for ; Thu, 18 Oct 2012 02:29:01 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so3810208bkc.31 for ; Thu, 18 Oct 2012 02:29:00 -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=qMYgFwgoCUAyf3jdZLnST6Y8bY23U3jp3AnjnW4MiCo=; b=mVvfATA0vMOtSWxRw8gVAezn+fQ2AbSjF7TdDzhOfhjm+7Il0HCvCgB3NIcqUJbEFr sIIXSWanqebfnoZhFjYrIW7QkQ+o6RCAN+XezE7cCVcc951plApx2Kxqdkr510NNN3eF iNHE6bULz6DW3AS80culJfvpo9mdWve4Ej0dBzPTcxDF9zO8GX1VR8doBmJbXYnfLjJu orGLwpLBN6D8+Z+Gb7N5+QWne3O7tJPaoifSm6JRQj/6lS2Oiot40k0Nk8N+78Lr4AaV Lhb1TKQR9dbHpGITr/lHj/9QrYe1c0NtGDWFJyBBxe7nskV+pEcxdT3ZxpeCfUUNSWPa pqWg== Received: by 10.204.129.213 with SMTP id p21mr6034346bks.115.1350552540212; Thu, 18 Oct 2012 02:29:00 -0700 (PDT) Received: from linux-phf7.site (sitigate.ulusofona.pt. [193.137.75.158]) by mx.google.com with ESMTPS id z22sm14203943bkw.2.2012.10.18.02.28.58 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 02:28:58 -0700 (PDT) Message-ID: <507FCADB.50102@ulusofona.pt> Date: Thu, 18 Oct 2012 10:24:43 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <507ED5CF.7040507@ulusofona.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn6WUvE/JbVRxNGg6ZZ3XuppsluLRLOq4RzfXvgWXdkJs6fZPm/7fKlsTfI0LV03B1tU78W Cc: roll@ietf.org, Antonio Oliveira Junior Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 18 Oct 2012 09:29:04 -0000 Hello, I have been in ROLL for quite some time, and our intention was always to consider LLNs. We will make that clear in the abstract. Let me know if a new draft should be sent now until the 22nd, or if we can proceed as usual and add the improvements to the next version (up until 6 months). BR, Rute On 10/18/2012 08:52 AM, Abdussalam Baryun wrote: > Hi Rute, > > If you want in for LLN, please than just state that in the Abstract. > Your reply to me has strong abstract statements which I don't see in > your draft. I really prefered that the abstract to be clear in which > network it is for MANETs of LLNs. In IETF there is a different between > the two networks now, before 2009 there was no different. > > AB > > On 10/17/12, Rute Sofia wrote: >> Hello Abdussalam >> >> thanks for the input but we are not going to submit this draft to MANET, >> as the intention is to describe energy-aware metrics. The scenarios >> described relate to LLNs, and the intention is to test in the future the >> performance of the metrics with RPL. Currently, this was tested only >> with AODV and OLSR as we did not have RPL available for ns2. >> >> The metrics are agnostic to the protocols. So the draft does not intend >> to create an extension of AODV, nor of OLSR. >> >> Anyway, we appreciate any feedback and would very much like >> contributions from ROLL involved elements. >> >> BR >> Rute Sofia >> >> On 10/17/2012 03:09 PM, Abdussalam Baryun wrote: >>> *Hi Antonio,* >>> If this draft is for all wireless multihop routings, then I suggest it >>> to be posted also to MANET list, so you can get feedback also, >>> AB >>> >>> On Wed, Oct 17, 2012 at 1:24 PM, Antonio Oliveira Junior >>> > wrote: >>> >>> Dear All, >>> >>> We submitted a new Internet-draft "Energy-awareness metrics global >>> applicability guidelines". >>> >>> http://tools.ietf.org/html/draft-ajunior-energy-awareness-00 >>> >>> Abstract: This document describes a new set of energy-awareness >>> metrics which have been devised to be applicable to any multihop >>> routing protocol, including the Routing for Low Power and Lossy >>> Networks (RPL) protocol. >>> >>> We appreciate your comments, >>> >>> Sincerely, >>> >>> -- >>> Antonio C. Oliveira Junior, PhD Student Computer Science >>> MAP-i Doctoral Programme (www.map.edu.pt/i ) >>> Researcher at IAN/SITI (http://siti.ulusofona.pt/) >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> -- >> Rute Sofia, PhD (rute.sofia@ulusofona.pt) >> Scientific Director for Technology >> Research Unit in Informatics Systems and Technologies (SITI) >> Coordinator of the Internet Architecture and Networking Lab (IAN Lab) >> University Lusofona, Portugal >> rute.sofia@ulusofona.pt >> >> http://siti.ulusofona.pt >> Tel.: 217 515 500 Fax: 21 757 7006 >> ....................................................... >> >> -- Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for Technology Research Unit in Informatics Systems and Technologies (SITI) Coordinator of the Internet Architecture and Networking Lab (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: 217 515 500 Fax: 21 757 7006 ....................................................... From j.schoenwaelder@jacobs-university.de Thu Oct 18 05:39: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 2CA5D21F877B for ; Thu, 18 Oct 2012 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.223 X-Spam-Level: X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 nh1QW+AGw36I for ; Thu, 18 Oct 2012 05:38:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFDE21F8470 for ; Thu, 18 Oct 2012 05:38:48 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2807E20BFF; Thu, 18 Oct 2012 14:38:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ag_GrGmA4SOA; Thu, 18 Oct 2012 14:38:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5EA420933; Thu, 18 Oct 2012 14:38:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75BDA22532E4; Thu, 18 Oct 2012 14:38:44 +0200 (CEST) Date: Thu, 18 Oct 2012 14:38:43 +0200 From: Juergen Schoenwaelder To: roll@ietf.org Message-ID: <20121018123843.GA84726@elstar.local> Mail-Followup-To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Roll] RFC 6550 section 18.2.1.1 defaults X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:39:05 -0000 Hi, RFC 6550 section 18.2.1.1 says: A RPL implementation SHOULD allow configuring the preferred mode of operation listed above along with the required parameters (in the second mode: the number of DIS messages and related timer). We did not find any defaults for this in RFC 6550. The Contiki RPL implementation seems to use 60 seconds, we are not sure about the number of messages. Are there any default values that people agree on? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pthubert@cisco.com Thu Oct 18 09:43: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 AC58821F8746 for ; Thu, 18 Oct 2012 09:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 ov3RB1RfG1pK for ; Thu, 18 Oct 2012 09:43:22 -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 D796321F8744 for ; Thu, 18 Oct 2012 09:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38150; q=dns/txt; s=iport; t=1350578602; x=1351788202; h=from:to:subject:date:message-id:mime-version; bh=zOVMwfwRsf8P+BsaLKcwglkXBerJxEx4l0TztiKtID0=; b=jkB2OJxdLEaMVdPeTJcusHhb1anXrEDQd7L6AXy0LTvIxwYQ5QOK71/z JdlBc0g95CLEXMEAfluYaKivpEgOZJj0Qd+AP32mGal0pqyTyihbIy1c3 C1NX0wt++oobpghASMcdM5661BaABwA/QjCOb3NA7wedtpe1N7gCU6hM+ 8=; X-Files: image001.jpg : 20186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAH0xgFCtJXG8/2dsb2JhbABFgkq1JAGIXoEIgiIBBAUNARIIATsBHQQBJQEBAQIIFQkFEAEDCQIMFAsHAQQSAQYCBgwIh2ILmzaBK6A8BItuhUhgA5ANAVGGIYIoiwyBa4JvgWM0 X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="jpg'145?scan'145,208,217,145";a="133098091" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 18 Oct 2012 16:43:07 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9IGh7FV020974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 16:43:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 11:43:07 -0500 From: "Pascal Thubert (pthubert)" To: "roll@ietf.org" Thread-Topic: using the flow label instead of hop by hop Thread-Index: Ac2tT14B78zttzpFSgOnw7I7S2GAIw== Date: Thu, 18 Oct 2012 16:43:06 +0000 Deferred-Delivery: Thu, 18 Oct 2012 16:42:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--50.253700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [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: Thu, 18 Oct 2012 16:43:23 -0000 --_004_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_ Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_" --_000_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi When I started this draft, we had a series of chats with Brian Carpenter an= d apparently reached a gentleman agreement that it was doable within the RP= L domain to use the flow label and avoid the Hop by Hop option. I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 bas= ed on that discussion but did not get news from the group since then. This technique has a number of advantages, in particular -it saves extra bytes for the RPL option and the HbH header. -it also avoids the prescribed tunneling within the RPL domain for packets = from the outside. - it has an optimized compression with 6LoWPAN. Is there interest in the group to continue? If so I'd be glad to have some = discussion time at the next meeting. Cheers, Pascal Thubert IPv6 Engineering pthubert@cisco.com Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille 06410 Biot - Sophia Antipolis France Cisco.com [Description: Description: http://www.cisco.com/web/europe/images/email/sig= nature/vertical04.jpg] For corporate legal information go to: http://www.cisco.com/web/about/doing= _business/legal/cri/index.html This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. --_000_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

When I started this draft, we had a series of chats = with Brian Carpenter and apparently reached a gentleman agreement that it w= as doable within the RPL domain to use the flow label and avoid the Hop by = Hop option.

 

I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on th= at discussion but did not get news from the group since then.

 

This technique has a number of advantages, in partic= ular

-it saves extra bytes for the RPL option and the HbH= header.

-it also avoids the prescribed tunneling within the = RPL domain for packets from the outside.

- it has an optimized compression with 6LoWPAN.=

 

Is there interest in the group to continue? If so I&= #8217;d be glad to have some discussion time at the next meeting.

 

Cheers,

 

 


Pascal Thubert
IPv6 Engineering

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


Cisco Systems
Village d'Entreprises Green Side bat. T3
400, Avenue Roumanille
06410 Biot - Sophia Antipolis 
France

Cisco.com

3D"Description:<= /span>

For corporate legal information go to: http://www.cisco.com/web/about/doing_business= /legal/cri/index.html

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

 

 

--_000_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_-- --_004_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20186; creation-date="Thu, 18 Oct 2012 16:43:06 GMT"; modification-date="Thu, 18 Oct 2012 16:43:06 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAASjAAAKQYAADhnAABO2P/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IAEQgAtQDIAwERAAIR AQMRAf/EASsAAQACAwEBAQEAAAAAAAAAAAAHCAQFBgEDAgkBAQACAwEBAQEAAAAAAAAAAAAFBgME BwECCAkQAAEDBAACCAUEAgMBAAAAAAARBAUBAgMGITUQEhMUNBUlJiAxMhYHMCMzF0A2IiQnKBEA AQIEAgMGEQYMBAcBAAAAAQIDEQQFBgASITETEEFRIrV2IDBhcbEycrIjc7MUdNQVNpaBkUJSNdZA ocFigpLCM4OVFtfDNCV10aLSQ1MkJgcSAAAEAgMIDggFAwMFAAAAAAABAgMRBCESshAxQXHRE3N0 IDBRYYGxwSJykjOT0zRAkaEyIyTUBfDC0hSUQlOz8VIVYmPDRGQTAQACAQIFBAIDAQEAAAAAAAEA ESExcRDwQVFhIIGRobHBMNHh8UD/2gAMAwEAAhEDEQAAAZ7/AFp/PaOrDT4Q1On6P4lLEbvHua+J usUf2/8AL6Dw9T5ucmkrYpXpU2N7/qvjfepu2+Yyxs8/FXY7unN/E0Oh+4e8MdQI9n6bHs/U4C0+ s9TkgpU2KGKdRn6M+TJIman8Hhtem+ZGxO7x2UtiiincZ+jNR8yGd7qzrt8sljZoAqZHfoDl8c4J j2uc26i6rxGGzx1PVWvOp2CadjmknZ6P6VGj/wBCT9t8l7vLVea+JqtOl2uXtjnkubHPfj5lqDof ofsvut2P3eNft8D0qro955n4m/SYtjnNr4quVQ0e/RHNwonbZ5XJOWliqmn3qxezxzoPuIA5/wCJ aL8V65n4m9V878v7HO5My0kAVi1O4c78TAlvPz61ERBRJg6DGc5Wovx3mZ83NpCyVB4rHr9vn/Py Xe/UUA8QVh6nvPYuWMtA9HoB4rhg7NoPmWEp5KJaCIh8bHnjidq8Q/HQ+j9hu7+qqK64uxThk5fu vY0AAAAAQBj61o/JU8kr6pdmIWNxfjPG85WI0XXcI7s/a2MDzazmr6PTwHoPAegHiEHT9MkRIKo2 Pg9TF+M8azlZ4D6tu0aPV/MAAAAAAAPTwiL76Hqvd8dt81iw0DixPjYjSbrXGZbJsPnT6P4hj0Hh 6P14/PoHn689/PvgPQI02Lrg+7W8xxe++YqaoHfxMexGc3WtFllcnzBtMeiABIsPYLXUPqdUL7yy O5evyLD2G1tD6lVK+csjqYr4A4bctO4xR3Q4IcSZCWXF+M8YzVcHh6eAFuKF1Lv4mdyPnJjfePgZ WC7+Kncj4yY/3jj+VgqkX3lvp4c7vTO019HPw6gk6FseHj2Iwmq6AAAPp59SrB2WJp2sfTz6EqQd liucrXz9+QAABKELYsT42Itma8AAAP6+cJ/TUHWOpfn3z5+/E7Vq4wzYKrM9ftf8lO4/mvXZcAAA Eow1h+u/8RHuw3xwZB4egAv5zPsUUTVd0WzqdDq7sywNogeyVCd63bv559Q4v5754egA8JUhrB0N hh4VzaGojZAAAAAAAAAAASpDz/b2WsQVkwc7FTAAAAAAAAAAAlaHnpMtVIr779cnEWAbTb0P0+dT qSIAB4egAHh6O/sFS5qMmtLpSQnTW2JEsFPrl5s8RDWh4ly1891mtvRtXboAAAAAAJzu3LcfHm4G Cte73IyfMP3le4Kz/EjH0HbxNlu5jqdaQims356A8PQAAACxF649kZMIeJJgrPk+4Ku4ZmNIC7Hk +3Lk2l1ZOHKv0cAd1L1XBxbXJxtgB4egHh7Zy/8AD8vJg8PSRoC0ZX1hqlrT8V1++ixl143o9SUg +q9QG924rspOtyFNVDQaUvBtU6iAOwkq7qNaQ02tJfb7xWx6FwH6fXwBI0Dasj3BUrUs8Q13oYs5 eeIfb6xVfovcv08tLfOEx1DXGG630jf7cTPFs5TEFc6Jw8XaBaS98Ky8mvENd6H3ktVJCmKgAJEg bVKVetlSsc3FEBfj2yNz4v2EjXY+iLd9fr47uVqldad2PiYyznltOgfn+HK50eLoK9eFmbtxLqN+ CeA9ACS65cP/2gAIAQEAAQUC27b9n+5/u3aja943Rvngdp3yTcU2zabaSk/t7vBXf9+tr/YG+n9g b6f2Bvp/YG+mrbpuOdh927Ufdu1D7ft7te/2Bvp/YG+mqbtuTjD927Ufdu1Evvu845P+wN9P7A30 i9x3+SeaXtOy4dj22vutTb7qVdaj4BRR/wCOatHD3LTUn1bHjB0wvNS5copIePMTVznNUw5sGBRS a5r0afbTttSr7r2udYfeLmfjW9j53kfudV8Aoo/8drzWxtHKSzSj1jRi8upq2fqWKZctmHHnv7bP ARtj9zbS2yiiikxzTo1HhfqNfde//wC+IIaxwYqKPvGxVfTlFFH7Xt8ePZ3ltr+WeSFMTF5mprbf O3xqKKKS/MkENV4X6hX3ZuMBXPuzjW6dW/Hfiv1vgyUUeeLjK+nqKKKXQT/Jmj4G/HnVBRRRRSV5 gghrPC/T6+7dxr7uU2DHbRzr/Booo7p/2o6v/RUUUUUUUUUUUUkvHoIa7wu06vu7cq+71J3jlg+D VRTu7alyiiiiiiiiiiiikh41BCB4XabX3fudfeCkzxyRHBuoooooooooooooooo98WghDcK6ZX3h ulfeKkpxvjOGBRRRRRTiiiinFFFFFFHfibbK3Vtjc1aMm17aul1947rX3ko7w35qtbLsWPrCiiim bV5pvrbizH/QdNXmq62ph1eaca3q9mOv4OYavNSUGoooo4p+8xspSiimlV95btX3n1hRRRRRSd1/ X2n4nls2P+gs9f8A5/w58VPwFg1/X7vxBE5sX9BarX/wnSc2K38O6dr+vyWgqKKZbLq5G/8AxsUU 0mvvPd6+9FFFFFFFFLetfW/dJe/UVLqX47raXXDHdJeO1W7rWiiiiinWOsdY0ivvTeK+9VFFFFFF FNr2TD+For8Oy107+U/xPIa2x338txm6PJbdt4x/iHJ+JWkRKO9P3Vt+Yr3eHujvrCinWFFOsaPX 3rvGNd0vpWwUUUUUUUiPzPG54PWPyGx1redZ2nVWMlv/AOS7dsat/wA2QkrH6l+SXen7K+/N0Uxj a3KKKKKKKKaNX3tu1PebvhVRRRRRRRRRRRRRRRRRRRRRTRa+991p7ykOFyiiiiiiiiiiiiiiiiii iiimiV98bpT3jK8L1FMTRxmtztMrexRRRRRRRRRRRRRSkbgusetu63qKaMwc2brudPeE1wvUUjKK ymuGBRRRRRRRRRRRRRTFT9ty1sc474h3SrSJ7O7TKe8Nyp7vn+GRRSJ4sJ7g2UUUUUUUUUUUUUUw 0/aQQQ02nu/cae7tk4ZVFIXjG7HwaqKKKNIPO6wSkd5cKKKKKKKKYKfsoIIadT3duFPdu08MyikF xi9o4NFFGsc9e2M9bcXXVlYvBWcxWvmKiiijeEfusD1k4YZFMdt2XJZZ1LUEENPp7t2+nuzbeGZR TX+UzTG58xqttbaXX1iGVWLHaJDJbepHP8jBzn1+NdVnY/DGuFFIPlUjGYZHFfqr+l0Vr+Nheggg hqFPdm44dQv2nammk1zdy0I7loRAtdPpFd21MlG34z68W2/GnW7tqZsLPR6ynctCO5aEN22pd32l ppNXXctCO5aEQrXT6RfdtTO7amd21M7tqZ3bUzu2pndtTNOw6hZtP//aAAgBAgABBQKKio3y3yuL MkXGlkVG3HlUWXRMZU8sjTyyNPLI08sjTyyNMcXGJ5XFnlUWVjI1fLI08sjTHFxh5XFnlUWXRkb1 vLI08sjS2Ljq1lYmN8tiuWGT54/l0V+dKKdnUrStOjH8uivz6MfTd9XRjJXlkXdTyzrUK1Us+XRX 52/Iu40SpZ8FtF+G759FhKcsjOW9Fvy6K/Ony6anXqVrWohb8Nfn0WEpyyLp6b1ei34KfCgnx1+f RaSnLIzlpUp/iUJPlsZy3/Hk+WxnLShX/EqSfLY3lxaXfGv6VOjrUK1JLl0by4trQuqvxWv29zy2 tfuvvzfvhc/bWvH11fufK/bYXXwU+V/TJcujeXfG2eOr53BSv3Vb/td1K/dVzt15/npX7qff7PJU rXYZB47wynTbWiX149Ely6O5f+gqFI/BR+UrSotDJH4Mr1V/RkeXx3L/ANBk1u2DNPYaN4Wbxu8k ZB5o/Hgj46s7ScyZ8ON9H3QNLL+vZ8cjy+Ow0rG32Vs/QzQOW1w7jMjuOdtHmTFGRXcr7oBxhyvY qx80x6/myZf0JHl8Xyxz8/8AGkPARfLHXz/xpDwEXyx38+i3Fkvpfiux0/Wo2x1pmxdlXokW+Skd F8sefPobfwvPo/Wt+nJjpktq0ymJr1aynLIvlj359Db+F79H61v09MpyyL5Y++roa/wPv4/gxtLs lrjB2P6Nv09MryyK5Y/+roafwP8A+Posw5MlMbK9e8YLR1SmXF8FjXLfblxX4alKdatKJTpleWRX LJD6uhn4dzi7XEfMb4+yxPs1VMOWuK+9pgvHWG3Dd0NfD5sNua2rDKuBpTFX4JXlcTfK0jX98h1u s9Os9Gl8l2HaShnyOFwZHJ2kmO73/b9Z6dZ6WZJPqvr5Dr9Z6dZ6Nskl2HaSh2kmdpKHaSZ2kodp KHaShLXytY3/2gAIAQMAAQUC2Cfm/O/Pp0gJeWzYpXYZBjirPz1asdomW+Wkk/rTzGQPMZA8wkDz GQJ2ZmMTvz6dPPp0ayUjc28xkDzGQJ+Yl8OXz6dPPp0jpOSvZeYyB5jID6cfMm8Jsc5knZ7nhrtK 9hsHi06Gnhc7jC2srsDXrNneB3abB4xOhp4Uvz4cRP5MeXKnRG+A6Nir+3A882CLd+cYYl5luat7 GuGe8WINPCzGe7M8Qj89WrqrptQncXWuQsx3ZL8VvZ4pZ7c1w1rW6qCCEd4Ho2H6YHnkjzDonPFI INfDP/GIIINM/ZX3wbe6rWPbtC903xVmsuLNeggghH+C6J76YLnc5LdlKYZqq23232zPiUEG3h3v i0EEEKSjWzG7lrb8Qgggggw8H0Tf0wdPW5ynrSERfXsZfxCCDf8AgeeKQQQQQQQQQQQQZeFFJjjS Dp61N09ZQiuFkp/Ogh22bqiCCCCCCCCCCCDTwyikrxpCU9ZmqesoR3CyR45kEEEEEEEEEEEEEEEG 3h1FJLjSFp6zNU9YQY8LXvHKgggggggggh1RBBBBDB/DW6lKVe46DnNbmIWnrEzT1dBvktx0z3Uy XoIIIIXxTyyOvst+xfK3nlyFkU8vjoyy37KwRTxwyQQQQw/xurq1EEIanq8xT1dBBBBBBB7HscWs Oq2/Y9/+i2XW/Y9kexrqjWtv2PGf6VD1tpqcTHsXEGgghZdSlmbjcghD09Xl6erIIIIIIIIUtrUr KOqxaFba0rS2tTDKOsEb1a0EEEEEEEEIinq0tT1VBBBBBBBCRfW6q31hxV3sWt5WOGZ2VtK5XMrL U1mut4W2fLGSlmz1yY+zyIIIIIIIRNPVZa9Ja2vWEEEEEEEG2zYb2rCYxMZZi+j8WeYm/Mcdm0NX GGOm8kY+y7TgxYBBBBBBBCJp6pMV9Xb8aIIIIIIIIIIIIIIIIIIIIIIRVPVJmvq7PjRBBBBBBBBB BBBBBBBBBBBBCLp6nNV9YYcbUEL3GHHdiz2ZrkEEEEEEEEEEEEEKvctLm2bt7UEIl3hulZqvrMZx tQQe+JjeOVBBBBBBBBBBBBBC+v8Azw57sN9sjgrRw/69IWvrM3X1mJ42IISHi4njmQQQQQQQQQQQ QQQyV/cUUUhK+szlfWoXjYghJeNhv50EEEHEpiwZWLzvgggggggghlr+4oopB19anK+twXHGghK+ Og+LhBDO8bNrnEzhpbRg+ykXfVq6QQQQzSbXBlbOcLuxC+6mOy67rXKKKQdfW53nev8A8aCEvzCM dUauqJWlUtpIOaOnUG0trag8aWO8OKXe4KRbzI9xIISnj2b3IzyWzzStr+WvdWqKKKQXO5/HBXTU DjiqY+owOowJXFD9/wCxhBjhxdV9hwp2MIRGOMox6jA6jAzYoTtYLHF0wdRgdRgSWKG792MIdjCH Ywh2MIdjCHYwh2MIQGOCtmv/2gAIAQICBj8CYUphpS1NJUZqSRnEyidJjyzHdpyDy7HUTkHl2YdB OQeWY7tOQUS7EegnIPLs9ROQeXY6icg8ux1E5B5dnqJyDy7HUTkHl2OonIPLMd2nIPLMd2nIPLsd ROQeXY6icg8ux1E5B5djqJyDyzHdpyDyzHdpyDy7HUTkHl2OonIPLsdROQQ/bs9ROQPqSw0laWlK IySRHEiiVJCX0DdkvSJjQOWTEvoEWSuR2mG2zGgcsmJfQIsl6RMaBdkxL6BFkvSJjQLsmJfQIsl6 RMaBdkxL6BFkvSJjQLsmJfQIsl6RMaBdkxL6FFkvSJjQrsmGNCiyW0qkCP5lKYn7MpBW5mvykP2E fmasbiZAz+ZUmJe3IYltzNeIESaz+O5e2ULr+hXZMMaFFktoflVn8sluJFDo5TDx4M0VlAVovykE ngzX5TCZSPyubjCG8dPrDJ4M0dlYltF4glD3uUxKsMn8FZ84oX/9C2h/QrsmGNCiyW00j/kednzT DeuRK8KQifVWzzZQLcw5dqf0K7JhjQosltLsxNuKJKToIsEeIuMIlyOJIUkvYYZKXJRtwKsRYuIP HJ5wnCKKkq3o3oBc5OuqrVoUYo+qm8Jb7YyuqS+aZ4oF6t0Nzko6qtWgZHhw+reBL3S2h/QrsmJc y/sIsltKpj7c8bVa+VPJxBEkpz4iYRUdMYcIbRKPZtSCp37wW++vOTDl/wDG+FK+3TCmm1YKeQIY dV8ZsqFcFPrCVfcHzdbReKnl2l/QrsmJfQIskC9Hf0K7JiX0DdkgXo7+hXZMS+gbskCuxK8Iq2/C KL119X/ZXZMS+gbskCukCx7eWIVTFEBWWJjQOWTEvoG7JArpAse3li2ExoHLJiX0Ddkgm6QLHsa8 YAqYx2ksWwmNA5ZMS2gbskE4rpAsd2KCoEXaEirEhXbphsa6YQMVV3KpXxDYTOgcsmJbQN2SCcV0 hAveuUXwSTvjNFew3IleEb2IESb0LqRBQoMoCsqlexmdA5ZMMlm2FJzSYfEUnmw5sSzSqYb4TWaZ 71XhEOza7xXhjs2u8PwwVVpiGlV4I7FjvleAPisy1bTLj/gHwWZatplx/wAA7FjvleADrNtR0ivC HZtd4fhjs2u8PwwXwWL391XgAqzbN7+4rwiHZtd4rwx2bXeK8MJg0xDSq8Edix3yvAHYsd8rwB2L HfK8Adix3yvAHYsd8rwB2LHfK8Adix3yvAD5ZthKc0qPxFK5sOdAs0mmF6kf/9oACAEDAgY/AppC Jp9DaH1oIkLUkiJKjSVCTIrxcI87N985+oOG9MzCjrFfcWfKCJt93Pqvc9VG/fEf3s13q8oLPTMw tk78VqP1UiJPvQ6aso7d7rqyjt3uurKO3e66so7d7rqygktTcylNTA4ssJ7487N985+oedm+9c/U G1KfeM6hf1q3MY7d7rqyjt3uurKGyZmplJQO84suUedm+9c/UPOzfeufqDalzD5qNP8AvVlHbvdd WUdu911ZQbxvPGeDnqv+sS2cmXVIcfQk0mozTBSiSfNOi8dB3yE7rbv+RVxw8FbkCdHyndb6CeIZ x44JECSurwCsyceO4nR8p3W+gniufEUlOMw3m1ErmneutdG62nBExJa21/kSJp1sq6FTDh0b6zED TVTumCZReIJ6HKd1voFxA0/0IoLluJc/pjA8QgbiI4yCJlNLcIXCQj3jCW9wiIVWu1X7BWVSewb6 N1rGrkEnrTVtIf0y7R3U9DlO630C4g50j2FRymXV7xfjcEUKUSfWKyKXN0xVcWkjxhGaUSoEd7Yt 9G63w8gk9aatpEy00mJk+u/0jEH00bwrppSYLocp3UdAuIOdLYpKJmqG4KktGseHZt9G63w8gk9a atpE5rTts7hoO8RgujyndR0S4gvpbajo3UcPIJPWmrZCb1p22dxWMF0ct2rWOqW3IxXUcIlNZatk JvWXbZ3FYwXR9BTiup4RKay1bITesu2zuKBYvQU4hE7woiYKrgEprLVshNay5bO4ZKES3Nkn7opP ya1VSOOGnBwGEUU5/wDMY/5Sr8nXqxjybmC4r7olPyaFVTOOLBwkJ04U57wg59waTGWa96nk2JAk 4LsrrLdshNaw5bPaJaeaIv3q3YKON8ufgvUQLAJZMac+dpwI035zCkxpz/5iMLn4F++J6EY75UQx UiZTEo58rTYnNN4QnyMyjW4yTATs1MF8w2XNON6ij1nsC2ErrDdshNaw5bPaaAX2jm/tiXWvc7Fi jvR37kDvigOfa0Vf2zqonRTgvdUsAp2mV1hu2QmdYctntLMpININaipUeGGK+dO7QHZoygbiFnDG ZCYObNKXjM6hqvRrHHhEuX3DNG0pVVK0RL3oX4n+N0Nfb/tzKKlSsZnjMsF86KTMTf3mZbrKaiok 379ZRw36IEHft8+wmrUiRlgphh/qpoP2BTe4cNoltYbtkJrWHLZ7SmV+7S5P1Lx0cRlf38Ic+4oa +EutBBHCETLewB5yfl88hw4l/wBNJ5Q1LS7eZlWrxR4CxQCUfdpVLzyMNHEZUb+AOTLKC/bunSje jEob5YuALR9qlksPOX1UchUnubm0y2sN2iE1rDlswfo8tp27RCa1ly2YP0eX06LRCb1l22YVdqqP nCqiO3mVF8U+8V2XQUY/uG7RCb1l22YVjuq/GAH0dvPGKyRzokYqNXhKay1bITesu2zC8d1XBxBX R288ewlNZatkJzWnbZheMrq+DiCuhylsTaqmZkFc2FXaVYz2EprTVshOa07bUHMZXV8HEQV0OUrp IeVBRirLRU57BnKh0g2Xyq1yw7uxNpcaxbwrtXrhrV7pEDVu7CT1pq2kTmtO21BzGV1fBxECUvsz oMRK8KyrwU4n3LxYgc2v3owLLcNCvfwHuGKkSURboUp2FYlYLrmPkFdFJHfLdHOSslDNNlVZ9p7G T1pq2kTJk9NIVnl1izKFlXrHWgefRRWjDm3g5mnpg6SvsoL/AM6h2jvdp8Udo73afFC678ySqLzC DwF/9BcQ8xNfx2/qh8pMTub1duHtmuIfOTE7m9Xbh7JqA8xNfx2/qgnNuvmmJ32klh0x8Y7R3u0+ KO0d7tPihXzE17x/+uj6kLzTz5lWwspLBp1DtHe7T4o7R3u0+KHK78ySo4GEHg1kuIeYmv46Pqh5 ia/jo+qHmJr+Oj6oeYmv46Pqh5ia/jo+qHmJr+O39UPMTX8dH1QljN6aWrPIqlmUIKvWKrE8+uit CPNvD//aAAgBAQEGPwKvNNV6qyrMrVp+TYYk5+alGG2JSadl2QGZd1tvNs2xEwio6Tj3muD+c1H1 nEoJe77oYCmnCoM1+qtBRziBOSbEcKL173gJViBdhctZBWo9q0D55ojDT1MAC5rh0aONW6mo/KpU 0VHCvNrwumWmUglss3DV20KI+g4hM2EwVw6xgg3td4IMCP6krOgjWP8AOY99ru+JKz67j33u74kr PrmPfa7viSs+uY99ru+JKz65h1b92XK+sTS0hT1dqjiobNowzLmiYace81wfzmo+sY95bg/nNR9Z xNpTet2pSmZfCUpuOsBKUh1QAAE5AADHvtd3xJWfXce+13fElZ9dxNmYu25nyl1sJL1eqjpSMp0D PNGGPea4P5zUfWce81wfzmo+s4nUN3ndjaEvqCUIuKrpSkaNCUpnAAMe+13fElZ9cx77Xd8SVn13 DcsL4u9KTFbq/wCpKzxGk9sf85rOodU4t+WXcFbnWJiq0+SfbqVUnqkh1mbmmpd7OicfeSVltwwM OKdIhi5ucFZ5RmdyUTvhhZPWU5o73D/CZtX4mmt2c9KmPKqwGZZouL34aAkfWWo6EjES/LBf1IuH /myY2cy0UR7VWtC+5UNB7O476WvyTO7O+lTHlVbkWZd50cLbS1j50g4m9s041mdRDaIUgmCDGAUB qjuz3j1fk3Z1e+lppI6y1KJ7zFs84aNyjLYu5h1zzdxi56+ydr2qtnVZtGZK+1gYb+CQ+H1bzbHH JPddon58OTLugr7VI1IQO1QOsMO+lL8k1uznpT/lVYbcA8JM+FcVvw07NPWSn8Z3H2ssXAkuM8Id QIph3Wr5cRTKTJHCGXP+nEzJLih1Lm3CVDKopKUoVoOnilI+fcW64oJQ2kqUTvAYee1bV1xz9dRV +XClPiLEuEqUn/yLVHIg/m6CTgJQkJSnQEpAAA6gGgdBO+PV+Tdnu5l+y7i2OcNF5SlsXtzuuTlm c3XfSleTa3Zv0l/yisSfo6Ox0BcZ8HONAql306FhQ+gTvoc1EHRjK6wy4ofT4yPnAiOxjI6oIajH ZN6Ek/nRJUqGMzUs84n6yW1ZfkMIHE1tmnGszjcNokpJypVGEev0M545W7O9yx2XcWvziovKUti8 nph7Ily67iWhDYirKqrzhSSo6BEdfBMs+SofQeA436aYQ+bCm3ElK0GCknWDh30lXk292a9Ie8or Ep4hHY6F0hDaE7ReUrcGkZjAjLmOrG0ndmpCNKW0nMFq3s2gcUfj6Ob8cfybs53LPZcxa/OKicpS 2Lp5x1vlOZ3GnBrca43VKDAH5sOekK7xvdmfHu+UViV8SjsdNmvGndmu5Z7LmLW5x0TlOWxdXOSu cpzW4x3Cu+wvx6u8RuqXsGs6jFSsgJJ4dPTpnxh3ZnrNdleLV5yUPlOVxdfOSu8qTW4z3CuyML8c e9R+Av8AjDuv9Zv9vFqc5aFypK4uznLXeVJrca7lXZwrxh71PRxhojCO9Hgjw9BGBgIAneiYwHXM Oie7s4CUiJOoDGlSE9SJPYGHM5TxssMsd6PUHDi0+ctC5UlcXbzmr3Kk1uIKNMARrhgpVoJVH8Q/ 4dFKXY5LoFFnptclLv7ZouKdbU+2SWAraJbLkq4mPCnqiMivIjMK+tYVlGYL9ozbWcGEc2z4seDR hV2CXSaKmd8xU/tm9oHYhOcsxz7LaqCI/W3Jy7G5dBosjNok5h8vtBwOuLYbBSwVbRbYdmm0xA1q 6hhfCyhBV7c7YpBV4NNuFvTr4hWYcEcVS4pSXQul0daUTrpfaS4lSshVs2VK2jgbS6kq6h6FzusK c3+1HW1n5920uc1B5UlcXdznr3Ks10i07glWGxXKhWHJecmhMuLceZHtnatljallIZVLMjQkFPy6 bXRtEZ/b8ynJnTmzCpXA4U5YxiG1g9Y4kv8AfVcqzeJtBcRnVcCWwjMMxX7RlXsgGvNshm62J24y w2qvN11Esma84c2jaDMSzfmoYDgagZZRXpSVaY4uhG0bz+35ZGTOnPmNSt9wJyxjmLaSrrCOL5/3 1Xk7Zx/+hhTjaVCa1KWkHw0vINs6Cf8AuuAhPCcX5V6kwhdTpTSDTpgzDja5ZewU4yEtpcS2rziY GXjJObUOgXoOvgxA6OMfybtpc56DyrK4u/nPX+VZvpMEpKjAmCQToSIqOjeAw1ZZTJ+yWZ4z6XAy vz4rK1u7FT222Ww2zhV+7zx+lDRuFC0qQoa0rBSodcHSMKypUrKkrVlBOVI1qVDUkR14qtoMJkzS qxNJnJlbjK1TiHR5oFBh0PJbSh0STccyFatEMDMlScwCkxBEUnUoR1pPSbQ5z0DlWUxd/Oi4OVpv pNvUO26HIvzE9LLdnKjNocCJpcpsUPOOLYLTs1NPOPE6VwZTlAECAKxWHGUS66nTqvOrYbJU20t+ cknFIQTAlIJxc6q29JSs+4/Nook1UMiWGn/aD3nCG3HVJbbmnUlGXSlRAUkHTpthu53KI9JTU2qn 0yrUZp9hs+fOyudE41NPuFtbaU50acpEeMd6jWta1vyGwVTm555+b2sHkmYeloFTCmXHp1RllKcc WVdunRi+r9qtNTOOUbb1STpoQl9DTkyKjUXyy24nK7MoSwG2SRxSY64Qrdr3Lbsm2yinuzspNS2Z 1UqgvMyvFdfSss1BBmEqQ4jKFZDxYYmZUrDhlph6XLie1XsXFN50/mqy9ItDnRb/ACtKYu8gw/8A qK/yrN9Jk6LfNqS1z+zQhMpOLEqtSktp2bZel5phSUTCWhlLqFeEGsayatdbFD/9GfRUGpakS7zM qmTanJhl5ttCkS5ayMJZhBKAMV6bue1/b8vVXtvKNbZCXJBZmJl5YSshBO0S8AYEdrijUikUkUGi UIhUlLpf2jxcbaDEuqLaW0MJlmRBCRmOknNiSYvmy5O4Z+npg1PZZNxLpgApxTE3Lr83W7lG0CVF CzpyjQMVasU+QaXS6zMPrm6Kpeyb83VNOvyyWXW28rT0kl5SEHIUZVHi8E/LWRZ8rblQqkfOqgkS jezWQobZDMnLt+cPt7RWzK1BKDpynViJ0k6ST0iz+dNv8rSmLt5z17lWawjrH8Hs7nVb3K0pi7ec 1e5UmsN9Y9kfg9m867e5Xk8XZzlrvKk1hnuVdkbudtEUnUcyRq0b5wlbhTxjlgDEgwjwQ6egxWCU pJgRwdUHCYElCxoJ4RrG7ZrhCYC6beUoZtKQKtKExj1MXXzkrvKk1hjuF9kbrP6flFYa8d+wrp7f cJ70Y2a9G+lQ1pPDjiltY4c2X5wcBx9QUpOlKE9qDwqJ14tTnLQuVJXF1c5K5ynNYl+4X3w3WP0/ KKwz4/8AYX09rxaO9HQWrzkofKcri6ecdb5TmcSvi3O+Tuy/8Tyq8M+kf4a+hQ/tUNpc0pBCirLv HeGnDHhS7tQuPFywKMurSdBzdJZ8U33o6C1ucdE5TlsXTzirfKUziU8W53yd2W/i+Wcwx6T/AIbm 6pyWZ2iUKyk5kJ40IwGZQjoOAudUlloaVISrM4ocERxEDqxwGfOmhk4oCApaUhOiGZCVJ0YRMyik v+bqKjszm8GocfVvpgD1uhbmGg3kcjli5BUASmJENURgNTAAKk5klJilQ6h0ajuIaRpU4tKEjqqM BhKfqpCfmEOgtfnFROUpbF0c4q1ylM4k/FO98ndlf4vlnMONtiLrZDzQ+spEYp/SST8uCFAgjQQd BBGsEcOAlAKlKMEpSIkk6gBvnDTK/wB6YuO9Ra/o/oiA+TCJBtRSjIHH4fTzE5UH80AR3EOpUdmS A839Fbf0ojhA1Y2oQpor40WFZEmOmOQhSRHqYabYU4UuNZ/CEEghRTrAHBuyfi1eUXjZuxSpOlt1 PbIJ19dJ3xiCHZdaPrFS0H5U5Fdk4D7y9vMDtICDbcdBKY6VK6vQ2vzionKUtivKFTuCWc9qz/nT SKHITrYnvOXfPdjMOXDT1qZMzmyRaEE8OJTb3BdLZ2bmXY2fSXweMnWV3zL5fx495bv+B6N/cLHv Ld/wPRv7hYltlXblWjwsFOWpS2lnwy4xQm83gNP5xx9tXD8MU373Y/1CtVrbQ05LYkNv1M2wu7P+ tj/Tq1WdtDftiQ2/Vht7u2nzY+2rh+GKb97sP7a4rsQvKzxW7MpDqP3SYQWq/GSf1ce8t3/A9G/u Fj3lu/4Ho39wsMQrdxEbFuBNr00HtBrH9YGBxLbe4LpbOwMAzZ1JfBG0VrK76l4H5Dj3lu/4Ho39 wse8t3/A9G/uFiU2dcuRaMisqnLUpjaz4RetCbydCf1jj7auH4Ypv3ux9tXD8MU373Y+2rh+GKb9 7sfbVw/DFN+92Ptq4fhim/e7H21cPwxTfvdj7auH4Ypv3uxQVGp3BMue1ZHzVpdDkJJsz3nLXmW2 mG7hqC0siZy54NGKeDH/2gAIAQEDAT8h3AIZonoDRFV4QikgBgAQoO8NYN6lel4SjIOijGKQAaGd wPlViyWzXrEfoYWZ8LBjIFRSGlH03Jt26LKAqJiCKmtM8YdQ3zcEF6AoDAcblxvOIIOq8L24xohZ zF8KeAMHG7cCEgCNGkxWToUTrpVHjvSBq7QcZ4QnGXZAvdUANWBXqlH4viEDCgqOhFYHzgtasA/d ZiH9lRsmo+yQ+otWhzVvUdTR1OCr0qAsBFtQCtbCGXA9PrLBEXEcm7cVj8zH9TwlkVdTYx5R1OqJ 9ygJ3pCwIwd1imhQIU2ruprPVtjrjyCKlIrxMkiz4vc4Oh1ItoXa5vxFei1TMa5gg9kdgIxa44Cg iewO3d7HVmGNA9sZ7R0ZmGIDNfdFV1hXOBDtAQB6AbXkqKlcTuoPEEdPi2IVQfoXu9j0jrxcbUMt JooNqVOrrdoEA+DTNFoei2jtLX7oiuUVCd2pyqQIoVzp6dF89g9JME1LTkHzkul1UCLwpUeANu9I 4BJOB0ecxcQuZ9QPpXopbgR0Djq6hDBZ9vW1w69dXiAAAAFAYANAOx6vi35a4j3j0KNjsCKqV6ij zcNiLiy7pZQPb+Wf/m/J+E4nvfoBdBvM/RFR4jhLYmKrmwaVcwAAUBgDAHQAx/L/APi05qOJ7r6Z VkiLOl/4W/8A/NryY4/v/wCbgQKeBn2T8SKj65/vUrrC4AXoUH0e7MyoWgpnQB13p9XxacmIvHGB ay1N9yDw2H2xhRjsXfW6PQDkORRaCmpE1qGiI1EcU6mL9R5Cwy2sQZDO/QsKSzndLk0PzPFAZyEr tGfSG7aVnhME7x5hMIjo2LGFqS2Z0zV/edasF+7RCsCMg7Foh6PsfuoyjNs7AKNz9fyaGivzDOkg s10pjFtuGkcpCFoCljNa3RJm4xWbSrqLOF6a1vSM4JtKLAX5S16Cv1tYE0mGt2gmQiVjwJHngEe1 WhaTGwnvgGs5n0Low12wnWFrGyU4xX9PRqtP8JX+Kiy0oxoFp2vQglGaJHxMC0MBwVgbhjRsBmBu dzTFcFI3BawXDHBklDQWKS10rB54K34IwMJh/wDH8JWx/vp1YtZVxTajInd7GChqerzHcT8hEAoH UxNYwwC9E9bFCbp0muLrvxn3MrhMZdoHSRWRYpnlwBIEkNWTOjVS2pko6lmbbHh/hbbGdAp3JKAo 2Xj+D/SuHx3XLYl6vDgnINRS9FzbFVCp3cs4JHffrh6ZsOukIPjIrFgCO4aVZqQge4IJuPmkp/x0 MOsggEXf1tRAoeoYVKKFBVVtVcqv8X/XVfdvyE3/APo//wD/AKaH7/8A+jP/AP8A/Uykz3zjmFup Es2tgGhJ1mlKwC8NB0/n/wD+5KIylCtUsyg3Zo2NToA1Y+/HrEZmiOAFOxZbCPf+J9g7w5LuP/A/ /wC2JrFfQj0dzudSUu54KVeDj2WXfYWSHQIa9qrgoWxL3/jubU+c8P8A0X/+WdWHYDFiY+zel+mf XN1Ra6GzOkHAixT2qP6z/wCL+I+OlYNm1ALfhxljgnTQ1FgXWlxDFhEDKr0dbHxMeiC1lKoAVrAa yo70es2oNQPp1gO8CzElBJ1uajmvtRwZBSa8JuUgZsn3MEfIVsX6ejZP03T2cbebxkEkAfJxslwj o6gpCkD0gHaMF1BWow7apZnDXDCnEjNXVFAcdxGjZ24M5oey2horrXR95r08HuY06CWyDhElWDTs 4gt4Aex0wRqwcVfJXRzL+84NDvjvaABQJZoqDKjVqo6dfUpG4o1a4lanwmgvU1rqsIZlih0AtxdO gkHs8E73B8cHtx7aJ9O0ig1RWj14XWujg9Ssrj4678a4U99eLp11QRPmFEUNS2u8fR/WiIou6G5x dOgE7UGajqvt/APXr169evTlG/HErU+E2F6j/9oACAECAwE/Ib5AQ4eAXVwaBgxwlhSimQzwWFBY XqYcGDDgyM9fjpYu47nHBgzBvjaWLvK9BgwZxwSQosvADqZLpMOOLvQn5eFzW3iKibEUzw/LLlzX 34AukCDfHU3463g7rPWMnLFp+bhc1N4a82XBgngY68pcui45bhrOnC5cuavHrj9PQauXNSaUuXLm RjXgbJLMuXcvhcua3Hqj4LM3hw0S5cdZoly5cuXuGeZcuXLly/SFFnJr4ly46w0ly5cuXLly5cuX Ljr6WZwa+Ny+Fy5cuXLly5cuXLl+lwZQa5lMJcuXLly5cuXLly5cuXLhp6Cgzl1zRNUuXLly5cpd dZcuXLLrrLly5cuaOIDHLnHrgtYCxLly5cuJzpFTVNtdLpK871XbdH2sr5zvEzbbDTVb6XWdpcRn aKmqLa6XSe21hMX+zL5ouILAs0111dC6aly5cuacWYuXHHlHLly5cuXLjdq1JQ6W6vPdz7THb/Qf yVwiXRaX9qPzjeHKrvApyZVfQa10mO3qPZ/ON4ud3gYDX6q/BrGKDsB1U5q+phxrLly5Q2kLT2ly 4o45xcuXLly5cuIGVESdi7OkLqruita8XmXBLBhLVrOl+o5HcVdl9E83A6OkuXLly5cuXHPHILly 5cuXLlyluWl1KC7ADtlat6soBl1aGEgaa1K1YZRm9TRTEECxyLjRQLvR66YOuYZyUxh1WGIAGjmY AT0KlO00yvu00u2jEcBodBriirqzMxdVTW5cuXLly5cuOYMhSxmQW7ly5cuXLlzxMeNctK0vqMdH tmFDA2BF6s33mK9irGIMeK86xetN1RS263dtX6msgPFXi1mullh1dY2gB1W6FhclBc3YZncTUr8W mhoui3uTwS5cuXLly4uABb6EuXLly5cuXLly5cuXLly5cuXLlx8IKX02XLly5cuXLly5cuXLly5c uXLly4+EFr6bLlys/wBIfqyy5cuXLly5cuXLly5cEuDUqdTJfBsVV23A9Y7bLlz8n8s5Twy5cuXL ly5cuXLly5c+gn2Z7QjqEqFFOnH37+uy5c/P/LOV8MuXLly5cuXLly5cuXPrPV79/UZcufm/lnJ+ GXLly4VoDA84ly5cuXLly59Z6nar7jhc/L/LOX8MuXH14PiOsHY6/wCR7Ndsn1DbFvTt1ly5cuB/ cE6hElxh1DUoOw9StX95Llz8n8sZdNk9o2NOsLVZQ/lF3YUPVL/pwPb07kVxU7PqXc2tmXLn0P2z R0mj2gaN9x+pfrsdj1C2dkCow4AmG87e2kXRMOifnjYcY71lqfV6X/PAVyUDx+UscgO9uCptDoaN 071/HHHjwamkzq89jdfPGw4Q2anU+va/5/gFKhSoUKFEzIERlyBcujT30n//2gAIAQMDAT8h6of7 e5hRbVrLa8IAAdRjMdLcahtywDWn087RUrXsZ8FYAO2Dx5TbHbR+4CSXpAABAAU6laMvUoOeOBI1 Guq6tMvEAAJBV2cya0eMSIFxtq67rxAAGgdI1FoeHV8EN3r1Tix1mCzI3mGSVBJ1H6/1Lo9AcBUS u6/qSgv73wGqwFj7/wClyi8GpoNzk4C9hwVTn3ZwapzwH5ZhgrLD18cFT6ni/fm+A/thkgvJTxZp NevS4WT1sNe2r8Tyfj3XV56YhvYwrgXL9ETb0L8t1+g4LTU/ctfjX2iNJyusbMzOZLFT5t+OAsre g8z/AIxhUDpTIPYau+QPnpGiK6rl9Ax2cuXMpAR5zC5cF7XiC5Hogz+iFFk1Lonfw6hMyy9dMfB/ 7G6XcH26E8cLRfxKRK1a9U9IfRS5cz3ZGfDWX1wLCaNX6iKk7+n2f7hpQFjM9txBc70Q3vfSDwpN 0sNeamIHWRVHjy/W8RW3X1AVbCXLme56KGIye2P3Jlt+ILmuiC18v5QAFU18HzfoiOzfBvxBex/P EKDHKC2JeX+UAB0HGfNfp6LuLfEvxOQd3/wgAA64s+R/T0RZG+QIeR6vrAvV9PQLVfT1AdBFqaEa oBDSHVr5r0AJqwgWw5p+pAFlmguiPILK+55LY9KN0613vWNsQZEU0C70vqy1d/GeAFlOgu1Hkllf nw0hg7tdivxbXa2AqWCoPTTU0Iu/pBUfiMD5fyBrGgLLJWS6ky6Hix11yqo6S86/4R2YcHnEDhel X1xvjO2YkGDnWFOtWt0X1udFCVebv/Au2YMPn+JNA8nYfJwd3SBJTZgvKhdOhkb0PQChTSUvO38p OxoBhArFQa4tla5XWS/wMcFKU8paUWi/aGNmZVXvXVOS14qOgVZf/jAI2xAE+rTtOoq0XbZoaApA IG6jQV0QMkdamAFwLFZFLBzlEqooZXClJqdKvLpiqmxzsDlKHUxC0Yj0HAHUbHXWqHRKzlaarUKI VdOiXwivbvTV/wAIixrDNAWfwAMNn320wX0DCHyNVwqQAUsAqlUqgJiSAWWrHPnVVaQ/MbjYdCgD QL73AEZjPfm1Z7FT0NI1wnPRkBBi1BwpdmlkArT3AqLcmlmmVeXX+IARjvyH/pAAAALNfkz/ANIA AAXxD8wcTEsPDHukLz/OAAUIRbpLhAJxEssAxh4cX8G4jotvwnNu5/OAAfNvzNbXc7ksnsl/iWoo 9V19u3GLO/iH4eIqHlhOS9z+cAA+R/n1A7I+TujxHQcsJl6cBoYOogX2i5Rcdb1vbt/CAcldfUBO G5i6PEVF6FYKiUvRcewx0KNFKHs5dqgbf1W0LfhRi9nR0YafOTevSCT9fVjS44do0jhODFEpfaWh ql+fSIZT7PnsPEVDEt1DtD19mva5RJajYgEtXpNMn8Dr7tvvC4v2Gtd3TxXARRh5uh/viXDgGNp7 4flYVRpdGKvu8RUfj+Ew51Rp/ROjLh2hQ/dn4JlWtf2djx9+kFPsUgwBqKq9QKoZ1lJTm7S6Vd9c Xjxq69A28u/Dg8+4/wCPijkW/MeDwj1SraugfE8eZXZ9i+P4nWg3tboWfJxeHGNTVg2jRUfh/A+f Pnz54+zSDCGgqnSFdjGs/9oADAMBAAIRAxEAABCmRAgIekIC1gl6QyeBOyJ/SBsZs6hQRuK8WiQD hvCTCLpaCSRs+fyLAEL/ALEOnbr2yj822W2UhTT6bA/wWAyEiX77rEkkkktsoiCjsfulm8l9ukJ5 uetZ7Zp15N8juJfPtvQZB3PSJPbcZbCcuDJZZLPv/vr0beFvttuxfJJfHgiPJJqKvJMttptMttvm ACgCABDDADbieSnCSTCSTASL7oRyyeyT22wH7dAtQAoAAABMmNmvy2XiXS3VEHHQzANqQaDFdNFE gtZ8U2jZL9dDKaw5RwW1/tt3/9oACAEBAwE/ECHLOd5XPX5sjmLeFTfOhR1yCFCKhxKnwL6FcBRH mnJgUL0mqjqxcj2fCXWUJQWQYLex2XYXDRHrwPdSPxczpPa5v7wVcYPwziA0U6rxm2jXDfxDTwAA BgntXK8B4T1j4dbcKUFJzJfBqdqRS6EQvACdLzc74WrW7DFDVQU9QxcCmFe4U88AywBUN6H8S36s GK2xMwx0+rgfB2RBV6ltbzn8TdX/ADHWGKEAYMYdKhQoqwESTTorWi1BtpGobSmeE6edLCCmmww9 kUq0oslOdZX9M3PrpOf9Tf3mS+//AG7yudsS6gIsgUCIDhYN0D7AWDwFCs10m/rzpK/qZt3+zrSt cc57xH4jSMlIYLL1L+DCQ7j9X3A1kyUrdFCxeqkLCHtkzzErOhIaC4hTWBRNAHoAXoCsq/dvontx 1m/ndl7d1+c00DAVS211RNAnrN8q+aZYKlLQ7po1suBvoUYp8kPmoLCdKThLA9mb+fvMH41QSvnU CtRAMsvJq81eb6x0cdo9W7dFxqwkDYKwmC0y+xXRoQATfOnn91U3/cxVdpyVOf7nPnzNofo/tlo9 x+Z3tX+vu9Zs/PB0Atfr08VHym6Xr3j5m05YTdX9afrg3c/cGgBqs6BIDdBfIIfBd7X8W4uZqPBB 5GL+bdaZF9kDmE84PZ1VXkwfRNZAZLhQsuHWH9py056zffnabvHO8sFawdHvOXOsdrS/pxy8L1+3 9MfLcH41xnSwOUbJfCIBAUOVSi1OqGZWN54vT0HuIoKRRJQu6/X0m774L27/AGe7Om1FG7p3Zunl +eAVjTKBICE/AgnDyDODT5Z3gEyEgzjwIAAAAAGAlM5m74/qfKYXnn+rm6YU1WGxxzpPI/fLmPIx +HO83qeJUheg/T+p/wBc9bhh7EFeZUrXsypd1+f659tJu51ljrV+zlN42m6HTFa+puqvfnE3HzN1 n+bTdz2n/XO83dObm7Pe5vef8m7/AJpmcufabts+Zu5/qX/uv9Zt7Svbk/Ud3J+B/bLCvKPtXUpO 9A+P0Tn8zO1ocfJyfX+pu5+po/2McPfxLNpGlW5YaYAAAdAAD4nde/PtOXtmZ9Zu0mnnzKHWd18/ jrN03bTfpz1xOXJPZ8zzw/ykz6dOdpt3ma093hb+GIleodtQlA9i9qZvzpMq00V/unS609vxzd/2 bvbWGes68/fWZ9Z+0386/ucz3+5v8TfPbz1nPOO03zfzqzfnPv2/Mz6/fmeeE+v6TZ7c9YeHPLPB 0fhv3LBvUPkZQb0Dn6Tf9wW+w++BpVv40pv5x5m+b5v/AM+Jvrab/uImqAoMiUsEpdgj2nPbhD35 P3BTIFEORlywthjRrfz2m/5Z4vDv3vnrPLCfUJAnJF2AvAauAPECOn3qDXaFE35ajVmWrRvLSvUI 0Beh/H9U3/v4lsnaUWAuEaYXgNRUW1bFdZur3++H/Oeek3zfW+8EU4oIML+y2kATXmCU4LVhG8tM IBJKZjv7RgTPw6/80NE608FSK1b/AClCl2Z6ztG6upnrDhhBhHJvm/l1Cc/M58+Ji3V/gh2Gzgu4 jKURjfz/AJN/PJLgvUt8UqC9B+ufh7Tntib+fab5v57Tf/X+Tf8At5zH7w73FabpQLvGGlFw0oEL RMtNHg0Qe655aL4H5VdUEO5MzKvonAOk6SqWVM3TBNji5Lux533ieULbAWiFmtYJm3aTh6UAIWg3 L9+am/npN8EPuEJKUiCMSpARUo7pDqt5/wBzf94+pcN6n8xrHY9exbTnz4nTrDzL9/7ud63+f1oz fX+e/ab6Pj9vaeb2+/zN/PLHB6qMAZZ0QK4IC8EpREsgzZYXv+Y4qwKIZkSAhhHrB0c5Gw1IxQYW 5IU6bIqO4Iplp9onERheVRhnfcPv/wBZvxL8/mb/ADf+5ubpu3Ju69WXBev3wpO9C+Bm+b5z50mv X7m+fXr4m/t9/wDZv4aYGjif2K88BeGv678SZw1tyslpnxpMxowiTPuOWY9tR7BJpgwJA6ZyKQsM uHpsH6UAdnByonMd5u2apgBJJW7shA2U2G+2ibudpz56zfN034m+eTz2xLDvUvkIbQlWZG5MiXcv XkGxpRkd5vzz1xPnvOvPJ7azfj8eKmnXtz7Tn7z685h4Y6Oe7OVxQuZf+XeT53EIFDRqW3hyD1bE mbiaNxo11qjsjFZUK24EQk1fHIBEes35+GDtPR4bpgYisxE00HMnsAD5WUFq5WeLfPib+dZv57+0 31++bm+v1N/3N+vP5lh3qXyEuWtV+frjpaWfjp7cb23z31m+b+f8nbfPb6m+u03895v08/meLN/3 z1m/n7ni9pv05qb+dZ0znzvN/wB/8mfXnv3n1w9pvJv/AMlh3qfyfvLlrWU6Hd/Hyazfz8zf9zn0 m/8AE3k38/qdt8/qV7/vm5v+5v8Aub+m039Cb+/4/ub6/E38/ib/AOpv+Obn/ef6udt/1N/3PN9p vlg3qOt6yuEa/Y/bzHS7jxj++b+fedOa2h+Rti6otWLqrGpVqabQR2BXU1N/3Px5Pib5vm9/E3f1 w75vm/n9zn2m/npN87bl4OCxr4IV0UQleF4uQKAGDHhOuCXGVQAyq/cccpqVaLM2IsqWPu3zDFdx 8Q3c5m/nrOZWgg8cPGt02n/PLgm/n6m6b+fib5v5eDn+Ju5/c6c89Jv/AMm+b5vlz938amIpggYJ yANDDWATUaRUqe4AFV3NzEsYK2bYa8gFjKmJQlaJp2WXKtV3VPiYnSz06D+5u+57Jja7/Ef1D0Sw fmubvaX7/f3N03c6zdz8TfN03zdzn8Toz/c3fc3S2l+0/wAYlrnVMeZ7JTt153my5Q3b8xcvetej 3eY7S/p3u83VXNzdjnbtOqdlvYfmWXuPTv8A3Uy69+0bGs5fNs3dvvH7jawQOlWkU9SGy6lHccIZ ZQIYC2bp2Xz2n+vzMOdpu7nTtN34+n2m7+t7mrUfPPmb+dIKnRT/AIVPAqPhNn+V0lb1ovx4SXpW r6e99x1e/wBcd3P6m6eUjLYJR2LHO/N+J+3PfEyCDD0k2JGQA7yzlI/VLBGgi6DkqiB1Y1k5ppqp Xwf5o4MWrpAmJum7rw7ud5U3etPFFQqSM1DhCauZLs4gDTVIvujyxsKDFHSn2mQsd3EvXUnRpOrH Pz14a+yfn8y1aW3+YYTS1rb+6bqnPSYc1Hp2+eU0vILUkpWadKtiBuNR+Eo0igRMwjq5NRWpAAKs OwB0BSjZWEUWw1UY8Go2OC9e7dB5w80pJH6kgr2ZWELcKGECpoZbDbtzHVPrv0fTGlI3mqDf/b3+ 5zZj7VPg/eN+TqsBhPAqFCIAxHZ3VIFdN5GjfDOieqQMo0WOfLtNk2/ibOSVPWjfsh8HDNJw8rM6 EkcOVt4awADqs0e97vZ+05l6kHnjOGW0JEKoBaWnMP8AW50aDsF/g1Wk5XRsg2bXE/2I0aKuDisG 9CKINLfua7sfU/DBRKCBM88WAastrAR9XhJz7ZUVnsOZe8afI72hHYrSci4aAFAbLo5l6ZnmXvH+ Z2YOZfeTnH6jafNM/wCRTp0k2A7vk4eFGNGX/9oACAECAwE/ELktmPs0+/JhAAOEIuuh0KdG1r1P EgYg8JIYopqab/SQIGSBfLm2r9DjhChmEW+TjggbWrZq3545QoIiL6cbBgjxT1elLsEjt8U2vqEC kiqZXHYda/cYLloS+nB9p+ZRm2YcofeVI1+J4jy5aHB9J9l+eGXK7EDilprLl9ZnxQLOtEVxK4Wg cTbu3sRn6n0R0x5US+D7j8wyTuPALrXpLi/oZSVjVGE2NCOzubnYLBAo0Jq4mW9w6R07D9+iTi1H TrvxB8jFTeJlxDkwOj1/5ACkL+JjWvAgKwWAdC+C+DCarrfHB9n7mhT7FXDFRWWYiNOsVM88P0hz rvFjtwd3Wd3BauhcqtWuD7ekMlvxxv24BpR2lzJvxEBRxMlHQ9INo8R9OJ4TNbypTMbj4+mq1l1j iWazun29A8plPpw4cTRHMqVLrga4LgJUYrcGUf4wAPC1TIPSfmeYqr0StSVreJCeJqnb6U6iYaeP ROsFjTrirfaz5ODs9BpXaNBbpEHFsramKk4PgI1HVwa5leg24ExKAwKgZYKB0wtBBi3Ai2nQmldD TVrFgFHnMmiuia9jm8S0NMsDIqElEILpllEANdAWshhpgHcAOhGRCAyChSWILOpmhFw9Az2IoBv6 A5xMPDifeYcZt+sIvEzaplmVFCiuza6aqg3VVYHuJqMWXwiULommjJ32uW2awfNZmBYXXBhGBS1u q8+waoU3pVi3cGrMx4RaX64Kdah1B7BFoYBEAACtqQs0HU9BHUGuqRGQQGnvM5fjZ0/b143h6J4S +BYGUMrQe7p3gDaB6IUPTbJ1t4QDUNEbH3JU0FqLQtdAvV8axig0hGYrJIoiyUASyuNqaRpOj2fH Do4K8FOC0xXpMeGifSW9+IazSyTaSoUw2qAsCqaoAMUMWh0xLdR6ubwKFhQK4WCz16WwJEtgB6oY ouGZjLVEr7FJFhZNrA7LRZjgCcEVa2MC1yg5crAu2ACjbtSij5Lp4nZDg+HBZD1VOXqK2+SEmo6T 6cT7cGiUl0JqdAqgVXkKH0KIz9UKNwIs7Wt73NVFUIZjILNBNTJ1SwJFzQdJOlSigAZVQgXYwuwH rZuGNYqIrGZgpXCwa2Gluq71rUEbYbBYcYhggFAacNvfi/b0AsZfhvvycTu4PLg8Nf4yAPlPpxO6 XSYTt1yGT0Dw9QKcTTwHEeU7uIcAAJm65DJxB19uFRda6seutFCqNX2rp04CNX8gALFoF0mVPIwh Jtha1NTFHUffgu8QCa1F5A7dhkOhcMTXLtTiUU8QYL6IMPWB9uDT5n0h5joR/gdQarv/AGdfiUJ9 3dfIn9yyYrBoOtq612qt+FIxJVz2Ti5tE69WAaP4QAavIEqV8caRmSrkskOBk82Ha4QZTVwLbOwR Wuj0M9DtKEKi2KpK0y63O7gy9QDfKYJUqV8wRISN1zmSXwZvMq4mMXCHIzV0Wl+YCA8oRXizG61O 0XKwAqwBgLCY3hoFFsOR2dShToX6QBxXVdGhS69t/EAgFgRsTTDjI6n+cGaQQ3WiEJoB8ErMqVNF CEqVcpk4mTzFpah93Ue4oealkaBpHCPk8QlJRoDKvajvDzzv8J7FHtGZUaOt6LwBadbO0vtF+cg6 XUs7hkejKXzDKjebsIX4CKU9UC3aagcTPdwzsyh1X7HqdcdZ5wAqe5b6WFTl0FdxLyvlqjQ6ypUq VBCgty1bghApYFqFqWFeLN5NWk+zxk6xHQNQ8wE+XfGnCF9ZPyM0U+kYvA61pO9cNTnpdB01SV+F PfXhLzxeVjCs2qNS1fLvGi36D6tq0nxTvx06SK66UHLUCfKd63gtXe4C1PGVChJDlK3UkClIUqUt /9oACAEDAwE/EKLIGNoeSBq6FjgBIiRC1EwF6EekIuTUOrVgXCrbEJFqW6k7BB4ADoQ4QQn3C3Lq zosoaABgEStEsTzM+ksXvl2ORychUMoAuroO3ExcUTaADKLVXKqq54liyiFgOipF5DAunF48V+Qu VuUVfKrxLFirhHnnWdqnqWVmpk9ddbXQsCoEJxMkUKDHu2PxSNI6Qdrv+aOKwFq6b8uwXanZX4AN atFsy8jpDuPTuj4iGul2S6D5OtOVTS16ZM6OXcONugu+wMQiLgUs1akFpxxcT5reGJR2v9zn1LLR KxKDnkG6jC6GrxdFvRdDHXLN2DchmXsIKmHOXd0OgLYli4/UFGU9f2AgNHkl9h04MMedhcLfA+RD aJ0QYc0urAZDLMKK7uBR5JNVNH+vQy4lZt5zvXb3qdfwBoiv5BorqhuZ2hRdVW1d/QHT5LeJyp0m l51Acf7pFOBUU6/mV+gKLpbNY1U6qqixV0zVgjSB2Smu128sevRV4I6gAF60WmFTEqIuoA3tZ7hF +wAAMC0ulpw59KOi5reOK/PU0tCtgt5AcDAIlr4CZglIcs35LNneg9h0hWyA0R6/5qOGG7xkqHtA vfLfpAeaMMQAi0Xd3Sxq+PAfXxV6Vmi0cEVIqbV1Xu+oFA5LeP7b+KallZDg5HL9iCUPFi7rBc4w 1nMPu35/5dEKn2H743tf4oqSPY/BeJ57Sz8SU3hgIA0KE06XoRU2K6rr/L0fsN/fE9h/HNDTbuCP Ed/yILfhx/Tw4/yf/qPYfvgY9r/BNTwbU4TxXf8AEywePrP+kudXWL7X39HsRGqC1gW6L7tNbPbj 7eP4mEbE1SuCeUuAA7Wj8hCscjQPAUt6Shpdz8Htg0EwvTxGBUgyJm167+p4Ctslo1LdLRq2AsMW mDSzDmrOr18GIqBa4O5ZbUmC7mOBbVYQkmjajYNcRFhjV6wvMzq8k7iFWxPkxFUTcgtgaYWiHo/w sYpTQt5Ww+Kfnj1PHsX+Cv5zQcNM+0CtBhFbgCqBwZDyruyg1odEeCDC5CKLdAXd1a606Mw4oB36 oBq0C3biCj5pwjIcq7tIKujoFlMw9G4KB6OXpPZEslR8fy3wITVm3ZleOZElNSK3iBMbvHpSda3E P6+r6NIC0CtBa46BlehDsHk2FZdecTbHBWxHqBE3HJLNeCoWhVrWgWZcRXwzgXIEkRCSm6WVllAW JY6Jeo99OP8Af1fqaBevoz6fT4exsLCo5MBbMg2bGVUyOUFxeZSAoVlUQeroBiyGwp1yUdAFavoi TbH8AS0VTL4uNiUGGYBXAowVCygyRaGbtphknUXy6EUVFw0tUeGrP4O9SzKB2Hgg+BKf4P8AR2gA yGxoBidGL4MVC9aiFqVBZxQQqWDciiQLQCWjY4oISRLBKWLDLi1TsCliJwHQKwBE5iqAMCTTKVpC 3ZUuRBQ6a1gJrQBEjVJFpsU5e/n+D/Q8aoJQtdh+Gbf/ABf/AP8AH0epJVRxxs/xP/n/AP8A/wCh Y9ASxb7fieO0pgUEqyzIJaQdLZwASwxldU1D+f8A/wCpigWsAoaJ9xaaIhdI5GlXua9OFAZ0lpgE 5CRSK0vVCVDBzfb8Lx/HUio9v51/v1B2/OgqsVSadh7dx6PcsasU9MHsrPuEI1WqQh1ALl1VutA1 lwwaim+1+jCwqj5fz+bVVyuXoFxd5tARc16AAG6nl6QBGs0AAuVuLpaw2ViXIGjSsdbGR2FN+P4Q BAua3oFhx6g9NEgVFR8+MDlox1xLcQUQvWmABClUOLwP2oF1aw30SWqytbQq3pmHGgQOZevFBBMK F+kDzqcixFBG1pLwF9YhJTi1VlluEbEUdxCEtEF2Ar9EbEPkhf36FiZVZQvZPRxNLIgL3Im0U+xE BhCIiI5ETCOokVg5AAGVVwAaseK6l74TwuE1CjmH7J25CCo7lo6hVrwUnRPQBkOtLQNHyBNDsBim KqrWwlVcVCFDIchdXeSuuvEgFtSQOaDJkzkUXVoiKNI2NI17GVu7EdpRrbpbBGLC6XaFox6QvgSj LV0LN+gKURZYlV3lRwAzBqrTs8ZMlUSxB6FXQUt0Nmatiio1nHvP2vylzrea6nF/E1cFGCkhDc9m KcGVlNGhwkyVMfMBwcwKyHRRZmjSC782XHQBhXVS8V14ydLq5UBeikqsuTFYt9YpUKVChAoRluyF k9LCkAb0/9k= --_004_E045AECD98228444A58C61C200AE1BD8221CB0DAxmbrcdx01ciscoc_-- From abdussalambaryun@gmail.com Fri Oct 19 00:30:55 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 8265721F8584 for ; Fri, 19 Oct 2012 00:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 v8zleNWXj1Jg for ; Fri, 19 Oct 2012 00:30:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A942E21F8528 for ; Fri, 19 Oct 2012 00:30:54 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so172778vbb.31 for ; Fri, 19 Oct 2012 00:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u1vYf3ArIG0t3u9lCm/Xnl16p6sk9DCsSvByZfbb5wA=; b=fi0QQhlzEWk/P4lb5twMKUMmHs4WG3/VRdlV3sFY/4jxPMujZaPjSbNMXM7nyCIva6 AJ6mzfI+ItSdJPcxrzML8Bra0UsFR1fFvNwQRTwWxfKgVxjk+BwvUvO29MWqpxhCABB7 x09qqSPwxwWtu5aAwptgASy8N6AV20tK1kQW92hB/jqxVFmJpQhMvaVNNizLMIX+3+re CK/O/dUWblJEGk9+10Ge8OfcZJt+31PPVnhMmPf1MNs7Yx6ljILLIkbem9mwsgiJcF8q Nw+I2U+C9kIf+mL2fQlanmBiSnqNSTorRGW+URjzK4gmaHYH1xQKq+9Sa7xmBDCdzEqH v+Dg== MIME-Version: 1.0 Received: by 10.220.240.135 with SMTP id la7mr415138vcb.44.1350631854079; Fri, 19 Oct 2012 00:30:54 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Fri, 19 Oct 2012 00:30:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Oct 2012 09:30:54 +0200 Message-ID: From: Abdussalam Baryun To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 19 Oct 2012 07:30:55 -0000 Hi Pascal, Yes I have totally interest to continue this work, the concept/ideas are greate. I will review and comment when available, I hope we get discussion on list or in f2f meeting, I recommend you to present draft and list it in the f2f ROLL-Agenda, thanking you, AB On 10/18/12, Pascal Thubert (pthubert) wrote: > Hi > > When I started this draft, we had a series of chats with Brian Carpenter and > apparently reached a gentleman agreement that it was doable within the RPL > domain to use the flow label and avoid the Hop by Hop option. > > I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 > based on that discussion but did not get news from the group since then. > > This technique has a number of advantages, in particular > -it saves extra bytes for the RPL option and the HbH header. > -it also avoids the prescribed tunneling within the RPL domain for packets > from the outside. > - it has an optimized compression with 6LoWPAN. > > Is there interest in the group to continue? If so I'd be glad to have some > discussion time at the next meeting. > > Cheers, > > > > Pascal Thubert > IPv6 Engineering > > pthubert@cisco.com > Phone :+33 497 23 26 34 > Mobile :+33 619 98 29 85 > > > Cisco Systems > Village d'Entreprises Green Side bat. T3 > 400, Avenue Roumanille > 06410 Biot - Sophia Antipolis > France > Cisco.com > > [Description: Description: > http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg] > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by reply > e-mail and delete all copies of this message. > > > > From rute.sofia@ulusofona.pt Fri Oct 19 06:52: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 394C021F8696 for ; Fri, 19 Oct 2012 06:52:44 -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 rsuwBrH9OvPy for ; Fri, 19 Oct 2012 06:52:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C93CF21F8686 for ; Fri, 19 Oct 2012 06:52:42 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so229363bkc.31 for ; Fri, 19 Oct 2012 06:52:42 -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=0OWDhAe0kf3KQ8NkbtKpFZb2UTFTreC+qXARME3fGNI=; b=nv4dAAwGWKMQXVe0nzrNV4Pi7XmXHD3xA8S8/Nbn5mmLAESN9u4Yn7lL6qnEUSWV3p yyzCbGcm6Ti0t3LCSrNFGXtUx+RCZXYZmbM19KBwFfD1X4yuq4McNgKhPXpnSBY+mo/F X9vlsoV6E0VK2pd+sXaJ7yncDdtDU97T/JeXEz29xfmWQDV7dv6J+AD2zv+eoMn/XlzW 951DLZGUajSvzeIpG0jScV4KeGY3zNMk2ne0pKKSbj9LZpiEP4zvA301oloe028gcve3 iUxvC9w/VE7LfUK4Rywq0luUlnTvrGSUH5wjGSYQg7rGU6ZSmHrLNTd3hY5vUBY2jmVz Hzpw== Received: by 10.204.146.69 with SMTP id g5mr474642bkv.37.1350654761681; Fri, 19 Oct 2012 06:52:41 -0700 (PDT) Received: from linux-phf7.site (sitigate.ulusofona.pt. [193.137.75.158]) by mx.google.com with ESMTPS id v14sm1108275bkv.10.2012.10.19.06.52.39 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 06:52:40 -0700 (PDT) Message-ID: <50815A27.6010305@ulusofona.pt> Date: Fri, 19 Oct 2012 14:48:23 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Michael Richardson References: <507ED5CF.7040507@ulusofona.pt> <21203.1350504863@obiwan.sandelman.ca> <507F27CF.1080205@ulusofona.pt> <15562.1350651750@obiwan.sandelman.ca> In-Reply-To: <15562.1350651750@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnix2vykm57Hshayl4fkcapVXivP13mx0giIgPCEdBhmtaDroBC9h+Ntii7au00nBNtxSLS Cc: roll@ietf.org Subject: Re: [Roll] draft-ajunior-energy-awareness-00 (Energy-awareness metrics global applicability guidelines) 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, 19 Oct 2012 13:52:44 -0000 Dear Michael, there must be some confusion. I quite frankly do not understand why mentioning two other protocols as *applicability scenario* requires a revision by two other WGs. So would appreciate if you could be so kind to clarify this as we are not defining operational extensions for any protocol. We are explaining *how* these metrics can be used in the context of LLNs, derived from the experimentation that we have done before in a specific case of LLNs, namely, user-centric networks (UCNs). The metrics proposed are energy-aware - as far as I can see, this is relevant for ROLL as these metrics do show interesting improvements in terms of network lifetime, and at the same time, keep backward compatibility as they can be used for shortest-path computation. We have analysed the other ROLL documents thoroughly to understand if there was room and the need to propose this draft to this specific WG. This draft clearly fits this goal: "- Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs." As for MANETs (not sure what the other WG mentioned by you may be), there is no relation. the WG is currently dealing with *specific extensions* to multihop routing in the context of MANETs. In regards to RPL. The protocol holds a container for this type of metrics and as such, it is adequate to understand eventual improvements and operational implications that the metrics may have. We are willing to work in this direction if ROLL believes this could benefit the WG. And we can forward a specific presentation on this still for the IETF meeting, if that could assist in understanding better the proposal. If there are technical issues to be noted, we would be grateful to have them forwarded, and look also forward for any contributions that any element in ROLL may want to give, as a few have already provided. BR, Rute Sofia On 10/19/2012 02:02 PM, Michael Richardson wrote: >>>>>> "Rute" == Rute Sofia writes: > >> Wouldn't three documents make more sense? (Certainly ROLL couldn't > >> publish a document about AODV and vv) > > Rute> Hum, that was never an intention but we can indeed consider > Rute> deepening ROLL's > Rute> part. The metrics have indeed been validated by scientific > Rute> publications. Otherwise, we could not understand whether or not the > Rute> performance improvement was reasonable enough to consider operational > Rute> aspects, and implementation. > > The problem is: how can this document be adopted or published, when it > requires review by three WG? > -- Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for Technology Research Unit in Informatics Systems and Technologies (SITI) Coordinator of the Internet Architecture and Networking Lab (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: 217 515 500 Fax: 21 757 7006 ....................................................... From j.schoenwaelder@jacobs-university.de Fri Oct 19 07:16: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 6255221F85E7 for ; Fri, 19 Oct 2012 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.223 X-Spam-Level: X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 G6brJ75wKpyy for ; Fri, 19 Oct 2012 07:16:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3551421F84D8 for ; Fri, 19 Oct 2012 07:16:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C95620C05; Fri, 19 Oct 2012 16:16:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LYuej1Odhzph; Fri, 19 Oct 2012 16:16:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C848C20C04; Fri, 19 Oct 2012 16:16:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0D0862257FD4; Fri, 19 Oct 2012 16:16:06 +0200 (CEST) Date: Fri, 19 Oct 2012 16:16:06 +0200 From: Juergen Schoenwaelder To: roll@ietf.org Message-ID: <20121019141606.GC92253@elstar.local> Mail-Followup-To: roll@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Roll] [internet-drafts@ietf.org: I-D Action: draft-sehgal-roll-rpl-mib-05.txt] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:16:11 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here is another update of the RPL-MIB. This version closes all issues we were aware of. It would be nice to have some RPL experts to review the document. Like last time, the appendix contains a JSON serialization for those looking for an easy to read example. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --3lcZGd9BuhuYXNfi Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS02.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.318.4; Fri, 19 Oct 2012 16:08:04 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AAF120C05 for ; Fri, 19 Oct 2012 16:08:08 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 969F02D7 for ; Fri, 19 Oct 2012 16:08:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -4.142 X-Spam-Level: X-Spam-Status: No, score=-4.142 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.141, SPF_PASS=-0.001] autolearn=ham Authentication-Results: demetrius3.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id RVLoL6TW0HqZ for ; Fri, 19 Oct 2012 16:08:07 +0200 (CEST) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -7.6 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by atlas2a.jacobs-university.de (Postfix) with ESMTP for ; Fri, 19 Oct 2012 16:08:07 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF52221F86E0; Fri, 19 Oct 2012 07:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1350655660; bh=9XBRgHFDo7kr2tqe0fUY/LtePY5P5/FbcFuVnapDpwU=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=U6MZJ6Xf0jHeJMoDZhQr/CvMuPLRzZYoJu/pqeuqutgHau7aN5tF9CGwHGCxiEG8Z HWeIGxdw+0ec/HkFu4/Al/5iGf8KtS+vbuUaJ3J4Pcq+jV4mgMv29fdDVpoZCQwI8G j6byBpot61nHVjXLu9FsCCpvxtrnKtinWS7vMVTI= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E898A21F86BF for ; Fri, 19 Oct 2012 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 BmohsaILHMFy for ; Fri, 19 Oct 2012 07:07:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4721F8607 for ; Fri, 19 Oct 2012 07:07:35 -0700 (PDT) From: To: Subject: I-D Action: draft-sehgal-roll-rpl-mib-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019140735.4726.9820.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 07:07:35 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org Return-Path: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of Managed Objects for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) Author(s) : Kevin Korte Juergen Schoenwaelder Anuj Sehgal Tina Tsou Cathy Zhou Filename : draft-sehgal-roll-rpl-mib-05.txt Pages : 36 Date : 2012-10-19 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-sehgal-roll-rpl-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-sehgal-roll-rpl-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --3lcZGd9BuhuYXNfi-- From internet-drafts@ietf.org Fri Oct 19 10:19: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 DD2B621F8753; Fri, 19 Oct 2012 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 5bbQ9G7G5yJ5; Fri, 19 Oct 2012 10:19:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D95D21F875A; Fri, 19 Oct 2012 10:19:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019171938.9893.94358.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 10:19:38 -0700 Cc: roll@ietf.org Subject: [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: Fri, 19 Oct 2012 17:19:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : Multicast Protocol for Low power and Lossy Networks (MPL) Author(s) : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-02.txt Pages : 24 Date : 2012-10-19 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL forwarders in an MPL domain. MPL uses the Trickle algorithm to drive packet transmissions for both control and data-plane packets. Specific Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johui@cisco.com Fri Oct 19 10:31:54 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 4E75221F879D for ; Fri, 19 Oct 2012 10:31:54 -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 3ym9bXt82zT3 for ; Fri, 19 Oct 2012 10:31:53 -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 58BFC21F876B for ; Fri, 19 Oct 2012 10:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3768; q=dns/txt; s=iport; t=1350667913; x=1351877513; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=t1N5MJTzPkXmylOl1MFX6vjF9dJg9YJQ6e4jX30OLSI=; b=QoVb50H83Z46p5iU5lOnF6sy3XkEy7G83+35+YMPl0crvnqsWWDUERv9 hww50Efg22cS7Jy4oDD7YJR+53sRyuqC2vFJolu7FPzZKcDbjTwAVzM8f v7Af6E6q34NBJkPmRmYcjYpZmIUkPgcBQNrRWT5H+RWEVvqQK2xtHlMc0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADqOgVCtJV2c/2dsb2JhbABFwGuBCIIgAQEBAwEBAQEPASc0GwIBCCIUECcLJQIEEwgBGYdcBgucIqAli1gbhXRgA5cGjTaBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="133510386" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Oct 2012 17:31:53 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9JHVqQ6006465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Oct 2012 17:31:52 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; Fri, 19 Oct 2012 12:31:52 -0500 From: "Jonathan Hui (johui)" To: "roll@ietf.org" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Thread-Index: AQHNrh+gRb5TlPk7pUqtIMGVkE0DSw== Date: Fri, 19 Oct 2012 17:31:52 +0000 Message-ID: References: <20121019171938.9893.94358.idtracker@ietfa.amsl.com> In-Reply-To: <20121019171938.9893.94358.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--49.702800-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 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: Fri, 19 Oct 2012 17:31:54 -0000 ROLL WG, This update includes the new text that was sent out during the last IETF me= eting and incorporates comments received since then (special thanks to Robe= rt Cragie, Esko Dijk, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter v= an der Stok). The following are some open discussion items that were raised in the commen= ts. Would be great to hear your thoughts. 1) MPL multicast scope. The current draft allows the MPL multicast scope t= o be link-local scope or something larger. On one hand, fixing the MPL mul= ticast scope to be link-local reduces the number of options, makes things s= impler, and improves interoperability. On the other hand, doing so will mak= e IPv6-in-IPv6 encapsulation a MUST even when the source and destinations a= re all in the MPL domain. 2) The S field. The current draft includes an S field in the MPL Hop-by-Ho= p Option to indicate the length of the seed identifier. On one hand, the l= ength of the seed identifier may be inferred by the Opt Data Len field. On= the other hand, if any future specification wants to define additional fie= lds following the seed identifier field, that specification would need some= way to indicate the length of the seed identifier. The S field was origin= ally included to allow the possibility of something like sub-TLVs, that are= extensively used throughout RPL. 3) Supporting different Trickle parameter sets. The latest draft removes a= flag that indicates which of two parameter sets to use when disseminating = MPL multicast packets. We removed the flag in attempt to simplify the draf= t. Furthermore, it wasn't clear that a single flag (2 parameter sets) was = sufficient. 4) Version number field. The current draft does not include a version fiel= d in the MPL Hop-by-Hop Option. Instead, it sets all reserved bits to zero= and requires all devices that implement this draft to drop the message if = any of those bits are non-zero. -- Jonathan Hui On Oct 19, 2012, at 10:19 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. >=20 > Title : Multicast Protocol for Low power and Lossy Networks (M= PL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-02.txt > Pages : 24 > Date : 2012-10-19 >=20 > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to drive > packet transmissions for both control and data-plane packets. > Specific Trickle parameter configurations allow MPL to trade between > dissemination latency and transmission efficiency. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From osk@exegin.com Fri Oct 19 11:59: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 E968821F87E3 for ; Fri, 19 Oct 2012 11:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otiFKy1B3v2P for ; Fri, 19 Oct 2012 11:59:56 -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 5E7F821F87AC for ; Fri, 19 Oct 2012 11:59:56 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so597856pad.31 for ; Fri, 19 Oct 2012 11:59:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type:x-gm-message-state; bh=x7kXN8a8Za4718bKgnb651oQ8b81WiBCTqRDdafvVhU=; b=QFAaP+MnvishlmLlGElhdfGFjRpvVd+EwMEWpiYWCJG3E8o1jFAzyiHk6+9jygNNOn svBgnCUHuFKhrc4e2uUjs8xpq0izRjGnlTbjglCc58u0fvwfkciDFDEklmcSfQc83JV/ RNrMNk5Ynh7SY+df6WUbGDKZZTql3e/h161YsOfcNUpLDZY3G0k6x5okfwy/JNPQcIZp 0LJYk9mVkh4Xy9937dr/yhufp1XUwglBlUPIheA4gntaJfRxaT+ChR0i0LgQwGxZbxU3 kNGLfxN/fswC3FbidOMVFNiI8cEN/iSwd+c1kVdy00bcobldKa4rMWHSfvwSDH0ohRHf nKgg== Received: by 10.68.211.99 with SMTP id nb3mr8897079pbc.16.1350673195870; Fri, 19 Oct 2012 11:59:55 -0700 (PDT) Received: from [172.16.1.66] ([184.71.143.130]) by mx.google.com with ESMTPS id bf6sm1482173pab.3.2012.10.19.11.59.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 11:59:54 -0700 (PDT) Message-ID: <5081A327.9010505@exegin.com> Date: Fri, 19 Oct 2012 11:59:51 -0700 From: Owen Kirby Organization: Exegin Technologies Limited User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030008030709060604040502" X-Gm-Message-State: ALoCoQkgReI+D3/GHG6T9YPubag6VQZwxnfUQs9HonhuKZlWWfs3M1JS1C1azkQpyQzPphgrsF4U 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: Fri, 19 Oct 2012 18:59:59 -0000 This is a multi-part message in MIME format. --------------030008030709060604040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pascal, I'm not entirely convinced that using the flow label like this is a good idea. Using the flow labels to carry the RPL HbH information works on the premise that packets being routed through the RPL domain wouldn't otherwise use the flow label. This assumption might be correct in a network of homogenous nodes with no external prefixes (eg: appendix A.5), but there may still be cases where packets being routed through the RPL domain might want to set the flow label. If this draft were to go forward, I would have some questions: When a forwarding node receives a packet with the flow label set, how does it determine whether the flow label contains an identifier of the 5-tuple, or it contains the RPL HbH information? To get it wrong would interfere with the forwarding behavior and lead to interoperability issues. When packets are received from an external prefix, how does the ingress router handle the flow label? Would it destroy the original label, leave the original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the label (ie: the inner header contains the original flow label, and the outer header contains the HbH information)? How would the DODAG root rebuild the flow label from the 5-tuple if it encounters packets that have been fragmented at the IPv6 layer? The primary use of the flow label is so that routers don't have to reassemble IPv6 fragments when forwarding to determine the 5-tuple (which is a challenging thing for a router to do). Cheers, Owen On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: > > Hi > > When I started this draft, we had a series of chats with Brian > Carpenter and apparently reached a gentleman agreement that it was > doable within the RPL domain to use the flow label and avoid the Hop > by Hop option. > > I published > http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 > based on > that discussion but did not get news from the group since then. > > This technique has a number of advantages, in particular > > -it saves extra bytes for the RPL option and the HbH header. > > -it also avoids the prescribed tunneling within the RPL domain for > packets from the outside. > > - it has an optimized compression with 6LoWPAN. > > Is there interest in the group to continue? If so I'd be glad to have > some discussion time at the next meeting. > > Cheers, > > > Pascal Thubert > IPv6 Engineering > > pthubert@cisco.com > Phone :+33 497 23 26 34 > Mobile :+33 619 98 29 85 > > > > > Cisco Systems > Village d'Entreprises Green Side bat. T3 > 400, Avenue Roumanille > 06410 Biot - Sophia Antipolis > France > > Cisco.com > > > > Description: Description: > http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the > intended recipient (or authorized to receive for the recipient), > please contact the sender by reply e-mail and delete all copies of > this message. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------030008030709060604040502 Content-Type: multipart/related; boundary="------------070604000302060606040500" --------------070604000302060606040500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Pascal,

I'm not entirely convinced that using the flow label like this is a good idea. Using the flow labels to carry the RPL HbH information works on the premise that packets being routed through the RPL domain wouldn't otherwise use the flow label. This assumption might be correct in a network of homogenous nodes with no external prefixes (eg: appendix A.5), but there may still be cases where packets being routed through the RPL domain might want to set the flow label. If this draft were to go forward, I would have some questions:

When a  forwarding node receives a packet with the flow label set, how does it determine whether the flow label contains an identifier of the 5-tuple, or it contains the RPL HbH information? To get it wrong would interfere with the forwarding behavior and lead to interoperability issues.

When packets are received from an external prefix, how does the ingress router handle the flow label? Would it destroy the original label, leave the original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the label (ie: the inner header contains the original flow label, and the outer header contains the HbH information)?

How would the DODAG root rebuild the flow label from the 5-tuple if it encounters packets that have been fragmented at the IPv6 layer? The primary use of the flow label is so that routers don't have to reassemble IPv6 fragments when forwarding to determine the 5-tuple (which is a challenging thing for a router to do).

Cheers,
Owen

On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote:

Hi

 

When I started this draft, we had a series of chats with Brian Carpenter and apparently reached a gentleman agreement that it was doable within the RPL domain to use the flow label and avoid the Hop by Hop option.

 

I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on that discussion but did not get news from the group since then.

 

This technique has a number of advantages, in particular

-it saves extra bytes for the RPL option and the HbH header.

-it also avoids the prescribed tunneling within the RPL domain for packets from the outside.

- it has an optimized compression with 6LoWPAN.

 

Is there interest in the group to continue? If so I’d be glad to have some discussion time at the next meeting.

 

Cheers,

 

 


Pascal Thubert
IPv6 Engineering

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


Cisco Systems
Village d'Entreprises Green Side bat. T3
400, Avenue Roumanille
06410 Biot - Sophia Antipolis 
France

Cisco.com

Description: Description: http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg

For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

 

 



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

--------------070604000302060606040500 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4AJkFkb2JlAGTAAAAA AQMAFQQDBgoNAAASjAAAKQYAADhnAABO2P/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIB AgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IA EQgAtQDIAwERAAIRAQMRAf/EASsAAQACAwEBAQEAAAAAAAAAAAAHCAQFBgEDAgkBAQACAwEB AQEAAAAAAAAAAAAFBgMEBwECCAkQAAEDBAACCAUEAgMBAAAAAAARBAUBAgMGITUQEhMUNBUl JiAxMhYHMCMzF0A2IiQnKBEAAQIEAgMGEQYMBAcBAAAAAQIDEQQFBgASITETEEFRIrV2IDBh cbEycrIjc7MUdNQVNpaBkUJSNdZAocFigpLCM4OVFtfDNCV10aLSQ1MkJgcSAAAEAgMIDggF AwMFAAAAAAABAgMRBCESshAxQXHRE3N0IDBRYYGxwSJykjOT0zRAkaEyIyTUBfDC0hSUQlOz 8VIVYmPDRGQTAQACAQIFBAIDAQEAAAAAAAEAESExcRDwQVFhIIGRobHBMNHh8UD/2gAMAwEA AhEDEQAAAZ7/AFp/PaOrDT4Q1On6P4lLEbvHua+JusUf2/8AL6Dw9T5ucmkrYpXpU2N7/qvj fepu2+Yyxs8/FXY7unN/E0Oh+4e8MdQI9n6bHs/U4C0+s9TkgpU2KGKdRn6M+TJIman8Hhte m+ZGxO7x2UtiiincZ+jNR8yGd7qzrt8sljZoAqZHfoDl8c4Jj2uc26i6rxGGzx1PVWvOp2Ca djmknZ6P6VGj/wBCT9t8l7vLVea+JqtOl2uXtjnkubHPfj5lqDofofsvut2P3eNft8D0qro9 55n4m/SYtjnNr4quVQ0e/RHNwonbZ5XJOWliqmn3qxezxzoPuIA5/wCJaL8V65n4m9V878v7 HO5My0kAVi1O4c78TAlvPz61ERBRJg6DGc5Wovx3mZ83NpCyVB4rHr9vn/PyXe/UUA8QVh6n vPYuWMtA9HoB4rhg7NoPmWEp5KJaCIh8bHnjidq8Q/HQ+j9hu7+qqK64uxThk5fuvY0AAAAA QBj61o/JU8kr6pdmIWNxfjPG85WI0XXcI7s/a2MDzazmr6PTwHoPAegHiEHT9MkRIKo2Pg9T F+M8azlZ4D6tu0aPV/MAAAAAAAPTwiL76Hqvd8dt81iw0DixPjYjSbrXGZbJsPnT6P4hj0Hh 6P14/PoHn689/PvgPQI02Lrg+7W8xxe++YqaoHfxMexGc3WtFllcnzBtMeiABIsPYLXUPqdU L7yyO5evyLD2G1tD6lVK+csjqYr4A4bctO4xR3Q4IcSZCWXF+M8YzVcHh6eAFuKF1Lv4mdyP nJjfePgZWC7+Kncj4yY/3jj+VgqkX3lvp4c7vTO019HPw6gk6FseHj2Iwmq6AAAPp59SrB2W Jp2sfTz6EqQdliucrXz9+QAABKELYsT42Itma8AAAP6+cJ/TUHWOpfn3z5+/E7Vq4wzYKrM9 ftf8lO4/mvXZcAAAEow1h+u/8RHuw3xwZB4egAv5zPsUUTVd0WzqdDq7sywNogeyVCd63bv5 59Q4v5754egA8JUhrB0Nhh4VzaGojZAAAAAAAAAAASpDz/b2WsQVkwc7FTAAAAAAAAAAAlaH npMtVIr779cnEWAbTb0P0+dTqSIAB4egAHh6O/sFS5qMmtLpSQnTW2JEsFPrl5s8RDWh4ly1 891mtvRtXboAAAAAAJzu3LcfHm4GCte73IyfMP3le4Kz/EjH0HbxNlu5jqdaQims356A8PQA AACxF649kZMIeJJgrPk+4Ku4ZmNIC7Hk+3Lk2l1ZOHKv0cAd1L1XBxbXJxtgB4egHh7Zy/8A D8vJg8PSRoC0ZX1hqlrT8V1++ixl143o9SUg+q9QG924rspOtyFNVDQaUvBtU6iAOwkq7qNa Q02tJfb7xWx6FwH6fXwBI0Dasj3BUrUs8Q13oYs5eeIfb6xVfovcv08tLfOEx1DXGG630jf7 cTPFs5TEFc6Jw8XaBaS98Ky8mvENd6H3ktVJCmKgAJEgbVKVetlSsc3FEBfj2yNz4v2EjXY+ iLd9fr47uVqldad2PiYyznltOgfn+HK50eLoK9eFmbtxLqN+CeA9ACS65cP/2gAIAQEAAQUC 27b9n+5/u3aja943Rvngdp3yTcU2zabaSk/t7vBXf9+tr/YG+n9gb6f2Bvp/YG+mrbpuOdh9 27Ufdu1D7ft7te/2Bvp/YG+mqbtuTjD927Ufdu1Evvu845P+wN9P7A30i9x3+SeaXtOy4dj2 2vutTb7qVdaj4BRR/wCOatHD3LTUn1bHjB0wvNS5copIePMTVznNUw5sGBRSa5r0afbTttSr 7r2udYfeLmfjW9j53kfudV8Aoo/8drzWxtHKSzSj1jRi8upq2fqWKZctmHHnv7bPARtj9zbS 2yiiikxzTo1HhfqNfde//wC+IIaxwYqKPvGxVfTlFFH7Xt8ePZ3ltr+WeSFMTF5mprbfO3xq KKKS/MkENV4X6hX3ZuMBXPuzjW6dW/Hfiv1vgyUUeeLjK+nqKKKXQT/Jmj4G/HnVBRRRRSV5 gghrPC/T6+7dxr7uU2DHbRzr/Booo7p/2o6v/RUUUUUUUUUUUUkvHoIa7wu06vu7cq+71J3j lg+DVRTu7alyiiiiiiiiiiiikh41BCB4XabX3fudfeCkzxyRHBuoooooooooooooooo98Wgh DcK6ZX3hulfeKkpxvjOGBRRRRRTiiiinFFFFFFHfibbK3Vtjc1aMm17aul1947rX3ko7w35q tbLsWPrCiiimbV5pvrbizH/QdNXmq62ph1eaca3q9mOv4OYavNSUGoooo4p+8xspSiimlV95 btX3n1hRRRRRSd1/X2n4nls2P+gs9f8A5/w58VPwFg1/X7vxBE5sX9BarX/wnSc2K38O6dr+ vyWgqKKZbLq5G/8AxsUU0mvvPd6+9FFFFFFFFLetfW/dJe/UVLqX47raXXDHdJeO1W7rWiii iinWOsdY0ivvTeK+9VFFFFFFFNr2TD+For8Oy107+U/xPIa2x338txm6PJbdt4x/iHJ+JWkR KO9P3Vt+Yr3eHujvrCinWFFOsaPX3rvGNd0vpWwUUUUUUUiPzPG54PWPyGx1redZ2nVWMlv/ AOS7dsat/wA2QkrH6l+SXen7K+/N0Uxja3KKKKKKKKaNX3tu1PebvhVRRRRRRRRRRRRRRRRR RRRRTRa+991p7ykOFyiiiiiiiiiiiiiiiiiiiiimiV98bpT3jK8L1FMTRxmtztMrexRRRRRR RRRRRRRSkbgusetu63qKaMwc2brudPeE1wvUUjKKymuGBRRRRRRRRRRRRRTFT9ty1sc474h3 SrSJ7O7TKe8Nyp7vn+GRRSJ4sJ7g2UUUUUUUUUUUUUUw0/aQQQ02nu/cae7tk4ZVFIXjG7Hw aqKKKNIPO6wSkd5cKKKKKKKKYKfsoIIadT3duFPdu08MyikFxi9o4NFFGsc9e2M9bcXXVlYv BWcxWvmKiiijeEfusD1k4YZFMdt2XJZZ1LUEENPp7t2+nuzbeGZRTX+UzTG58xqttbaXX1iG VWLHaJDJbepHP8jBzn1+NdVnY/DGuFFIPlUjGYZHFfqr+l0Vr+NheggghqFPdm44dQv2namm k1zdy0I7loRAtdPpFd21MlG34z68W2/GnW7tqZsLPR6ynctCO5aEN22pd32lppNXXctCO5aE QrXT6RfdtTO7amd21M7tqZ3bUzu2pndtTNOw6hZtP//aAAgBAgABBQKKio3y3yuLMkXGlkVG 3HlUWXRMZU8sjTyyNPLI08sjTyyNMcXGJ5XFnlUWVjI1fLI08sjTHFxh5XFnlUWXRkb1vLI0 8sjS2Ljq1lYmN8tiuWGT54/l0V+dKKdnUrStOjH8uivz6MfTd9XRjJXlkXdTyzrUK1Us+XRX 52/Iu40SpZ8FtF+G759FhKcsjOW9Fvy6K/Ony6anXqVrWohb8Nfn0WEpyyLp6b1ei34KfCgn x1+fRaSnLIzlpUp/iUJPlsZy3/Hk+WxnLShX/EqSfLY3lxaXfGv6VOjrUK1JLl0by4trQuqv xWv29zy2tfuvvzfvhc/bWvH11fufK/bYXXwU+V/TJcujeXfG2eOr53BSv3Vb/td1K/dVzt15 /npX7qff7PJUrXYZB47wynTbWiX149Ely6O5f+gqFI/BR+UrSotDJH4Mr1V/RkeXx3L/ANBk 1u2DNPYaN4Wbxu8kZB5o/Hgj46s7ScyZ8ON9H3QNLL+vZ8cjy+Ow0rG32Vs/QzQOW1w7jMju OdtHmTFGRXcr7oBxhyvYqx80x6/myZf0JHl8Xyxz8/8AGkPARfLHXz/xpDwEXyx38+i3Fkvp fiux0/Wo2x1pmxdlXokW+SkdF8sefPobfwvPo/Wt+nJjpktq0ymJr1aynLIvlj359Db+F79H 61v09MpyyL5Y++roa/wPv4/gxtLslrjB2P6Nv09MryyK5Y/+roafwP8A+Posw5MlMbK9e8YL R1SmXF8FjXLfblxX4alKdatKJTpleWRXLJD6uhn4dzi7XEfMb4+yxPs1VMOWuK+9pgvHWG3D d0NfD5sNua2rDKuBpTFX4JXlcTfK0jX98h1us9Os9Gl8l2HaShnyOFwZHJ2kmO73/b9Z6dZ6 WZJPqvr5Dr9Z6dZ6Nskl2HaSh2kmdpKHaSZ2kodpKHaShLXytY3/2gAIAQMAAQUC2Cfm/O/P p0gJeWzYpXYZBjirPz1asdomW+Wkk/rTzGQPMZA8wkDzGQJ2ZmMTvz6dPPp0ayUjc28xkDzG QJ+Yl8OXz6dPPp0jpOSvZeYyB5jID6cfMm8Jsc5knZ7nhrtK9hsHi06Gnhc7jC2srsDXrNne B3abB4xOhp4Uvz4cRP5MeXKnRG+A6Nir+3A882CLd+cYYl5luat7GuGe8WINPCzGe7M8Qj89 WrqrptQncXWuQsx3ZL8VvZ4pZ7c1w1rW6qCCEd4Ho2H6YHnkjzDonPFIINfDP/GIIINM/ZX3 wbe6rWPbtC903xVmsuLNeggghH+C6J76YLnc5LdlKYZqq23232zPiUEG3h3vi0EEEKSjWzG7 lrb8Qgggggw8H0Tf0wdPW5ynrSERfXsZfxCCDf8AgeeKQQQQQQQQQQQQZeFFJjjSDp61N09Z QiuFkp/Ogh22bqiCCCCCCCCCCCDTwyikrxpCU9ZmqesoR3CyR45kEEEEEEEEEEEEEEEG3h1F JLjSFp6zNU9YQY8LXvHKgggggggggh1RBBBBDB/DW6lKVe46DnNbmIWnrEzT1dBvktx0z3Uy XoIIIIXxTyyOvst+xfK3nlyFkU8vjoyy37KwRTxwyQQQQw/xurq1EEIanq8xT1dBBBBBBB7H scWsOq2/Y9/+i2XW/Y9kexrqjWtv2PGf6VD1tpqcTHsXEGgghZdSlmbjcghD09Xl6erIIIII IIIUtrUrKOqxaFba0rS2tTDKOsEb1a0EEEEEEEEIinq0tT1VBBBBBBBCRfW6q31hxV3sWt5W OGZ2VtK5XMrLU1mut4W2fLGSlmz1yY+zyIIIIIIIRNPVZa9Ja2vWEEEEEEEG2zYb2rCYxMZZ i+j8WeYm/Mcdm0NXGGOm8kY+y7TgxYBBBBBBBCJp6pMV9Xb8aIIIIIIIIIIIIIIIIIIIIIIR VPVJmvq7PjRBBBBBBBBBBBBBBBBBBBBBCLp6nNV9YYcbUEL3GHHdiz2ZrkEEEEEEEEEEEEEK vctLm2bt7UEIl3hulZqvrMZxtQQe+JjeOVBBBBBBBBBBBBBC+v8Azw57sN9sjgrRw/69IWvr M3X1mJ42IISHi4njmQQQQQQQQQQQQQQyV/cUUUhK+szlfWoXjYghJeNhv50EEEHEpiwZWLzv gggggggghlr+4oopB19anK+twXHGghK+Og+LhBDO8bNrnEzhpbRg+ykXfVq6QQQQzSbXBlbO cLuxC+6mOy67rXKKKQdfW53nev8A8aCEvzCMdUauqJWlUtpIOaOnUG0trag8aWO8OKXe4KRb zI9xIISnj2b3IzyWzzStr+WvdWqKKKQXO5/HBXTUDjiqY+owOowJXFD9/wCxhBjhxdV9hwp2 MIRGOMox6jA6jAzYoTtYLHF0wdRgdRgSWKG792MIdjCHYwh2MIdjCHYwh2MIQGOCtmv/2gAI AQICBj8CYUphpS1NJUZqSRnEyidJjyzHdpyDy7HUTkHl2YdBOQeWY7tOQUS7EegnIPLs9ROQ eXY6icg8ux1E5B5dnqJyDy7HUTkHl2OonIPLMd2nIPLMd2nIPLsdROQeXY6icg8ux1E5B5dj qJyDyzHdpyDyzHdpyDy7HUTkHl2OonIPLsdROQQ/bs9ROQPqSw0laWlKIySRHEiiVJCX0Ddk vSJjQOWTEvoEWSuR2mG2zGgcsmJfQIsl6RMaBdkxL6BFkvSJjQLsmJfQIsl6RMaBdkxL6BFk vSJjQLsmJfQIsl6RMaBdkxL6FFkvSJjQrsmGNCiyW0qkCP5lKYn7MpBW5mvykP2EfmasbiZA z+ZUmJe3IYltzNeIESaz+O5e2ULr+hXZMMaFFktoflVn8sluJFDo5TDx4M0VlAVovykEngzX 5TCZSPyubjCG8dPrDJ4M0dlYltF4glD3uUxKsMn8FZ84oX/9C2h/QrsmGNCiyW00j/kednzT DeuRK8KQifVWzzZQLcw5dqf0K7JhjQosltLsxNuKJKToIsEeIuMIlyOJIUkvYYZKXJRtwKsR YuIPHJ5wnCKKkq3o3oBc5OuqrVoUYo+qm8Jb7YyuqS+aZ4oF6t0Nzko6qtWgZHhw+reBL3S2 h/QrsmJcy/sIsltKpj7c8bVa+VPJxBEkpz4iYRUdMYcIbRKPZtSCp37wW++vOTDl/wDG+FK+ 3TCmm1YKeQIYdV8ZsqFcFPrCVfcHzdbReKnl2l/QrsmJfQIskC9Hf0K7JiX0DdkgXo7+hXZM S+gbskCuxK8Iq2/CKL119X/ZXZMS+gbskCukCx7eWIVTFEBWWJjQOWTEvoG7JArpAse3li2E xoHLJiX0Ddkgm6QLHsa8YAqYx2ksWwmNA5ZMS2gbskE4rpAsd2KCoEXaEirEhXbphsa6YQMV V3KpXxDYTOgcsmJbQN2SCcV0hAveuUXwSTvjNFew3IleEb2IESb0LqRBQoMoCsqlexmdA5ZM Mlm2FJzSYfEUnmw5sSzSqYb4TWaZ71XhEOza7xXhjs2u8PwwVVpiGlV4I7FjvleAPisy1bTL j/gHwWZatplx/wAA7FjvleADrNtR0ivCHZtd4fhjs2u8PwwXwWL391XgAqzbN7+4rwiHZtd4 rwx2bXeK8MJg0xDSq8Edix3yvAHYsd8rwB2LHfK8Adix3yvAHYsd8rwB2LHfK8Adix3yvAD5 ZthKc0qPxFK5sOdAs0mmF6kf/9oACAEDAgY/AppCJp9DaH1oIkLUkiJKjSVCTIrxcI87N985 +oOG9MzCjrFfcWfKCJt93Pqvc9VG/fEf3s13q8oLPTMwtk78VqP1UiJPvQ6aso7d7rqyjt3u urKO3e66so7d7rqygktTcylNTA4ssJ7487N985+oedm+9c/UG1KfeM6hf1q3MY7d7rqyjt3u urKGyZmplJQO84suUedm+9c/UPOzfeufqDalzD5qNP8AvVlHbvddWUdu911ZQbxvPGeDnqv+ sS2cmXVIcfQk0mozTBSiSfNOi8dB3yE7rbv+RVxw8FbkCdHyndb6CeIZx44JECSurwCsyceO 4nR8p3W+gniufEUlOMw3m1ErmneutdG62nBExJa21/kSJp1sq6FTDh0b6zEDTVTumCZReIJ6 HKd1voFxA0/0IoLluJc/pjA8QgbiI4yCJlNLcIXCQj3jCW9wiIVWu1X7BWVSewb6N1rGrkEn rTVtIf0y7R3U9DlO630C4g50j2FRymXV7xfjcEUKUSfWKyKXN0xVcWkjxhGaUSoEd7Yt9G63 w8gk9aatpEy00mJk+u/0jEH00bwrppSYLocp3UdAuIOdLYpKJmqG4KktGseHZt9G63w8gk9a atpE5rTts7hoO8RgujyndR0S4gvpbajo3UcPIJPWmrZCb1p22dxWMF0ct2rWOqW3IxXUcIlN ZatkJvWXbZ3FYwXR9BTiup4RKay1bITesu2zuKBYvQU4hE7woiYKrgEprLVshNay5bO4ZKES 3Nkn7opPya1VSOOGnBwGEUU5/wDMY/5Sr8nXqxjybmC4r7olPyaFVTOOLBwkJ04U57wg59wa TGWa96nk2JAk4LsrrLdshNaw5bPaJaeaIv3q3YKON8ufgvUQLAJZMac+dpwI035zCkxpz/5i MLn4F++J6EY75UQxUiZTEo58rTYnNN4QnyMyjW4yTATs1MF8w2XNON6ij1nsC2ErrDdshNaw 5bPaaAX2jm/tiXWvc7FijvR37kDvigOfa0Vf2zqonRTgvdUsAp2mV1hu2QmdYctntLMpININ aipUeGGK+dO7QHZoygbiFnDGZCYObNKXjM6hqvRrHHhEuX3DNG0pVVK0RL3oX4n+N0Nfb/tz KKlSsZnjMsF86KTMTf3mZbrKaiok379ZRw36IEHft8+wmrUiRlgphh/qpoP2BTe4cNoltYbt kJrWHLZ7SmV+7S5P1Lx0cRlf38Ic+4oa+EutBBHCETLewB5yfl88hw4l/wBNJ5Q1LS7eZlWr xR4CxQCUfdpVLzyMNHEZUb+AOTLKC/bunSjejEob5YuALR9qlksPOX1UchUnubm0y2sN2iE1 rDlswfo8tp27RCa1ly2YP0eX06LRCb1l22YVdqqPnCqiO3mVF8U+8V2XQUY/uG7RCb1l22YV juq/GAH0dvPGKyRzokYqNXhKay1bITesu2zC8d1XBxBXR288ewlNZatkJzWnbZheMrq+DiCu hylsTaqmZkFc2FXaVYz2EprTVshOa07bUHMZXV8HEQV0OUrpIeVBRirLRU57BnKh0g2Xyq1y w7uxNpcaxbwrtXrhrV7pEDVu7CT1pq2kTmtO21BzGV1fBxECUvszoMRK8KyrwU4n3LxYgc2v 3owLLcNCvfwHuGKkSURboUp2FYlYLrmPkFdFJHfLdHOSslDNNlVZ9p7GT1pq2kTJk9NIVnl1 izKFlXrHWgefRRWjDm3g5mnpg6SvsoL/AM6h2jvdp8Udo73afFC678ySqLzCDwF/9BcQ8xNf x2/qh8pMTub1duHtmuIfOTE7m9Xbh7JqA8xNfx2/qgnNuvmmJ32klh0x8Y7R3u0+KO0d7tPi hXzE17x/+uj6kLzTz5lWwspLBp1DtHe7T4o7R3u0+KHK78ySo4GEHg1kuIeYmv46Pqh5ia/j o+qHmJr+Oj6oeYmv46Pqh5ia/jo+qHmJr+O39UPMTX8dH1QljN6aWrPIqlmUIKvWKrE8+uit CPNvD//aAAgBAQEGPwKvNNV6qyrMrVp+TYYk5+alGG2JSadl2QGZd1tvNs2xEwio6Tj3muD+ c1H1nEoJe77oYCmnCoM1+qtBRziBOSbEcKL173gJViBdhctZBWo9q0D55ojDT1MAC5rh0aON W6mo/KpU0VHCvNrwumWmUglss3DV20KI+g4hM2EwVw6xgg3td4IMCP6krOgjWP8AOY99ru+J Kz67j33u74krPrmPfa7viSs+uY99ru+JKz65h1b92XK+sTS0hT1dqjiobNowzLmiYace81wf zmo+sY95bg/nNR9ZxNpTet2pSmZfCUpuOsBKUh1QAAE5AADHvtd3xJWfXce+13fElZ9dxNmY u25nyl1sJL1eqjpSMp0DPNGGPea4P5zUfWce81wfzmo+s4nUN3ndjaEvqCUIuKrpSkaNCUpn AAMe+13fElZ9cx77Xd8SVn13DcsL4u9KTFbq/wCpKzxGk9sf85rOodU4t+WXcFbnWJiq0+Sf bqVUnqkh1mbmmpd7OicfeSVltwwMOKdIhi5ucFZ5RmdyUTvhhZPWU5o73D/CZtX4mmt2c9Km PKqwGZZouL34aAkfWWo6EjES/LBf1IuH/myY2cy0UR7VWtC+5UNB7O476WvyTO7O+lTHlVbk WZd50cLbS1j50g4m9s041mdRDaIUgmCDGAUBqjuz3j1fk3Z1e+lppI6y1KJ7zFs84aNyjLYu 5h1zzdxi56+ydr2qtnVZtGZK+1gYb+CQ+H1bzbHHJPddon58OTLugr7VI1IQO1QOsMO+lL8k 1uznpT/lVYbcA8JM+FcVvw07NPWSn8Z3H2ssXAkuM8IdQIph3Wr5cRTKTJHCGXP+nEzJLih1 Lm3CVDKopKUoVoOnilI+fcW64oJQ2kqUTvAYee1bV1xz9dRV+XClPiLEuEqUn/yLVHIg/m6C TgJQkJSnQEpAAA6gGgdBO+PV+Tdnu5l+y7i2OcNF5SlsXtzuuTlmc3XfSleTa3Zv0l/yisSf o6Ox0BcZ8HONAql306FhQ+gTvoc1EHRjK6wy4ofT4yPnAiOxjI6oIajHZN6Ek/nRJUqGMzUs 84n6yW1ZfkMIHE1tmnGszjcNokpJypVGEev0M545W7O9yx2XcWvziovKUti8nph7Ily67iWh DYirKqrzhSSo6BEdfBMs+SofQeA436aYQ+bCm3ElK0GCknWDh30lXk292a9Ie8orEp4hHY6F 0hDaE7ReUrcGkZjAjLmOrG0ndmpCNKW0nMFq3s2gcUfj6Ob8cfybs53LPZcxa/OKicpS2Lp5 x1vlOZ3GnBrca43VKDAH5sOekK7xvdmfHu+UViV8SjsdNmvGndmu5Z7LmLW5x0TlOWxdXOSu cpzW4x3Cu+wvx6u8RuqXsGs6jFSsgJJ4dPTpnxh3ZnrNdleLV5yUPlOVxdfOSu8qTW4z3Cuy ML8ce9R+Av8AjDuv9Zv9vFqc5aFypK4uznLXeVJrca7lXZwrxh71PRxhojCO9Hgjw9BGBgIA neiYwHXMOie7s4CUiJOoDGlSE9SJPYGHM5TxssMsd6PUHDi0+ctC5UlcXbzmr3Kk1uIKNMAR rhgpVoJVH8Q/4dFKXY5LoFFnptclLv7ZouKdbU+2SWAraJbLkq4mPCnqiMivIjMK+tYVlGYL 9ozbWcGEc2z4seDRhV2CXSaKmd8xU/tm9oHYhOcsxz7LaqCI/W3Jy7G5dBosjNok5h8vtBwO uLYbBSwVbRbYdmm0xA1q6hhfCyhBV7c7YpBV4NNuFvTr4hWYcEcVS4pSXQul0daUTrpfaS4l SshVs2VK2jgbS6kq6h6FzusKc3+1HW1n5920uc1B5UlcXdznr3Ks10i07glWGxXKhWHJecmh MuLceZHtnatljallIZVLMjQkFPy6bXRtEZ/b8ynJnTmzCpXA4U5YxiG1g9Y4kv8AfVcqzeJt BcRnVcCWwjMMxX7RlXsgGvNshm62J24yw2qvN11Esma84c2jaDMSzfmoYDgagZZRXpSVaY4u hG0bz+35ZGTOnPmNSt9wJyxjmLaSrrCOL5/31Xk7Zx/+hhTjaVCa1KWkHw0vINs6Cf8AuuAh PCcX5V6kwhdTpTSDTpgzDja5ZewU4yEtpcS2rziYGXjJObUOgXoOvgxA6OMfybtpc56DyrK4 u/nPX+VZvpMEpKjAmCQToSIqOjeAw1ZZTJ+yWZ4z6XAyvz4rK1u7FT222Ww2zhV+7zx+lDRu FC0qQoa0rBSodcHSMKypUrKkrVlBOVI1qVDUkR14qtoMJkzSqxNJnJlbjK1TiHR5oFBh0PJb Sh0STccyFatEMDMlScwCkxBEUnUoR1pPSbQ5z0DlWUxd/Oi4OVpvpNvUO26HIvzE9LLdnKjN ocCJpcpsUPOOLYLTs1NPOPE6VwZTlAECAKxWHGUS66nTqvOrYbJU20t+cknFIQTAlIJxc6q2 9JSs+4/Nook1UMiWGn/aD3nCG3HVJbbmnUlGXSlRAUkHTpthu53KI9JTU2qn0yrUZp9hs+fO yudE41NPuFtbaU50acpEeMd6jWta1vyGwVTm555+b2sHkmYeloFTCmXHp1RllKccWVdunRi+ r9qtNTOOUbb1STpoQl9DTkyKjUXyy24nK7MoSwG2SRxSY64Qrdr3Lbsm2yinuzspNS2Z1Uqg vMyvFdfSss1BBmEqQ4jKFZDxYYmZUrDhlph6XLie1XsXFN50/mqy9ItDnRb/ACtKYu8gw/8A qK/yrN9Jk6LfNqS1z+zQhMpOLEqtSktp2bZel5phSUTCWhlLqFeEGsayatdbFD/9GfRUGpak S7zMqmTanJhl5ttCkS5ayMJZhBKAMV6bue1/b8vVXtvKNbZCXJBZmJl5YSshBO0S8AYEdrij UikUkUGiUIhUlLpf2jxcbaDEuqLaW0MJlmRBCRmOknNiSYvmy5O4Z+npg1PZZNxLpgApxTE3 Lr83W7lG0CVFCzpyjQMVasU+QaXS6zMPrm6Kpeyb83VNOvyyWXW28rT0kl5SEHIUZVHi8E/L WRZ8rblQqkfOqgkSjezWQobZDMnLt+cPt7RWzK1BKDpynViJ0k6ST0iz+dNv8rSmLt5z17lW awjrH8Hs7nVb3K0pi7ec1e5UmsN9Y9kfg9m867e5Xk8XZzlrvKk1hnuVdkbudtEUnUcyRq0b 5wlbhTxjlgDEgwjwQ6egxWCUpJgRwdUHCYElCxoJ4RrG7ZrhCYC6beUoZtKQKtKExj1MXXzk rvKk1hjuF9kbrP6flFYa8d+wrp7fcJ70Y2a9G+lQ1pPDjiltY4c2X5wcBx9QUpOlKE9qDwqJ 14tTnLQuVJXF1c5K5ynNYl+4X3w3WP0/KKwz4/8AYX09rxaO9HQWrzkofKcri6ecdb5TmcSv i3O+Tuy/8Tyq8M+kf4a+hQ/tUNpc0pBCirLvHeGnDHhS7tQuPFywKMurSdBzdJZ8U33o6C1u cdE5TlsXTzirfKUziU8W53yd2W/i+Wcwx6T/AIbm6pyWZ2iUKyk5kJ40IwGZQjoOAudUlloa VISrM4ocERxEDqxwGfOmhk4oCApaUhOiGZCVJ0YRMyikv+bqKjszm8GocfVvpgD1uhbmGg3k cjli5BUASmJENURgNTAAKk5klJilQ6h0ajuIaRpU4tKEjqqMBhKfqpCfmEOgtfnFROUpbF0c 4q1ylM4k/FO98ndlf4vlnMONtiLrZDzQ+spEYp/SST8uCFAgjQQdBBGsEcOAlAKlKMEpSIkk 6gBvnDTK/wB6YuO9Ra/o/oiA+TCJBtRSjIHH4fTzE5UH80AR3EOpUdmSA839Fbf0ojhA1Y2o Qpor40WFZEmOmOQhSRHqYabYU4UuNZ/CEEghRTrAHBuyfi1eUXjZuxSpOlt1PbIJ19dJ3xiC HZdaPrFS0H5U5Fdk4D7y9vMDtICDbcdBKY6VK6vQ2vzionKUtivKFTuCWc9qz/nTSKHITrYn vOXfPdjMOXDT1qZMzmyRaEE8OJTb3BdLZ2bmXY2fSXweMnWV3zL5fx495bv+B6N/cLHvLd/w PRv7hYltlXblWjwsFOWpS2lnwy4xQm83gNP5xx9tXD8MU373Y/1CtVrbQ05LYkNv1M2wu7P+ tj/Tq1WdtDftiQ2/Vht7u2nzY+2rh+GKb97sP7a4rsQvKzxW7MpDqP3SYQWq/GSf1ce8t3/A 9G/uFj3lu/4Ho39wsMQrdxEbFuBNr00HtBrH9YGBxLbe4LpbOwMAzZ1JfBG0VrK76l4H5Dj3 lu/4Ho39wse8t3/A9G/uFiU2dcuRaMisqnLUpjaz4RetCbydCf1jj7auH4Ypv3ux9tXD8MU3 73Y+2rh+GKb97sfbVw/DFN+92Ptq4fhim/e7H21cPwxTfvdj7auH4Ypv3uxQVGp3BMue1ZHz VpdDkJJsz3nLXmW2mG7hqC0siZy54NGKeDH/2gAIAQEDAT8h3AIZonoDRFV4QikgBgAQoO8N YN6lel4SjIOijGKQAaGdwPlViyWzXrEfoYWZ8LBjIFRSGlH03Jt26LKAqJiCKmtM8YdQ3zcE F6AoDAcblxvOIIOq8L24xohZzF8KeAMHG7cCEgCNGkxWToUTrpVHjvSBq7QcZ4QnGXZAvdUA NWBXqlH4viEDCgqOhFYHzgtasA/dZiH9lRsmo+yQ+otWhzVvUdTR1OCr0qAsBFtQCtbCGXA9 PrLBEXEcm7cVj8zH9TwlkVdTYx5R1OqJ9ygJ3pCwIwd1imhQIU2ruprPVtjrjyCKlIrxMkiz 4vc4Oh1ItoXa5vxFei1TMa5gg9kdgIxa44CgiewO3d7HVmGNA9sZ7R0ZmGIDNfdFV1hXOBDt AQB6AbXkqKlcTuoPEEdPi2IVQfoXu9j0jrxcbUMtJooNqVOrrdoEA+DTNFoei2jtLX7oiuUV Cd2pyqQIoVzp6dF89g9JME1LTkHzkul1UCLwpUeANu9I4BJOB0ecxcQuZ9QPpXopbgR0Djq6 hDBZ9vW1w69dXiAAAAFAYANAOx6vi35a4j3j0KNjsCKqV6ijzcNiLiy7pZQPb+Wf/m/J+E4n vfoBdBvM/RFR4jhLYmKrmwaVcwAAUBgDAHQAx/L/APi05qOJ7r6ZVkiLOl/4W/8A/NryY4/v /wCbgQKeBn2T8SKj65/vUrrC4AXoUH0e7MyoWgpnQB13p9XxacmIvHGBay1N9yDw2H2xhRjs XfW6PQDkORRaCmpE1qGiI1EcU6mL9R5Cwy2sQZDO/QsKSzndLk0PzPFAZyErtGfSG7aVnhME 7x5hMIjo2LGFqS2Z0zV/edasF+7RCsCMg7Foh6PsfuoyjNs7AKNz9fyaGivzDOkgs10pjFtu GkcpCFoCljNa3RJm4xWbSrqLOF6a1vSM4JtKLAX5S16Cv1tYE0mGt2gmQiVjwJHngEe1WhaT GwnvgGs5n0Low12wnWFrGyU4xX9PRqtP8JX+Kiy0oxoFp2vQglGaJHxMC0MBwVgbhjRsBmBu dzTFcFI3BawXDHBklDQWKS10rB54K34IwMJh/wDH8JWx/vp1YtZVxTajInd7GChqerzHcT8h EAoHUxNYwwC9E9bFCbp0muLrvxn3MrhMZdoHSRWRYpnlwBIEkNWTOjVS2pko6lmbbHh/hbbG dAp3JKAo2Xj+D/SuHx3XLYl6vDgnINRS9FzbFVCp3cs4JHffrh6ZsOukIPjIrFgCO4aVZqQg e4IJuPmkp/x0MOsggEXf1tRAoeoYVKKFBVVtVcqv8X/XVfdvyE3/APo//wD/AKaH7/8A+jP/ AP8A/Uykz3zjmFupEs2tgGhJ1mlKwC8NB0/n/wD+5KIylCtUsyg3Zo2NToA1Y+/HrEZmiOAF OxZbCPf+J9g7w5LuP/A//wC2JrFfQj0dzudSUu54KVeDj2WXfYWSHQIa9qrgoWxL3/jubU+c 8P8A0X/+WdWHYDFiY+zel+mfXN1Ra6GzOkHAixT2qP6z/wCL+I+OlYNm1ALfhxljgnTQ1FgX WlxDFhEDKr0dbHxMeiC1lKoAVrAayo70es2oNQPp1gO8CzElBJ1uajmvtRwZBSa8JuUgZsn3 MEfIVsX6ejZP03T2cbebxkEkAfJxslwjo6gpCkD0gHaMF1BWow7apZnDXDCnEjNXVFAcdxGj Z24M5oey2horrXR95r08HuY06CWyDhElWDTs4gt4Aex0wRqwcVfJXRzL+84NDvjvaABQJZoq DKjVqo6dfUpG4o1a4lanwmgvU1rqsIZlih0AtxdOgkHs8E73B8cHtx7aJ9O0ig1RWj14XWuj g9Ssrj4678a4U99eLp11QRPmFEUNS2u8fR/WiIou6G5xdOgE7UGajqvt/APXr169evTlG/HE rU+E2F6j/9oACAECAwE/Ib5AQ4eAXVwaBgxwlhSimQzwWFBYXqYcGDDgyM9fjpYu47nHBgzB vjaWLvK9BgwZxwSQosvADqZLpMOOLvQn5eFzW3iKibEUzw/LLlzX34AukCDfHU3463g7rPWM nLFp+bhc1N4a82XBgngY68pcui45bhrOnC5cuavHrj9PQauXNSaUuXLmRjXgbJLMuXcvhcua 3Hqj4LM3hw0S5cdZoly5cuXuGeZcuXLly/SFFnJr4ly46w0ly5cuXLly5cuXLjr6WZwa+Ny+ Fy5cuXLly5cuXLl+lwZQa5lMJcuXLly5cuXLly5cuXLhp6Cgzl1zRNUuXLly5cpddZcuXLLr rLly5cuaOIDHLnHrgtYCxLly5cuJzpFTVNtdLpK871XbdH2sr5zvEzbbDTVb6XWdpcRnaKmq La6XSe21hMX+zL5ouILAs0111dC6aly5cuacWYuXHHlHLly5cuXLjdq1JQ6W6vPdz7THb/Qf yVwiXRaX9qPzjeHKrvApyZVfQa10mO3qPZ/ON4ud3gYDX6q/BrGKDsB1U5q+phxrLly5Q2kL T2ly4o45xcuXLly5cuIGVESdi7OkLqruita8XmXBLBhLVrOl+o5HcVdl9E83A6OkuXLly5cu XHPHILly5cuXLlyluWl1KC7ADtlat6soBl1aGEgaa1K1YZRm9TRTEECxyLjRQLvR66YOuYZy Uxh1WGIAGjmYAT0KlO00yvu00u2jEcBodBriirqzMxdVTW5cuXLly5cuOYMhSxmQW7ly5cuX LlzxMeNctK0vqMdHtmFDA2BF6s33mK9irGIMeK86xetN1RS263dtX6msgPFXi1mullh1dY2g B1W6FhclBc3YZncTUr8Wmhoui3uTwS5cuXLly4uABb6EuXLly5cuXLly5cuXLly5cuXLlx8I KX02XLly5cuXLly5cuXLly5cuXLly4+EFr6bLlys/wBIfqyy5cuXLly5cuXLly5cEuDUqdTJ fBsVV23A9Y7bLlz8n8s5Twy5cuXLly5cuXLly5c+gn2Z7QjqEqFFOnH37+uy5c/P/LOV8MuX Lly5cuXLly5cuXPrPV79/UZcufm/lnJ+GXLly4VoDA84ly5cuXLly59Z6nar7jhc/L/LOX8M uXH14PiOsHY6/wCR7Ndsn1DbFvTt1ly5cuB/cE6hElxh1DUoOw9StX95Llz8n8sZdNk9o2NO sLVZQ/lF3YUPVL/pwPb07kVxU7PqXc2tmXLn0P2zR0mj2gaN9x+pfrsdj1C2dkCow4AmG87e 2kXRMOifnjYcY71lqfV6X/PAVyUDx+UscgO9uCptDoaN071/HHHjwamkzq89jdfPGw4Q2anU +va/5/gFKhSoUKFEzIERlyBcujT30n//2gAIAQMDAT8h6of7e5hRbVrLa8IAAdRjMdLcahty wDWn087RUrXsZ8FYAO2Dx5TbHbR+4CSXpAABAAU6laMvUoOeOBI1Guq6tMvEAAJBV2cya0eM SIFxtq67rxAAGgdI1FoeHV8EN3r1Tix1mCzI3mGSVBJ1H6/1Lo9AcBUSu6/qSgv73wGqwFj7 /wClyi8GpoNzk4C9hwVTn3ZwapzwH5ZhgrLD18cFT6ni/fm+A/thkgvJTxZpNevS4WT1sNe2 r8Tyfj3XV56YhvYwrgXL9ETb0L8t1+g4LTU/ctfjX2iNJyusbMzOZLFT5t+OAsreg8z/AIxh UDpTIPYau+QPnpGiK6rl9Ax2cuXMpAR5zC5cF7XiC5Hogz+iFFk1Lonfw6hMyy9dMfB/7G6X cH26E8cLRfxKRK1a9U9IfRS5cz3ZGfDWX1wLCaNX6iKk7+n2f7hpQFjM9txBc70Q3vfSDwpN 0sNeamIHWRVHjy/W8RW3X1AVbCXLme56KGIye2P3Jlt+ILmuiC18v5QAFU18HzfoiOzfBvxB ex/PEKDHKC2JeX+UAB0HGfNfp6LuLfEvxOQd3/wgAA64s+R/T0RZG+QIeR6vrAvV9PQLVfT1 AdBFqaEaoBDSHVr5r0AJqwgWw5p+pAFlmguiPILK+55LY9KN0613vWNsQZEU0C70vqy1d/Ge AFlOgu1Hkllfnw0hg7tdivxbXa2AqWCoPTTU0Iu/pBUfiMD5fyBrGgLLJWS6ky6Hix11yqo6 S86/4R2YcHnEDhelX1xvjO2YkGDnWFOtWt0X1udFCVebv/Au2YMPn+JNA8nYfJwd3SBJTZgv KhdOhkb0PQChTSUvO38pOxoBhArFQa4tla5XWS/wMcFKU8paUWi/aGNmZVXvXVOS14qOgVZf /jAI2xAE+rTtOoq0XbZoaApAIG6jQV0QMkdamAFwLFZFLBzlEqooZXClJqdKvLpiqmxzsDlK HUxC0Yj0HAHUbHXWqHRKzlaarUKIVdOiXwivbvTV/wAIixrDNAWfwAMNn320wX0DCHyNVwqQ AUsAqlUqgJiSAWWrHPnVVaQ/MbjYdCgDQL73AEZjPfm1Z7FT0NI1wnPRkBBi1BwpdmlkArT3 AqLcmlmmVeXX+IARjvyH/pAAAALNfkz/ANIAAAXxD8wcTEsPDHukLz/OAAUIRbpLhAJxEssA xh4cX8G4jotvwnNu5/OAAfNvzNbXc7ksnsl/iWoo9V19u3GLO/iH4eIqHlhOS9z+cAA+R/n1 A7I+TujxHQcsJl6cBoYOogX2i5Rcdb1vbt/CAcldfUBOG5i6PEVF6FYKiUvRcewx0KNFKHs5 dqgbf1W0LfhRi9nR0YafOTevSCT9fVjS44do0jhODFEpfaWhql+fSIZT7PnsPEVDEt1DtD19 mva5RJajYgEtXpNMn8Dr7tvvC4v2Gtd3TxXARRh5uh/viXDgGNp74flYVRpdGKvu8RUfj+Ew 51Rp/ROjLh2hQ/dn4JlWtf2djx9+kFPsUgwBqKq9QKoZ1lJTm7S6Vd9cXjxq69A28u/Dg8+4 /wCPijkW/MeDwj1SraugfE8eZXZ9i+P4nWg3tboWfJxeHGNTVg2jRUfh/A+fPnz54+zSDCGg qnSFdjGs/9oADAMBAAIRAxEAABCmRAgIekIC1gl6QyeBOyJ/SBsZs6hQRuK8WiQDhvCTCLpa CSRs+fyLAEL/ALEOnbr2yj822W2UhTT6bA/wWAyEiX77rEkkkktsoiCjsfulm8l9ukJ5uetZ 7Zp15N8juJfPtvQZB3PSJPbcZbCcuDJZZLPv/vr0beFvttuxfJJfHgiPJJqKvJMttptMttvm ACgCABDDADbieSnCSTCSTASL7oRyyeyT22wH7dAtQAoAAABMmNmvy2XiXS3VEHHQzANqQaDF dNFEgtZ8U2jZL9dDKaw5RwW1/tt3/9oACAEBAwE/ECHLOd5XPX5sjmLeFTfOhR1yCFCKhxKn wL6FcBRHmnJgUL0mqjqxcj2fCXWUJQWQYLex2XYXDRHrwPdSPxczpPa5v7wVcYPwziA0U6rx m2jXDfxDTwAABgntXK8B4T1j4dbcKUFJzJfBqdqRS6EQvACdLzc74WrW7DFDVQU9QxcCmFe4 U88AywBUN6H8S36sGK2xMwx0+rgfB2RBV6ltbzn8TdX/ADHWGKEAYMYdKhQoqwESTTorWi1B tpGobSmeE6edLCCmmww9kUq0oslOdZX9M3PrpOf9Tf3mS+//AG7yudsS6gIsgUCIDhYN0D7A WDwFCs10m/rzpK/qZt3+zrStcc57xH4jSMlIYLL1L+DCQ7j9X3A1kyUrdFCxeqkLCHtkzzEr OhIaC4hTWBRNAHoAXoCsq/dvontx1m/ndl7d1+c00DAVS211RNAnrN8q+aZYKlLQ7po1suBv oUYp8kPmoLCdKThLA9mb+fvMH41QSvnUCtRAMsvJq81eb6x0cdo9W7dFxqwkDYKwmC0y+xXR oQATfOnn91U3/cxVdpyVOf7nPnzNofo/tlo9x+Z3tX+vu9Zs/PB0Atfr08VHym6Xr3j5m05Y TdX9afrg3c/cGgBqs6BIDdBfIIfBd7X8W4uZqPBB5GL+bdaZF9kDmE84PZ1VXkwfRNZAZLhQ suHWH9py056zffnabvHO8sFawdHvOXOsdrS/pxy8L1+39MfLcH41xnSwOUbJfCIBAUOVSi1O qGZWN54vT0HuIoKRRJQu6/X0m774L27/AGe7Om1FG7p3Zunl+eAVjTKBICE/AgnDyDODT5Z3 gEyEgzjwIAAAAAGAlM5m74/qfKYXnn+rm6YU1WGxxzpPI/fLmPIx+HO83qeJUheg/T+p/wBc 9bhh7EFeZUrXsypd1+f659tJu51ljrV+zlN42m6HTFa+puqvfnE3HzN1n+bTdz2n/XO83dOb m7Pe5vef8m7/AJpmcufabts+Zu5/qX/uv9Zt7Svbk/Ud3J+B/bLCvKPtXUpO9A+P0Tn8zO1o cfJyfX+pu5+po/2McPfxLNpGlW5YaYAAAdAAD4nde/PtOXtmZ9Zu0mnnzKHWd18/jrN03bTf pz1xOXJPZ8zzw/ykz6dOdpt3ma093hb+GIleodtQlA9i9qZvzpMq00V/unS609vxzd/2bvbW Ges68/fWZ9Z+0386/ucz3+5v8TfPbz1nPOO03zfzqzfnPv2/Mz6/fmeeE+v6TZ7c9YeHPLPB 0fhv3LBvUPkZQb0Dn6Tf9wW+w++BpVv40pv5x5m+b5v/AM+Jvrab/uImqAoMiUsEpdgj2nPb hD35P3BTIFEORlywthjRrfz2m/5Z4vDv3vnrPLCfUJAnJF2AvAauAPECOn3qDXaFE35ajVmW rRvLSvUI0Beh/H9U3/v4lsnaUWAuEaYXgNRUW1bFdZur3++H/Oeek3zfW+8EU4oIML+y2kAT XmCU4LVhG8tMIBJKZjv7RgTPw6/80NE608FSK1b/AClCl2Z6ztG6upnrDhhBhHJvm/l1Cc/M 58+Ji3V/gh2Gzgu4jKURjfz/AJN/PJLgvUt8UqC9B+ufh7Tntib+fab5v57Tf/X+Tf8At5zH 7w73FabpQLvGGlFw0oELRMtNHg0Qe655aL4H5VdUEO5MzKvonAOk6SqWVM3TBNji5Lux533i eULbAWiFmtYJm3aTh6UAIWg3L9+am/npN8EPuEJKUiCMSpARUo7pDqt5/wBzf94+pcN6n8xr HY9exbTnz4nTrDzL9/7ud63+f1ozfX+e/ab6Pj9vaeb2+/zN/PLHB6qMAZZ0QK4IC8EpREsg zZYXv+Y4qwKIZkSAhhHrB0c5Gw1IxQYW5IU6bIqO4Iplp9onERheVRhnfcPv/wBZvxL8/mb/ ADf+5ubpu3Ju69WXBev3wpO9C+Bm+b5z50mvX7m+fXr4m/t9/wDZv4aYGjif2K88BeGv678S Zw1tyslpnxpMxowiTPuOWY9tR7BJpgwJA6ZyKQsMuHpsH6UAdnByonMd5u2apgBJJW7shA2U 2G+2ibudpz56zfN034m+eTz2xLDvUvkIbQlWZG5MiXcvXkGxpRkd5vzz1xPnvOvPJ7azfj8e KmnXtz7Tn7z685h4Y6Oe7OVxQuZf+XeT53EIFDRqW3hyD1bEmbiaNxo11qjsjFZUK24EQk1f HIBEes35+GDtPR4bpgYisxE00HMnsAD5WUFq5WeLfPib+dZv57+031++bm+v1N/3N+vP5lh3 qXyEuWtV+frjpaWfjp7cb23z31m+b+f8nbfPb6m+u03895v08/meLN/3z1m/n7ni9pv05qb+ dZ0znzvN/wB/8mfXnv3n1w9pvJv/AMlh3qfyfvLlrWU6Hd/Hyazfz8zf9zn0m/8AE3k38/qd t8/qV7/vm5v+5v8Aub+m039Cb+/4/ub6/E38/ib/AOpv+Obn/ef6udt/1N/3PN9pvlg3qOt6 yuEa/Y/bzHS7jxj++b+fedOa2h+Rti6otWLqrGpVqabQR2BXU1N/3Px5Pib5vm9/E3f1w75v m/n9zn2m/npN87bl4OCxr4IV0UQleF4uQKAGDHhOuCXGVQAyq/cccpqVaLM2IsqWPu3zDFdx 8Q3c5m/nrOZWgg8cPGt02n/PLgm/n6m6b+fib5v5eDn+Ju5/c6c89Jv/AMm+b5vlz938amIp ggYJyANDDWATUaRUqe4AFV3NzEsYK2bYa8gFjKmJQlaJp2WXKtV3VPiYnSz06D+5u+57Jja7 /Ef1D0SwfmubvaX7/f3N03c6zdz8TfN03zdzn8Toz/c3fc3S2l+0/wAYlrnVMeZ7JTt153my 5Q3b8xcvetej3eY7S/p3u83VXNzdjnbtOqdlvYfmWXuPTv8A3Uy69+0bGs5fNs3dvvH7jawQ OlWkU9SGy6lHccIZZQIYC2bp2Xz2n+vzMOdpu7nTtN34+n2m7+t7mrUfPPmb+dIKnRT/AIVP AqPhNn+V0lb1ovx4SXpWr6e99x1e/wBcd3P6m6eUjLYJR2LHO/N+J+3PfEyCDD0k2JGQA7yz lI/VLBGgi6DkqiB1Y1k5ppqpXwf5o4MWrpAmJum7rw7ud5U3etPFFQqSM1DhCauZLs4gDTVI vujyxsKDFHSn2mQsd3EvXUnRpOrHPz14a+yfn8y1aW3+YYTS1rb+6bqnPSYc1Hp2+eU0vILU kpWadKtiBuNR+Eo0igRMwjq5NRWpAAKsOwB0BSjZWEUWw1UY8Go2OC9e7dB5w80pJH6kgr2Z WELcKGECpoZbDbtzHVPrv0fTGlI3mqDf/b3+5zZj7VPg/eN+TqsBhPAqFCIAxHZ3VIFdN5Gj fDOieqQMo0WOfLtNk2/ibOSVPWjfsh8HDNJw8rM6EkcOVt4awADqs0e97vZ+05l6kHnjOGW0 JEKoBaWnMP8AW50aDsF/g1Wk5XRsg2bXE/2I0aKuDisG9CKINLfua7sfU/DBRKCBM88WAast rAR9XhJz7ZUVnsOZe8afI72hHYrSci4aAFAbLo5l6ZnmXvH+Z2YOZfeTnH6jafNM/wCRTp0k 2A7vk4eFGNGX/9oACAECAwE/ELktmPs0+/JhAAOEIuuh0KdG1r1PEgYg8JIYopqab/SQIGSB fLm2r9DjhChmEW+TjggbWrZq3545QoIiL6cbBgjxT1elLsEjt8U2vqECkiqZXHYda/cYLloS +nB9p+ZRm2YcofeVI1+J4jy5aHB9J9l+eGXK7EDilprLl9ZnxQLOtEVxK4WgcTbu3sRn6n0R 0x5US+D7j8wyTuPALrXpLi/oZSVjVGE2NCOzubnYLBAo0Jq4mW9w6R07D9+iTi1HTrvxB8jF TeJlxDkwOj1/5ACkL+JjWvAgKwWAdC+C+DCarrfHB9n7mhT7FXDFRWWYiNOsVM88P0hzrvFj twd3Wd3BauhcqtWuD7ekMlvxxv24BpR2lzJvxEBRxMlHQ9INo8R9OJ4TNbypTMbj4+mq1l1j iWazun29A8plPpw4cTRHMqVLrga4LgJUYrcGUf4wAPC1TIPSfmeYqr0StSVreJCeJqnb6U6i YaePROsFjTrirfaz5ODs9BpXaNBbpEHFsramKk4PgI1HVwa5leg24ExKAwKgZYKB0wtBBi3A i2nQmldDTVrFgFHnMmiuia9jm8S0NMsDIqElEILpllEANdAWshhpgHcAOhGRCAyChSWILOpm hFw9Az2IoBv6A5xMPDifeYcZt+sIvEzaplmVFCiuza6aqg3VVYHuJqMWXwiULommjJ32uW2a wfNZmBYXXBhGBS1uq8+waoU3pVi3cGrMx4RaX64Kdah1B7BFoYBEAACtqQs0HU9BHUGuqRGQ QGnvM5fjZ0/b143h6J4S+BYGUMrQe7p3gDaB6IUPTbJ1t4QDUNEbH3JU0FqLQtdAvV8axig0 hGYrJIoiyUASyuNqaRpOj2fHDo4K8FOC0xXpMeGifSW9+IazSyTaSoUw2qAsCqaoAMUMWh0x LdR6ubwKFhQK4WCz16WwJEtgB6oYouGZjLVEr7FJFhZNrA7LRZjgCcEVa2MC1yg5crAu2ACj btSij5Lp4nZDg+HBZD1VOXqK2+SEmo6T6cT7cGiUl0JqdAqgVXkKH0KIz9UKNwIs7Wt73NVF UIZjILNBNTJ1SwJFzQdJOlSigAZVQgXYwuwHrZuGNYqIrGZgpXCwa2Gluq71rUEbYbBYcYhg gFAacNvfi/b0AsZfhvvycTu4PLg8Nf4yAPlPpxO6XSYTt1yGT0Dw9QKcTTwHEeU7uIcAAJm6 5DJxB19uFRda6seutFCqNX2rp04CNX8gALFoF0mVPIwhJtha1NTFHUffgu8QCa1F5A7dhkOh cMTXLtTiUU8QYL6IMPWB9uDT5n0h5joR/gdQarv/AGdfiUJ93dfIn9yyYrBoOtq612qt+FIx JVz2Ti5tE69WAaP4QAavIEqV8caRmSrkskOBk82Ha4QZTVwLbOwRWuj0M9DtKEKi2KpK0y63 O7gy9QDfKYJUqV8wRISN1zmSXwZvMq4mMXCHIzV0Wl+YCA8oRXizG61O0XKwAqwBgLCY3hoF FsOR2dShToX6QBxXVdGhS69t/EAgFgRsTTDjI6n+cGaQQ3WiEJoB8ErMqVNFCEqVcpk4mTzF pah93Ue4oealkaBpHCPk8QlJRoDKvajvDzzv8J7FHtGZUaOt6LwBadbO0vtF+cg6XUs7hkej KXzDKjebsIX4CKU9UC3aagcTPdwzsyh1X7HqdcdZ5wAqe5b6WFTl0FdxLyvlqjQ6ypUqVBCg ty1bghApYFqFqWFeLN5NWk+zxk6xHQNQ8wE+XfGnCF9ZPyM0U+kYvA61pO9cNTnpdB01SV+F PfXhLzxeVjCs2qNS1fLvGi36D6tq0nxTvx06SK66UHLUCfKd63gtXe4C1PGVChJDlK3UkClI UqUt/9oACAEDAwE/EKLIGNoeSBq6FjgBIiRC1EwF6EekIuTUOrVgXCrbEJFqW6k7BB4ADoQ4 QQn3C3LqzosoaABgEStEsTzM+ksXvl2ORychUMoAuroO3ExcUTaADKLVXKqq54liyiFgOipF 5DAunF48V+QuVuUVfKrxLFirhHnnWdqnqWVmpk9ddbXQsCoEJxMkUKDHu2PxSNI6Qdrv+aOK wFq6b8uwXanZX4ANatFsy8jpDuPTuj4iGul2S6D5OtOVTS16ZM6OXcONugu+wMQiLgUs1akF pxxcT5reGJR2v9zn1LLRKxKDnkG6jC6GrxdFvRdDHXLN2DchmXsIKmHOXd0OgLYli4/UFGU9 f2AgNHkl9h04MMedhcLfA+RDaJ0QYc0urAZDLMKK7uBR5JNVNH+vQy4lZt5zvXb3qdfwBoiv 5BorqhuZ2hRdVW1d/QHT5LeJyp0ml51Acf7pFOBUU6/mV+gKLpbNY1U6qqixV0zVgjSB2Smu 128sevRV4I6gAF60WmFTEqIuoA3tZ7hF+wAAMC0ulpw59KOi5reOK/PU0tCtgt5AcDAIlr4C ZglIcs35LNneg9h0hWyA0R6/5qOGG7xkqHtAvfLfpAeaMMQAi0Xd3Sxq+PAfXxV6Vmi0cEVI qbV1Xu+oFA5LeP7b+KallZDg5HL9iCUPFi7rBc4w1nMPu35/5dEKn2H743tf4oqSPY/BeJ57 Sz8SU3hgIA0KE06XoRU2K6rr/L0fsN/fE9h/HNDTbuCPEd/yILfhx/Tw4/yf/qPYfvgY9r/B NTwbU4TxXf8AEywePrP+kudXWL7X39HsRGqC1gW6L7tNbPbj7eP4mEbE1SuCeUuAA7Wj8hCs cjQPAUt6Shpdz8Htg0EwvTxGBUgyJm167+p4Ctslo1LdLRq2AsMWmDSzDmrOr18GIqBa4O5Z bUmC7mOBbVYQkmjajYNcRFhjV6wvMzq8k7iFWxPkxFUTcgtgaYWiHo/wsYpTQt5Ww+Kfnj1P HsX+Cv5zQcNM+0CtBhFbgCqBwZDyruyg1odEeCDC5CKLdAXd1a606Mw4oB36oBq0C3biCj5p wjIcq7tIKujoFlMw9G4KB6OXpPZEslR8fy3wITVm3ZleOZElNSK3iBMbvHpSda3EP6+r6NIC 0CtBa46BlehDsHk2FZdecTbHBWxHqBE3HJLNeCoWhVrWgWZcRXwzgXIEkRCSm6WVllAWJY6J eo99OP8Af1fqaBevoz6fT4exsLCo5MBbMg2bGVUyOUFxeZSAoVlUQeroBiyGwp1yUdAFavoi TbH8AS0VTL4uNiUGGYBXAowVCygyRaGbtphknUXy6EUVFw0tUeGrP4O9SzKB2Hgg+BKf4P8A R2gAyGxoBidGL4MVC9aiFqVBZxQQqWDciiQLQCWjY4oISRLBKWLDLi1TsCliJwHQKwBE5iqA MCTTKVpC3ZUuRBQ6a1gJrQBEjVJFpsU5e/n+D/Q8aoJQtdh+Gbf/ABf/AP8AH0epJVRxxs/x P/n/AP8A/wChY9ASxb7fieO0pgUEqyzIJaQdLZwASwxldU1D+f8A/wCpigWsAoaJ9xaaIhdI 5GlXua9OFAZ0lpgE5CRSK0vVCVDBzfb8Lx/HUio9v51/v1B2/OgqsVSadh7dx6PcsasU9MHs rPuEI1WqQh1ALl1VutA1lwwaim+1+jCwqj5fz+bVVyuXoFxd5tARc16AAG6nl6QBGs0AAuVu Lpaw2ViXIGjSsdbGR2FN+P4QBAua3oFhx6g9NEgVFR8+MDlox1xLcQUQvWmABClUOLwP2oF1 aw30SWqytbQq3pmHGgQOZevFBBMKF+kDzqcixFBG1pLwF9YhJTi1VlluEbEUdxCEtEF2Ar9E bEPkhf36FiZVZQvZPRxNLIgL3Im0U+xEBhCIiI5ETCOokVg5AAGVVwAaseK6l74TwuE1CjmH 7J25CCo7lo6hVrwUnRPQBkOtLQNHyBNDsBimKqrWwlVcVCFDIchdXeSuuvEgFtSQOaDJkzkU XVoiKNI2NI17GVu7EdpRrbpbBGLC6XaFox6QvgSjLV0LN+gKURZYlV3lRwAzBqrTs8ZMlUSx B6FXQUt0Nmatiio1nHvP2vylzrea6nF/E1cFGCkhDc9mKcGVlNGhwkyVMfMBwcwKyHRRZmjS C782XHQBhXVS8V14ydLq5UBeikqsuTFYt9YpUKVChAoRluyFk9LCkAb0/9k= --------------070604000302060606040500-- --------------030008030709060604040502-- From pal@cs.stanford.edu Fri Oct 19 13:08: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 BEF6521F87FE for ; Fri, 19 Oct 2012 13:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlWm8s4TbcKA for ; Fri, 19 Oct 2012 13:08:19 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id F11E721F8200 for ; Fri, 19 Oct 2012 13:08:18 -0700 (PDT) Received: from dn0a21026c.sunet ([10.33.2.108]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TPIrd-0006hK-Fg; Fri, 19 Oct 2012 13:08:16 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <5081A327.9010505@exegin.com> Date: Fri, 19 Oct 2012 12:46:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5081A327.9010505@exegin.com> To: Owen Kirby X-Mailer: Apple Mail (2.1278) X-Scan-Signature: 8ab272620d4bdfee2f14268d9892c5ce 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: Fri, 19 Oct 2012 20:08:20 -0000 I realize there's a lot of pressure for this in terms of header sizes, = but this seems like exactly the kind of engineering hack/optimization = that has painful long-term implications. Such as the Internet of Things = prevents the flow label from ever being used effectively. Phil On Oct 19, 2012, at 11:59 AM, Owen Kirby wrote: > Pascal, >=20 > I'm not entirely convinced that using the flow label like this is a = good idea. Using the flow labels to carry the RPL HbH information works = on the premise that packets being routed through the RPL domain wouldn't = otherwise use the flow label. This assumption might be correct in a = network of homogenous nodes with no external prefixes (eg: appendix = A.5), but there may still be cases where packets being routed through = the RPL domain might want to set the flow label. If this draft were to = go forward, I would have some questions: >=20 > When a forwarding node receives a packet with the flow label set, how = does it determine whether the flow label contains an identifier of the = 5-tuple, or it contains the RPL HbH information? To get it wrong would = interfere with the forwarding behavior and lead to interoperability = issues. >=20 > When packets are received from an external prefix, how does the = ingress router handle the flow label? Would it destroy the original = label, leave the original label in tact, or use IPv6-in-IPv6 = encapsulation to preserve the label (ie: the inner header contains the = original flow label, and the outer header contains the HbH information)? >=20 > How would the DODAG root rebuild the flow label from the 5-tuple if it = encounters packets that have been fragmented at the IPv6 layer? The = primary use of the flow label is so that routers don't have to = reassemble IPv6 fragments when forwarding to determine the 5-tuple = (which is a challenging thing for a router to do). >=20 > Cheers, > Owen >=20 > On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: >> Hi >> =20 >> When I started this draft, we had a series of chats with Brian = Carpenter and apparently reached a gentleman agreement that it was = doable within the RPL domain to use the flow label and avoid the Hop by = Hop option. >> =20 >> I published = http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on = that discussion but did not get news from the group since then. >> =20 >> This technique has a number of advantages, in particular >> -it saves extra bytes for the RPL option and the HbH header. >> -it also avoids the prescribed tunneling within the RPL domain for = packets from the outside. >> - it has an optimized compression with 6LoWPAN. >> =20 >> Is there interest in the group to continue? If so I=92d be glad to = have some discussion time at the next meeting. >> =20 >> Cheers, >> =20 >> =20 >>=20 >> Pascal Thubert >> IPv6 Engineering >>=20 >> pthubert@cisco.com >> Phone :+33 497 23 26 34 >> Mobile :+33 619 98 29 85 >>=20 >>=20 >> Cisco Systems >> Village d'Entreprises Green Side bat. T3=20 >> 400, Avenue Roumanille >> 06410 Biot - Sophia Antipolis =20 >> France >>=20 >> Cisco.com >>=20 >> >>=20 >> For corporate legal information go to: = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. >> =20 >> =20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >>=20 >> 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 pthubert@cisco.com Sat Oct 20 01: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 CFDB421F87E0 for ; Sat, 20 Oct 2012 01:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 iGlWihh8L1yO for ; Sat, 20 Oct 2012 01:09:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEC421F87A2 for ; Sat, 20 Oct 2012 01:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50597; q=dns/txt; s=iport; t=1350720563; x=1351930163; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5sgbf5ceB4bSxWHDlNz56x0WDS7DTUzyQshuP73BE3w=; b=gqQrgacd3oxXifwCCQZErS26ft7/fHNWuJ4x25aLDPUVys2KwvYhRUCG kPD/YIReHtFpITKZzE0dHux/X5HP9zGuOcEnKDX+uGmrcadvqDNchtN9W bLZScpH3qu9L0ZJFM1Pa+GfZWVkPOE/veB/8FnTpAtTNDWlw2VqxCOXwF 4=; X-Files: image001.jpg : 20186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAHZbglCtJV2c/2dsb2JhbABEgkq1ZwGIW4EIgiEBAQQBAQECDQESCAE7AQQLDgICAQgODwEBAQIIAxIHAgUQAQMJAgELFBEBAQQOBAEGAgYGBQEIh2ILnACfZgSLVgUVAYMlgk9gA5AQAVGGI4Ioiw6Ba4JvgWMXHg X-IronPort-AV: E=Sophos;i="4.80,621,1344211200"; d="jpg'145?scan'145,208,217,145";a="133640372" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2012 08:09:22 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9K89MsI028223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 08:09:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 03:09:21 -0500 From: "Pascal Thubert (pthubert)" To: Owen Kirby Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2tT14B78zttzpFSgOnw7I7S2GAIwBBnWmAAA9+R3A= Date: Sat, 20 Oct 2012 08:09:20 +0000 Deferred-Delivery: Sat, 20 Oct 2012 08:09:00 +0000 Message-ID: References: <5081A327.9010505@exegin.com> In-Reply-To: <5081A327.9010505@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.55.80.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--59.909800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "roll@ietf.org" , "Brian E Carpenter \(brian.e.carpenter@gmail.com\)" 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: Sat, 20 Oct 2012 08:09:28 -0000 --_004_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_ Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_" --_000_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Owen: I think we are back to the discussion with Brian (cc'ing Brian to make sure= my account is faithful). I think that we converged that the draft is actually doable, considering th= e LLN as one bug host from the perspective of the wider Internet. With the proposal, the LLN gateway is in charge of setting the flow label t= owards the Internet and the flow label does not belong to the packet origin= ator in the LLN, which, like any host in the Internet for the last 20 years= , are wasting the precious bits. So if an LLN originator sets the flow label it will be erased and recalcula= ted if the LLN uses that draft. Can we justify that? 1) First thing first, the flow label is part of the IP header. Which is whe= re you place stuff that you want examined by the router. Anything farther down the packet will be a lot more trouble for the router.= And app level communication does not belong here, whether it is a LLN app = or any other app. 2) After 15 years of IPv6, the internet community finally found and standar= dized a usage for the label that basically adds burden to the hosts to serv= e the core but neiter sender nor receiver can use the value of the field fo= r any practical usage. For LLN devices that would mean ask a battery operated constrained node to = do additional computation in case the packet goes in the powered Internet a= nd needs load balancing. Do you know of any LLN device that would spend ene= rgy doing that? It makes a lot more sense to push the burden to the power border router at = the edge of the LLN in case the packet goes out the LLN towards the Interne= t. 3) The FL can only be compressed if it is NULL. This is the natural value f= or any constrained device, whether it aims at forwarding over RPL or not. The burden of computing the tuple in the originator is not only on that nod= e, but on all nodes in the LLN, and that would be whether the packet goes o= ut to the Internet where the tuple can be used, or not. HbH adds up to the waste, additional encap then adds up too. In a LLN that = means wasting energy on every packet, with practical and measurable consequ= ences in terms of battery life. In classical 15.4 that also means more frag= mentation, and the consequences cascade. The draft does not prevent an instance that needs the flow label for other = usages to use the HbH. But is allows to control the damage when flow label = is not used otherwise. Please see inline When a forwarding node receives a packet with the flow label set, how does= it determine whether the flow label contains an identifier of the 5-tuple,= or it contains the RPL HbH information? To get it wrong would interfere wi= th the forwarding behavior and lead to interoperability issues. [] Does not. If the instance is configured for Flow Label, then the origina= l value is lost. In the future, we could store it in a new HC option but so= far the need as not emerged. When packets are received from an external prefix, how does the ingress rou= ter handle the flow label? Would it destroy the original label, leave the o= riginal label in tact, or use IPv6-in-IPv6 encapsulation to preserve the la= bel (ie: the inner header contains the original flow label, and the outer h= eader contains the HbH information)? [] The only usage is in the core. When the FL comes in the LLN, the role is= done, the FL would be ignored anyway. I hoped we could convey something end to end here, like a hint for the inst= anceId, but failed so far. So we are back to the BR selecting the instance based on the same heuristic= s as if the HbH is used. How would the DODAG root rebuild the flow label from the 5-tuple if it enco= unters packets that have been fragmented at the IPv6 layer? The primary use= of the flow label is so that routers don't have to reassemble IPv6 fragmen= ts when forwarding to determine the 5-tuple (which is a challenging thing f= or a router to do). [] Since the BR compute the FL, it uses the same heuristic for the first an= d all fragments. Mixing instanceID and IP addresses mostly. Or keeping only= the instanceID when we want the latency+jitter to be homogeneous within an= instance over the net. For LLN applications, the distribution of 5 tuples = is a lot wider than necessary or even beneficial for the core, and instanc= eID + IP provides a better granularity and more meaningful volumes. Cheers, Pascal Cheers, Owen On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: Hi When I started this draft, we had a series of chats with Brian Carpenter an= d apparently reached a gentleman agreement that it was doable within the RP= L domain to use the flow label and avoid the Hop by Hop option. I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 bas= ed on that discussion but did not get news from the group since then. This technique has a number of advantages, in particular -it saves extra bytes for the RPL option and the HbH header. -it also avoids the prescribed tunneling within the RPL domain for packets = from the outside. - it has an optimized compression with 6LoWPAN. Is there interest in the group to continue? If so I'd be glad to have some = discussion time at the next meeting. Cheers, Pascal Thubert IPv6 Engineering pthubert@cisco.com Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille 06410 Biot - Sophia Antipolis France Cisco.com [Description: Description: http://www.cisco.com/web/eu= rope/images/email/signature/vertical04.jpg] For corporate legal information go to: http://www.cisco.com/web/about/doing= _business/legal/cri/index.html This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Owen:

 

I think we are back to= the discussion with Brian (cc’ing Brian to make sure my account is f= aithful).

I think that we conver= ged that the draft is actually doable, considering the LLN as one bug host = from the perspective of the wider Internet.

 

With the proposal, the= LLN gateway is in charge of setting the flow label towards the Internet an= d the flow label does not belong to the packet originator in the LLN, which= , like any host in the Internet for the last 20 years, are wasting the precious bits.

So if an LLN originato= r sets the flow label it will be erased and recalculated if the LLN uses th= at draft. Can we justify that?

 

1) First thing first, = the flow label is part of the IP header. Which is where you place stuff tha= t you want examined by the router.

Anything farther down = the packet will be a lot more trouble for the router. And app level communi= cation does not belong here, whether it is a LLN app or any other app.=

 

2) After 15 years of I= Pv6, the internet community finally found and standardized a usage for the = label that basically adds burden to the hosts to serve the core but neiter = sender nor receiver can use the value of the field for any practical usage.

For LLN devices that w= ould mean ask a battery operated constrained node to do additional computat= ion in case the packet goes in the powered Internet and needs load balancin= g. Do you know of any LLN device that would spend energy doing that?

It makes a lot more se= nse to push the burden to the power border router at the edge of the LLN in= case the packet goes out the LLN towards the Internet.

 

3) The FL can only be = compressed if it is NULL. This is the natural value for any constrained dev= ice, whether it aims at forwarding over RPL or not.

The burden of computin= g the tuple in the originator is not only on that node, but on all nodes in= the LLN, and that would be whether the packet goes out to the Internet whe= re the tuple can be used, or not.

HbH adds up to the was= te, additional encap then adds up too. In a LLN that means wasting energy o= n every packet, with practical and measurable consequences in terms of batt= ery life. In classical 15.4 that also means more fragmentation, and the consequences cascade.<= /p>

 

The draft does not pre= vent an instance that needs the flow label for other usages to use the HbH.= But is allows to control the damage when flow label is not used otherwise.= Please see inline

 


When a  forwarding node receives a packet with the flow label set, how= does it determine whether the flow label contains an identifier of the 5-t= uple, or it contains the RPL HbH information? To get it wrong would interfe= re with the forwarding behavior and lead to interoperability issues.

[] Does not. If = the instance is configured for Flow Label, then the original value is lost.= In the future, we could store it in a new HC option but so far the need as= not emerged.

 


When packets are received from an external prefix, how does the ingress rou= ter handle the flow label? Would it destroy the original label, leave the o= riginal label in tact, or use IPv6-in-IPv6 encapsulation to preserve the la= bel (ie: the inner header contains the original flow label, and the outer header contains the HbH information= )?

[] The only usag= e is in the core. When the FL comes in the LLN, the role is done, the FL wo= uld be ignored anyway.

I hoped we could= convey something end to end here, like a hint for the instanceId, but fail= ed so far.

So we are back t= o the BR selecting the instance based on the same heuristics as if the HbH = is used.

 


How would the DODAG root rebuild the flow label from the 5-tuple if it enco= unters packets that have been fragmented at the IPv6 layer? The primary use= of the flow label is so that routers don't have to reassemble IPv6 fragmen= ts when forwarding to determine the 5-tuple (which is a challenging thing for a router to do).

[] Since the BR = compute the FL, it uses the same heuristic for the first and all fragments.= Mixing instanceID and IP addresses mostly. Or keeping only the instanceID = when we want the latency+jitter to be homogeneous within an instance over the net. For LLN applications, the dis= tribution of 5 tuples is a lot wider than necessary or even beneficial for = the core,  and instanceID + IP provides a better granularity and m= ore meaningful volumes.

 

Cheers,

 

Pascal


Cheers,
Owen

On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote:

Hi

 

When I started this draft, we had a series of chats = with Brian Carpenter and apparently reached a gentleman agreement that it w= as doable within the RPL domain to use the flow label and avoid the Hop by = Hop option.

 

I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on th= at discussion but did not get news from the group since then.

 

This technique has a number of advantages, in partic= ular

-it saves extra bytes for the RPL option and the HbH= header.

-it also avoids the prescribed tunneling within the = RPL domain for packets from the outside.

- it has an optimized compression with 6LoWPAN.=

 

Is there interest in the group to continue? If so I&= #8217;d be glad to have some discussion time at the next meeting.

 

Cheers,

 

 


Pascal Thubert
IPv6 Engineering

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


Cisco Systems
Village d'Entreprises Green Side bat. T3
400, Avenue Roumanille
06410 Biot - Sophia Antipolis 
France

Cisco.com

3D"Description:

For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

 

 




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

 

--_000_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_-- --_004_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20186; creation-date="Sat, 20 Oct 2012 08:09:18 GMT"; modification-date="Sat, 20 Oct 2012 08:09:18 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAASjAAAKQYAADhnAABO2P/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IAEQgAtQDIAwERAAIR AQMRAf/EASsAAQACAwEBAQEAAAAAAAAAAAAHCAQFBgEDAgkBAQACAwEBAQEAAAAAAAAAAAAFBgME BwECCAkQAAEDBAACCAUEAgMBAAAAAAARBAUBAgMGITUQEhMUNBUlJiAxMhYHMCMzF0A2IiQnKBEA AQIEAgMGEQYMBAcBAAAAAQIDEQQFBgASITETEEFRIrV2IDBhcbEycrIjc7MUdNQVNpaBkUJSNdZA ocFigpLCM4OVFtfDNCV10aLSQ1MkJgcSAAAEAgMIDggFAwMFAAAAAAABAgMRBCESshAxQXHRE3N0 IDBRYYGxwSJykjOT0zRAkaEyIyTUBfDC0hSUQlOz8VIVYmPDRGQTAQACAQIFBAIDAQEAAAAAAAEA ESExcRDwQVFhIIGRobHBMNHh8UD/2gAMAwEAAhEDEQAAAZ7/AFp/PaOrDT4Q1On6P4lLEbvHua+J usUf2/8AL6Dw9T5ucmkrYpXpU2N7/qvjfepu2+Yyxs8/FXY7unN/E0Oh+4e8MdQI9n6bHs/U4C0+ s9TkgpU2KGKdRn6M+TJIman8Hhtem+ZGxO7x2UtiiincZ+jNR8yGd7qzrt8sljZoAqZHfoDl8c4J j2uc26i6rxGGzx1PVWvOp2CadjmknZ6P6VGj/wBCT9t8l7vLVea+JqtOl2uXtjnkubHPfj5lqDof ofsvut2P3eNft8D0qro955n4m/SYtjnNr4quVQ0e/RHNwonbZ5XJOWliqmn3qxezxzoPuIA5/wCJ aL8V65n4m9V878v7HO5My0kAVi1O4c78TAlvPz61ERBRJg6DGc5Wovx3mZ83NpCyVB4rHr9vn/Py Xe/UUA8QVh6nvPYuWMtA9HoB4rhg7NoPmWEp5KJaCIh8bHnjidq8Q/HQ+j9hu7+qqK64uxThk5fu vY0AAAAAQBj61o/JU8kr6pdmIWNxfjPG85WI0XXcI7s/a2MDzazmr6PTwHoPAegHiEHT9MkRIKo2 Pg9TF+M8azlZ4D6tu0aPV/MAAAAAAAPTwiL76Hqvd8dt81iw0DixPjYjSbrXGZbJsPnT6P4hj0Hh 6P14/PoHn689/PvgPQI02Lrg+7W8xxe++YqaoHfxMexGc3WtFllcnzBtMeiABIsPYLXUPqdUL7yy O5evyLD2G1tD6lVK+csjqYr4A4bctO4xR3Q4IcSZCWXF+M8YzVcHh6eAFuKF1Lv4mdyPnJjfePgZ WC7+Kncj4yY/3jj+VgqkX3lvp4c7vTO019HPw6gk6FseHj2Iwmq6AAAPp59SrB2WJp2sfTz6EqQd liucrXz9+QAABKELYsT42Itma8AAAP6+cJ/TUHWOpfn3z5+/E7Vq4wzYKrM9ftf8lO4/mvXZcAAA Eow1h+u/8RHuw3xwZB4egAv5zPsUUTVd0WzqdDq7sywNogeyVCd63bv559Q4v5754egA8JUhrB0N hh4VzaGojZAAAAAAAAAAASpDz/b2WsQVkwc7FTAAAAAAAAAAAlaHnpMtVIr779cnEWAbTb0P0+dT qSIAB4egAHh6O/sFS5qMmtLpSQnTW2JEsFPrl5s8RDWh4ly1891mtvRtXboAAAAAAJzu3LcfHm4G Cte73IyfMP3le4Kz/EjH0HbxNlu5jqdaQims356A8PQAAACxF649kZMIeJJgrPk+4Ku4ZmNIC7Hk +3Lk2l1ZOHKv0cAd1L1XBxbXJxtgB4egHh7Zy/8AD8vJg8PSRoC0ZX1hqlrT8V1++ixl143o9SUg +q9QG924rspOtyFNVDQaUvBtU6iAOwkq7qNaQ02tJfb7xWx6FwH6fXwBI0Dasj3BUrUs8Q13oYs5 eeIfb6xVfovcv08tLfOEx1DXGG630jf7cTPFs5TEFc6Jw8XaBaS98Ky8mvENd6H3ktVJCmKgAJEg bVKVetlSsc3FEBfj2yNz4v2EjXY+iLd9fr47uVqldad2PiYyznltOgfn+HK50eLoK9eFmbtxLqN+ CeA9ACS65cP/2gAIAQEAAQUC27b9n+5/u3aja943Rvngdp3yTcU2zabaSk/t7vBXf9+tr/YG+n9g b6f2Bvp/YG+mrbpuOdh927Ufdu1D7ft7te/2Bvp/YG+mqbtuTjD927Ufdu1Evvu845P+wN9P7A30 i9x3+SeaXtOy4dj22vutTb7qVdaj4BRR/wCOatHD3LTUn1bHjB0wvNS5copIePMTVznNUw5sGBRS a5r0afbTttSr7r2udYfeLmfjW9j53kfudV8Aoo/8drzWxtHKSzSj1jRi8upq2fqWKZctmHHnv7bP ARtj9zbS2yiiikxzTo1HhfqNfde//wC+IIaxwYqKPvGxVfTlFFH7Xt8ePZ3ltr+WeSFMTF5mprbf O3xqKKKS/MkENV4X6hX3ZuMBXPuzjW6dW/Hfiv1vgyUUeeLjK+nqKKKXQT/Jmj4G/HnVBRRRRSV5 gghrPC/T6+7dxr7uU2DHbRzr/Booo7p/2o6v/RUUUUUUUUUUUUkvHoIa7wu06vu7cq+71J3jlg+D VRTu7alyiiiiiiiiiiiikh41BCB4XabX3fudfeCkzxyRHBuoooooooooooooooo98WghDcK6ZX3h ulfeKkpxvjOGBRRRRRTiiiinFFFFFFHfibbK3Vtjc1aMm17aul1947rX3ko7w35qtbLsWPrCiiim bV5pvrbizH/QdNXmq62ph1eaca3q9mOv4OYavNSUGoooo4p+8xspSiimlV95btX3n1hRRRRRSd1/ X2n4nls2P+gs9f8A5/w58VPwFg1/X7vxBE5sX9BarX/wnSc2K38O6dr+vyWgqKKZbLq5G/8AxsUU 0mvvPd6+9FFFFFFFFLetfW/dJe/UVLqX47raXXDHdJeO1W7rWiiiiinWOsdY0ivvTeK+9VFFFFFF FNr2TD+For8Oy107+U/xPIa2x338txm6PJbdt4x/iHJ+JWkRKO9P3Vt+Yr3eHujvrCinWFFOsaPX 3rvGNd0vpWwUUUUUUUiPzPG54PWPyGx1redZ2nVWMlv/AOS7dsat/wA2QkrH6l+SXen7K+/N0Uxj a3KKKKKKKKaNX3tu1PebvhVRRRRRRRRRRRRRRRRRRRRRTRa+991p7ykOFyiiiiiiiiiiiiiiiiii iiimiV98bpT3jK8L1FMTRxmtztMrexRRRRRRRRRRRRRSkbgusetu63qKaMwc2brudPeE1wvUUjKK ymuGBRRRRRRRRRRRRRTFT9ty1sc474h3SrSJ7O7TKe8Nyp7vn+GRRSJ4sJ7g2UUUUUUUUUUUUUUw 0/aQQQ02nu/cae7tk4ZVFIXjG7HwaqKKKNIPO6wSkd5cKKKKKKKKYKfsoIIadT3duFPdu08MyikF xi9o4NFFGsc9e2M9bcXXVlYvBWcxWvmKiiijeEfusD1k4YZFMdt2XJZZ1LUEENPp7t2+nuzbeGZR TX+UzTG58xqttbaXX1iGVWLHaJDJbepHP8jBzn1+NdVnY/DGuFFIPlUjGYZHFfqr+l0Vr+Nheggg hqFPdm44dQv2nammk1zdy0I7loRAtdPpFd21MlG34z68W2/GnW7tqZsLPR6ynctCO5aEN22pd32l ppNXXctCO5aEQrXT6RfdtTO7amd21M7tqZ3bUzu2pndtTNOw6hZtP//aAAgBAgABBQKKio3y3yuL MkXGlkVG3HlUWXRMZU8sjTyyNPLI08sjTyyNMcXGJ5XFnlUWVjI1fLI08sjTHFxh5XFnlUWXRkb1 vLI08sjS2Ljq1lYmN8tiuWGT54/l0V+dKKdnUrStOjH8uivz6MfTd9XRjJXlkXdTyzrUK1Us+XRX 52/Iu40SpZ8FtF+G759FhKcsjOW9Fvy6K/Ony6anXqVrWohb8Nfn0WEpyyLp6b1ei34KfCgnx1+f RaSnLIzlpUp/iUJPlsZy3/Hk+WxnLShX/EqSfLY3lxaXfGv6VOjrUK1JLl0by4trQuqvxWv29zy2 tfuvvzfvhc/bWvH11fufK/bYXXwU+V/TJcujeXfG2eOr53BSv3Vb/td1K/dVzt15/npX7qff7PJU rXYZB47wynTbWiX149Ely6O5f+gqFI/BR+UrSotDJH4Mr1V/RkeXx3L/ANBk1u2DNPYaN4Wbxu8k ZB5o/Hgj46s7ScyZ8ON9H3QNLL+vZ8cjy+Ow0rG32Vs/QzQOW1w7jMjuOdtHmTFGRXcr7oBxhyvY qx80x6/myZf0JHl8Xyxz8/8AGkPARfLHXz/xpDwEXyx38+i3Fkvpfiux0/Wo2x1pmxdlXokW+Skd F8sefPobfwvPo/Wt+nJjpktq0ymJr1aynLIvlj359Db+F79H61v09MpyyL5Y++roa/wPv4/gxtLs lrjB2P6Nv09MryyK5Y/+roafwP8A+Posw5MlMbK9e8YLR1SmXF8FjXLfblxX4alKdatKJTpleWRX LJD6uhn4dzi7XEfMb4+yxPs1VMOWuK+9pgvHWG3Dd0NfD5sNua2rDKuBpTFX4JXlcTfK0jX98h1u s9Os9Gl8l2HaShnyOFwZHJ2kmO73/b9Z6dZ6WZJPqvr5Dr9Z6dZ6Nskl2HaSh2kmdpKHaSZ2kodp KHaShLXytY3/2gAIAQMAAQUC2Cfm/O/Pp0gJeWzYpXYZBjirPz1asdomW+Wkk/rTzGQPMZA8wkDz GQJ2ZmMTvz6dPPp0ayUjc28xkDzGQJ+Yl8OXz6dPPp0jpOSvZeYyB5jID6cfMm8Jsc5knZ7nhrtK 9hsHi06Gnhc7jC2srsDXrNneB3abB4xOhp4Uvz4cRP5MeXKnRG+A6Nir+3A882CLd+cYYl5luat7 GuGe8WINPCzGe7M8Qj89WrqrptQncXWuQsx3ZL8VvZ4pZ7c1w1rW6qCCEd4Ho2H6YHnkjzDonPFI INfDP/GIIINM/ZX3wbe6rWPbtC903xVmsuLNeggghH+C6J76YLnc5LdlKYZqq23232zPiUEG3h3v i0EEEKSjWzG7lrb8Qgggggw8H0Tf0wdPW5ynrSERfXsZfxCCDf8AgeeKQQQQQQQQQQQQZeFFJjjS Dp61N09ZQiuFkp/Ogh22bqiCCCCCCCCCCCDTwyikrxpCU9ZmqesoR3CyR45kEEEEEEEEEEEEEEEG 3h1FJLjSFp6zNU9YQY8LXvHKgggggggggh1RBBBBDB/DW6lKVe46DnNbmIWnrEzT1dBvktx0z3Uy XoIIIIXxTyyOvst+xfK3nlyFkU8vjoyy37KwRTxwyQQQQw/xurq1EEIanq8xT1dBBBBBBB7HscWs Oq2/Y9/+i2XW/Y9kexrqjWtv2PGf6VD1tpqcTHsXEGgghZdSlmbjcghD09Xl6erIIIIIIIIUtrUr KOqxaFba0rS2tTDKOsEb1a0EEEEEEEEIinq0tT1VBBBBBBBCRfW6q31hxV3sWt5WOGZ2VtK5XMrL U1mut4W2fLGSlmz1yY+zyIIIIIIIRNPVZa9Ja2vWEEEEEEEG2zYb2rCYxMZZi+j8WeYm/Mcdm0NX GGOm8kY+y7TgxYBBBBBBBCJp6pMV9Xb8aIIIIIIIIIIIIIIIIIIIIIIRVPVJmvq7PjRBBBBBBBBB BBBBBBBBBBBBCLp6nNV9YYcbUEL3GHHdiz2ZrkEEEEEEEEEEEEEKvctLm2bt7UEIl3hulZqvrMZx tQQe+JjeOVBBBBBBBBBBBBBC+v8Azw57sN9sjgrRw/69IWvrM3X1mJ42IISHi4njmQQQQQQQQQQQ QQQyV/cUUUhK+szlfWoXjYghJeNhv50EEEHEpiwZWLzvgggggggghlr+4oopB19anK+twXHGghK+ Og+LhBDO8bNrnEzhpbRg+ykXfVq6QQQQzSbXBlbOcLuxC+6mOy67rXKKKQdfW53nev8A8aCEvzCM dUauqJWlUtpIOaOnUG0trag8aWO8OKXe4KRbzI9xIISnj2b3IzyWzzStr+WvdWqKKKQXO5/HBXTU DjiqY+owOowJXFD9/wCxhBjhxdV9hwp2MIRGOMox6jA6jAzYoTtYLHF0wdRgdRgSWKG792MIdjCH Ywh2MIdjCHYwh2MIQGOCtmv/2gAIAQICBj8CYUphpS1NJUZqSRnEyidJjyzHdpyDy7HUTkHl2YdB OQeWY7tOQUS7EegnIPLs9ROQeXY6icg8ux1E5B5dnqJyDy7HUTkHl2OonIPLMd2nIPLMd2nIPLsd ROQeXY6icg8ux1E5B5djqJyDyzHdpyDyzHdpyDy7HUTkHl2OonIPLsdROQQ/bs9ROQPqSw0laWlK IySRHEiiVJCX0DdkvSJjQOWTEvoEWSuR2mG2zGgcsmJfQIsl6RMaBdkxL6BFkvSJjQLsmJfQIsl6 RMaBdkxL6BFkvSJjQLsmJfQIsl6RMaBdkxL6FFkvSJjQrsmGNCiyW0qkCP5lKYn7MpBW5mvykP2E fmasbiZAz+ZUmJe3IYltzNeIESaz+O5e2ULr+hXZMMaFFktoflVn8sluJFDo5TDx4M0VlAVovykE ngzX5TCZSPyubjCG8dPrDJ4M0dlYltF4glD3uUxKsMn8FZ84oX/9C2h/QrsmGNCiyW00j/kednzT DeuRK8KQifVWzzZQLcw5dqf0K7JhjQosltLsxNuKJKToIsEeIuMIlyOJIUkvYYZKXJRtwKsRYuIP HJ5wnCKKkq3o3oBc5OuqrVoUYo+qm8Jb7YyuqS+aZ4oF6t0Nzko6qtWgZHhw+reBL3S2h/QrsmJc y/sIsltKpj7c8bVa+VPJxBEkpz4iYRUdMYcIbRKPZtSCp37wW++vOTDl/wDG+FK+3TCmm1YKeQIY dV8ZsqFcFPrCVfcHzdbReKnl2l/QrsmJfQIskC9Hf0K7JiX0DdkgXo7+hXZMS+gbskCuxK8Iq2/C KL119X/ZXZMS+gbskCukCx7eWIVTFEBWWJjQOWTEvoG7JArpAse3li2ExoHLJiX0Ddkgm6QLHsa8 YAqYx2ksWwmNA5ZMS2gbskE4rpAsd2KCoEXaEirEhXbphsa6YQMVV3KpXxDYTOgcsmJbQN2SCcV0 hAveuUXwSTvjNFew3IleEb2IESb0LqRBQoMoCsqlexmdA5ZMMlm2FJzSYfEUnmw5sSzSqYb4TWaZ 71XhEOza7xXhjs2u8PwwVVpiGlV4I7FjvleAPisy1bTLj/gHwWZatplx/wAA7FjvleADrNtR0ivC HZtd4fhjs2u8PwwXwWL391XgAqzbN7+4rwiHZtd4rwx2bXeK8MJg0xDSq8Edix3yvAHYsd8rwB2L HfK8Adix3yvAHYsd8rwB2LHfK8Adix3yvAD5ZthKc0qPxFK5sOdAs0mmF6kf/9oACAEDAgY/AppC Jp9DaH1oIkLUkiJKjSVCTIrxcI87N985+oOG9MzCjrFfcWfKCJt93Pqvc9VG/fEf3s13q8oLPTMw tk78VqP1UiJPvQ6aso7d7rqyjt3uurKO3e66so7d7rqygktTcylNTA4ssJ7487N985+oedm+9c/U G1KfeM6hf1q3MY7d7rqyjt3uurKGyZmplJQO84suUedm+9c/UPOzfeufqDalzD5qNP8AvVlHbvdd WUdu911ZQbxvPGeDnqv+sS2cmXVIcfQk0mozTBSiSfNOi8dB3yE7rbv+RVxw8FbkCdHyndb6CeIZ x44JECSurwCsyceO4nR8p3W+gniufEUlOMw3m1ErmneutdG62nBExJa21/kSJp1sq6FTDh0b6zED TVTumCZReIJ6HKd1voFxA0/0IoLluJc/pjA8QgbiI4yCJlNLcIXCQj3jCW9wiIVWu1X7BWVSewb6 N1rGrkEnrTVtIf0y7R3U9DlO630C4g50j2FRymXV7xfjcEUKUSfWKyKXN0xVcWkjxhGaUSoEd7Yt 9G63w8gk9aatpEy00mJk+u/0jEH00bwrppSYLocp3UdAuIOdLYpKJmqG4KktGseHZt9G63w8gk9a atpE5rTts7hoO8RgujyndR0S4gvpbajo3UcPIJPWmrZCb1p22dxWMF0ct2rWOqW3IxXUcIlNZatk JvWXbZ3FYwXR9BTiup4RKay1bITesu2zuKBYvQU4hE7woiYKrgEprLVshNay5bO4ZKES3Nkn7opP ya1VSOOGnBwGEUU5/wDMY/5Sr8nXqxjybmC4r7olPyaFVTOOLBwkJ04U57wg59waTGWa96nk2JAk 4LsrrLdshNaw5bPaJaeaIv3q3YKON8ufgvUQLAJZMac+dpwI035zCkxpz/5iMLn4F++J6EY75UQx UiZTEo58rTYnNN4QnyMyjW4yTATs1MF8w2XNON6ij1nsC2ErrDdshNaw5bPaaAX2jm/tiXWvc7Fi jvR37kDvigOfa0Vf2zqonRTgvdUsAp2mV1hu2QmdYctntLMpININaipUeGGK+dO7QHZoygbiFnDG ZCYObNKXjM6hqvRrHHhEuX3DNG0pVVK0RL3oX4n+N0Nfb/tzKKlSsZnjMsF86KTMTf3mZbrKaiok 379ZRw36IEHft8+wmrUiRlgphh/qpoP2BTe4cNoltYbtkJrWHLZ7SmV+7S5P1Lx0cRlf38Ic+4oa +EutBBHCETLewB5yfl88hw4l/wBNJ5Q1LS7eZlWrxR4CxQCUfdpVLzyMNHEZUb+AOTLKC/bunSje jEob5YuALR9qlksPOX1UchUnubm0y2sN2iE1rDlswfo8tp27RCa1ly2YP0eX06LRCb1l22YVdqqP nCqiO3mVF8U+8V2XQUY/uG7RCb1l22YVjuq/GAH0dvPGKyRzokYqNXhKay1bITesu2zC8d1XBxBX R288ewlNZatkJzWnbZheMrq+DiCuhylsTaqmZkFc2FXaVYz2EprTVshOa07bUHMZXV8HEQV0OUrp IeVBRirLRU57BnKh0g2Xyq1yw7uxNpcaxbwrtXrhrV7pEDVu7CT1pq2kTmtO21BzGV1fBxECUvsz oMRK8KyrwU4n3LxYgc2v3owLLcNCvfwHuGKkSURboUp2FYlYLrmPkFdFJHfLdHOSslDNNlVZ9p7G T1pq2kTJk9NIVnl1izKFlXrHWgefRRWjDm3g5mnpg6SvsoL/AM6h2jvdp8Udo73afFC678ySqLzC DwF/9BcQ8xNfx2/qh8pMTub1duHtmuIfOTE7m9Xbh7JqA8xNfx2/qgnNuvmmJ32klh0x8Y7R3u0+ KO0d7tPihXzE17x/+uj6kLzTz5lWwspLBp1DtHe7T4o7R3u0+KHK78ySo4GEHg1kuIeYmv46Pqh5 ia/jo+qHmJr+Oj6oeYmv46Pqh5ia/jo+qHmJr+O39UPMTX8dH1QljN6aWrPIqlmUIKvWKrE8+uit CPNvD//aAAgBAQEGPwKvNNV6qyrMrVp+TYYk5+alGG2JSadl2QGZd1tvNs2xEwio6Tj3muD+c1H1 nEoJe77oYCmnCoM1+qtBRziBOSbEcKL173gJViBdhctZBWo9q0D55ojDT1MAC5rh0aONW6mo/KpU 0VHCvNrwumWmUglss3DV20KI+g4hM2EwVw6xgg3td4IMCP6krOgjWP8AOY99ru+JKz67j33u74kr PrmPfa7viSs+uY99ru+JKz65h1b92XK+sTS0hT1dqjiobNowzLmiYace81wfzmo+sY95bg/nNR9Z xNpTet2pSmZfCUpuOsBKUh1QAAE5AADHvtd3xJWfXce+13fElZ9dxNmYu25nyl1sJL1eqjpSMp0D PNGGPea4P5zUfWce81wfzmo+s4nUN3ndjaEvqCUIuKrpSkaNCUpnAAMe+13fElZ9cx77Xd8SVn13 DcsL4u9KTFbq/wCpKzxGk9sf85rOodU4t+WXcFbnWJiq0+SfbqVUnqkh1mbmmpd7OicfeSVltwwM OKdIhi5ucFZ5RmdyUTvhhZPWU5o73D/CZtX4mmt2c9KmPKqwGZZouL34aAkfWWo6EjES/LBf1IuH /myY2cy0UR7VWtC+5UNB7O476WvyTO7O+lTHlVbkWZd50cLbS1j50g4m9s041mdRDaIUgmCDGAUB qjuz3j1fk3Z1e+lppI6y1KJ7zFs84aNyjLYu5h1zzdxi56+ydr2qtnVZtGZK+1gYb+CQ+H1bzbHH JPddon58OTLugr7VI1IQO1QOsMO+lL8k1uznpT/lVYbcA8JM+FcVvw07NPWSn8Z3H2ssXAkuM8Id QIph3Wr5cRTKTJHCGXP+nEzJLih1Lm3CVDKopKUoVoOnilI+fcW64oJQ2kqUTvAYee1bV1xz9dRV +XClPiLEuEqUn/yLVHIg/m6CTgJQkJSnQEpAAA6gGgdBO+PV+Tdnu5l+y7i2OcNF5SlsXtzuuTlm c3XfSleTa3Zv0l/yisSfo6Ox0BcZ8HONAql306FhQ+gTvoc1EHRjK6wy4ofT4yPnAiOxjI6oIajH ZN6Ek/nRJUqGMzUs84n6yW1ZfkMIHE1tmnGszjcNokpJypVGEev0M545W7O9yx2XcWvziovKUti8 nph7Ily67iWhDYirKqrzhSSo6BEdfBMs+SofQeA436aYQ+bCm3ElK0GCknWDh30lXk292a9Ie8or Ep4hHY6F0hDaE7ReUrcGkZjAjLmOrG0ndmpCNKW0nMFq3s2gcUfj6Ob8cfybs53LPZcxa/OKicpS 2Lp5x1vlOZ3GnBrca43VKDAH5sOekK7xvdmfHu+UViV8SjsdNmvGndmu5Z7LmLW5x0TlOWxdXOSu cpzW4x3Cu+wvx6u8RuqXsGs6jFSsgJJ4dPTpnxh3ZnrNdleLV5yUPlOVxdfOSu8qTW4z3CuyML8c e9R+Av8AjDuv9Zv9vFqc5aFypK4uznLXeVJrca7lXZwrxh71PRxhojCO9Hgjw9BGBgIAneiYwHXM Oie7s4CUiJOoDGlSE9SJPYGHM5TxssMsd6PUHDi0+ctC5UlcXbzmr3Kk1uIKNMARrhgpVoJVH8Q/ 4dFKXY5LoFFnptclLv7ZouKdbU+2SWAraJbLkq4mPCnqiMivIjMK+tYVlGYL9ozbWcGEc2z4seDR hV2CXSaKmd8xU/tm9oHYhOcsxz7LaqCI/W3Jy7G5dBosjNok5h8vtBwOuLYbBSwVbRbYdmm0xA1q 6hhfCyhBV7c7YpBV4NNuFvTr4hWYcEcVS4pSXQul0daUTrpfaS4lSshVs2VK2jgbS6kq6h6FzusK c3+1HW1n5920uc1B5UlcXdznr3Ks10i07glWGxXKhWHJecmhMuLceZHtnatljallIZVLMjQkFPy6 bXRtEZ/b8ynJnTmzCpXA4U5YxiG1g9Y4kv8AfVcqzeJtBcRnVcCWwjMMxX7RlXsgGvNshm62J24y w2qvN11Esma84c2jaDMSzfmoYDgagZZRXpSVaY4uhG0bz+35ZGTOnPmNSt9wJyxjmLaSrrCOL5/3 1Xk7Zx/+hhTjaVCa1KWkHw0vINs6Cf8AuuAhPCcX5V6kwhdTpTSDTpgzDja5ZewU4yEtpcS2rziY GXjJObUOgXoOvgxA6OMfybtpc56DyrK4u/nPX+VZvpMEpKjAmCQToSIqOjeAw1ZZTJ+yWZ4z6XAy vz4rK1u7FT222Ww2zhV+7zx+lDRuFC0qQoa0rBSodcHSMKypUrKkrVlBOVI1qVDUkR14qtoMJkzS qxNJnJlbjK1TiHR5oFBh0PJbSh0STccyFatEMDMlScwCkxBEUnUoR1pPSbQ5z0DlWUxd/Oi4OVpv pNvUO26HIvzE9LLdnKjNocCJpcpsUPOOLYLTs1NPOPE6VwZTlAECAKxWHGUS66nTqvOrYbJU20t+ cknFIQTAlIJxc6q29JSs+4/Nook1UMiWGn/aD3nCG3HVJbbmnUlGXSlRAUkHTpthu53KI9JTU2qn 0yrUZp9hs+fOyudE41NPuFtbaU50acpEeMd6jWta1vyGwVTm555+b2sHkmYeloFTCmXHp1RllKcc WVdunRi+r9qtNTOOUbb1STpoQl9DTkyKjUXyy24nK7MoSwG2SRxSY64Qrdr3Lbsm2yinuzspNS2Z 1UqgvMyvFdfSss1BBmEqQ4jKFZDxYYmZUrDhlph6XLie1XsXFN50/mqy9ItDnRb/ACtKYu8gw/8A qK/yrN9Jk6LfNqS1z+zQhMpOLEqtSktp2bZel5phSUTCWhlLqFeEGsayatdbFD/9GfRUGpakS7zM qmTanJhl5ttCkS5ayMJZhBKAMV6bue1/b8vVXtvKNbZCXJBZmJl5YSshBO0S8AYEdrijUikUkUGi UIhUlLpf2jxcbaDEuqLaW0MJlmRBCRmOknNiSYvmy5O4Z+npg1PZZNxLpgApxTE3Lr83W7lG0CVF CzpyjQMVasU+QaXS6zMPrm6Kpeyb83VNOvyyWXW28rT0kl5SEHIUZVHi8E/LWRZ8rblQqkfOqgkS jezWQobZDMnLt+cPt7RWzK1BKDpynViJ0k6ST0iz+dNv8rSmLt5z17lWawjrH8Hs7nVb3K0pi7ec 1e5UmsN9Y9kfg9m867e5Xk8XZzlrvKk1hnuVdkbudtEUnUcyRq0b5wlbhTxjlgDEgwjwQ6egxWCU pJgRwdUHCYElCxoJ4RrG7ZrhCYC6beUoZtKQKtKExj1MXXzkrvKk1hjuF9kbrP6flFYa8d+wrp7f cJ70Y2a9G+lQ1pPDjiltY4c2X5wcBx9QUpOlKE9qDwqJ14tTnLQuVJXF1c5K5ynNYl+4X3w3WP0/ KKwz4/8AYX09rxaO9HQWrzkofKcri6ecdb5TmcSvi3O+Tuy/8Tyq8M+kf4a+hQ/tUNpc0pBCirLv HeGnDHhS7tQuPFywKMurSdBzdJZ8U33o6C1ucdE5TlsXTzirfKUziU8W53yd2W/i+Wcwx6T/AIbm 6pyWZ2iUKyk5kJ40IwGZQjoOAudUlloaVISrM4ocERxEDqxwGfOmhk4oCApaUhOiGZCVJ0YRMyik v+bqKjszm8GocfVvpgD1uhbmGg3kcjli5BUASmJENURgNTAAKk5klJilQ6h0ajuIaRpU4tKEjqqM BhKfqpCfmEOgtfnFROUpbF0c4q1ylM4k/FO98ndlf4vlnMONtiLrZDzQ+spEYp/SST8uCFAgjQQd BBGsEcOAlAKlKMEpSIkk6gBvnDTK/wB6YuO9Ra/o/oiA+TCJBtRSjIHH4fTzE5UH80AR3EOpUdmS A839Fbf0ojhA1Y2oQpor40WFZEmOmOQhSRHqYabYU4UuNZ/CEEghRTrAHBuyfi1eUXjZuxSpOlt1 PbIJ19dJ3xiCHZdaPrFS0H5U5Fdk4D7y9vMDtICDbcdBKY6VK6vQ2vzionKUtivKFTuCWc9qz/nT SKHITrYnvOXfPdjMOXDT1qZMzmyRaEE8OJTb3BdLZ2bmXY2fSXweMnWV3zL5fx495bv+B6N/cLHv Ld/wPRv7hYltlXblWjwsFOWpS2lnwy4xQm83gNP5xx9tXD8MU373Y/1CtVrbQ05LYkNv1M2wu7P+ tj/Tq1WdtDftiQ2/Vht7u2nzY+2rh+GKb97sP7a4rsQvKzxW7MpDqP3SYQWq/GSf1ce8t3/A9G/u Fj3lu/4Ho39wsMQrdxEbFuBNr00HtBrH9YGBxLbe4LpbOwMAzZ1JfBG0VrK76l4H5Dj3lu/4Ho39 wse8t3/A9G/uFiU2dcuRaMisqnLUpjaz4RetCbydCf1jj7auH4Ypv3ux9tXD8MU373Y+2rh+GKb9 7sfbVw/DFN+92Ptq4fhim/e7H21cPwxTfvdj7auH4Ypv3uxQVGp3BMue1ZHzVpdDkJJsz3nLXmW2 mG7hqC0siZy54NGKeDH/2gAIAQEDAT8h3AIZonoDRFV4QikgBgAQoO8NYN6lel4SjIOijGKQAaGd wPlViyWzXrEfoYWZ8LBjIFRSGlH03Jt26LKAqJiCKmtM8YdQ3zcEF6AoDAcblxvOIIOq8L24xohZ zF8KeAMHG7cCEgCNGkxWToUTrpVHjvSBq7QcZ4QnGXZAvdUANWBXqlH4viEDCgqOhFYHzgtasA/d ZiH9lRsmo+yQ+otWhzVvUdTR1OCr0qAsBFtQCtbCGXA9PrLBEXEcm7cVj8zH9TwlkVdTYx5R1OqJ 9ygJ3pCwIwd1imhQIU2ruprPVtjrjyCKlIrxMkiz4vc4Oh1ItoXa5vxFei1TMa5gg9kdgIxa44Cg iewO3d7HVmGNA9sZ7R0ZmGIDNfdFV1hXOBDtAQB6AbXkqKlcTuoPEEdPi2IVQfoXu9j0jrxcbUMt JooNqVOrrdoEA+DTNFoei2jtLX7oiuUVCd2pyqQIoVzp6dF89g9JME1LTkHzkul1UCLwpUeANu9I 4BJOB0ecxcQuZ9QPpXopbgR0Djq6hDBZ9vW1w69dXiAAAAFAYANAOx6vi35a4j3j0KNjsCKqV6ij zcNiLiy7pZQPb+Wf/m/J+E4nvfoBdBvM/RFR4jhLYmKrmwaVcwAAUBgDAHQAx/L/APi05qOJ7r6Z VkiLOl/4W/8A/NryY4/v/wCbgQKeBn2T8SKj65/vUrrC4AXoUH0e7MyoWgpnQB13p9XxacmIvHGB ay1N9yDw2H2xhRjsXfW6PQDkORRaCmpE1qGiI1EcU6mL9R5Cwy2sQZDO/QsKSzndLk0PzPFAZyEr tGfSG7aVnhME7x5hMIjo2LGFqS2Z0zV/edasF+7RCsCMg7Foh6PsfuoyjNs7AKNz9fyaGivzDOkg s10pjFtuGkcpCFoCljNa3RJm4xWbSrqLOF6a1vSM4JtKLAX5S16Cv1tYE0mGt2gmQiVjwJHngEe1 WhaTGwnvgGs5n0Low12wnWFrGyU4xX9PRqtP8JX+Kiy0oxoFp2vQglGaJHxMC0MBwVgbhjRsBmBu dzTFcFI3BawXDHBklDQWKS10rB54K34IwMJh/wDH8JWx/vp1YtZVxTajInd7GChqerzHcT8hEAoH UxNYwwC9E9bFCbp0muLrvxn3MrhMZdoHSRWRYpnlwBIEkNWTOjVS2pko6lmbbHh/hbbGdAp3JKAo 2Xj+D/SuHx3XLYl6vDgnINRS9FzbFVCp3cs4JHffrh6ZsOukIPjIrFgCO4aVZqQge4IJuPmkp/x0 MOsggEXf1tRAoeoYVKKFBVVtVcqv8X/XVfdvyE3/APo//wD/AKaH7/8A+jP/AP8A/Uykz3zjmFup Es2tgGhJ1mlKwC8NB0/n/wD+5KIylCtUsyg3Zo2NToA1Y+/HrEZmiOAFOxZbCPf+J9g7w5LuP/A/ /wC2JrFfQj0dzudSUu54KVeDj2WXfYWSHQIa9qrgoWxL3/jubU+c8P8A0X/+WdWHYDFiY+zel+mf XN1Ra6GzOkHAixT2qP6z/wCL+I+OlYNm1ALfhxljgnTQ1FgXWlxDFhEDKr0dbHxMeiC1lKoAVrAa yo70es2oNQPp1gO8CzElBJ1uajmvtRwZBSa8JuUgZsn3MEfIVsX6ejZP03T2cbebxkEkAfJxslwj o6gpCkD0gHaMF1BWow7apZnDXDCnEjNXVFAcdxGjZ24M5oey2horrXR95r08HuY06CWyDhElWDTs 4gt4Aex0wRqwcVfJXRzL+84NDvjvaABQJZoqDKjVqo6dfUpG4o1a4lanwmgvU1rqsIZlih0AtxdO gkHs8E73B8cHtx7aJ9O0ig1RWj14XWujg9Ssrj4678a4U99eLp11QRPmFEUNS2u8fR/WiIou6G5x dOgE7UGajqvt/APXr169evTlG/HErU+E2F6j/9oACAECAwE/Ib5AQ4eAXVwaBgxwlhSimQzwWFBY XqYcGDDgyM9fjpYu47nHBgzBvjaWLvK9BgwZxwSQosvADqZLpMOOLvQn5eFzW3iKibEUzw/LLlzX 34AukCDfHU3463g7rPWMnLFp+bhc1N4a82XBgngY68pcui45bhrOnC5cuavHrj9PQauXNSaUuXLm RjXgbJLMuXcvhcua3Hqj4LM3hw0S5cdZoly5cuXuGeZcuXLly/SFFnJr4ly46w0ly5cuXLly5cuX Ljr6WZwa+Ny+Fy5cuXLly5cuXLl+lwZQa5lMJcuXLly5cuXLly5cuXLhp6Cgzl1zRNUuXLly5cpd dZcuXLLrrLly5cuaOIDHLnHrgtYCxLly5cuJzpFTVNtdLpK871XbdH2sr5zvEzbbDTVb6XWdpcRn aKmqLa6XSe21hMX+zL5ouILAs0111dC6aly5cuacWYuXHHlHLly5cuXLjdq1JQ6W6vPdz7THb/Qf yVwiXRaX9qPzjeHKrvApyZVfQa10mO3qPZ/ON4ud3gYDX6q/BrGKDsB1U5q+phxrLly5Q2kLT2ly 4o45xcuXLly5cuIGVESdi7OkLqruita8XmXBLBhLVrOl+o5HcVdl9E83A6OkuXLly5cuXHPHILly 5cuXLlyluWl1KC7ADtlat6soBl1aGEgaa1K1YZRm9TRTEECxyLjRQLvR66YOuYZyUxh1WGIAGjmY AT0KlO00yvu00u2jEcBodBriirqzMxdVTW5cuXLly5cuOYMhSxmQW7ly5cuXLlzxMeNctK0vqMdH tmFDA2BF6s33mK9irGIMeK86xetN1RS263dtX6msgPFXi1mullh1dY2gB1W6FhclBc3YZncTUr8W mhoui3uTwS5cuXLly4uABb6EuXLly5cuXLly5cuXLly5cuXLlx8IKX02XLly5cuXLly5cuXLly5c uXLly4+EFr6bLlys/wBIfqyy5cuXLly5cuXLly5cEuDUqdTJfBsVV23A9Y7bLlz8n8s5Twy5cuXL ly5cuXLly5c+gn2Z7QjqEqFFOnH37+uy5c/P/LOV8MuXLly5cuXLly5cuXPrPV79/UZcufm/lnJ+ GXLly4VoDA84ly5cuXLly59Z6nar7jhc/L/LOX8MuXH14PiOsHY6/wCR7Ndsn1DbFvTt1ly5cuB/ cE6hElxh1DUoOw9StX95Llz8n8sZdNk9o2NOsLVZQ/lF3YUPVL/pwPb07kVxU7PqXc2tmXLn0P2z R0mj2gaN9x+pfrsdj1C2dkCow4AmG87e2kXRMOifnjYcY71lqfV6X/PAVyUDx+UscgO9uCptDoaN 071/HHHjwamkzq89jdfPGw4Q2anU+va/5/gFKhSoUKFEzIERlyBcujT30n//2gAIAQMDAT8h6of7 e5hRbVrLa8IAAdRjMdLcahtywDWn087RUrXsZ8FYAO2Dx5TbHbR+4CSXpAABAAU6laMvUoOeOBI1 Guq6tMvEAAJBV2cya0eMSIFxtq67rxAAGgdI1FoeHV8EN3r1Tix1mCzI3mGSVBJ1H6/1Lo9AcBUS u6/qSgv73wGqwFj7/wClyi8GpoNzk4C9hwVTn3ZwapzwH5ZhgrLD18cFT6ni/fm+A/thkgvJTxZp NevS4WT1sNe2r8Tyfj3XV56YhvYwrgXL9ETb0L8t1+g4LTU/ctfjX2iNJyusbMzOZLFT5t+OAsre g8z/AIxhUDpTIPYau+QPnpGiK6rl9Ax2cuXMpAR5zC5cF7XiC5Hogz+iFFk1Lonfw6hMyy9dMfB/ 7G6XcH26E8cLRfxKRK1a9U9IfRS5cz3ZGfDWX1wLCaNX6iKk7+n2f7hpQFjM9txBc70Q3vfSDwpN 0sNeamIHWRVHjy/W8RW3X1AVbCXLme56KGIye2P3Jlt+ILmuiC18v5QAFU18HzfoiOzfBvxBex/P EKDHKC2JeX+UAB0HGfNfp6LuLfEvxOQd3/wgAA64s+R/T0RZG+QIeR6vrAvV9PQLVfT1AdBFqaEa oBDSHVr5r0AJqwgWw5p+pAFlmguiPILK+55LY9KN0613vWNsQZEU0C70vqy1d/GeAFlOgu1Hkllf nw0hg7tdivxbXa2AqWCoPTTU0Iu/pBUfiMD5fyBrGgLLJWS6ky6Hix11yqo6S86/4R2YcHnEDhel X1xvjO2YkGDnWFOtWt0X1udFCVebv/Au2YMPn+JNA8nYfJwd3SBJTZgvKhdOhkb0PQChTSUvO38p OxoBhArFQa4tla5XWS/wMcFKU8paUWi/aGNmZVXvXVOS14qOgVZf/jAI2xAE+rTtOoq0XbZoaApA IG6jQV0QMkdamAFwLFZFLBzlEqooZXClJqdKvLpiqmxzsDlKHUxC0Yj0HAHUbHXWqHRKzlaarUKI VdOiXwivbvTV/wAIixrDNAWfwAMNn320wX0DCHyNVwqQAUsAqlUqgJiSAWWrHPnVVaQ/MbjYdCgD QL73AEZjPfm1Z7FT0NI1wnPRkBBi1BwpdmlkArT3AqLcmlmmVeXX+IARjvyH/pAAAALNfkz/ANIA AAXxD8wcTEsPDHukLz/OAAUIRbpLhAJxEssAxh4cX8G4jotvwnNu5/OAAfNvzNbXc7ksnsl/iWoo 9V19u3GLO/iH4eIqHlhOS9z+cAA+R/n1A7I+TujxHQcsJl6cBoYOogX2i5Rcdb1vbt/CAcldfUBO G5i6PEVF6FYKiUvRcewx0KNFKHs5dqgbf1W0LfhRi9nR0YafOTevSCT9fVjS44do0jhODFEpfaWh ql+fSIZT7PnsPEVDEt1DtD19mva5RJajYgEtXpNMn8Dr7tvvC4v2Gtd3TxXARRh5uh/viXDgGNp7 4flYVRpdGKvu8RUfj+Ew51Rp/ROjLh2hQ/dn4JlWtf2djx9+kFPsUgwBqKq9QKoZ1lJTm7S6Vd9c Xjxq69A28u/Dg8+4/wCPijkW/MeDwj1SraugfE8eZXZ9i+P4nWg3tboWfJxeHGNTVg2jRUfh/A+f Pnz54+zSDCGgqnSFdjGs/9oADAMBAAIRAxEAABCmRAgIekIC1gl6QyeBOyJ/SBsZs6hQRuK8WiQD hvCTCLpaCSRs+fyLAEL/ALEOnbr2yj822W2UhTT6bA/wWAyEiX77rEkkkktsoiCjsfulm8l9ukJ5 uetZ7Zp15N8juJfPtvQZB3PSJPbcZbCcuDJZZLPv/vr0beFvttuxfJJfHgiPJJqKvJMttptMttvm ACgCABDDADbieSnCSTCSTASL7oRyyeyT22wH7dAtQAoAAABMmNmvy2XiXS3VEHHQzANqQaDFdNFE gtZ8U2jZL9dDKaw5RwW1/tt3/9oACAEBAwE/ECHLOd5XPX5sjmLeFTfOhR1yCFCKhxKnwL6FcBRH mnJgUL0mqjqxcj2fCXWUJQWQYLex2XYXDRHrwPdSPxczpPa5v7wVcYPwziA0U6rxm2jXDfxDTwAA BgntXK8B4T1j4dbcKUFJzJfBqdqRS6EQvACdLzc74WrW7DFDVQU9QxcCmFe4U88AywBUN6H8S36s GK2xMwx0+rgfB2RBV6ltbzn8TdX/ADHWGKEAYMYdKhQoqwESTTorWi1BtpGobSmeE6edLCCmmww9 kUq0oslOdZX9M3PrpOf9Tf3mS+//AG7yudsS6gIsgUCIDhYN0D7AWDwFCs10m/rzpK/qZt3+zrSt cc57xH4jSMlIYLL1L+DCQ7j9X3A1kyUrdFCxeqkLCHtkzzErOhIaC4hTWBRNAHoAXoCsq/dvontx 1m/ndl7d1+c00DAVS211RNAnrN8q+aZYKlLQ7po1suBvoUYp8kPmoLCdKThLA9mb+fvMH41QSvnU CtRAMsvJq81eb6x0cdo9W7dFxqwkDYKwmC0y+xXRoQATfOnn91U3/cxVdpyVOf7nPnzNofo/tlo9 x+Z3tX+vu9Zs/PB0Atfr08VHym6Xr3j5m05YTdX9afrg3c/cGgBqs6BIDdBfIIfBd7X8W4uZqPBB 5GL+bdaZF9kDmE84PZ1VXkwfRNZAZLhQsuHWH9py056zffnabvHO8sFawdHvOXOsdrS/pxy8L1+3 9MfLcH41xnSwOUbJfCIBAUOVSi1OqGZWN54vT0HuIoKRRJQu6/X0m774L27/AGe7Om1FG7p3Zunl +eAVjTKBICE/AgnDyDODT5Z3gEyEgzjwIAAAAAGAlM5m74/qfKYXnn+rm6YU1WGxxzpPI/fLmPIx +HO83qeJUheg/T+p/wBc9bhh7EFeZUrXsypd1+f659tJu51ljrV+zlN42m6HTFa+puqvfnE3HzN1 n+bTdz2n/XO83dObm7Pe5vef8m7/AJpmcufabts+Zu5/qX/uv9Zt7Svbk/Ud3J+B/bLCvKPtXUpO 9A+P0Tn8zO1ocfJyfX+pu5+po/2McPfxLNpGlW5YaYAAAdAAD4nde/PtOXtmZ9Zu0mnnzKHWd18/ jrN03bTfpz1xOXJPZ8zzw/ykz6dOdpt3ma093hb+GIleodtQlA9i9qZvzpMq00V/unS609vxzd/2 bvbWGes68/fWZ9Z+0386/ucz3+5v8TfPbz1nPOO03zfzqzfnPv2/Mz6/fmeeE+v6TZ7c9YeHPLPB 0fhv3LBvUPkZQb0Dn6Tf9wW+w++BpVv40pv5x5m+b5v/AM+Jvrab/uImqAoMiUsEpdgj2nPbhD35 P3BTIFEORlywthjRrfz2m/5Z4vDv3vnrPLCfUJAnJF2AvAauAPECOn3qDXaFE35ajVmWrRvLSvUI 0Beh/H9U3/v4lsnaUWAuEaYXgNRUW1bFdZur3++H/Oeek3zfW+8EU4oIML+y2kATXmCU4LVhG8tM IBJKZjv7RgTPw6/80NE608FSK1b/AClCl2Z6ztG6upnrDhhBhHJvm/l1Cc/M58+Ji3V/gh2Gzgu4 jKURjfz/AJN/PJLgvUt8UqC9B+ufh7Tntib+fab5v57Tf/X+Tf8At5zH7w73FabpQLvGGlFw0oEL RMtNHg0Qe655aL4H5VdUEO5MzKvonAOk6SqWVM3TBNji5Lux533ieULbAWiFmtYJm3aTh6UAIWg3 L9+am/npN8EPuEJKUiCMSpARUo7pDqt5/wBzf94+pcN6n8xrHY9exbTnz4nTrDzL9/7ud63+f1oz fX+e/ab6Pj9vaeb2+/zN/PLHB6qMAZZ0QK4IC8EpREsgzZYXv+Y4qwKIZkSAhhHrB0c5Gw1IxQYW 5IU6bIqO4Iplp9onERheVRhnfcPv/wBZvxL8/mb/ADf+5ubpu3Ju69WXBev3wpO9C+Bm+b5z50mv X7m+fXr4m/t9/wDZv4aYGjif2K88BeGv678SZw1tyslpnxpMxowiTPuOWY9tR7BJpgwJA6ZyKQsM uHpsH6UAdnByonMd5u2apgBJJW7shA2U2G+2ibudpz56zfN034m+eTz2xLDvUvkIbQlWZG5MiXcv XkGxpRkd5vzz1xPnvOvPJ7azfj8eKmnXtz7Tn7z685h4Y6Oe7OVxQuZf+XeT53EIFDRqW3hyD1bE mbiaNxo11qjsjFZUK24EQk1fHIBEes35+GDtPR4bpgYisxE00HMnsAD5WUFq5WeLfPib+dZv57+0 31++bm+v1N/3N+vP5lh3qXyEuWtV+frjpaWfjp7cb23z31m+b+f8nbfPb6m+u03895v08/meLN/3 z1m/n7ni9pv05qb+dZ0znzvN/wB/8mfXnv3n1w9pvJv/AMlh3qfyfvLlrWU6Hd/Hyazfz8zf9zn0 m/8AE3k38/qdt8/qV7/vm5v+5v8Aub+m039Cb+/4/ub6/E38/ib/AOpv+Obn/ef6udt/1N/3PN9p vlg3qOt6yuEa/Y/bzHS7jxj++b+fedOa2h+Rti6otWLqrGpVqabQR2BXU1N/3Px5Pib5vm9/E3f1 w75vm/n9zn2m/npN87bl4OCxr4IV0UQleF4uQKAGDHhOuCXGVQAyq/cccpqVaLM2IsqWPu3zDFdx 8Q3c5m/nrOZWgg8cPGt02n/PLgm/n6m6b+fib5v5eDn+Ju5/c6c89Jv/AMm+b5vlz938amIpggYJ yANDDWATUaRUqe4AFV3NzEsYK2bYa8gFjKmJQlaJp2WXKtV3VPiYnSz06D+5u+57Jja7/Ef1D0Sw fmubvaX7/f3N03c6zdz8TfN03zdzn8Toz/c3fc3S2l+0/wAYlrnVMeZ7JTt153my5Q3b8xcvetej 3eY7S/p3u83VXNzdjnbtOqdlvYfmWXuPTv8A3Uy69+0bGs5fNs3dvvH7jawQOlWkU9SGy6lHccIZ ZQIYC2bp2Xz2n+vzMOdpu7nTtN34+n2m7+t7mrUfPPmb+dIKnRT/AIVPAqPhNn+V0lb1ovx4SXpW r6e99x1e/wBcd3P6m6eUjLYJR2LHO/N+J+3PfEyCDD0k2JGQA7yzlI/VLBGgi6DkqiB1Y1k5ppqp Xwf5o4MWrpAmJum7rw7ud5U3etPFFQqSM1DhCauZLs4gDTVIvujyxsKDFHSn2mQsd3EvXUnRpOrH Pz14a+yfn8y1aW3+YYTS1rb+6bqnPSYc1Hp2+eU0vILUkpWadKtiBuNR+Eo0igRMwjq5NRWpAAKs OwB0BSjZWEUWw1UY8Go2OC9e7dB5w80pJH6kgr2ZWELcKGECpoZbDbtzHVPrv0fTGlI3mqDf/b3+ 5zZj7VPg/eN+TqsBhPAqFCIAxHZ3VIFdN5GjfDOieqQMo0WOfLtNk2/ibOSVPWjfsh8HDNJw8rM6 EkcOVt4awADqs0e97vZ+05l6kHnjOGW0JEKoBaWnMP8AW50aDsF/g1Wk5XRsg2bXE/2I0aKuDisG 9CKINLfua7sfU/DBRKCBM88WAastrAR9XhJz7ZUVnsOZe8afI72hHYrSci4aAFAbLo5l6ZnmXvH+ Z2YOZfeTnH6jafNM/wCRTp0k2A7vk4eFGNGX/9oACAECAwE/ELktmPs0+/JhAAOEIuuh0KdG1r1P EgYg8JIYopqab/SQIGSBfLm2r9DjhChmEW+TjggbWrZq3545QoIiL6cbBgjxT1elLsEjt8U2vqEC kiqZXHYda/cYLloS+nB9p+ZRm2YcofeVI1+J4jy5aHB9J9l+eGXK7EDilprLl9ZnxQLOtEVxK4Wg cTbu3sRn6n0R0x5US+D7j8wyTuPALrXpLi/oZSVjVGE2NCOzubnYLBAo0Jq4mW9w6R07D9+iTi1H TrvxB8jFTeJlxDkwOj1/5ACkL+JjWvAgKwWAdC+C+DCarrfHB9n7mhT7FXDFRWWYiNOsVM88P0hz rvFjtwd3Wd3BauhcqtWuD7ekMlvxxv24BpR2lzJvxEBRxMlHQ9INo8R9OJ4TNbypTMbj4+mq1l1j iWazun29A8plPpw4cTRHMqVLrga4LgJUYrcGUf4wAPC1TIPSfmeYqr0StSVreJCeJqnb6U6iYaeP ROsFjTrirfaz5ODs9BpXaNBbpEHFsramKk4PgI1HVwa5leg24ExKAwKgZYKB0wtBBi3Ai2nQmldD TVrFgFHnMmiuia9jm8S0NMsDIqElEILpllEANdAWshhpgHcAOhGRCAyChSWILOpmhFw9Az2IoBv6 A5xMPDifeYcZt+sIvEzaplmVFCiuza6aqg3VVYHuJqMWXwiULommjJ32uW2awfNZmBYXXBhGBS1u q8+waoU3pVi3cGrMx4RaX64Kdah1B7BFoYBEAACtqQs0HU9BHUGuqRGQQGnvM5fjZ0/b143h6J4S +BYGUMrQe7p3gDaB6IUPTbJ1t4QDUNEbH3JU0FqLQtdAvV8axig0hGYrJIoiyUASyuNqaRpOj2fH Do4K8FOC0xXpMeGifSW9+IazSyTaSoUw2qAsCqaoAMUMWh0xLdR6ubwKFhQK4WCz16WwJEtgB6oY ouGZjLVEr7FJFhZNrA7LRZjgCcEVa2MC1yg5crAu2ACjbtSij5Lp4nZDg+HBZD1VOXqK2+SEmo6T 6cT7cGiUl0JqdAqgVXkKH0KIz9UKNwIs7Wt73NVFUIZjILNBNTJ1SwJFzQdJOlSigAZVQgXYwuwH rZuGNYqIrGZgpXCwa2Gluq71rUEbYbBYcYhggFAacNvfi/b0AsZfhvvycTu4PLg8Nf4yAPlPpxO6 XSYTt1yGT0Dw9QKcTTwHEeU7uIcAAJm65DJxB19uFRda6seutFCqNX2rp04CNX8gALFoF0mVPIwh Jtha1NTFHUffgu8QCa1F5A7dhkOhcMTXLtTiUU8QYL6IMPWB9uDT5n0h5joR/gdQarv/AGdfiUJ9 3dfIn9yyYrBoOtq612qt+FIxJVz2Ti5tE69WAaP4QAavIEqV8caRmSrkskOBk82Ha4QZTVwLbOwR Wuj0M9DtKEKi2KpK0y63O7gy9QDfKYJUqV8wRISN1zmSXwZvMq4mMXCHIzV0Wl+YCA8oRXizG61O 0XKwAqwBgLCY3hoFFsOR2dShToX6QBxXVdGhS69t/EAgFgRsTTDjI6n+cGaQQ3WiEJoB8ErMqVNF CEqVcpk4mTzFpah93Ue4oealkaBpHCPk8QlJRoDKvajvDzzv8J7FHtGZUaOt6LwBadbO0vtF+cg6 XUs7hkejKXzDKjebsIX4CKU9UC3aagcTPdwzsyh1X7HqdcdZ5wAqe5b6WFTl0FdxLyvlqjQ6ypUq VBCgty1bghApYFqFqWFeLN5NWk+zxk6xHQNQ8wE+XfGnCF9ZPyM0U+kYvA61pO9cNTnpdB01SV+F PfXhLzxeVjCs2qNS1fLvGi36D6tq0nxTvx06SK66UHLUCfKd63gtXe4C1PGVChJDlK3UkClIUqUt /9oACAEDAwE/EKLIGNoeSBq6FjgBIiRC1EwF6EekIuTUOrVgXCrbEJFqW6k7BB4ADoQ4QQn3C3Lq zosoaABgEStEsTzM+ksXvl2ORychUMoAuroO3ExcUTaADKLVXKqq54liyiFgOipF5DAunF48V+Qu VuUVfKrxLFirhHnnWdqnqWVmpk9ddbXQsCoEJxMkUKDHu2PxSNI6Qdrv+aOKwFq6b8uwXanZX4AN atFsy8jpDuPTuj4iGul2S6D5OtOVTS16ZM6OXcONugu+wMQiLgUs1akFpxxcT5reGJR2v9zn1LLR KxKDnkG6jC6GrxdFvRdDHXLN2DchmXsIKmHOXd0OgLYli4/UFGU9f2AgNHkl9h04MMedhcLfA+RD aJ0QYc0urAZDLMKK7uBR5JNVNH+vQy4lZt5zvXb3qdfwBoiv5BorqhuZ2hRdVW1d/QHT5LeJyp0m l51Acf7pFOBUU6/mV+gKLpbNY1U6qqixV0zVgjSB2Smu128sevRV4I6gAF60WmFTEqIuoA3tZ7hF +wAAMC0ulpw59KOi5reOK/PU0tCtgt5AcDAIlr4CZglIcs35LNneg9h0hWyA0R6/5qOGG7xkqHtA vfLfpAeaMMQAi0Xd3Sxq+PAfXxV6Vmi0cEVIqbV1Xu+oFA5LeP7b+KallZDg5HL9iCUPFi7rBc4w 1nMPu35/5dEKn2H743tf4oqSPY/BeJ57Sz8SU3hgIA0KE06XoRU2K6rr/L0fsN/fE9h/HNDTbuCP Ed/yILfhx/Tw4/yf/qPYfvgY9r/BNTwbU4TxXf8AEywePrP+kudXWL7X39HsRGqC1gW6L7tNbPbj 7eP4mEbE1SuCeUuAA7Wj8hCscjQPAUt6Shpdz8Htg0EwvTxGBUgyJm167+p4Ctslo1LdLRq2AsMW mDSzDmrOr18GIqBa4O5ZbUmC7mOBbVYQkmjajYNcRFhjV6wvMzq8k7iFWxPkxFUTcgtgaYWiHo/w sYpTQt5Ww+Kfnj1PHsX+Cv5zQcNM+0CtBhFbgCqBwZDyruyg1odEeCDC5CKLdAXd1a606Mw4oB36 oBq0C3biCj5pwjIcq7tIKujoFlMw9G4KB6OXpPZEslR8fy3wITVm3ZleOZElNSK3iBMbvHpSda3E P6+r6NIC0CtBa46BlehDsHk2FZdecTbHBWxHqBE3HJLNeCoWhVrWgWZcRXwzgXIEkRCSm6WVllAW JY6Jeo99OP8Af1fqaBevoz6fT4exsLCo5MBbMg2bGVUyOUFxeZSAoVlUQeroBiyGwp1yUdAFavoi TbH8AS0VTL4uNiUGGYBXAowVCygyRaGbtphknUXy6EUVFw0tUeGrP4O9SzKB2Hgg+BKf4P8AR2gA yGxoBidGL4MVC9aiFqVBZxQQqWDciiQLQCWjY4oISRLBKWLDLi1TsCliJwHQKwBE5iqAMCTTKVpC 3ZUuRBQ6a1gJrQBEjVJFpsU5e/n+D/Q8aoJQtdh+Gbf/ABf/AP8AH0epJVRxxs/xP/n/AP8A/wCh Y9ASxb7fieO0pgUEqyzIJaQdLZwASwxldU1D+f8A/wCpigWsAoaJ9xaaIhdI5GlXua9OFAZ0lpgE 5CRSK0vVCVDBzfb8Lx/HUio9v51/v1B2/OgqsVSadh7dx6PcsasU9MHsrPuEI1WqQh1ALl1VutA1 lwwaim+1+jCwqj5fz+bVVyuXoFxd5tARc16AAG6nl6QBGs0AAuVuLpaw2ViXIGjSsdbGR2FN+P4Q BAua3oFhx6g9NEgVFR8+MDlox1xLcQUQvWmABClUOLwP2oF1aw30SWqytbQq3pmHGgQOZevFBBMK F+kDzqcixFBG1pLwF9YhJTi1VlluEbEUdxCEtEF2Ar9EbEPkhf36FiZVZQvZPRxNLIgL3Im0U+xE BhCIiI5ETCOokVg5AAGVVwAaseK6l74TwuE1CjmH7J25CCo7lo6hVrwUnRPQBkOtLQNHyBNDsBim KqrWwlVcVCFDIchdXeSuuvEgFtSQOaDJkzkUXVoiKNI2NI17GVu7EdpRrbpbBGLC6XaFox6QvgSj LV0LN+gKURZYlV3lRwAzBqrTs8ZMlUSxB6FXQUt0Nmatiio1nHvP2vylzrea6nF/E1cFGCkhDc9m KcGVlNGhwkyVMfMBwcwKyHRRZmjSC782XHQBhXVS8V14ydLq5UBeikqsuTFYt9YpUKVChAoRluyF k9LCkAb0/9k= --_004_E045AECD98228444A58C61C200AE1BD8221D85A6xmbrcdx01ciscoc_-- From pthubert@cisco.com Sat Oct 20 01:20:02 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 8AF6921F887D for ; Sat, 20 Oct 2012 01:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 bUSE9IU6caO8 for ; Sat, 20 Oct 2012 01:19:59 -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 09A9921F860D for ; Sat, 20 Oct 2012 01:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4546; q=dns/txt; s=iport; t=1350721199; x=1351930799; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=my+kbsEQS3YmkyzHOCzEtxkwYZGlMb/ejtue+x89kj8=; b=jCm1ngok6rIFttGRJfASfIzkaYWm/x8UyK1I0iYpQ003Q+Q4/RVblLdT SrafX+jznH+lODIOxxsCl6UvY8TyhARJUsetrRth0dmybUZnyCFpi0MK0 erHGbUBxuqcvNj2nKoeiXlAP5vX3QD3LJ/4z/hMzD6p1rVHwzTBjeiVD6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGleglCtJV2c/2dsb2JhbABEDsB/gQiCIAEBAQMBAQEBDwEnNAsFBwIEAQgOAwQBAQEKFAkiDAsUCQkBBAENBQgSAQeHXAYLm3mfZgSLVhqFdWADlwWNNoFrgjI9gWMXHg X-IronPort-AV: E=Sophos;i="4.80,621,1344211200"; d="scan'208";a="133693533" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 20 Oct 2012 08:19:39 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9K8JcKm032577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 08:19:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 03:19:38 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis , Owen Kirby Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2um3zKJUl7oGcgSNK+KxLSa35+rw== Date: Sat, 20 Oct 2012 08:19:37 +0000 Deferred-Delivery: Sat, 20 Oct 2012 08:19:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.80.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--48.729500-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: Sat, 20 Oct 2012 08:20:02 -0000 Phil; There is indeed lot of pressure for this in terms of header sizes and energ= y consumption in the *real world*. And there is no hack in the proposed solution. Simply we believe more in practical engineering and ML discussions than we = trust in crystal balls.=20 Cheers, Pascal -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: vendredi 19 octobre 2012 21:46 To: Owen Kirby Cc: Pascal Thubert (pthubert); roll@ietf.org Subject: Re: [Roll] using the flow label instead of hop by hop I realize there's a lot of pressure for this in terms of header sizes, but = this seems like exactly the kind of engineering hack/optimization that has = painful long-term implications. Such as the Internet of Things prevents the= flow label from ever being used effectively. Phil On Oct 19, 2012, at 11:59 AM, Owen Kirby wrote: > Pascal, >=20 > I'm not entirely convinced that using the flow label like this is a good = idea. Using the flow labels to carry the RPL HbH information works on the p= remise that packets being routed through the RPL domain wouldn't otherwise = use the flow label. This assumption might be correct in a network of homoge= nous nodes with no external prefixes (eg: appendix A.5), but there may stil= l be cases where packets being routed through the RPL domain might want to = set the flow label. If this draft were to go forward, I would have some que= stions: >=20 > When a forwarding node receives a packet with the flow label set, how do= es it determine whether the flow label contains an identifier of the 5-tupl= e, or it contains the RPL HbH information? To get it wrong would interfere = with the forwarding behavior and lead to interoperability issues. >=20 > When packets are received from an external prefix, how does the ingress r= outer handle the flow label? Would it destroy the original label, leave the= original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the = label (ie: the inner header contains the original flow label, and the outer= header contains the HbH information)? >=20 > How would the DODAG root rebuild the flow label from the 5-tuple if it en= counters packets that have been fragmented at the IPv6 layer? The primary u= se of the flow label is so that routers don't have to reassemble IPv6 fragm= ents when forwarding to determine the 5-tuple (which is a challenging thing= for a router to do). >=20 > Cheers, > Owen >=20 > On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: >> Hi >> =20 >> When I started this draft, we had a series of chats with Brian Carpenter= and apparently reached a gentleman agreement that it was doable within the= RPL domain to use the flow label and avoid the Hop by Hop option. >> =20 >> I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 = based on that discussion but did not get news from the group since then. >> =20 >> This technique has a number of advantages, in particular -it saves=20 >> extra bytes for the RPL option and the HbH header. >> -it also avoids the prescribed tunneling within the RPL domain for packe= ts from the outside. >> - it has an optimized compression with 6LoWPAN. >> =20 >> Is there interest in the group to continue? If so I'd be glad to have so= me discussion time at the next meeting. >> =20 >> Cheers, >> =20 >> =20 >>=20 >> Pascal Thubert >> IPv6 Engineering >>=20 >> pthubert@cisco.com >> Phone :+33 497 23 26 34 >> Mobile :+33 619 98 29 85 >>=20 >>=20 >> Cisco Systems >> Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille >> 06410 Biot - Sophia Antipolis >> France >>=20 >> Cisco.com >>=20 >> >>=20 >> For corporate legal information go to:=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> This e-mail may contain confidential and privileged material for the sol= e use of the intended recipient. Any review, use, distribution or disclosur= e by others is strictly prohibited. If you are not the intended recipient (= or authorized to receive for the recipient), please contact the sender by r= eply e-mail and delete all copies of this message. >> =20 >> =20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >>=20 >> 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 pthubert@cisco.com Sat Oct 20 01:56: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 E19FD21F8789 for ; Sat, 20 Oct 2012 01:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.336 X-Spam-Level: X-Spam-Status: No, score=-9.336 tagged_above=-999 required=5 tests=[AWL=1.263, 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 xb7Lc2jnD5Ma for ; Sat, 20 Oct 2012 01:56:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB821F8640 for ; Sat, 20 Oct 2012 01:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1360; q=dns/txt; s=iport; t=1350723401; x=1351933001; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=boLiUOk9NiT1c1IFm/xgjAUe39MI7vyqvh0sqbCTb0k=; b=XBIwjWE4M7hflbDbZePRvqwpWrwikvakt5gGTxP7cHkwsL+5t6SX5fK6 tmlzMdI5SXvUiLLVohMzP8X2kZPgXt/pGuUoZyVFcAHgerH+k41Gwhso3 ANCoIZ2+QheNofGVqFFl9N5+CD61nLeL5e0RTP0mGGdoh76Cznxss+bFw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMJmglCtJV2Z/2dsb2JhbABEwQ2BCIIgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAEBBA4FCBIEBIdiC5txn2WLWoYPYAOXBY02gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,621,1344211200"; d="scan'208";a="133644108" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2012 08:56:40 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9K8uevL032085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 08:56:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 03:56:40 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2tT14B78zttzpFSgOnw7I7S2GAIwA19ZqAAB49RjA= Date: Sat, 20 Oct 2012 08:56:39 +0000 Deferred-Delivery: Sat, 20 Oct 2012 08:56:00 +0000 Message-ID: References: <20123.1350653167@obiwan.sandelman.ca> In-Reply-To: <20123.1350653167@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.80.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--39.638600-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: Sat, 20 Oct 2012 08:56:42 -0000 Hello Michael: This is actually what the early RPL drafts would do.=20 But at the time that collisioned with work at 6MAN, so we opted for the HbH= /encaps alternate. Now that the 6MAN work has stabilized, we have the opportunity to reconside= r. The bright side is that Brian helped and the current draft incorporates the= resolution of his comments. Cheers, Pascal -----Original Message----- From: mcr@obiwan.sandelman.ca [mailto:mcr@obiwan.sandelman.ca] On Behalf Of= Michael Richardson Sent: vendredi 19 octobre 2012 15:26 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] using the flow label instead of hop by hop >>>>> "pthubert" =3D=3D pthubert writes: pthubert> I published pthubert> pthubert> http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 b= ased on that discussion but did not get news from the group since then.=20 pthubert> This technique has a number of advantages, in particular pthubert> -it saves extra bytes for the RPL option and the HbH pthubert> header. Has it been field tested? i.e. has it got code? Is there some other interest it it? It seems like a big win to me. --=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From jeonggil.ko@gmail.com Sat Oct 20 02:02:30 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 484B721F8789 for ; Sat, 20 Oct 2012 02:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 bkeIFz4Bavuc for ; Sat, 20 Oct 2012 02:02:29 -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 0413221F860D for ; Sat, 20 Oct 2012 02:02:22 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so607671dan.31 for ; Sat, 20 Oct 2012 02:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tF8pgE02HNsoetZBL2L1zbicgbNwZb1/e77q1X0GRPI=; b=TOxMf+YQbT2pfxJVwXsHCC2tE3Su5pmstirFvIqzvX1Yd6/VXO04FFGQkFcjE0KEBs lKmrmFhQHVs/hLuRGfDaMo6MPIgZtE0CqcyNg+Fa9Az5Fd0YskjB8+yrZraosUZJDICw xSBvB33af5r1filAQo/dTNyQVzOD3tDDDymx71NtlfMz3PNQ9Ht+qs6r79yB/H80ESJq pLqsJ/wjC8asAu2D/sO6Bk0HVaBeBDj1hHFHvpWPv26UXYgxD19f+Ejo7Enx8qyuC8vP br/Le7CQs3GktfDZPeVXBWyhmf8p9Bg59DJzr86A5cKRWmRzS/QOSv2kagtz0Lri/q1V wtQg== Received: by 10.68.235.71 with SMTP id uk7mr14114733pbc.10.1350723741486; Sat, 20 Oct 2012 02:02:21 -0700 (PDT) Received: from [10.211.10.10] ([129.254.38.231]) by mx.google.com with ESMTPS id j10sm2461964pax.4.2012.10.20.02.02.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Oct 2012 02:02:20 -0700 (PDT) Sender: "JeongGil (John) Ko" Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: JeongGil Ko Date: Sat, 20 Oct 2012 18:02:14 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121020080910.1372.90616.idtracker@ietfa.amsl.com> To: roll@ietf.org X-Mailer: Apple Mail (2.1499) Cc: =?utf-8?Q?=EB=B0=95=EC=A2=85=EC=A4=80_Park?= Subject: [Roll] Fwd: New Version Notification for draft-ko-roll-mix-network-pathology-01.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: Sat, 20 Oct 2012 09:02:30 -0000 Dear RoLL WG, Please review this updated version of = draft-ko-roll-mix-network-pathology.=20 This draft discusses about the routing pathologies that occur when = storing and non-storing mode nodes are mixed together in a single = network. Compared to the previous version of the draft, we have = addressed some of the comments from the mailing list and added in an = additional case where the mixture of storing and non-storing mode nodes = can affect the performance of the RPL network for *collection traffic* = as well as downwards connectivity. As the draft indicates, due to RPL = restricting different MOPs from fully functioning in the same network = (e.g., one MOP is forced to be a leaf), differences in downwards routing = schemes affects the route quality for collection traffic as well. = Specifically, due to different MOPs despite having physical connectivity = to the root, a node may not be able to find a routing connection to the = root. Given that collection is the main focus in many applications, this = is something that needs to be addressed. As a side comment, this draft addresses some of the issues that came up = in our large scale HVAC supporting WSN system deployment in a 15 story = building. We plan to install ~2000 sensors and actuators in this = building for HVAC related applications (e.g., CO, Temp, Hum, PIR sensors = and Air Conditioning, light, ventilation, heating controlling = actuators).=20 Cost reasons restrict us to have resource rich devices on the sensor = devices but actuation units (which are pretty expensive already) can be = resource rich (i.e., sensing devices will have similar capabilities to = an MSP430 while the actuators are more Cortex M3-like MCUs). Since these = sensor devices cannot support storing mode routing, and RPL restricts us = from having a mixture of storing and non-storing mode nodes, all nodes = will have to be non-storing mode nodes for the network to be RPL = compliant. While sensor nodes typically generate collection-direction traffic, to = make the actuators take action, downwards packets would need to be = generated; thus, this would increase the number of downwards packets and = make the network/transmission quality/efficiency for the downwards = routes an important factor to consider. By adding in features such as = application layer acknowledgements, the quantity of downwards traffic = will increase even more.=20 Nevertheless a few inefficiencies exist with downwards routes in our = application when using the non-storing mode ONLY. (1) First, due to the = increased number of nodes, the length of the source routing headers can = result to be long. (2) Second, the number of hops that =93actuation=94 = messages travel increases, since most of these, essentially downwards, = packets would need to travel all the way to the root before being = transmitted downwards. (3) Third, the increased quantity in downwards = traffic will give more load on the one hop neighborhood of the DODAG = root since the root would need to deal with sensor reports in large = quantities (e.g., collection) and also actuation messages in increased = quantities (e.g., downwards). (4) Fourth, given that the locations of = the sensor and actuator units are not adjustable (e.g., the placement = must be close to the actual sensing/actuation units) it is difficult to = overcome this inefficiency by simply improving the network topology. Given this, we can think of a case where more powerful nodes have = storing mode capabilities. This change can *ideally* resolve the issues = that we introduced above. Nevertheless, the DODAG root should be able to = attach source routing headers for its non-storing mode sensor nodes to = forward downwards packets; therefore, the root should implement = non-storing mode. In this case, even if the actuators are configured as = storing mode nodes, given RPL, they can only act as leaf nodes. By = forcing storing mode nodes to be leaf nodes brings back the issues = introduced above. Furthermore, since we cannot use these nodes for = collection traffic forwarding, this will affect the data collection = performance as well. Therefore, we are in need of a scheme that can mix = storing and non-storing mode nodes in a single network effectively. By allowing both storing and non-storing modes to fully interoperate (as = the draft indicates), the number of downwards messages that the DODAG = root MUST take care of can decrease given that actuator nodes with = storing capabilities can add source routing headers within the network = to cool down the hot-spot near the DODAG root and also reduce the number = of hops that each packet travels to reach the final destination. = Furthermore, since all nodes will participate in the DODAG construction = process as routing-capable nodes, the quality of the selected links can = potentially increase; thus, improving the performance of collection = routes as well. Due to the aforementioned reasons, we are proposing the attached draft. = Our proposal in the draft introduces light-weight modifications to the = current RPL specs so that RPL can also support the cases mentioned = above. With minimal increase in complexity, RPL will be able to tolerate = more types of networks and you won't need to worry about which MOP your = neighbors installed on their RPL network! :) Your review and thoughts = will be of great help in improving the draft :) Thanks! -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ Begin forwarded message: > From: > Subject: New Version Notification for = draft-ko-roll-mix-network-pathology-01.txt > Date: October 20, 2012 5:09:10 PM GMT+09:00 > To: > Cc: , , , = , >=20 >=20 >=20 > A new version of I-D, draft-ko-roll-mix-network-pathology-01.txt > has been successfully submitted by JeongGil Ko and posted to the > IETF repository. >=20 > Filename: draft-ko-roll-mix-network-pathology > Revision: 01 > Title: RPL Routing Pathology In a Network With a Mix = of Nodes Operating in Storing and Non-Storing Modes > Creation date: 2012-10-20 > WG ID: Individual Submission > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-ko-roll-mix-network-pathology-01= .txt > Status: = http://datatracker.ietf.org/doc/draft-ko-roll-mix-network-pathology > Htmlized: = http://tools.ietf.org/html/draft-ko-roll-mix-network-pathology-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ko-roll-mix-network-pathology-01 >=20 > Abstract: > The RPL specification allows nodes running with storing or non- > storing modes to operate in the same network. We describe how such = a > mix can result in network partitioning even when there are plenty of > physical links available in the network. The partitioning affects > both upwards (nodes to root) and downwards (root to leaf) traffic. > This routing pathology stems from a recommendation made in the RPL > specification forcing nodes with different modes of operation to = join > the RPL network as leaf nodes only. We propose a solution that > modifies RPL by mandating that all the nodes parse and interpret > source routing headers and storing mode nodes to sometimes act like = a > non-storing mode root by attaching source routing headers. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From abdussalambaryun@gmail.com Sat Oct 20 03:04: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 C340A21F8A59 for ; Sat, 20 Oct 2012 03:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 dI+8CzNOA4Ha for ; Sat, 20 Oct 2012 03:04:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7021F88FE for ; Sat, 20 Oct 2012 03:04:46 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1526874vcb.31 for ; Sat, 20 Oct 2012 03:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Q/LHSnjpcA8jcd7hSf1FMSPwfbE2ZqSco69MRVJis3Q=; b=GMEfhJZ0GgO4gS4L38NLSyMdf0LG71OP6/zWMtDhWSvU2BiNtZ18rYx0UmLaLWXJD1 kv2Kqnsmes+/aATbHsQOzVvIZqvXhRnlKh0FLrqdrlEItCe9c2xXA25ysT9d1Oj0Jr3L kHyoQluxEuc4iAmrW/0iT9Qn/eNwM5DNEB3tvilft8mQDIw3MNFe853v37F1k+CUR4Ov e2CL5T90+e9wDdLhqHniyc+BKBjNCHdpAw8bHpxV/iaN1E8odS7Rg+aC6TQ9Jh8wgkpQ 7zPCxslQ4mazRU3Tbm+6H76IjKpkLqeaQrHNiyaA+uIK7Tcr3NyF6zhCDMGyHSU0mIQx jEDA== MIME-Version: 1.0 Received: by 10.220.142.8 with SMTP id o8mr5055721vcu.23.1350727485346; Sat, 20 Oct 2012 03:04:45 -0700 (PDT) Received: by 10.220.204.9 with HTTP; Sat, 20 Oct 2012 03:04:45 -0700 (PDT) In-Reply-To: References: <20121020080910.1372.90616.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2012 12:04:45 +0200 Message-ID: From: Abdussalam Baryun To: JeongGil Ko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?67CV7KKF7KSAIFBhcms=?= , roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ko-roll-mix-network-pathology-01.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: Sat, 20 Oct 2012 10:04:49 -0000 Hi John, I interested in your proposal, and like to see the draft team present it to ROLL 85 meeting if available, I have commented before draft-00, and my full comments will come when completed. AB On 10/20/12, JeongGil Ko wrote: > Dear RoLL WG, > > Please review this updated version of draft-ko-roll-mix-network-pathology= . > > This draft discusses about the routing pathologies that occur when storin= g > and non-storing mode nodes are mixed together in a single network. Compar= ed > to the previous version of the draft, we have addressed some of the comme= nts > from the mailing list and added in an additional case where the mixture o= f > storing and non-storing mode nodes can affect the performance of the RPL > network for *collection traffic* as well as downwards connectivity. As th= e > draft indicates, due to RPL restricting different MOPs from fully > functioning in the same network (e.g., one MOP is forced to be a leaf), > differences in downwards routing schemes affects the route quality for > collection traffic as well. Specifically, due to different MOPs despite > having physical connectivity to the root, a node may not be able to find = a > routing connection to the root. Given that collection is the main focus i= n > many applications, this is something that needs to be addressed. > > As a side comment, this draft addresses some of the issues that came up i= n > our large scale HVAC supporting WSN system deployment in a 15 story > building. We plan to install ~2000 sensors and actuators in this building > for HVAC related applications (e.g., CO, Temp, Hum, PIR sensors and Air > Conditioning, light, ventilation, heating controlling actuators). > > Cost reasons restrict us to have resource rich devices on the sensor devi= ces > but actuation units (which are pretty expensive already) can be resource > rich (i.e., sensing devices will have similar capabilities to an MSP430 > while the actuators are more Cortex M3-like MCUs). Since these sensor > devices cannot support storing mode routing, and RPL restricts us from > having a mixture of storing and non-storing mode nodes, all nodes will ha= ve > to be non-storing mode nodes for the network to be RPL compliant. > > While sensor nodes typically generate collection-direction traffic, to ma= ke > the actuators take action, downwards packets would need to be generated; > thus, this would increase the number of downwards packets and make the > network/transmission quality/efficiency for the downwards routes an > important factor to consider. By adding in features such as application > layer acknowledgements, the quantity of downwards traffic will increase e= ven > more. > > Nevertheless a few inefficiencies exist with downwards routes in our > application when using the non-storing mode ONLY. (1) First, due to the > increased number of nodes, the length of the source routing headers can > result to be long. (2) Second, the number of hops that =93actuation=94 me= ssages > travel increases, since most of these, essentially downwards, packets wou= ld > need to travel all the way to the root before being transmitted downwards= . > (3) Third, the increased quantity in downwards traffic will give more loa= d > on the one hop neighborhood of the DODAG root since the root would need t= o > deal with sensor reports in large quantities (e.g., collection) and also > actuation messages in increased quantities (e.g., downwards). (4) Fourth, > given that the locations of the sensor and actuator units are not adjusta= ble > (e.g., the placement must be close to the actual sensing/actuation units)= it > is difficult to overcome this inefficiency by simply improving the networ= k > topology. > > Given this, we can think of a case where more powerful nodes have storing > mode capabilities. This change can *ideally* resolve the issues that we > introduced above. Nevertheless, the DODAG root should be able to attach > source routing headers for its non-storing mode sensor nodes to forward > downwards packets; therefore, the root should implement non-storing mode.= In > this case, even if the actuators are configured as storing mode nodes, gi= ven > RPL, they can only act as leaf nodes. By forcing storing mode nodes to be > leaf nodes brings back the issues introduced above. Furthermore, since we > cannot use these nodes for collection traffic forwarding, this will affec= t > the data collection performance as well. Therefore, we are in need of a > scheme that can mix storing and non-storing mode nodes in a single networ= k > effectively. > > By allowing both storing and non-storing modes to fully interoperate (as = the > draft indicates), the number of downwards messages that the DODAG root MU= ST > take care of can decrease given that actuator nodes with storing > capabilities can add source routing headers within the network to cool do= wn > the hot-spot near the DODAG root and also reduce the number of hops that > each packet travels to reach the final destination. Furthermore, since al= l > nodes will participate in the DODAG construction process as routing-capab= le > nodes, the quality of the selected links can potentially increase; thus, > improving the performance of collection routes as well. > > Due to the aforementioned reasons, we are proposing the attached draft. O= ur > proposal in the draft introduces light-weight modifications to the curren= t > RPL specs so that RPL can also support the cases mentioned above. With > minimal increase in complexity, RPL will be able to tolerate more types o= f > networks and you won't need to worry about which MOP your neighbors > installed on their RPL network! :) Your review and thoughts will be of gr= eat > help in improving the draft :) > > Thanks! > > -John > > ------ > JeongGil Ko, Ph.D. > Researcher > Electronics and Telecommunications Research Institute (ETRI) > http://sites.google.com/site/jeonggilko/ > > Begin forwarded message: > >> From: >> Subject: New Version Notification for >> draft-ko-roll-mix-network-pathology-01.txt >> Date: October 20, 2012 5:09:10 PM GMT+09:00 >> To: >> Cc: , , , >> , >> >> >> >> A new version of I-D, draft-ko-roll-mix-network-pathology-01.txt >> has been successfully submitted by JeongGil Ko and posted to the >> IETF repository. >> >> Filename: draft-ko-roll-mix-network-pathology >> Revision: 01 >> Title: RPL Routing Pathology In a Network With a Mix of Nodes Operatin= g >> in Storing and Non-Storing Modes >> Creation date: 2012-10-20 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-ko-roll-mix-network-pathology-= 01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-ko-roll-mix-network-pathology >> Htmlized: >> http://tools.ietf.org/html/draft-ko-roll-mix-network-pathology-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ko-roll-mix-network-pathology-0= 1 >> >> Abstract: >> The RPL specification allows nodes running with storing or non- >> storing modes to operate in the same network. We describe how such a >> mix can result in network partitioning even when there are plenty of >> physical links available in the network. The partitioning affects >> both upwards (nodes to root) and downwards (root to leaf) traffic. >> This routing pathology stems from a recommendation made in the RPL >> specification forcing nodes with different modes of operation to join >> the RPL network as leaf nodes only. We propose a solution that >> modifies RPL by mandating that all the nodes parse and interpret >> source routing headers and storing mode nodes to sometimes act like a >> non-storing mode root by attaching source routing headers. >> >> >> >> >> The IETF Secretariat >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jeonggil.ko@gmail.com Sat Oct 20 03:09: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 13F8521F8640 for ; Sat, 20 Oct 2012 03:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 o65Km0HeP-Ay for ; Sat, 20 Oct 2012 03:09:33 -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 0954121F8422 for ; Sat, 20 Oct 2012 03:09:33 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so941419pad.31 for ; Sat, 20 Oct 2012 03:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Qba2clcmUvDrhXDtTuJKfwCknBqsFIbcC778aNAuAtA=; b=hsFrp8j4lVTLioIMt/dWoUZ7al8N7MLaI76iU7+MWHKcgyMoh3vgMHBhu/Q2c3K5ol kIB1vgdwZs9+5GkIr3HjFkhJAsY0iWZ2zTDqQFbcmJ23uBH6urpS5y8SOV2oo6gLQazC f5gbWuXrrC0eNsAYTDgoew/zpjRWY/lZZ1Ce9CAvSkmrBHnX2JZg62yURB3wdeG45nfV i5/GOkZL1RmpZ7p4WHqeDowChe2SGrumPA/pdhiWBdly5xyiuhLo+VLKB0V1JfQvfKnn aRcf9Gi6+OzZxYgxhKHnLCKxCdgrNy3ORz1A0VZs8yIMU6Hw7QdPAN5OYJenbrPJ6Leg rgqw== Received: by 10.68.241.170 with SMTP id wj10mr10142545pbc.56.1350727772455; Sat, 20 Oct 2012 03:09:32 -0700 (PDT) Received: from [10.211.10.10] ([129.254.38.231]) by mx.google.com with ESMTPS id oj1sm2647198pbb.19.2012.10.20.03.09.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Oct 2012 03:09:31 -0700 (PDT) Sender: "JeongGil (John) Ko" Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: JeongGil Ko In-Reply-To: Date: Sat, 20 Oct 2012 19:09:26 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <112E19DC-138E-4D21-ABA1-592B5A09CC48@etri.re.kr> References: <20121020080910.1372.90616.idtracker@ietfa.amsl.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: =?utf-8?Q?=EB=B0=95=EC=A2=85=EC=A4=80_Park?= , roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ko-roll-mix-network-pathology-01.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: Sat, 20 Oct 2012 10:09:34 -0000 Abdussalam, I am also hoping to present this draft at the meeting :) Thank you for the comments on -00, your points have beed addressed in = -01.=20 Thanks! -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 20, 2012, at 7:04 PM, Abdussalam Baryun = wrote: >=20 > Hi John, > I interested in your proposal, and like to see the draft team present > it to ROLL 85 meeting if available, I have commented before draft-00, > and my full comments will come when completed. >=20 > AB >=20 > On 10/20/12, JeongGil Ko wrote: >> Dear RoLL WG, >>=20 >> Please review this updated version of = draft-ko-roll-mix-network-pathology. >>=20 >> This draft discusses about the routing pathologies that occur when = storing >> and non-storing mode nodes are mixed together in a single network. = Compared >> to the previous version of the draft, we have addressed some of the = comments >> from the mailing list and added in an additional case where the = mixture of >> storing and non-storing mode nodes can affect the performance of the = RPL >> network for *collection traffic* as well as downwards connectivity. = As the >> draft indicates, due to RPL restricting different MOPs from fully >> functioning in the same network (e.g., one MOP is forced to be a = leaf), >> differences in downwards routing schemes affects the route quality = for >> collection traffic as well. Specifically, due to different MOPs = despite >> having physical connectivity to the root, a node may not be able to = find a >> routing connection to the root. Given that collection is the main = focus in >> many applications, this is something that needs to be addressed. >>=20 >> As a side comment, this draft addresses some of the issues that came = up in >> our large scale HVAC supporting WSN system deployment in a 15 story >> building. We plan to install ~2000 sensors and actuators in this = building >> for HVAC related applications (e.g., CO, Temp, Hum, PIR sensors and = Air >> Conditioning, light, ventilation, heating controlling actuators). >>=20 >> Cost reasons restrict us to have resource rich devices on the sensor = devices >> but actuation units (which are pretty expensive already) can be = resource >> rich (i.e., sensing devices will have similar capabilities to an = MSP430 >> while the actuators are more Cortex M3-like MCUs). Since these sensor >> devices cannot support storing mode routing, and RPL restricts us = from >> having a mixture of storing and non-storing mode nodes, all nodes = will have >> to be non-storing mode nodes for the network to be RPL compliant. >>=20 >> While sensor nodes typically generate collection-direction traffic, = to make >> the actuators take action, downwards packets would need to be = generated; >> thus, this would increase the number of downwards packets and make = the >> network/transmission quality/efficiency for the downwards routes an >> important factor to consider. By adding in features such as = application >> layer acknowledgements, the quantity of downwards traffic will = increase even >> more. >>=20 >> Nevertheless a few inefficiencies exist with downwards routes in our >> application when using the non-storing mode ONLY. (1) First, due to = the >> increased number of nodes, the length of the source routing headers = can >> result to be long. (2) Second, the number of hops that =93actuation=94 = messages >> travel increases, since most of these, essentially downwards, packets = would >> need to travel all the way to the root before being transmitted = downwards. >> (3) Third, the increased quantity in downwards traffic will give more = load >> on the one hop neighborhood of the DODAG root since the root would = need to >> deal with sensor reports in large quantities (e.g., collection) and = also >> actuation messages in increased quantities (e.g., downwards). (4) = Fourth, >> given that the locations of the sensor and actuator units are not = adjustable >> (e.g., the placement must be close to the actual sensing/actuation = units) it >> is difficult to overcome this inefficiency by simply improving the = network >> topology. >>=20 >> Given this, we can think of a case where more powerful nodes have = storing >> mode capabilities. This change can *ideally* resolve the issues that = we >> introduced above. Nevertheless, the DODAG root should be able to = attach >> source routing headers for its non-storing mode sensor nodes to = forward >> downwards packets; therefore, the root should implement non-storing = mode. In >> this case, even if the actuators are configured as storing mode = nodes, given >> RPL, they can only act as leaf nodes. By forcing storing mode nodes = to be >> leaf nodes brings back the issues introduced above. Furthermore, = since we >> cannot use these nodes for collection traffic forwarding, this will = affect >> the data collection performance as well. Therefore, we are in need of = a >> scheme that can mix storing and non-storing mode nodes in a single = network >> effectively. >>=20 >> By allowing both storing and non-storing modes to fully interoperate = (as the >> draft indicates), the number of downwards messages that the DODAG = root MUST >> take care of can decrease given that actuator nodes with storing >> capabilities can add source routing headers within the network to = cool down >> the hot-spot near the DODAG root and also reduce the number of hops = that >> each packet travels to reach the final destination. Furthermore, = since all >> nodes will participate in the DODAG construction process as = routing-capable >> nodes, the quality of the selected links can potentially increase; = thus, >> improving the performance of collection routes as well. >>=20 >> Due to the aforementioned reasons, we are proposing the attached = draft. Our >> proposal in the draft introduces light-weight modifications to the = current >> RPL specs so that RPL can also support the cases mentioned above. = With >> minimal increase in complexity, RPL will be able to tolerate more = types of >> networks and you won't need to worry about which MOP your neighbors >> installed on their RPL network! :) Your review and thoughts will be = of great >> help in improving the draft :) >>=20 >> Thanks! >>=20 >> -John >>=20 >> ------ >> JeongGil Ko, Ph.D. >> Researcher >> Electronics and Telecommunications Research Institute (ETRI) >> http://sites.google.com/site/jeonggilko/ >>=20 >> Begin forwarded message: >>=20 >>> From: >>> Subject: New Version Notification for >>> draft-ko-roll-mix-network-pathology-01.txt >>> Date: October 20, 2012 5:09:10 PM GMT+09:00 >>> To: >>> Cc: , , , >>> , >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-ko-roll-mix-network-pathology-01.txt >>> has been successfully submitted by JeongGil Ko and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-ko-roll-mix-network-pathology >>> Revision: 01 >>> Title: RPL Routing Pathology In a Network With a Mix = of Nodes Operating >>> in Storing and Non-Storing Modes >>> Creation date: 2012-10-20 >>> WG ID: Individual Submission >>> Number of pages: 9 >>> URL: >>> = http://www.ietf.org/internet-drafts/draft-ko-roll-mix-network-pathology-01= .txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-ko-roll-mix-network-pathology >>> Htmlized: >>> http://tools.ietf.org/html/draft-ko-roll-mix-network-pathology-01 >>> Diff: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ko-roll-mix-network-pathology-01 >>>=20 >>> Abstract: >>> The RPL specification allows nodes running with storing or non- >>> storing modes to operate in the same network. We describe how such = a >>> mix can result in network partitioning even when there are plenty = of >>> physical links available in the network. The partitioning affects >>> both upwards (nodes to root) and downwards (root to leaf) traffic. >>> This routing pathology stems from a recommendation made in the RPL >>> specification forcing nodes with different modes of operation to = join >>> the RPL network as leaf nodes only. We propose a solution that >>> modifies RPL by mandating that all the nodes parse and interpret >>> source routing headers and storing mode nodes to sometimes act like = a >>> non-storing mode root by attaching source routing headers. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 From philip.levis@gmail.com Sat Oct 20 06:50: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 B962921F84E0 for ; Sat, 20 Oct 2012 06:50:17 -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 uZAC2rSTMAfV for ; Sat, 20 Oct 2012 06:50:17 -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 DD47021F8432 for ; Sat, 20 Oct 2012 06:50:16 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1077628pbb.31 for ; Sat, 20 Oct 2012 06:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8TK3t7h/tu56kMi82R5avT3UNs9sowydIhfXBzBKpSs=; b=Tkapl4OK7/EDuBOhOMJ7l0msZ/KqIZFn1E9lYsTH8a6vAI8ax/o5GlAQWCVlhUBvK3 lh3vFL4mn5i+J5piyZbfAC0KAIrSdTwOZ1QNC4AEUdue+17QtjkMfR50L+gVO1iXjyu9 IJyIobXl49T3J0lwLQtSSHFJwFm10hepA9cFDaSKJ1B/Sjs8CU+2g48dAe/21zmOfs+4 R4sKngxhqHHIrkW5sn/Uz1gAK+BAzryp+dW10VQXYJnStDKecqKmE/hG/mj6ekMLpDxh eMY4G+qxTIK3Ri2A46xteC8JfVNRmpueQQd6cAF28FjEnHTv+EmWIXD0LZ1ndw8uHou+ S4XA== Received: by 10.68.237.167 with SMTP id vd7mr5773617pbc.161.1350741016549; Sat, 20 Oct 2012 06:50:16 -0700 (PDT) Received: from [192.168.0.106] ([76.14.66.110]) by mx.google.com with ESMTPS id oi2sm2866210pbb.62.2012.10.20.06.50.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Oct 2012 06:50:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Sat, 20 Oct 2012 06:50:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33921BF9-9D15-49F8-AB15-55740DC984E1@gmail.com> References: To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) 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: Sat, 20 Oct 2012 13:50:18 -0000 On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > Phil; >=20 > There is indeed lot of pressure for this in terms of header sizes and = energy consumption in the *real world*. I'm personally concerned about header sizes and energy consumption in = The Matrix. Because I don't live in the real world. Oh, wait, sorry, I = do. Can you walk me through the quantitative reasoning that a few bytes = of header will increase energy consumption? It the belief that it will = lead to sub-packet fragmentation in some non-amortized sense? Generally = speaking, in low power wireless networks, energy consumption is = dominated by idle listening and communication latency/interval support, = not the length of packets. Of course there is a spectrum of low power = approaches and their point on that spectrum. Are you thinking of one in = particular? Could implementers who are encountering this pressure comment? I'm a = sucker for and easily swayed by quantitative data as well as first-hand = rather than second-hand reports. > And there is no hack in the proposed solution. > Simply we believe more in practical engineering and ML discussions = than we trust in crystal balls.=20 *coughs politely* I believe in very practical engineering that considers = long term consequences. Solving a problem a certain way now might cause = significant problems in the future. I agree this is a tradeoff -- in my = personal opinion, nothing more, the tradeoff on this one is 100% clear. Phil ------ Philip Levis President, Kumu Networks Associate Professor, Stanford University http://csl.stanford.edu/~pal From adrian@olddog.co.uk Sat Oct 20 12:37: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 D5A4B21F88CF for ; Sat, 20 Oct 2012 12:37:08 -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 l10Vv56DngXc for ; Sat, 20 Oct 2012 12:37:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1516221F8837 for ; Sat, 20 Oct 2012 12:37:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9KJb5mH025661 for ; Sat, 20 Oct 2012 20:37:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9KJb4F1025642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 20 Oct 2012 20:37:05 +0100 From: "Adrian Farrel" To: References: <33921BF9-9D15-49F8-AB15-55740DC984E1@gmail.com> In-Reply-To: <33921BF9-9D15-49F8-AB15-55740DC984E1@gmail.com> Date: Sat, 20 Oct 2012 20:37:07 +0100 Message-ID: <0b7901cdaefa$4a6f7d50$df4e77f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6WTrNgeMfrPZD7Jaw/xPpLiXLIgM3fKtZlk+FTkA= Content-Language: en-gb 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 Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 19:37:08 -0000 Speaking as an individual and without an implementation... Isn't this MPLS? Hasn't the routing area looked at the idea of using the IPv6 flow label for labelled forwarding more than once in the past? Hasn't the conclusion always been that you could do it, but you would have to be sure that you were not overloading the field? And hasn't the resulting discussion led to a debate on the value of label stacks and the impracticality of label stacks using the flow label? Cheers, Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: 20 October 2012 14:50 > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > Phil; > > > > There is indeed lot of pressure for this in terms of header sizes and energy > consumption in the *real world*. > > I'm personally concerned about header sizes and energy consumption in The > Matrix. Because I don't live in the real world. Oh, wait, sorry, I do. Can you walk > me through the quantitative reasoning that a few bytes of header will increase > energy consumption? It the belief that it will lead to sub-packet fragmentation in > some non-amortized sense? Generally speaking, in low power wireless > networks, energy consumption is dominated by idle listening and communication > latency/interval support, not the length of packets. Of course there is a spectrum > of low power approaches and their point on that spectrum. Are you thinking of > one in particular? > > Could implementers who are encountering this pressure comment? I'm a sucker > for and easily swayed by quantitative data as well as first-hand rather than > second-hand reports. > > > And there is no hack in the proposed solution. > > Simply we believe more in practical engineering and ML discussions than we > trust in crystal balls. > > *coughs politely* I believe in very practical engineering that considers long term > consequences. Solving a problem a certain way now might cause significant > problems in the future. I agree this is a tradeoff -- in my personal opinion, nothing > more, the tradeoff on this one is 100% clear. > > Phil > > ------ > > Philip Levis > President, Kumu Networks > Associate Professor, Stanford University > http://csl.stanford.edu/~pal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sat Oct 20 14:29:40 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 7C08B21F8934 for ; Sat, 20 Oct 2012 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 x6VtRn3qlMl2 for ; Sat, 20 Oct 2012 14:29:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BF24B21F8932 for ; Sat, 20 Oct 2012 14:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3536; q=dns/txt; s=iport; t=1350768579; x=1351978179; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FKy/ccAyTy/EbM6Zu3zJR5KUsamgwhrTvSit2ScIagc=; b=jlhJsuLbC47cbG93Zoqq70YcpE83k7vHmx7uc6NPjdWmtYvMQGee7qD9 aVYmKtdcQoeKKbCH14PiqVcim5PX8TE1zLYL+Ir1vuDTtfHCGJa8Gr3pC q6hzIoYk2K/AvBn2dbs4/CAEnXNRRtjillPZUGUXaPlIJlLekY1zSUwVV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALQWg1CtJXHA/2dsb2JhbABEFsB4gQiCIAEBAQQBAQEPASc0FwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIEweHYgubOp8vi18bhXRgA6EdgyKBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,622,1344211200"; d="scan'208";a="133724581" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2012 21:29:39 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9KLTd1m006041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 21:29:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 16:29:38 -0500 From: "Pascal Thubert (pthubert)" To: "adrian@olddog.co.uk" , "roll@ietf.org" Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: AQJ6WTrNJUl7oGcgSNK+KxLSa35+rwM3fKtZlk+FTkCAAB8mYA== Date: Sat, 20 Oct 2012 21:29:37 +0000 Deferred-Delivery: Sat, 20 Oct 2012 21:29:00 +0000 Message-ID: References: <33921BF9-9D15-49F8-AB15-55740DC984E1@gmail.com> <0b7901cdaefa$4a6f7d50$df4e77f0$@olddog.co.uk> In-Reply-To: <0b7901cdaefa$4a6f7d50$df4e77f0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.80.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--52.392900-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 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: Sat, 20 Oct 2012 21:29:40 -0000 Adrian, This draft is not mpls. This draft is about carrying the RPL info (rank, in= stance, flags) in the flow label as opposed to the HbH which incurs additio= nal header + eventually tunneling. My other draft on fragment forwarding has a lot more to do with label switc= hing since the first fragment lays a label that the other fragments follow.= But then we are not using the flow label but a 6LoWPAN datagram identifier= tag. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: samedi 20 octobre 2012 21:37 To: roll@ietf.org Subject: Re: [Roll] using the flow label instead of hop by hop Speaking as an individual and without an implementation... Isn't this MPLS?=20 Hasn't the routing area looked at the idea of using the IPv6 flow label for= labelled forwarding more than once in the past? Hasn't the conclusion always been that you could do it, but you would have = to be sure that you were not overloading the field? And hasn't the resulting discussion led to a debate on the value of label s= tacks and the impracticality of label stacks using the flow label? Cheers, Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Philip Levis > Sent: 20 October 2012 14:50 > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop >=20 > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: >=20 > > Phil; > > > > There is indeed lot of pressure for this in terms of header sizes=20 > > and energy > consumption in the *real world*. >=20 > I'm personally concerned about header sizes and energy consumption in=20 > The Matrix. Because I don't live in the real world. Oh, wait, sorry, I=20 > do. Can you walk > me through the quantitative reasoning that a few bytes of header will=20 > increase energy consumption? It the belief that it will lead to=20 > sub-packet fragmentation in > some non-amortized sense? Generally speaking, in low power wireless=20 > networks, energy consumption is dominated by idle listening and=20 > communication latency/interval support, not the length of packets. Of=20 > course there is a spectrum > of low power approaches and their point on that spectrum. Are you=20 > thinking of one in particular? >=20 > Could implementers who are encountering this pressure comment? I'm a=20 > sucker for and easily swayed by quantitative data as well as=20 > first-hand rather than second-hand reports. >=20 > > And there is no hack in the proposed solution. > > Simply we believe more in practical engineering and ML discussions=20 > > than we > trust in crystal balls. >=20 > *coughs politely* I believe in very practical engineering that=20 > considers long term > consequences. Solving a problem a certain way now might cause=20 > significant problems in the future. I agree this is a tradeoff -- in=20 > my personal opinion, nothing > more, the tradeoff on this one is 100% clear. >=20 > Phil >=20 > ------ >=20 > Philip Levis > President, Kumu Networks > Associate Professor, Stanford University http://csl.stanford.edu/~pal=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Oct 22 00:05: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 5EDE221F879B for ; Mon, 22 Oct 2012 00:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 tagged_above=-999 required=5 tests=[AWL=1.010, 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 9CD4JclCeLAk for ; Mon, 22 Oct 2012 00:05:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAAD21F874E for ; Mon, 22 Oct 2012 00:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3178; q=dns/txt; s=iport; t=1350889522; x=1352099122; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XQI2OthW42SjzddEz0Z3zWoEbsAP+binDuNPAd1MXaw=; b=fqLYA40WyOzur6s6pRIZUAy21/fHieB/0FiwzlV2DoJx/cn27iaQtCq7 /E/BTUbNmX6Q1qCMDkcozocvVjqLDd9E3Oa0+N2J483qU7ai15CUjneUC YrjZRgVRyTerpY+R+ghoojlJ3VTXVG42A39pBxuLsSzstg5EAwPl/HX7K w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPTvhFCtJV2b/2dsb2JhbABFhhS5fHuBCIIgAQEBBBIBEBFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBGYdiC5tTjSGRdYEgij8bhUIyYAOXCI03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133947694" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2012 07:04:59 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9M74xcd008554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 07:04:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 02:04:58 -0500 From: "Pascal Thubert (pthubert)" To: "roll@ietf.org" Thread-Topic: New Version Notification for draft-phinney-roll-rpl-industrial-applicability-01.txt Thread-Index: AQHNsCJYmfdL6Zrm9UC/PmVn7gcqNpfE5Qdw Date: Mon, 22 Oct 2012 07:04:57 +0000 Deferred-Delivery: Mon, 22 Oct 2012 07:04:00 +0000 Message-ID: References: <20121022065615.6885.54639.idtracker@ietfa.amsl.com> In-Reply-To: <20121022065615.6885.54639.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.83.191] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--27.473700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Roll] FW: New Version Notification for draft-phinney-roll-rpl-industrial-applicability-01.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: Mon, 22 Oct 2012 07:05:23 -0000 SGk6DQoNCkFzIHByb21pc2VkLCBwbGVhc2UgZmluZCBvbmxpbmUgdGhlIHVwZGF0ZSBvZiB0aGUg aW5kdXN0cmlhbCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1waGlubmV5LXJvbGwtcnBsLWluZHVzdHJpYWwtYXBwbGljYWJp bGl0eS0wMS50eHQgLg0KVGhvdWdoIHRoZSBkaXNjdXNzaW9ucyBhcmUgb3BlbiBhbmQgYWN0aXZl LCBhbmQgSVB2NiBpcyBhbHJlYWR5IGFkb3B0ZWQgaW4gc29tZSBjYXNlcywgUlBMIGhhcyBub3Qg Zm91bmQgeWV0IGFuIHByYWN0aWNhbCBvcGVuaW5nIGluIGluZHVzdHJpYWwuIA0KVGhpcyB3b3Jr IGlzIHRodXMgYW4gYWR2YW5jZWQgc3R1ZHkgYmFzZWQgb24gZXhpc3RpbmcgcHJhY3RpY2VzIG9u IGhvdyBSUEwgY291bGQgYXBwbHkgdGhlcmUuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogbHVuZGkgMjIgb2N0b2JyZSAy MDEyIDA4OjU2DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6IHRvbS5waGlubmV5 QGNveC5uZXQ7IHJvYmVydC5hc3NpbWl0aUBuaXZpcy5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxp Y2FiaWxpdHktMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBoaW5uZXkt cm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3Ry aWFsLWFwcGxpY2FiaWxpdHkNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFJQTCBhcHBsaWNhYmls aXR5IGluIGluZHVzdHJpYWwgbmV0d29ya3MNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTIyDQpX RyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMzcNClVSTDog ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGhp bm5leS1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHktMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGhpbm5leS1yb2xs LXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHkNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxp Y2FiaWxpdHktMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHktMDEN Cg0KQWJzdHJhY3Q6DQogICBUaGUgd2lkZSBkZXBsb3ltZW50IG9mIHdpcmVsZXNzIGRldmljZXMs IHdpdGggdGhlaXIgbG93IGluc3RhbGxlZA0KICAgY29zdCAoY29tcGFyZWQgdG8gd2lyZWQgZGV2 aWNlcyksIHdpbGwgc2lnbmlmaWNhbnRseSBpbXByb3ZlIHRoZQ0KICAgcHJvZHVjdGl2aXR5IGFu ZCBzYWZldHkgb2YgaW5kdXN0cmlhbCBwbGFudHMuICBJdCB3aWxsIHNpbXVsdGFuZW91c2x5DQog ICBpbmNyZWFzZSB0aGUgZWZmaWNpZW5jeSBhbmQgc2FmZXR5IG9mIHRoZSBwbGFudCdzIHdvcmtl cnMsIGJ5DQogICBleHRlbmRpbmcgYW5kIG1ha2luZyBtb3JlIHRpbWVseSB0aGUgaW5mb3JtYXRp b24gc2V0IGF2YWlsYWJsZSBhYm91dA0KICAgcGxhbnQgb3BlcmF0aW9ucy4gIFRoZSBuZXcgUm91 dGluZyBQcm90b2NvbCBmb3IgTG93IFBvd2VyIGFuZCBMb3NzeQ0KICAgTmV0d29ya3MgKFJQTCkg ZGVmaW5lcyBhIERpc3RhbmNlIFZlY3RvciBwcm90b2NvbCB0aGF0IGlzIGRlc2lnbmVkDQogICBm b3Igc3VjaCBuZXR3b3Jrcy4gIFRoZSBhaW0gb2YgdGhpcyBkb2N1bWVudCBpcyB0byBhbmFseXpl IHRoZQ0KICAgYXBwbGljYWJpbGl0eSBvZiB0aGF0IHJvdXRpbmcgcHJvdG9jb2wgaW4gaW5kdXN0 cmlhbCBMTE5zIGZvcm1lZCBvZg0KICAgZmllbGQgZGV2aWNlcy4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From stokcons@xs4all.nl Mon Oct 22 06:53: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 B3A3A21F8BB6 for ; Mon, 22 Oct 2012 06:53:50 -0700 (PDT) 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 Q0jZ1Sod+iCW for ; Mon, 22 Oct 2012 06:53:50 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id CD68321F8BBD for ; Mon, 22 Oct 2012 06:53:49 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9MDrG5C083897; Mon, 22 Oct 2012 15:53:16 +0200 (CEST) (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); Mon, 22 Oct 2012 15:53:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 22 Oct 2012 15:53:16 +0200 From: peter van der Stok To: jonathan hui , richard kelsey , Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (iPDgIr5/pijF9sX/3tMpEZ2t0H2TyEFe) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [Roll] MPL draft 2 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, 22 Oct 2012 13:53:50 -0000 Hi Jonathan and Richard, thanks for the new MPL draft. During a first reading I had some problems with the domain concept. I understood that a domain may be composed of several link-local scopes. When configuring an interface with one link-local scope I should like to reject link-local multicasts which come from link-local neigbors that do not belong to the domain for which the interface is configured. For example: closely spaced wireless nodes which have different edge routers. To express the domain in the multicast address were you thinking of "transient" and "unicast prefix based" mc addresses with format ff32::prefix:group?. Configuring the interface with a link-local scope limited to one prefix may cover the domain concept adequately. In my opinion some text on interface configuration to implement packet rejection based on Mc domain will be useful. Greetings Peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From rdroms.ietf@gmail.com Mon Oct 22 10:59: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 E195221F8B76 for ; Mon, 22 Oct 2012 10:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 tQZEcqckWlEl for ; Mon, 22 Oct 2012 10:59:20 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29F0321F8B73 for ; Mon, 22 Oct 2012 10:59:19 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3592317vcb.31 for ; Mon, 22 Oct 2012 10:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:x-mailer:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=i1hA/4HyaSV+ZMsxEZlZ4H0o7JZzmrfxvqfbeoOmHhk=; b=u1VfX/lGFRFWwzX9n41f1HaYyC5wwj+8qbCajvTdoBUpkg+69E84akNaKXHU7ZH4RL jJUVSmb91Zx0G2ncurctvxKmInnKRsdPYjxziKjxDS6/GGlvIvMo+uQaKTZn76lOlQd6 fLTx5CYfSHlIF0DfU2HoozHJwC1g5jmhtVra4QzNbMUWrXNDTzJGe5azGqvZv1G0VxAm E2DAN5/Vq5obczpZ+CfixeUjB65lzimiBLAErJa5O30ZFjSe8YXvXXdh0tyLxRph267p SfvdELioeNSYuTq8LzBwgDU+//xCktTc8Tef0y54fvItKeKw0hlRJErvVbwW8PG1NHiw h97Q== Received: by 10.221.2.76 with SMTP id nt12mr16232761vcb.12.1350928759750; Mon, 22 Oct 2012 10:59:19 -0700 (PDT) Received: from [10.138.94.46] (mobile-198-228-194-105.mycingular.net. [198.228.194.105]) by mx.google.com with ESMTPS id cz16sm10725919vdb.15.2012.10.22.10.59.18 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 10:59:19 -0700 (PDT) From: Ralph Droms X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Message-Id: Date: Mon, 22 Oct 2012 13:59:17 -0400 To: roll Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: [Roll] AD review of draft-kelsey-intarea-mesh-link-establishment 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, 22 Oct 2012 17:59:21 -0000 I've been asked to sponsor draft-kelsey-intarea-mesh-link-establishment as a= n AD-sponsored individual submission. As part of my AD review of the docume= nt, I'm soliciting input from a variety of relevant communities, including t= he roll WG. I expect to complete my review next week and then send the document out for I= ETF last call. Please respond with comments by next Monday, Oct 29, either t= o the mailing list or directly to me. I'm aware that the last call will ov= erlap the IETF meeting in Atlanta but it will be a four week last call, whic= h should be enough for reviewing this document. - Ralph From jdrake@juniper.net Mon Oct 22 12:16: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 E4EEC21F86EB for ; Mon, 22 Oct 2012 12:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 ZQ4je8PVSiyR for ; Mon, 22 Oct 2012 12:16:57 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C114921F856D for ; Mon, 22 Oct 2012 12:16:56 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUIWbqIrsUdcgTQ5nNlS6RPPq8f0E8P9a@postini.com; Mon, 22 Oct 2012 12:16:56 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 22 Oct 2012 12:15:32 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 22 Oct 2012 12:15:31 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Oct 2012 12:21:46 -0700 Received: from mail32-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 22 Oct 2012 19:15:29 +0000 Received: from mail32-am1 (localhost [127.0.0.1]) by mail32-am1-R.bigfish.com (Postfix) with ESMTP id 57BF93200B2 for ; Mon, 22 Oct 2012 19:15:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I542M1432Idcamzz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1155h) Received: from mail32-am1 (localhost.localdomain [127.0.0.1]) by mail32-am1 (MessageSwitch) id 135093332763080_11327; Mon, 22 Oct 2012 19:15:27 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.243]) by mail32-am1.bigfish.com (Postfix) with ESMTP id 092D41C0074; Mon, 22 Oct 2012 19:15:27 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 22 Oct 2012 19:15:26 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.214]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0224.004; Mon, 22 Oct 2012 19:15:25 +0000 From: John E Drake To: "Pascal Thubert (pthubert)" , "adrian@olddog.co.uk" , "roll@ietf.org" Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2um3zK78zttzpFSgOnw7I7S2GAIwALlesAAAwdYYAAA+3UgABf0V4g Date: Mon, 22 Oct 2012 19:15:25 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E072D13C3@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <33921BF9-9D15-49F8-AB15-55740DC984E1@gmail.com> <0b7901cdaefa$4a6f7d50$df4e77f0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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, 22 Oct 2012 19:16:58 -0000 Pascal, So the information that you are carrying in the IPv6 label field has nothin= g to do with IPv6 labels? So, why is this not an egregious hack? Yours irrespectively, John > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: Saturday, October 20, 2012 2:30 PM > To: adrian@olddog.co.uk; roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop >=20 > Adrian, >=20 > This draft is not mpls. This draft is about carrying the RPL info > (rank, instance, flags) in the flow label as opposed to the HbH which > incurs additional header + eventually tunneling. > My other draft on fragment forwarding has a lot more to do with label > switching since the first fragment lays a label that the other > fragments follow. But then we are not using the flow label but a > 6LoWPAN datagram identifier tag. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: samedi 20 octobre 2012 21:37 > To: roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop >=20 > Speaking as an individual and without an implementation... >=20 > Isn't this MPLS? > Hasn't the routing area looked at the idea of using the IPv6 flow label > for labelled forwarding more than once in the past? > Hasn't the conclusion always been that you could do it, but you would > have to be sure that you were not overloading the field? > And hasn't the resulting discussion led to a debate on the value of > label stacks and the impracticality of label stacks using the flow > label? >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Philip Levis > > Sent: 20 October 2012 14:50 > > To: Pascal Thubert (pthubert) > > Cc: roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > Phil; > > > > > > There is indeed lot of pressure for this in terms of header sizes > > > and energy > > consumption in the *real world*. > > > > I'm personally concerned about header sizes and energy consumption in > > The Matrix. Because I don't live in the real world. Oh, wait, sorry, > I > > do. Can you > walk > > me through the quantitative reasoning that a few bytes of header will > > increase energy consumption? It the belief that it will lead to > > sub-packet > fragmentation in > > some non-amortized sense? Generally speaking, in low power wireless > > networks, energy consumption is dominated by idle listening and > > communication latency/interval support, not the length of packets. Of > > course there is a > spectrum > > of low power approaches and their point on that spectrum. Are you > > thinking of one in particular? > > > > Could implementers who are encountering this pressure comment? I'm a > > sucker for and easily swayed by quantitative data as well as > > first-hand rather than second-hand reports. > > > > > And there is no hack in the proposed solution. > > > Simply we believe more in practical engineering and ML discussions > > > than we > > trust in crystal balls. > > > > *coughs politely* I believe in very practical engineering that > > considers long > term > > consequences. Solving a problem a certain way now might cause > > significant problems in the future. I agree this is a tradeoff -- in > > my personal opinion, > nothing > > more, the tradeoff on this one is 100% clear. > > > > Phil > > > > ------ > > > > Philip Levis > > President, Kumu Networks > > Associate Professor, Stanford University http://csl.stanford.edu/~pal > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From qiuying@i2r.a-star.edu.sg Mon Oct 22 20:50: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 BF3911F0C54; Mon, 22 Oct 2012 20:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zSFOis-8d37E; Mon, 22 Oct 2012 20:50:23 -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 389201F0429; Mon, 22 Oct 2012 20:50:21 -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 q9N3mEf9021247; Tue, 23 Oct 2012 11:50:19 +0800 Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw2.scei.a-star.edu.sg with ESMTP id 185k4h01gw-1; Tue, 23 Oct 2012 11:50:19 +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; Tue, 23 Oct 2012 11:50:18 +0800 From: QIU Ying To: , <6lowpan@ietf.org> Date: Tue, 23 Oct 2012 11:56:34 +0800 Message-ID: <015801cdb0d2$649305b0$2db91110$@a-star.edu.sg> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQ 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-10-23_02:2012-10-22, 2012-10-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=9 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210220422 Content-Type: text/plain; charset="UTF-8" Subject: [Roll] FW: New Version Notification for draft-qiu-roll-kemp-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: Tue, 23 Oct 2012 03:50:23 -0000 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 =20=20=20=20 -----Original Message----- A new version of I-D, draft-qiu-roll-kemp-02.txt has been successfully subm= itted 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 S= ensor 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=3Ddraft-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. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 The IETF Secretariat Institute for Infocomm Research disclaimer: "This email is confidential an= d may be privileged. If you are not the intended recipient, please delete i= t 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 Mon Oct 22 21:00: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 393E61F0C54; Mon, 22 Oct 2012 21:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 o6mWQTnJDmRk; Mon, 22 Oct 2012 21:00:36 -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 4B15C1F0C69; Mon, 22 Oct 2012 21:00:36 -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 q9N40YqE009699; Tue, 23 Oct 2012 12:00:34 +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; Tue, 23 Oct 2012 12:00:34 +0800 From: QIU Ying To: "'QIU Ying'" , , <6lowpan@ietf.org> References: In-Reply-To: Date: Tue, 23 Oct 2012 12:06:49 +0800 Message-ID: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQAADK/bA= 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-10-23_02:2012-10-22, 2012-10-23, 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-1210220426 Subject: Re: [Roll] slot for New Version of draft-qiu-roll-kemp-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: Tue, 23 Oct 2012 04:00:37 -0000 Dear JV, Might I ask a 5-10min slot to update the draft? Sorry for late applying as I were not sure if I am able to attend IETF85. Regards and Thanks 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." From jeonggil.ko@gmail.com Mon Oct 22 23:32: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 40CEA21F8AB5 for ; Mon, 22 Oct 2012 23:32:19 -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 e-lyhOcDar2i for ; Mon, 22 Oct 2012 23:32:18 -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 3441821F8AAB for ; Mon, 22 Oct 2012 23:32:18 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2497576pad.31 for ; Mon, 22 Oct 2012 23:32:17 -0700 (PDT) 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=tWBbcEPdQ3dArQF2GFON4m/MANBB3tkwP8HG0iGtAeY=; b=MwMokdKFtVAe4ehu/N0CfbiSalo5Pwhlf0ZlCreBlXM6cPXsANTDATx76fu31t95k+ 2Aew7Qf5BnKdJXibwoZ7d4fJje0J1oDo1+hSBAek0XvOMVs+5GhjWv/7hgfFhqkHamWQ tDBvGPS8O1hGkCZ20VwdnqbJOEAwoV144df5w3jYLlrt+pdYhfRzlN7Nk1umPnoqzsgs zAw6dwZtVyhguJH8exTk0MKLb3EVRRyFiHl8UIpu+/82BpFdiY6UwG6vAC+CMQERs+d8 PeC8FMjpZ8txF5uqIZBcbIoRrVkmUTt+qbShcGyi3BccTt+qDNNndSubUstp0Hq7thx9 wKMg== Received: by 10.68.235.71 with SMTP id uk7mr37459308pbc.10.1350973937779; Mon, 22 Oct 2012 23:32:17 -0700 (PDT) Received: from [10.217.10.249] ([129.254.38.233]) by mx.google.com with ESMTPS id ok3sm1068276pbb.11.2012.10.22.23.32.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 23:32:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: JeongGil Ko In-Reply-To: <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com> Date: Tue, 23 Oct 2012 15:32:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu> <1BACA0A8-CF05-418E-9C5E-657FB0713037@etri.re.kr> <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com> To: "JP Vasseur (jvasseur)" , Philip Levis X-Mailer: Apple Mail (2.1499) Cc: JeongGil Ko , roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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: Tue, 23 Oct 2012 06:32:19 -0000 JP, Phil, I've updated the draft with additional use cases and my previous email = on the list regarding the draft update should provide an answer to the = questions that came up on this email thread :) Thanks! -John On Sep 5, 2012, at 8:08 PM, JP Vasseur (jvasseur) = wrote: > Fully agreeing with Phil; as RPL is being deployed and mature, we need = to be careful not to add anything that is not strongly > motivated by a concrete use case and requirements. Thanks for your = work. >=20 > JP. >=20 > On Sep 5, 2012, at 3:34 AM, JeongGil Ko wrote: >=20 >> Phil, >>=20 >> Thanks for your feedback. Nice idea with the additional informative = documentation. I will get together with the authors of the draft to = discuss and initiate an informative document. >>=20 >> Thanks! >>=20 >> -John >>=20 >>=20 >> On Sep 5, 2012, at 10:29 AM, Philip Levis wrote: >>=20 >>> In that case, you're the application that is the compelling use = case. eIt would be great if you could write a document that more = concretely lays out your arguments below; they seem sound to me, but one = short email seems insufficient to motivate a significant protocol = addition. A more detailed design document would also clearly specify the = constraints of the solution. For example, from your description below, = it sounds like complete mixed mode is unnecessary; instead, allowing = non-storing trees off of a storing network would be sufficient. It could = be that setup covers 99% of the mixed use cases, and it is much much = simpler than arbitrary compositions. >>>=20 >>> Phi >>>=20 >>> On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote: >>>=20 >>>> Phil, >>>>=20 >>>> With the RFC 6550, developers can build applications with storing = mode or not-storing mode nodes. In some cases they 'can' design systems = to be mixed, but since either one of the modes should act as a leaf = node, they may result in forming non-optimal routes (in both traffic = directions). >>>>=20 >>>> While it may not be a general application (I think it can be but = others may think differently), we are currently designing a system where = (relatively) resource-rich nodes act as sub-DODAG heads (I am using this = expression due to the lack of a better term) and a larger number of = resource-constraint nodes act as sensing units. Basically it's a network = with device heterogeneity and the two devices have their respective = tasks in the network. This doesn't necessarily mean that these resource = constraint nodes are always positioned physically at a corner of the = network to act as leaf nodes. The physical location of any of these = nodes can be at locations where by using it to forward packets, can = increase the efficiency of packet forwarding on the DODAG. Thus, but = forcing a set of nodes to be leaf nodes, we may miss a chance to have = more efficient routing paths. >>>>=20 >>>> In such a network, given RFC 6550, to make sure that the default = route performs at its optimal, a system designer needs to select between = the storing or non-storing mode (this is the only way we can have all = the nodes in the network capable of forwarding packets). First, since we = have memory constraints, we do not want the resource constraint nodes to = implement storing mode; thus, a full storing mode network is not an = option. On the other hand, implementing the entire network with = non-storing mode would be inefficient since packets would always have to = travel to the DODAG root for all downwards packets (not saying its not = going to work but less efficient). An alternative would be to implement = non-storing mode for nodes that cannot meet the heavier memory = requirements and for the nodes that can spare some space to store = routes... use the storing mode. This can help cut the stretch of the = packets that travel to non-root destinations. Networks with device = heterogeneity (a mi > x >>=20 >>> of powerful and 'dumb' nodes) can choose to use such 'mixed' network = configuration to preserve the upwards routing performance and also = perform downwards routing efficiently. The draft simply proposes a few = light weight changes that are required to make this happen. >>>>=20 >>>> I agree with you that if a proposal not realist nor useful in real = life, that it is meaningless (or less meaningful) to push the proposal = on the standards track. Nevertheless, I believe that we should make sure = that RPL can allow/tolerate for various network configurations so that = it is not the standards that is limiting the development of new systems. = My $0.02 :) >>>>=20 >>>> Thanks! >>>>=20 >>>> -John >>>>=20 >>>>=20 >>>> On Sep 5, 2012, at 1:17 AM, Philip Levis wrote: >>>>=20 >>>>>=20 >>>>> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Hi Philip, >>>>>>=20 >>>>>> I also think that RPL is complicated, for good reasons, but not = always >>>>>> complicated protocols should not be optimized or assisted by = others. >>>>>> However, new ideas and drafts are always recommended. >>>>>=20 >>>>>=20 >>>>> As an academic, I agree wholeheartedly. Also as an academic, I'd = argue that new ideas which do not have a strong application pull are the = province of research, not standardization. Our goal here is to = standardize practice for interoperability, not come up with new ideas. = But that's just my 2 cents. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>=20 >>>=20 >>> Phil >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Oct 23 03:52: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 186CE21F86CE for ; Tue, 23 Oct 2012 03:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 W57PSr4iFMUz for ; Tue, 23 Oct 2012 03:52:34 -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 2D70621F86CC for ; Tue, 23 Oct 2012 03:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2649; q=dns/txt; s=iport; t=1350989554; x=1352199154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tnqLWMu3IyzwWbixJhs+Hfb6FbfqD4q8G0fuJCn34CM=; b=KuWPjoXCMWWlTqVI6O24qLsE5dxTpGvPwprb9GRw28I1EepiHGeIb698 VLySJCZO7QFmbgShfQH036W0rR0Si+Tf1OeE3j3tRqDqiahPpWlZOqRfN H0x6oCfH7Zlb5QMXDFexKeUONX0qmpaM5n3A0VNR3OknfnBBBRQqT5KKZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJJ1hlCtJXG9/2dsb2JhbABEwWOBCIIeAQEBAwEBAQEPASc0CQIFBwQCAQgRBAEBCxQJBycLFAkIAgQOBQgBGYdcBgucYY9ckEKLXxuFY2ADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134448265" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 23 Oct 2012 10:52:33 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9NAqXx8025162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Oct 2012 10:52:33 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 05:52:32 -0500 From: "JP Vasseur (jvasseur)" To: "Pascal Thubert (pthubert)" Thread-Topic: [Roll] New Version Notification for draft-phinney-roll-rpl-industrial-applicability-01.txt Thread-Index: AQHNsQyAd1mZSWb7jUS45NHaji5uqg== Date: Tue, 23 Oct 2012 10:52:32 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220150E5@xmb-rcd-x02.cisco.com> References: <20121022065615.6885.54639.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--36.982100-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: <488F5904127BEC47A0C36A2C98EF7333@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification for draft-phinney-roll-rpl-industrial-applicability-01.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: Tue, 23 Oct 2012 10:52:35 -0000 Thanks Pascal - Are you asking for a slot in Atlanta ? On Oct 22, 2012, at 9:04 AM, Pascal Thubert (pthubert) wrote: > Hi: >=20 > As promised, please find online the update of the industrial applicabilit= y statement http://www.ietf.org/internet-drafts/draft-phinney-roll-rpl-indu= strial-applicability-01.txt . > Though the discussions are open and active, and IPv6 is already adopted i= n some cases, RPL has not found yet an practical opening in industrial.=20 > This work is thus an advanced study based on existing practices on how RP= L could apply there. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: lundi 22 octobre 2012 08:56 > To: Pascal Thubert (pthubert) > Cc: tom.phinney@cox.net; robert.assimiti@nivis.com > Subject: New Version Notification for draft-phinney-roll-rpl-industrial-a= pplicability-01.txt >=20 >=20 > A new version of I-D, draft-phinney-roll-rpl-industrial-applicability-01.= txt > has been successfully submitted by Pascal Thubert and posted to the IETF = repository. >=20 > Filename: draft-phinney-roll-rpl-industrial-applicability > Revision: 01 > Title: RPL applicability in industrial networks > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-phinney-roll-r= pl-industrial-applicability-01.txt > Status: http://datatracker.ietf.org/doc/draft-phinney-roll-rpl-i= ndustrial-applicability > Htmlized: http://tools.ietf.org/html/draft-phinney-roll-rpl-indust= rial-applicability-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-phinney-roll-rp= l-industrial-applicability-01 >=20 > Abstract: > The wide deployment of wireless devices, with their low installed > cost (compared to wired devices), will significantly improve the > productivity and safety of industrial plants. It will simultaneously > increase the efficiency and safety of the plant's workers, by > extending and making more timely the information set available about > plant operations. The new Routing Protocol for Low Power and Lossy > Networks (RPL) defines a Distance Vector protocol that is designed > for such networks. The aim of this document is to analyze the > applicability of that routing protocol in industrial LLNs formed of > field devices. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Oct 23 04:16:33 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 C765E21F867A for ; Tue, 23 Oct 2012 04:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.478, 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 8kYSJfHxyyNo for ; Tue, 23 Oct 2012 04:16:29 -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 5FDBB21F8659 for ; Tue, 23 Oct 2012 04:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3032; q=dns/txt; s=iport; t=1350990989; x=1352200589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UMEudORzS4SRKxTU2JKmGO4l+v1a2Jr86f05GX9ksFI=; b=YcTJh7MK7bn/vHUaM3IwXUskpo7ZM4PbR2ccGez0ZcB0lwCC1n0O1ZMz uNPKICqjtVtjJhJXhDoLe/7sqlLi+0YEN8XtpaLlcmSNmH8bXLU0XEI3x CNIpZ9XzYq/CsvAk9tGKvFdhTUOiRO05/9KhnuCocLFHcGbMxLw3TM46Z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO17hlCtJXG//2dsb2JhbABEwWOBCIIeAQEBAwEBAQEPASc0CQIFBwQCAQgRBAEBCxQJBycLFAkIAgQOBQgBGYdcBgucWI9ckEKLXxuFY2ADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134461136" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 23 Oct 2012 11:16:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBGSjE000749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Oct 2012 11:16:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 06:16:28 -0500 From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" Thread-Topic: [Roll] New Version Notification for draft-phinney-roll-rpl-industrial-applicability-01.txt Thread-Index: AQHNsQ/YQzqACHf5HEuNL4JhZ6HpvA== Date: Tue, 23 Oct 2012 11:16:28 +0000 Deferred-Delivery: Tue, 23 Oct 2012 11:16:00 +0000 Message-ID: References: <20121022065615.6885.54639.idtracker@ietfa.amsl.com> <03B78081B371D44390ED6E7BADBB4A77220150E5@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220150E5@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--39.248800-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] New Version Notification for draft-phinney-roll-rpl-industrial-applicability-01.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: Tue, 23 Oct 2012 11:16:33 -0000 Yes, JP,=20 please save a slot for discussion on this draft. I think Robert will be presenting. Cheers, Pascal -----Original Message----- From: JP Vasseur (jvasseur)=20 Sent: mardi 23 octobre 2012 12:53 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification for draft-phinney-roll-rpl-ind= ustrial-applicability-01.txt Thanks Pascal - Are you asking for a slot in Atlanta ? On Oct 22, 2012, at 9:04 AM, Pascal Thubert (pthubert) wrote: > Hi: >=20 > As promised, please find online the update of the industrial applicabilit= y statement http://www.ietf.org/internet-drafts/draft-phinney-roll-rpl-indu= strial-applicability-01.txt . > Though the discussions are open and active, and IPv6 is already adopted i= n some cases, RPL has not found yet an practical opening in industrial.=20 > This work is thus an advanced study based on existing practices on how RP= L could apply there. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: lundi 22 octobre 2012 08:56 > To: Pascal Thubert (pthubert) > Cc: tom.phinney@cox.net; robert.assimiti@nivis.com > Subject: New Version Notification for draft-phinney-roll-rpl-industrial-a= pplicability-01.txt >=20 >=20 > A new version of I-D, draft-phinney-roll-rpl-industrial-applicability-01.= txt > has been successfully submitted by Pascal Thubert and posted to the IETF = repository. >=20 > Filename: draft-phinney-roll-rpl-industrial-applicability > Revision: 01 > Title: RPL applicability in industrial networks > Creation date: 2012-10-22 > WG ID: Individual Submission > Number of pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-phinney-roll-r= pl-industrial-applicability-01.txt > Status: http://datatracker.ietf.org/doc/draft-phinney-roll-rpl-i= ndustrial-applicability > Htmlized: http://tools.ietf.org/html/draft-phinney-roll-rpl-indust= rial-applicability-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-phinney-roll-rp= l-industrial-applicability-01 >=20 > Abstract: > The wide deployment of wireless devices, with their low installed > cost (compared to wired devices), will significantly improve the > productivity and safety of industrial plants. It will simultaneously > increase the efficiency and safety of the plant's workers, by > extending and making more timely the information set available about > plant operations. The new Routing Protocol for Low Power and Lossy > Networks (RPL) defines a Distance Vector protocol that is designed > for such networks. The aim of this document is to analyze the > applicability of that routing protocol in industrial LLNs formed of > field devices. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Oct 23 04:41: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 B061221F86BD for ; Tue, 23 Oct 2012 04:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.169 X-Spam-Level: X-Spam-Status: No, score=-10.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 ULeMizXtZTui for ; Tue, 23 Oct 2012 04:41:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0F021F8644 for ; Tue, 23 Oct 2012 04:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5419; q=dns/txt; s=iport; t=1350992482; x=1352202082; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eqzQ40ABfMkGecLvNrLJ4mvkvH8ImU6ioYFtMEoQ198=; b=QsbhHZoyQzYIynjVKE2sFi9lmaORQzk9ArIYBih1rH9hN1GN+OR30O+u vkV/wf8U5No9ISStCsPFNnEdYWpITWbEIUDGxfslWZSEVbsY3YT/dztG2 TJIQh3i8GU+wRZGOeHUepMDOb7k0wbMMBnwN3JL1sfVQkG2W0/elt9zmq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP+BhlCtJV2d/2dsb2JhbABEFsFNgQiCHgEBAQQBAQEPASctBxcGAQgRBAEBAQoUCS4LFAkJAQQBEggTB4diC5xOj1yQQotfG4VjYAOhHYMigWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="131426771" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2012 11:41:16 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBfGeP030129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 11:41:16 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 06:41:16 -0500 From: "Pascal Thubert (pthubert)" To: John E Drake , "adrian@olddog.co.uk" , "roll@ietf.org" Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2xEy0nd273o7OGRK2FV075gsSicw== Date: Tue, 23 Oct 2012 11:41:16 +0000 Deferred-Delivery: Tue, 23 Oct 2012 11:41:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--54.790900-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 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: Tue, 23 Oct 2012 11:41:23 -0000 Hi: In short: The packets carried within an instance share a characteristic whi= ch the OF optimizes for.=20 The OF determines a RPL topology and thus how the flow that is tagged with = that instance is processed in the network.=20 For flows to be processed differently one may different instances. Considering how open the definition of flow in 2460 is, this fits.=20 The rank stretches that a bit since it qualifies where the flow is in the N= etwork.=20 Then again RFC 2460 is open enough not to bar anything.=20 Rather, the spirit is for us to do something useful with this field in the = forwarding plane and that is exactly what this proposal is doing . Cheers, Pascal -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: lundi 22 octobre 2012 21:15 To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org Subject: RE: [Roll] using the flow label instead of hop by hop Pascal, So the information that you are carrying in the IPv6 label field has nothin= g to do with IPv6 labels? So, why is this not an egregious hack? Yours irrespectively, John > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Pascal Thubert (pthubert) > Sent: Saturday, October 20, 2012 2:30 PM > To: adrian@olddog.co.uk; roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop >=20 > Adrian, >=20 > This draft is not mpls. This draft is about carrying the RPL info=20 > (rank, instance, flags) in the flow label as opposed to the HbH which=20 > incurs additional header + eventually tunneling. > My other draft on fragment forwarding has a lot more to do with label=20 > switching since the first fragment lays a label that the other=20 > fragments follow. But then we are not using the flow label but a=20 > 6LoWPAN datagram identifier tag. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Adrian Farrel > Sent: samedi 20 octobre 2012 21:37 > To: roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop >=20 > Speaking as an individual and without an implementation... >=20 > Isn't this MPLS? > Hasn't the routing area looked at the idea of using the IPv6 flow=20 > label for labelled forwarding more than once in the past? > Hasn't the conclusion always been that you could do it, but you would=20 > have to be sure that you were not overloading the field? > And hasn't the resulting discussion led to a debate on the value of=20 > label stacks and the impracticality of label stacks using the flow=20 > label? >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > > Of Philip Levis > > Sent: 20 October 2012 14:50 > > To: Pascal Thubert (pthubert) > > Cc: roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > Phil; > > > > > > There is indeed lot of pressure for this in terms of header sizes=20 > > > and energy > > consumption in the *real world*. > > > > I'm personally concerned about header sizes and energy consumption=20 > > in The Matrix. Because I don't live in the real world. Oh, wait,=20 > > sorry, > I > > do. Can you > walk > > me through the quantitative reasoning that a few bytes of header=20 > > will increase energy consumption? It the belief that it will lead to=20 > > sub-packet > fragmentation in > > some non-amortized sense? Generally speaking, in low power wireless=20 > > networks, energy consumption is dominated by idle listening and=20 > > communication latency/interval support, not the length of packets.=20 > > Of course there is a > spectrum > > of low power approaches and their point on that spectrum. Are you=20 > > thinking of one in particular? > > > > Could implementers who are encountering this pressure comment? I'm a=20 > > sucker for and easily swayed by quantitative data as well as=20 > > first-hand rather than second-hand reports. > > > > > And there is no hack in the proposed solution. > > > Simply we believe more in practical engineering and ML discussions=20 > > > than we > > trust in crystal balls. > > > > *coughs politely* I believe in very practical engineering that=20 > > considers long > term > > consequences. Solving a problem a certain way now might cause=20 > > significant problems in the future. I agree this is a tradeoff -- in=20 > > my personal opinion, > nothing > > more, the tradeoff on this one is 100% clear. > > > > Phil > > > > ------ > > > > Philip Levis > > President, Kumu Networks > > Associate Professor, Stanford University=20 > > http://csl.stanford.edu/~pal=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jdrake@juniper.net Tue Oct 23 05:40: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 7F49021F86C0 for ; Tue, 23 Oct 2012 05:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 7EXoLt-XGPNQ for ; Tue, 23 Oct 2012 05:40:55 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCC21F86BD for ; Tue, 23 Oct 2012 05:40:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUIaQVWaAhU1TBJ1M1AHMonqhg7iXEjto@postini.com; Tue, 23 Oct 2012 05:40:55 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 23 Oct 2012 05:40:05 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 23 Oct 2012 05:40:04 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Oct 2012 05:42:15 -0700 Received: from mail91-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 12:40:03 +0000 Received: from mail91-ch1 (localhost [127.0.0.1]) by mail91-ch1-R.bigfish.com (Postfix) with ESMTP id 8813A601A7 for ; Tue, 23 Oct 2012 12:40:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I542M1432Idcamzz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1155h) Received: from mail91-ch1 (localhost.localdomain [127.0.0.1]) by mail91-ch1 (MessageSwitch) id 1350996002323461_5643; Tue, 23 Oct 2012 12:40:02 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail91-ch1.bigfish.com (Postfix) with ESMTP id 4CB264007B; Tue, 23 Oct 2012 12:40:02 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 12:40:02 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.2.153]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0224.004; Tue, 23 Oct 2012 12:40:01 +0000 From: John E Drake To: "Pascal Thubert (pthubert)" , "adrian@olddog.co.uk" , "roll@ietf.org" Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2xEy0n78zttzpFSgOnw7I7S2GAIwAA16iw Date: Tue, 23 Oct 2012 12:40:01 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E07DDE577@CH1PRD0510MB356.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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: Tue, 23 Oct 2012 12:40:56 -0000 Right, once explained in the proper context the proposal makes perfect sens= e. Yours irrespectively, John > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, October 23, 2012 4:41 AM > To: John E Drake; adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Hi: >=20 > the list.> >=20 > In short: The packets carried within an instance share a characteristic > which the OF optimizes for. > The OF determines a RPL topology and thus how the flow that is tagged > with that instance is processed in the network. > For flows to be processed differently one may different instances. >=20 > Considering how open the definition of flow in 2460 is, this fits. >=20 > The rank stretches that a bit since it qualifies where the flow is in > the Network. > Then again RFC 2460 is open enough not to bar anything. >=20 > Rather, the spirit is for us to do something useful with this field in > the forwarding plane and that is exactly what this proposal is doing . >=20 > Cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: lundi 22 octobre 2012 21:15 > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Pascal, >=20 > So the information that you are carrying in the IPv6 label field has > nothing to do with IPv6 labels? So, why is this not an egregious hack? >=20 > Yours irrespectively, >=20 > John >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Pascal Thubert (pthubert) > > Sent: Saturday, October 20, 2012 2:30 PM > > To: adrian@olddog.co.uk; roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > Adrian, > > > > This draft is not mpls. This draft is about carrying the RPL info > > (rank, instance, flags) in the flow label as opposed to the HbH which > > incurs additional header + eventually tunneling. > > My other draft on fragment forwarding has a lot more to do with label > > switching since the first fragment lays a label that the other > > fragments follow. But then we are not using the flow label but a > > 6LoWPAN datagram identifier tag. > > > > Cheers, > > > > Pascal > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Adrian Farrel > > Sent: samedi 20 octobre 2012 21:37 > > To: roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > Speaking as an individual and without an implementation... > > > > Isn't this MPLS? > > Hasn't the routing area looked at the idea of using the IPv6 flow > > label for labelled forwarding more than once in the past? > > Hasn't the conclusion always been that you could do it, but you would > > have to be sure that you were not overloading the field? > > And hasn't the resulting discussion led to a debate on the value of > > label stacks and the impracticality of label stacks using the flow > > label? > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf > > > Of Philip Levis > > > Sent: 20 October 2012 14:50 > > > To: Pascal Thubert (pthubert) > > > Cc: roll@ietf.org > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > > > Phil; > > > > > > > > There is indeed lot of pressure for this in terms of header sizes > > > > and energy > > > consumption in the *real world*. > > > > > > I'm personally concerned about header sizes and energy consumption > > > in The Matrix. Because I don't live in the real world. Oh, wait, > > > sorry, > > I > > > do. Can you > > walk > > > me through the quantitative reasoning that a few bytes of header > > > will increase energy consumption? It the belief that it will lead > to > > > sub-packet > > fragmentation in > > > some non-amortized sense? Generally speaking, in low power wireless > > > networks, energy consumption is dominated by idle listening and > > > communication latency/interval support, not the length of packets. > > > Of course there is a > > spectrum > > > of low power approaches and their point on that spectrum. Are you > > > thinking of one in particular? > > > > > > Could implementers who are encountering this pressure comment? I'm > a > > > sucker for and easily swayed by quantitative data as well as > > > first-hand rather than second-hand reports. > > > > > > > And there is no hack in the proposed solution. > > > > Simply we believe more in practical engineering and ML > discussions > > > > than we > > > trust in crystal balls. > > > > > > *coughs politely* I believe in very practical engineering that > > > considers long > > term > > > consequences. Solving a problem a certain way now might cause > > > significant problems in the future. I agree this is a tradeoff -- > in > > > my personal opinion, > > nothing > > > more, the tradeoff on this one is 100% clear. > > > > > > Phil > > > > > > ------ > > > > > > Philip Levis > > > President, Kumu Networks > > > Associate Professor, Stanford University > > > http://csl.stanford.edu/~pal > > > _______________________________________________ > > > Roll mailing 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 >=20 From guo@merl.com Tue Oct 23 07:11: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 5910321F85CB for ; Tue, 23 Oct 2012 07:11:43 -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 imGB3sTOieKL for ; Tue, 23 Oct 2012 07:11:42 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id B982921F8573 for ; Tue, 23 Oct 2012 07:11:42 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9NEBfKQ020329; Tue, 23 Oct 2012 10:11:41 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9NEBaWn010277; Tue, 23 Oct 2012 10:11:41 -0400 Message-ID: <5086A598.7030508@merl.com> Date: Tue, 23 Oct 2012 10:11:36 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> In-Reply-To: <501945CC.5040801@merl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Philip Orlik , Kieran Parsons Subject: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 14:11:43 -0000 Dear ROLL WG members, As we all know that loop is an open issue in RPL. Experiment shows that loop occurs quite often. We have proposed a loop free local DODAG repair solution. The proposed repair method does not increase rank, and therefore, it does not create any loop. Also, the proposed repair method does not require any modification to RPL and works for both storing mode and non-storing mode of RPL. It provides benefits to RPL. The detailed solution is specified in draft-guo-roll-loop-free-dodag-repair-00. Please review the draft. Your comments and feedback are welcome. Best regards, Jianlin Guo Senior Principal Member Research Staff Mitsubishi Electric Research Laboratories 201 Broadway, Cambridge, MA, USA From pal@cs.stanford.edu Tue Oct 23 09:07: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 3B3C221F86E7 for ; Tue, 23 Oct 2012 09:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiesCPK0FBSH for ; Tue, 23 Oct 2012 09:07:35 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id C6AD921F86D2 for ; Tue, 23 Oct 2012 09:07:35 -0700 (PDT) Received: from dn0a2101f9.sunet ([10.33.1.249]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TQh0v-0001p6-0C; Tue, 23 Oct 2012 09:07:35 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <5086A598.7030508@merl.com> Date: Tue, 23 Oct 2012 08:39:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> To: Jianlin Guo X-Mailer: Apple Mail (2.1278) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: roll@ietf.org, Philip Orlik , Kieran Parsons Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 16:07:36 -0000 I thought the hop-by-hop header detects loops and triggered DIOs repair = them? Phil On Oct 23, 2012, at 7:11 AM, Jianlin Guo wrote: > Dear ROLL WG members, >=20 > As we all know that loop is an open issue in RPL. Experiment shows = that loop occurs quite often. We have proposed a loop free local DODAG = repair solution. The proposed repair method does not increase rank, and = therefore, it does not create any loop. Also, the proposed repair method = does not require any modification to RPL and works for both storing mode = and non-storing mode of RPL. It provides benefits to RPL. >=20 > The detailed solution is specified in = draft-guo-roll-loop-free-dodag-repair-00. Please review the draft. Your = comments and feedback are welcome. >=20 > Best regards, > Jianlin Guo > Senior Principal Member Research Staff > Mitsubishi Electric Research Laboratories > 201 Broadway, Cambridge, MA, USA >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Oct 23 09:07: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 9C27611E80E9 for ; Tue, 23 Oct 2012 09:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1xWgjj-X9wt for ; Tue, 23 Oct 2012 09:07:39 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82A11E80E5 for ; Tue, 23 Oct 2012 09:07:39 -0700 (PDT) Received: from dn0a2101f9.sunet ([10.33.1.249]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TQh0x-0001p6-SP; Tue, 23 Oct 2012 09:07:38 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 23 Oct 2012 08:41:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> References: To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) X-Scan-Signature: 1d850ab87a3e5a2ab763966491000bbf 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: Tue, 23 Oct 2012 16:07:43 -0000 What if an end-host outside the RPL instance wants to use a flow label = for its own purposes? It might think that a flow denotes a stream of = associated packets to a node within a RPL instance, not the OF that = instance happens to use.=20 Phil On Oct 23, 2012, at 4:41 AM, Pascal Thubert (pthubert) wrote: > Hi: >=20 > >=20 > In short: The packets carried within an instance share a = characteristic which the OF optimizes for.=20 > The OF determines a RPL topology and thus how the flow that is tagged = with that instance is processed in the network.=20 > For flows to be processed differently one may different instances. >=20 > Considering how open the definition of flow in 2460 is, this fits.=20 >=20 > The rank stretches that a bit since it qualifies where the flow is in = the Network.=20 > Then again RFC 2460 is open enough not to bar anything.=20 >=20 > Rather, the spirit is for us to do something useful with this field in = the forwarding plane and that is exactly what this proposal is doing . >=20 > Cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: lundi 22 octobre 2012 21:15 > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Pascal, >=20 > So the information that you are carrying in the IPv6 label field has = nothing to do with IPv6 labels? So, why is this not an egregious hack? >=20 > Yours irrespectively, >=20 > John >=20 >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20= >> Of Pascal Thubert (pthubert) >> Sent: Saturday, October 20, 2012 2:30 PM >> To: adrian@olddog.co.uk; roll@ietf.org >> Subject: Re: [Roll] using the flow label instead of hop by hop >>=20 >> Adrian, >>=20 >> This draft is not mpls. This draft is about carrying the RPL info=20 >> (rank, instance, flags) in the flow label as opposed to the HbH which=20= >> incurs additional header + eventually tunneling. >> My other draft on fragment forwarding has a lot more to do with label=20= >> switching since the first fragment lays a label that the other=20 >> fragments follow. But then we are not using the flow label but a=20 >> 6LoWPAN datagram identifier tag. >>=20 >> Cheers, >>=20 >> Pascal >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20= >> Of Adrian Farrel >> Sent: samedi 20 octobre 2012 21:37 >> To: roll@ietf.org >> Subject: Re: [Roll] using the flow label instead of hop by hop >>=20 >> Speaking as an individual and without an implementation... >>=20 >> Isn't this MPLS? >> Hasn't the routing area looked at the idea of using the IPv6 flow=20 >> label for labelled forwarding more than once in the past? >> Hasn't the conclusion always been that you could do it, but you would=20= >> have to be sure that you were not overloading the field? >> And hasn't the resulting discussion led to a debate on the value of=20= >> label stacks and the impracticality of label stacks using the flow=20 >> label? >>=20 >> Cheers, >> Adrian >>=20 >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20= >>> Of Philip Levis >>> Sent: 20 October 2012 14:50 >>> To: Pascal Thubert (pthubert) >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] using the flow label instead of hop by hop >>>=20 >>> On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: >>>=20 >>>> Phil; >>>>=20 >>>> There is indeed lot of pressure for this in terms of header sizes=20= >>>> and energy >>> consumption in the *real world*. >>>=20 >>> I'm personally concerned about header sizes and energy consumption=20= >>> in The Matrix. Because I don't live in the real world. Oh, wait,=20 >>> sorry, >> I >>> do. Can you >> walk >>> me through the quantitative reasoning that a few bytes of header=20 >>> will increase energy consumption? It the belief that it will lead to=20= >>> sub-packet >> fragmentation in >>> some non-amortized sense? Generally speaking, in low power wireless=20= >>> networks, energy consumption is dominated by idle listening and=20 >>> communication latency/interval support, not the length of packets.=20= >>> Of course there is a >> spectrum >>> of low power approaches and their point on that spectrum. Are you=20 >>> thinking of one in particular? >>>=20 >>> Could implementers who are encountering this pressure comment? I'm a=20= >>> sucker for and easily swayed by quantitative data as well as=20 >>> first-hand rather than second-hand reports. >>>=20 >>>> And there is no hack in the proposed solution. >>>> Simply we believe more in practical engineering and ML discussions=20= >>>> than we >>> trust in crystal balls. >>>=20 >>> *coughs politely* I believe in very practical engineering that=20 >>> considers long >> term >>> consequences. Solving a problem a certain way now might cause=20 >>> significant problems in the future. I agree this is a tradeoff -- in=20= >>> my personal opinion, >> nothing >>> more, the tradeoff on this one is 100% clear. >>>=20 >>> Phil >>>=20 >>> ------ >>>=20 >>> Philip Levis >>> President, Kumu Networks >>> Associate Professor, Stanford University=20 >>> http://csl.stanford.edu/~pal=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From guo@merl.com Tue Oct 23 09:17:30 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 3755311E8103 for ; Tue, 23 Oct 2012 09:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dizhskMDAUya for ; Tue, 23 Oct 2012 09:17:29 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1A211E80E6 for ; Tue, 23 Oct 2012 09:17:29 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9NGHHEu021595; Tue, 23 Oct 2012 12:17:17 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9NGHCWn013077; Tue, 23 Oct 2012 12:17:17 -0400 Message-ID: <5086C308.5010601@merl.com> Date: Tue, 23 Oct 2012 12:17:12 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Philip Levis References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> In-Reply-To: <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, Philip Orlik , Kieran Parsons Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 16:17:30 -0000 Hi Phil, Thank you for your comment. Goal of our local repair method is to prevent loop from occurring and therefore, loop detection is unnecessary. Jianlin On 10/23/2012 11:39 AM, Philip Levis wrote: > I thought the hop-by-hop header detects loops and triggered DIOs repair them? > > Phil > > On Oct 23, 2012, at 7:11 AM, Jianlin Guo wrote: > >> Dear ROLL WG members, >> >> As we all know that loop is an open issue in RPL. Experiment shows that loop occurs quite often. We have proposed a loop free local DODAG repair solution. The proposed repair method does not increase rank, and therefore, it does not create any loop. Also, the proposed repair method does not require any modification to RPL and works for both storing mode and non-storing mode of RPL. It provides benefits to RPL. >> >> The detailed solution is specified in draft-guo-roll-loop-free-dodag-repair-00. Please review the draft. Your comments and feedback are welcome. >> >> Best regards, >> Jianlin Guo >> Senior Principal Member Research Staff >> Mitsubishi Electric Research Laboratories >> 201 Broadway, Cambridge, MA, USA >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From guo@merl.com Tue Oct 23 09:33: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 50F8B1F0C51 for ; Tue, 23 Oct 2012 09:33:56 -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 1IR2Lysi6otg for ; Tue, 23 Oct 2012 09:33:55 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id A948E21F85F9 for ; Tue, 23 Oct 2012 09:33:55 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9NGXi3j021735; Tue, 23 Oct 2012 12:33:44 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9NGXdWn013409; Tue, 23 Oct 2012 12:33:44 -0400 Message-ID: <5086C6E3.2030202@merl.com> Date: Tue, 23 Oct 2012 12:33:39 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Philip Levis References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> In-Reply-To: <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 16:33:56 -0000 Hi Phil, One more point, I think that DIO repair needs to build a new DODAG version, and global DODAG re-building process may interrupt application data transmission and increase delay, which is not acceptable for some applications. Jianlin On 10/23/2012 11:39 AM, Philip Levis wrote: > I thought the hop-by-hop header detects loops and triggered DIOs repair them? > > Phil > > On Oct 23, 2012, at 7:11 AM, Jianlin Guo wrote: > >> Dear ROLL WG members, >> >> As we all know that loop is an open issue in RPL. Experiment shows that loop occurs quite often. We have proposed a loop free local DODAG repair solution. The proposed repair method does not increase rank, and therefore, it does not create any loop. Also, the proposed repair method does not require any modification to RPL and works for both storing mode and non-storing mode of RPL. It provides benefits to RPL. >> >> The detailed solution is specified in draft-guo-roll-loop-free-dodag-repair-00. Please review the draft. Your comments and feedback are welcome. >> >> Best regards, >> Jianlin Guo >> Senior Principal Member Research Staff >> Mitsubishi Electric Research Laboratories >> 201 Broadway, Cambridge, MA, USA >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Oct 23 09:34:04 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 ECACC21F84B1 for ; Tue, 23 Oct 2012 09:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQNCVIeqlppj for ; Tue, 23 Oct 2012 09:34:04 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C511E80A5 for ; Tue, 23 Oct 2012 09:34:00 -0700 (PDT) Received: from dn0a2101f9.sunet ([10.33.1.249]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TQhQW-0002Ie-FO; Tue, 23 Oct 2012 09:34:00 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <5086C308.5010601@merl.com> Date: Tue, 23 Oct 2012 09:34:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> <5086C308.5010601@merl.com> To: Jianlin Guo X-Mailer: Apple Mail (2.1278) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: roll@ietf.org, Philip Orlik , Kieran Parsons Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 16:34:05 -0000 The original observation behind loop detection and repair is that it is = often much simpler and less expensive than loop prevention. This is not = always true; I wouldn't to use it on core routers. But the tradeoffs = that LLNs introduce make it an attractive option.=20 Phil On Oct 23, 2012, at 9:17 AM, Jianlin Guo wrote: > Hi Phil, >=20 > Thank you for your comment. Goal of our local repair method is to = prevent loop from occurring and therefore, loop detection is = unnecessary. >=20 > Jianlin > On 10/23/2012 11:39 AM, Philip Levis wrote: >> I thought the hop-by-hop header detects loops and triggered DIOs = repair them? >>=20 >> Phil >>=20 >> On Oct 23, 2012, at 7:11 AM, Jianlin Guo wrote: >>=20 >>> Dear ROLL WG members, >>>=20 >>> As we all know that loop is an open issue in RPL. Experiment shows = that loop occurs quite often. We have proposed a loop free local DODAG = repair solution. The proposed repair method does not increase rank, and = therefore, it does not create any loop. Also, the proposed repair method = does not require any modification to RPL and works for both storing mode = and non-storing mode of RPL. It provides benefits to RPL. >>>=20 >>> The detailed solution is specified in = draft-guo-roll-loop-free-dodag-repair-00. Please review the draft. Your = comments and feedback are welcome. >>>=20 >>> Best regards, >>> Jianlin Guo >>> Senior Principal Member Research Staff >>> Mitsubishi Electric Research Laboratories >>> 201 Broadway, Cambridge, MA, USA >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 From pal@cs.stanford.edu Tue Oct 23 09:34: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 CC03A11E80DC for ; Tue, 23 Oct 2012 09:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw2PqvTLnX8q for ; Tue, 23 Oct 2012 09:34:37 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1C11E80D1 for ; Tue, 23 Oct 2012 09:34:37 -0700 (PDT) Received: from dn0a2101f9.sunet ([10.33.1.249]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TQhR6-0002Ie-Sa; Tue, 23 Oct 2012 09:34:37 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <5086C6E3.2030202@merl.com> Date: Tue, 23 Oct 2012 09:34:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F8152A7-D682-4442-87ED-51DC762545DE@cs.stanford.edu> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> <5086C6E3.2030202@merl.com> To: Jianlin Guo X-Mailer: Apple Mail (2.1278) X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 Cc: roll@ietf.org Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 16:34:38 -0000 On Oct 23, 2012, at 9:33 AM, Jianlin Guo wrote: > Hi Phil, >=20 > One more point, I think that DIO repair needs to build a new DODAG = version, and global DODAG re-building process may interrupt application = data transmission and increase delay, which is not acceptable for some = applications. >=20 > Jianlin You would be incorrect; please re-read 6550. Phil From pthubert@cisco.com Tue Oct 23 10:49: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 D530211E80EC for ; Tue, 23 Oct 2012 10:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.208 X-Spam-Level: X-Spam-Status: No, score=-10.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 e8Hsu7nU5DrG for ; Tue, 23 Oct 2012 10:49:25 -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 CD76321F85E2 for ; Tue, 23 Oct 2012 10:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6986; q=dns/txt; s=iport; t=1351014565; x=1352224165; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HIS8sBtm+d5zldX0+Wgfz99c+5VVYMb71XicFYhwxkc=; b=R8UjfYxIkevA8ZSjZ6TtaVJku79ROJ+p8cuMxItfVSopRxn1DTGGM91S MMREFR+7ZnpfqXegGqoq0k9F326yHlVTjlSN2DGJNVtwKzYCTUpUZGkQd 1Q7toneBR5HGUNjbEsJj4WSD1OSWFYCQs28TW/Owu6MadDNRM5dlpz2HS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACrYhlCtJXG+/2dsb2JhbABEDgjBWoEIgh4BAQEDAQEBAQ8BJy0HCwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEDgUIEweHXAYLnA6PXJAyi18bhWNgA6EdgyKBa4IyPYIY X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134341483" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 23 Oct 2012 17:49:20 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NHnKHk011154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 17:49:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 12:49:19 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: AQHNsTiIS+G272WWTEymTPhIOnuvhZfHKRcg Date: Tue, 23 Oct 2012 17:49:19 +0000 Deferred-Delivery: Tue, 23 Oct 2012 17:49:00 +0000 Message-ID: References: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> In-Reply-To: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--49.543100-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: Tue, 23 Oct 2012 17:49:27 -0000 Phil, The flow label is not protected by any IPSec so it cannot be used as a back= channel end-to-end. Now that would be a hack.=20 And it is not for node to node communication but for node to network commun= ication. That, in fact, would be a bad idea when destination options can be= used safely. Over the core internet, 6MAN has specified how the flow label is supposed t= o be set and it is the responsibility of the root that an outgoing packet. On incoming packets, a normal host ignores the flow label that it cannot tr= ust anyway. The RPL root will flush it and use it as RPL requires within th= e RPL domain. Cheers, Pascal -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: mardi 23 octobre 2012 17:42 To: Pascal Thubert (pthubert) Cc: John E Drake; adrian@olddog.co.uk; roll@ietf.org Subject: Re: [Roll] using the flow label instead of hop by hop What if an end-host outside the RPL instance wants to use a flow label for = its own purposes? It might think that a flow denotes a stream of associated= packets to a node within a RPL instance, not the OF that instance happens = to use.=20 Phil On Oct 23, 2012, at 4:41 AM, Pascal Thubert (pthubert) wrote: > Hi: >=20 > copy the list.> >=20 > In short: The packets carried within an instance share a characteristic w= hich the OF optimizes for.=20 > The OF determines a RPL topology and thus how the flow that is tagged wit= h that instance is processed in the network.=20 > For flows to be processed differently one may different instances. >=20 > Considering how open the definition of flow in 2460 is, this fits.=20 >=20 > The rank stretches that a bit since it qualifies where the flow is in the= Network.=20 > Then again RFC 2460 is open enough not to bar anything.=20 >=20 > Rather, the spirit is for us to do something useful with this field in th= e forwarding plane and that is exactly what this proposal is doing . >=20 > Cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: lundi 22 octobre 2012 21:15 > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Pascal, >=20 > So the information that you are carrying in the IPv6 label field has noth= ing to do with IPv6 labels? So, why is this not an egregious hack? >=20 > Yours irrespectively, >=20 > John >=20 >=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 >> Of Pascal Thubert (pthubert) >> Sent: Saturday, October 20, 2012 2:30 PM >> To: adrian@olddog.co.uk; roll@ietf.org >> Subject: Re: [Roll] using the flow label instead of hop by hop >>=20 >> Adrian, >>=20 >> This draft is not mpls. This draft is about carrying the RPL info=20 >> (rank, instance, flags) in the flow label as opposed to the HbH which=20 >> incurs additional header + eventually tunneling. >> My other draft on fragment forwarding has a lot more to do with label=20 >> switching since the first fragment lays a label that the other=20 >> fragments follow. But then we are not using the flow label but a=20 >> 6LoWPAN datagram identifier tag. >>=20 >> Cheers, >>=20 >> Pascal >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 >> Of Adrian Farrel >> Sent: samedi 20 octobre 2012 21:37 >> To: roll@ietf.org >> Subject: Re: [Roll] using the flow label instead of hop by hop >>=20 >> Speaking as an individual and without an implementation... >>=20 >> Isn't this MPLS? >> Hasn't the routing area looked at the idea of using the IPv6 flow=20 >> label for labelled forwarding more than once in the past? >> Hasn't the conclusion always been that you could do it, but you would=20 >> have to be sure that you were not overloading the field? >> And hasn't the resulting discussion led to a debate on the value of=20 >> label stacks and the impracticality of label stacks using the flow=20 >> label? >>=20 >> Cheers, >> Adrian >>=20 >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 >>> Of Philip Levis >>> Sent: 20 October 2012 14:50 >>> To: Pascal Thubert (pthubert) >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] using the flow label instead of hop by hop >>>=20 >>> On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: >>>=20 >>>> Phil; >>>>=20 >>>> There is indeed lot of pressure for this in terms of header sizes=20 >>>> and energy >>> consumption in the *real world*. >>>=20 >>> I'm personally concerned about header sizes and energy consumption=20 >>> in The Matrix. Because I don't live in the real world. Oh, wait,=20 >>> sorry, >> I >>> do. Can you >> walk >>> me through the quantitative reasoning that a few bytes of header=20 >>> will increase energy consumption? It the belief that it will lead to=20 >>> sub-packet >> fragmentation in >>> some non-amortized sense? Generally speaking, in low power wireless=20 >>> networks, energy consumption is dominated by idle listening and=20 >>> communication latency/interval support, not the length of packets. >>> Of course there is a >> spectrum >>> of low power approaches and their point on that spectrum. Are you=20 >>> thinking of one in particular? >>>=20 >>> Could implementers who are encountering this pressure comment? I'm a=20 >>> sucker for and easily swayed by quantitative data as well as=20 >>> first-hand rather than second-hand reports. >>>=20 >>>> And there is no hack in the proposed solution. >>>> Simply we believe more in practical engineering and ML discussions=20 >>>> than we >>> trust in crystal balls. >>>=20 >>> *coughs politely* I believe in very practical engineering that=20 >>> considers long >> term >>> consequences. Solving a problem a certain way now might cause=20 >>> significant problems in the future. I agree this is a tradeoff -- in=20 >>> my personal opinion, >> nothing >>> more, the tradeoff on this one is 100% clear. >>>=20 >>> Phil >>>=20 >>> ------ >>>=20 >>> Philip Levis >>> President, Kumu Networks >>> Associate Professor, Stanford University=20 >>> http://csl.stanford.edu/~pal=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From guo@merl.com Tue Oct 23 11:02: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 9AE4E11E80D9 for ; Tue, 23 Oct 2012 11:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPA+O9gIsggS for ; Tue, 23 Oct 2012 11:02:26 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A9911E80ED for ; Tue, 23 Oct 2012 11:02:26 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9NI2N21022731; Tue, 23 Oct 2012 14:02:23 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9NI2HWn015558; Tue, 23 Oct 2012 14:02:23 -0400 Message-ID: <5086DBA9.6060602@merl.com> Date: Tue, 23 Oct 2012 14:02:17 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Philip Levis References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <8F2798CD-B406-4D56-B1AB-2E6F3A4B15A9@cs.stanford.edu> <5086C6E3.2030202@merl.com> <0F8152A7-D682-4442-87ED-51DC762545DE@cs.stanford.edu> In-Reply-To: <0F8152A7-D682-4442-87ED-51DC762545DE@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 23 Oct 2012 18:02:27 -0000 Phil, Our local repair method is to locally repair DODAG by a node whose parent set becomes empty. In this case, RPL provides following set of actions: 1) Start its own floating DODAG 2) Poison the broken path 3) Trigger a local repair It would be appreciated if you could point out what local repairs are specified? Jianlin On 10/23/2012 12:34 PM, Philip Levis wrote: > On Oct 23, 2012, at 9:33 AM, Jianlin Guo wrote: > >> Hi Phil, >> >> One more point, I think that DIO repair needs to build a new DODAG version, and global DODAG re-building process may interrupt application data transmission and increase delay, which is not acceptable for some applications. >> >> Jianlin > You would be incorrect; please re-read 6550. > > Phil > From sarikaya2012@gmail.com Tue Oct 23 13:23: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 79E881F0424; Tue, 23 Oct 2012 13:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wc25LD7xkDr; Tue, 23 Oct 2012 13:23:23 -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 A26D71F0CA1; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6939554iec.31 for ; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=6Dtn5gQLIXLKoVJ8/BQKeyqYyv7eSgCnnHmFU3Vymmo=; b=Ou0f72iTfqNhs/SGXLT9M5jXRagmfwjts+Llwq+fzicyVeuQ4abS51D/xMz/f/k2VQ UFmQu38LXum1aTR5YuKW87USrs85/5qz3ZM3l1ruJRLvZqkM2j0OZpt+BcFCsrxOWg/K UnB/kzp2r7Yb8SfXQdv1DCbgV0CA3UyYnAII8dVJOyEaLWZrTc3234AzIKw9924J0PIn 1Og6GorCvLgfmQ85XKU96lnr20xDIHKjNo4JQLp/7kRfGgFnB24FNWisInB5vcouFdTq seLxP6/O/A1D14npJcmfd2BjL0+Av0f/ZtKi1OkSd7n6UWnRuv+MqjygMQagUgakmbSK TRng== MIME-Version: 1.0 Received: by 10.50.5.205 with SMTP id u13mr306986igu.37.1351023803199; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Tue, 23 Oct 2012 13:23:23 -0700 (PDT) In-Reply-To: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> Date: Tue, 23 Oct 2012 15:23:23 -0500 Message-ID: From: Behcet Sarikaya To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Keoh, Sye Loong" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-kemp-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:23:24 -0000 Hi Jean-Pierre, all, There is some overlap with this draft and our work on Secure Bootstrapping that was being pursued until recently in Core WG. It is still not clear to me which WG should be home for this activity, can you please clarify? Regards, Behcet On Mon, Oct 22, 2012 at 11:06 PM, QIU Ying wrot= e: > Dear JV, > > Might I ask a 5-10min slot to update the draft? > > Sorry for late applying as I were not sure if I am able to attend IETF85. > > Regards and Thanks > 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=3Ddraft-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 From pal@cs.stanford.edu Tue Oct 23 13:49: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 BF04E1F0424 for ; Tue, 23 Oct 2012 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KslPi+0Y0so1 for ; Tue, 23 Oct 2012 13:49:27 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9947311E80AE for ; Tue, 23 Oct 2012 13:49:26 -0700 (PDT) Received: from dn0a2101f9.sunet ([10.33.1.249]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TQlPg-0006xm-B1; Tue, 23 Oct 2012 13:49:25 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 23 Oct 2012 13:49:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 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: Tue, 23 Oct 2012 20:49:27 -0000 On Oct 23, 2012, at 10:49 AM, Pascal Thubert (pthubert) wrote: > Phil, >=20 > The flow label is not protected by any IPSec so it cannot be used as a = backchannel end-to-end. Now that would be a hack.=20 What do you mean, a backchannel?=20 > And it is not for node to node communication but for node to network = communication. That, in fact, would be a bad idea when destination = options can be used safely. > Over the core internet, 6MAN has specified how the flow label is = supposed to be set and it is the responsibility of the root that an = outgoing packet. I'm not sure I understand what you're saying. Can you summarize how 6MAN = has specified it is supposed to be set? I thought I understood their = recommendations (from when we last had this discussion) but maybe it has = changed. My concern is that a node sets the flow label to communicate = some information and RPL throws it away. At the very least, we now need = RPL to somehow figure out how to set the flow label for packets leaving = the LLN: this is a form of protocol translation and so, while not = impossible or impermissible, worries me. > On incoming packets, a normal host ignores the flow label that it = cannot trust anyway. The RPL root will flush it and use it as RPL = requires within the RPL domain. Just because a field doesn't have integrity protection doesn't mean that = it can't and won't be used. I mean, are you suggesting that the = recommendations for the flow label no longer follow RFC3697:=20 "The Flow Label value set by the source MUST be delivered unchanged = to the destination node(s)." Phil= From brian.e.carpenter@gmail.com Wed Oct 24 06:59:57 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 EC66C21F86A0 for ; Wed, 24 Oct 2012 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 r7RR6jqU30e3 for ; Wed, 24 Oct 2012 06:59:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC74321F8829 for ; Wed, 24 Oct 2012 06:59:54 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so254220bkc.31 for ; Wed, 24 Oct 2012 06:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/MuxwRUvsYU963sz8YWPgCeSUU5S21lqfgv0Usjer0M=; b=Telsd0ULri2mpmLU5Mwiw+fsMlcIeKkj12q/k6x+mYrKfO2HIk+FDQZCXQyv02mM3Q e7wGKe5uqg7kyPSA9RuSrIWOY7LjZ2B+QH1juWSzrOapiY3KVmMqzH4rozDtYdZF9spN KPKcjwmBB5MHbyBFhFcXk3fe/+H8B3BZDsG3WXUMXnTjoDK3cKOO2fZLxN9nlo2kdU7m z8CMd3jD2eEpRTTWo+3V19NV5jMThI1vr9E/1etvn+LVFxTsjizvY/IPY1B6uwvF9IDO NO99Qk1wt0DtiXAaFM0oxGPb2FTFkjUF/xu/dIr9pUiHRWP9x+lReiBF+2dTV7g9V6g0 H1DA== Received: by 10.204.11.133 with SMTP id t5mr4977600bkt.14.1351087193412; Wed, 24 Oct 2012 06:59:53 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-188.as13285.net. [2.101.189.188]) by mx.google.com with ESMTPS id v14sm8235697bkv.10.2012.10.24.06.59.48 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 06:59:49 -0700 (PDT) Message-ID: <5087F457.1050409@gmail.com> Date: Wed, 24 Oct 2012 14:59:51 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <5081A327.9010505@exegin.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Wed, 24 Oct 2012 13:59:58 -0000 The worst case I can see from this approach is that all packets with the same source/dest address pair would get the same flow label and hence be treated the same for ECMP, LAG or any other kind of load balancing. That will arise if the flow label has to be calculated based only on the address 2-tuple due to fragmentation. I don't see that as a disaster - a lot of load balancing is already based on the 2-tuple anyway. The revised flow label spec explicitly allows the case where it's a router (often but not necessarily the first hop router) that sets the flow label, iff the source doesn't do so. As far as I understand the proposal, it's compatible with that. Regards Brian Carpenter On 20/10/2012 09:09, Pascal Thubert (pthubert) wrote: > Hi Owen: > > I think we are back to the discussion with Brian (cc'ing Brian to make sure my account is faithful). > I think that we converged that the draft is actually doable, considering the LLN as one bug host from the perspective of the wider Internet. > > With the proposal, the LLN gateway is in charge of setting the flow label towards the Internet and the flow label does not belong to the packet originator in the LLN, which, like any host in the Internet for the last 20 years, are wasting the precious bits. > So if an LLN originator sets the flow label it will be erased and recalculated if the LLN uses that draft. Can we justify that? > > 1) First thing first, the flow label is part of the IP header. Which is where you place stuff that you want examined by the router. > Anything farther down the packet will be a lot more trouble for the router. And app level communication does not belong here, whether it is a LLN app or any other app. > > 2) After 15 years of IPv6, the internet community finally found and standardized a usage for the label that basically adds burden to the hosts to serve the core but neiter sender nor receiver can use the value of the field for any practical usage. > For LLN devices that would mean ask a battery operated constrained node to do additional computation in case the packet goes in the powered Internet and needs load balancing. Do you know of any LLN device that would spend energy doing that? > It makes a lot more sense to push the burden to the power border router at the edge of the LLN in case the packet goes out the LLN towards the Internet. > > 3) The FL can only be compressed if it is NULL. This is the natural value for any constrained device, whether it aims at forwarding over RPL or not. > The burden of computing the tuple in the originator is not only on that node, but on all nodes in the LLN, and that would be whether the packet goes out to the Internet where the tuple can be used, or not. > HbH adds up to the waste, additional encap then adds up too. In a LLN that means wasting energy on every packet, with practical and measurable consequences in terms of battery life. In classical 15.4 that also means more fragmentation, and the consequences cascade. > > The draft does not prevent an instance that needs the flow label for other usages to use the HbH. But is allows to control the damage when flow label is not used otherwise. Please see inline > > > When a forwarding node receives a packet with the flow label set, how does it determine whether the flow label contains an identifier of the 5-tuple, or it contains the RPL HbH information? To get it wrong would interfere with the forwarding behavior and lead to interoperability issues. > > [] Does not. If the instance is configured for Flow Label, then the original value is lost. In the future, we could store it in a new HC option but so far the need as not emerged. > > > When packets are received from an external prefix, how does the ingress router handle the flow label? Would it destroy the original label, leave the original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the label (ie: the inner header contains the original flow label, and the outer header contains the HbH information)? > > [] The only usage is in the core. When the FL comes in the LLN, the role is done, the FL would be ignored anyway. > I hoped we could convey something end to end here, like a hint for the instanceId, but failed so far. > So we are back to the BR selecting the instance based on the same heuristics as if the HbH is used. > > > How would the DODAG root rebuild the flow label from the 5-tuple if it encounters packets that have been fragmented at the IPv6 layer? The primary use of the flow label is so that routers don't have to reassemble IPv6 fragments when forwarding to determine the 5-tuple (which is a challenging thing for a router to do). > > [] Since the BR compute the FL, it uses the same heuristic for the first and all fragments. Mixing instanceID and IP addresses mostly. Or keeping only the instanceID when we want the latency+jitter to be homogeneous within an instance over the net. For LLN applications, the distribution of 5 tuples is a lot wider than necessary or even beneficial for the core, and instanceID + IP provides a better granularity and more meaningful volumes. > > Cheers, > > Pascal > > Cheers, > Owen > > On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: > Hi > > When I started this draft, we had a series of chats with Brian Carpenter and apparently reached a gentleman agreement that it was doable within the RPL domain to use the flow label and avoid the Hop by Hop option. > > I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on that discussion but did not get news from the group since then. > > This technique has a number of advantages, in particular > -it saves extra bytes for the RPL option and the HbH header. > -it also avoids the prescribed tunneling within the RPL domain for packets from the outside. > - it has an optimized compression with 6LoWPAN. > > Is there interest in the group to continue? If so I'd be glad to have some discussion time at the next meeting. > > Cheers, > > > > Pascal Thubert > IPv6 Engineering > > pthubert@cisco.com > Phone :+33 497 23 26 34 > Mobile :+33 619 98 29 85 > > > Cisco Systems > Village d'Entreprises Green Side bat. T3 > 400, Avenue Roumanille > 06410 Biot - Sophia Antipolis > France > Cisco.com > > [Description: Description: http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg] > > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > From pthubert@cisco.com Wed Oct 24 07:14: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 7B36421F86F4 for ; Wed, 24 Oct 2012 07:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=0.359, 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 Yg-QzRVRNFim for ; Wed, 24 Oct 2012 07:14:08 -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 4BA6721F86EA for ; Wed, 24 Oct 2012 07:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11832; q=dns/txt; s=iport; t=1351088048; x=1352297648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qHvEmNf68uX8HaxTSox4CyeoAgd1njQH6N4kJmFaT1U=; b=AV8CEx8i01r7N8GV1nQ+bD83JwD7x0/1ujVfD7Yt2HWnPER713osVyNu ptNi16HYC8edhHYy0+LFmDZb96DGENgxuLDsux8GQssEXINUQdCm5gYNc Tctn/HJq0R3EjA24g0kwGvV9bMtlt2STIu+8zlHIEmbQPiCVaOxmYVI6S I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADj2h1CtJV2Z/2dsb2JhbABEhhS6YnqBCIIeAQEBAwEBAQEPARARNQEECwUHAgICAQgRBAEBAQICBgsSAwICAhkGBgsUAQgIAQEEDgUIDAUBCIdQAwkGC5skjSKJDw2JVASBHIlaZwUVAYMigh0yYQOUHoJsihKDJYFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="134922224" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 24 Oct 2012 14:14:07 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9OEE7i9004340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 14:14:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 09:14:07 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2tT14B78zttzpFSgOnw7I7S2GAIwEoILKqAAAmCLA= Date: Wed, 24 Oct 2012 14:14:06 +0000 Deferred-Delivery: Wed, 24 Oct 2012 14:14:00 +0000 Message-ID: References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> In-Reply-To: <5087F457.1050409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--63.970200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Wed, 24 Oct 2012 14:14:09 -0000 SGkgQnJpYW4sDQoNCj4gIFRoZSB3b3JzdCBjYXNlIEkgY2FuIHNlZSBmcm9tIHRoaXMgYXBwcm9h Y2ggaXMgdGhhdCBhbGwgcGFja2V0cyB3aXRoIHRoZSBzYW1lIHNvdXJjZS9kZXN0IGFkZHJlc3Mg cGFpciB3b3VsZCBnZXQgdGhlIHNhbWUgZmxvdyBsYWJlbCBhbmQgaGVuY2UgYmUgdHJlYXRlZCB0 aGUgc2FtZSBmb3IgRUNNUCwgTEFHIG9yIGFueSBvdGhlciBraW5kIG9mIGxvYWQgYmFsYW5jaW5n DQoNClRoaXMgaXMgYWN0dWFsbHkgbm90IHRoZSBjYXNlLiANCg0KQSBzYW1lIG5vZGUgbWF5IHBh cnRpY2lwYXRlIHRvIG11bHRpcGxlIGluc3RhbmNlcywgZWFjaCBpbnN0YW5jZSBkZXNpZ25lZCB0 byBzZXJ2ZSBhIGNlcnRhaW4gY2xhc3Mgb2YgdHJhZmZpYyB3aXRoIGEgY2VydGFpbiBvcHRpbWl6 YXRpb24uIA0KV2l0aCB0aGUgcHJvcG9zYWwsIHRoZSBpbnN0YW5jZS1JRCBpcyBzdGFtcGVkIGlu IHRoZSBmbG93IGxhYmVsLg0KVGhlIHJvb3Qgd2lsbCBwcm9iYWJseSB1c2UgdGhlIGluc3RhbmNl LUlEIGZvciB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGZpbmFsIGZsb3cgbGFiZWwsIHNvIHRoYXQg cGFja2V0cyByZWNlaXZlZCBvdmVyIGEgc2FtZSBpbnN0YW5jZSBhcmUgdHJlYXRlZCB0aGUgc2Ft ZSBvdmVyIHRoZSBjb3JlLiANCg0KVGhpcyBpcyB0cnVlIHdoZXRoZXIgdGhlIHBhY2tldHMgYXJl IGZyb20gYSBzYW1lIG9yIGZyb20gbXVsdGlwbGUgc291cmNlcy4gU28gdGhlIHJvb3QgbWF5IG9y IG1heSBub3QgYWdncmVnYXRlIG11bHRpcGxlIHNlbnNvcnMgKGZpZWxkIGRldmljZXMpIGluIGEg c2FtZSBmbG93IC0gb3Igbm90Lg0KDQpGb3Igc29tZSBhcHBsaWNhdGlvbnMgc3VjaCBhcyBpbmR1 c3RyaWFsIGNvbnRyb2wgZmxvd3MsIGppdHRlciBhbmQgbGF0ZW5jeSBhcmUgY3JpdGljYWwsIGFu ZCBpdCBpcyBnb29kIHRoYXQgZGlmZmVyZW50IHNvdXJjZXMgYXJlIHRyZWF0ZWQgdGhlIHNhbWUs IHRodXMgY29uc2lkZXJlZCBhIHNhbWUgZmxvdy4NClRoaXMgd291bGQgYmUgZGlmZmljdWx0IHRv IGNvb3JkaW5hdGUgaWZzIHRoZSBzZW5zb3JzIHRoZW1zZWx2ZXMgd2VyZSBpbiBjaGFyZ2Ugb2Yg Y29tcHV0aW5nIHRoZSBsYWJlbCBidXQgaXMgYW4gb2J2aW91cyB0aGluZyB0byBkbyBmb3IgdGhl IHJvb3QuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21h aWwuY29tXSANClNlbnQ6IG1lcmNyZWRpIDI0IG9jdG9icmUgMjAxMiAxNjowMA0KVG86IFBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkNCkNjOiBPd2VuIEtpcmJ5OyByb2xsQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW1JvbGxdIHVzaW5nIHRoZSBmbG93IGxhYmVsIGluc3RlYWQgb2YgaG9wIGJ5IGhv cA0KDQpUaGUgd29yc3QgY2FzZSBJIGNhbiBzZWUgZnJvbSB0aGlzIGFwcHJvYWNoIGlzIHRoYXQg YWxsIHBhY2tldHMgd2l0aCB0aGUgc2FtZSBzb3VyY2UvZGVzdCBhZGRyZXNzIHBhaXIgd291bGQg Z2V0IHRoZSBzYW1lIGZsb3cgbGFiZWwgYW5kIGhlbmNlIGJlIHRyZWF0ZWQgdGhlIHNhbWUgZm9y IEVDTVAsIExBRyBvciBhbnkgb3RoZXIga2luZCBvZiBsb2FkIGJhbGFuY2luZy4gVGhhdCB3aWxs IGFyaXNlIGlmIHRoZSBmbG93IGxhYmVsIGhhcyB0byBiZSBjYWxjdWxhdGVkIGJhc2VkIG9ubHkg b24gdGhlIGFkZHJlc3MgMi10dXBsZSBkdWUgdG8gZnJhZ21lbnRhdGlvbi4gSSBkb24ndCBzZWUg dGhhdCBhcyBhIGRpc2FzdGVyIC0gYSBsb3Qgb2YgbG9hZCBiYWxhbmNpbmcgaXMgYWxyZWFkeSBi YXNlZCBvbiB0aGUgMi10dXBsZSBhbnl3YXkuDQoNClRoZSByZXZpc2VkIGZsb3cgbGFiZWwgc3Bl YyBleHBsaWNpdGx5IGFsbG93cyB0aGUgY2FzZSB3aGVyZSBpdCdzIGEgcm91dGVyIChvZnRlbiBi dXQgbm90IG5lY2Vzc2FyaWx5IHRoZSBmaXJzdCBob3Agcm91dGVyKSB0aGF0IHNldHMgdGhlIGZs b3cgbGFiZWwsIGlmZiB0aGUgc291cmNlIGRvZXNuJ3QgZG8gc28uIEFzIGZhciBhcyBJIHVuZGVy c3RhbmQgdGhlIHByb3Bvc2FsLCBpdCdzIGNvbXBhdGlibGUgd2l0aCB0aGF0Lg0KDQpSZWdhcmRz DQogICBCcmlhbiBDYXJwZW50ZXINCg0KT24gMjAvMTAvMjAxMiAwOTowOSwgUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KSB3cm90ZToNCj4gSGkgT3dlbjoNCj4gDQo+IEkgdGhpbmsgd2UgYXJlIGJh Y2sgdG8gdGhlIGRpc2N1c3Npb24gd2l0aCBCcmlhbiAoY2MnaW5nIEJyaWFuIHRvIG1ha2Ugc3Vy ZSBteSBhY2NvdW50IGlzIGZhaXRoZnVsKS4NCj4gSSB0aGluayB0aGF0IHdlIGNvbnZlcmdlZCB0 aGF0IHRoZSBkcmFmdCBpcyBhY3R1YWxseSBkb2FibGUsIGNvbnNpZGVyaW5nIHRoZSBMTE4gYXMg b25lIGJ1ZyBob3N0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSB3aWRlciBJbnRlcm5ldC4N Cj4gDQo+IFdpdGggdGhlIHByb3Bvc2FsLCB0aGUgTExOIGdhdGV3YXkgaXMgaW4gY2hhcmdlIG9m IHNldHRpbmcgdGhlIGZsb3cgbGFiZWwgdG93YXJkcyB0aGUgSW50ZXJuZXQgYW5kIHRoZSBmbG93 IGxhYmVsIGRvZXMgbm90IGJlbG9uZyB0byB0aGUgcGFja2V0IG9yaWdpbmF0b3IgaW4gdGhlIExM Tiwgd2hpY2gsIGxpa2UgYW55IGhvc3QgaW4gdGhlIEludGVybmV0IGZvciB0aGUgbGFzdCAyMCB5 ZWFycywgYXJlIHdhc3RpbmcgdGhlIHByZWNpb3VzIGJpdHMuDQo+IFNvIGlmIGFuIExMTiBvcmln aW5hdG9yIHNldHMgdGhlIGZsb3cgbGFiZWwgaXQgd2lsbCBiZSBlcmFzZWQgYW5kIHJlY2FsY3Vs YXRlZCBpZiB0aGUgTExOIHVzZXMgdGhhdCBkcmFmdC4gQ2FuIHdlIGp1c3RpZnkgdGhhdD8NCj4g DQo+IDEpIEZpcnN0IHRoaW5nIGZpcnN0LCB0aGUgZmxvdyBsYWJlbCBpcyBwYXJ0IG9mIHRoZSBJ UCBoZWFkZXIuIFdoaWNoIGlzIHdoZXJlIHlvdSBwbGFjZSBzdHVmZiB0aGF0IHlvdSB3YW50IGV4 YW1pbmVkIGJ5IHRoZSByb3V0ZXIuDQo+IEFueXRoaW5nIGZhcnRoZXIgZG93biB0aGUgcGFja2V0 IHdpbGwgYmUgYSBsb3QgbW9yZSB0cm91YmxlIGZvciB0aGUgcm91dGVyLiBBbmQgYXBwIGxldmVs IGNvbW11bmljYXRpb24gZG9lcyBub3QgYmVsb25nIGhlcmUsIHdoZXRoZXIgaXQgaXMgYSBMTE4g YXBwIG9yIGFueSBvdGhlciBhcHAuDQo+IA0KPiAyKSBBZnRlciAxNSB5ZWFycyBvZiBJUHY2LCB0 aGUgaW50ZXJuZXQgY29tbXVuaXR5IGZpbmFsbHkgZm91bmQgYW5kIHN0YW5kYXJkaXplZCBhIHVz YWdlIGZvciB0aGUgbGFiZWwgdGhhdCBiYXNpY2FsbHkgYWRkcyBidXJkZW4gdG8gdGhlIGhvc3Rz IHRvIHNlcnZlIHRoZSBjb3JlIGJ1dCBuZWl0ZXIgc2VuZGVyIG5vciByZWNlaXZlciBjYW4gdXNl IHRoZSB2YWx1ZSBvZiB0aGUgZmllbGQgZm9yIGFueSBwcmFjdGljYWwgdXNhZ2UuDQo+IEZvciBM TE4gZGV2aWNlcyB0aGF0IHdvdWxkIG1lYW4gYXNrIGEgYmF0dGVyeSBvcGVyYXRlZCBjb25zdHJh aW5lZCBub2RlIHRvIGRvIGFkZGl0aW9uYWwgY29tcHV0YXRpb24gaW4gY2FzZSB0aGUgcGFja2V0 IGdvZXMgaW4gdGhlIHBvd2VyZWQgSW50ZXJuZXQgYW5kIG5lZWRzIGxvYWQgYmFsYW5jaW5nLiBE byB5b3Uga25vdyBvZiBhbnkgTExOIGRldmljZSB0aGF0IHdvdWxkIHNwZW5kIGVuZXJneSBkb2lu ZyB0aGF0Pw0KPiBJdCBtYWtlcyBhIGxvdCBtb3JlIHNlbnNlIHRvIHB1c2ggdGhlIGJ1cmRlbiB0 byB0aGUgcG93ZXIgYm9yZGVyIHJvdXRlciBhdCB0aGUgZWRnZSBvZiB0aGUgTExOIGluIGNhc2Ug dGhlIHBhY2tldCBnb2VzIG91dCB0aGUgTExOIHRvd2FyZHMgdGhlIEludGVybmV0Lg0KPiANCj4g MykgVGhlIEZMIGNhbiBvbmx5IGJlIGNvbXByZXNzZWQgaWYgaXQgaXMgTlVMTC4gVGhpcyBpcyB0 aGUgbmF0dXJhbCB2YWx1ZSBmb3IgYW55IGNvbnN0cmFpbmVkIGRldmljZSwgd2hldGhlciBpdCBh aW1zIGF0IGZvcndhcmRpbmcgb3ZlciBSUEwgb3Igbm90Lg0KPiBUaGUgYnVyZGVuIG9mIGNvbXB1 dGluZyB0aGUgdHVwbGUgaW4gdGhlIG9yaWdpbmF0b3IgaXMgbm90IG9ubHkgb24gdGhhdCBub2Rl LCBidXQgb24gYWxsIG5vZGVzIGluIHRoZSBMTE4sIGFuZCB0aGF0IHdvdWxkIGJlIHdoZXRoZXIg dGhlIHBhY2tldCBnb2VzIG91dCB0byB0aGUgSW50ZXJuZXQgd2hlcmUgdGhlIHR1cGxlIGNhbiBi ZSB1c2VkLCBvciBub3QuDQo+IEhiSCBhZGRzIHVwIHRvIHRoZSB3YXN0ZSwgYWRkaXRpb25hbCBl bmNhcCB0aGVuIGFkZHMgdXAgdG9vLiBJbiBhIExMTiB0aGF0IG1lYW5zIHdhc3RpbmcgZW5lcmd5 IG9uIGV2ZXJ5IHBhY2tldCwgd2l0aCBwcmFjdGljYWwgYW5kIG1lYXN1cmFibGUgY29uc2VxdWVu Y2VzIGluIHRlcm1zIG9mIGJhdHRlcnkgbGlmZS4gSW4gY2xhc3NpY2FsIDE1LjQgdGhhdCBhbHNv IG1lYW5zIG1vcmUgZnJhZ21lbnRhdGlvbiwgYW5kIHRoZSBjb25zZXF1ZW5jZXMgY2FzY2FkZS4N Cj4gDQo+IFRoZSBkcmFmdCBkb2VzIG5vdCBwcmV2ZW50IGFuIGluc3RhbmNlIHRoYXQgbmVlZHMg dGhlIGZsb3cgbGFiZWwgZm9yIA0KPiBvdGhlciB1c2FnZXMgdG8gdXNlIHRoZSBIYkguIEJ1dCBp cyBhbGxvd3MgdG8gY29udHJvbCB0aGUgZGFtYWdlIHdoZW4gDQo+IGZsb3cgbGFiZWwgaXMgbm90 IHVzZWQgb3RoZXJ3aXNlLiBQbGVhc2Ugc2VlIGlubGluZQ0KPiANCj4gDQo+IFdoZW4gYSAgZm9y d2FyZGluZyBub2RlIHJlY2VpdmVzIGEgcGFja2V0IHdpdGggdGhlIGZsb3cgbGFiZWwgc2V0LCBo b3cgZG9lcyBpdCBkZXRlcm1pbmUgd2hldGhlciB0aGUgZmxvdyBsYWJlbCBjb250YWlucyBhbiBp ZGVudGlmaWVyIG9mIHRoZSA1LXR1cGxlLCBvciBpdCBjb250YWlucyB0aGUgUlBMIEhiSCBpbmZv cm1hdGlvbj8gVG8gZ2V0IGl0IHdyb25nIHdvdWxkIGludGVyZmVyZSB3aXRoIHRoZSBmb3J3YXJk aW5nIGJlaGF2aW9yIGFuZCBsZWFkIHRvIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLg0KPiANCj4g W10gRG9lcyBub3QuIElmIHRoZSBpbnN0YW5jZSBpcyBjb25maWd1cmVkIGZvciBGbG93IExhYmVs LCB0aGVuIHRoZSBvcmlnaW5hbCB2YWx1ZSBpcyBsb3N0LiBJbiB0aGUgZnV0dXJlLCB3ZSBjb3Vs ZCBzdG9yZSBpdCBpbiBhIG5ldyBIQyBvcHRpb24gYnV0IHNvIGZhciB0aGUgbmVlZCBhcyBub3Qg ZW1lcmdlZC4NCj4gDQo+IA0KPiBXaGVuIHBhY2tldHMgYXJlIHJlY2VpdmVkIGZyb20gYW4gZXh0 ZXJuYWwgcHJlZml4LCBob3cgZG9lcyB0aGUgaW5ncmVzcyByb3V0ZXIgaGFuZGxlIHRoZSBmbG93 IGxhYmVsPyBXb3VsZCBpdCBkZXN0cm95IHRoZSBvcmlnaW5hbCBsYWJlbCwgbGVhdmUgdGhlIG9y aWdpbmFsIGxhYmVsIGluIHRhY3QsIG9yIHVzZSBJUHY2LWluLUlQdjYgZW5jYXBzdWxhdGlvbiB0 byBwcmVzZXJ2ZSB0aGUgbGFiZWwgKGllOiB0aGUgaW5uZXIgaGVhZGVyIGNvbnRhaW5zIHRoZSBv cmlnaW5hbCBmbG93IGxhYmVsLCBhbmQgdGhlIG91dGVyIGhlYWRlciBjb250YWlucyB0aGUgSGJI IGluZm9ybWF0aW9uKT8NCj4gDQo+IFtdIFRoZSBvbmx5IHVzYWdlIGlzIGluIHRoZSBjb3JlLiBX aGVuIHRoZSBGTCBjb21lcyBpbiB0aGUgTExOLCB0aGUgcm9sZSBpcyBkb25lLCB0aGUgRkwgd291 bGQgYmUgaWdub3JlZCBhbnl3YXkuDQo+IEkgaG9wZWQgd2UgY291bGQgY29udmV5IHNvbWV0aGlu ZyBlbmQgdG8gZW5kIGhlcmUsIGxpa2UgYSBoaW50IGZvciB0aGUgaW5zdGFuY2VJZCwgYnV0IGZh aWxlZCBzbyBmYXIuDQo+IFNvIHdlIGFyZSBiYWNrIHRvIHRoZSBCUiBzZWxlY3RpbmcgdGhlIGlu c3RhbmNlIGJhc2VkIG9uIHRoZSBzYW1lIGhldXJpc3RpY3MgYXMgaWYgdGhlIEhiSCBpcyB1c2Vk Lg0KPiANCj4gDQo+IEhvdyB3b3VsZCB0aGUgRE9EQUcgcm9vdCByZWJ1aWxkIHRoZSBmbG93IGxh YmVsIGZyb20gdGhlIDUtdHVwbGUgaWYgaXQgZW5jb3VudGVycyBwYWNrZXRzIHRoYXQgaGF2ZSBi ZWVuIGZyYWdtZW50ZWQgYXQgdGhlIElQdjYgbGF5ZXI/IFRoZSBwcmltYXJ5IHVzZSBvZiB0aGUg ZmxvdyBsYWJlbCBpcyBzbyB0aGF0IHJvdXRlcnMgZG9uJ3QgaGF2ZSB0byByZWFzc2VtYmxlIElQ djYgZnJhZ21lbnRzIHdoZW4gZm9yd2FyZGluZyB0byBkZXRlcm1pbmUgdGhlIDUtdHVwbGUgKHdo aWNoIGlzIGEgY2hhbGxlbmdpbmcgdGhpbmcgZm9yIGEgcm91dGVyIHRvIGRvKS4NCj4gDQo+IFtd IFNpbmNlIHRoZSBCUiBjb21wdXRlIHRoZSBGTCwgaXQgdXNlcyB0aGUgc2FtZSBoZXVyaXN0aWMg Zm9yIHRoZSBmaXJzdCBhbmQgYWxsIGZyYWdtZW50cy4gTWl4aW5nIGluc3RhbmNlSUQgYW5kIElQ IGFkZHJlc3NlcyBtb3N0bHkuIE9yIGtlZXBpbmcgb25seSB0aGUgaW5zdGFuY2VJRCB3aGVuIHdl IHdhbnQgdGhlIGxhdGVuY3kraml0dGVyIHRvIGJlIGhvbW9nZW5lb3VzIHdpdGhpbiBhbiBpbnN0 YW5jZSBvdmVyIHRoZSBuZXQuIEZvciBMTE4gYXBwbGljYXRpb25zLCB0aGUgZGlzdHJpYnV0aW9u IG9mIDUgdHVwbGVzIGlzIGEgbG90IHdpZGVyIHRoYW4gbmVjZXNzYXJ5IG9yIGV2ZW4gYmVuZWZp Y2lhbCBmb3IgdGhlIGNvcmUsICBhbmQgaW5zdGFuY2VJRCArIElQIHByb3ZpZGVzIGEgYmV0dGVy IGdyYW51bGFyaXR5IGFuZCBtb3JlIG1lYW5pbmdmdWwgdm9sdW1lcy4NCj4gDQo+IENoZWVycywN Cj4gDQo+IFBhc2NhbA0KPiANCj4gQ2hlZXJzLA0KPiBPd2VuDQo+IA0KPiBPbiAxOC8xMC8yMDEy IDk6NDMgQU0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+IEhpDQo+IA0KPiBX aGVuIEkgc3RhcnRlZCB0aGlzIGRyYWZ0LCB3ZSBoYWQgYSBzZXJpZXMgb2YgY2hhdHMgd2l0aCBC cmlhbiBDYXJwZW50ZXIgYW5kIGFwcGFyZW50bHkgcmVhY2hlZCBhIGdlbnRsZW1hbiBhZ3JlZW1l bnQgdGhhdCBpdCB3YXMgZG9hYmxlIHdpdGhpbiB0aGUgUlBMIGRvbWFpbiB0byB1c2UgdGhlIGZs b3cgbGFiZWwgYW5kIGF2b2lkIHRoZSBIb3AgYnkgSG9wIG9wdGlvbi4NCj4gDQo+IEkgcHVibGlz aGVkIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1mbG93LWxh YmVsLTAxIGJhc2VkIG9uIHRoYXQgZGlzY3Vzc2lvbiBidXQgZGlkIG5vdCBnZXQgbmV3cyBmcm9t IHRoZSBncm91cCBzaW5jZSB0aGVuLg0KPiANCj4gVGhpcyB0ZWNobmlxdWUgaGFzIGEgbnVtYmVy IG9mIGFkdmFudGFnZXMsIGluIHBhcnRpY3VsYXIgLWl0IHNhdmVzIA0KPiBleHRyYSBieXRlcyBm b3IgdGhlIFJQTCBvcHRpb24gYW5kIHRoZSBIYkggaGVhZGVyLg0KPiAtaXQgYWxzbyBhdm9pZHMg dGhlIHByZXNjcmliZWQgdHVubmVsaW5nIHdpdGhpbiB0aGUgUlBMIGRvbWFpbiBmb3IgcGFja2V0 cyBmcm9tIHRoZSBvdXRzaWRlLg0KPiAtIGl0IGhhcyBhbiBvcHRpbWl6ZWQgY29tcHJlc3Npb24g d2l0aCA2TG9XUEFOLg0KPiANCj4gSXMgdGhlcmUgaW50ZXJlc3QgaW4gdGhlIGdyb3VwIHRvIGNv bnRpbnVlPyBJZiBzbyBJJ2QgYmUgZ2xhZCB0byBoYXZlIHNvbWUgZGlzY3Vzc2lvbiB0aW1lIGF0 IHRoZSBuZXh0IG1lZXRpbmcuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiANCj4gDQo+IFBhc2NhbCBU aHViZXJ0DQo+IElQdjYgRW5naW5lZXJpbmcNCj4gDQo+IHB0aHViZXJ0QGNpc2NvLmNvbTxtYWls dG86cHRodWJlcnRAY2lzY28uY29tPg0KPiBQaG9uZSA6KzMzIDQ5NyAyMyAyNiAzNA0KPiBNb2Jp bGUgOiszMyA2MTkgOTggMjkgODUNCj4gDQo+IA0KPiBDaXNjbyBTeXN0ZW1zDQo+IFZpbGxhZ2Ug ZCdFbnRyZXByaXNlcyBHcmVlbiBTaWRlIGJhdC4gVDMgNDAwLCBBdmVudWUgUm91bWFuaWxsZQ0K PiAwNjQxMCBCaW90IC0gU29waGlhIEFudGlwb2xpcw0KPiBGcmFuY2UNCj4gQ2lzY28uY29tPGh0 dHA6Ly93d3cuY2lzY28uY29tL2dsb2JhbC9GUi8+DQo+IA0KPiBbRGVzY3JpcHRpb246IERlc2Ny aXB0aW9uOiAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvZXVy b3BlL2ltYWdlcy9lbWFpbC9zaWduYXR1cmUvdmVydGljYWwwNC5qcGddDQo+IA0KPiBGb3IgY29y cG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOiANCj4gaHR0cDovL3d3dy5jaXNjby5jb20v d2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQo+IFRoaXMgZS1t YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6ZWQg dG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIg YnkgcmVwbHkgZS1tYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiANCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gDQo+IFJvbGxA aWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQo+IA0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gDQo+IA0KPiANCg== From rdroms.ietf@gmail.com Wed Oct 24 07:40: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 10AD121F8B46 for ; Wed, 24 Oct 2012 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 5k9oh7YAFNmK for ; Wed, 24 Oct 2012 07:40:18 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52E21F8AC0 for ; Wed, 24 Oct 2012 07:40:18 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so342085wey.31 for ; Wed, 24 Oct 2012 07:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=C59zIfX0p7/56cKNSvYAaN/Y4rSWnj1+txC//D4YyEI=; b=IshbbF2mB5drSmFqWdDAa+kdzB0qyqmY9pbHtO+PVFlyZR2iBmXzB0M4FIo8Dq+aZf hRqW2VsCWbHCvE3zjOXz3X9AFegWLPpCvDz0+SENcp8SQ0KZR+rOv55R/rvF1sQVFka+ l+cPNyRcBp2hJoh59ikTSGItYQUCDU2lBDrMW8slO5q7dvzQMqqUzf6XztfNAXsiWHEX QjB2MnPnsLMRx1Ofdfh9HO4oJcWyLrWXGD1KSqOUue8IbEgFl3BEuQS+Ht/wSOxCcjQU blXNsk20+toy8ZaydFTAb/BysAfvSp8jT2N63/pHoh5Hp8rBtMlKfMb6UfFzHcB0wQr1 ZSvw== Received: by 10.180.105.168 with SMTP id gn8mr6442989wib.10.1351089617625; Wed, 24 Oct 2012 07:40:17 -0700 (PDT) Received: from [172.16.5.157] ([83.175.217.26]) by mx.google.com with ESMTPS id cu1sm4643314wib.6.2012.10.24.07.40.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 07:40:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Wed, 24 Oct 2012 16:40:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> To: "Pascal Thubert (pthubert)" , Brian E Carpenter X-Mailer: Apple Mail (2.1283) Cc: roll 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: Wed, 24 Oct 2012 14:40:20 -0000 Seems to me this conversation ought to include 6man fairly soon. - Ralph On Oct 24, 2012, at 4:14 PM 10/24/12, Pascal Thubert (pthubert) wrote: > Hi Brian, >=20 >> The worst case I can see from this approach is that all packets with = the same source/dest address pair would get the same flow label and = hence be treated the same for ECMP, LAG or any other kind of load = balancing >=20 > This is actually not the case.=20 >=20 > A same node may participate to multiple instances, each instance = designed to serve a certain class of traffic with a certain = optimization.=20 > With the proposal, the instance-ID is stamped in the flow label. > The root will probably use the instance-ID for the computation of the = final flow label, so that packets received over a same instance are = treated the same over the core.=20 >=20 > This is true whether the packets are from a same or from multiple = sources. So the root may or may not aggregate multiple sensors (field = devices) in a same flow - or not. >=20 > For some applications such as industrial control flows, jitter and = latency are critical, and it is good that different sources are treated = the same, thus considered a same flow. > This would be difficult to coordinate ifs the sensors themselves were = in charge of computing the label but is an obvious thing to do for the = root. >=20 > Cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: mercredi 24 octobre 2012 16:00 > To: Pascal Thubert (pthubert) > Cc: Owen Kirby; roll@ietf.org > Subject: Re: [Roll] using the flow label instead of hop by hop >=20 > The worst case I can see from this approach is that all packets with = the same source/dest address pair would get the same flow label and = hence be treated the same for ECMP, LAG or any other kind of load = balancing. That will arise if the flow label has to be calculated based = only on the address 2-tuple due to fragmentation. I don't see that as a = disaster - a lot of load balancing is already based on the 2-tuple = anyway. >=20 > The revised flow label spec explicitly allows the case where it's a = router (often but not necessarily the first hop router) that sets the = flow label, iff the source doesn't do so. As far as I understand the = proposal, it's compatible with that. >=20 > Regards > Brian Carpenter >=20 > On 20/10/2012 09:09, Pascal Thubert (pthubert) wrote: >> Hi Owen: >>=20 >> I think we are back to the discussion with Brian (cc'ing Brian to = make sure my account is faithful). >> I think that we converged that the draft is actually doable, = considering the LLN as one bug host from the perspective of the wider = Internet. >>=20 >> With the proposal, the LLN gateway is in charge of setting the flow = label towards the Internet and the flow label does not belong to the = packet originator in the LLN, which, like any host in the Internet for = the last 20 years, are wasting the precious bits. >> So if an LLN originator sets the flow label it will be erased and = recalculated if the LLN uses that draft. Can we justify that? >>=20 >> 1) First thing first, the flow label is part of the IP header. Which = is where you place stuff that you want examined by the router. >> Anything farther down the packet will be a lot more trouble for the = router. And app level communication does not belong here, whether it is = a LLN app or any other app. >>=20 >> 2) After 15 years of IPv6, the internet community finally found and = standardized a usage for the label that basically adds burden to the = hosts to serve the core but neiter sender nor receiver can use the value = of the field for any practical usage. >> For LLN devices that would mean ask a battery operated constrained = node to do additional computation in case the packet goes in the powered = Internet and needs load balancing. Do you know of any LLN device that = would spend energy doing that? >> It makes a lot more sense to push the burden to the power border = router at the edge of the LLN in case the packet goes out the LLN = towards the Internet. >>=20 >> 3) The FL can only be compressed if it is NULL. This is the natural = value for any constrained device, whether it aims at forwarding over RPL = or not. >> The burden of computing the tuple in the originator is not only on = that node, but on all nodes in the LLN, and that would be whether the = packet goes out to the Internet where the tuple can be used, or not. >> HbH adds up to the waste, additional encap then adds up too. In a LLN = that means wasting energy on every packet, with practical and measurable = consequences in terms of battery life. In classical 15.4 that also means = more fragmentation, and the consequences cascade. >>=20 >> The draft does not prevent an instance that needs the flow label for=20= >> other usages to use the HbH. But is allows to control the damage when=20= >> flow label is not used otherwise. Please see inline >>=20 >>=20 >> When a forwarding node receives a packet with the flow label set, = how does it determine whether the flow label contains an identifier of = the 5-tuple, or it contains the RPL HbH information? To get it wrong = would interfere with the forwarding behavior and lead to = interoperability issues. >>=20 >> [] Does not. If the instance is configured for Flow Label, then the = original value is lost. In the future, we could store it in a new HC = option but so far the need as not emerged. >>=20 >>=20 >> When packets are received from an external prefix, how does the = ingress router handle the flow label? Would it destroy the original = label, leave the original label in tact, or use IPv6-in-IPv6 = encapsulation to preserve the label (ie: the inner header contains the = original flow label, and the outer header contains the HbH information)? >>=20 >> [] The only usage is in the core. When the FL comes in the LLN, the = role is done, the FL would be ignored anyway. >> I hoped we could convey something end to end here, like a hint for = the instanceId, but failed so far. >> So we are back to the BR selecting the instance based on the same = heuristics as if the HbH is used. >>=20 >>=20 >> How would the DODAG root rebuild the flow label from the 5-tuple if = it encounters packets that have been fragmented at the IPv6 layer? The = primary use of the flow label is so that routers don't have to = reassemble IPv6 fragments when forwarding to determine the 5-tuple = (which is a challenging thing for a router to do). >>=20 >> [] Since the BR compute the FL, it uses the same heuristic for the = first and all fragments. Mixing instanceID and IP addresses mostly. Or = keeping only the instanceID when we want the latency+jitter to be = homogeneous within an instance over the net. For LLN applications, the = distribution of 5 tuples is a lot wider than necessary or even = beneficial for the core, and instanceID + IP provides a better = granularity and more meaningful volumes. >>=20 >> Cheers, >>=20 >> Pascal >>=20 >> Cheers, >> Owen >>=20 >> On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: >> Hi >>=20 >> When I started this draft, we had a series of chats with Brian = Carpenter and apparently reached a gentleman agreement that it was = doable within the RPL domain to use the flow label and avoid the Hop by = Hop option. >>=20 >> I published = http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on = that discussion but did not get news from the group since then. >>=20 >> This technique has a number of advantages, in particular -it saves=20 >> extra bytes for the RPL option and the HbH header. >> -it also avoids the prescribed tunneling within the RPL domain for = packets from the outside. >> - it has an optimized compression with 6LoWPAN. >>=20 >> Is there interest in the group to continue? If so I'd be glad to have = some discussion time at the next meeting. >>=20 >> Cheers, >>=20 >>=20 >>=20 >> Pascal Thubert >> IPv6 Engineering >>=20 >> pthubert@cisco.com >> Phone :+33 497 23 26 34 >> Mobile :+33 619 98 29 85 >>=20 >>=20 >> Cisco Systems >> Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille >> 06410 Biot - Sophia Antipolis >> France >> Cisco.com >>=20 >> [Description: Description: = http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg] >>=20 >> For corporate legal information go to:=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> Roll mailing list >>=20 >> Roll@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From brian.e.carpenter@gmail.com Wed Oct 24 09: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 0759D21F8C6D for ; Wed, 24 Oct 2012 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 I65DJvriNxhK for ; Wed, 24 Oct 2012 09:08:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A676C21F8C67 for ; Wed, 24 Oct 2012 09:08:58 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so327573bkc.31 for ; Wed, 24 Oct 2012 09:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k0BhlrFB5m5D4kBLFkANGBiYRySZWx05THzLh/Mqtm8=; b=jDwz7Vh4cRKS56Iyvlb+u9KuGfCCASnDrVGqgNJ/ado/8vVAg90iGzKyyBqSQRNgOa y4IGFfMz/oy6OpVbeCuXUyaCUpgc7DjNbGVTnCHPQ/Vl3StdSLCGrgXpaCP4PU2njeHo K4cUB8/FqgUFtXczZkx1MmPNOsP7mbhQO2S0vUlal9kuMrctAUCfonTd3obr9jVJX/S2 YRwnRlF6P+UJ4C0xmn5N85Rvwzu8dykNcKTtreCDMmscgmOZ9mryCinxRIevCtYoDfIA TOuj6kTpDEYIcSbZ3BLQxPYqgecFP8nAxwfM3HtlsSJM5k6WLd0JRqmHT9FTVYEj/CFG qaQg== Received: by 10.204.4.200 with SMTP id 8mr5198678bks.81.1351094937677; Wed, 24 Oct 2012 09:08:57 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-188.as13285.net. [2.101.189.188]) by mx.google.com with ESMTPS id x13sm8702204bkv.16.2012.10.24.09.08.50 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 09:08:51 -0700 (PDT) Message-ID: <50881297.4050801@gmail.com> Date: Wed, 24 Oct 2012 17:08:55 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ralph Droms References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: roll 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: Wed, 24 Oct 2012 16:09:00 -0000 On 24/10/2012 15:40, Ralph Droms wrote: > Seems to me this conversation ought to include 6man fairly soon. If ROLL wants to go this way, I agree. I *think* the proposal does no violence to the 6man RFCs, but that's only my opinion. Brian > > - Ralph > > On Oct 24, 2012, at 4:14 PM 10/24/12, Pascal Thubert (pthubert) wrote: > >> Hi Brian, >> >>> The worst case I can see from this approach is that all packets with the same source/dest address pair would get the same flow label and hence be treated the same for ECMP, LAG or any other kind of load balancing >> This is actually not the case. >> >> A same node may participate to multiple instances, each instance designed to serve a certain class of traffic with a certain optimization. >> With the proposal, the instance-ID is stamped in the flow label. >> The root will probably use the instance-ID for the computation of the final flow label, so that packets received over a same instance are treated the same over the core. >> >> This is true whether the packets are from a same or from multiple sources. So the root may or may not aggregate multiple sensors (field devices) in a same flow - or not. >> >> For some applications such as industrial control flows, jitter and latency are critical, and it is good that different sources are treated the same, thus considered a same flow. >> This would be difficult to coordinate ifs the sensors themselves were in charge of computing the label but is an obvious thing to do for the root. >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: mercredi 24 octobre 2012 16:00 >> To: Pascal Thubert (pthubert) >> Cc: Owen Kirby; roll@ietf.org >> Subject: Re: [Roll] using the flow label instead of hop by hop >> >> The worst case I can see from this approach is that all packets with the same source/dest address pair would get the same flow label and hence be treated the same for ECMP, LAG or any other kind of load balancing. That will arise if the flow label has to be calculated based only on the address 2-tuple due to fragmentation. I don't see that as a disaster - a lot of load balancing is already based on the 2-tuple anyway. >> >> The revised flow label spec explicitly allows the case where it's a router (often but not necessarily the first hop router) that sets the flow label, iff the source doesn't do so. As far as I understand the proposal, it's compatible with that. >> >> Regards >> Brian Carpenter >> >> On 20/10/2012 09:09, Pascal Thubert (pthubert) wrote: >>> Hi Owen: >>> >>> I think we are back to the discussion with Brian (cc'ing Brian to make sure my account is faithful). >>> I think that we converged that the draft is actually doable, considering the LLN as one bug host from the perspective of the wider Internet. >>> >>> With the proposal, the LLN gateway is in charge of setting the flow label towards the Internet and the flow label does not belong to the packet originator in the LLN, which, like any host in the Internet for the last 20 years, are wasting the precious bits. >>> So if an LLN originator sets the flow label it will be erased and recalculated if the LLN uses that draft. Can we justify that? >>> >>> 1) First thing first, the flow label is part of the IP header. Which is where you place stuff that you want examined by the router. >>> Anything farther down the packet will be a lot more trouble for the router. And app level communication does not belong here, whether it is a LLN app or any other app. >>> >>> 2) After 15 years of IPv6, the internet community finally found and standardized a usage for the label that basically adds burden to the hosts to serve the core but neiter sender nor receiver can use the value of the field for any practical usage. >>> For LLN devices that would mean ask a battery operated constrained node to do additional computation in case the packet goes in the powered Internet and needs load balancing. Do you know of any LLN device that would spend energy doing that? >>> It makes a lot more sense to push the burden to the power border router at the edge of the LLN in case the packet goes out the LLN towards the Internet. >>> >>> 3) The FL can only be compressed if it is NULL. This is the natural value for any constrained device, whether it aims at forwarding over RPL or not. >>> The burden of computing the tuple in the originator is not only on that node, but on all nodes in the LLN, and that would be whether the packet goes out to the Internet where the tuple can be used, or not. >>> HbH adds up to the waste, additional encap then adds up too. In a LLN that means wasting energy on every packet, with practical and measurable consequences in terms of battery life. In classical 15.4 that also means more fragmentation, and the consequences cascade. >>> >>> The draft does not prevent an instance that needs the flow label for >>> other usages to use the HbH. But is allows to control the damage when >>> flow label is not used otherwise. Please see inline >>> >>> >>> When a forwarding node receives a packet with the flow label set, how does it determine whether the flow label contains an identifier of the 5-tuple, or it contains the RPL HbH information? To get it wrong would interfere with the forwarding behavior and lead to interoperability issues. >>> >>> [] Does not. If the instance is configured for Flow Label, then the original value is lost. In the future, we could store it in a new HC option but so far the need as not emerged. >>> >>> >>> When packets are received from an external prefix, how does the ingress router handle the flow label? Would it destroy the original label, leave the original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the label (ie: the inner header contains the original flow label, and the outer header contains the HbH information)? >>> >>> [] The only usage is in the core. When the FL comes in the LLN, the role is done, the FL would be ignored anyway. >>> I hoped we could convey something end to end here, like a hint for the instanceId, but failed so far. >>> So we are back to the BR selecting the instance based on the same heuristics as if the HbH is used. >>> >>> >>> How would the DODAG root rebuild the flow label from the 5-tuple if it encounters packets that have been fragmented at the IPv6 layer? The primary use of the flow label is so that routers don't have to reassemble IPv6 fragments when forwarding to determine the 5-tuple (which is a challenging thing for a router to do). >>> >>> [] Since the BR compute the FL, it uses the same heuristic for the first and all fragments. Mixing instanceID and IP addresses mostly. Or keeping only the instanceID when we want the latency+jitter to be homogeneous within an instance over the net. For LLN applications, the distribution of 5 tuples is a lot wider than necessary or even beneficial for the core, and instanceID + IP provides a better granularity and more meaningful volumes. >>> >>> Cheers, >>> >>> Pascal >>> >>> Cheers, >>> Owen >>> >>> On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: >>> Hi >>> >>> When I started this draft, we had a series of chats with Brian Carpenter and apparently reached a gentleman agreement that it was doable within the RPL domain to use the flow label and avoid the Hop by Hop option. >>> >>> I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on that discussion but did not get news from the group since then. >>> >>> This technique has a number of advantages, in particular -it saves >>> extra bytes for the RPL option and the HbH header. >>> -it also avoids the prescribed tunneling within the RPL domain for packets from the outside. >>> - it has an optimized compression with 6LoWPAN. >>> >>> Is there interest in the group to continue? If so I'd be glad to have some discussion time at the next meeting. >>> >>> Cheers, >>> >>> >>> >>> Pascal Thubert >>> IPv6 Engineering >>> >>> pthubert@cisco.com >>> Phone :+33 497 23 26 34 >>> Mobile :+33 619 98 29 85 >>> >>> >>> Cisco Systems >>> Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille >>> 06410 Biot - Sophia Antipolis >>> France >>> Cisco.com >>> >>> [Description: Description: http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg] >>> >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Roll mailing 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 rdroms.ietf@gmail.com Wed Oct 24 09:29: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 BBFED21F8CBC for ; Wed, 24 Oct 2012 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 plZ1SX1252HG for ; Wed, 24 Oct 2012 09:29:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53FFF21F8CB2 for ; Wed, 24 Oct 2012 09:29:01 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so337116bkc.31 for ; Wed, 24 Oct 2012 09:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=N3Pa/R2jH1cMMmjPskrK5d0QYI6Uilwb8oGLc8EWNSw=; b=wKhazwtRxpfnnzu2r568yZIKNvEb64cIYls/a1BpAcGeSrB0vPn5pS6EygyDSfAwV9 WjFnOExYpTKv/A6ToscI7AYYmUITKqAEjCI/IBVuHNnWo9CrT63WUIsneMhppIGfspc+ b1CCL4yOuslKWtErJW+8EEclreLDCOPHLs9ob6I+NHMSL9/iq8OWzLncC4BLZli/RuLq g9u0sd3CvIvODb6iNfOkZvzrgW8BdoMnE/wiad5v/E+vVIjbgCJnQ9/QgAy6joZwfPTE vNrOoyi66XKVu8pyTfRt8LTD5UzfG88EJCJB+xHmylO1vjhsg5V5pm1HdNAgkDnvwz79 b/vg== Received: by 10.205.126.16 with SMTP id gu16mr4875307bkc.67.1351096140319; Wed, 24 Oct 2012 09:29:00 -0700 (PDT) Received: from [172.16.5.158] ([83.175.217.26]) by mx.google.com with ESMTPS id 1sm8650718bks.3.2012.10.24.09.28.57 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 09:28:59 -0700 (PDT) References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> <50881297.4050801@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50881297.4050801@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4556F196-AFD4-41A4-BDDB-1C3514C4F96B@gmail.com> X-Mailer: iPhone Mail (10A405) From: Ralph Droms Date: Wed, 24 Oct 2012 18:28:53 +0200 To: Brian E Carpenter Cc: roll 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: Wed, 24 Oct 2012 16:29:03 -0000 On Oct 24, 2012, at 6:08 PM, Brian E Carpenter = wrote: > On 24/10/2012 15:40, Ralph Droms wrote: >> Seems to me this conversation ought to include 6man fairly soon. >=20 > If ROLL wants to go this way, I agree. Right. I've been waiting to see how the conversation here plays out before b= ringing up 6man. > I *think* the proposal does > no violence to the 6man RFCs, but that's only my opinion. Well, of course yours is a carefully considered and respected opinion... - Ralph >=20 > Brian >=20 >>=20 >> - Ralph >>=20 >> On Oct 24, 2012, at 4:14 PM 10/24/12, Pascal Thubert (pthubert) wrote: >>=20 >>> Hi Brian, >>>=20 >>>> The worst case I can see from this approach is that all packets with th= e same source/dest address pair would get the same flow label and hence be t= reated the same for ECMP, LAG or any other kind of load balancing >>> This is actually not the case.=20 >>>=20 >>> A same node may participate to multiple instances, each instance designe= d to serve a certain class of traffic with a certain optimization.=20 >>> With the proposal, the instance-ID is stamped in the flow label. >>> The root will probably use the instance-ID for the computation of the fi= nal flow label, so that packets received over a same instance are treated th= e same over the core.=20 >>>=20 >>> This is true whether the packets are from a same or from multiple source= s. So the root may or may not aggregate multiple sensors (field devices) in a= same flow - or not. >>>=20 >>> For some applications such as industrial control flows, jitter and laten= cy are critical, and it is good that different sources are treated the same,= thus considered a same flow. >>> This would be difficult to coordinate ifs the sensors themselves were in= charge of computing the label but is an obvious thing to do for the root. >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>>=20 >>> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 >>> Sent: mercredi 24 octobre 2012 16:00 >>> To: Pascal Thubert (pthubert) >>> Cc: Owen Kirby; roll@ietf.org >>> Subject: Re: [Roll] using the flow label instead of hop by hop >>>=20 >>> The worst case I can see from this approach is that all packets with the= same source/dest address pair would get the same flow label and hence be tr= eated the same for ECMP, LAG or any other kind of load balancing. That will a= rise if the flow label has to be calculated based only on the address 2-tupl= e due to fragmentation. I don't see that as a disaster - a lot of load balan= cing is already based on the 2-tuple anyway. >>>=20 >>> The revised flow label spec explicitly allows the case where it's a rout= er (often but not necessarily the first hop router) that sets the flow label= , iff the source doesn't do so. As far as I understand the proposal, it's co= mpatible with that. >>>=20 >>> Regards >>> Brian Carpenter >>>=20 >>> On 20/10/2012 09:09, Pascal Thubert (pthubert) wrote: >>>> Hi Owen: >>>>=20 >>>> I think we are back to the discussion with Brian (cc'ing Brian to make s= ure my account is faithful). >>>> I think that we converged that the draft is actually doable, considerin= g the LLN as one bug host from the perspective of the wider Internet. >>>>=20 >>>> With the proposal, the LLN gateway is in charge of setting the flow lab= el towards the Internet and the flow label does not belong to the packet ori= ginator in the LLN, which, like any host in the Internet for the last 20 yea= rs, are wasting the precious bits. >>>> So if an LLN originator sets the flow label it will be erased and recal= culated if the LLN uses that draft. Can we justify that? >>>>=20 >>>> 1) First thing first, the flow label is part of the IP header. Which is= where you place stuff that you want examined by the router. >>>> Anything farther down the packet will be a lot more trouble for the rou= ter. And app level communication does not belong here, whether it is a LLN a= pp or any other app. >>>>=20 >>>> 2) After 15 years of IPv6, the internet community finally found and sta= ndardized a usage for the label that basically adds burden to the hosts to s= erve the core but neiter sender nor receiver can use the value of the field f= or any practical usage. >>>> For LLN devices that would mean ask a battery operated constrained node= to do additional computation in case the packet goes in the powered Interne= t and needs load balancing. Do you know of any LLN device that would spend e= nergy doing that? >>>> It makes a lot more sense to push the burden to the power border router= at the edge of the LLN in case the packet goes out the LLN towards the Inte= rnet. >>>>=20 >>>> 3) The FL can only be compressed if it is NULL. This is the natural val= ue for any constrained device, whether it aims at forwarding over RPL or not= . >>>> The burden of computing the tuple in the originator is not only on that= node, but on all nodes in the LLN, and that would be whether the packet goe= s out to the Internet where the tuple can be used, or not. >>>> HbH adds up to the waste, additional encap then adds up too. In a LLN t= hat means wasting energy on every packet, with practical and measurable cons= equences in terms of battery life. In classical 15.4 that also means more fr= agmentation, and the consequences cascade. >>>>=20 >>>> The draft does not prevent an instance that needs the flow label for=20= >>>> other usages to use the HbH. But is allows to control the damage when=20= >>>> flow label is not used otherwise. Please see inline >>>>=20 >>>>=20 >>>> When a forwarding node receives a packet with the flow label set, how d= oes it determine whether the flow label contains an identifier of the 5-tupl= e, or it contains the RPL HbH information? To get it wrong would interfere w= ith the forwarding behavior and lead to interoperability issues. >>>>=20 >>>> [] Does not. If the instance is configured for Flow Label, then the ori= ginal value is lost. In the future, we could store it in a new HC option but= so far the need as not emerged. >>>>=20 >>>>=20 >>>> When packets are received from an external prefix, how does the ingress= router handle the flow label? Would it destroy the original label, leave th= e original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the l= abel (ie: the inner header contains the original flow label, and the outer h= eader contains the HbH information)? >>>>=20 >>>> [] The only usage is in the core. When the FL comes in the LLN, the rol= e is done, the FL would be ignored anyway. >>>> I hoped we could convey something end to end here, like a hint for the i= nstanceId, but failed so far. >>>> So we are back to the BR selecting the instance based on the same heuri= stics as if the HbH is used. >>>>=20 >>>>=20 >>>> How would the DODAG root rebuild the flow label from the 5-tuple if it e= ncounters packets that have been fragmented at the IPv6 layer? The primary u= se of the flow label is so that routers don't have to reassemble IPv6 fragme= nts when forwarding to determine the 5-tuple (which is a challenging thing f= or a router to do). >>>>=20 >>>> [] Since the BR compute the FL, it uses the same heuristic for the firs= t and all fragments. Mixing instanceID and IP addresses mostly. Or keeping o= nly the instanceID when we want the latency+jitter to be homogeneous within a= n instance over the net. For LLN applications, the distribution of 5 tuples i= s a lot wider than necessary or even beneficial for the core, and instanceI= D + IP provides a better granularity and more meaningful volumes. >>>>=20 >>>> Cheers, >>>>=20 >>>> Pascal >>>>=20 >>>> Cheers, >>>> Owen >>>>=20 >>>> On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote: >>>> Hi >>>>=20 >>>> When I started this draft, we had a series of chats with Brian Carpente= r and apparently reached a gentleman agreement that it was doable within the= RPL domain to use the flow label and avoid the Hop by Hop option. >>>>=20 >>>> I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01= based on that discussion but did not get news from the group since then. >>>>=20 >>>> This technique has a number of advantages, in particular -it saves=20 >>>> extra bytes for the RPL option and the HbH header. >>>> -it also avoids the prescribed tunneling within the RPL domain for pack= ets from the outside. >>>> - it has an optimized compression with 6LoWPAN. >>>>=20 >>>> Is there interest in the group to continue? If so I'd be glad to have s= ome discussion time at the next meeting. >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>> Pascal Thubert >>>> IPv6 Engineering >>>>=20 >>>> pthubert@cisco.com >>>> Phone :+33 497 23 26 34 >>>> Mobile :+33 619 98 29 85 >>>>=20 >>>>=20 >>>> Cisco Systems >>>> Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille >>>> 06410 Biot - Sophia Antipolis >>>> France >>>> Cisco.com >>>>=20 >>>> [Description: Description: http://www.cisco.com/we= b/europe/images/email/signature/vertical04.jpg] >>>>=20 >>>> For corporate legal information go to:=20 >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> This e-mail may contain confidential and privileged material for the so= le use of the intended recipient. Any review, use, distribution or disclosur= e by others is strictly prohibited. If you are not the intended recipient (o= r authorized to receive for the recipient), please contact the sender by rep= ly e-mail and delete all copies of this message. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> Roll mailing list >>>>=20 >>>> Roll@ietf.org >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 From adrian@olddog.co.uk Wed Oct 24 10:46: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 244F321F882B for ; Wed, 24 Oct 2012 10:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 aX+mg-7SDX6P for ; Wed, 24 Oct 2012 10:46:02 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D470B21F880B for ; Wed, 24 Oct 2012 10:46:01 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OHjv7b014252; Wed, 24 Oct 2012 18:45:57 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OHju5h014238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Oct 2012 18:45:56 +0100 From: "Adrian Farrel" To: "'Pascal Thubert \(pthubert\)'" , "'John E Drake'" , References: In-Reply-To: Date: Wed, 24 Oct 2012 18:45:54 +0100 Message-ID: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGl+sB8sMRWMj58md5XARQXdypERJgYKJIw Content-Language: en-gb 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 Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:46:03 -0000 Hi Pascal, Speaking as an individual and without an implementation... I guess I need to look at this in more detail (it always helps to read the draft) this still sounds exactly like label switching. That is some value of a label is applied to a packet and that label will identify the flow and direct the forwarding decision made at the next router. Furthermore, the label may be modified hop by hop. The "overloading" of information into the label doesn't get away from the fact that it is a label applied to a packet. Cheers, Adrian > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: 23 October 2012 12:41 > To: John E Drake; adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop > > Hi: > > list.> > > In short: The packets carried within an instance share a characteristic which the > OF optimizes for. > The OF determines a RPL topology and thus how the flow that is tagged with that > instance is processed in the network. > For flows to be processed differently one may different instances. > > Considering how open the definition of flow in 2460 is, this fits. > > The rank stretches that a bit since it qualifies where the flow is in the Network. > Then again RFC 2460 is open enough not to bar anything. > > Rather, the spirit is for us to do something useful with this field in the forwarding > plane and that is exactly what this proposal is doing . > > Cheers, > > Pascal > > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: lundi 22 octobre 2012 21:15 > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop > > Pascal, > > So the information that you are carrying in the IPv6 label field has nothing to do > with IPv6 labels? So, why is this not an egregious hack? > > Yours irrespectively, > > John > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Pascal Thubert (pthubert) > > Sent: Saturday, October 20, 2012 2:30 PM > > To: adrian@olddog.co.uk; roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > Adrian, > > > > This draft is not mpls. This draft is about carrying the RPL info > > (rank, instance, flags) in the flow label as opposed to the HbH which > > incurs additional header + eventually tunneling. > > My other draft on fragment forwarding has a lot more to do with label > > switching since the first fragment lays a label that the other > > fragments follow. But then we are not using the flow label but a > > 6LoWPAN datagram identifier tag. > > > > Cheers, > > > > Pascal > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Adrian Farrel > > Sent: samedi 20 octobre 2012 21:37 > > To: roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > Speaking as an individual and without an implementation... > > > > Isn't this MPLS? > > Hasn't the routing area looked at the idea of using the IPv6 flow > > label for labelled forwarding more than once in the past? > > Hasn't the conclusion always been that you could do it, but you would > > have to be sure that you were not overloading the field? > > And hasn't the resulting discussion led to a debate on the value of > > label stacks and the impracticality of label stacks using the flow > > label? > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of Philip Levis > > > Sent: 20 October 2012 14:50 > > > To: Pascal Thubert (pthubert) > > > Cc: roll@ietf.org > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > > > Phil; > > > > > > > > There is indeed lot of pressure for this in terms of header sizes > > > > and energy > > > consumption in the *real world*. > > > > > > I'm personally concerned about header sizes and energy consumption > > > in The Matrix. Because I don't live in the real world. Oh, wait, > > > sorry, > > I > > > do. Can you > > walk > > > me through the quantitative reasoning that a few bytes of header > > > will increase energy consumption? It the belief that it will lead to > > > sub-packet > > fragmentation in > > > some non-amortized sense? Generally speaking, in low power wireless > > > networks, energy consumption is dominated by idle listening and > > > communication latency/interval support, not the length of packets. > > > Of course there is a > > spectrum > > > of low power approaches and their point on that spectrum. Are you > > > thinking of one in particular? > > > > > > Could implementers who are encountering this pressure comment? I'm a > > > sucker for and easily swayed by quantitative data as well as > > > first-hand rather than second-hand reports. > > > > > > > And there is no hack in the proposed solution. > > > > Simply we believe more in practical engineering and ML discussions > > > > than we > > > trust in crystal balls. > > > > > > *coughs politely* I believe in very practical engineering that > > > considers long > > term > > > consequences. Solving a problem a certain way now might cause > > > significant problems in the future. I agree this is a tradeoff -- in > > > my personal opinion, > > nothing > > > more, the tradeoff on this one is 100% clear. > > > > > > Phil > > > > > > ------ > > > > > > Philip Levis > > > President, Kumu Networks > > > Associate Professor, Stanford University > > > http://csl.stanford.edu/~pal > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Oct 24 11:06: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 3D7F921F884F for ; Wed, 24 Oct 2012 11:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.522 X-Spam-Level: X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 8sCSRvtzm56x for ; Wed, 24 Oct 2012 11:06:11 -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 857D021F8840 for ; Wed, 24 Oct 2012 11:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=931; q=dns/txt; s=iport; t=1351101971; x=1352311571; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UsjFgLcYZ+XvKQrDjfcaiE2/qq/o26g6u9Krmuyay14=; b=ikGhjIwj2GsgyYoMAyOs5Wvukc5V3HeWqRW5Y5SflQfXyHQr10eSVy/0 SRDgT4Hy5euDrZ5OeYJ/hFLJVdECFfAK8nJvJyn1cccViIgbF7r6Gl+mL zFCXxWvHktqGHAejCIRqUEez8LgJSJPOnHFi696MP3XxvXLcdNRZEAq/t k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACwtiFCtJV2d/2dsb2JhbABEwXmBCIIgAQQSASc/EgEqFEIPGAQODRqHYpxMoBqLfIVxYQOkQYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="134748397" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 24 Oct 2012 18:06:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9OI6Bqx017740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 18:06:11 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 13:06:10 -0500 From: "JP Vasseur (jvasseur)" To: "roll@ietf.org WG" Thread-Topic: Draft Agenda Thread-Index: AQHNshI/1lX/Rsr9DkGoyi2Nck5zRw== Date: Wed, 24 Oct 2012 18:06:10 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772201ED1C@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.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--26.685400-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: Michael Richardson Subject: [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: Wed, 24 Oct 2012 18:06:12 -0000 Dear all, please find bellow the draft agenda for ROLL's WG meeting in Atlanta - let = us know if you have any comment: 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) RPL deployment experience in large scale networks draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] 7) RPL applicability in industrial networks draft-phinney-roll-rpl-industrial-applicability-01 (Pascal - 10mn) [60] 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] draft-guo-roll-loop-free-dodag-repair Thanks. JP and Michael.= From jeonggil.ko@gmail.com Wed Oct 24 14:42:04 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 A807F21F86B8 for ; Wed, 24 Oct 2012 14:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.445 X-Spam-Level: X-Spam-Status: No, score=-101.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, 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 3B2yn2hpJQK7 for ; Wed, 24 Oct 2012 14:42:04 -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 E372921F863F for ; Wed, 24 Oct 2012 14:42:03 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so657350pad.31 for ; Wed, 24 Oct 2012 14:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dAHKA3xERj7ZwnCctCg3mG9FCx4rzlzORz2Z/m/bbfI=; b=WC5H0sPthakEuxw/JTONkv0tdmiwbMrUnP2W5JhAFvYnhdaCBK7Mu88nU+rhDBKqc1 jRBYBVcDU79YUbmABWCTN3N9W1L+mTExnfJ9pYIdU+zUmAchlEGcclixN/hXZtCKDCKX qp25BvDMK2s0GTEEu4OodJBxZelUx65dXn+cLQCyCHHgzQuGWdsl9BaEGHLUVJ5WORyE Mkt2izfuC1wfIjpvBRnW3Lg16Lq+jknLdfRTBgIWePffj/F2mWWGBULHq4wqs2Q1TMAy T1ilzWCTZfRh8iWadq60JDi8p5bGAKvXhhDMAQr59CKpT3V8lYdi5pPWkvzA0mW3LHrd YEsQ== Received: by 10.68.247.196 with SMTP id yg4mr54410010pbc.167.1351114923694; Wed, 24 Oct 2012 14:42:03 -0700 (PDT) Received: from 172.20.nate.com ([203.226.204.139]) by mx.google.com with ESMTPS id j10sm10078121pax.4.2012.10.24.14.41.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 14:42:02 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JeongGil Ko In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> Date: Thu, 25 Oct 2012 06:41:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1278) Cc: "roll@ietf.org WG" , Michael Richardson 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: Wed, 24 Oct 2012 21:42:04 -0000 JP, I've also put in a request for a slot at the meeting in Atlanta for = presenting "draft-ko-roll-mix-network-pathology" but I do not see this = on the agenda. This draft discusses about a critical and practical = performance issue of RPL networks (both collection and downwards) when = they are intentionally or accidentally deployed with devices of = different MOPs. I believe that such an issue is important to discuss as = a group. Thanks. -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 25, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote: > Dear all, >=20 > please find bellow the draft agenda for ROLL's WG meeting in Atlanta - = let us know if you have any comment: >=20 > 1) Agenda/admin (Chairs - 5mn) [5] >=20 > 2) WG Status (Chairs - 10 mn) [15] >=20 > 3) Security Framework and Applicability Statement template > (Michael - 10m) [25] > draft=3Ddraft-richardson-roll-applicability-template-00 >=20 > 4) RPL applicability in industrial networks > draft-phinney-roll-rpl-industrial-applicability-01 > (Pascal - 10mn) [35] >=20 > 5) Industrial Deterministic Routing Extension for Low-Power > and Lossy Networks (M. Wei - 10mn) [45] >=20 > 6) RPL deployment experience in large scale networks > draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >=20 > 7) RPL applicability in industrial networks > draft-phinney-roll-rpl-industrial-applicability-01 > (Pascal - 10mn) [60] >=20 > 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] > draft-guo-roll-loop-free-dodag-repair >=20 > Thanks. >=20 > JP and Michael. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed Oct 24 23:53: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 8022311E80A3 for ; Wed, 24 Oct 2012 23:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.757 X-Spam-Level: X-Spam-Status: No, score=-9.757 tagged_above=-999 required=5 tests=[AWL=0.842, 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 Sbqa429aEqjE for ; Wed, 24 Oct 2012 23:53:20 -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 3D05111E808D for ; Wed, 24 Oct 2012 23:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7789; q=dns/txt; s=iport; t=1351148000; x=1352357600; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0rrCeYK8D+F/8/G8mS+j8+AMcBnA/NhfjDVLhYh3RYg=; b=KFgTyu6YzgzohvPI4IWJ12mgIXg18vICSMpSlQKpvJvFB5juYYLV8M5T DS9aQVYR+nqTfcyAGQad3VSbMv+AzxYK8xYxcwpWuSY7R0nx5EOHuZRCN glMlgjuffyqFAUiQogv1HvPii9NGnY84qe/jH/E9jr/sQzcF3Z5LVuVuP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHjgiFCtJXG9/2dsb2JhbAA6ChbCC4EIgh4BAQEEAQEBDwEnLQcEEwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIEweHYgudLKAEi2EQC4VxYQOhH4MigWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,645,1344211200"; d="scan'208";a="135201556" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 25 Oct 2012 06:53:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9P6rCZw027375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Oct 2012 06:53:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.178]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 01:53:12 -0500 From: "Pascal Thubert (pthubert)" To: "adrian@olddog.co.uk" , "'John E Drake'" , "roll@ietf.org" Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: AQGl+sB8sMRWMj58md5XARQXdypERJgYKJIwgADXyYA= Date: Thu, 25 Oct 2012 06:53:11 +0000 Deferred-Delivery: Thu, 25 Oct 2012 06:53:00 +0000 Message-ID: References: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> In-Reply-To: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.85.245] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--59.983100-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 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: Thu, 25 Oct 2012 06:53:21 -0000 I certainly agree with a good number of your words, Adrian. *We are indeed talking about a label that is applied to a packet.=20 *It is a label that is related to the flow, and determined by the instance = ID. *It is information that will be used for the routing decision at each hop i= n the LLN. Which means that the flow label in the routing header is the perfect place = for it. I am still unsure what the relation you make with label switching. The dis= tinction I'm making is as follows: *In this proposal there is no switching of tags, since the instance is cons= erved in the label. Only some metadata is mutable. *there is no switching packets either, RPL routing still takes place at eve= ry hop which involves a route lookup. *and there is no switched path to follow with the label, but a topology -a = RIB- to be determined. IOW, the instance is more like a topology index for the RIB/FIB lookup that= still needs to take place. Cheers, Pascal -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: mercredi 24 octobre 2012 19:46 To: Pascal Thubert (pthubert); 'John E Drake'; roll@ietf.org Subject: RE: [Roll] using the flow label instead of hop by hop Hi Pascal, Speaking as an individual and without an implementation... I guess I need to look at this in more detail (it always helps to read the draft) this still sounds exactly like label switching. That is some value of a label is applied to a packet and that label will id= entify the flow and direct the forwarding decision made at the next router. Furthermore, the label may be modified hop by hop. The "overloading" of information into the label doesn't get away from the f= act that it is a label applied to a packet. Cheers, Adrian > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: 23 October 2012 12:41 > To: John E Drake; adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Hi: >=20 > copy the list.> >=20 > In short: The packets carried within an instance share a=20 > characteristic which the > OF optimizes for. > The OF determines a RPL topology and thus how the flow that is tagged=20 > with that > instance is processed in the network. > For flows to be processed differently one may different instances. >=20 > Considering how open the definition of flow in 2460 is, this fits. >=20 > The rank stretches that a bit since it qualifies where the flow is in=20 > the Network. > Then again RFC 2460 is open enough not to bar anything. >=20 > Rather, the spirit is for us to do something useful with this field in=20 > the forwarding > plane and that is exactly what this proposal is doing . >=20 > Cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: lundi 22 octobre 2012 21:15 > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Pascal, >=20 > So the information that you are carrying in the IPv6 label field has=20 > nothing to do > with IPv6 labels? So, why is this not an egregious hack? >=20 > Yours irrespectively, >=20 > John >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > > Of Pascal Thubert (pthubert) > > Sent: Saturday, October 20, 2012 2:30 PM > > To: adrian@olddog.co.uk; roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > Adrian, > > > > This draft is not mpls. This draft is about carrying the RPL info=20 > > (rank, instance, flags) in the flow label as opposed to the HbH=20 > > which incurs additional header + eventually tunneling. > > My other draft on fragment forwarding has a lot more to do with=20 > > label switching since the first fragment lays a label that the other=20 > > fragments follow. But then we are not using the flow label but a=20 > > 6LoWPAN datagram identifier tag. > > > > Cheers, > > > > Pascal > > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > > Of Adrian Farrel > > Sent: samedi 20 octobre 2012 21:37 > > To: roll@ietf.org > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > Speaking as an individual and without an implementation... > > > > Isn't this MPLS? > > Hasn't the routing area looked at the idea of using the IPv6 flow=20 > > label for labelled forwarding more than once in the past? > > Hasn't the conclusion always been that you could do it, but you=20 > > would have to be sure that you were not overloading the field? > > And hasn't the resulting discussion led to a debate on the value of=20 > > label stacks and the impracticality of label stacks using the flow=20 > > label? > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > > > Behalf Of Philip Levis > > > Sent: 20 October 2012 14:50 > > > To: Pascal Thubert (pthubert) > > > Cc: roll@ietf.org > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > > > Phil; > > > > > > > > There is indeed lot of pressure for this in terms of header=20 > > > > sizes and energy > > > consumption in the *real world*. > > > > > > I'm personally concerned about header sizes and energy consumption=20 > > > in The Matrix. Because I don't live in the real world. Oh, wait,=20 > > > sorry, > > I > > > do. Can you > > walk > > > me through the quantitative reasoning that a few bytes of header=20 > > > will increase energy consumption? It the belief that it will lead=20 > > > to sub-packet > > fragmentation in > > > some non-amortized sense? Generally speaking, in low power=20 > > > wireless networks, energy consumption is dominated by idle=20 > > > listening and communication latency/interval support, not the length = of packets. > > > Of course there is a > > spectrum > > > of low power approaches and their point on that spectrum. Are you=20 > > > thinking of one in particular? > > > > > > Could implementers who are encountering this pressure comment? I'm=20 > > > a sucker for and easily swayed by quantitative data as well as=20 > > > first-hand rather than second-hand reports. > > > > > > > And there is no hack in the proposed solution. > > > > Simply we believe more in practical engineering and ML=20 > > > > discussions than we > > > trust in crystal balls. > > > > > > *coughs politely* I believe in very practical engineering that=20 > > > considers long > > term > > > consequences. Solving a problem a certain way now might cause=20 > > > significant problems in the future. I agree this is a tradeoff --=20 > > > in my personal opinion, > > nothing > > > more, the tradeoff on this one is 100% clear. > > > > > > Phil > > > > > > ------ > > > > > > Philip Levis > > > President, Kumu Networks > > > Associate Professor, Stanford University=20 > > > http://csl.stanford.edu/~pal=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 From jvasseur@cisco.com Wed Oct 24 23:55: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 CA08A11E80A6 for ; Wed, 24 Oct 2012 23:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.378 X-Spam-Level: X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 3lhrM4lJJMUv for ; Wed, 24 Oct 2012 23:55:35 -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 DEE5E11E80A3 for ; Wed, 24 Oct 2012 23:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=361; q=dns/txt; s=iport; t=1351148135; x=1352357735; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=TuoniFjKOo4deBaZ/lL6Ur7aY7wDJAEZc8aaqCWAqOo=; b=RGYpCEkZ7Kb1s8Khy5B9LgdAXMnf2n3us+mcfBnNeXPixj5SwrhY1Dh6 haTnE3TFordoFC9YS5dCO5JuUmg3GKpQyv3R2YJ9AUgUSmwhgw5Ex4lb2 rykshZBQAayyxg45iUExGnucxSCpJlAtQM2n0GI14GM6WX6nP/ygPCfaX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALbhiFCtJXG+/2dsb2JhbABEwiCBCIIgAQQSASc0CxIBKhRCJwQODRqHYp03oASRbWEDpEGBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,645,1344211200"; d="scan'208";a="135202081" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 25 Oct 2012 06:55:34 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9P6tYTH028714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Oct 2012 06:55:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 01:55:34 -0500 From: "JP Vasseur (jvasseur)" To: "roll@ietf.org WG" Thread-Topic: WG Last Call draft-ietf-roll-trickle-mcast-02 Thread-Index: AQHNsn26aiFXfsVin0Sq6ZVjYiOAPg== Date: Thu, 25 Oct 2012 06:55:33 +0000 Message-ID: <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.60.114.231] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--32.385600-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: Michael Richardson Subject: [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, 25 Oct 2012 06:55:35 -0000 Dear all, draft-ietf-roll-trickle-mcast-02 has been discussed on the mailing list an= d 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. Thanks. JP. From alejandro.lampropulos@telecom-bretagne.eu Wed Oct 24 09:27: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 763C121F8B7E for ; Wed, 24 Oct 2012 09:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SUBJ_ALL_CAPS=2.077] 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 5euLQRqma0iH for ; Wed, 24 Oct 2012 09:27:25 -0700 (PDT) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id DCA6C21F85F3 for ; Wed, 24 Oct 2012 09:27:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id AF842342DA for ; Wed, 24 Oct 2012 18:27:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWWg4nGrzVjY for ; Wed, 24 Oct 2012 18:27:23 +0200 (CEST) Received: from zmail210.enst-bretagne.fr (zmail210.enst-bretagne.fr [10.29.89.130]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 8DADF342C3 for ; Wed, 24 Oct 2012 18:27:23 +0200 (CEST) Date: Wed, 24 Oct 2012 18:27:23 +0200 (CEST) From: Alejandro Martin LAMPROPULOS To: roll@ietf.org Message-ID: <276d7202-9185-4e21-95dc-34723d8001d3@zmail210> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - FF3.0 (Mac)/7.1.3_GA_3346) Subject: [Roll] RPL (RFC 6550). DTSN 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, 25 Oct 2012 07:35:57 -0000 Hi, I saw that in the RFC 6550 the DTSN value is used to trigger DAO messages from sub-DODAG. My question is, when would it be useful to increment this value? In the RFC it says: 'A RPL implementation MAY allow for configuring a set of rules specifying the triggers for DTSN increment (manual or event-based).' Which events could be used to trigger the DTSN incrementation? Thank you very much. Regards, Alejandro From stokcons@xs4all.nl Thu Oct 25 04:28:31 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 E2D1D21F89BE for ; Thu, 25 Oct 2012 04:28:31 -0700 (PDT) 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 lC-v1PmvM0sA for ; Thu, 25 Oct 2012 04:28:30 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04D21F89B4 for ; Thu, 25 Oct 2012 04:28:30 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9PBRuOU065407; Thu, 25 Oct 2012 13:27:57 +0200 (CEST) (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, 25 Oct 2012 13:27:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2012 13:27:56 +0200 From: peter van der Stok To: , jonathan hui , richard kelsey Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> Message-ID: <17c4d278837c229b90fe6585a0f487fa@xs4all.nl> X-Sender: stokcons@xs4all.nl (BAVYi/onJ4FZAJcKsyaHtK+DuG+8W+BW) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner 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, 25 Oct 2012 11:28:32 -0000 Dear Richard and Jonathan, We are quite happy with this new draft but I should like to comment on two aspects which need improvement according to me. (next to my earlier remark about implementation of MC domain) Multicast message encapsulation: For our applications it is important that the MC control message fits into one link-layer frame. Simulations show that with fragmented 6LoWPAN packets the MPL behavior becomes quite unpredictable unless specific measures are taken in all transmitting nodes. Knowing that the payload of a MPL packet is around 60 bytes, and may be further reduced by security overhead (see draft-keoh-tls-multicast-security-00), every byte of payload counts. Therefore I suggest that the original MC message can be distributed inside the LLN network without the encapsulation by the MPL message. I can very well imagine that encapsulation is needed to send the message to the seed (from inside the LLN network or from outside), but once it reaches the seed within the LLN, transmission of the original MC message inside the LLN is recommended without the encapsulation but including the MPL option in the header of the original MC packet. The MPL-2 draft suggests that when the MPL domain is composed of multiple MPL link-local scopes (even when contained within the LLN) each MPL forwarder encapsulates and decapsulates. I suggest that the wording is changed such that this is not necessary as long as the MC packet travels within the LLN. Forwarder behavior: The draft describes that sending of ICMP messages can be suppressed by setting REACTIVE_TIMER_EXPIRATIONS to zero. I like to suggest the same possibility for PROACTIVE_TIMER_EXPIRATIONS. The motivation is the following: In rather dense networks, it would be beneficial to reduce the number of forwarders. However, the non-forwarders may not receive some messages in spite of the density. By allowing these nodes to use the sending of ICMP messages, the forwarding nodes can be informed of the missing message to trigger a retransmission Peter van der Stok JP Vasseur (jvasseur) schreef op 2012-10-25 08:55: > Dear all, > > 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 > 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 > and copy the mailing list and the co-chairs. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Oct 25 05: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 DF9E321F8A0A for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[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 nz47msE6KDws for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3FD21F8A01 for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) Received: from sandelman.ca (unknown [67.71.177.200]) by relay.sandelman.ca (Postfix) with ESMTPS id 9F6E181AE; Thu, 25 Oct 2012 08:31:21 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 77E5ECA0C7; Thu, 25 Oct 2012 08:10:02 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-reply-to: References: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Tue, 23 Oct 2012 17:49:19 -0000." 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, 25 Oct 2012 08:10:02 -0400 Message-ID: <23613.1351167002@sandelman.ca> Sender: mcr@sandelman.ca 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: Thu, 25 Oct 2012 12:39:04 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: PT> The flow label is not protected by any IPSec so it cannot be PT> used as a backchannel end-to-end. Now that would be a hack.=20=20 I'm not sure where a back/convert channel is mentioned in the thread. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiSwaAAoJEKD0KQ7Gj3P29eEIAImQRh/viwv/DFE0YBsrDcvd Xy0nEl85QR3OFtp4+5zb5A1UBOyupzRgOI417trC4zWkvSSXCPuiUdXAE1tz/EjV NUMlkARKojNGH6gIzGmMbyq4OUTH8womb8G487yCe4MET+upOfj8mqvmVWpgObbX CLO5XM9xusfJn1lHFPtLJsqjy+ZZp17e35ovjDJZMIK32uzGTdviqkThG8BOlbHM W4dO6cwmXgTupCdD3nFbLhG8sMMZxh4tJQwpc9+pKv39WfVlF1aDPPT0wLSli0Vk TUBlxclE+RFwGnXAjFV+ewCJlTGyK6guesbVN8EtWjAuXXYhCFdC6w23WZveCH4= =Nbsx -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Oct 25 05: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 E1BE321F8ADB for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[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 HxrOV0kaVFKZ for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6D44D21F8A0B for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) Received: from sandelman.ca (unknown [67.71.177.200]) by relay.sandelman.ca (Postfix) with ESMTPS id 90A0581A9; Thu, 25 Oct 2012 08:31:21 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6CECCCA0C6; Thu, 25 Oct 2012 08:08:13 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-reply-to: <5086A598.7030508@merl.com> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> Comments: In-reply-to Jianlin Guo message dated "Tue, 23 Oct 2012 10:11:36 -0400." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) Date: Thu, 25 Oct 2012 08:08:13 -0400 Message-ID: <23378.1351166893@sandelman.ca> Sender: mcr@sandelman.ca Cc: Philip Orlik , Kieran Parsons Subject: Re: [Roll] Loop free local DODAG repair solution 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, 25 Oct 2012 12:39:04 -0000 Jianlin Guo wrote: JG> Dear ROLL WG members, JG> As we all know that loop is an open issue in RPL. Experiment shows that loop JG> occurs quite often. We have proposed a loop free local DODAG Can you quantify "quite often"? Do you have any metrics for how often loops occur, and what the cost is of their repair? I think that the WG would be very very very interested in additional -experiences draft, or pointers to papers explaining same, that gives a repeateable experiment in which loops are observed. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mcr@sandelman.ca Thu Oct 25 05:39:04 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 E3CC621F8AEC for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[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 ZUYDNQorlj1H for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 72A6021F8A14 for ; Thu, 25 Oct 2012 05:39:03 -0700 (PDT) Received: from sandelman.ca (unknown [67.71.177.200]) by relay.sandelman.ca (Postfix) with ESMTPS id 98A5E81AC; Thu, 25 Oct 2012 08:31:21 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A78D9CA0C9; Thu, 25 Oct 2012 08:16:56 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-reply-to: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> References: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> Comments: In-reply-to "Adrian Farrel" message dated "Wed, 24 Oct 2012 18:45:54 +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: Thu, 25 Oct 2012 08:16:56 -0400 Message-ID: <23940.1351167416@sandelman.ca> Sender: mcr@sandelman.ca 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: Thu, 25 Oct 2012 12:39:04 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Adrian Farrel wrote: AF> I guess I need to look at this in more detail (it always helps to r= ead the AF> draft) this still sounds exactly like label switching. It sure looks like it at first. However, labelled switching uses the label to get across a series of routers.. The label mostly denotes a specific path which the source has chosen. Labelled switching is therefore a form of source route (except that the source route is abstracted). The presence of this label in RPL does not pick a route, rather it picks one routing table among many. It is therefore more akin to the DSCP than the MPLS label, but even that's not correct. RPL is doing storing mode (LPM at each hop), or non-storing mode (source routing) at each hop regardless of the label. The label picks a DODAG. It's probably more relevant to storing mode where there is an evaluation (longest-prefix-match) at each hop, and when there are multiple DODAG, there are multiple fib. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiS23AAoJEKD0KQ7Gj3P2k+cIAI/O2MdhBi8m/6y264bhB5K0 E9YQReCoL/QJU9qZGGuPBl9553d3jBp0XqbAcPvw05V0EiB4IDgbGejkZO4SjCeT D0qTzH8aqVI0w2L09kGDPiatk0yk4s5S8HAdquRBSn2xTMQOtKC4prh3f3RmumSx mf5naIXFKXGkc8NeIOvJg/IJDdv8pZqw1CoR7SJdFlNpi6h8uCi2+CAVua2OWAjw 8Un0u8K3MOPR+Uky/DLQEfOr0CVdMcV+JC+3ehYGpyW2tOtXzFY6bPx7BvXmlNai Xj/iztfFwE3zTtGQA/0tAJXfjPV/U7GYPvCCNBBvNC1Ot57V6XdgZmkBpxtZQag= =GRlH -----END PGP SIGNATURE----- --=-=-=-- From Gerald.Paprocki@us.elster.com Thu Oct 25 05:48: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 BEFB921F87A2 for ; Thu, 25 Oct 2012 05:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_05=-1.11, 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 rtZON+eL93iz for ; Thu, 25 Oct 2012 05:48:35 -0700 (PDT) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by ietfa.amsl.com (Postfix) with SMTP id 2830121F879E for ; Thu, 25 Oct 2012 05:48:35 -0700 (PDT) X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-2.tower-136.messagelabs.com!1351169308!11099814!1 X-Originating-IP: [129.179.1.27] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32618 invoked from network); 25 Oct 2012 12:48:28 -0000 Received: from ip27.net129179-1.block1.us.syntegra.com (HELO us-smtp01.smtp.elster.com) (129.179.1.27) by server-2.tower-136.messagelabs.com with SMTP; 25 Oct 2012 12:48:28 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: roll@ietf.org Message-ID: Date: Thu, 25 Oct 2012 08:48:31 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.2FP3|July 10, 2011) at 10/25/2012 08:39:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Gerald Paprocki is out of the office (returning 10/29/2012) 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, 25 Oct 2012 12:48:36 -0000 I am out of the office until 10/29/2012. I am out of the office and will be returning Monday Oct 29th. If assistance is required during my absence please contact one of my primes below. - IP AxisLink Secure Tunnel server - Inyong Park @ 919-250-5698 - EA_MS Interfaces - Bill Phillips @ 919-212-4888 - EA Inspector - Ying Xu @ 919-250-5446 Note: This is an automated response to your message "Roll Digest, Vol 57, Issue 33" sent on 10/25/2012 8:39:04 AM. This is the only notification you will receive while this person is away. From adrian@olddog.co.uk Thu Oct 25 05:50: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 D10CC21F89D6 for ; Thu, 25 Oct 2012 05:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 Fi0avjVcODmU for ; Thu, 25 Oct 2012 05:50:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 525A121F89D1 for ; Thu, 25 Oct 2012 05:50:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9PCoVSr004381; Thu, 25 Oct 2012 13:50:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9PCoUNV004375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 13:50:30 +0100 From: "Adrian Farrel" To: "'Pascal Thubert \(pthubert\)'" , "'John E Drake'" , References: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> In-Reply-To: Date: Thu, 25 Oct 2012 13:50:28 +0100 Message-ID: <145401cdb2af$4ff91fc0$efeb5f40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGl+sB8sMRWMj58md5XARQXdypERAJyK7jBAaXWfpCX+KdcwA== Content-Language: en-gb 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 Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:50:38 -0000 Hi, This and Michael's follow-up are helpful. My take-away is that this is a place to put information that will be used during the routing process, but that the forwarding decision will not be made on this information in isolation. That makes my "overlap with label switching" concern go away. (Which is entirely different from considering whether this is a good idea or not, on which I have no position :-) Adrian > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: 25 October 2012 07:53 > To: adrian@olddog.co.uk; 'John E Drake'; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop > > I certainly agree with a good number of your words, Adrian. > *We are indeed talking about a label that is applied to a packet. > *It is a label that is related to the flow, and determined by the instance ID. > *It is information that will be used for the routing decision at each hop in the LLN. > > Which means that the flow label in the routing header is the perfect place for it. > > I am still unsure what the relation you make with label switching. The distinction > I'm making is as follows: > *In this proposal there is no switching of tags, since the instance is conserved in > the label. Only some metadata is mutable. > *there is no switching packets either, RPL routing still takes place at every hop > which involves a route lookup. > *and there is no switched path to follow with the label, but a topology -a RIB- to > be determined. > > IOW, the instance is more like a topology index for the RIB/FIB lookup that still > needs to take place. > > Cheers, > > Pascal > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: mercredi 24 octobre 2012 19:46 > To: Pascal Thubert (pthubert); 'John E Drake'; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop > > Hi Pascal, > > Speaking as an individual and without an implementation... > > I guess I need to look at this in more detail (it always helps to read the > draft) this still sounds exactly like label switching. > That is some value of a label is applied to a packet and that label will identify the > flow and direct the forwarding decision made at the next router. > Furthermore, the label may be modified hop by hop. > > The "overloading" of information into the label doesn't get away from the fact > that it is a label applied to a packet. > > Cheers, > Adrian > > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: 23 October 2012 12:41 > > To: John E Drake; adrian@olddog.co.uk; roll@ietf.org > > Subject: RE: [Roll] using the flow label instead of hop by hop > > > > Hi: > > > > > copy the list.> > > > > In short: The packets carried within an instance share a > > characteristic which > the > > OF optimizes for. > > The OF determines a RPL topology and thus how the flow that is tagged > > with > that > > instance is processed in the network. > > For flows to be processed differently one may different instances. > > > > Considering how open the definition of flow in 2460 is, this fits. > > > > The rank stretches that a bit since it qualifies where the flow is in > > the > Network. > > Then again RFC 2460 is open enough not to bar anything. > > > > Rather, the spirit is for us to do something useful with this field in > > the > forwarding > > plane and that is exactly what this proposal is doing . > > > > Cheers, > > > > Pascal > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: lundi 22 octobre 2012 21:15 > > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > > Subject: RE: [Roll] using the flow label instead of hop by hop > > > > Pascal, > > > > So the information that you are carrying in the IPv6 label field has > > nothing > to do > > with IPv6 labels? So, why is this not an egregious hack? > > > > Yours irrespectively, > > > > John > > > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of Pascal Thubert (pthubert) > > > Sent: Saturday, October 20, 2012 2:30 PM > > > To: adrian@olddog.co.uk; roll@ietf.org > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > Adrian, > > > > > > This draft is not mpls. This draft is about carrying the RPL info > > > (rank, instance, flags) in the flow label as opposed to the HbH > > > which incurs additional header + eventually tunneling. > > > My other draft on fragment forwarding has a lot more to do with > > > label switching since the first fragment lays a label that the other > > > fragments follow. But then we are not using the flow label but a > > > 6LoWPAN datagram identifier tag. > > > > > > Cheers, > > > > > > Pascal > > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > > Of Adrian Farrel > > > Sent: samedi 20 octobre 2012 21:37 > > > To: roll@ietf.org > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > Speaking as an individual and without an implementation... > > > > > > Isn't this MPLS? > > > Hasn't the routing area looked at the idea of using the IPv6 flow > > > label for labelled forwarding more than once in the past? > > > Hasn't the conclusion always been that you could do it, but you > > > would have to be sure that you were not overloading the field? > > > And hasn't the resulting discussion led to a debate on the value of > > > label stacks and the impracticality of label stacks using the flow > > > label? > > > > > > Cheers, > > > Adrian > > > > > > > -----Original Message----- > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > > > Behalf Of Philip Levis > > > > Sent: 20 October 2012 14:50 > > > > To: Pascal Thubert (pthubert) > > > > Cc: roll@ietf.org > > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > > > > > Phil; > > > > > > > > > > There is indeed lot of pressure for this in terms of header > > > > > sizes and energy > > > > consumption in the *real world*. > > > > > > > > I'm personally concerned about header sizes and energy consumption > > > > in The Matrix. Because I don't live in the real world. Oh, wait, > > > > sorry, > > > I > > > > do. Can you > > > walk > > > > me through the quantitative reasoning that a few bytes of header > > > > will increase energy consumption? It the belief that it will lead > > > > to sub-packet > > > fragmentation in > > > > some non-amortized sense? Generally speaking, in low power > > > > wireless networks, energy consumption is dominated by idle > > > > listening and communication latency/interval support, not the length of > packets. > > > > Of course there is a > > > spectrum > > > > of low power approaches and their point on that spectrum. Are you > > > > thinking of one in particular? > > > > > > > > Could implementers who are encountering this pressure comment? I'm > > > > a sucker for and easily swayed by quantitative data as well as > > > > first-hand rather than second-hand reports. > > > > > > > > > And there is no hack in the proposed solution. > > > > > Simply we believe more in practical engineering and ML > > > > > discussions than we > > > > trust in crystal balls. > > > > > > > > *coughs politely* I believe in very practical engineering that > > > > considers long > > > term > > > > consequences. Solving a problem a certain way now might cause > > > > significant problems in the future. I agree this is a tradeoff -- > > > > in my personal opinion, > > > nothing > > > > more, the tradeoff on this one is 100% clear. > > > > > > > > Phil > > > > > > > > ------ > > > > > > > > Philip Levis > > > > President, Kumu Networks > > > > Associate Professor, Stanford University > > > > http://csl.stanford.edu/~pal > > > > _______________________________________________ > > > > Roll mailing list > > > > Roll@ietf.org > > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll From guo@merl.com Thu Oct 25 07:01: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 6996321F89B9 for ; Thu, 25 Oct 2012 07:01: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.001, 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 4qK1TZ-1CvL3 for ; Thu, 25 Oct 2012 07:01:46 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFC121F896B for ; Thu, 25 Oct 2012 07:01:46 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9PE1jdc015067; Thu, 25 Oct 2012 10:01:45 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9PE1arV030070; Thu, 25 Oct 2012 10:01:41 -0400 Message-ID: <50894640.1080804@merl.com> Date: Thu, 25 Oct 2012 10:01:36 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Michael Richardson References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> In-Reply-To: <23378.1351166893@sandelman.ca> Content-Type: multipart/alternative; boundary="------------070108020005070302010308" Cc: roll@ietf.org, Philip Orlik , Kieran Parsons Subject: Re: [Roll] Loop free local DODAG repair solution 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, 25 Oct 2012 14:01:47 -0000 This is a multi-part message in MIME format. --------------070108020005070302010308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed". For your second question, further investigation and experiments are needed. Jianlin On 10/25/2012 8:08 AM, Michael Richardson wrote: > Jianlin Guo wrote: > JG> Dear ROLL WG members, > > JG> As we all know that loop is an open issue in RPL. Experiment shows that loop > JG> occurs quite often. We have proposed a loop free local DODAG > > Can you quantify "quite often"? > Do you have any metrics for how often loops occur, and what the cost is > of their repair? > > I think that the WG would be very very very interested in additional -experiences > draft, or pointers to papers explaining same, that gives a repeateable > experiment in which loops are observed. > --------------070108020005070302010308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed".

For your second question, further investigation and experiments are needed.

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment shows that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -experiences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

--------------070108020005070302010308-- From jdrake@juniper.net Thu Oct 25 07:16:33 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 5F52E21F8966 for ; Thu, 25 Oct 2012 07:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.578 X-Spam-Level: X-Spam-Status: No, score=-4.578 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 3r3dMbFkUPQR for ; Thu, 25 Oct 2012 07:16:32 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EE1AB21F894F for ; Thu, 25 Oct 2012 07:16:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUIlJv+7Mg/EakEeqB2UCFl+e5WpecDgQ@postini.com; Thu, 25 Oct 2012 07:16:32 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 25 Oct 2012 07:15:05 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 25 Oct 2012 07:15:04 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 25 Oct 2012 07:17:10 -0700 Received: from mail103-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 25 Oct 2012 14:15:03 +0000 Received: from mail103-co1 (localhost [127.0.0.1]) by mail103-co1-R.bigfish.com (Postfix) with ESMTP id 86EB9560080 for ; Thu, 25 Oct 2012 14:15:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I542M1432Idcamzz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail103-co1 (localhost.localdomain [127.0.0.1]) by mail103-co1 (MessageSwitch) id 1351174501706314_31214; Thu, 25 Oct 2012 14:15:01 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.227]) by mail103-co1.bigfish.com (Postfix) with ESMTP id 9FA20180050; Thu, 25 Oct 2012 14:15:01 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 25 Oct 2012 14:14:57 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.2.205]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0224.004; Thu, 25 Oct 2012 14:14:56 +0000 From: John E Drake To: "adrian@olddog.co.uk" , "'Pascal Thubert (pthubert)'" , "roll@ietf.org" Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2xEy0n78zttzpFSgOnw7I7S2GAIwA/D0QAABt+3YAADHpcAAAC5l8g Date: Thu, 25 Oct 2012 14:14:55 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E07DE696B@CH1PRD0510MB356.namprd05.prod.outlook.com> References: <12f101cdb20f$6b310280$41930780$@olddog.co.uk> <145401cdb2af$4ff91fc0$efeb5f40$@olddog.co.uk> In-Reply-To: <145401cdb2af$4ff91fc0$efeb5f40$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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: Thu, 25 Oct 2012 14:16:33 -0000 Adrian, It's pretty consistent with the re-definition of the IPv6 label as a flow l= abel in the RFC that Pascal mentioned previously. Yours irrespectively, John > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, October 25, 2012 5:50 AM > To: 'Pascal Thubert (pthubert)'; John E Drake; roll@ietf.org > Subject: RE: [Roll] using the flow label instead of hop by hop >=20 > Hi, >=20 > This and Michael's follow-up are helpful. >=20 > My take-away is that this is a place to put information that will be > used during the routing process, but that the forwarding decision will > not be made on this information in isolation. >=20 > That makes my "overlap with label switching" concern go away. >=20 > (Which is entirely different from considering whether this is a good > idea or not, on which I have no position :-) >=20 > Adrian >=20 > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: 25 October 2012 07:53 > > To: adrian@olddog.co.uk; 'John E Drake'; roll@ietf.org > > Subject: RE: [Roll] using the flow label instead of hop by hop > > > > I certainly agree with a good number of your words, Adrian. > > *We are indeed talking about a label that is applied to a packet. > > *It is a label that is related to the flow, and determined by the > instance ID. > > *It is information that will be used for the routing decision at each > > hop in > the LLN. > > > > Which means that the flow label in the routing header is the perfect > > place for > it. > > > > I am still unsure what the relation you make with label switching. > > The > distinction > > I'm making is as follows: > > *In this proposal there is no switching of tags, since the instance > is > conserved in > > the label. Only some metadata is mutable. > > *there is no switching packets either, RPL routing still takes place > > at every > hop > > which involves a route lookup. > > *and there is no switched path to follow with the label, but a > > topology -a > RIB- to > > be determined. > > > > IOW, the instance is more like a topology index for the RIB/FIB > lookup > > that > still > > needs to take place. > > > > Cheers, > > > > Pascal > > > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: mercredi 24 octobre 2012 19:46 > > To: Pascal Thubert (pthubert); 'John E Drake'; roll@ietf.org > > Subject: RE: [Roll] using the flow label instead of hop by hop > > > > Hi Pascal, > > > > Speaking as an individual and without an implementation... > > > > I guess I need to look at this in more detail (it always helps to > read > > the > > draft) this still sounds exactly like label switching. > > That is some value of a label is applied to a packet and that label > > will > identify the > > flow and direct the forwarding decision made at the next router. > > Furthermore, the label may be modified hop by hop. > > > > The "overloading" of information into the label doesn't get away from > > the fact that it is a label applied to a packet. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > > Sent: 23 October 2012 12:41 > > > To: John E Drake; adrian@olddog.co.uk; roll@ietf.org > > > Subject: RE: [Roll] using the flow label instead of hop by hop > > > > > > Hi: > > > > > > > > copy the list.> > > > > > > In short: The packets carried within an instance share a > > > characteristic which > > the > > > OF optimizes for. > > > The OF determines a RPL topology and thus how the flow that is > > > tagged with > > that > > > instance is processed in the network. > > > For flows to be processed differently one may different instances. > > > > > > Considering how open the definition of flow in 2460 is, this fits. > > > > > > The rank stretches that a bit since it qualifies where the flow is > > > in the > > Network. > > > Then again RFC 2460 is open enough not to bar anything. > > > > > > Rather, the spirit is for us to do something useful with this field > > > in the > > forwarding > > > plane and that is exactly what this proposal is doing . > > > > > > Cheers, > > > > > > Pascal > > > > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: lundi 22 octobre 2012 21:15 > > > To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org > > > Subject: RE: [Roll] using the flow label instead of hop by hop > > > > > > Pascal, > > > > > > So the information that you are carrying in the IPv6 label field > has > > > nothing > > to do > > > with IPv6 labels? So, why is this not an egregious hack? > > > > > > Yours irrespectively, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > > > Behalf Of Pascal Thubert (pthubert) > > > > Sent: Saturday, October 20, 2012 2:30 PM > > > > To: adrian@olddog.co.uk; roll@ietf.org > > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > > > Adrian, > > > > > > > > This draft is not mpls. This draft is about carrying the RPL info > > > > (rank, instance, flags) in the flow label as opposed to the HbH > > > > which incurs additional header + eventually tunneling. > > > > My other draft on fragment forwarding has a lot more to do with > > > > label switching since the first fragment lays a label that the > > > > other fragments follow. But then we are not using the flow label > > > > but a 6LoWPAN datagram identifier tag. > > > > > > > > Cheers, > > > > > > > > Pascal > > > > > > > > -----Original Message----- > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > > > Behalf Of Adrian Farrel > > > > Sent: samedi 20 octobre 2012 21:37 > > > > To: roll@ietf.org > > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > > > Speaking as an individual and without an implementation... > > > > > > > > Isn't this MPLS? > > > > Hasn't the routing area looked at the idea of using the IPv6 flow > > > > label for labelled forwarding more than once in the past? > > > > Hasn't the conclusion always been that you could do it, but you > > > > would have to be sure that you were not overloading the field? > > > > And hasn't the resulting discussion led to a debate on the value > > > > of label stacks and the impracticality of label stacks using the > > > > flow label? > > > > > > > > Cheers, > > > > Adrian > > > > > > > > > -----Original Message----- > > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > > > > Behalf Of Philip Levis > > > > > Sent: 20 October 2012 14:50 > > > > > To: Pascal Thubert (pthubert) > > > > > Cc: roll@ietf.org > > > > > Subject: Re: [Roll] using the flow label instead of hop by hop > > > > > > > > > > On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote: > > > > > > > > > > > Phil; > > > > > > > > > > > > There is indeed lot of pressure for this in terms of header > > > > > > sizes and energy > > > > > consumption in the *real world*. > > > > > > > > > > I'm personally concerned about header sizes and energy > > > > > consumption in The Matrix. Because I don't live in the real > > > > > world. Oh, wait, sorry, > > > > I > > > > > do. Can you > > > > walk > > > > > me through the quantitative reasoning that a few bytes of > header > > > > > will increase energy consumption? It the belief that it will > > > > > lead to sub-packet > > > > fragmentation in > > > > > some non-amortized sense? Generally speaking, in low power > > > > > wireless networks, energy consumption is dominated by idle > > > > > listening and communication latency/interval support, not the > > > > > length of > > packets. > > > > > Of course there is a > > > > spectrum > > > > > of low power approaches and their point on that spectrum. Are > > > > > you thinking of one in particular? > > > > > > > > > > Could implementers who are encountering this pressure comment? > > > > > I'm a sucker for and easily swayed by quantitative data as well > > > > > as first-hand rather than second-hand reports. > > > > > > > > > > > And there is no hack in the proposed solution. > > > > > > Simply we believe more in practical engineering and ML > > > > > > discussions than we > > > > > trust in crystal balls. > > > > > > > > > > *coughs politely* I believe in very practical engineering that > > > > > considers long > > > > term > > > > > consequences. Solving a problem a certain way now might cause > > > > > significant problems in the future. I agree this is a tradeoff > > > > > -- in my personal opinion, > > > > nothing > > > > > more, the tradeoff on this one is 100% clear. > > > > > > > > > > Phil > > > > > > > > > > ------ > > > > > > > > > > Philip Levis > > > > > President, Kumu Networks > > > > > Associate Professor, Stanford University > > > > > http://csl.stanford.edu/~pal > > > > > _______________________________________________ > > > > > Roll mailing 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 >=20 From c.chauvenet@watteco.com Thu Oct 25 09:07: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 2189721F8901 for ; Thu, 25 Oct 2012 09:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[AWL=1.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PhPBdiMOiIfb for ; Thu, 25 Oct 2012 09:07:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id AF48721F8920 for ; Thu, 25 Oct 2012 09:07:06 -0700 (PDT) Received: from mail249-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 25 Oct 2012 16:07:05 +0000 Received: from mail249-tx2 (localhost [127.0.0.1]) by mail249-tx2-R.bigfish.com (Postfix) with ESMTP id EF8D61480108; Thu, 25 Oct 2012 16:07:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bhc85dh1418Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail249-tx2 (localhost.localdomain [127.0.0.1]) by mail249-tx2 (MessageSwitch) id 1351181221567536_20539; Thu, 25 Oct 2012 16:07:01 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.244]) by mail249-tx2.bigfish.com (Postfix) with ESMTP id 60E479400DC; Thu, 25 Oct 2012 16:07:00 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 25 Oct 2012 16:06:58 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0224.004; Thu, 25 Oct 2012 16:06:56 +0000 From: C Chauvenet To: Jianlin Guo Thread-Topic: [Roll] Loop free local DODAG repair solution Thread-Index: AQHNsShZPcx+lZkhlUaljQOJ54dOTZfJ8H+AgAAfrgCAACMDgA== Date: Thu, 25 Oct 2012 16:06:56 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> In-Reply-To: <50894640.1080804@merl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D21564932DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" , Philip Orlik , Kieran Parsons Subject: Re: [Roll] Loop free local DODAG repair solution 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, 25 Oct 2012 16:07:09 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D21564932DBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit : Hi Michael, For your first question, draft-clausen-lln-rpl-experiences-04 pointed out t= hat "it can be observed that with current implementations of RPL, such as t= he ContikiRPL implementation, loops do occur - and, frequently. During the = same experiments described in Section 13, a snapshot of the DODAG was made = every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was o= bserved". Is it something that you observed in your own deployments ? More specifically : did you find similar results ? Best, C=E9dric. For your second question, further investigation and experiments are needed. Jianlin On 10/25/2012 8:08 AM, Michael Richardson wrote: Jianlin Guo wrote: JG> Dear ROLL WG members, JG> As we all know that loop is an open issue in RPL. Experiment shows = that loop JG> occurs quite often. We have proposed a loop free local DODAG Can you quantify "quite often"? Do you have any metrics for how often loops occur, and what the cost is of their repair? I think that the WG would be very very very interested in additional -exper= iences draft, or pointers to papers explaining same, that gives a repeateable experiment in which loops are observed. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_97B69B30E0EF244B940B65EA541E3F2D21564932DBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <330690054F5E954093DC328316AB8CA3@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi, 

Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit :

Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out t= hat "it can be observed that with current implementations of RPL, such= as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13,= a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed&quo= t;.

Is it something that you observed in your own deployments ?
More specifically : did you find similar results ? 

Best,

C=E9dric.


For your second question, further investigation and experiments are needed.=

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment sho=
ws that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -exper=
iences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

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

--_000_97B69B30E0EF244B940B65EA541E3F2D21564932DBXPRD0510MB395_-- From pal@cs.stanford.edu Thu Oct 25 11:00: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 2CBF821F8992 for ; Thu, 25 Oct 2012 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX14nH2Yq350 for ; Thu, 25 Oct 2012 11:00:21 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 72C5F21F8940 for ; Thu, 25 Oct 2012 11:00:20 -0700 (PDT) Received: from dn52219v.sunet ([10.33.5.63]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TRRj9-0000rH-86; Thu, 25 Oct 2012 11:00:19 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <50881297.4050801@gmail.com> Date: Thu, 25 Oct 2012 11:00:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <399491E5-8BC7-4A33-9426-B9047FC051FF@cs.stanford.edu> References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> <50881297.4050801@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll 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: Thu, 25 Oct 2012 18:00:22 -0000 On Oct 24, 2012, at 9:08 AM, Brian E Carpenter wrote: > On 24/10/2012 15:40, Ralph Droms wrote: >> Seems to me this conversation ought to include 6man fairly soon. >=20 > If ROLL wants to go this way, I agree. I *think* the proposal does > no violence to the 6man RFCs, but that's only my opinion. >=20 > Brian Brian, My thought process is simple. =46rom my reading, the proposal violates = RFC6437: "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." Its seems to me that using the flow label as more efficient = representation of a hop-by-hop option isn't a "compelling operational = security reason." It's an optimization. There hasn't yet been any = evidence or data presented on the potential efficiency benefits this = will have (hand-waving "energy" is not evidence). Adding *more* = complexity to RPL though an alternative representation of the hop-by-hop = header seems to me to add complexity without much benefit. If there were = evidence indicating that in a large number of operational scenarios this = optimization would lead to a significant savings, then that might be = compelling. But my experience is that the overall benefit of this = compression is going to be minimal. Using the flow label in a way which = someone reading RFC6437 would not guess or assume is problematic from an = interoperability standpoint. So, significant possible cost in terms of = interoperability, significant cost in terms of increased complexity, = minimal gain in terms of performance. If 6man obsoletes RFC6437 such that this proposed use doesn't violate a = MUST, then I'd be all ears. RFC6437 does say that you MAY modify a flow = label of zero (so routers may fill it in for end hosts that not do so), = says that the end host SHOULD set it to a non-zero value, and that nodes = MUST keep non-zero labels unchanged. I don't want to repeat the headache = that NATs introduced by violating end-to-end in an unanticipated way. Phil ------ Philip Levis President, Kumu Networks Associate Professor, Stanford University http://csl.stanford.edu/~pal From brian.e.carpenter@gmail.com Thu Oct 25 11:17: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 A0D0721F8722 for ; Thu, 25 Oct 2012 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.696 X-Spam-Level: X-Spam-Status: No, score=-101.696 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 FlAPxq4qLLzq for ; Thu, 25 Oct 2012 11:17:09 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8F3821F8508 for ; Thu, 25 Oct 2012 11:17:08 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so707773eaa.31 for ; Thu, 25 Oct 2012 11:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qGRe5jWtdjwqxjgopHh9nIUo7y0wrWgWk3WdAGJuWNU=; b=Ad1vSMXRDQy1tgiAx0zS2d8lniR96TwmAjMY/hbKWApXRCi5uWVcHTYRpKCsoAo42w ta8pLXU1Dhtxuu+blH/raVfQQPlTMSTGfs7M8JLchVNbzALl1uZteaHC6BX6zOtU3b1s kfpotpO9edGLIWI1KqJoIBYwrl184GS6/PdGLOmkj/b+fTmNABuhQ3yaLVdO0RwB/ZVs yw/Rw0WGZOLtz2v/aQj4fxN6N26QlTfaDq0u0kzlIyAs/3hNaErthmnia6fr5Jpjj5VY ibGRUs2gnMWWUzpAFajeRt2NT3SI9GHuRWAogRqf0ePoukxoYfULSo0SYVdrNaOjvg9n 6Hcg== Received: by 10.14.203.65 with SMTP id e41mr28092384eeo.34.1351189027752; Thu, 25 Oct 2012 11:17:07 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-61.as13285.net. [2.102.218.61]) by mx.google.com with ESMTPS id s1sm31748459eem.9.2012.10.25.11.17.05 (version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 11:17:06 -0700 (PDT) Message-ID: <50898229.1030105@gmail.com> Date: Thu, 25 Oct 2012 19:17:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> <50881297.4050801@gmail.com> <399491E5-8BC7-4A33-9426-B9047FC051FF@cs.stanford.edu> In-Reply-To: <399491E5-8BC7-4A33-9426-B9047FC051FF@cs.stanford.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: roll 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: Thu, 25 Oct 2012 18:17:09 -0000 On 25/10/2012 19:00, Philip Levis wrote: > On Oct 24, 2012, at 9:08 AM, Brian E Carpenter wrote: > >> On 24/10/2012 15:40, Ralph Droms wrote: >>> Seems to me this conversation ought to include 6man fairly soon. >> If ROLL wants to go this way, I agree. I *think* the proposal does >> no violence to the 6man RFCs, but that's only my opinion. >> >> Brian > > Brian, > > My thought process is simple. From my reading, the proposal violates RFC6437: > > "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." I have to say it's a while since I read the draft all through, but I seemed to remember that the packet would always be encapsulated in an outer packet, in which case there is no problem if the outer packet's flow label is set locally and vanishes at the ROLL boundary. If not, then yes, there's a violation. > Its seems to me that using the flow label as more efficient representation of a hop-by-hop option isn't a "compelling operational security reason." It's an optimization. There hasn't yet been any evidence or data presented on the potential efficiency benefits this will have (hand-waving "energy" is not evidence). Adding *more* complexity to RPL though an alternative representation of the hop-by-hop header seems to me to add complexity without much benefit. If there were evidence indicating that in a large number of operational scenarios this optimization would lead to a significant savings, then that might be compelling. But my experience is that the overall benefit of this compression is going to be minimal. Using the flow label in a way which someone reading RFC6437 would not guess or assume is problematic from an interoperability standpoint. So, significant possible cost in terms of interoperability, significant cost in terms of increased complexity, minimal gain in ter ms of performance. > > If 6man obsoletes RFC6437 such that this proposed use doesn't violate a MUST, then I'd be all ears. RFC6437 does say that you MAY modify a flow label of zero (so routers may fill it in for end hosts that not do so), says that the end host SHOULD set it to a non-zero value, and that nodes MUST keep non-zero labels unchanged. I don't want to repeat the headache that NATs introduced by violating end-to-end in an unanticipated way. I think it would be entirely possible (I am not particularly advocating this) for RFC-roll to formally update RFC 6437 for this particular usage. Speaking purely personally, I wouldn't oppose this, although others might object. The reason I wouldn't oppose it is that the idea is that on the open Internet, any forwarding device should be able to use the flow label for ECMP, LAG or some other kind of load balancing. If the label is set according to RFC 6437 at a well-defined point (such as the ROLL/Internet boundary), this would be satisfied. Yes, I am being a bit heretical about my own RFC ;-). Brian > Phil > > ------ > > Philip Levis > President, Kumu Networks > Associate Professor, Stanford University > http://csl.stanford.edu/~pal > > > From jramasas@silverspringnet.com Thu Oct 25 11:19:14 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 AEED421F85AC for ; Thu, 25 Oct 2012 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 poGOPxhDE7BV for ; Thu, 25 Oct 2012 11:19:14 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3336C21F8589 for ; Thu, 25 Oct 2012 11:19:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAJWBiVAKOQxl/2dsb2JhbABEgkqDBb1pgiAFLV4BDB5WHwcBBBMIxl+Le4VyYQOpIoFkNQ X-IronPort-AV: E=Sophos;i="4.80,649,1344236400"; d="scan'208,217";a="15366434" Received: from sfo-exca-02.silverspringnet.com ([10.57.12.101]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 25 Oct 2012 11:19:13 -0700 Received: from SFO-EXMB-01.silverspringnet.com ([fe80::fdb4:fa8c:9a07:be02]) by SFO-EXCA-02.silverspringnet.com ([::1]) with mapi id 14.01.0355.002; Thu, 25 Oct 2012 11:19:14 -0700 From: Jay Ramasastry To: "Roll@ietf.org" Thread-Topic: remove my name Thread-Index: Ac2y3SXHSd7g849wSqOXWxW0zcU5JQ== Date: Thu, 25 Oct 2012 18:19:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.12.115] Content-Type: multipart/alternative; boundary="_000_DA965D9450BE4147AD4D9708973823A676772B79SFOEXMB01silver_" MIME-Version: 1.0 Subject: [Roll] remove my name 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, 25 Oct 2012 18:19:14 -0000 --_000_DA965D9450BE4147AD4D9708973823A676772B79SFOEXMB01silver_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lease remove my name from the e-mail list. Thanks Jay Ramasastry jramasas@silverspringnet.com --_000_DA965D9450BE4147AD4D9708973823A676772B79SFOEXMB01silver_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lease remove my name from the e-mail list.

Thanks

 

Jay Ramasastry

jramasas@silverspringnet.com

--_000_DA965D9450BE4147AD4D9708973823A676772B79SFOEXMB01silver_-- From mcr@sandelman.ca Thu Oct 25 14:43: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 9DA2521F868C for ; Thu, 25 Oct 2012 14:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 SllfyqnK5vu9 for ; Thu, 25 Oct 2012 14:43:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD2321F860F for ; Thu, 25 Oct 2012 14:43:57 -0700 (PDT) Received: from sandelman.ca (74-115-197-230.eng.wind.ca [74.115.197.230]) by relay.sandelman.ca (Postfix) with ESMTPS id E506081AC; Thu, 25 Oct 2012 17:36:17 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 44722CA0CE; Thu, 25 Oct 2012 11:04:55 -0400 (EDT) From: Michael Richardson To: Philip Levis In-reply-to: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> References: <0FBCBE37-CD1D-402B-ABE8-800EF6A6E3C7@cs.stanford.edu> Comments: In-reply-to Philip Levis message dated "Tue, 23 Oct 2012 08:41:35 -0700." 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, 25 Oct 2012 11:04:55 -0400 Message-ID: <1232.1351177495@sandelman.ca> Sender: mcr@sandelman.ca 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: Thu, 25 Oct 2012 21:43:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Philip Levis wrote: PL> What if an end-host outside the RPL instance wants to use a flow PL> label for its own purposes? It might think that a flow denotes a PL> stream of associated packets to a node within a RPL instance, not PL> the OF that instance happens to use.=20=20 I presume that this end-host is interacting with the LLN in some way (or the question is irrelevant) When the packets arrive at the gateway, a 6in6 header is added. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiVUWAAoJEKD0KQ7Gj3P2FV0H/0HgiNayTr6QtTwJ5yozLZBJ Y/qxJ3d3lWrfEcYYylavThYTctOdSYSv6iQ12Tk3qHsaRnWJ4Y7e+Zsdcpgwdozw A22f0eBS0VRkO3B8grqABM27HFIU7OrQ8YalfEbjDBDOnGPjkqSIEVzRQMpt5Zv3 W9rEk25hdiVBk0C1JnykPJsCaykyHyTaBIzuJfXGAXkfiqNoKunWGKp84teJCJGu o4ZvhSVCxuWudCm3npCa22CXHzznQdkrFejDlhf4lNVVrLqLGw6wTL2eoT4M4nHT 1Gt90LYvy460BlmiyVTbOTTd3VdfKfASJth5sT35D7u6JYguNQLAPx1rU3V81js= =pWyz -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Oct 25 14:43: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 BB0AD21F860F for ; Thu, 25 Oct 2012 14:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, MISSING_SUBJECT=1.762] 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 Mp0qt5yL3FTG for ; Thu, 25 Oct 2012 14:43:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE5F21F867C for ; Thu, 25 Oct 2012 14:43:57 -0700 (PDT) Received: from sandelman.ca (74-115-197-230.eng.wind.ca [74.115.197.230]) by relay.sandelman.ca (Postfix) with ESMTPS id 2680681B7 for ; Thu, 25 Oct 2012 17:36:18 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D92D8CA0BC for ; Thu, 25 Oct 2012 09:16:48 -0400 (EDT) From: Michael Richardson To: "roll@ietf.org" Date: Thu, 25 Oct 2012 09:16:48 -0400 Message-ID: <26644.1351171008@sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] (no subject) 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, 25 Oct 2012 21:43:58 -0000 cc: Brian E Carpenter , "Pascal Thubert (pthubert)" , Fcc: +outgoing Subject: Re: [Roll] using the flow label instead of hop by hop In-reply-to: <5087F457.1050409@gmail.com> References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Wed, 24 Oct 2012 14:59:51 +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" -------- --=-=-= Content-Transfer-Encoding: quoted-printable First, I think that the intro, section 1, para 2 is very much misleading people into thinking that this is somehow about what the flow label is for packets leaving the LLN and crossing the Internet.=20=20 It's a consideration, but only for one case, which is not necessarily a com= mon one. There are three cases to consider. 1) packets within the LLN. 2) packets entering the LLN. 3) packets exiting the LLN. We care mostly about #1.=20=20 It's where optimizations save the most bits (=3D=3Denergy), and in which it matters whether we use the right DODAG or not. In particular, for the cases where a P2P DODAG has been constructed (with storing nodes, therefore no source routes), the packet never goes to the DODAG root. My gut is that case #1 is at least 90% of the packets, in some cases, 99.9%. Note that where two low power layer-2s are connected via a wired network (or higher power wireless network), RPL messages connect the two islands into a single DODAG, and so the packet isn't technically leaving the LLN.=20=20 For case #2, a) the gateway can't trust the flowid to be sensible anyway, and b) the gateway needs to do some larger analysis to determine what DODAG to use. As such, it's hard to do anything other than add a 6in6 header in order to preserve the inner flow label, which is what would be done in the absense of this proposal. Having done so, the opportunity to set the outer flow label presents itself, or to add the hop-by-hop header.=20=20=20 For case #3, packets leaving the LLN, the encoded flow label seen on the outgoing packet is meaningless to the Internet. If left as is, however, it does rather uniquely group flows. If the sending node needed a specific flow label expressed in an end to end fashion, and this proposal was active, then a 6in6 header would be appropriate as before. I think the question is, what is 6man going to say about host stacks (TCP for instance) setting the flow label on packets? Is there going to be any suggestion that a TCP SYN-ACK should use the same flow label as was seen on the SYN? =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiTu/AAoJEKD0KQ7Gj3P2MrsH/2yZ4XS84vXVeAI2zDbeKgDW z1G9wQT9fJT9pfiJrslsgsVgd4RUxRQSxAQc99ArDMOl4Qr71cNa7dVjFBfuYXEA 00HamIYfRgzGVcbRPlNG9ORSNNNO+J9CrOdYIWyFV22WGrHG2d3YyijWBicWwkFB I8z3BF3gzdCNXA9aqG45JHu0/0ZsB82bmaCFq9svhaD8JHAW1f84oa5NAeOyhvjt oJmGsklJyXxGjhwzdyqnE2IEP+LrU3cqeJQco4XNW8NWXb6VpitgIWcWTP0LbtDf 1rOwxyK5NbdBlt3hYcUTJFNMkcC2hQcTlakBBZ+hl1sYIt1F/945RbrFcEn5hRw= =LkMl -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Oct 25 14:44: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 659F021F88CF; Thu, 25 Oct 2012 14:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=0.975, 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 YP69kDHPtESV; Thu, 25 Oct 2012 14:44:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7621F88CE; Thu, 25 Oct 2012 14:44:06 -0700 (PDT) Received: from sandelman.ca (74-115-197-230.eng.wind.ca [74.115.197.230]) by relay.sandelman.ca (Postfix) with ESMTPS id 5247681A9; Thu, 25 Oct 2012 17:36:27 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 08549CA0CD; Thu, 25 Oct 2012 11:01:11 -0400 (EDT) From: Michael Richardson To: sarikaya@ieee.org In-reply-to: References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> Comments: In-reply-to Behcet Sarikaya message dated "Tue, 23 Oct 2012 15:23:23 -0500." 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, 25 Oct 2012 11:01:10 -0400 Message-ID: <1116.1351177270@sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, "Keoh, Sye Loong" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-kemp-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, 25 Oct 2012 21:44:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Behcet Sarikaya wrote: BS> There is some overlap with this draft and our work on Secure BS> Bootstrapping that was being pursued until recently in Core WG. BS> It is still not clear to me which WG should be home for this activi= ty, BS> can you please clarify? I thought that this was the point of SOLACE. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiVQ2AAoJEKD0KQ7Gj3P2pn8H/0NqHQYbX+0hA80YL1AOdtLE YOmWSjqhtAhy0j7aAIuLfsxSkpuspQZA6DgW4Wk0IKiXrc8wBVShd1xbf+yWmUTz xSQw7aVEgKBj951aXQ7fNjm+2XJKjq6SevEVqGGOHPjOFVvsYUHqNrK/HZziBRMy zv2ifx8opO7ItOoMZIMc7mHjHGLGLKyWDLPRJ1ZKjw9vlY5cflnpBRrcsuDy0uJo aVdTMwZDAPHCU+0rxxn+Or7XeFNcw6IrQug0tzSEZ6aQXLy0LU6Ct6zmt0IcJJzp p8wgwDYGP2BHqNjte6EdAVCOXTPbMYKBH6uSnREJuEyKLJ9S0w9FlsNGFwTwUR8= =n7GN -----END PGP SIGNATURE----- --=-=-=-- From pal@cs.stanford.edu Thu Oct 25 15:54: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 4AA2B21F84ED for ; Thu, 25 Oct 2012 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Yi7Ku1BCnTHJ for ; Thu, 25 Oct 2012 15:54:27 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 608F721F84A0 for ; Thu, 25 Oct 2012 15:54:27 -0700 (PDT) Received: from dn52219v.sunet ([10.33.5.63]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TRWJk-0003yx-KQ; Thu, 25 Oct 2012 15:54:25 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <50898229.1030105@gmail.com> Date: Thu, 25 Oct 2012 15:54:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09E96C25-8B21-446F-95F6-C36F339C6E54@cs.stanford.edu> References: <5081A327.9010505@exegin.com> <5087F457.1050409@gmail.com> <50881297.4050801@gmail.com> <399491E5-8BC7-4A33-9426-B9047FC051FF@cs.stanford.edu> <50898229.1030105@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e Cc: roll 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: Thu, 25 Oct 2012 22:54:30 -0000 On Oct 25, 2012, at 11:17 AM, Brian E Carpenter wrote: > The reason I wouldn't oppose it is that the idea is that on the open > Internet, any forwarding device should be able to use the flow label > for ECMP, LAG or some other kind of load balancing. If the label is > set according to RFC 6437 at a well-defined point (such as the = ROLL/Internet > boundary), this would be satisfied. Yes, I am being a bit heretical > about my own RFC ;-). Again, my concern is being in accordance with RFC6437. If 6man obsoletes = it for a more flexible use of the flow label, then I have zero = objections to the proposal (and even think it is good). Phil From thomas@thomasclausen.org Thu Oct 25 23:24: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 1A56921F8427 for ; Thu, 25 Oct 2012 23:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Opw3SbhHf0ov for ; Thu, 25 Oct 2012 23:24:24 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B11BF21F8421 for ; Thu, 25 Oct 2012 23:24:24 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id EC0BBA67D5 for ; Thu, 25 Oct 2012 23:24:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 42B5B1C083C; Thu, 25 Oct 2012 23:24:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (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 E19D31C051B; Thu, 25 Oct 2012 23:24:21 -0700 (PDT) References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <916169D2-0DD7-4077-A919-5EC9762A8816@thomasclausen.org> X-Mailer: iPad Mail (10A403) From: Thomas Heide Clausen Date: Fri, 26 Oct 2012 08:24:21 +0200 To: "JP Vasseur (jvasseur)" Cc: "roll@ietf.org WG" , Michael Richardson 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: Fri, 26 Oct 2012 06:24:25 -0000 Dear JP, Michael, All, I have only just flipped through this latest version of this I-D; a more det= ailed review will follow. However, I already have one major comment..... I wonder why a WGLC is issued for a protocol specification, wherein the "Sec= urity Considerations" section is entirely empty? (Well, fair be fair, it doe= s explicitly say "TODO"...) Knowing the IESG and the SEC ADs, they tend to (rightfully) not be lenient o= n such matters, and I think that it behoves the WG to be very attentive to s= ecurity also. In my opinion, it is not prudent for the WG to consider a protocol specifica= tion as "mature enough to take forward" until such time that also the securi= ty implications and considerations are carefully addressed. As it is, they are not - and, for that reason alone I'd like to go on record= with strong opposition to progressing this document. Note, I have not reviewed the document in detail - that will come. However l= ack of _any_ security considerations whatsoever is, alone, a showstopper.=20= Best, Thomas ps: FWIW, the 2119-boilerplate used doesn't capture the errata. Sent from my iPad On 25 oct. 2012, at 08:55, "JP Vasseur (jvasseur)" wrot= e: > Dear all, >=20 > draft-ietf-roll-trickle-mcast-02 has been discussed on the mailing list a= nd 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 From pthubert@cisco.com Fri Oct 26 05:19:40 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 4429621F84C0 for ; Fri, 26 Oct 2012 05:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYO4vm760V2l for ; Fri, 26 Oct 2012 05:19:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9209221F84AD for ; Fri, 26 Oct 2012 05:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1740; q=dns/txt; s=iport; t=1351253979; x=1352463579; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/+e991LwtBtj7Ttluzmu1ScSl74z4t2e9gB06lYnRRU=; b=eXCnbJtIjp1jkmNMe+zQO7UYOlp8OOpQD1BBkRaneW5H5MYxhb40lgTG BolEVk5hAt7e5a4n6Z9urmWhlIMdFTPZq0cy0zyGuPpINOVQrm4hdGlhj 0HWS7QXMR1PjLM4kgwgNqXBI9AfKHDno+Q2RM9hY8/1hejWn1b9oz/Bf0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKF/ilCtJV2c/2dsb2JhbABEDsIpgQiCHgEBAQQSASc/DAYBCBEEAQELFAk5FAkJAQQBDQUIGodinRagDYtohg1hA6RIgWuCMj2BWwYaHg X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135663286" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 26 Oct 2012 12:19:34 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9QCJYQo008117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 12:19:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.178]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 07:19:34 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , Philip Levis Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2zdAzMC8Y4/WcPS4SX3fcFVFCNpQ== Date: Fri, 26 Oct 2012 12:19:33 +0000 Deferred-Delivery: Fri, 26 Oct 2012 12:19:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--27.797800-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: Fri, 26 Oct 2012 12:19:40 -0000 Hi Michael At the time I wondered what sort of communication to the other side of the = core was being envisioned in this thread. If the end host wanted to use that flow label as a backchannel (or covert c= hannel or an IPv6 version of the D-channel or whatever) 20 bits of data at = a time, now, that would be a hack. In any fashion, the flow label cannot be used to transport valuable informa= tion because it cannot be verified on the receiving side. Still, with the p= roposal, the root gets to see it, so for what that is worth it may use it. The flow label is currently defined for the end host to interact with the c= ore. Once the core is traversed, the value of the flow label is consumed. T= hus it can be reset and reused. Resetting the flow label for incoming packets at the root is a safe thing t= o do, there is no envisioned need to preserve the original flow label, and = thus no envisioned need for IPinIP. Cheers, Pascal -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael Richa= rdson Sent: jeudi 25 octobre 2012 17:05 To: Philip Levis Cc: Pascal Thubert (pthubert); roll@ietf.org Subject: Re: [Roll] using the flow label instead of hop by hop Philip Levis wrote: PL> What if an end-host outside the RPL instance wants to use a flow PL> label for its own purposes? It might think that a flow denotes a PL> stream of associated packets to a node within a RPL instance, not PL> the OF that instance happens to use. =20 I presume that this end-host is interacting with the LLN in some way (or th= e question is irrelevant) When the packets arrive at the gateway, a 6in6 he= ader is added. From jsjeong@etri.re.kr Fri Oct 26 05:40: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 6F35521F855A for ; Fri, 26 Oct 2012 05:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.742 X-Spam-Level: X-Spam-Status: No, score=-92.742 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 TJKKmsdg5icA for ; Fri, 26 Oct 2012 05:39:59 -0700 (PDT) Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id 20A3621F84DC for ; Fri, 26 Oct 2012 05:39:58 -0700 (PDT) Received: from SMTPEG1.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id q9QCdglu032415; Fri, 26 Oct 2012 21:39:43 +0900 Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 26 Oct 2012 21:39:39 +0900 Received: from SMTP4.etri.info ([169.254.3.138]) by SMTP2.etri.info ([169.254.2.197]) with mapi id 14.01.0355.002; Fri, 26 Oct 2012 21:39:33 +0900 From: =?euc-kr?B?waTBvrz2?= To: "JP Vasseur (jvasseur)" Thread-Topic: [Roll] Draft Agenda Thread-Index: AQHNshI/1lX/Rsr9DkGoyi2Nck5zR5fIZcaAgAKNIIA= Date: Fri, 26 Oct 2012 12:39:32 +0000 Message-ID: References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.192.201] Content-Type: text/plain; charset="euc-kr" Content-ID: <1D568A40FA7914438C951CA2044D9210@etri.re.kr> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?euc-kr?B?sO3BpLHm?= , "roll@ietf.org WG" , Michael Richardson 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: Fri, 26 Oct 2012 12:40:00 -0000 SlAsDQoNCkpvaG4gaGFzIHJlcXVlc3RlZCBhIHNsb3QuIEJ1dCB3ZSd2ZSBub3QgYmVlbiByZXBs aWVkIGFueXRoaW5nLiBJcyB0aGUgYWdlbmRhIGFscmVhZHkgZml4ZWQ/DQoNClJlZ2FyZHMsDQot Sm9uZ3Nvbw0KDQoyMDEyLiAxMC4gMjUuLCC/wMD8IDY6NDEsIEplb25nR2lsIEtvIDxqZW9uZ2dp bC5rb0BldHJpLnJlLmtyPiDA27y6Og0KDQo+IA0KPiBKUCwNCj4gDQo+IEkndmUgYWxzbyBwdXQg aW4gYSByZXF1ZXN0IGZvciBhIHNsb3QgYXQgdGhlIG1lZXRpbmcgaW4gQXRsYW50YSBmb3IgcHJl c2VudGluZyAiZHJhZnQta28tcm9sbC1taXgtbmV0d29yay1wYXRob2xvZ3kiIGJ1dCBJIGRvIG5v dCBzZWUgdGhpcyBvbiB0aGUgYWdlbmRhLiBUaGlzIGRyYWZ0IGRpc2N1c3NlcyBhYm91dCBhIGNy aXRpY2FsIGFuZCBwcmFjdGljYWwgcGVyZm9ybWFuY2UgaXNzdWUgb2YgUlBMIG5ldHdvcmtzIChi b3RoIGNvbGxlY3Rpb24gYW5kIGRvd253YXJkcykgd2hlbiB0aGV5IGFyZSBpbnRlbnRpb25hbGx5 IG9yIGFjY2lkZW50YWxseSBkZXBsb3llZCB3aXRoIGRldmljZXMgb2YgZGlmZmVyZW50IE1PUHMu IEkgYmVsaWV2ZSB0aGF0IHN1Y2ggYW4gaXNzdWUgaXMgaW1wb3J0YW50IHRvIGRpc2N1c3MgYXMg YSBncm91cC4NCj4gDQo+IFRoYW5rcy4NCj4gDQo+IC1Kb2huDQo+IA0KPiAtLS0tLS0NCj4gSmVv bmdHaWwgS28sIFBoLkQuDQo+IFJlc2VhcmNoZXINCj4gRWxlY3Ryb25pY3MgYW5kIFRlbGVjb21t dW5pY2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGUgKEVUUkkpDQo+IGh0dHA6Ly9zaXRlcy5nb29n bGUuY29tL3NpdGUvamVvbmdnaWxrby8NCj4gDQo+IE9uIE9jdCAyNSwgMjAxMiwgYXQgMzowNiBB TSwgSlAgVmFzc2V1ciAoanZhc3NldXIpIHdyb3RlOg0KPiANCj4+IERlYXIgYWxsLA0KPj4gDQo+ PiBwbGVhc2UgZmluZCBiZWxsb3cgdGhlIGRyYWZ0IGFnZW5kYSBmb3IgUk9MTCdzIFdHIG1lZXRp bmcgaW4gQXRsYW50YSAtIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50Og0KPj4g DQo+PiAxKSBBZ2VuZGEvYWRtaW4gKENoYWlycyAtIDVtbikgWzVdDQo+PiANCj4+IDIpIFdHIFN0 YXR1cyAoQ2hhaXJzIC0gMTAgbW4pIFsxNV0NCj4+IA0KPj4gMykgU2VjdXJpdHkgRnJhbWV3b3Jr IGFuZCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCB0ZW1wbGF0ZQ0KPj4gKE1pY2hhZWwgLSAxMG0p IFsyNV0NCj4+IGRyYWZ0PWRyYWZ0LXJpY2hhcmRzb24tcm9sbC1hcHBsaWNhYmlsaXR5LXRlbXBs YXRlLTAwDQo+PiANCj4+IDQpIFJQTCBhcHBsaWNhYmlsaXR5IGluIGluZHVzdHJpYWwgbmV0d29y a3MNCj4+IGRyYWZ0LXBoaW5uZXktcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAx DQo+PiAoUGFzY2FsIC0gMTBtbikgWzM1XQ0KPj4gDQo+PiA1KSBJbmR1c3RyaWFsIERldGVybWlu aXN0aWMgUm91dGluZyBFeHRlbnNpb24gZm9yIExvdy1Qb3dlcg0KPj4gYW5kIExvc3N5IE5ldHdv cmtzIChNLiBXZWkgLSAxMG1uKSBbNDVdDQo+PiANCj4+IDYpIFJQTCBkZXBsb3ltZW50IGV4cGVy aWVuY2UgaW4gbGFyZ2Ugc2NhbGUgbmV0d29ya3MNCj4+IGRyYWZ0LWh1aS12YXNzZXVyLXJvbGwt cnBsLWRlcGxveW1lbnQgKFRCRCAtIDVtbikgWzUwXQ0KPj4gDQo+PiA3KSBSUEwgYXBwbGljYWJp bGl0eSBpbiBpbmR1c3RyaWFsIG5ldHdvcmtzDQo+PiBkcmFmdC1waGlubmV5LXJvbGwtcnBsLWlu ZHVzdHJpYWwtYXBwbGljYWJpbGl0eS0wMQ0KPj4gKFBhc2NhbCAtIDEwbW4pIFs2MF0NCj4+IA0K Pj4gOCkgTG9vcCBGcmVlIERPREFHIExvY2FsIFJlcGFpciAoSmlhbmxpbiBHdW8gLSAxMG1uKSBb NzBdDQo+PiBkcmFmdC1ndW8tcm9sbC1sb29wLWZyZWUtZG9kYWctcmVwYWlyDQo+PiANCj4+IFRo YW5rcy4NCj4+IA0KPj4gSlAgYW5kIE1pY2hhZWwuDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+IFJvbGxA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Um9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0K From cabo@tzi.org Fri Oct 26 05:56: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 1E23221F85D5 for ; Fri, 26 Oct 2012 05:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 7EGoOIhwtB5p for ; Fri, 26 Oct 2012 05:56:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5428121F85CF for ; Fri, 26 Oct 2012 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9QCuOas008934; Fri, 26 Oct 2012 14:56:24 +0200 (CEST) Received: from [192.168.217.117] (p548935F1.dip.t-dialin.net [84.137.53.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D593D673; Fri, 26 Oct 2012 14:56:23 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 26 Oct 2012 14:56:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1499) 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: Fri, 26 Oct 2012 12:56:47 -0000 On Oct 26, 2012, at 14:19, "Pascal Thubert (pthubert)" = wrote: > In any fashion, the flow label cannot be used to transport valuable = information because it cannot be verified on the receiving side.=20 I hear that a lot. Most of our current protocols are indeed designed to ignore v6 specific = IP header fields. But just to give a very accessible example: A v6 specific version of ESP = (RFC4303) could use the label to transmit the SPI. I'm not saying this because I want to rule out the use of the label for = forwarding fabric purposes; it's just that with more focus on IPv6, = hosts may find good uses for the label. But using the label from = RPL-cognizant nodes, e.g for router-sourced packets or for the outer = header of the RPL tunnel, should be fine (if there is a way to detect = that this has happened). Overwriting the label when a previously = formulated IPv6 packet enters the RPL instance is bad for the same = reasons adding the RFC 6553 RPL hop-by-hop option or the RFC 6554 = routing header in the middle of the path would be bad. Gr=FC=DFe, Carsten From guo@merl.com Fri Oct 26 06:28: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 7C01021F85EB for ; Fri, 26 Oct 2012 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srSR9kRth8lF for ; Fri, 26 Oct 2012 06:28:22 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAE821F85E8 for ; Fri, 26 Oct 2012 06:28:22 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9QDSKSR027444; Fri, 26 Oct 2012 09:28:21 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9QDRsrV001690; Fri, 26 Oct 2012 09:28:20 -0400 Message-ID: <508A8FDA.4040104@merl.com> Date: Fri, 26 Oct 2012 09:27:54 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: C Chauvenet References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------090903030107000104000500" Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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, 26 Oct 2012 13:28:23 -0000 This is a multi-part message in MIME format. --------------090903030107000104000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 10/25/2012 12:06 PM, C Chauvenet wrote: > Hi, > > Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit : > >> Hi Michael, >> >> For your first question, draft-clausen-lln-rpl-experiences-04 pointed >> out that "it can be observed that with current implementations of >> RPL, such as the ContikiRPL implementation, loops do occur - and, >> frequently. During the same experiments described in Section 13, a >> snapshot of the DODAG was made every ten seconds. In 74.14% of the >> 4114 snapshots, at least one loop was observed". > > Is it something that you observed in your own deployments ? > More specifically : did you find similar results ? We observed the occurrence of loops, unfortunately we did not measure the percentage. > Best, > > Cédric. > >> >> For your second question, further investigation and experiments are >> needed. >> >> Jianlin >> >> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>> Jianlin Guo wrote: >>> JG> Dear ROLL WG members, >>> >>> JG> As we all know that loop is an open issue in RPL. Experiment shows that loop >>> JG> occurs quite often. We have proposed a loop free local DODAG >>> >>> Can you quantify "quite often"? >>> Do you have any metrics for how often loops occur, and what the cost is >>> of their repair? >>> >>> I think that the WG would be very very very interested in additional -experiences >>> draft, or pointers to papers explaining same, that gives a repeateable >>> experiment in which loops are observed. >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --------------090903030107000104000500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/25/2012 12:06 PM, C Chauvenet wrote:
Hi, 

Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit :

Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed".

Is it something that you observed in your own deployments ?
More specifically : did you find similar results ?
We observed the occurrence of loops, unfortunately we did not measure the percentage.

Best,

Cédric.


For your second question, further investigation and experiments are needed.

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment shows that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -experiences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

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


--------------090903030107000104000500-- From c.chauvenet@watteco.com Fri Oct 26 08:22: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 0A60421F854E for ; Fri, 26 Oct 2012 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=1.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3t9uaCZQjINE for ; Fri, 26 Oct 2012 08:22:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id EC75021F862D for ; Fri, 26 Oct 2012 08:21:58 -0700 (PDT) Received: from mail238-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 26 Oct 2012 15:21:57 +0000 Received: from mail238-tx2 (localhost [127.0.0.1]) by mail238-tx2-R.bigfish.com (Postfix) with ESMTP id 6AF3F880278; Fri, 26 Oct 2012 15:21:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bhc85dh1418Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail238-tx2 (localhost.localdomain [127.0.0.1]) by mail238-tx2 (MessageSwitch) id 1351264915774876_18065; Fri, 26 Oct 2012 15:21:55 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.249]) by mail238-tx2.bigfish.com (Postfix) with ESMTP id B058AC20051; Fri, 26 Oct 2012 15:21:55 +0000 (UTC) Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 26 Oct 2012 15:21:44 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.67.167]) with mapi id 14.16.0224.004; Fri, 26 Oct 2012 15:21:34 +0000 From: C Chauvenet To: Jianlin Guo Thread-Topic: [Roll] Loop free local DODAG repair solution Thread-Index: AQHNsShZPcx+lZkhlUaljQOJ54dOTZfJ8H+AgAAfrgCAACMDgIABZecAgAAfwYA= Date: Fri, 26 Oct 2012 15:21:34 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> In-Reply-To: <508A8FDA.4040104@merl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.42.4] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D2156744DDBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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, 26 Oct 2012 15:22:03 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D2156744DDBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thank you for your answer. See inline. Le 26 oct. 2012 =E0 15:27, Jianlin Guo a =E9crit : On 10/25/2012 12:06 PM, C Chauvenet wrote: Hi, Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit : Hi Michael, For your first question, draft-clausen-lln-rpl-experiences-04 pointed out t= hat "it can be observed that with current implementations of RPL, such as t= he ContikiRPL implementation, loops do occur - and, frequently. During the = same experiments described in Section 13, a snapshot of the DODAG was made = every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was o= bserved". Is it something that you observed in your own deployments ? More specifically : did you find similar results ? We observed the occurrence of loops, unfortunately we did not measure the p= ercentage. So how did you evaluate the benefit of the mechanism that you proposed ? C=E9dric. Best, C=E9dric. For your second question, further investigation and experiments are needed. Jianlin On 10/25/2012 8:08 AM, Michael Richardson wrote: Jianlin Guo wrote: JG> Dear ROLL WG members, JG> As we all know that loop is an open issue in RPL. Experiment shows = that loop JG> occurs quite often. We have proposed a loop free local DODAG Can you quantify "quite often"? Do you have any metrics for how often loops occur, and what the cost is of their repair? I think that the WG would be very very very interested in additional -exper= iences draft, or pointers to papers explaining same, that gives a repeateable experiment in which loops are observed. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_97B69B30E0EF244B940B65EA541E3F2D2156744DDBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5CE3C8DDBEBC1846BC1752ED067390CC@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
Thank you for your answer.
See inline.

Le 26 oct. 2012 =E0 15:27, Jianlin Guo a =E9crit :

On 10/25/2012 12:06 PM, C Chauvenet wrote:
Hi, 

Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit :

Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out t= hat "it can be observed that with current implementations of RPL, such= as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13,= a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed&quo= t;.

Is it something that you observed in your own deployments ?
More specifically : did you find similar results ?
We observed the occurrence of loops, unfortunately we did not measure the p= ercentage.

So how did you evaluate the benefit of the mechanism that you proposed= ?

C=E9dric.


Best,

C=E9dric.


For your second question, further investigation and experiments are needed.=

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment sho=
ws that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -exper=
iences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

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



--_000_97B69B30E0EF244B940B65EA541E3F2D2156744DDBXPRD0510MB395_-- From guo@merl.com Fri Oct 26 08:36:55 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 30AD121F856D for ; Fri, 26 Oct 2012 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntTZOO5w9JoA for ; Fri, 26 Oct 2012 08:36:52 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4479F21F856B for ; Fri, 26 Oct 2012 08:36:52 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9QFapH2028642; Fri, 26 Oct 2012 11:36:51 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9QFajrV004402; Fri, 26 Oct 2012 11:36:50 -0400 Message-ID: <508AAE0D.8030903@merl.com> Date: Fri, 26 Oct 2012 11:36:45 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: C Chauvenet References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------050806090806030004020609" Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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, 26 Oct 2012 15:36:55 -0000 This is a multi-part message in MIME format. --------------050806090806030004020609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit We compared performance metrics such as packet delivery rate. On 10/26/2012 11:21 AM, C Chauvenet wrote: > Hi, > Thank you for your answer. > See inline. > > Le 26 oct. 2012 à 15:27, Jianlin Guo a écrit : > >> On 10/25/2012 12:06 PM, C Chauvenet wrote: >>> Hi, >>> >>> Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit : >>> >>>> Hi Michael, >>>> >>>> For your first question, draft-clausen-lln-rpl-experiences-04 >>>> pointed out that "it can be observed that with current >>>> implementations of RPL, such as the ContikiRPL implementation, >>>> loops do occur - and, frequently. During the same experiments >>>> described in Section 13, a snapshot of the DODAG was made every ten >>>> seconds. In 74.14% of the 4114 snapshots, at least one loop was >>>> observed". >>> >>> Is it something that you observed in your own deployments ? >>> More specifically : did you find similar results ? >> We observed the occurrence of loops, unfortunately we did not measure >> the percentage. > > So how did you evaluate the benefit of the mechanism that you proposed ? > > Cédric. > >> >>> Best, >>> >>> Cédric. >>> >>>> >>>> For your second question, further investigation and experiments are >>>> needed. >>>> >>>> Jianlin >>>> >>>> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>>>> Jianlin Guo wrote: >>>>> JG> Dear ROLL WG members, >>>>> >>>>> JG> As we all know that loop is an open issue in RPL. Experiment shows that loop >>>>> JG> occurs quite often. We have proposed a loop free local DODAG >>>>> >>>>> Can you quantify "quite often"? >>>>> Do you have any metrics for how often loops occur, and what the cost is >>>>> of their repair? >>>>> >>>>> I think that the WG would be very very very interested in additional -experiences >>>>> draft, or pointers to papers explaining same, that gives a repeateable >>>>> experiment in which loops are observed. >>>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >> > --------------050806090806030004020609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We compared performance metrics such as packet delivery rate.
On 10/26/2012 11:21 AM, C Chauvenet wrote:
Hi,
Thank you for your answer.
See inline.

Le 26 oct. 2012 à 15:27, Jianlin Guo a écrit :

On 10/25/2012 12:06 PM, C Chauvenet wrote:
Hi, 

Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit :

Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed".

Is it something that you observed in your own deployments ?
More specifically : did you find similar results ?
We observed the occurrence of loops, unfortunately we did not measure the percentage.

So how did you evaluate the benefit of the mechanism that you proposed ?

Cédric.


Best,

Cédric.


For your second question, further investigation and experiments are needed.

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment shows that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -experiences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

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




--------------050806090806030004020609-- From c.chauvenet@watteco.com Fri Oct 26 09:11:04 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 AD74B21F8644 for ; Fri, 26 Oct 2012 09:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.122 X-Spam-Level: X-Spam-Status: No, score=-4.122 tagged_above=-999 required=5 tests=[AWL=-0.524, 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 nlFEuCLUeysN for ; Fri, 26 Oct 2012 09:11:03 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 847DF21F8633 for ; Fri, 26 Oct 2012 09:11:03 -0700 (PDT) Received: from mail177-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 26 Oct 2012 16:11:03 +0000 Received: from mail177-va3 (localhost [127.0.0.1]) by mail177-va3-R.bigfish.com (Postfix) with ESMTP id E8E7C2C01EA; Fri, 26 Oct 2012 16:11:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371Ic89bhc85dh1418Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dh5eeeKz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail177-va3 (localhost.localdomain [127.0.0.1]) by mail177-va3 (MessageSwitch) id 1351267859536579_21512; Fri, 26 Oct 2012 16:10:59 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.237]) by mail177-va3.bigfish.com (Postfix) with ESMTP id 7EEC92A00C2; Fri, 26 Oct 2012 16:10:59 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 26 Oct 2012 16:10:58 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.174]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0224.004; Fri, 26 Oct 2012 16:10:55 +0000 From: C Chauvenet To: Jianlin Guo Thread-Topic: [Roll] Loop free local DODAG repair solution Thread-Index: AQHNsShZPcx+lZkhlUaljQOJ54dOTZfJ8H+AgAAfrgCAACMDgIABZecAgAAfwYCAAAQ/gIAACYsA Date: Fri, 26 Oct 2012 16:10:55 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AAE0D.8030903@merl.com> In-Reply-To: <508AAE0D.8030903@merl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.67.132] Content-Type: multipart/alternative; boundary="_000_97B69B30E0EF244B940B65EA541E3F2D215676A7DBXPRD0510MB395_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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, 26 Oct 2012 16:11:04 -0000 --_000_97B69B30E0EF244B940B65EA541E3F2D215676A7DBXPRD0510MB395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Le 26 oct. 2012 =E0 17:36, Jianlin Guo a =E9crit : We compared performance metrics such as packet delivery rate. Ok. In general do you have a document about your experiments that you would lik= e to share ? I think it could be a good way to defend your mechanism. There are 2 sub questions related to your draft : - Is there a strong need for an additional mechanism to prevent loops ? (t= he HbH header option mentioned by phil is already there). - Is your mechanism the good way to do so (overhead induced, efficiency...= ) As mentioned by Phil, this subject has been previously discussed inside ROL= L few years ago, and did not recommend to add such mechanisms. For instance, [1] concludes that "the turmoil caused by dismantling of the sub-DAGs in order to increase ranks may be much more than what the routing loops themselves will cause. Consequently, the use of such loop avoidance mechanism in the operation of a DAG based routing protocol can not be universally recommended." [1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf Best, C=E9dric. On 10/26/2012 11:21 AM, C Chauvenet wrote: Hi, Thank you for your answer. See inline. Le 26 oct. 2012 =E0 15:27, Jianlin Guo a =E9crit : On 10/25/2012 12:06 PM, C Chauvenet wrote: Hi, Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit : Hi Michael, For your first question, draft-clausen-lln-rpl-experiences-04 pointed out t= hat "it can be observed that with current implementations of RPL, such as t= he ContikiRPL implementation, loops do occur - and, frequently. During the = same experiments described in Section 13, a snapshot of the DODAG was made = every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was o= bserved". Is it something that you observed in your own deployments ? More specifically : did you find similar results ? We observed the occurrence of loops, unfortunately we did not measure the p= ercentage. So how did you evaluate the benefit of the mechanism that you proposed ? C=E9dric. Best, C=E9dric. For your second question, further investigation and experiments are needed. Jianlin On 10/25/2012 8:08 AM, Michael Richardson wrote: Jianlin Guo wrote: JG> Dear ROLL WG members, JG> As we all know that loop is an open issue in RPL. Experiment shows = that loop JG> occurs quite often. We have proposed a loop free local DODAG Can you quantify "quite often"? Do you have any metrics for how often loops occur, and what the cost is of their repair? I think that the WG would be very very very interested in additional -exper= iences draft, or pointers to papers explaining same, that gives a repeateable experiment in which loops are observed. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_97B69B30E0EF244B940B65EA541E3F2D215676A7DBXPRD0510MB395_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <56BD524C0062204295B0EC9023192EB0@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Le 26 oct. 2012 =E0 17:36, Jianlin Guo a =E9crit :

We compared performance metrics such as pack= et delivery rate.

Ok.

In general do you have a document about your experiments that you woul= d like to share ?
I think it could be a good way to defend your mechanism.

There are 2 sub questions related to your draft : 

 - Is there a strong need for an additional mechanism to prevent = loops ? (the HbH header option mentioned by phil is already there).
 - Is your mechanism the good way to do so (overhead induced, eff= iciency...)

As mentioned by Phil, this subject has been previously discussed insid= e ROLL few years ago, and did not recommend to add such mechanisms.

For instance, [1] concludes that 

"the turmoil caused
by dismantling of the sub-DAGs in order to increase ranks
may be much more than what the routing loops themselves
will cause. Consequently, the use of such loop avoidance
mechanism in the operation of a DAG based routing protocol
can not be universally recommended."

[1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf<= /div>

Best,

C=E9dric.

On 10/26/2012 11:21 AM, C Chauvenet wrote:
Hi,
Thank you for your answer.
See inline.

Le 26 oct. 2012 =E0 15:27, Jianlin Guo a =E9crit :

On 10/25/2012 12:06 PM, C Chauvenet wrote:
Hi, 

Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit :

Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out t= hat "it can be observed that with current implementations of RPL, such= as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13,= a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed&quo= t;.

Is it something that you observed in your own deployments ?
More specifically : did you find similar results ?
We observed the occurrence of loops, unfortunately we did not measure the p= ercentage.

So how did you evaluate the benefit of the mechanism that you proposed= ?

C=E9dric.


Best,

C=E9dric.


For your second question, further investigation and experiments are needed.=

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment sho=
ws that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -exper=
iences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

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





--_000_97B69B30E0EF244B940B65EA541E3F2D215676A7DBXPRD0510MB395_-- From guo@merl.com Fri Oct 26 12:18: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 C09A821F8665 for ; Fri, 26 Oct 2012 12:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH4hTHR-EpwO for ; Fri, 26 Oct 2012 12:18:26 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FBA21F862B for ; Fri, 26 Oct 2012 12:18:26 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9QJIPPE030546; Fri, 26 Oct 2012 15:18:25 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9QJIHrV009228; Fri, 26 Oct 2012 15:18:24 -0400 Message-ID: <508AE1F9.1080600@merl.com> Date: Fri, 26 Oct 2012 15:18:17 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: C Chauvenet References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AAE0D.8030903@merl.com> <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------060108060308070209060206" Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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, 26 Oct 2012 19:18:27 -0000 This is a multi-part message in MIME format. --------------060108060308070209060206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thank you for the paper. I agree with [1] on that "dismantling of the sub-DAG, rooted at the node doing the rank increase, causes more turmoil in the network than the routing loops themselves". Now, consider a case in which a node's parent set becomes empty. In this case, RPL provides following set of actions: 1) Start its own floating DODAG 2) Poison the broken path 3) Trigger a local repair Both 1) and 2) actions will increase packet delivery delay time (which may be not acceptable for some applications) and possibly cause packet dropping due to limited buffer size of a LLN node (which may also be not acceptable for some applications). So, trigger a local repair is a practical option. Our local repair mechanism is designed for this purpose and it does not create any loops. Jianlin On 10/26/2012 12:10 PM, C Chauvenet wrote: > > Le 26 oct. 2012 à 17:36, Jianlin Guo a écrit : > >> We compared performance metrics such as packet delivery rate. > > Ok. > > In general do you have a document about your experiments that you > would like to share ? > I think it could be a good way to defend your mechanism. > > There are 2 sub questions related to your draft : > > - Is there a strong need for an additional mechanism to prevent loops > ? (the HbH header option mentioned by phil is already there). > - Is your mechanism the good way to do so (overhead induced, > efficiency...) > > As mentioned by Phil, this subject has been previously discussed > inside ROLL few years ago, and did not recommend to add such mechanisms. > > For instance, [1] concludes that > / > / > /"the turmoil caused/ > /by dismantling of the sub-DAGs in order to increase ranks/ > /may be much more than what the routing loops themselves/ > /will cause. Consequently, the use of such loop avoidance/ > /mechanism in the operation of a DAG based routing protocol/ > /can not be universally recommended."/ > > [1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf > > Best, > > Cédric. > >> On 10/26/2012 11:21 AM, C Chauvenet wrote: >>> Hi, >>> Thank you for your answer. >>> See inline. >>> >>> Le 26 oct. 2012 à 15:27, Jianlin Guo a écrit : >>> >>>> On 10/25/2012 12:06 PM, C Chauvenet wrote: >>>>> Hi, >>>>> >>>>> Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit : >>>>> >>>>>> Hi Michael, >>>>>> >>>>>> For your first question, draft-clausen-lln-rpl-experiences-04 >>>>>> pointed out that "it can be observed that with current >>>>>> implementations of RPL, such as the ContikiRPL implementation, >>>>>> loops do occur - and, frequently. During the same experiments >>>>>> described in Section 13, a snapshot of the DODAG was made every >>>>>> ten seconds. In 74.14% of the 4114 snapshots, at least one loop >>>>>> was observed". >>>>> >>>>> Is it something that you observed in your own deployments ? >>>>> More specifically : did you find similar results ? >>>> We observed the occurrence of loops, unfortunately we did not >>>> measure the percentage. >>> >>> So how did you evaluate the benefit of the mechanism that you proposed ? >>> >>> Cédric. >>> >>>> >>>>> Best, >>>>> >>>>> Cédric. >>>>> >>>>>> >>>>>> For your second question, further investigation and experiments >>>>>> are needed. >>>>>> >>>>>> Jianlin >>>>>> >>>>>> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>>>>>> Jianlin Guo wrote: >>>>>>> JG> Dear ROLL WG members, >>>>>>> >>>>>>> JG> As we all know that loop is an open issue in RPL. Experiment shows that loop >>>>>>> JG> occurs quite often. We have proposed a loop free local DODAG >>>>>>> >>>>>>> Can you quantify "quite often"? >>>>>>> Do you have any metrics for how often loops occur, and what the cost is >>>>>>> of their repair? >>>>>>> >>>>>>> I think that the WG would be very very very interested in additional -experiences >>>>>>> draft, or pointers to papers explaining same, that gives a repeateable >>>>>>> experiment in which loops are observed. >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>> >>> >> > --------------060108060308070209060206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thank you for the paper. I agree with [1] on that "dismantling of the sub-DAG, rooted at the node doing the rank increase, causes more turmoil in the network than the routing loops themselves".

Now, consider a case in which a node's parent set becomes empty. In this case, RPL provides following set of actions:

1) Start its own floating DODAG
2) Poison the broken path
3) Trigger a local repair

Both 1) and 2) actions will increase packet delivery delay time (which may be not acceptable for some applications) and possibly cause packet dropping due to limited buffer size of a LLN node (which may also be not acceptable for some applications). So, trigger a local repair is a practical option. Our local repair mechanism is designed for this purpose and it does not create any loops.

Jianlin

On 10/26/2012 12:10 PM, C Chauvenet wrote:

Le 26 oct. 2012 à 17:36, Jianlin Guo a écrit :

We compared performance metrics such as packet delivery rate.

Ok.

In general do you have a document about your experiments that you would like to share ?
I think it could be a good way to defend your mechanism.

There are 2 sub questions related to your draft : 

 - Is there a strong need for an additional mechanism to prevent loops ? (the HbH header option mentioned by phil is already there).
 - Is your mechanism the good way to do so (overhead induced, efficiency...)

As mentioned by Phil, this subject has been previously discussed inside ROLL few years ago, and did not recommend to add such mechanisms.

For instance, [1] concludes that 

"the turmoil caused
by dismantling of the sub-DAGs in order to increase ranks
may be much more than what the routing loops themselves
will cause. Consequently, the use of such loop avoidance
mechanism in the operation of a DAG based routing protocol
can not be universally recommended."


Best,

Cédric.

On 10/26/2012 11:21 AM, C Chauvenet wrote:
Hi,
Thank you for your answer.
See inline.

Le 26 oct. 2012 à 15:27, Jianlin Guo a écrit :

On 10/25/2012 12:06 PM, C Chauvenet wrote:
Hi, 

Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit :

Hi Michael,

For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed".

Is it something that you observed in your own deployments ?
More specifically : did you find similar results ?
We observed the occurrence of loops, unfortunately we did not measure the percentage.

So how did you evaluate the benefit of the mechanism that you proposed ?

Cédric.


Best,

Cédric.


For your second question, further investigation and experiments are needed.

Jianlin

On 10/25/2012 8:08 AM, Michael Richardson wrote:
Jianlin Guo <guo@merl.com> wrote:
    JG> Dear ROLL WG members,

    JG> As we all know that loop is an open issue in RPL. Experiment shows that loop
    JG> occurs quite often. We have proposed a loop free local DODAG

Can you quantify "quite often"?
Do you have any metrics for how often loops occur, and what the cost is
of their repair?

I think that the WG would be very very very interested in additional -experiences
draft, or pointers to papers explaining same, that gives a repeateable
experiment in which loops are observed.

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






--------------060108060308070209060206-- From ulrich@herberg.name Fri Oct 26 20:33: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 9C59421F8698 for ; Fri, 26 Oct 2012 20:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-2.710, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, J_CHICKENPOX_12=0.6, 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 b6i6K-WnV7CR for ; Fri, 26 Oct 2012 20:33:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9F21F8694 for ; Fri, 26 Oct 2012 20:33:10 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4032321vbb.31 for ; Fri, 26 Oct 2012 20:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DzoALGAIINWmTnWfxid/RI6UTjm6tr2/lBvqCPu6EQs=; b=JWkmqVC7jdTwbAsCnDIMnIQk/JPLmyFAQhp1fMyTSzUbT3xUab/geQY56plWRFmdbL T68G6V+2v/KetNsL4x8Jqz6tO5ilgZPqv/cIx0b39QjjiWiHXrF5wCutrG53InQUgs99 vCiSdUEXgDrLTXEkeudRKVr8V8OsqLPjpemjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DzoALGAIINWmTnWfxid/RI6UTjm6tr2/lBvqCPu6EQs=; b=aLF2Sv9n8c1URmkSMQTfRUkK9Fn2PEmNal+U5Mx9YkvLniUaXEwTkOwxCISp1gN1Xq cMgL2Nl4y+3WOvcI4vyDxEjVH9sjN0Vth0eucVYUhf1gNnL6sRhiy7qtdO6klPaha1T4 TmUtYe5pLc/GkLR874Ld4pgFrw46Hn4GLxsdXhmz8SPKk+OF0MHEe1DqYAyMS1/khF/B I4ZUOLqZLFYfo3PxXLZ1UcSxGbrLJKstV0N3bsQP+JsIw9lKClklsVAr8ZDFbF9znUwo tBwVs4tG7peQo1uB0AhssjKjvWZSpvUuQxmbIBXt3seEKabbQ5VX12nZCW79lFP+kqVJ qyvQ== MIME-Version: 1.0 Received: by 10.220.119.196 with SMTP id a4mr191330vcr.19.1351308789616; Fri, 26 Oct 2012 20:33:09 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 26 Oct 2012 20:33:09 -0700 (PDT) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> Date: Fri, 26 Oct 2012 20:33:09 -0700 Message-ID: From: Ulrich Herberg To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm18NHxS7Hu7oxXiChKNx4O1S+gZfe87tWEZ0frrJAeuGxr1j1ibqw1X+KA09l15OepnBrQ Cc: richard.kelsey@silabs.com, "roll@ietf.org WG" , Michael Richardson 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, 27 Oct 2012 03:33:13 -0000 Hi, below is my review. My major comment is that the IANA section needs to be fixed and a security considerations section needs to be written. Without that section, the document should not go forward in my opinion. Then I have multiple questions for clarity (see the detailed review). Also, as a standards track document, I think it should give some guidelines about which values for the parameters to use, as well as some indications about the state requirements of the protocol. Are there any implementations and/or deployments of the protocol out there? Best regards Ulrich ROLL J. Hui Internet-Draft Cisco Intended status: Standards Track R. Kelsey Expires: April 22, 2013 Silicon Labs October 19, 2012 Multicast Protocol for Low power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-02 Abstract This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL forwarders in an MPL domain. MPL uses the Trickle algorithm to drive packet transmissions for both control and data-plane packets. Specific Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Hui & Kelsey Expires April 22, 2013 [Page 1] Internet-Draft MPL October 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11 5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13 5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Hui & Kelsey Expires April 22, 2013 [Page 2] Internet-Draft MPL October 2012 1. Introduction Low power and Lossy Networks typically operate with strict resource constraints in communication, computation, memory, and energy. Such resource constraints may preclude the use of existing IPv6 multicast topology and forwarding mechanisms. Traditional IP multicast forwarding typically relies on topology maintenance mechanisms to forward multicast messages to all subscribers of a multicast group. However, maintaining such topologies in LLNs is costly and may not be feasible given the available resources. Memory constraints may limit devices to maintaining links/routes to one or a few neighbors. For this reason, the Routing Protocol for LLNs (RPL) UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" specifies both storing and non-storing modes [RFC6550]. The latter allows RPL routers to maintain only one or a few default routes towards a LLN Border Router (LBR) UH> I did not find LBR in the terminology section. and use source routing to forward packets away from the LBR. For the same reasons, a LLN device may not be able to maintain a multicast forwarding topology when operating with limited memory. Furthermore, the dynamic properties of wireless networks can make the cost of maintaining a multicast forwarding topology prohibitively expensive. In wireless environments, topology maintenance may involve selecting a connected dominating set used to forward multicast messages to all nodes in an administrative domain. However, existing mechanisms often require two-hop topology information and the cost of maintaining such information grows polynomially with network density. This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating multicast messages to all MPL forwarders in an MPL domain. By using the Trickle algorithm [RFC6206], MPL requires only small, constant state for each MPL device that initiates disseminations. The Trickle algorithm also allows MPL to be density-aware, allowing the communication rate to scale logarithmically with density. UH> I am not sure I understand the last sentence. What does it mean? How is that achieved? UH> By the way, since this is a standards track document, is there any deployment experience? Implementations? Hui & Kelsey Expires April 22, 2013 [Page 3] Internet-Draft MPL October 2012 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119 The following terms are used throughout this document: MPL forwarder An IPv6 router that subscribes to the MPL multicast group and participates in disseminating MPL multicast packets. MPL multicast scope The multicast scope that MPL uses when forwarding MPL multicast packets. In other words, the multicast scope of the IPv6 Destination Address of an MPL multicast packet. UH> An RFC reference to "scope" could be helpful. MPL domain A connected set of MPL forwarders that define the extent of the MPL dissemination process. UH> What does connected mean? What if a the network is split in two parts? As a form of flood, all MPL forwarders in an MPL domain will receive MPL multicast packets. UH> Probably not *all* forwards will receive it (assuming packets can be lost) The MPL domain MUST be composed of at least one MPL multicast scope and MAY be composed of multiple MPL multicast scopes. UH> Why is that? Anyway, I am unsure whether one can say that a routing domain "consists" of multicast scopes. If I understand that correctly, the multicast scope just determines how far a message propagates. MPL seed A MPL forwarder that begins the dissemination process for an MPL multicast packet. The MPL seed may be different than the source of the original multicast packet. MPL seed identifier An identifier that uniquely identifies an MPL forwarder within its MPL domain. UH> How is the uniqueness guaranteed? What kind of identifier is that? An IP address? I see it's defined later, but maybe it would be helpful to mention it here, too. original multicast packet An IPv6 multicast packet that is disseminated using MPL. UH> That terminology sounds a bit confusing; I would have imagined that the above description matches the following term "MPL multicast packet". What's the difference between an "original multicast packet" and an "MPL multicast packet"? I assume the one is the inner packet when using IPv6-in-IPv6 tunnels, the other one is the outer packet with the options header. MPL multicast packet An IPv6 multicast packet that contains an MPL Hop-by-Hop Option. When either source or destinations are beyond the MPL multicast scope, UH> Above it was said there may be multiple scopes in a domain. Here you talk about "the" scope. Which one? the MPL multicast packet is an IPv6-in-IPv6 packet that contains an MPL Hop-by-Hop Option in the outer IPv6 header and encapsulates an original multicast packet. When both source and destinations are within the MPL multicast scope, the MPL Hop-by-Hop Option may be included directly within the original multicast packet. Hui & Kelsey Expires April 22, 2013 [Page 4] Internet-Draft MPL October 2012 3. Overview MPL delivers IPv6 multicast packets by disseminating them to all MPL forwarders within an MPL domain. MPL dissemination is a form of flood. An MPL forwarder may broadcast/multicast an MPL multicast packet out of the same physical interface on which it was received. Using link-layer broadcast/multicast allows MPL to forward multicast packets without explicitly identifying next-hop destinations. An MPL forwarder may also broadcast/multicast MPL multicast packets out other interfaces to disseminate the message across different links. MPL does not build or maintain a multicast forwarding topology to forward multicast packets. Any MPL forwarder may initiate the dissemination process by serving as an MPL seed for an original multicast packet. The MPL seed may or may not be the same device as the source of the original multicast packet. When the original multicast packet's source is outside the LLN, UH> LLN or MPL domain? How can a router determine if an incoming packet is inside our outside the MPL domain? the MPL seed may be the ingress router. Even if an original multicast packet source is within the LLN, the source may first forward the multicast packet to the MPL seed using IPv6-in-IPv6 tunneling. UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a title not related to "IPv6 tunneling". I suggest to make an own section. Because MPL state requirements grows with the number of active MPL seeds, UH> In section 1 it was written that the state is constant. Here you say it grows. Which one is it? limiting the number of MPL seeds reduces the amount of state that MPL forwarders must maintain. Because MPL typically broadcasts/multicasts MPL packets out of the same interface on which they were received, UH> Why typically? Doesn't that depend on the scenario that this specification is used in? MPL forwarders are likely to receive an MPL multicast packet more than once. UH> I am not sure if that is the only reason. Isn't the reason that it may be received from multiple neighbors? The MPL seed tags each original multicast packet with an MPL seed identifier and a sequence number. The sequence number provides a total ordering of MPL multicast packets disseminated by the MPL seed. MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include MPL-specific information along with the original multicast packet. Each IPv6 multicast packet that MPL disseminates includes the MPL Option. Because the original multicast packet's source and the MPL seed may not be the same device, the MPL Option may be added to the original multicast packet en-route. To allow Path MTU discovery to work properly, MPL encapsulates the original multicast packet in another IPv6 header that includes the MPL Option. Upon receiving a new MPL multicast packet for forwarding, the MPL forwarder may proactively transmit the MPL multicast packet packet a limited number of times and then falls back into an optional reactive mode. In maintenance mode, an MPL forwarder buffers recently received MPL multicast packets and advertises a summary of recently received MPL multicast packets from time to time, allowing neighboring MPL forwarders to determine if they have any new multicast packets to offer or receive. Hui & Kelsey Expires April 22, 2013 [Page 5] Internet-Draft MPL October 2012 MPL forwarders schedule their packet (control and data) transmissions using the Trickle algorithm [RFC6206]. Trickle's adaptive transmission interval allows MPL to quickly disseminate messages when there are new MPL multicast packets, but reduces transmission overhead as the dissemination process completes. Trickle's suppression mechanism and transmission time selection allow MPL's communication rate to scale logarithmically with density. UH> I think the whole introduction is not very easy to read. There is a lot of text about some details (IPv6-in-IPv6 tunnels, multiple interfaces), but the essential mechanism is hard to identify from the text. Also, there is nothing mentioned about what kind of state is required to be stored on each router (which information sets etc). Hui & Kelsey Expires April 22, 2013 [Page 6] Internet-Draft MPL October 2012 4. Message Formats 4.1. MPL Option The MPL Option is carried in an IPv6 Hop-by-Hop Options header, UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options header" UH> More importantly, RFC6564 specifies: New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible. Any proposal to create a new option for the existing Hop-by-Hop Header MUST include a detailed explanation of why the hop-by-hop behavior is absolutely essential in the document proposing the new option with hop-by-hop behavior. UH> I did not see such an explanation. immediately following the IPv6 header. The MPL Option has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S |M| rsv | sequence | seed-id (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UH> It could help to mention that this is formatted in network byte order Option Type XX (to be confirmed by IANA). Opt Data Len Length of the Option Data field in octets. MUST be set to either 2 or 4. UH> 2 or 4 depending on what? S 2-bit unsigned integer. Identifies the length of seed-id. 0 indicates that the seed-id is 0 and not included in the MPL Option. 1 indicates that the seed-id is a 16-bit unsigned integer. 2 indicates that the seed-id is a 64-bit unsigned integer. 3 indicates that the seed-id is a 128- bit unsigned integer. M 1-bit flag. 0 indicates that the value in sequence is not the greatest sequence number that was received from the MPL seed. rsv 5-bit reserved field. MUST be set to zero and incoming MPL multicast packets in which they are not zero MUST be dropped. sequence 8-bit unsigned integer. Identifies relative ordering of MPL multicast packets from the source identified by seed-id. seed-id Uniquely identifies the MPL seed that initiated dissemination of the MPL multicast packet. The size of seed-id is indicated by the S field. The Option Data of the Trickle Multicast option MUST NOT change as the MPL multicast packet is forwarded. Nodes that do not understand Hui & Kelsey Expires April 22, 2013 [Page 7] Internet-Draft MPL October 2012 the Trickle Multicast option MUST discard the packet. Thus, according to [RFC2460] the three high order bits of the Option Type must be set to '010'. The Option Data length is variable. The seed-id uniquely identifies an MPL seed within the MPL domain. When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address assigned to one of its interfaces that is unique within the MPL domain. Managing MPL seed identifiers is not within scope of this document. The sequence field establishes a total ordering of MPL multicast packets from the same MPL seed. The MPL seed MUST increment the sequence field's value on each new MPL multicast packet that it disseminates. Implementations MUST follow the Serial Number Arithmetic as defined in [RFC1982] when incrementing a sequence value or comparing two sequence values. Future updates to this specification may define additional fields following the seed-id field. 4.2. ICMPv6 MPL Message The MPL forwarder uses ICMPv6 MPL messages to advertise information about recently received MPL multicast packets. The ICMPv6 MPL message has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . MPL Window[1..n] . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address A link-local address assigned to the sending interface. Destination Address The link-local all-nodes MPL forwarders multicast address (FF02::TBD). Hui & Kelsey Expires April 22, 2013 [Page 8] Internet-Draft MPL October 2012 Hop Limit 255 ICMPv6 Fields: Type XX (to be confirmed by IANA). Code 0 Checksum The ICMP checksum. See [RFC4443]. MPL Window[1..n] List of one or more MPL Windows (defined in Section 4.2.1). An MPL forwarder transmits an ICMPv6 MPL message to advertise information about buffered MPL multicast packets. More explicitly, the ICMPv6 MPL message encodes the sliding window state (described in Section 5.2) that the MPL forwarder maintains for each MPL seed. The advertisement serves to indicate to neighboring MPL forwarders regarding newer messages that it may send or the neighboring MPL forwarders have yet to receive. 4.2.1. MPL Window An MPL Window encodes the sliding window state (described in Section 5.2 that the MPL forwarder maintains for an MPL seed. UH> missing ")" Each MPL Window has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | w-min | w-len | S | seed-id (0, 2 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . buffered-mpl-packets (0 to 8 octets) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ w-min 8-bit unsigned integer. Indicates the first sequence number associated with the first bit in buffered-mpl-packets. w-len 6-bit unsigned integer. Indicates the size of the sliding window and the number of valid bits in buffered-mpl-packets. The sliding window's upper bound is the sum of w-min and w-len. Hui & Kelsey Expires April 22, 2013 [Page 9] Internet-Draft MPL October 2012 S 2-bit unsigned integer. Identifies the length of seed-id. 0 indicates that the seed-id value is 0 and not included in the MPL Option. 1 indicates that the seed-id value is a 16-bit unsigned integer. 2 indicates that the seed-id value is a 128-bit unsigned integer. 3 is reserved. seed-id Indicates the MPL seed associated with this sliding window. buffered-mpl-packets Variable-length bit vector. Identifies the sequence numbers of MPL multicast packets that the MPL forwarder has buffered. The sequence number is determined by w-min + i, where i is the offset within buffered-mpl-packets. The MPL Window does not have any octet alignment requirement. Hui & Kelsey Expires April 22, 2013 [Page 10] Internet-Draft MPL October 2012 5. MPL Forwarder Behavior An MPL forwarder implementation needs to manage sliding windows for each active MPL seed. The sliding window allows the MPL forwarder to determine what multicast packets to accept and what multicast packets are buffered. An MPL forwarder must also manage MPL packet transmissions. 5.1. Multicast Packet Dissemination MPL uses the Trickle algorithm to control packet transmissions when disseminating MPL multicast packets [RFC6206]. MPL provides two propagation mechanisms for disseminating MPL multicast packets. 1. With proactive propagation, an MPL forwarder transmits buffered MPL multicast packets using the Trickle algorithm. This method is called proactive propagation since an MPL forwarder actively transmits MPL multicast packets without discovering that a neighboring MPL forwarder has yet to receive the message. 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL messages using the Trickle algorithm. An MPL forwarder only transmits buffered MPL multicast packets upon discovering that neighboring devices have not yet to receive the corresponding MPL multicast packets. When receiving a new multicast packet, an MPL forwarder first utilizes proactive propagation to forward the MPL multicast packet. Proactive propagation reduces dissemination latency since it does not require discovering that neighboring devices have not yet received the MPL multicast packet. MPL forwarders utilize proactive propagation for newly received MPL multicast packets since they can assume that some neighboring MPL forwarders have yet to receive the MPL multicast packet. After a limited number of MPL multicast packet transmissions, the MPL forwarder may terminate proactive propagation for the MPL multicast packet. An MPL forwarder may optionally use reactive propagation to continue the dissemination process with lower communication overhead. With reactive propagation, neighboring MPL forwarders use ICMPv6 MPL messages to discover new MPL multicast messages that have not yet been received. When discovering that a neighboring MPL forwarder has not yet received a new MPL multicast packet, the MPL forwarder enables proactive propagation again. UH> There is not a lot of RFC2119 language in the above. Or is that defined later? Is this above section more like an introduction? Hui & Kelsey Expires April 22, 2013 [Page 11] Internet-Draft MPL October 2012 5.1.1. Trickle Parameters and Variables As specified in RFC 6206 [RFC6206], a Trickle timer runs for a defined interval and has three configuration parameters: the minimum interval size Imin, the maximum interval size Imax, and a redundancy constant k. MPL defines a fourth configuration parameter, TimerExpirations, which indicates the number of Trickle timer expiration events that occur before terminating the Trickle algorithm. Each MPL forwarder maintains a separate Trickle parameter set for the proactive and reactive propagation methods. TimerExpirations MUST be greater than 0 for proactive propagation. TimerExpirations MAY be set to 0 for reactive propagation, which effectively disables reactive propagation. As specified in RFC 6206 [RFC6206], a Trickle timer has three variables: the current interval size I, a time within the current interval t, and a counter c. UH> This sentence starts confusing, as it looks very similar to the first paragraph in this section. "a Trickle timer has three variables" How about using the same language as in RFC6206: "In addition to these three parameters, Trickle maintains three variables: o I, the current interval size, o t, a time within the current interval, and o c, a counter." MPL defines a fourth variable, e, which counts the number of Trickle timer expiration events since the Trickle timer was last reset. 5.1.2. Proactive Propagation With proactive propagation, the MPL forwarder transmits buffered MPL multicast packets using the Trickle algorithm. Each buffered MPL multicast packet that is proactively being disseminated with proactive propagation has an associated Trickle timer. UH> I think that somewhere the state requirements need to be mentioned. How does that affect scalability of the algorithm etc. Density is mentioned somewhere in the beginning, but not explained how that would affect scalability and state requirements. Adhering to Section 5 of RFC 6206 [RFC6206], this document defines the following: o This document defines a "consistent" transmission for proactive propagation as receiving an MPL multicast packet that has the same MPL seed identifier and sequence number as a buffered MPL packet. o This document defines an "inconsistent" transmission for proactive propagation as receiving an MPL multicast packet that has the same MPL seed identifier, the M flag set, and has a sequence number less than the buffered MPL multicast packet's sequence number. o This document does not define any external "events". o This document defines both MPL multicast packets and ICMPv6 MPL multicast packets as Trickle messages. These messages are defined in the sections below. UH> I don't see the term Trickle message used anywhere else. Hui & Kelsey Expires April 22, 2013 [Page 12] Internet-Draft MPL October 2012 o The actions outside the Trickle algorithm that the protocol takes involve managing sliding window state, and is specified in Section 5.2. 5.1.3. Reactive Propagation With reactive propagation, the MPL forwarder transmits ICMPv6 MPL messages using the Trickle algorithm. A MPL forwarder maintains a single Trickle timer for reactive propagation with each MPL domain. When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not execute the Trickle algorithm for reactive propagation and reactive propagation is disabled. Adhering to Section 5 of RFC 6206 [RFC6206], this document defines the following: o This document defines a "consistent" transmission for reactive propagation as receiving an ICMPv6 MPL message that indicates neither the receiving nor transmitting node has new MPL multicast packets to offer. o This document defines an "inconsistent" transmission for reactive propagation as receiving an ICMPv6 MPL message that indicates either the receiving or transmitting node has at least one new MPL multicast packet to offer. o This document defines an "event" for reactive propagation as updating any sliding window (i.e. changing the value of WindowMin, WindowMax, or the set of buffered MPL multicast packets) in response to receiving an MPL multicast packet. o This document defines both MPL multicast packets and ICMPv6 MPL multicast packets as Trickle messages. These messages are defined in the sections below. UH> I don't see the term "Trickle message" anywhere else (other than in 5.1.2) o The actions outside the Trickle algorithm that the protocol takes involve managing sliding window state, and is specified in Section 5.2. 5.2. Sliding Windows Every MPL forwarder MUST maintain a sliding window of sequence numbers for each MPL seed of recently received MPL packets. The sliding window performs two functions: 1. Indicate what MPL multicast packets the MPL forwarder should accept. 2. Indicate what MPL multicast packets are buffered and may be transmitted to neighboring MPL forwarders. Hui & Kelsey Expires April 22, 2013 [Page 13] Internet-Draft MPL October 2012 Each sliding window logically consists of: 1. A lower-bound sequence number, WindowMin, that represents the sequence number of the oldest MPL multicast packet the MPL forwarder is willing to receive or has buffered. An MPL forwarder MUST ignore any MPL multicast packet that has sequence value less than than WindowMin. 2. An upper-bound sequence value, WindowMax, that represents the sequence number of the next MPL multicast packet that the MPL forwarder expects to receive. An MPL forwarder MUST accept any MPL multicast packet that has sequence number greater than or equal to WindowMax. 3. A list of MPL multicast packets, BufferedPackets, buffered by the MPL forwarder. Each entry in BufferedPackets MUST have a sequence number in the range [WindowMin, WindowMax). 4. A timer, HoldTimer, that indicates the minimum lifetime of the sliding window. The MPL forwarder MUST NOT free a sliding window before HoldTimer expires. When receiving an MPL multicast packet, if no existing sliding window exists for the MPL seed, the MPL forwarder MUST create a new sliding window before accepting the MPL multicast packet. The MPL forwarder may reclaim memory resources by freeing a sliding window for another MPL seed if its HoldTimer has expired. If, for any reason, the MPL forwarder cannot create a new sliding window, it MUST discard the packet. If a sliding window exists for the MPL seed, the MPL forwarder MUST ignore the MPL multicast packet if the packet's sequence number is less than WindowMin or appears in BufferedPackets. Otherwise, the MPL forwarder MUST accept the packet and determine whether or not to forward the packet and/or pass the packet to the next higher layer. When accepting an MPL multicast packet, the MPL forwarder MUST update the sliding window based on the packet's sequence number. If the sequence number is not less than WindowMax, the MPL forwarder MUST set WindowMax to 1 greater than the packet's sequence number. If WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST increment WindowMin such that WindowMax - WindowMin <= MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free any entries in BufferedPackets that have a sequence number less than WindowMin. If the MPL forwarder has available memory resources, it MUST buffer the MPL multicast packet for proactive propagation. If not enough Hui & Kelsey Expires April 22, 2013 [Page 14] Internet-Draft MPL October 2012 memory resources are available to buffer the packet, the MPL forwarder MUST increment WindowMin and free entries in BufferedPackets that have a sequence number less than WindowMin until enough memory resources are available. Incrementing WindowMin will ensure that the MPL forwarder does not accept previously received packets. An MPL forwarder MAY reclaim memory resources from sliding windows for other MPL seeds. If a sliding window for another MPL seed is actively disseminating messages and has more than one entry in its BufferedPackets, the MPL forwarder may free entries for that MPL seed by incrementing WindowMin as described above. If the MPL forwarder cannot free enough memory resources to buffer the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1 greater than the packet's sequence number. When memory resources are available, an MPL forwarder SHOULD buffer a MPL multicast packet until the proactive propagation completes (i.e. the Trickle algorithm stops execution) and MAY buffer for longer. After proactive propagation completes, the MPL forwarder may advance WindowMin to the packet's sequence number to reclaim memory resources. When the MPL forwarder no longer buffers any packets, it MAY set WindowMin equal to WindowMax. When setting WindowMin equal to WindowMax, the MPL forwarder MUST initialize HoldTimer to WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the MPL forwarder MAY free the sliding window to reclaim memory resources. 5.3. Transmission of MPL Multicast Packets The MPL forwarder manages buffered MPL multicast packet transmissions using the Trickle algorithm. When adding a packet to BufferedPackets, the MPL forwarder MUST create a Trickle timer for the packet and start execution of the Trickle algorithm. After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL forwarder MUST stop executing the Trickle algorithm. When a buffered MPL multicast packet does not have an active Trickle timer, the MPL forwarder MAY free the buffered packet by advancing WindowMin to 1 greater than the packet's sequence number. Each interface that supports MPL is configured with exactly one MPL multicast scope. The MPL multicast scope MUST be site-local or smaller and defaults to link-local. A scope larger than link-local MAY be used only when that scope corresponds exactly to the MPL domain. UH> Why is this written in a section called "Transmission of MPL Multicast Packets"? Seems more like an initial configuration. Same for the below IPv6.. I would have expected that in a dedicated section about IPv6 tunneling UH> How would the router now that the scope corresponds exactly to the MPL domain? Hui & Kelsey Expires April 22, 2013 [Page 15] Internet-Draft MPL October 2012 An MPL domain may therefore be composed of one or more MPL multicast scopes. For example, the MPL domain may be composed of a single MPL multicast scope when using a site-local scope. Alternatively, the MPL domain may be composed of multiple MPL multicast scopes when using a link-local scope. UH> I am not quite sure how the scope works in this specification. Is that used somewhere when deciding whether to forward packets? IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an original multicast packet whose source or destination address is outside the MPL multicast scope. UH> The source address is a unicast address, right? How can that be outside a multicast scope? How would you know? IPv6-in-IPv6 encapsulation is necessary to support Path MTU discovery when the MPL forwarder is not the source of the original multicast packet. 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. UH> That should be specified more clearly. What does "remove" mean? I suppose you mean decapsulate the inner IPv6 packet. The destination address scope for the outer IPv6 header MUST be the MPL multicast scope. UH> Again, which one? I thought there can be several scopes? When an MPL domain is composed of multiple MPL multicast scopes (e.g. when the MPL multicast scope is link-local), an MPL forwarder MUST decapsulate and encapsulate the original multicast packet when crossing between different MPL multicast scopes. UH> When would you know when to cross a multicast scope? Do you mean routing domain? In doing so, the MPL forwarder MUST duplicate the MPL Option, unmodified, in the new outer IPv6 header. The IPv6 destination address of the MPL multicast packet is the all- MPL-forwarders multicast address (TBD). UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest to define the variable and use the value only in the IANA section. The scope of the IPv6 destination address is set to the MPL multicast scope. UH> which one? 5.4. Reception of MPL Multicast Packets Upon receiving an MPL multicast packet, the MPL forwarder first determines whether or not to accept and buffer the MPL multicast packet based on its MPL seed and sequence value, as specified in Section 5.2. If the MPL forwarder accepts the MPL multicast packet, the MPL forwarder determines whether or not to deliver the original multicast packet to the next higher layer. UH> How would it determine that? For example, if the MPL multicast packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the outer IPv6 header, which also removes MPL Option. UH> For example? What exactly needs to be done? 5.5. Transmission of ICMPv6 MPL Messages The MPL forwarder generates and transmits a new ICMPv6 MPL message whenever Trickle requests a transmission. UH> So for each data packet there would be a new ICMPv6 message? Wouldn't that create a lot of overhead? UH> To which address is the ICMP message sent? On which interface? The MPL forwarder includes an encoding of each sliding window in the ICMPv6 MPL message. Each sliding window is encoded using an MPL Window entry, defined in Section 5.2. The MPL forwarder sets the MPL Window fields as Hui & Kelsey Expires April 22, 2013 [Page 16] Internet-Draft MPL October 2012 follows: S If the MPL seed identifier is 0, set S to 0. If the MPL seed identifier is within the range [1, 65535], set S to 2. Otherwise, set S to 3. w-min Set to the lower bound of the sliding window (i.e. WindowMin). w-len Set to the length of the window (i.e. WindowMax - WindowMin). seed-id If S is non-zero, set to the MPL seed identifier. buffered-mpl-packets Set each bit that represents a sequence number of a packet in BufferedPackets to 1. Set all other bits to 0. The i'th bit in buffered-mpl-packets represents a sequence number of w-min + i. 5.6. Reception of ICMPv6 MPL Messages An MPL forwarder processes each ICMPv6 MPL message that it receives to determine if it has any new MPL multicast packets to receive or offer. An MPL forwarder determines if a new MPL multicast packet has not been received from a neighboring node if any of the following conditions hold true: 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed that does not have a corresponding sliding window entry on the MPL forwarder. 2. The neighbor has a packet in its BufferedPackets that has sequence value greater than or equal to WindowMax (i.e. w-min + w-len >= WindowMax). 3. The neighbor has a packet in its BufferedPackets that has sequence number within range of the sliding window but is not included in BufferedPackets (i.e. the i'th bit in buffered-mpl- packets is set to 1, where the sequence number is w-min + i). When an MPL forwarder determines that it has not yet received a new MPL multicast packet buffered by a neighboring device, the MPL forwarder resets the Trickle timer associated with reactive propagation. An MPL forwarder determines if an entry in BufferedPackets has not been received by a neighboring MPL forwarder if any of the following Hui & Kelsey Expires April 22, 2013 [Page 17] Internet-Draft MPL October 2012 conditions hold true: 1. The ICMPv6 MPL message does not include an MPL Window for the packet's MPL seed. 2. The packet's sequence number is greater than or equal to the neighbor's WindowMax value (i.e. the packet's sequence number is greater than or equal to w-min + w-len). 3. The packet's sequence number is within the range of the neighbor's sliding window [WindowMin, WindowMax), but not included in the neighbor's BufferedPacket (i.e. the packet's sequence number is greater than or equal to w-min, strictly less than w-min + w-len, and the corresponding bit in buffered-mpl- packets is set to 0. When an MPL forwarder determines that it has at least one buffered MPL multicast packet that has not yet been received by a neighbor, the MPL forwarder resets the Trickle timer associated with reactive propagation. Additionally, for each buffered MPL multicast packet that should be transferred, the MPL forwarder MUST reset the Trickle timer and reset e to 0 for proactive propagation. If the Trickle timer for proactive propagation has already stopped execution, UH> Which timer? I thought there is one timer per packet in the proactive mode? the MPL forwarder MUST initialize a new Trickle timer and start execution of the Trickle algorithm. Hui & Kelsey Expires April 22, 2013 [Page 18] Internet-Draft MPL October 2012 6. MPL Parameters An MPL forwarder maintains two sets of Trickle parameters for the proactive and reactive methods. The Trickle parameters are listed below: PROACTIVE_IMIN The minimum Trickle timer interval, as defined in [RFC6206] for proactive propagation. PROACTIVE_IMAX The maximum Trickle timer interval, as defined in [RFC6206] for proactive propagation. PROACTIVE_K The redundancy constant, as defined in [RFC6206] for proactive propagation. PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations that occur before terminating the Trickle algorithm. MUST be set to a value greater than 0. REACTIVE_IMIN The minimum Trickle timer interval, as defined in [RFC6206] for reactive propagation. REACTIVE_IMAX The maximum Trickle timer interval, as defined in [RFC6206] for reactive propagation. REACTIVE_K The redundancy constant, as defined in [RFC6206] for reactive propagation. REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations that occur before terminating the Trickle algorithm. MAY be set to 0, which disables reactive propagation. WINDOW_HOLD_TIME The minimum lifetime for sliding window state. UH> I don't see any recommendations for these values. That is typically requested in the IESG evaluation for standards track documents (either default values and/or guideslines on the values). Hui & Kelsey Expires April 22, 2013 [Page 19] Internet-Draft MPL October 2012 7. Acknowledgements The authors would like to acknowledge the helpful comments of Robert Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter van der Stok, which greatly improved the document. Hui & Kelsey Expires April 22, 2013 [Page 20] Internet-Draft MPL October 2012 8. IANA Considerations The Trickle Multicast option requires an IPv6 Option Number. HEX act chg rest --- --- --- ----- C 01 0 TBD The first two bits indicate that the IPv6 node MUST discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data MUST NOT change en-route. UH> That does not look like a valid IANA section. RFC 5226 give some good guidelines. Hui & Kelsey Expires April 22, 2013 [Page 21] Internet-Draft MPL October 2012 9. Security Considerations TODO. UH> This document needs a security considerations section. Refer to RFC 3552. Hui & Kelsey Expires April 22, 2013 [Page 22] Internet-Draft MPL October 2012 10. References 10.1. Normative References [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. 10.2. Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-06 (work in progress), September 2011. UH> That document is never actually cited. Also, it has not been updated in over a year. Hui & Kelsey Expires April 22, 2013 [Page 23] Internet-Draft MPL October 2012 Authors' Addresses Jonathan W. Hui Cisco 170 West Tasman Drive San Jose, California 95134 USA Phone: +408 424 1547 Email: jonhui@cisco.com Richard Kelsey Silicon Labs 25 Thomson Place Boston, Massachusetts 02210 USA Phone: +617 951 1225 Email: richard.kelsey@silabs.com Hui & Kelsey Expires April 22, 2013 [Page 24] From stokcons@xs4all.nl Mon Oct 29 03:45: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 2BB7221F857C for ; Mon, 29 Oct 2012 03:45:27 -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=[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 xYSnb7EII7OE for ; Mon, 29 Oct 2012 03:45:26 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4753221F8553 for ; Mon, 29 Oct 2012 03:45:24 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9TAipeY007018 for ; Mon, 29 Oct 2012 11:44:51 +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); Mon, 29 Oct 2012 11:44:51 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5933f1d47f4f72ec9b3450dcd231ee76" Date: Mon, 29 Oct 2012 11:44:51 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <49c0b45be05cf97ba606deae2b3288a3@xs4all.nl> X-Sender: stokcons@xs4all.nl (viipuKRfRM79S7zAT5HfjH3FivcG7PFN) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [Roll] Fwd: Re: 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, 29 Oct 2012 10:45:27 -0000 --=_5933f1d47f4f72ec9b3450dcd231ee76 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed 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. --=_5933f1d47f4f72ec9b3450dcd231ee76 Content-Transfer-Encoding: base64 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name=MPL-2.docx Content-Disposition: attachment; filename=MPL-2.docx UEsDBBQABgAIAAAAIQDr01KodAEAAKMFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtOwzAQRfdI/IPlLUrcskAIJemCxxIqUT7AtSethV+y3dffM0nbCAFNRatuIkXxnHvveCbFaG00 WUKIytmSDvMBJWCFk8rOSvoxecnuKYmJW8m1s1DSDUQ6qq6visnGQyRYbWNJ5yn5B8aimIPhMXce LH6pXTA84WuYMc/FJ58Bux0M7phwNoFNWWoYtCre0EBQEsiYh/TKDeqwlQsSDxqDB2OONEoet2WN ckm591oJntA3W1r5QzNzda0ESCcWDSBvaD44ATFiMqPzPfmmIbOqeIKaL3Qiz2t0tm1GAB3/J7oL mWNlayzOlY89Cv2pds4ONqcL1485oTkd2XBl9/4P+ohpo+ECV7Tl9smjz3FwPjIchrNHBJqblyAz nBMPISnoru5wdEgJ5+kS4XfkvvjtiiRcOWDtc3h2D1rMUcka93DCpxrO1vu1lh36qIkVTN8v1v1v 8D4j3fwJF05oxv530VT/MXWs/cVWXwAAAP//AwBQSwMEFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsA CAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMkttKA0EMhu8F32HIfTfbCiLS2d5IoXci6wOEmewBdw7MpNq+ vaMgulDbXub058tP1puDm9Q7pzwGr2FZ1aDYm2BH32t4bbeLB1BZyFuagmcNR86waW5v1i88kZSh PIwxq6Lis4ZBJD4iZjOwo1yFyL5UupAcSQlTj5HMG/WMq7q+x/RXA5qZptpZDWln70C1x1g2X9YO XTcafgpm79jLiRXIB2Fv2S5iKmxJxnKNain1LBpsMM8lnZFirAo24Gmi1fVE/1+LjoUsCaEJic/z fHWcA1peD3TZonnHrzsfIVksFn17+0ODsy9oPgEAAP//AwBQSwMEFAAGAAgAAAAhAJs7tcMJAQAA tAMAABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAArJNNTsMwEIX3SNzBmj1xUqBCVZ1uUKVuIRzAdSY/IrEjzxTI7TGRUlJR hU02luZZfu+zZ7zdfbWN+EBPtbMKkigGgda4vLalgrdsf/cEgljbXDfOooIeCXbp7c32BRvN4RBV dUciuFhSUDF3GynJVNhqilyHNuwUzreaQ+lL2WnzrkuUqzheSz/1gPTCUxxyBf6Q34PI+i4k/+/t iqI2+OzMqUXLVyLkJx5fkTlcjoKt9iWygokYBVqQ10FWS4LQH4pRmUNIFkXgvgnNPD8DDfVc/HrJ eA4jgr/pQymHNZljeFySoXCWM31sJhxnaQ7iYUkI49qfcZ10YlRGBHnx19JvAAAA//8DAFBLAwQU AAYACAAAACEAT9UZ23neAAAc2hkAEQAAAHdvcmQvZG9jdW1lbnQueG1s7H1rc9vIkuX3jdj/UMEP d/pGWDZfoh53pAlZtqK91w+tWr0TOzf6AwQWxVqDKA4KpKz+9XsSAB9FESRluSUTPOpoiwIhiiii 8mSePJn57//xbRCpsU6csfFJrfG6XlM6Dm3XxLcntd+vL/YOa8qlQdwNIhvrk9q9drX/OP2f/+Pf 7467NhwNdJwqvETsjsd4tp+mw+M3b1zY14PAvbZDHePJnk0GQYofk9s3gyD5OhruhXYwDFJzYyKT 3r9p1uudWvEy9qQ2SuLj4iX2BiZMrLO9VH7l2PZ6JtTFt8lvJJv83fw33xVvOfuLbxId4T3Y2PXN 0E1ebfC9r4ZL7E9eZLzqIsaDaHLe3XCTv9ZNgjt8HoMof9t3NukOExtq53D0Xf7k9BUb9VV/u1hA eYnpb2zyFvy/OXkng8DE05eRu2Ph859+eK/x4b3J//YbeanZhWAtTnEv3djuvXwfqrtj3Ivdq5Ma 7onz1uHFRW1y6BIf9IOD73QvGEXpw2cu5w5lr3yZyLc0uHHFd7zuOIhOapHupfJHhtad1I4andqb VSc0DlvN1Wc0D9qHq89odTrt1We09w/rq8/Ybx+teaeddmPNOz1oNde808Nme807xYKteaeNev1g zVtt1I+O1rzXRuOovubNNpp4u6tXrdE6aK97u+3OfvZ238zuFjcMQuw13CRBL9VyH8oNExm555t4 weKHq1GEA8Eotfm7SPJ7Lrmwcerkl11ozEnt3I4SoxP1Wd/Jb+rApWfOBCe1azPQTg6rKzsIsLXu jvtnsXv4KyHu1PlXye5Y9yfOz+7oZnGJ7s9z+bNzx3BN2ZvC92Hx5nBCtuO87SU74Od99/hgTq++ fPyonvT1v16rX0fm3+VjPpV/YR9kWeTSaYZya0gztIgPNENzlotm6PRDDDyIdboHP6yXfpc9Ojcu tDRDuXM2gSvPKaMZohmiN1Tmy4n/ImYo7uquxOrpyB2r37KYPek6dZ0E4dc1hunqtfqnjpy+pxmi GYIJzkJhBmUMyh4RUooZev9taBIN83M2TEykms1XqllvtNZYn/zp38AFhjZWH8HQ0AzRDNEMYQXI DQkd8xhmC2ZIMgnHQtmBjBvCHOlkrGunGxmhJSd9CVN7A7aucZQZsyZtE20TbdML2yYStX7aigwJ GZLnYEi477jv1mRYmaedpXaZIFnpi3+CcsOESH+ry8SmNrSRglZIfbR3amjvsIzQHeEn5+6RFE8h HPnq1C+fLj/+nT44fXD64C/sg0MxgXewhdqRlTbJYwA8OwNaPLG29z6Ry07vh2AXbpNggExLkhZ6 n+1cj1MIDCGwNDrt7SU2ivbSxIRfI703ENu8V/cpj5JleB93ZRHoINJBpIP4/EI+7jvuO+675993 W+sEnZ7duBTSkNTzcWhGaEZoRp7fjHDfcd9x3z3/vtta+C7lMK77xqlpaaYb6tD0DKqK0r5Wm/Ct dAdIrYLGogKU0qsfKb1alsWBTQpSBVJ1bLqwUB8uxx01mKaEkAm6CxIpRFcmplWiVaJVwgrQKv1I q+SZlZLERgXyO5DVC9eDcvXuJldcpHKq5hujSjOTELxWChoCFYytQXmU+MWxRuVUalW+TqMwVVAh SHOLFP97K8Y4nXE643TG6dI3Zn2XjVW1CJ5ZqS70BLFfU1pypRWFnKXRTGqHNrK3969U1zinByZG FypEOej94oJboWqsCqJIQMq7SYg9xB5iD7GH2LMZ9J4WDBKaG3p2dLcgyMRQUWcBTxc9xUxcRD8j V+QErnOtHxDn1iYm7Q8EfrqJGWtv0Qg+BB+CD8GH4LMh+KD8/Kv2xVW7BTwgHGM3QIQjHXazup4b m/aFY0shMs9Ke7pBGuwNoyDWKl8u95qgw0QPEz1M9NzlzsaP6vzxW66DCdENLSttgb1B6Y5G70Yx SD1zO0ryVuDCvKD8UBIE8INhw7pa3SBxoDUTAZJ5Q/9s3JwP+2azAQEbEDxHA4KqJSWV8jyeEhex AjnoOa7b+qa05JormhLAyAkM2LjP/N95F1lpmW1h5Dk6wUQa6f1PDeZLqp3IeJLxJONJxnNjxvMU Xhp6byvbg6gMRRif9IBt/YnkRHJZASI5h4stMiQcLpaNouNwMdiHn2c02irRZlZcuTDyB0jvRjcD k6YQkUNt0RtBuyeksky9jEOt7qCqEJm5R/QwumB0weiC0cXG0UVpwbdnVkq41Arwx1mZaKYl2OSC K0oeI7R8e36pDg4z+jh7eES2mDEmY0zGmEW+gAOsvdGRjDEZY/5847dXxZh+eOlUkCCEROtzKRGb 9PUpSGatJier9/Etyrt1grM8/4hxJuNMxpmMM58eZ14H7qu6sAkYrV8+vL+++DsqiT7bVOddfCDt hpbyNrGjoUPrBOhbIoc6IoO+E+ZmlJL8YpDCIOWlgxSKJ5Fp2MKBFaeF/+d5diVUX0WZr5nnG6BT HKadJ2jns/dOBlc4ANE1uvhEABsRX4SjJNFxOjvLWzY6xHSI6RDTIX66Q+yZlRJrXIHES25jldnl JgpoU9pP0+HxmzdSsgrZPmp7k9cyMOm1TW7fdDMYelMAzxtmZBjsMNh56WCHjh4dPTp6dPSe7ugt hJtZRiaD/Ll8DCqiTTfrchGA/vxmBqOBxKLOfFMDdLzo+94TbRNtE20TbdPTbdOOBKEYBL7JlVaU /JR82o1WoyGiT919pRKNpkmhPEKf8nXrghFAUVQBHsLeOBuhY8vaGyG74IreCTf3Ks+0zvHhKcSg fpNluhd0L+he0L2ge7Fhs8bUDHyFSgmdv+2ocopU6YcUXD4K1YIhSiqGiYFLIa3O0BB4ljEtOH+k WhPd08imhv7yEGAIMAQYAgwBZkOAGcDKwtRG64K1W3Sl3HaQKalURKgKmAlNphjVYEczxShGQKJB vVM1kThJ+TRA6TbBJJTXNW+tiDhEHCLO8yMO9x33Hffd8++76km1l/VOuTPolaK/DQ1q3GyszhCO RqrZfKWa9UaLMirKqCijooyKhe3LGu6zsJ2F7T9lYfvpuR3eJ+a2n0p5qCFz/IYwThgnjBPGCeP5 RIN2Z78jnAK4JYwTIoz/lDBewuIrNYP3X8K/S6DeVNIOApO1Rqi/hVBPep2qIabuytw/00UprukZ 9EYFy49nyOpzihZnm7xwR/TqsYueWSlR71RABDuRfW5yuRXNIwejtG8TafpwBvI4CzRFpuR0MtZd csYMNhlsMthksMlgk8FmvXPeOry4qAkmJJdJ9m27gs0saTxxekS3jFEb/0+HqUjJ5jqhS8Q5C0L/ zamP+nZBbEchC4UsFLJQyPJ0yfJlYscmm0ShrjTG+UpjZpijzP68s+FoAMaL5f6MQxiHvHQcUj2a 65eiDVkqZLvWsxZkERLtsdN7BnPH/i46eowTFz8JqjpxjqRwHP1IPNqIHhE9InpE9Iie7hF5ZqW6 5PtwdAMzC4fPxptccUX598l460lUDiL+MsJ4Xw0Sfmz0neANfpg8TU+YnjA9YXrC+i73NdyfyH2j W97JZpWzpTKUTSxwBRK+IcY/yURhv8FPCcZuO+KcvipEQveqq12IyTFa3dtRMsnyirgImV6MlAkF hF0+WhlHhgh1vBuCsQ1jG8Y2zx/bcN9x33Hfcd9lyu6Jo+cNZG0ctpqr75DmQftw9RmtTqe9+oz2 /mF99Rn77aNMhF7+Tjvtxpp3etBqrnmnrNKrtryfeEe8W21nGo2j+hoj0WjCTKx5ldZBe41Ba7Cs ZguUTqe/joz6WzAY/kP9U0dO36v5r/dZKwy30Ahj/ozs8b8ug1utGn8w5GUtDWtpXriWhi4AXYA1 4E0XALPBPyMDgK0aupPaOThdUxzKuiM8Jikg+63QMuPltnGarz9P6AG6y4FPlx+XHldfwtTeYOmk 7pbwT/gn/BP+j7NKl6PGGj6LzJvvqGDB1oXU9frBukWtHx2tYQnJAEyw/kfCP91u/24m4w1JiZ9p oNtNt3ta+JjuupIotV68UFEJUcmnnPZROzqRpEKxem67Gv8MhjaWai30IJah7hgup3qJHUDCOne6 GqDWwls7Yo9vaYk9xJ5YyJ3+WeyMz+/8SJ9vW+u5osClVzruYpJWV1I3bxMdfM3bgpbYK7V2rKdM iqmAvtXEYTTq+l3hdguafjODYZR3yHv72zv1MS/kUykgSdSwEyFsV4r6foPOFcJX1X7Nar41GXNi EjGJmHQOjfx8tQU816IRDOOhhV6ku4U6ebfWrE2OmmtoIRUWqDiRKWxjtG7tZhUWdpSquyBJgji9 ByQxFGLaCVYlb69F+tsEJ7XnF3xvayi087Az9ec9M7pb4INIRpqSLI982MKVBeMsGH/pgnFS3KS4 qWp8fr+O+477jvvu+ffd1sZTp9fBTSTZAKSz45StR5kW0L2U/jP954KhoyzYEwWyIL/aBflbi+Ol QpAG5GqoGEpsd5Qn/1+rx/6nWh7ZyBiDMQZjDMYYT2/C2IRtutbJwMQ2srfoZfBYy4Tfb9M2MZ/M fDJWAE2U0zPHfLIvWbo7dn9+j4ypBdvyZYypkNKT+vF2SX5D7dM20TbRNtE2/eDm1W3Ylk/aOWnj dGGTQYASpEfaKHVA20TbRNtE2/SDbRMistcNz7aUiNMqUH0kZvjy4yYXu+2t9UvoxS/DrJ7ose4x wSev3gtuYH6yYRZekoG1R6w9Yu3R9wTtAj5+X7NKg8+H80+X484O44/0uZsEQpuCkDr0FozZLGaz mM1iNuvp2SzpuAn4YfTTe58kcGzT+6E+qUmjiYpGP/9p4q59XHJAHRF8SLuRdiPt9oNpt/2ci5J0 AGrt0SpIvdX9YGxssnFioOHTdnSM6RjTMaZj/CMc4/2dcopHUYo57wtNH0uIqIq6xpdB+FWn6p1x TkPelw29XwlEBB+mBFh3lI04oY5POlg8ZqYLuIaSBGU+BQXws0sAdI0B51+jXW6KeRmAddKpTpyS lmT/J0iMlLm6EgjiLByCD8GH4CMzxrKd8KPBZ4dy0ugGiU74ZrzT8JPYYXCbBz0lkDPLVhN8CD4E H4LPXwY+fvV2CQ9VDTXulSb2zGHPDGTKHjX8m4M5H+Z8mPNhzufH5Hx2KOr5LTJdE9964p4SpK1o xicXQz2qDpHgw8iHkQ8jn78g8tl/7Tu2Jba4GlHPNUaruAFS7ZjttcMIhB6mWT3IRH6hchFCCSQ1 2JyDgwLY6PSlG51Wr+Ei2v689puSVRp8rnSosypwIs+nB8hTSrv5RZuk3Ui7kXYj7fZjaDffsa00 +DDyGevaqUxvyFsB5AFQ3hmsJO55rRoEH0Y+jHwY+fx4tdv+a9+2VBp8GPmUIk9Z3APwYd9Jgg/B h+Dzo8GnUxTAz5V+lFuh5c802JyDtom2ibbpR9umA9ims/BrbO8i3b3VAxmzuLYuwLdRzbrHr5Mx JmNMxpiM8dMZ40PYpg9nn89k/qszaByUlS2Vkoe+Vcp/arJxEP0m+k30m36033QE2/SbDkeJSe+/ 0z41fRE6/Sb6TfSb6Dc93W9q1F+rK93TiY7D0sYiy7yl2bGmr1GmbaJtom2ibXq6bVIK1gmDvz9n s+HQi+Pxloq2ibVZrM1ibdZfUJsF24TB3x/i3vdaJ9om2ibaJtqmH26bzkZp3ybu39RZt5tARfsd cV3TL/1hTMeYjjHd88d03Hfcd9x33HfoDF4yZLdx2GquvkOaB+3D1We0Op326jM4ypejfJ9jlC/x jni32hI1Gkf1Neas0TxsrrFnjdZBu77mD7U7+x05BfckjK8TaYwbBiHao2HqW9BDV/6TWl3EEpGJ MSCyiRcsfrgaRTgQjFKb/4nkMpHfTi6sCCbxyy405qR2bqEIwIQzif9w9CXnZXDfcd+t2Q7cd7Ot Gjp/92Y85mOa7ct+E6PAfcd9x33H+I7x3fHQwqjCcVvjuR01Ousct3r9IHPcVixq/ehoTdRMP3PO NSXeHY9FzhLp3ixhR17FX48G9x3ju0mkXEZXwnyv8XfIZ3pWhnhHXqV1eHEhDFGCwrZLkE71znl2 SEilLIycMVTcd/AiD1rNNRQh/UzymZfC3062UrG7rt7pXoD2pw+f4b7rtBtrYibuuyVhQoN5hByt JluM+24+itxvH63xiLnvHsbezN8dZ0lF5hFuYFYe3h/UqyyyVeQzyWeuZl7IZ5LPzO8Q6lXIqyxD VcZ3S1wNxncFG8n4btmeYXz3IHFKfWZxozQLJYP781xkoVkYkx9DXMf4DtmNsnQG4zvGd6xHmOcR WQfkR2/MmzNvzrz5vIVgHuEhT8w8gu9nbu0Y29NfR0b9LRgM/6H+qSOn79X81/tvQ4NGGOpsmJhI NZuvVLPeaM2fkT3+12Vwq1XzD7aop+uNeCxTpDcoFTfBSY0lGuXBKF1vut7VKQXeXhfgQ4ya7Fin e+8SlGc/QHc58Ony49Lj6kuY2hsUeMIvYKd1ToEQtTXhnx0JICZnxYpXj0LlPJXzVPDO82rM8DLD O+3j892dQLbX7UaDfnTBThPbHYWpsTHZM7JndJ+xAnSf6T4vyjToPlfbfd5WGI8Cl17pGHNTdVey YG8THXzNxzOob4Mo63yInoZDZNF0Mta1U9BoH+2dGto7sGZB3MVPzt2jl2F6Z5OvTqX3QxMGUXSv 7FCGsWp1Z9K+cmliwlThZdD8MNT0Fegr0Fd4YV9hW21WWmqZPLMCJjextvc+SbDOMEswY7dJMPgt DZK0qHfBE9Jb48ojNrKWrT9t51ZcymmIUddpEhh0ld3kit/H3a2+3pKP28QqtIPBKAbeSPz5Sn4c jtLih4Ee2OT+VYZROtbJ7b1M4x2FfW/J2IjTz+FSYL3oubOA9q8ooCX2bCn2LPXgS6C2osAzB79q ENwrBEdhNOpqlfa1GjmtbE/pb8al0jL+w+W4owZoLQSUcimxh3EPNj4lBi/JkRJ7thR7Uju0kb29 96zobmGPMG4YPHsXJF1Bl4EO+0Fs3MAhuLlOgq6RSCiIADsEHWQhOOFqoXk1Ze3uZWTtBJ0tBZ2Z td1h2JlldRIdGVRU2VhN0BgxEJhIHQdxqOcACc97C0amjUzb6kZkZNrItE0aoCDNUUL7K+WZlRL3 vwJZngJ4NrnaihJtU9oMsOIc1AmQF1gFcYFyoxsXJgaVO4CingpmwY66Texo+NpbNUIPoYfQ8/yl vNWLeX6F7Gmsk1e5zwu/V0gYh6TyxBsW3xiJ6Y8fP+O7Q0bapZBCCWsjmYLYpuqG4ifWGbLOUFaA SQDZCY+ZH0u3+LSHu8bcRL4VLYkCKuoX35qxBv+CbHMwDkwUYDWmylpH15fwQnh5aXhhyMmQkyEn Q04pkV7f7nmVW/cp0zEjkpxqvrNQMjIDk6quHpswp8WyLEwRkUYm/uregAhLs+dIhlF1RtUZA867 HJEYcHo99yUCL+vDL9U2Nt7lWNOiylP19J2Ktbnt39hElGYXOJr2wW+iWtRJ5Y3EoleAG6FDLxOb 2tBGolMj8hB5iDxEHiLPdzC9p1kW6Zery49/V26oQ9NDdsmzqLtFe97YrJGATQRlJKUW23jPpfnP A9tFrPOvq4vzzv5+/Q+yoGRByYK+NAtaPQHANRzdKEjRcFh0SPbOKZhnlTEtkCJBnTShYaCQlR4o MaoBJx50V/cCFAJ6Fpw8MXli8sTkiZ/OE3tmpcQxrIAqNie1N7nYiib/UyvFfw6sDMID9dYm6N2V cS/49svHt1d/z1xjKUPPW21l4CQeM+sx8r5mwQ3i8Ycjodj5hJ1PnmO0ZPV84k2McQWQh/UYwyD8 qlNAzx20zL3EDjLeH5gzTQkAdIKBiNEkLeDQfEtAyrs/GPAw4GHAw4CHAc9muqDTXOLj2dCS6K6i Ac+scEZlSud5km2+8K/A5zzUWdIohshD5CHyEHmIPBsiz11fxzuMO3n/eoGTrIN9JrjVqOPM9LjM LzO/zPzyS+eX6dLRpaNLR5fu6S7dxSiBhjnByACdq5m793EwMCGaO4sfkGY9z3rwBND/DL1ooIYu 5t2EQQzNx9es+bPnLNE20TbRNtE2Pd02eWalhPurQH5NeuVscqkVpTnRxmyiHcz0zXMtzZYwm4JL fXODds9jHfkNsQk8BB4CD4GHwLMhz6m/DXXsYEh3AX1OodX4EM8CGR2PTWLjgcYwOUQ+xYSFHIom PZ0DAgzZTrKdL812UjkI4e42zus08dhGuwEvJU27HVizMOsOEEgnmxg/IJXWtQMTY1wnUmxOpzI6 rSslVMuElgxqGNQwqGFQw6Bmw6Bm2jt/F4KaEtRZnBoQZz0C0J4bOZugC+zBjM4E+DPWAkXonUZV B+McxjmMc/QP7lczHRswHQs8G9yI+SUYnoWSmf8eIbmskFbe69vhlInxzDe9YHrB9ILpBdML3tAL NjHIhAFcPLvLSmbplSUdGiXDLuOy5vPM2fCauWWS+Vl3fpcxog5Rh6hD1PnrUQddDqNoTsoEkYvt vU8S8P6YQKtPardJMJh7Xp7YxoQAqhPvY5DfaCHmp1aXqLuyNZlqnpauyPTZLV2PEvomK7sphLbo dI8UfXpPhoYMjfATQ+tOahxm/0LD7OkR0iOkR0iP8Oke4bVMEejacCQCtFmX6yxc/YRmqSYMELNe zo0UUB/tnRpiDivaqsZd0qMcMEB3ACvAWariGP+o0TYfrXP36vOkyO+XT+jB/0rd9Q0mPSMEGxtp Nv/hctxZXqVhfLaR7hLdJbpLdJee7i557s4Ssqgi/Nh02KH2HbySK64o/zWpMUfFBvAHs56tQd9n SeTEOlfK5us0CpHVSaZZHe8eIfQQegg9hB5Cz4aKgSBem5ERkK0o5ExVw5MijPlumq9U1zinpzUb s5MnQltCD9kYsjFkY36wfNYzKyUxQAVUAQsDWkoutKLIAylEFuUUxX8a09TyQg0JfYrqDKXe3qNK MMMkREHXiQm/Rn7VPuMdxjuMdxjvMN7ZNN6JbjFAN+0PNgHZimJPNjW4We/88SqDoKIUx+UjPN0A 0PRKqtZdGkiOOg1SLeGR0kHY91aN4EPwIfgQfAg+G4JP5tvrsQmlfW6QwuNHQ0OYV0iCZkwTDK+v +t2twEjJyOki1MHM6QKt8chZgg/pNtJtpNtIt32H9usUbv1ipeNuIYugL9pt3aD7SV5cs4fBntL/ PluZCcsW2sFgFEOHK0W0Cu1SgNVEHlbhsApHVoCy2+8wvSX1fkp5Dm2JMa5AoseFwULaouRaK8q3 RfY2yDhHoAoqYPP5aizwrLU6nfZq/qi9f1hffcZ++6iz+oxOu9FcfcZBq3m4+ozDZnvNOz1qdNa8 00a9frDmrbLAkwWe626Rw9aau7l50F5zN3PfnfjEPfcd9x33XS+dxjjEO5f5+cMgFF7g7jhA08Lk pFaXFYpMjNYszfb0h6tRhAPBKLW5F5FcJvLbyYXFkAn5ZRcac1I7t6PEoIz3M9otvnAoxcytDwD0 M6NFSGwc1de4EY0mzMRqv7nROsA2ebOKPWq0O/uZ7cU9mQY33HeXYmfqnfPW4cWF2Ims4dM73QvQ HuDhM5dzh2SZh7ntmawkvuMlxpKhjfScgUe4suZjoZ+5uGDrbmTGd8Q77rs5I0NeZYnlJd4tQBvx bh6YyWc+8FXoZxYeXLPwQNyf5xJWZl5dfgy+cxZ0SlwnDiDjO9/dZXy3GAA0GN/NqJgQzTXn2Zks YH1MbyXuu+VhJvcd910sJEb/DO2M/U2Go9x3SwIE5u987GbenHmEKTNMPhOuCnmVJWaTvAp5lRXl MeRVyKtMs++M74Ai9DPpZ1KvIkl25s2Xszf0M3fdz0RaATTNNo4c+3Vk1N+CwfAf6p86cvpezX+9 /zbE7GGnzoaJiVSz+Uo1643W/BnZ439dBrdatf7wynSYWvFhkxQvKV5SvPMp/Aalc5TOVUYqvr0u wIcYmn0MFdh7l0C+/wDd5YC0BFj69SVM7Q0SxPALmoT/Fbwa4Z/wT/gn/GfFGxNRGuG/MvDPcJfh 7ppKISoJ/wIl4fa63U3M77rWCcamWDQ+8afL0JrQmtCaPH/HYO477jvuu+ffd1uL4qUt66Q781ek 0+5sguGctU+//3Zde5V/V5+/ZI+v3v/v3z9cvX8nx3/79ezjx+mD/AzyaeTTwBQMLURI7Lz0Qp2X ttUyRYFLr3Tc1YnuSnr+baKDr3mDkVKbBSv05fePhT2SRzNLdf7l06f3n9/lxurT2f+FqQrirqp9 ubz+8OXz2ceaTOVK+8bRaNFo0WhhBdgBWOSCjykOBTVeapo8s1LSFbcCHYC7NhwNdJxucrkVbQKM TvNF93kjeelholMMtQ8w+kW7MDE3+AFQc3VxrpqozVYyo0se/OHPgmEgz0CegfzzB/Lcd9x33HfP v++2NUwt9/iEQOtZmcWTTZxBoswp8Q1GDh5A2k/s6LZvR2kWdGIQdO43HXuOE40RjRGN0fMbI+47 7jvuu+ffd9VzAkR3jpHaGD8HIrsQoJ/F6sPluKPgAYAfyAfEutFNTg444Q5SuA74TfoCpKJJRZOK /sFjUJfVwXimprr09ACt9TGbze0yP30L3Blmyc9hkGA1zDAbTA5Oem42eXzr3RF0iOkQ0yGmQyyt pdY3p16VB91h8JFYYApAChOnvurU+Vm/EuQtMqW0wrTCtMLPb4W577jvuO+ef99Vkw6cuQAutEO9 K7PhkQ71QsrVrk7VPvrFDz3tB2nWlATZYIx46et4QhMjWeytE8GH4EPwIfgw9M4HKj+6pTPYiNMn h95VwyP1IVYWaUZ0/ZT6vleSciTsMN3IdCPTjUw34h548sQqgZ2p1++Z1t2KfPIg1/YyUUume3mn XWriIDU2VmfdLvozs+hSSs3KRh6x8yI7Lz5H58XK+bjLco27QrfZ3g5jThBn3NoUfotkq59rJbFG Yo3E2vMTa9x33Hfcd8+/76rn3gmr27WDANLV6deZCm0c61B6LjidKgSectq0BgP1FZJ66+qeidGn gaxn3lIpWD4YjKEnQ0+GnufI0OcD4nLtKzyY5DLJKJvSfj9TgzT3YJOIrAI9gPS3dLc7ABVkZwZP xjmNDtk52zlMbAi2E32zz9ALwLsd6BXTK6ZXTK+YMo8nyDzg5Q88q7pbqTbgTi+ytovWplG0GPYg SMppUW+BCDuEHcIOYYew8wTYyTkoz67uFvDcGeBNokNtxlnjkiVljhgVRK6NXFtao8KQCsNnUBjO 5QZkdMmi7MPEwumZ7kk+vzEYpX2bnNTiaNzotA7qcpd20RZDqt0bzb1Gfa95dN2oH+8fHtfr/1UT 6g/K6ePEme4VXqJ+cLZ/eHSYH8+ZweTCxqn8jcCFxpzUzu0oMbPxcS/RXF0UiaFNoLcb2rjrwRXC AKyIXFZXR8XCNGQRnrIwl1jQer1z3jq8uJDXktV6p0Gob816YTGuwWYuJ3lv8tK94pxTWU9wwvgX R2QlZ7dYc+OVrB8dt+vLb7GjVr1eb/38t9jyxVJ3Ju2vveVaT12oFbfclqzf5HYK7QBzc5DEzIVc k8MP7jI8UezX9qMWr/HwLqvM4pXcgkj7RmJ3iz0qO/vhrk0KQ3XlrUZm8H9mw15yyRY5biDh4sYb yvUMJ1f60Er7F++b7mIfTX75ne4FaKr18DUu5w5lf67ImAU3Gc6UiZ2PGp01fMRhq7n6jOZB+3D1 Ga1Op736DCa+K5T4ntnI/e+wkVnQ9hO6c0LdFiZpshkrYbPmEuZzDz0TVsKuVCB3PpUsb3K9FR2g k1UMLVz/bAt3vmMLZ/C9dJMsxbafHe0LZ7AE82WsHQbcKcQnc05kTskNo6zKt3iBRe9HLMr3eAZX dAJKi7c67cYad+Wg1Vzjrhw222vcFXhN9dUOTQNB9zrPqn50tOa9Yk5Vfc2bbTTxdte8l9ZBe93b bXf2s7eLexKuYuYyOrTMk1EaYCV6aJwN/1JMQQQdJ2gavGDxw9UowgEQFzZ/F4VU66dG8Jl5O6B5 W23e5nyCuYdC902xU2UIkhWVlli6Ofpuu3ym09ceMNJiM32/xtbSYs9Y9ycX9U9iLu477jvuO8pm ni6bEcfFafD8c19nvnYvr1i60beSUULF0nyffhvTHwCXXcYmk8atEI37U0dwScEk+amTn51JKklt z9mi+YeeqakuB1tU6WxytRVlYKGjXyhPmheGHG5MUTSQZX5covnibeeodfbTqxwmtELWZ0RulMkB eeypQKplF2YUSz6+ApVskHX+sBQzieRyV4ZE8li87Uj35jSkJJIzdntCS2wtrVmSypp3PmaPNwHm CqSCJSrc5FIr6oMMgntJYXZNr6cT1JNLFBxn4a+DlDbU0tmD7TtWk1AMfx8gBunwv4AOJ+4MkXK+ TYJBBXDHJgZMYxDtMvZMxsSycWSNWtnFoIMyGROc1J4/+cOkqx/90rujd8fmbN/TnG2adDVdRJam J4WZm7g7FfDuzvyEcUkWp6KcwtzHnXUBHcXmv0c6ulfTJ9CWbcrpz1eHURc9R7sSeAg8BJ7vAZ4Z iT17tCPAM+3AvMn1VhR/pAgefdgMGkOIC5L3DaKiW1QyVHCh3P+k1iC5QHJhdVKnwQJ4TwTA2rft rn2rlkJK7QqRwDTRXMFhroZDW/dYZSMuF3VyIl5IleGcS7p6Ip6lq/cS/e+oknufCNim9xVSK3Sn AzZ2Wi03ctIZAaQC2QRCDCFGVuAlIYZSBUoV1rA4FKJSiArdbNEVs7QAQvIEs2hyk9xJBUQKs3B6 kwuuaLJoBZGAEacppp5SrEB16gMlAhNIL5NAYg1EhViFX+1w7+Z+D9/Ul2FqbOyH1bulmlP/2dex 0tAuwGObFN8lHjIz3mG8w3jn+UsiCDoVAp2udmkxKdpPFO4W3ASJRuH3PUYUZdXefgCcdXZ9Reyh Yo5p1BfmuIk9FcKexU4auwU5PsYU7KPJ6DVh4fZMvCffCTuEHcIOYecZxpd6pqbEGFcm0bPJxVY0 yZPpQhfSOeoB+6iMX7VLuo10G+k20m1Pbz8/K0OdPdrEHFcAe3Y75LEjjNDKixX6OujiscyN03EY DN0owuhziX68O4GgQ9Ah6BB0CDqJ+qy/LwY8ZdXcnJpx2kM+Exjc2LQ/kRcAi4g9JNtItpFs+z5D W6qnnoU5s0eeqaku2UZ9wVjXTpXoC4pGPAgBs0Y8M4E99QWdzprpzez+9kBzzVoe1vJsUMszQ5zZ ox3Bnt0m20Rf8DCpU0w4MXEYjboL1esk20i2kWwj2Uay7QlkW9ckOkyj+00wtqL6grlAZ0I9PiTg vPUh8hB5iDzPjzzcd9x33Hfcd+WtsNn417cQbPy7zY1/iXf+3UxanbT6cwxV4b7jvqOfST+Tfmbe hvuw2V6T8Kafuc1+5taWqZ/+OjLqb8Fg+A/1Tx05fT9LGuPR+29DsNtOnQ0TE6lm85Vq1hst7xT5 4V+Xwa1W7T9I8VJNSTXlC6sp6XrT9abr/fyu9/a6AB9iVOnFOt17lwS99AG6ywHRFi39+hKm9ga6 PPgFTcI/4Z/wT/jPQ14EtGtgiCMmOWKyVpcpKpGJ9Umtuc0MAN1uut1r7B0LOFjAMSvgOG29VurL WCdjo+/oOtN1putM15mu8/FYqhE8x5jJMyfjJh06Wcj8zbtjsDQ6OamM67y1zFlp/b/QZV0dGaC7 Wz6r26mbezUbKyufK6oXByq1i6PdQzsY6Di9CuJbnTVEww1guie1o9zblFm7iTPdq0u5I+qd89bh xUVN7pdi6ltygTleTu4aFxpzUju3o8TMHLGXGGAJVcBpEEXCKtLxoeODe5Ozyl9iHwpnkY+G3E4r EgUuvdIx+grqrkgQ3iY6+PomG81capo9g1PdNiw9m9wFCVZmccjLPJygHNEHk2FibW9xfvvDokUB moOLztFB2wOa39L7CF1Pcg/uvIAt3cOnE4da0Ar3WwFKk3cxeXb+bchZGX7h4BYiW8mdV9RIBnGW S+vaAUZrggDIPIXpdHnMgFMyEUDh4xso2/NuVjKMflhALftioNQgwzhzbEPn+7oZLrg/J/apWc/9 Z/fnuTjHWdSZH5tYKdlv24yOaYklUosRxlKrX4Hey73IWr/DYwneP0S47Qqmln/QQJezHG2mzoCS bjAeqJSsSAU+/ZvEBt0QHuKbaeO1Ta68mvcC2mxnrsbypaBnQc+CuUtKBp/eB2gTC1sBbMl7Sm9y sRWFEwx2QHiajU51wUCrYf/emTCIMEMIqYleEGqFUPaub8K+Mqm6C5xClyQNQrzrDzkn9BB6CD2E nqdDz+9OkmhQEn7di4J78ABLAgCFrJO9c5krjExbERfNepV5Fp2miaaJpomm6emmyTMr1WVccq94 MeG0lF2sqFssSR5xjfW3YWRCg66gynQh3jC9ewGnWH9L9/p2CG2IS00cpMj3uClN590lBB+CD8GH 4EPwqa3P1ImebJrj8MxoCdhWFH4kuxNEzi4NfURpMKX/VYHVCmjlLRhxh7hD3CHuEHc2xB3Mk9SJ Z0J3C3OmhL8T7fpM0a6z5MBAOye9oYIwsc7h6V4mB0wzns4xFZBpVYObiQDJK3uhvo36tufo1QqV baWUtoWo1qJvXWxTdTMyUVfZBNon2Cr8D3ntzA8uwoas/sYObWRv72HHPHtOl5guMV1iusR0iTd0 iQub6hnR3XKKZ/hS8Cz0dOnp1uBlsc7xJesc6cnRk6MnR0/u6Z7cWXyficimWaesssbEJjVBmlNf MypMqjqhggjBhUnXByctn+Jbzz2iZaJlomWiZXq6ZfLMSknUVYEKjGCXZWZFMZ/TuisaZinuK5+7 rNR1X2dglZ0vGgHrJ6wIPgQfgg/Bh+CzIcEJG7oJzFZUZZYl1fIYJ6v96+qxQb0fSvwghVAO7eWk +i8vDnwIS97CEXmIPEQeIg+RZ0PkydNJng0tifG2HXxOURfzn30dZ6DyEEYKAfO/uQngoG0atMxo hJohk7dCRBmiDFGGKPN0lPn48fOrzCBJMcWUTrnJnWFw+piVikYXsEM6gfl6P4b5Mr15eoZ2ie2O KQPACrykDKB6glfPrJQ4hBUg/aeyqk2ud9sd4OVNHQu/d87rLRoLC/cyhaeChBGuv2cSxxI/qs+o PpMVIOzITnhMF2TUVpdYot3pI5z30t9h0BFwmYLvBIJQ7ifHp6HQKGvA9eFy3Nkz8Z5891aMLAxZ GLIwZGGezsJ4ZqW60U46imPMEFtQipZc77ZHO0L3v9VhMHIFoqTQ0S580JioBhdOZp81sqnRwQjd tjD1LI7GjU7rIDvWxa9hknS90dxr1PeaR9eN+nF9/7he/698VA1e4OFMmeLgO42C43r98H3joNnw Jtv8jCPUsBrX6CdW4pwl+r9HJtEyOS5TyhVn5zN4sn9xRHzBatX+LtwxJpbZHtkd0xD3f7M7prH0 jpFb4+Jt56h19tPfGumpiUPMwnLaV0nCBcOKyKeOD3+yMM2nLow3K8PfSluyXpPNcZvYbBLz5Ge5 mzCKCv8Wm2Vu2VobL1v98Hj/4FEW6KJeb9SbP/1tNlmmXTIwwrZlYU88GtygyTBndOXz9tjDxGLe VKN+dNRkkMMgh0HOhoKmIEwxFGLBbdullsET+sy9Qk+sAeoH80nQaoovU4JNRmh0R6gizPAnGNhR zMQOEzvih7KtABM7TOw8Nq91uuC8V5RaK2GInDBsgJIg9SvZHTI9Lp12S2PnGkIMIUZW4CUhhslT Jk/JK5BXeDqvMJ9kS++HMrQRU2qms9LcbFpyPiZtblBAUdTpBes0TDRMNEw0TE83TJ5ZKQnFKqBh l5L5TS512wUdJVHndFzAbD4wRIT36k4nejoi+NViRBrgych81ZHfd4HgQ/Ah+BB8CD4bZtsWJhuU oGxFoacYQC/luMtmoamBBcqAD0UztTjU0CNez6vb0+D2gZhqKNTgsJA8XYlArHPeOry4ELaoVGV4 9U73glGUPjz9cu5Q9sqXEB+h/iK4yTRb+I7XHcvN7s2JOWp01hjBw9YaUULzoH24+jVanU579Rkc V7P4wTQaR/U1y9poHjbXrGujddCur176Rruzn90DcIgmd4tD4C65ZIgeeyhHx60ldyXkxCKPxQsW P1yNIhyALtLmfyLJ77nk51O8irNXvDm894fbS7bKz/vuWUZ1qoOwv8ORT2kPG5VpCud7ehYzow30 hUHcVYG3agx6fPgj7hB3OCbtXAodMt8wH5cMK1GAYVmFyM6U7zqUwmh49J4V3a3QJxcTFiHNZD0m EkOoLcdAHIe5eKlNgwjtobs6Ed9xQR9D5CHyrAlEGPHAZ/us7yS8ClEQcI5uuOLGyaGsUOIxrRcY 8aRFULqdAd/pMppJhiA7pwcmhvyuK/Ng5pso+Gq71SBFc0xzTHP8/NkP7jvuO+675993iGi30w8o kUIUc8p1D5y8BF+xvlPSNUn9aod7N/d7+Ka+DFNMj5v1nJ3+bBVK/KNR149qaZpommiaaJooiNhQ EIEIbc8NdWh6JoRFxTC1QSAWVwWRleTppNtDafKGAVuZLIGKgQWdBptDOBOc1Gidn26d3yOVnvuK D7tyTgo652gmN3EW89YBMHpeLoReI71Geo20S0+3S55ZKWGvK1DDkUfhj3H9KsddTMoIJXlR6hzP pnOJjKnIc3j3CKGH0EPoIfQQejYkLGTomGdBS1C2ojUcMtFm+fzhRY4cDWxQ1o6xxN0u0uz5rAJv 4Qg9hB5CD6GH0LMh9EzcfM+K7hj8oG4PHVPQHi1vi6J0vJeN+xRprUXSILJ36jJAi+hP17+L0Cu0 Y51A4mW9RSP0EHoIPYQeQs+G0HNnk6+eBd0t2EGFxlAn0X3eFwW1LMHQjSLoh/N8zgSYH45oM7G3 asQd4g5xh7hD3NkQdwJwTX2deEZ0t6AnE6T2dYCKwLxXdCE7nSoJComqnwwj0BBoCDTPDzTcd9x3 3HfPv+8qJ+9Qvw8hgs47pkkngLw6ZVk9q4JmWv6/C5Iuzpym4TyfiXaJdol2iXaJgeeGgWdhUHc6 9BQBB5jPfEIgZhSkSRA7TMibCAkf0J0e5HgzjtvSj2Oj4c9VH9ZbUouapzNlASdDfeWxN/u4WsW3 7KlXtJbFxnjYUpY99dhTjz31nqGnnomlb5/pYnT0/sYY1Wgc1zsPB8pL9+iLt52j1tlPPzk+PS2K bhfErMAcrEjW+zqxtvc+EdDBlCK0KL5NgsFU1AqQmixb56nLdim9kRcad7/T2P9bs5oTyM7mB+cr OjlUcRSfDUlOzUCaaORlJrHqQYrl1E0QfkXpI8S/0tQ9a6WB9oYJGhE/GDpNhoIMBRkKMhRkKDZk KAZ2ofdQRfPip5D2fojzccg6DtBHGINCuvqVQIrw4VOmRt2Mej2duIw1j1OOqsr6nZZ1B2GEyQiT EeYzRJhbStudFtOadrnYcVm6NY9xgi7KSlLjsr6BbjQYBCgysT1Cz0mNbafYdmrWg12jVuuMbaf+ nLD8+XCQu2P3J6GnbF4Koed06YBEp3qJHShh2rJ6enxHFCQlj9D9eLlXkmkk00imkUwjmbYhmRZr c9u/QR3fgiGtKKdWIkLx6DQUmFjV1RhdilEpWpmeyH7uVT8Yo6dLjC4w+o6Yk08Hnjh33lRgEmwk 2EiwMcopjXKmnYM9M7pbiJPLHjOosZK8QSvLouhBs6CRAkGRFg0txvixdfsLcWhkEsgkkEl4fiaB +477jvuO+w7q6+BmKb/QOGw1V98hzYP24eozmKtlrpa52u8fEI7defrryKi/BYPhP9Q/deTAkM5/ vf82NAlEImfDxESq2XylmvVGa/6M7PG/LoNbrfb/8JgAugB0AVab70bjqL7Gwjeah832mldpHbTr a05pd/Y7cgruSeBRViDkwN1IZwrU9faQJEC5jkTrEXIFJ7UmXrD44WoU4QBKf23+J5JLFLWisvXC xqmUXgUuNOakdm5H022Ioy8pG+G+475bsx2472ZeQwh6bn73Zqpz9wjBk+y3wihg5yfOdK+8ksDM XPy0VkNcgA8xDGCs0713CWzhA3SXA5JaXfr1JUztDVYTfkGT8M98KrYAGW/CP4zqUSNzucgA5BsC fuwaRxYLts6PrdcP1i1q/ehoDa9Ct9v8BfBPt5tuN93u52e8q9c6c0HG6MK+7oKFEP2iSSaDg34J QUAkNspaVnSD/8/eFza3bSTb/pUpfcgmFUsPACmKUp5YpchWxZXYVsnam73r8gcIGIpTBgEGA4qW Kz/+dg9ACkMBJG06lAge791Yorm+4QjT5/Tp7tOZ/9PU30xrlcQaXBxcHFz8iaW45sUmK6zU9Po1 YEH3WO92Jz2v2r5OVfCJYMePbmmwIBsMxYeri/OO53Q+8ra6/E9pQ7cf+uSMdCetRwNsGGwYbBhs eNUJrojmrK9kTFtiZMjF5F/JZO1TbgBTM+wjhBVwmotFhW2xofWrfOSZyWG6neWImp832fDJlJxm 84lhbSoSNOH115hR6p53pWpJk1601E6Qk5+mZ4jKswOJBXZow+daPooST1mUQCK0nbG4x9vrbGZf A7QNRR0/lTwpXO1n8YIs+zKa9wrHAYFNLU4jF0IuhFwIudCquVBWw4B3JuNJyJyOV4bucLbj5/tR H7IaqunwMhsCGi2CZDiKyNlCkw63yhk1QJCdyY2rfN6CiwB3gbvAXeAucHdFFyk9Ho1o2of7B74i zDYttx/KYODHSg9Na0U5q8utC7WMJO3/IDw23oWcGv4L7RZQGaEy8glAZeSb8DXzI9QgvesJHyU0 w3GsAp/D6g5DT8rVKypq6cCnxosoufVN4wUdTEQlrgk1YZCjYaxVdn9gnRIyHWQ6yHQ2n+ng3uHe 4d7h3mHGDTNuhAWwlpiffZ92PbyUfX8cZY8X5V6WXuLEqZikn55knXkUZkstr27MlsLSxfKcwL1r Hy8ZlO603SVz0kctb4k7Ee4d7h3unexnM+37EPfu0doIWJidUN8+uaoV7hb1u+NYT2GnJOgq0FWg q0BXga4CXQW6SoWnIPI78EzwzKmN1zdbdoJngmeCZ4JngmeCZ4JngmcamcqqrEHPZOXOOhKsZLBW onKzb92WWOaX0DMf3yrsln50qbCSAZ7Mud9Vzb40bEObgyF4oWMFEfrESrV39KvkdWabrWL113mr e3HBHRqPdxNNX0R/Zu2eUvSJPebvLlbumT2AyO9uKII8fj6Q3yG/ixlxBmc0rWrv16NXv9vKPdTv 7JwI9w73Dveu3I+MLfN2hMCOOax2LqeDmL9DfveYvyO/O0F+h/1plKpgbcBTGnohv7PZG/I75HfI 75Df1ferIr9Dfof8rhwhkN8hv0N/ZvlGtDqd9uKpF/BM8EzwzPKdQR3BzkTBM8EzwTPLEQI8EzwT PLN8I8Az5yfnnOPjJZ6DLuaAMAeEOaCZnyB4JngmeGYZVcEzwTPBM8s3AjwTPPOBNKJfRZ/uEW1a rPBDz4SeSas3mGdHKpZkzgyeCZ5ZRlXwTPBM8MzyjQDPBM8Ez7TcNcAzrePAPiDsA8I+oDJmwj8T /pkpfNpLLl3w8bOVFxc+fvDxg49fKULAx6/CUsqFjx98/Orn3sAzwTPBM8uZF3gmeGZeAzZWJuT+ egGeCZ4JnrmkMQI8EzwTPHNmfYR5hIeSH3xrKxJz8EzwTPBM3rDQI8c8s+7LwIephBLfpEj6uJEI dXPUzTuHpkeXPO6mWYke+YGKb+mJ8fuZTNGfeYW9JNhLMqOiHrXXLEnesJfE8q0l0YdO7/HaH0aq 56sKUUDs/TZW4gd/OPpF/C4jLe9F+derzyOVSi3ORqmKhOe9EJ7jtsrvMF9/uPRvpeh8/P8cYnv8 z9T8c2SAenowFGWdDlJeg0J0Jo+5CkorKK2gtILSSn2EQAvP8y2tbC8FeB1TDhTLbP9lSunQI3Tn F95c/lH5ungXZMkNCXfECzzAP5z8ZzkEHHiUf7p3rYZEn9/KibhKhj6cHsvgjsloW8+GAw8mozEZ XY4QmIx+LBJgY5S9MWp7aXf7gHi11Jq1s4skHfqZBoMGgwaDphOAtxC8heY3A2Dmu9kz39uM5K6F 3NSdkiZJ/1XKRcHsfkSuT7epP3yf+WlWdPDQH2xjtZApy+Ufq3zYV3G41R9VfB5GJ9wnQj+8EdVA ZXon93ri3ShTSWwdAHYn2joGdtrMIxe8xqfGBBT20NtbUfpHb68dQ1DoRKFzPOuF+B5Rg4hYDaQL cT2QpsKZg7tQWgR+Sv/fQ6Fi4cfi9eVdR/yWjPZv7vfpt4IEaDGQfijTF2ADUG3oEcUG86dUbbY2 e6yNSlZYaW5KqYZDGSo/k9H9Kp+4oXllP4miZMIzCRmBkQGcHF0o456Dp4Gv+U3WYSEHtfkjclDk oJvotgHqbKmQOYu3VhitQdnGYg4XnU+sEwCQAEiWjH7BqABGBVicyAtdTMaPts1tbttsHoGjOQ2n YlbDrXjNq3itBToANXMa21xMcTzNFEdDw5IrPNESbXEoOuJIdMUxhaqVX0NgQmBCYKITQJmFfSX0 FzoKMx/hOXnGqr/UrVFbVPyt4EBzL/28v+Q/iEyITIhMiEyTaRzaVGSyAk+NeN2AruO/RVXfbc3n bahYf01t5ELkJyFe+pkv/pCx+Nt6AiDeQ7yHeL95z4UmZutLKO8ySrz/MyITSDFIMUjxdyfFf4v3 4u83xISEFWIq6KAeySgq8d+mTuWl+m6lo5hR48qDmP3pllqZ1jbS8qOi5V9jGQdEoQ2J5t+0lOG+ CsWPiZnp86Of+FX6BVLN+lqdozpaK9FaidbKb1OaQarrogoGIG3pAgOQz3cAEjKb/ayCEYARbIIR 4N7h3kHehrzNWyLW6/koBv3zmlqe9Iv//Ef8mCXiRoogifsqpalUcXMvXp+9PfvpwJJXEIcQhxCH Nh+HcO9w73DvNn/vmlfetuC8onDUELdGojmrfNKGFn5mTVIFwaN+qdtsIJK+sdgoKKB5U1/JyHg9 JUEmM80ml/9+f20dHbAH2APsAfasn3sW0cj6zQo1zcWjG9u0qOaDNhSOtMwE6QtSkXcT7UsTSSra 0BXQaTAzEsCwrX6aYVtwO3A7cDtwu/W53Y7wuPcWec2/8fZvVCbGsVa3sTFOzuStTG2Cs1uET7wO ZZwpEheMX6eIpvqD9ZQAfAA+AB+Az/rgUxGUl05INEToLlr5rcDaULDpHZBnjopDFZBlNgOLT7IC WUZPpxloeYFDOwtC6ywAMgAZgAxABiCTirfy2yYSe3Gyy9VUFQfROMxX4jDe0BrAwpTjgCzcbEAC 9mB+DqPfGP3+tkBbO8e7wwnO/L6XhiY3NT/6Um7jC7dTrTQKD7AD2AHsAHYAO/QMrL1mlxwgejNa b4XW3QKfKoXNF522hULW+UBtg9oGtQ1qG9S2NdQ2FZsGAiuwNhR4qKTTmlPQ5ks6lPZ43X3rMIAy QBmgDFAGKLMGylDPmhVUG4owNbra4m49AAwABgCzeYDBvcO9w73b/L2DzQHJxqlW4dVlerrnOJ3z VvfiYo8n9NLL1Pz2/DwZWaV+U1EYdo0824/8210eQajsFKWdaWNJeoNFfAE6AB2ADkAHasIaasJ0 yYAVWXdLUqDxA+qTNfL1bSp5RCF72L0Qj4c35H3AFVXriAA+AB+AD8AH4LMG+Ex8bQXV3cKdVAZS 3dF4Qj9NhgZ+eECBG0ft/A9QA6gB1GweanDvcO9w7zZ/73ZP1MbSR5LxM9oWfrpnjmJmp7hbSx/t msChKQekUsvUkEQ2/C1sfnnjQ+HN+EWmiYB3wuI4jW1P2Pa0iW1PzUMuOyTl362Sspc2GG/pal4a JAqSoYpvV/m4M8Da0g9b02zHesRwHGVk3EOa+MgPPpHVPJVhxWSgggFLFvfCT22HZGRNyJoWo7Hr HjvdJW/xul57yVtaR21nyVvancMOv4WeSVriqrkfRNNTTJea+KbfzyQ3jbCZcaRi4p4e/YXFN1fj iF7wx1mS/794vt0kfN+KVhf6d9/CXpia2FOFPGJXzOF227fH5DS8zoTznDBNRiNI4osjHRIcJDib SHBA7kDuFkcikDtF7UJs2EdsbG1Di+aSu1Wy6gaICGivK/P4rmVAQkJCbrgvyrbzcw+GijVdJBWe 7rlHfKUoJRsklLbF0Z3baR2ZhC2knj1er+x6+66z7x1fO92Tw+6J4/w3nwSY5kU8IXDhOK7jbcGE QJZkfmQdBgUDOg1OYkMZTQ+lu+6hWIMTxUm9lESntuas6DSu5eesl8rIz6ihhg9t+hp/TXMg+Svm 9xEf4Kj8SBRDI9OXqg7k6qXs+ySElWZMirdfll4yf3Oei0/lBvqd3kjjC6c2cTh2jTBhdInKN7jd lrcYab2j9hIVpdXpLBFRkDfM/2DAX8BfOGYU1xjilGdE1tKR9JI0lOluF0ZoIW91bWTWyqmTcRqg MsKQWIeBAB+AzyZEK1TlubGqIWtz1HRBmb0tZrcmB27up7tzMCkAhGEFYJRoUkic4+MlSSPSm38i vSF2DFmhn80eRDA7MDswu3NWro309yiHrpUVLMG3htQ0oiwiw321yxSuXBb5d6z+GsvoXszIbb59 dzoOatwHqFqiMkWVDvvUAD22sA7oAfQAer4FesoRafr1jsBRqLSW1OtP5cMkXuUzN7Tfn2Tt6Z7E +bZ/mjy7HkDPhtowS/KgNmjln+5hPhoWOGtY4Gj1xY6qNUlfcxGntClxursrFKRwMxK9F30z9mxh MlIepDyLW6OgckPlXvyEoHnOjiGu4xwt60hEdQl8z1a0aZz2y7dIDZRJincjTrbFSz/zRZF3Xqcq +BRJ8WY2cp7kbzKzgG/fXYtg4Me3UszZBoIQ2JcZGig0UGig3xKYrDyjJhNrQPmNUqtVPmlDc86q zl1BJuD9JJ341NvMLltvk1ByEc7PRJgYe/BxTF3POoPV1mJiDewB9mwCe8D5wPkWRyKIQBCBFj8h EIHsGAIR6Pkti2Oc41lE4J39rIJngmdugmdu7fBY77exEj/4w9Ev4ncZaXLqLP969XmkyFpanI1S FQnPeyHIPqNVfof5+sOlT3Lr0UdLLUAoQihaTKxAvUG9Fz8hoN52DAH1fr7Ue3spwGsy2Epjme2/ TMnt+BG68wsshlf+ehdkCW++ZFstwD9sLDBkTCcgyQf/7InafkG7bciEAgAFYBMKAO4d7t3iZAbp 7j+R7m4t7d714f7d7i5a3MRKk6YB9RiZ4ZZ8n5IZrBzrF8ixkGMhx3riHAuYQz+ALdwh1fODgGxp d9uUNkvEh6uLc6/dcT4agMkGqZRioG4Hwnj2ihtF6/uKYYti/uKatu4CegA9gB5AzyRPc/UXOoqS b9m3TnlZYaW5wxTDsc5W+agNnaZ4WEX+L9qs8q/cJ8aa7otkfJsNeMLizk+VfxNJuNbCRwY+MnwC KCiRbzGW4USy5J5Lq4+XrO2hA1u2+hjz/ElMyQ4tDNOBUqd757SPo6RSP+W921aRIaLi95XkMUgZ cl/or6n0P9F2bdrwUSt586T/1OBnXGFz6semA4XfIiYqG9BueZKPzWthMvRVDKoAqgCq8NRUYVtD Vn1g+nMg41lkotTE9bq5PPbj+9PWTy9mUchEpjdn/yvGmnxHYvH68q4j/DCk5nltZX1oE0CbANoE 4Ia5vhumFVaaq5v5WqvbeM7OvubjNlQ7o4pNEkuuyHBhhtchp30/mBqPECrllHmOGVvPB2AHsAPY AewAdmgB/LR+tcD6q5fLClYMbSjo9KgW88aP/Vtqi3hQWWY7ZlJCHG2srQrhRQfJyIARyTDIbSC7 QHaB7CLRE8CB4CtbIghkgvFQxjvRF9CDRA+sAFY8NVZACIAQACEAQsD6QkBes6eNpHEg8/07QpLx 8U2k9IC0SV9kSeZHeUs5p5YkX1qWylZujbCEsISwhLC0fliywkqNZNcAb/58KtTW32o+bUOrYv00 GZr+C+0P81YwbsIoGstnO7HNThgVB6nkRJvfbz0gwB3gDnAHuAPcWbEupmXO+K0oumPAw7tG/8Vj StGYCmGxkH4wELGc2PmNyCGaIIe2wyhb4wXsAHYAO4AdwM6KsEOGOFoOVexncidyHm7KeD0cRSZr 8XkFphYmleknUZRMTN7zXtKYbCTejodkwGrhMeAF8AJ4AbysDy9nKU3bDWWmAtqmK0LZV9SKTS3I xkLGPe56H8WER2RmCgsr/T5NzBR1AcOREZtgHEMjtqOEhrhdrAfHenAYx6zum9NLbG63W1pLkAxH 5AZDoJJNkjlY0egoQ0cZOsrQUVZQC/jDwB+mc9jhxJcEEOpE0qYnm2R4xg+yeOnT4OTpnsMXJqI8 5nTPa8++uRpH9II/zpI8cU55myb5GWDfkGWIExCFL3vkGF+Xr2x7r3WBuRhn41SK8ShkmY/6x0jm otkjPZKB6qvAyGBi6N8XeSj7KyiWxkgE63NNxlYGIYJBBIMIBhFsfRHM0q9q8q8GtJTlpQXCylU+ b0ObythVbGpEZjAFOSZyTOSYyDGRYxZm38gxkWPumdT42WbIlPz32gf2Otrm0jbuFDl/Q36DO0zb uN3/DVktkt2sdQrQAKABQAPYvAaAe4d7h3u3+XvXPANmnjJndO8n6YQ2YsqUHZZ1wXjygYsc9029 wA/vZJop8mBWMf0vhqZkAEaA9jO0n9EJYJuFKQhjb9lXrG3r+TfJ2B5eq0mlG1oRSGVAg+PRveAv 1B11P1suJsWUny7mzvNMnN8C1AHqAHWAOnDG/AbQ7Q0rxLzdwp0BzdtwNXpWlecUiBKaEwALgAXA 8sTAAoETAicETgic6zcXCiEc+u/8L3f+Bfreq3itBToAOgA68MR0oHl1Fwo1jnAp5LREWxyKjjgS XXH8Na8hMCEwITAhMH1nAUyIn/fX/A8iEyITIhMi03ePTH+bBO36nvbjmV/59+dJaH1v/uh8IINP ejzM31j8829EJkQmRCZEpu8emdZkTPs/IzIhMiEyITJ998iUcySLBn3VN+BMGNDGgPZTD2g3UQCn ls7KX9z/adGhmsakBliC/KniMJl8WOXTbnv7b889OIg/Vv7A6UXYgABlgDJAme+96J4iS13IWfF1 RCZEJkQmRKbvH5mgGZKHLCk+xqvdsj3yjtrdxd2frU6nvfgd7cOus/gdh+1jY2ZrvGwr/z06bddb /Hcctbwl/6Zdr73k35R8lZf8m7qOc7TkXxV7H/TT7H1Apzo61RfHCNc9dpYECdejMLHkb2kdkZu2 8YOuC5tue4es03DvcO+WXAfcO7JzeUvElcjN2sbyfN8KR0L661KtwqtLdvt3Ouet7sXF87csrLXF f30pLoy9PUY/keoj1X/qVB/ADmAHsGP0c/3Rz/fJOA2kOAvDlOwucr3/TNBqok/7URLQVhtacGP+ xNda3fLiVbMShzcUxOH8ngaEJYQlhCWEpfXDUlXhcZUOkAb0u6iYVsT1/cB2Ea/p79n6jheUjpFP Ip9EPknxjVezY3+qVeRFYRT7U5/f9ldqBqgVil9Knak4X5M6TSp3hLiRTfwqn3TbKVvNj74sGUTR fkwDx9p2zddiOI4y2qGrbS9nqAZQDaAaQDWAapBXor9ln3mvkGl3GIB+vLhwvJOT619f/gRRAaIC RAWIChAVqjrHISo0W1RAPoV8CvnU5vMp3DvcO9w73Lv6WTm321oyK4epPjuGYKrv+ZV/GOd4ygF4 Zz+rmKaNTu0TwVSf+gemi3Dv7KcM9w73Lmaxc3AWa3W6d04t7bh3izMR8Ew7hoBnPl+eubW+jr3f xkr84A9Hv4jfZaTlvdXV/urzSNFkjTgbpSoSnvdCeI7bst7C33y49G+l6H60KrugAPb1BQUABQAF kP3soeoNqcnqpIaBFDnjEEemNk15NY7k6Z4/zpKcJKaFZwUowPdNHEgI7r3maa5YZvsvU7+fPUJ3 foG9nCt/vQuy5IYEBOIFHuAfuy/o+pohGfjYwcdumdUh4B/wvzdD/NM9b5vhH+ku0t3FeiYqTf+E 4r21ylvNjJoQvyUj8YcaqjIT9w4Pwa7BrsGu6QQkDWeegV2DXZekRMwLNHteoHko//r8zeVdB461 e1gBMd+R5hwfL2nBRSrxT6QSSOGRwiOF3/xwRPPA3crVqSKSJkn/VZpS8pLdj6iueZv6wwbYQF7T h5mvCv7nP+JHst+9kSJI4r5Kh2THe3MvXp+9PZvzPKg5l8J7CMEYwRjBePPBGPcO9w73bvP3rnkk 6Jzs9ebZgWMxI8QaxBrEms3HGtw73Dvcu83fu+ZhvAXnNQl9A4SO84EMPunxsExnyEpZcBFHBMUf 2o6ONYfRUGdl8V5K8eHq4rzdbrc+2icBtAHaAG02jza4d7h3uHebv3fNY3k8/bUjTO9PFYfJ5MMq n3bbqVzPPTiIPzKl/UPpTCR9kcRSJKkYJqk0E3/5YWjxYyj7NJMZChVbBwOEAcIAYYAw2IqxxlaM 9zLIVBKL9oF34KJF4iTzb6hP5o6fKWs8En2icweCEWsMgWAIBEMg5hkgKk6BE0Mgz88fhn4wtaOe Z7G9flBkqR9rGv3Uwo9NdYFGRDj7Hkqt2WONOiv98E6mmdL2IkekYjZbgNvaPH/CzMg/MTPSPLHP UnhqqpgNKOmquJ+kQ7MEeJVPvO1iXw0E+TfJOBM3435fpqTvGaiZLsAVIz/4JDN9QPZfrAjKz6NI BSqL7l9YJwboAfRABYQKuL4KaIWV5kJPttNL2IvB93JWI+PArGKngxE6UqGKb8XEFOKEzvxMcgFK B6m6QQmq014capH3IO/ZhMs08h4qUqRahVeX6eme43TOW92Liz3eaf18rYrZ7Hdabjo88H4S2cDP 6B95tZ/yoYmfhmTmO/RVnNF/taDXhPSDgckMtJSh3dpZg9ENTZYEtfxaFAWZDzKfxXAM0Q2iG0WJ AhLqCwFWWKmJqg0Q3Wa1i6GMs1U+c0ORRMv0jtbqUDWHshwVcIpDX8dS3Q5ukpTTH06PZoCsraMC 6gB1gDrQ26C37XlOfhH0l3M9bRrLXyuBbi+Vt5TXUFS1wmgNyjYUcWI54cQubyMg5OHEjxymh/69 0DIOue2b88A5CLIODLgD3AHuAHeAOyviTg1/3y3gGfh3UtxLkhkTkcpAqjtpa4iAFcAKYGXzsIJ7 h3uHe7f5e7e1ldOemVCzUsIaKtMApZqbHi//WOXDNlQwyGe/rQMAYgAxgBibRwzcO9w73LvN37ut ZWo1wx5CFPOGObYLtN2aVeXeUbu7+HrBegDWA1Q9eysne1RlfMr9k80LSaV+1NXaUWkwmptjTDOq EK+oORVJCjbj0r00wRymKE9kitK8yMRRpmBKA59bJiR15EVRQpNJt9ybR8PDJwg9CD0IPU9MiqCP QB9ZnMBhDANjGBQllo5hkBeuw4a4c7/cue/5W6/itRboAOgA6MAT04HmZSIUahzhUshpibY4FB1x JLri+GteQ2BCYEJgQmCa5DxZf6GjMBbLK03Q1NaThPh5f83/IDIhMiEyITJ998j0t0nQrPDS3HbF yf5wbjdLzWdtaLci/6z5Bz7ZX/YD1yMZRQ1oUI2kvYun4udtPmpjf+B/i/f8I+c68L4KxY/OC0qQ aIzV7YgkyMi39Cd6JKynAToxdGLoxOijW3+AFXmPWTcxTSKtPT1op7OjrOs4R8vWtDjHxx4iEyLT 94hMed5jkp9v+gc4E5t41m0hg78u/HXhr7vAbWmBVkwzleVfVm5Wkb7epv6wAYn6dLnGzigTw1G0 7EfbCGWit18sSFn2aflBbqgM86PDvi7dB8WldMFh8wIiwfMy6MvHxBDfhO9XdJ4jEqWYs9qXiEyI TIhMmGWkec7/930j05rNMPs/W1wSBStbSoX4AvFlE+IL7h3uHcoxmy/H4N7h3uHebf7eNW9ixqLR za0toO2zLPh0929opcU41uo2NptiM3krUxKLXhdLlgoTB5Vqe/kUcAe4A9wB7nyP9ptyQMq/3hEs 0vKvMTkK2htSa6C3odXQeDy8IZ84X+skULTUL6Qt5tkgdw5i0BGMT3NzGsAeYA+wB9gD7MkNNr+l INNDj9XJKE2S/qs0pYaL7H4kT/fQYxVeXaane47TOW91Ly72uNJXOAClF0mc8cZIXwdKne6dJ+O0 5JD0FP0a9GProS8BfQnoS3jqvgQwcjByMHIw8vUZ+Y4oPzBdqKXdj1h5g2cBbOWzs1oxRqsvUiR9 66YAgAHAAGAA8PoAbIeknSrH0LoCK6juViVGRyrkNQ20qyFMJsKPQ1OFKQo0SV+Q+SGZBlE9Rlun BOgB9AB6AD2AnjWqMXMV7t1CHpSiGlqKqja2mHoAUJfhNS2ImvIOi1TUXIAGeFvk9OpfNoeq+bhF zw8YFhgWGBYYFhjWGgxrPBrJdBWMaWij5U0ypoxe5f38ejwkBZmsn8kC22T6qEfU1iO4PSjVCp0x 06ag4jwu5/qERpdp0YqiF7WkHLvLnD27rSXGnrBLtfkQ7FKfX28ac3a+EODu9rMKPwr4UcCPQvaz h6ZF4J1lhk4EwVmS7cIe/Nn1YgPvbogXm/1w1tMMvAPeAe+Ad/X2+MC7tsNkKFKxvBpHNIblj7Mk ZwDPd/YIeAe806d7LtbQKP90D7WZlWszvd/GSvzgD0e/iN9lpOW91XD56vNIpVKLs1GqIuF5tKDP cVvWW/ibD5f+rRTHH616BqQmSE1LEmf32OkueYvX9dpL3tI6IsQ2Q+d1K3/cdufQyPz0TNJ7TEFA 0+oH01964vczyVPGU9Q/3fNAAcy8NUorJJsnhKudtrukCHTU8pY8yvQgL3mSQb23+d5trQVj73VM ATCW2f7LlGLhI3TnF95c/lH5ungXZAk7JhEv8AD/WDtHkIFtMU/hPgIFAAoAFACdnemnUQCQ7iLd XZKFIt0loviWVvYQSQgoVpU9u77aNG6Kd1tLu6unUYhlWzS6ZhSjAZMn7ysSCq/acmKVE2lon7R4 Hco4U31FKiwNhItIxrdkSAu/jYWCH9oc0OawiTaH5oFPRVDeFUDSUob7KtwFsOkdCIdszEMVkMc5 A4ufGXQpjoC9NcaSp3Mc6zSQ4yDHQY6D7oKVuwtqc5wdhhlyMrKCak2G19B8Jk54f0YQjUOz38mg DheX3o0ylcQHwn2AJeuUAD2AHkAPoAfQs4bpAPN8K6ruFvawfvYow/GFaxvdWgcE2AHsAHYAO4Cd NWBHUX8ZrXG1AmtDkYeENe8hg1kgrPnWaQBmADOAGcDMqjAT+Tq7knEoUxny7M2vqfQ/5RXRf1Jy UzFvXFMhDZodcxMHTUYOEhqdiKM7t9M6MhMUIVUUaIKC2oH3XWffO752uieHxyeO8998fRv9z4x9 Fds1XTiO63hbsNat054P13QUbCsVyqg4Ec98+nVOxFp1VxzTS0mF3K05KDqNa/k567lel89r+i1/ nXsP0St8aun0IbA+svmT3LXrmW73Q3dKQHd7RBOBMr2Tez3R+tra8EME8dydiiCzYqsVSFZmwVsU BLIaBHpUZKbyMokvXrfyVokfSakR7QP3J+vAKJI8jrzeuk+SFYa2OvLSmRa30xSZGheBsV91kZkl 2t7Q9raJtjfIFZArIFdArlhVrqijhDsz67BDraU17L/c8PW61HgqzWg5n4/wtU4CRfJRSEvfaMYh Gyh7LQlgB7AD2AHsrA875Wg0/drSGWqEmQaM3RX7rVb5tA1tQc1XXkFJgJLAuiHcSuBWQrPo2ANj +YTDrKzZJoFbW4OtTS+xtbWhW1t7+6tw1QYwczIk/SQzLcT/+KnybyK5yufedo7e2y8cLW5UJu4k uQmmtIjXNr2wzgEiEEQgiEAQgSACrdGRr+VfYxkHO4EwNYwxHg/Jt1bz3lmePx6Oo4zcMHQmpjD8 aFgOyAPkAfIAeYA8ayAPzeBadL6m0LLtaU0N6DDS9JN04qc0uiEGvhZT2YKSnmsznlwBzAAeAA+A B8AD4FkDeHK+v8PYQ6MBoaRFH0NabBiKm3sx2acvxc9LR3j0SEZRA/RVteyHbz5oM5nHCzEZ0LAo fta0AOx+RENsDf5Zs2/nPM0GhQSFBIUEhQSFXINCJv2+lrtsoMZt+UQZp5rF0sJ8U5jjcBTtBHfs 7RfFDzTHojkWzbF8AmiORXPs/FA5mmPRHHuRxNSqRxZYOlDKXmX2RFGDlI2aqlNeWuLa059kQ5NM RJjQ0g92Yh/4d1L48b1Igkxmwo/UbTykfVNkIvLXWKWSvwYXABcAFwAXKEalMCiDQZnOYYfFRBKV M/+m2VwAwjmEcwjnmxfOce9w73DvcO8MxaCMmjZSnto3wu22vMVPiHfU7i5+R6vTaS9+BywVH507 1tj/A2vsgXf27ca9w72DlansZw/SG/DOUl5IiHIWY7frOEdGqFhAIpzj4yUswgXeAe/y3Sr+TSUT Bc+0sRv37vlVB5lf8m4V8Ez7WQXPBM8EzwTPrKeI4Jlts9osormxq3FEszO05CzJmXf6bNd1Ae+q uSrwDngHvAPeAe8CFd9yA2efZqJpvR7rbAxxtLsUeNfqXlzwgfCm1kvePdg5Ny9xJ6RJI83jYzp/ qAOoUhRBn5ilVqJnHH1iVWsmr17Kvk/ec6VLhntXtJp22u4Sbf6o5S2p8OPe4d7h3pX57mH7eElR DPeuotuodUS0cGEZyG2jL7pMHK9w73DvFt8Yj+B5yaXCvTMiK/TM6jQTeib0TOiZZZxBX7Rd4Uf9 DnpmmZZCz0R+h/zunM0rzDF4Jq0lfgmeSdWNunIGeCZ4JngmeGZ9hADPBM8EzyxHCPBM8EzwzPKN wLz5/BA/5u+Uf7oHn4d6XgU9E3om+jPRJ1YfIcAzwTPBM8EzF8i3LngmeOaSTiP4q1gTC9AzoWdC zyyjKngmeCZ4ZvlGQM+EnvlgDoZdSdiVNN8lgvk7zN9hDqiMmZi/e2zljTmgci/m5ER/Ac8s3xnw TPBM8Mx5eQ565oM7NngmeCZ4ZhkzwTPBM1NVoKYZw9df7Jkf8Mx5tQI8EzzzefBMGscrfMBsGxV2 4DODevTb83OZpx6t3m9jJX7wh6NfxO8y0vJelH+9+jyitdJanI1SFQnPeyE8x22V38Fff7j0b6Vw nY9mxagxrYd1/SM0w0jifPjGqpYp3lPsCKgYcZ6MQQHKpBirWuxmcqxqeX4gOrV62l4K8DomT+VY ZvsvU7JXnkd38/2byz8qXxfvgiy5IQ5GvMAD/C9oaQX8A/7hSFAGd0yK2eCODl508KKDtxwh0MGL Dt5lnRXbS7sPD4RgXn2RpBM/DYlE/yoH/p1KUhBpEGmShEYJaUIYhdMYhUPrCFpH+BkgrYkcD5vd OrK1gC4+D6MTPfIDWko2oqqZTO/kXo9ks7PY4Hx/hvNqOIrkUMaZn6kkFrGUoRZZIoZ+zJU0HanQ bDtTcZhMtKD/IRgBGAEYAZ3AUw4tNS8yWWGFCGeaJP1XKbcyZPcjCmO3qT98n/lplhOQbe1xkH4w WOWjvorDrf6gNQjkB5m6kwaDNEENpZ3Xg3mUEX4UMdZk9CeclD6AVZZYR8flLrNXkh4S3jd59XgV nt0CM30fNufVulVD54LO1VidqyYoCWGFleaCTyipuj6kVcWrfN6GItBk4GdiSHtTVeDrTFCO9Elm JuXxg0COMuHHoah+k3VqAB+7ZIimAjQVbKKpYFszn4iizZWMqbYiQ25S/jWV/qd8x+Guw5Kf7jIg 3Yz7fX4oKBd6pM4NxwRRfqRnehznQzlkAYwgw1E+i8IcZDjWQL5mQo8ktV2HnCz1Yz1UWlPRQ1uh tCb72/ZsqHdgfUpkL8hellTy3WOnu+QtMN+B+Q6DT93qQwxFYygaQ9HfPkdJN6t3eOBayF3DTxpQ GuUe1Kkuu8pH3nZKVsPBL40iLV4SOZWk1Zu+HOs4wN3A3ZYQM3C3B9jBNHtOUi0POEyz2zEE0+yY Zn8wvCBdde2osUhkYxV/rMnMhlucrlMVfIokyfy3SaqywZDbb4MkztIkKrR+YclVVJ2WMRjBgrwT tWjUolGLrmvjWhSZrLDS3FQzfEiu4ttVPnNDc00Gose9UB+uLs47ntP5yBk5F5zT5E6FDFcTNOAu 0juBO8Ad4A5wZ1IuC5FcV9huZj2KpCP/9rGkV4O0DUWdoQwGfqz00MwTCguMDeA8giQUrwE7e+h2 ohN4ym4nFB5s0RB0D3QPdO9b6J5LmeWfpHVyalmMhJao0QuawZmf/Mz79WhQZ9oubWXtiEyITCiJ XqshiTRv5URcJeTfwYRpcBZrZbt5f4/iBt+3SzLW39ZhnPr+Z7YWtkJLTWrWgH6bavFvrNnvpbIw ZWdhNQfT0JyVfAqUFkOZDZLQej4APYAeQA+gh5eseE7+JNQvYV1Ue9sh6FE7MXNT0+AZkL+NDKtT H0HoG1AvyHz+kydJ0T2gB20f0EGfWAdF1rO9iV+vaKXLdhmBqjO/CQlyyTjjelyQ3Mk0zwPJLccH 6gB1gDpAnck0vaGjMDZ5SHhWy/l6sVS3gxvq7975dsMHN8+Br8W9zLjdPZWBZF9Qlh1Jw9bkj2SL jVDZoLJBZdu8yoZ7h3uHe7f5e9c8icGbtnyQ72FuAr5qx8fr8zeXdx1uCEEeijwUeSjyUOSh8tuO oFckV7ssfi5qcKmwYE1iVN1ym2L/Zir7WFYS6IJGFzR6Db+lC3qHGj5QdevNOterR9zEeET79+Zr b8h4kPEg40HG8210v6YBjXFnZ7rcUXnjza+hvFMBDYfQUncp4iSrKrwFSUqrYgmFzMZXyG2LdW+k PUh7kPYg7fmy4Ah6MyMLi8fv1uRUsWEP/Ryw8ICFB58ALDz06d6x21nMr9xuy1v8DngY270p8DCG h/HmPIz/JBPiom+TBwV8EZPvwIzvFMbFFU4efZXqzKJD6DGz7zEyS2SWyCwXpFW1sqYVVmqyrAYY d4wzFakvcpebOCp9o3iSoBgvMJMEVWNuSEORhiINfeo0tHntzZdVRnbzTlIq1pT/q5CcQlr8I/DH NHGbnu7F0Z3baR05/FroZ5KdRFxv33X2veNr5/jEcej//rtn+W2d7jnOheO4jpe/XthxPb8UiJfY 0R4zNVRfLHwm2k/nwZ8plNH0WNrrHsslHafjdM5b3YsL/rtSrcKXkgjl1pwWnca1/Jz1aCX8OOAT m77AX5PnWv6K9SxYH9r8ybN+GqgOWfJ8pq6XiJ75OLgvzE8UjaAn9B4qU84/MCP+cKPix3r1+Cd9 ZZ3E9H0vZd+nxYKP335Zesn8zfmx0TpT81zWrTWFdmU1gHa9dnuxUkcHVjgj1R0ptKvnF7gp0DTU 5NEKK83NE1P511ilcpVP21DXxvl2ShIpZ3P41T0xxSQ6PB4ZD+uiNRRKKJRQKKFQWi4wnJ0U/LlH Ph47jDqVumO+Sm3mfqJFoeI++EBaJ8bkC8lOxin8KKF+AUAOIAeQA8iphZySm4QVSGvSu4YmPIQv 3IgR3U8ttcKaabPcZ5hw+l4EfmydGKAH/RiL9TzXPXa6S97ikSy45C2to/YyWbDdOTR9gvRMTlVZ TQ3F3HFE5ZN+JlnuZ5IQqZjLJvQXFt9cjSN6gSosSf5vUXDTFDrb5nrErLBSE4gb0I/haz0e7nLC kw3IJVgnQxotK+lrnAaV8h0zevbY79F6RgA9gJ4loAHokSnv+GKcCygxPk8e4rnxadFf6E9WdOfl +1aUiul/xLVyu4LKCsTzBc5Fy1SssNJc6KmUmlb57A3Nf8QZc0LqRp87g1LnzSHfnJU7b9wt77zR IxmovpKPClqPe2866x5MVfPFdvbeRNStlOVn1rTum5rm6Xg8vKGLk/Qr9QLrNoGkgaSBpMETeP2N d1ZYaS5JK8zPtFZJvBNDG70Xs/mLmQAghv69IG5GrcDU7flQ9eSvRv6tn9HhWM8DYAYwA5gBzABm VtwxRKHWCqA1gNrQzJ9XBy1XQwAqABWAyuZBBfcO9w73bvP3jso3DSvsnM2vRue8Mhlx+kh71e/F WEvqfXq8YojNAYIkzlQ8tkv1CE0ITQhNCE3IM1fMM3d7uMOeXCfxkmy1ydWBdqeLKJlQCS1IhsNx rAKjaApepD6Qflhsv7MSdCAPkAfIA+QB8qyIPFNeb0XR3ZI5S9WyF4u6bTkNwuJU6o9sdTpL5hAw WojRQowWYrTQ6pombj6bZsfSVBbPpl4qPF84V2mbHhB1fdAgSHnHkIXUyHeQ7yDfQb6DfGfFfOdG SrsnbrdynakXF2tnvG1gikA8/WuQhpcOPPh5WfOGhEJ2qyXAB+AD8AH4AHxWBJ95+93dwh4eVJ/i T7Hcpqq7sKLRHSkPnCOp58a4lrnO8fGSLWbwUlEYaH8Qm2rGM3dmXbeM/ZsIq20yRXu6S7UeQRNS Kj4AtgBbgC10Atihih2q81VL7KEwW0sa648HBQ8KHhS8zSt4uHe4d7h3uHf1+2DcbmuJyuUdtZcY BqNP79QOM9AOtfJP93DvcO9yMR35HfK7KovJK+z3rN3U1mm7S5D5qOUtQWbcO9w73DvZf1hGddg+ Nlsp6pEZ9844kFt7gl3s+zAjBaynbLXpeu+3sRI/+MPRL+J3GWlaIVT+9erziJbOanE2SlUkPO+F oGX2rfI7+OsPl/6tFK77ESVNlDRR0kRJM8/xaFP8EqkRUpMFqnRgy3ZoOc7RskNFm9rTSE1ba8/V ex2Tl3Mss/2XKa1hm0d38z33y1b+ehdkCS8bIF7gAf4B/4B/wD/gP9/ZZYE7lDcob1DeoLyZvX60 /5ZgokJWw6bdnVl32Ds8cA9cizPXjOU1YK0ujX1fpyr4FNl+vTUfuKFrDS791B9KyrW08ONQ/I+f qscDMujQs1tn4Og13xuPKcN/YsoQ9w73bolcjXXVmO5dYbr3TIvZpl6hYnF1cS46ntMRH+gr/uLj C3IhKOiQyNSQTjUdx1rQ0ifhW4QQQQlBCUFp823DW1vL2XXLgVD2VTy3IH23kkzFxTxSlkyKScZp 5K6WSsnrcvrqdpzmmwxGs0z0xGx3pUWuajgeAntQwEMB74kLeNuKPZGvsysZhzKVITcE/koO/59y tXvXUWkak634uluwpNUXKZZ9fkqboqgBavdrwtOVPuu2C93Fcvih/5npAyW7BfcwP+3X9DJluqR0 +2S/F47j0I+De+tckN8iv0V+i/wWRq4rGrlSGqczP86sKLpbTOITnPN6SFORpj5xmgrqBuoG6gbq tj5149mSXLenvigqgo5T2r9bo1e/2BkNgZ+s1MzfGsneXoBSwfiMdtIAPWEyUMHAordAGiANkAZI sz7SWGGlIobeUn9uA+RnFYe8sn6nnfezgRTxeMijqUl/rtlKsqtFXgiXdzLOuEZOuy6TIBin1iMC 5AHyAHmAPECeFeXpG0k9rLs84kP1T6r9EraYtZZyBjx+dJukKhsMIV5DvN6DeA3xGiYJFfPPMElo tknCtvY2ZrUdjK/8YCDsbdVD2u6W0X9ZzdaSW62zByIw67ymP8rMxA9lqkg6UdAGJ3hiTtC82GSF lebKnbRa0w94yeYqn3fbK2Q1QMRdttRvb47B2jVKfhODJNTkv7HsdJrSfL2ThdOax2LuZ86cZHKi wtM974iTUH9MD0d6uhdHd26ndeTwayGxFfpzsnPcd5197/jaOT5x3BPH+e8eZ+4pvSXVKrw63XOc C8dxHS9/vXDBvkhYT6e/WgdKne6dUzW/5NbwFKs+ydi99+bsf62jIGGfzoI/Tygj+rc1R9Jd90iq 7L1eSrLv2JqTotO4lp/pvP79/poPbPo9f532ilesx8D6zOZPnvODUHNNbmzoQNkHZR+UfVD22XjZ p4TPx18FRt6W4zNpIRY+1yQrj8n7FmFrnYaUJdZHr6ImLcPMVmZrFU+DBdMFhdtOanJLaQ5V2bhl w8xY7ghFcebzt4dY0XK/Kla0tjtWVFM4tk6a6QDlBHiuYfjhdpXOz/uq86u4XdsUhXqmwVbIfl8a tSC6F6HSxoey+gSXR6fWuufXnOhU+xwWuZPJrvjr5mZTkJryH28Fh2lEj351ABYksQjk0QvdvWFl CyvbmLFycBbrx+JooG291DxL+gu93xjFe8VuKP3lnAXW0mscb1h1o9+3exlhTWhZXrtoSOP+N6fB FoHaVhU2S4RjOiKqClkvRD1vnWeoIz6BUZHlmkJF57zVvbjgq2dqF9ZxTV/E5mlsnqZnYZRQGHax h6MMMJMTgM4JyQtJ/1Wa0jOS3Y+oRtoQ0JlGWyuKViQv/HEfC7BWKN1W5KEf7ci/NRNh6M/nH2Ld fiJkMMhgNpHBcCYDEpcxYTV8BPcO924T947yo2k61AhgF+JblnHMXNMtSoSYhK4gdAWhK2jjXUFb GpJ7d5X7DRuaWfbyRRrkIJKSo8i8EzYvfMrI0EtMaAacVkKxO0nxVmAM8s0pzXed42MPGAOMAcas aDgy3ThgRdGGQkxNdTSb7lgIkjHvXxABNExomDPpCJiilX+6t3lMgV4AvQBcbvP3rnkaZqVB9jS7 fiHktDfGEAA2s6ywvrQIEkITQhNCE0IT0swV08yMzfitELpbOeZjx2St4kAaqLEX2U9o4zBvAiU3 EupmRSaKTBSZKJ/AUzifMM2bzgWgmwbdNPV9fa577HSXMEK0RO9MS3Tv8MA98FbhOw3YlkHzqpdw kOMzmPZAWz94aAXQCpYgA8CDqm5v5YR53ncb4sS9w73DvYNGt75G9yf1nFVbu7wwAo7tXp6lfqyH ikw8b8bkEZPKkO3NQQn+j70v7G0bSbb9Kw19mN0F4qwo2bLlgQVkbAdj7M3EcDw39+1gMGiLLZsI RWrYlB3n17+qJimxJVKU7USWyBPcu0lsxbtqsetUnTp1Cio1qNRemcepX2fTCisllHoNSszx1I9p I6N+pslhLUZxJnL4RRGqTKlzcGs1Dua7sYQw6zQAPGbor9vr7a/OADEWiLFAjAWW2SER3V0imW2M oRCAZyAS4CHEoRW/np4XQmR8eaMYi8j+UiuztZFqHR7QsbIS8DDgYVajMJpnuQ0f343/RLFD1eay Wxn38Y3ZH/22nbtWyEyn8euYcoZCgt0EZCCk1uHQI+tyd7YU2KjKqP34zr1TkamKlqzg4YIygm4D ug3N7TVxFY4lyp3nlDuf2Os9DMSBCEfi6v2p6HXaPfEH/Yn/8Cf3ASg1dsPhdMzT664aeYFKJglG oe+HDxSdjpEWoweAHsAr9wBQjqIcRTkKWcDLZQEWnNe39xYKcU3JzTrvtqbutktpnRStYUgbCHRM yV5LpIoPrTlDtBbYWIcG5AHyAHmAPC9HHtGY/luOB7RiaQnc1hSAiACN1FB598xxEhXKgsNZZ9Lq zyXOq0poOcZKZoyOYnT0tUdH69eFI/Dh+KMVNWI8lxJgb8TtSxm49LW/p4rH2oPp+Ia/Ro0bSwWd xipMtSM0ITS9dmhCPYp6FPUo6tGX16PrlGY1mEIAE7rMhAaiRUZGIENXB1JMIpzYWAtT3Vcy1a1l PdoQ/AEZqloDJhVAhs41nZ3D/QrjKYAPwGfur/KaPnq1BJ8CMjS1hRAjX94SKZoumDA69kWO1IIu MDJ2lojxXIznQq/+HL16cxQCvtJN1qbRVG4gLBB5OPYCTSJrzz1pdfe5ySCn8V0YnbQC/97pdQ/b /DWXBqlOyLzb6ew57b1O/7rdP27vH7fb/22ZCTl6iZmdO2m12/39Tv/sNPk62+HSt7Zycq54WJ23 OSw2JmmIQwaPPMthHR3hL52d9f53yzpkwG827/6xJBOx3q/1qBw86VE52O1HZWDHjPkH7yo/uzu9 lx6I9eykF+pMEaTvzJWi07hWX+PBP3TuCvEjlH2D/0wRIfkKX5zc+R0+6fwKYk99zs/IIVaeW5QF XOtNm1C0zSF3ACkHf0axvKHP7547ab7CwO2KE4HXw4/weqD4i0F33DvcO5q5xqB70ovW355DHHCS EpuEzhR61HIKR+cRZyfx44QqxttIjiHl4BS+d9o9ev9+V6vinFdBSJcmCDPTAlMYU86vokD6oqXu SeGrW0jzkOZxOWd8NSHeeCXxBtI8lFerhWYor35EeVW/vjXSvMWktqajo0uK3ZuQllkUDZCyyZ4r Lk4/XN73sLECxuF5HhMZ3ytlfPVDnuYoE2YT+uuAbU3hJ1taQaLdbM31mAQb8lZp8m29vqMd1yL7 gpCRSp0TXevIUPag7EHZg0HFlw8qNgd8vMAKoc3yy0kkX8axl7bwKbLfBX8N/hr8NZ/Aa85/IJFD IodEbvOJHO4d7h3uHe5duVDVOep2Vj8hmDO2Y4jTbh/2Vh8ZWPNXYs2Bd/azijnaRWE+dBI/QieB e4d7VwGJTr9dYVfidI46Fd13p3u43674L9rvHRh4pmeSpnPMUKembhQ7aNNE7Ij0rSTiZULEp01d NAlLPzD9y9XUpy/Q0GyY/Fds77ZIvm/pdBj9b9/FXZe/Tj3xkxxPfhb/Ub5Wj0TQz3+df514EYmT 300izxedzhtB88rd+feTP/1xSd1E4XT+tAhvhCKEoooIgVA0dwX6bluHce9w73DvNk817axQbHAR 8KyRivfOIkrLFtHd/J3lqoW/Pg7jkBcNsI8J4H/F+CcYADAAm3DSAvwD/gH/m4d/3DvcO9y7zd+7 nU27i73yKMm20ugS2WhdDCDsFYklb7amkxkylceG01jTGjfBmtlsREP6t2HkxXdj+qqMzbfICCQO h6EvYvlFLZnnwXwI5kMrqk90W39Et7V+2NMc+PGC+9C/bzL+jGUgb7kbq33PNV1ZL3DDB6FjciZ+ Y2bRPXIdnagh7xelVaP2QAsKHhQ8KHhQ8GAmcO0TGHxSJucXB2879jzc6soHoRahFqF286EW9w73 Dvdu8/duZ+vqwcFb5223IQQu2cdcKSYxG11FX0bhRN7K2AtRHsPhAA4HcDigWi7UJ62+UzWciIlP a1ULHVjVSAkmPkPygufxGT30vJPWaTiNco2N13QW2dmcrbQP/5n6r7ToOslwRG71d7pcliSxozB6 kJFL+tc4koEee/ThwL+Vgh82Xi/socIk+itNotcvLjWkvMxMSdd5uzVVCE01t2ULdUFUfL8zJuJz CBpLL4jp/8lG3DozsJhgMcFigsVcu01ZmhFbYaWkZVkDZSpHXb/JyqBMhRp7YyptCGEKyyDxwAUS 1UfJNgs3ZACy29qAHkAPoAfQ83Lo+XynAnF1/u70+uJ/z/+6vvhwfvXX+f9dXly9u774+NsnQUrF dhEv46a7FS3oQlhCWEJYQlh6eViywkp9M2L1VQ2ncZNT4kISpjw15kVuWevAekYAPYAeQA+gB9DT 6qTdfv3tlFva9/MjoSCZWj7Gg1zf1QqkJWBb004AlTeup+WNr1xm/t07FZnWQChmIwUiHImr96ei 12n3rJMC5AByADmAnHl8fTheGXNL+f8/KL5wePmTmRYOSeFwOlZBnO6M1KZVOQp9WvdF0ekYUWjF RD784OAHBz84a8U19LDQw8IRPhK/qYfXUtGTVX8p+ltwXlJ+1aD7H/JWbM82WCp5tzUtNpfSOila wzDQno4p2WtlWmetaebJokCtJwRlJ8pOlJ0oO19edjbHlApkp2oNhNTUOxsq754pThnkJmpEKgon ooFcEcmuyhuSV5WN1cAd4A5wB7gD3Fn7BAaBIimviqz8vVk1D+s75qATkOQ5m+iMGYWCkAx67wiY AvVgxm7GUz8m8NGxdWbAHmAPsAfYs3bkLSXbGlTzyOEXFds5fMOwJyTtxkhFmJ2BgRAMhF6r9cG5 G6/yRQ6HHA45HHK4l+dwVmlYktKgYUpL4Nu90+7R+/cthv/t3fVe3htfbpgGouUF6JmujqMwiYJJ 1HwBOszrOPzpb/YoxHOlug3iD0oMeEsAt6aaHfRM6d4Y39XO4f4RcIdkWul5ODBNhWlq3iV2SP6c eePYfwN3nnECA7RMrZZpaceUhDo+53YiDFTWPrUqYxBuINxWAza2l+ZMvl8cvjOiu37OuM0peorl J80qeSamcSxidE9ht740S9ru9zsAlc13cZDMIZnDvdv8vatfMmfViCWZDbqnde2eqnszalrqPS1t wSBgB7AD2AHsvFy00xwOYTpxaW1pcLsO0Na1axo8Cu17Lo/4kGWVGz6If3pv1VsxvJPBLX+V54LI mXCq2F6v6qT0RPl+DXKSz+YoPnj2RtuCHMy84V1/NgZvrM8VqQRSCaQSSCU2kkrUDDHkVyuU1hcx BLe7KTXQivraI3Ez5fkt5dqjwSLpUOh/kVOFdS6AGEAMIAYQsxGIuY3kuAY1SaT0hDzoGr2DJMxZ VJAv0gfaQD4TAqRggxli1vLF8iaT0VuWqjBdXmqUO/12hVza6Rx19ivgqnu4n25zKDt6Z7930OOf QskPvUYbySUlSIZ6OZajWEXUy2DVsu8F6qTVoR+Y/uVq6tMX5DQOk/8V2zsixokdZojNJg/cO6Or Lr0OuHfz0S9IGkt9YKy6saCerkl2B9PlpRnim5C2KxeleJo8Md2cKab1iIBaALVQkasBeYA8M5+F crv/5jTCZzW0FUlLwHbXu50lmUZKVbP38nXkDb/4KvNa1rRw7vpO6fkXhIxUuvLJtY4M4APwAfiA 1wavvfYJDBZag81CnaSFOoxpkYwWN4r2BoK/Bn+ds67AFJc8aW0eUJDIIZFDIrf5e4cpLmr5Rdpz ry65G7gzvpADw183WZsg0yQunMb08SkjjsuIBOnfhhEtGBkna5s46aNFV3E4DH0Ryy/Y37SyUwjN AjQLm1gUXT/saQ6D7QX3oX/fZPwZy0Caga2FcS4d04LAN6Zj6mlBcvuhN/JIqL1Au6DgQcGDggcF z9q8bUkbjSBHVI6J1kSz80mZnF8cvO3YrO1qDhuhFqEWoXbzoRb3DvcO927z925n6+oBAbsl7ynB 9RoMl5HE6VNiA7LOG66pBCxx/YCvFhrwaMDzCbzmQiIka0jWkKwhWXs5H3V+r6JHM0dEXpoPMnJp +OHD75+uxVh6QUz/L+SiBRoZmmj191QFQ7ujgKCEoISghKD08qC0TpVVg7IymI5vVGRXVCVFdE1r SvZvVnKYDLJqRY1XApdIDcnc2X9M3UxS26x0AimZNrIeEOAOcAe4A9wB7rQ6qcuO/naqiaIwTivJ 1yhIpr448SDVwFhBtFm485CYOU9URAg01iJ+CMVoGiQi1WPrYIAuQBegy+bRBfcO9w73bvP3bmf7 0aWSO4dqxovA9YYk9RUPd7RwuNg2iQdP+DtzIlTfhVMfHhboeKLj+dodz/qFpQZJgeVwqCaxVVbV tN4c2FJnJLFIYpHEbj6Jxb3DvcO92/y9q1+W1lmzeGTPw9maHzbgHctHsqyych5EJUQlRCVEpZc3 KhtUO8aRDPTYi2NlE3E1LSBLWMw4FIHybu9uyCmH1s5aNKVGzQmGEgzlazOUyO6Q3SG723x2h3uH e4d7h3tXvtbROep2Vj8hncP9ii2H3V6vYskhjBhhxAgjxlW641+nnvhJjic/i/8oX6tHZjFmv86/ Tjxa4iveTSLPF53OG9FpO93Zt9M//HEpb5Vwun+CWMUeW1K4T0J90nLa2AOAPQArXZKRAthFQt/p VS1kbrcPzULmFXkV7p33KvduZ9usg4uAFnkHKt47i2in9yK6m78zt1346+MwDmlelvMC23gKDIB9 uVGJoBLZRCWCe4d7t5pXcbBM+AcsE8a9w73Dvds8472zaXeJqESIc/ZeWViJ4Ye3NCrnk//KkNZu ejrWZMqCmXhITCAxgcQkZVyJPqoAILTcfDWKZ1cGfNt+mw/D9wJ1NfXVSUtO4zB5hlJfmuh9GBDW PBxLPfS8k9ZpOI28efb8mna79QN+nol/J2ihtor2bsIpzStklp4icaV7U7mmhpZl+X4NXPgSX/MP Cxu/CuTF5g3vuhHf4E2yZTNSE+q2ks8emR/dYUwF2d0MqtBN1ejq2OZxD8crDeVKy0tu41hCjYKo WpNtZxl8rvN2dx1DSj7vJHFgB1d20gl9V+liqx3zfWrzWWcFUhOkZkVNiWbCvBwaku4pXyEZ9Yv+ tn7c5vt2GXHeE9E/imgr+9VldNJqt3un3aP371vmO+kLtq8yo0pS6vhKBbSvQLksCvwlUvJLogEq iU+JqMAKOvXFo5mJ2Trvt6aARBudHzyfKIdbQfOTbCvu3RMwReJO6tmwPhfCAQ9UWgcFNAIaAY3Q YsOofs5DvKIMHABzBsnuJO82CMkPRgbJZqXx1I+ppUrVULLEImHgGIQKq0ZgD7AH2APsAfY8AXvo pVO7jVFS29W01vGV5k6ODCoJ17r07fjNWjVbwQdei5ZdCZ2x1ntHf3a3WK0YBsIr5/gw2oLRFoy2 5JVlmGy1q0Uo7aC0e7dhBQeNSJckaUKwgTA1GKYTWja3KLUzRUvjlHby61qp664XalDandiRGRZK CwcCpd2G4/Suax7KUQZKu0kUhqPziMUs8eOEBgxYWLjrGFKSVdhKu0B9LdXZ0bK7dK2dhbloMdnQ BFoBtMImaIVdFdsBeI5jyBtaA6G+TtSQZ4ZmerqZfi63N/XD75+uRbL0j0UQgB54NVJaBq9GzLCy qvwpKvVVzBrXPGwWVy2vSmdaxS1pxMl/LumThxHiEuIS4hKdAOLS945LVmgpEKbUZOpR/T2V/jrv taZEDKXBVe++LnKr1CahKc0b7FTjkBjLG4IHI8O07GzAl4Ev2wRfBp4aPDVGITAK8fJRiG5ieEV2 lmxQUUQb6OYIcX6ZjkbJ3Pzwi4r1WinsrmfwJMeZ7We/eeSuqPW2gTRAGiANkOblSNMgKQ7D6Gzo 266YSzivXUeREkFOYqRNborRo/CaM4LXxDyi5AkwLe87Sf4yEnkFmCO0ldBWekjyye/Z7rZCSwnE 1mDkt9AWpeTt1jSjSCW+lEywfjeSAa29/aPq469Zr6khltzFGUVz2KiGdRb/ZRdKIJ5APIF42jzx hHuHe4d7t/l7V78RmH3TWoy9sYqak7T9Sv7+/PDYIuqCGq0WFlzZLL8XuGTkGSuzNEeMvcAbT8fC 90aKP/509YFVpQFmADOAGcAM+opPMPNMN9JagbQAWmo84f9ASBM+UGJxTeyf1WZNHKZ/+3gtRpGi btPC+l7rzAA+AB+AD8AH4PME8LlRJGmxxYHNwh4LQgreel26TM0qYYu7TGzo4NEiWPQkMO6EDbB8 Aq85C418Hfk68nXk6y/P1z/fqSDdeMjrD2ktSNHI0xvhjUQQUhJAc1H8upR4obWJTD9YiSBiE2IT YhNi08tjkxVWCurLunijcFCtnK2sMYdNNEpmPkuLDpX7Zva32cxQQmYPjS0XUdmBesggyHpIgD3A HmAPsAfY0+q0k4ugv53SdvPEmif5GgXJ6DIyNNagIH8vAdqajk8kJH7qQWsWwKd91EWzyKIWK7AH A3wY4HtlLrR+OlErrJSE4xoM742lbfhd8k5rCjyRGvrSG4uxGodkBkCttXAaDUkwSp4zLNgxbFxW 5KQ8G3soEEUX0qSfLadF3YO6B3UP6p6X1z3M/jMHw4R/Q3DIazT5VvUhQ8RzHGnP3bHt4CUinjup UyGPS/XsxehNmlFw/iF1GMyYV+upQHaB7ALZBbKLl2cXVlgpqfdqUNnO2lbrvN+a1rdDGVChKopa dmk1S6ISWkfJG8BcTw9l5MJrdX91mIWbPtz0N+GmD0qVOO0dzPoHE8k+3U1AnQEGETCIgEEEDCJQ FRHqk1bf6a3OnZyjbmf1KzqH+0erX9Ht9ZChqVGMe/fa965+GdrFaMmiIBk30IajZHPTrDcxYynn nvKmjrTyHpCWIC1XR3PH6bcrAr7TOepURHyne7ifSu3KluA5+70Dg070TNJrNCdumlJ1bvE/HMsR bRo+abU5pPheoE5aHfqB6V+upj59QU7jMHkvqXAveh8GtFyd/rEeet5J65S0Ax7tK/5NPSAy0Rn8 2xzxNzqg9ef5S1omojFt0Nug2XYGGcQsKj+5Fc7fS4rrf2jqj/89VcFQZdvCPXt4A8gD5AHyoF2G dtmaQwi+0nYELekM1rRTFt/R1LVVuxS8/7rIcFIP/0ZvbBCs4p1MlIw0loBRtmRmkSZRGI7Oo4hy 9vhxQkVPPfyASWb1keXaD55WhrewLjpSRaSKSBWRKr48VSywfpXDoZrEudKVRkdc4Sqim8iQXImH O8WRidGIlTpxiNCEcUaCX9NPc9r9fkW/DPxpjnIdUg8yz8I+mYHkVCCZyuYUaAfFJ03nT1PRpxVE Cwq5Gvu4zElSRpp/E65MpE42YCTcKWGMgaNAfY3FnXfL6OPLRxVBzAMxDzeuAD1wFYWYZ1HkTD3o iiY0qZ+qetDt9mGVQgopnydPWqhGX16NGlfRpP40PgZlrqKcMRRUrtOJS7uzrEwKTBmYMjBliE0v j01WWCkp0Gowg0ihdZ13WtOequ1PLW6kJkuLMMiRocs6HjMRz6+wzg3AA+AB8AB4ADxrqnkydaQV RUtwtqboE0zHN0Rteto01ljeRLDSPJGP/Fr1DNRD44F5FA6Ofn4wDJNyCweCfqoGuUYdDsyj0HzT WtbkuhlGBiVt87WQswY0RaoHbkiqUPJhU1vcEbdmuQlvQqFMcd5KL+EprOcDHIWdfcAnaTEfg1YL Wi2KEtnej5I4VD3rWrMxlGbDzh6mjmo5dFJyu3+6jX/mbvtfH97931+fL347+/j5r08X/z0HfQH6 Atog2GnM/UNeLGanGb6SIFSdYtRkq6cXkPXtWAWNcGMs+bCtIrWgBVSzbLLZQ816Orxj8iJuWlaJ IoLC/YDv+opB7vpQlc2+5T/58c8nVlwH+QjyEQIpCKQgkFqzsVlAwdjzjwWZco2nRsW7xKNAy7ES sTdObFKKxkJ4LSagBx4FGBSlE3jNQVHK9Ol/ATwKdm0r4EAGTV65TGQcuSTDc62iVK+pKNtQU3fy XrHP/IKD70yijfQC6QXSC6QXG7aQX2yELJlh1qQp1iz314UdZavLetCooFFBo26eRsW9w73Dvdv8 vasfh0QbzJb9jO6kFvJeer688ZUYq3EYPYpIaVrYNFR6vgL7ZjoaqQjlJ8pPlJ8oPzdcftakuly0 7lldcNUNgNhHb2l1GZkSCyIT5DD2iPikP03krYy9MEjMjtj3XQXh9PYOyAPkAfK8MvKgFkUtilp0 87Uo7h3uHe4d7p1Zz005gDHpsfysnKNuxTaczuF+xTJxeGLBE2s+Ywn93jN2tA9+nXriJzme/Cz+ o3ytHkX+1/nXiUfUqng3iTxfdDpvRKftdPOv4D//cSlvlXD2/0TJi5IXJS9K3mTrEK1QqUgBkQJY KRF2zuy3eWeVT7s0r6Y+bSyW0zhMnqHUZyl6HwbwlZjnPN/DV2JwEdAC00DFe2eRHMWL6G7+zlR4 4a+PwzhkZ2bKCzqAf8A/4B/wD/gv4Duwck6b8pT2lvICs4djghoVnbRmiE8uxrsM/2C8wXhXlDtO v11BaDodChMVP6V7SNfELMOO5Q3dowJqdb93YEoveibpNfW+d3UTnTTGzi1Rblo1Q7PkRTPNqpAR jVDOJK3kXZ5oV3Oe5TNHUeu8gDnAnAooAOZ8R7KE79ulsWSDW8MumlUMSLz5ICN3YSygWbDz4fdP 12Lmpdo0a8lmew3KwBXs+UQS5cy4AwkFSFuQtq9M2javiF30Z9jRhGrwi5kyVO6lHH5RsbaiaUFe Yd52k+2AkG80aUHKNIg937oToCxAWYCy2LwwvHkZRk1GcAuGSQvyihq7GS86PNhsOU/dZnthuK9s gU3BQdUl72yW71fJNpwHz0d2waqKsk4w1rZibWvAktq7d4H2TlqnZJKDta1Ug7x4bWttsgs9jewV AAWgWePswngYL5tMuSFNPbGXhxwO1SQmnw9174VT7bPV1FCR9YdrZRooa1HWoqxFWbvuyh5f6vhK BdSJZur4Vv0SKfklEfWV5LqN0YWRQHgdJr0OmLRgZwwQAYgARDYPIrh3uHe4d5u/d/XrSbwLFrfs vft/XDD60hsvWRWTEiscC+17rhmI8gI3fLAFBAhMCEwITAhM61aVcdNrR9J3W7Rcs7jMkHjMyACQ VsrViSExrWazEEawgbEkajP/WuEBeNBH40bRJNQnLafd71eY8zkYLMJgEfpoyTRYPEjs4P0m74J1 Pa3V2AvIDJ90OGOlNfHatKqFRk54ZQutaaFl5HcyEGGQzJ880hSS8BY00yh5UPKg5EHJ8+NLnroo AZs4gTKY+SFwOZOM9IqxfLSHG7nSMfoOdq/jksiqDYE0QBogDZDmxyNNTbSCN02ubmaGCRgyKCBV 6zzWSrWrq/Qw8m6UK+RNeK/eIo/AzAG40lf2TED+jvwd+Tvy95fn74Vrxocy4PmP1C2JF7ouC3hm To1ICJAQICF45YSgfnJCK6wUlF01IRawZXxxy3gRvW18G7WKYXHQJAclSjEcKwyg7EHZg7IHZc/L yx4rrNQ3u7il0VraNLPOu62vMWOQ2yXwD03N8L+nKhgqEUzHtL0NhDbEvxD/8gm85g5pZHbI7JDZ IbN7eWb3+U4Fy2y1tWXoDQmzF2ZVP/368ff/Oct2D0krYUJsQmxCbEJsenlsYi3uIt0pjE/4IrHp Kp8yMs89aXWPODejZeB3IW0MDfx7p9c9NItDXSrtaHEoLZ/ec9p7nf51u3/c7h232/9tcUof0T+L tOdeXfKm0XbvtHv0/j3/LP7imSJzyHa7v9/pn50mL0+XO23fkvGHYzqNa/U1HrBX3SQKk4Ej/tNE 3tLITRiIYTie+CqmmZt/em8TkVL2jziW094q+k/6ivl9wsczyY5n+XAKT+zqTI3k1I+XX36Z+5L5 yelgVLp9ssyflDbeV0SVo27FIGLncL9iqWa316vYqQmbVNikwib1VFM4MNtkO2bBLMeM9Bo33Veg 2R3K68gbfvFpRal/G0ZefEemNXE40UJ9VcMpQ49VKhiMoSfJAHcfwJ1h8L9S+DUovgDIdNMyKLYy FZPDbHFSUmY4wkO/H8j6KN1jy4NYfhjcgmlene0gD0EegjzkOXnIuxG1+KrqoiJVzQJ0eQEnQQxd +6a+fEnNuUPFZTygaG0dBSV/dBaMP4Rf2ZE4QPMMzWnYuEl47t5LahcvPiEgEUYxXwljmgTwBngD vJ8D3lZYKRAi1cWpAzu7WgNBglZDYRuX/2UpEn/fNsy1ng5KSwA6AJ0V00YwJsSCLzDXGXE/iJSm nW9DZfu7FoBsPfapCGG0L4ww3Giem0MFYcpAppwkGxM+inTXzBuyIQTMrAiqqG1Q26C2+RG1TT1G OIv7w9wBwsBiAdbW2S6JJkukz1WcBahlh/ApllGcNMV2tAM6SKt6+XWtN7zrI0YLK+sKPtc6JJLF 8SxNLimkGYvrtT7v+jzg3qLMg7SH4eg84nsbP05Ihln7sGZ94qCiIIlfLecAFQUqClTUjIqKQyt+ Nit1qHrrNetxNSQbLs4Ti3RGxr3HC7zYk773TTWmOvo19F0em6r0X6hz8rgQ+ZA5InNE5ohhypcP U36++O3s4+e/fv34P2d/XV98ODfbtjRzagCYBrETtOkzEUA3JctEVkFKKvV14lF732Sb1geP/AL5 BfIL5Bcvzy9sDQ33c40fOstrFrZKQ7Y5nwSA4cCJHYCxT1p78qSFiPTyiGQlOiUUcg16rg2TbVqf KtJXO3pCfAnx5SbEl7h3uHcoG5GkrZ2kDQ7edi3krm8+RgzrdSQDPfa0XjY8WlLC1VgDGY7MZM0H sgH0hlLH4tJMctrzRYASQAmgZPNQgnuHe4d7t/l7Vzf/Psp2liZoxzKQt2QunHj60S70QifnOJcl ISdg/6wy72PQOqB1NkHr1C82NaTmnGovuF3nve76TGGxitrYBC1ZD1MhbhwepOvS6QiZWjjQwKl1 UkiEkQgjEUYivDaXWRKDRGN0tL9MRyMVKbeIzivgdWsxrjEondQZmqWhBC8ZAMU8w8J+QoAZ1DSZ 5St0TdA1faOHIbc05eFYf4NPkHUklIvPZ4DvbBPpAmSpce8ssZvLDenMNqgIaquxqjaDm9mqlbfA G+AN8IZOAKuZ9UkLC/N8lbM/PursV6z2owMzy8zKeXin3T6s2kLY7vcr1hDC6wVeL7lEp5ROSOY0 L68+vju9vvjfczO1e/XX+f9dXly9u774+NunSsKhHo6RgzTTsdKbZmWDCaWg7lUQJ0Oc3FG1zuO5 LPaZtdmWsNPswF29vDW3BneC5a3MG1pIc9jtVKyZBRaZdVGaihzuzNC+Zt7JRUuweEOO7wW8pzlZ qsV/uZr69AVarxUmNH1aIeaWTXX43629f+vQ7Hz+t1mYuH3rm/kip2scs9tYiz2P1fR4TdBqZiRv xedm4ZWxsOLNr9niV7rlxZzF0mORu9bdZ1xrc6sLL076RRvwzMu3eGsqnYZZAps0smeCKn60sm/x n7/Dwnb7XLITRCJQKsrq7TsVhR4SgYTutrIjZ793YGpoemxJ7/Z9E4H9Z0SM7U8E6KbTfTSbRg+e 8QbrGRJLy+ZCrakbkhw1CGNxJ+9pO3kg5DD26E8ZiW4KrFmLF+GVn5kyNSo8KxYKvnr3dnPRp/eM 6LOt4dWUWad3klbNZ8H18Blvjy8KSBDT1bZgHrnPj8x9MpIg+T15igeMWumjmLuzR898qKOsBLDY h/SLdrGwI0VUacYwq9iFZVs1m15Je/E3j0Ka5dbMWc0WtPL+GucHJAxXKL1KMxCUXssB1+keEmVq 0LYscfv+pVe0ffxpAa73nxkCgevLjxlwfTtw/cD0Sp7Y82gYE3BrlNkRMc9U8DP9nAD58iZxo5yj nMlQrd+JT63A795p9+j9+xbKhxtKKRFmTlrA70T6mxUx/Lu5HVkdQu3hdnprsi8VlSa4d+XMHfLm 5UiDe2ffu/rNgJ/L4Z3wAlKYjORQcTYQCz2dTMIo1saZwtNiGAYj73ZKQ23iwYvvqG1NDQL/UYSB 2Q7POUFsCJak04rIlFPWwp1iUQEGhS8UvhQxslGmUuLRCiuU7yzuoamJImqcGQCu835r6lChh+FE sTVkapY0OxNhviOMYuqGdiV4sdrzwyEtRscA8Uo2E7AD2IEpEgaISweI9Vj6fvU20RoPEcvAFa4a ScJfzX1KUtN/ScCF18ClyOPL6Jb8KgxJOn+BBdXgYuwJD0APoAfQ8xzoYYEFZblTTURLGBDB8nCn uDfDlAxnyETERLTQZhIGrp6RMBS5uHvzvUbewBCDIWZFwCSkKXmnQ8N4FbIJKCsMk8FZACbTSO9Z LI3bdhVcPHDDsfQCK7MrIZ12nYQZmI7+jLGn4YlA043nEYoD50lqoL4ZFrWEE9yIzI1ApyzfVkqh 4hLq8SIQOhwT2kqtlqy36az4/eaObP35Wqd9fNApPrL2ead3emoUD1t9ZIM31g2hqLd8IE+bTKzn MxSELs3UjOWj0HcyoqEaU14K6cd34fT2jlM2EszSN8ZqfKMizb5V1Sf7pAkuetra7f8mj1SmCdj9 2xmo+CGMvlDA4k6k6xmzzSAW0yDZojOJ1Mj7qvRbQdfYpM58jU2KPO9yFvQ05RrH/6T5MsfZ7eMf /G6dqLihY3RzJElakvxR/dQ+aTDG6e74sV29PxXdbrv3Z/XBrD9SUwfksLOODDnAnoE9q6gwnX67 wjIGdarF86/yTs3qVNw73Dvcu80b++Pe4d7h3uHelXcZnKNuhXVO53C/IiGCC0WjXCi2kF5Fnlk8 uwV1BNQRUEesUEcMfp164ic5nvws/qN8TTR5/tf514lHEgjxbhJ5vuh03ohO2+nmX8F//uOSNqwK 52CJg8NoCkZTVph3YTTlR4ymoORFyYuSd/Ml7+5qcS54HpU6vXtnEZmfL6K7+TsbWRb++jiMQ+qo c17QWWzBAf4B/4B/Sp9/Uw/iigRvm6hEAP+Af8D/5uEf9w73Dvdu8/duZ9PuEjn00hKSYTge066t K3aH/hTLKM7E42lTalcnAN4FxvAmGQQw2l1S6ZKcNCSZLo1l0dumoRgezRoZ55swEmP+lmWpj4pj RX6N3gd6H5uoOGofgevqhWOmXO2Rm9rOYAnxnhCErNTGE1/NlquIHPosYI4k+5vg1seob69iJBUw A5gBzKxosa+b6NcVZmb2Yla2XlOkKfmwE0MJYzAxZVyhCcWcu5r5Ltvg+NyIkbwNzH80IGUdGSgm UEygmEAx8ZbvTrpfRX97DvIwiVKe+pqATWmyzbUkE6g0CUwuOQhL4F1mrjXtfr9CQQ+h148Qeu0q 7+JLHV+pwCWy12Xl6C+0GuVLYq9akj0tceJ1TZVNbmgF12alyYlvR+o5nGTF1mlkGXC+J0L+QAsd kUnef+OJazrOuwedM+MxE2nPvcwt+jALQBLPqWxXdNlys75jtkpj6CjxNSNXswoOiQ6sal9cu31Y dagAIk+etF4lP84bjn2KHyl3TEfkT9PupRpRuA+GiusXusWp61J2j7PvWheZX2ZeDB0hdIQr8m1k l8gu5yGlzGZOiIvL+96eF+zx74JikZzoqU9kW0hChN8/Xc+8YHMsHdfJ5PiaLuUVEoUvB/qytAed IHSC0Al6Dh9nFTklJZ/RfiX0765KvsLIu/UC6a/zdnfd9rWEypg1w9IFsESnksqNHFCnEe2DI4kC GVnGdEYGlqTr0vStFp4t0siq4JfUuXZZjDoX6yixjrIscvN9g9k4JX47izvTmMg81WDYSXdWiDn8 ZJqDFVURYAdL3+IWcXLJdgrQq69Gr2YNDWvJeJ5zfR8GtFbr4VjqoeedtE4pncyRQoo6bu/0Zv/X E01QkgI3ppsXqCFl7zJ6bDLwhNl+a3EpyUL+w/XvZCNP4HOvotnGpURpkrJsZCZAhvFBGFunhpoH 2jdo316ltwfwYSnA1W5h74AyfiuAlrCKNaXZMj5tZFaRZLxjrvyZyOEXFZPmOl//WAcGxAHiAHGA OC9XW1thpSQO16C7Y7XU13nPNcUe6euQVo/54YMmxYAR0c9LG1ITRGpM1Y8BJtYXfJxwr8c6L0AP oAfQA+gB9Kw35zRYmkkqQdmaIk4KLzxXyo2e0nJHMOuWLcc02xrdcHnnKuS2kNuuUPlBbpvrrAxp bXu+2WIahvobUWZGTlE9pQltQbzbmrbFRkWzkEdPJ5OQLOmokCEu7ZrAp0i/ZrQGrKJO4GlKLgeG d0PRsyLOQk0NNTXU1GWaPMgLBndK0gy1FUObBT7Z1E6ZuM06GnBq4NTAqW2eU3vuvTtTBP/t9i9n B+cHByxCNE34MzWSUz/OjeWn3zETDOmLMal/kxWgvspxGYfdTsUiU0zqa354NKkDmEwjPeWIahV6 2vgB9L1AkfHS/uwvV1OfviCncZiWsMmQgKt8erXnnrQO+vzv6AV3If2QwL93et1D889dGfPPoqU5 e057r9O/bvePnYPjdvu/6Y/aPkFnY5iK+edHphRP//yMLJf+2bJoKP2iHdm2XcVLp3GtvsaDz2T7 lbUzU+swkmnmXdpX24b9U729fcsZWfYD+c+JvwN95fk+D/ZpZucOnCid0sak25ZMutFjT48r40TP eUacMVTzFq+iNjc9e4PGUemJQFjPQFo6FGFsJ0pKWVbEU/rxJXHG+tebLBDPdSVcCyO68iNT5k7R 7cHJ3CoHnFoPdOWia7fu0XX/GW+wYdHVVZnfj6Lg6eb8fxIlXrlmItOW0ANlEuF18lawFsnM6MF+ v8K0D9nolmSjXsDzoyYbNXTbE5O1bc1GqSNyGZ3e8fK07O31nhktUw8ImH+CUqxoJOz3DkzYI4Yj e1qeRSlmlFvye/IUJ0zJItPYO3zmQx3RragXU1VaYA2jUJvdGzcqflDEZrneyLiSGvlKbjbMyFU0 6Vl+XEHlHLSPOr/wZ7bY1rBTB9PWSF/MGRti0DJcoq2RiA3t4u57xSB6QpeCzdHawcZpH3f7W93W KEgQ1u/azN8eLucNBTNczpOW0z2kFuFK5yDne13OqgRhntQnbccnJvWGIzD/kdqfbV9XkjKsActO eZJuzoaqsUd2OEym5up6RvPYpE/UdqKwloEviwlS2//tf69+7A3JzWfxvWz9//CSrCwZw6cFz+bD 0nKsTNI1+5joI6NnmN9d7lF+Wrfk0MCPOaCtP6WBF5DeYCSHtndD4Sk8u6Wy9adQ8qzI5EZHamg9 /YWH8zTKd6cekTUejWfzwVv/aAy8exbmPOGaPI3MOtqhYFFyTR48khtNYzEOqb4lsCiaLl+Oqc8l xRIo3er0wKhOViPK09iTXQoXJQ9JdQR9Qo3nHDu5I9nJtOqf17+ciQ+kLPV47+EsvGhaCuGHAZmW 02QtOdlxfsJ7W4UfDqUvPpyK1KL7X9aB7mhyWfysvC3LyKqWsOUytvUratZB5oLwLj5MxceYFSnW g1KUuxytLzp06Ob15oi1i4c10Eq51WfytJS/5AE6OncOO05r65Oc4gfIvoYFkz56ony/yEeIC9xd ee+DXKPe3npQ9o7nng67+sEu8BRpiU8LIqx7sQAqu/KBFj/MbL5nNgmbut96n4Uxcf1ilyhZ+j8W 0pvHIR8Td+XIBikrIqOINsHbt6DwdJ5W7eai49bfmEFZ8l6YfMxCwTz1OHpaLZz0KsyxbP3ZFN8s Gybmj8tcD3e0fkls9zcsxtReIGO7o6aX7iwZ4cq1L9NW0haqludzCRfUGA454dfhG45OHJyeov16 8sFkIWr1zELuFNEERp9ps32mgibw0fqM0TyK7I5K7Gh9Smj+9hgycDlxOTd7OQmfzEOX/L5KJXb0 BFJvJtwweVCGUZYJ+i7DfEnyJBYaycZiwp1OfCbSFz1b34hpkLDsyn1DpKGpZQL18AMyhiskB6WD PZCQL0fcTYpQZsnBVqb1FBot+ffR+lw0gN3prBYyQXpZIHnbmLprXtL3n9AzaCqwU088tR0UiXOW oZa+c2VfgdMpN4A6AWLRdKniBsWi24zT+RrG3I6s4Fh2elpFNaYyzuwfr06acRlXipSB7T8S22eX MQfi6ze5ufG/3WMV2YWm95ndRos7MKzCNsvGSgkCFnLw0rBCp+MwWTjGavT5quW0nUceHtzptZqd eV1z/wlNTue4U9Lk3BUle/H5shqkVHCUuyrrdzznV2VdImtHTjDLXGnT0N4PYJzOkubdUb/dOTtr ZXd4NaKmL0Z6i/T2FdPbXJhYv/lPYaLjGNnItvao5oiae4NPaOXPUoZ6xsFiPBGG0N+bTYbpHCyn 0l3B2l+j380iKkdT0rXTf9JXyk/LfGf3Uph0rn0miM/7tJFbC0X6taYE5xem/IRS1DizoGTbjy17 CjjPSxZXpEkdJ30/AGgrKCNgKqpUe7IflFEqI1ts7fSfoNmYwT2HI2g2ljuIoH9+JP2TJXPJ76s0 G/0naDash7qYd9llSC5N8Yp2ThHbsgKsraRn/Y4wTSelVcK6SU9uJcEuiF81yfJp0I15KpvDMpnQ mgfqtJ/Qjqz5M5sI2LOckg8wV1nw7Tf4k9Era3Y7KlJGNDaQMiJlNClNsoCTbx0X6gnaJr/j3sVc 609C2mCKVYNYNYhVgytWDQ4O3u5z9MiRZoUDaEXTt7vV9hwQPXilhmqyZBtCsSIKw9F5xIVF/Dih /UW3kRzPZu6K6w2TJ+8eSSqI8+ME2FhCsOGWuJQ8s7o0jIn8LecGDBwBjmwCR1A3YZfnamG64/Tb FbsOnQ5tO6z4KaDarbqpfmKu3ydkPUmOgirxlZPBAu2VSLfMHPjCZNjIixZsOBGVEJUq4gmiEo1g /KYemHkYEvFwGk4jL/2S4ez0N/pOjrmhXazfyuqyjM2pX1RqSKnpKprIGdNWXbuqalahSeulqNsS kVG1CELTfJFDLr/NlqqbKW+oWG7HWA8IcAe4A9zZ/GZ74A5h9fLuoK1n/FJ7NSuGNgtzbqRWLpvu 85YEpjl57MIAjlZ/T1UwVIJysKmiPbNakK3kkIyk6QVeYJ0ZcAe4A9wB7kgivZM++6pqjXpGpfot K6yUhOIatNY+qSF31cTB287bdd5y2lpDnEWcRZzdfJzFvcO9w73b/L2rX119MXcFmE0iioTmSzwB bK31QtPJShUQlBCUEJQQlFB0rVdzDmYB1wqjJUVmTcWM80Yb79xYaDfRbAptmUiaTLltqUWLRgE+ AB+AD8AH4LMm+CSZfIORJ50lDdTXWNx5tyx08OWjihaOZL6vx2k/wQWvfbzfKV71lNuWss1jt2WU uN2g47WUZgYhdayxDo8wOd3mWqsBjGWXmvwzsr5THk9s7xc/Izsymh0PaCPRREb0DEx9ad+c+YdP WRx14z2XVk+01zfHKzkda2QpbfKfJSY+O3Jo2cD1e5JVqa9yTFtd+dZkX+Y/5+awd5ZxGtDaiTm3 NHOcXAwQGFLCkBLZ3MTyJlPX2uPhkCVTXgJZcjKmWZaTiEXn2sJx0Bq06RuftE+10sbieM8L9ozV MUnC5ERT+sH6haJpmEiNQ1pVykplgM+KUIsJWUzIbmJCdmcz2lKN2NL6FivO5P28nPbTbH8LKIQV BVDOj3ObmYWs0nnDx5T9hf9slT30jVnV+CQr4Se6oO3WoZU8gw933vBOSF+HNDGawB337T/OrDJK j3lHmZnl5dsoJFFIrshuMHWfDbNSVP1u860UtHHvcO9w76i+JJJGXIVjiRy6bCqeTcoO3h4sZMd1 5WqoTXQdyUCPPa2JmljnXddU40OGZRenH3gvlfEtU1rL24XBegAJ5DuQ72xevoN7h3uHe7f5e1c/ EvQ69eWfiZrFrQpUJGNKjWXgijjJhWiqX4qAUuVcRjBOMgIrQ0JgQmBCYEJggp53TT0vTU8EioYl rCjarFmS68gbfvEVtUDIKUYbpElRx1TgXJAvgZQXDP0pLemxjg3gA/AB+AB8AD5rgo9sMr1JCrTQ 9YJbXsygJPXhte+Zvz94gRs+kDeZcclcLnhspx2ADkAHoLN50MG9w73Dvdv8vasfBXpeBP5amPyA PEqnmpOEdI/D5yQ3UEEcPb4RrhqR1zhsTCuWnkCiDok65DUr5DUl8uDGzEc908a0dlC0zHPS9uy5 n1sKPuSc7bvUjwP5ycbwZSOoAB2AziZAB3Uo6lDUoZuvQ3HvcO9w73DvyjNA56jbWf2EdA73K1a6 dns9kBsqNyrltPv9ilPFzN6PmNnb2WJ38OvUEz+RYdbP4j/K1+pR5H+df514EWlN300izxedzhvR aTvd/Cv4z39c0uiJcHp/Qu+DkpcmYSchrXpFKNKePGkhBUAKkFwI2j5fkaz0nV57dUrktNuHvaqX IAV4lXu3uynARUB7mQMV751FchQvorv5O8+YFv76OIzDG3LTo7ygA/gH/AP+6QSU1PE7wH8VUoEB sGxZAf/77RbdHp9UO1dTX5205DQOk2xne63XmOlmI1Uw3mC8KzJz2C7DdpmqhMR22acc4UoFroqU y/zZL5GSX/5tNBNNFxyNQt8PH2wBTU2HLgfHKJpQNKFo2sai6eiw+777C2ekkfbcqyKP4KszNZK0 ruek1W73TrtH799nL7/kL6U/gYO6yRENFapX6eKoBqhIIlA0oWhqzeqkk1ansmjKL1Lq8fNJZdVd GJ20Av/e6XUPzQ9zyVOGfhixeHtOe6/Tv+ZVQT2zSMkkJdH7MCCxK/1jPfS8k9ZpOI1yjdTXZDx2 lngtzfM+LWnL85/h4TM+Q445URbJFkLT9tbWJl7S40e1NVXYeAevccvW+QyyB8uCSPOBJbXOFgYP eluDNk2Ru7Rpj9204jsZm4lyrZS759HUmBZt9thazM/N8r1CsueJ+YL9cuQLvX2nQrp02O1UCMLQ YzXZpaaVRjwWSWg9otYexXuGDOZVn5ovHD0Da7Y/X8ijaf8Z79DCot0KeqU5R1F314p9JQxMDRaA BWG8zjutqZF0atbFc9IGAOc7Tt4KZwEhrWMiEAQYHt+zn5FVkmK2bfFEdlhznIMKx6Bo7Yrn/Dtc fxf3nB4AGMaPE0qsbiM5rgEYLm50LIH9moJhrvqTpGjfu/FiMQ20d5sYicTqVkVvxZLSDTgIHKy3 4D2PEp1nlEw7VRQ63We8Q+BgrXBwRg1aNU+z0LCIFJWit2/BonU+qAlviGlDTVjrOdQ8Fq6/enhe Me0WFq6/J3j+DoGFNcNCU/j8f/audqlxLMm+yg3/6J6JBdaSjQ304liKjym6iioHMNOz09GxcZGu bW3Jkke6xlC/9kF2X26fZPPqw+ja+nAVlMHyqYhuwKgoJN/MPHnyZKbm6WsaCXt7rLVAei6WBSkx NA92tYeBsIewV/ue52zYq6eOKHuHz1bZoC4YyKR5Z0P1IUT+aV6+piGvoCS8RHtqz6I04ulS2Fzl 7JmgItFcIZseEMhpCydmQh6znFUbrS6pX6N0qmjQqNHu7EeSajqwdM0LyGNs4dJxdWwacWLUUx6T vcOXlcckdq4bf5QsvmGhID2OW/Ege5eDuT5ClYmYY9OgeYfm/QaRWHCH0ThgdsOkz5q0FW3hauU8 0x+kPo87RumV7+8c1Z8iXGj7sKJ3Ai707blQs56iCjLsNEiYLyuq2GQXWoA0I+mh7k1njhwlejRa cUzT5X43dlhnf7+1/0fGz5rkZz+TYCGYOaHYgYtVkbQICGFW5oJMr971+qwDqme9PnuHL1uvr6uL nePTVrQkkR5ghGtfCI5W9MImnIByUeiFXcZh6G3JqZq/fPL+BjvRKBnEAKGcNx8y+hrJ6N+w3WXa imtSspnpxemCskUNtOpjShHZjdjmKg2xjZQAM5qXRDTknT/1bLUxW720sDD7T86eiGCfTPvpVeCJ 4FhKHaqCzAqlGwC94iwbFOMytH2VKg0Cjj6gxSJ5SnZmS1Q0C7+S6UdvGNGwySvfswiTCDyVRM49 S07ECSfCdTMhZxL4/uA8COgXqJVULt4CeeV4Kz2QTe+i6v1ZDyk5b7xqi0tuEwEHjcIV1XqMSP0B I1Jhd7A72N36N/FsI7OwLTjPFduB8IpK9mBdFOsivKEcpYTLjFpG/RmLiJZvT4hUJrQ8Z/ata+Nk L0l4+MNWJDwF5rD7zfnvhr/dW5rfAkkDSQNJrx9Jw+5gd7C79dtd/TLYaMBXFVStySg3mmJNbSir 3Oym1yEKYPmNaszxfG/3qwj8WDee1MvVkNOFJh69koGIg4iDiLP+iAO7g93B7tZvd/VDenfTwUAt V6wUQy6WLDaVmhtP3CqsF93qpoO9XuU7WhP8Tls8vghaurXlElfBrRFTg5ijcZSBmAQipM77kHGC 8P+cCs8SzJuO70SgHX8gCSAJIAkgCbWf44fLW2sScfxtZos4iwOuWoSjRZIcVWtdMOO7BCT3Y6ix 0m1vOn4sIAuJGTRongQJWxh3XearuRIKdtBuQDXRR3s0wBbAFsAWwBYvgi1uSUmmeZcaxxvnZzla 6V5rGmRUGkvwAtzU0VIDWE24qZS0AU+R9hZqyxExhmqrxlChDfdtteGCp3iacfDmtfUFiepsV829 +JftwYxbARh7YBiUQRaNr8Q0KEyD8hoEKUcntI5Vn2VBrz57vIVi9NQMcjB7YPbA7IHZW5nZ6+3v daoASk1QN1VHroUlJtLxvVVuuaYcHs1Xuzy96t93mFKRX4kw5EMRag8EUQRRBFFk/VEEdge7g92t 3+7qpx4/8aLoPvCDGQ9sUoJQvcqiUC9CFulRMwhgHCOAWJ5K9b2AMJJzD0RQupcNfA74nHXwOfXz TFqikSMVqUmyKf1VbrSmKaYtpAioyiOYM2AUUkacuh28R+aJWRSWxlNXOhYPZSJZjTSKSdxhPvog UElQVPnEr/1OcugL1qgvWMUhZ0Z8b2ofpa/6Rle5100PPig5I0WRCBTqCQjCUiehw48b6ydPQFqC tARpuX67qx81sERazvPIUCWSvDB/jBJMz9cXacEvwS/BL8EvrSyFKdArV89CrwlleSeqlwKoW930 vLHgfU74R5sNAn8cBRtnOLrzA8cb0hBGO+IyFYmZ7Ccc+C5tLaRvaqk2gg6CDoIOgg6CzmpDa3qW 79mOUmTqCsSCwmBNQ8/Id20mg6k4QjBBEw1KX2A04+LnodGpABMHLbP8CrPbPii/Ai3taGl/2tr5 mpWE+jGaaiKXmo+TI7d0PMud2qTH5LFUM15Exkixmb6iBvwDDwAPAA+8Mh6on1+ijfeV8xdqwmqq qcuaF92u1NL2KcRQaYxKZPeCWE3LD2j+9ERl3cRrhq4TfUx2f9JY6oAITo96AYT2zEBrgtYszyIM 47BZkWgY5oHZrvgprW67WXFJu7MfZUV0JmnaRqi0siFNLVPHeXbEB6Q8Pm40lSjGJQEyzU6mH5h8 cT116QU+lX78TwRqYgI59wtfjWOnvxxazvJsBiDi6BF/pQd0/3xac4sij2qvnjdg6eNxymMQvC28 bYUThLd9oiwwPCd2zNqgSvB+ug8xms1uFZnaPDysYFOBcpwfYHf1y6/NhPfzRKwhiTvgkm43LbOa HTmewp6OfdwwCB4rGDqVI59ArOfeG51WN4KvNpcKyzYNc9do7pqHt83DI7Nz1Gz+oxFBWPprQejY 1wR9mwfd1kXrXfz6m0W4BN7zdTg7OjFBWIgekLrH/InLmYad7IPc/6YH2d3sB9lztCNV9cjmRfTs A+t80wPb8JPX2yl4YEFqR32VRDY7p62Di4tNtSQ1qV3t/9DudQU72tCH0MMyGFosF9yLRi+e5UFd 19pbj7RSh4SY4YEZHpjhcarQZ4bYIy+R8KIFAE0xePRHcy05UaUm5aN0RecqtzsHVhsaQfMBOaPD MRVsGAjKQQIVWjya0cFodSl31W6xqidTl11zsUDjij+sdMM1PQt/cvbEHktG+GsPAugC6AKkNTof 1lMiXAwqWSqj+01UxpZyP7ZwCffFrOPBcx+YxpYkFMqZoOxiY8hIehy34kH2Zrtu3ASZvqBiHKkE 6P/0ika1ajcdfWfzyFb201D+cgwIF/j+4DxQsF0+Tohor8cyvz/rogMgNCA0ILT1IzTYHewOdrd+ u6ufrKBVJitAue9IRkCd4HoOH10LSFfA0KoeByUxASFH7zxWMGJwMjT7ygeG0Ox/4yPoodzHvOn4 jup8M0eOSEAUcG8o0plXC+1id1PJnKi7DIEHgYfIMwQeBB4Enmgq+7cGnmQchD7wISeNqfEARoo2 WhzJufvFsp9i7CPd+2YVYyBVpR70RKoaK0qo4Xxr3nznZzla6aDXVEN0RxuhyNbvpmpRibB3V3oW mT6PTTX68cRd6VY3/W3v6e8oyh8of6D8gfLHeoRhNZGd00CTL0LqhH4OHq5zNhCyUEglMDd22GxE SEFNJaLX/jkVniVSmor4p0SNvD34cTtQBNRLWO+G9W6zBlEcr8kqAr4DvgO+A74/H77/NhJeOtt4 PheNZXa8RTKWZF24Gln5SPhvvpUn2v6mIR94JngmeCZ4pud7JjWpcTx1pWPRHt1kStOcn2Z3jwvb wGxx71hiJ8pH6a/CKUH8APHDK6cp9RN7a26lgPurQVVsjgRXud9NL40V6LdVNZwGdSl+8zZwrC8u cZ3OmER4PAx9y6G5G3akxyM0zC3p3GM4u1IZQegNvd1rMmMIORuqvqJJohM+5Grr5DYEnR7awBEu VBkB4eI1wwXoStCVoCtBVz6frjyJN0bOM+dsDcUZqBJLvMgLgnqC6Cr054+OrymZQH3gauGbhmwR exB7EHsQe54fezS3kuNZa6K/vRPxGMCyiSI1Ft/OVRdLtU9tqR2L0AZtDB1E3PXAd12fVokOtUOC 2IPYg9iz/tgDu4Pdwe5gd8WFUuOgVbHvEFskdR+CLZJvd1c24p1+VrHeCuutsN6qeL2VS1rfa+HZ agZFnw/FOxJXfYlb7nrvpw77iY8nv7APwg3FY7zyKvn/+cPEIcUWO5kEjstMc4fRXtaWdgl98bv6 mczo/oFkGFotFN9fWR4McABwgGR4/cnwxmoke5cebTv0hNw9C/hALkb36GvFhef++WxJX81QVfva Ef4R/hH+Ef5j9eWh0akIQ+DkXDF4mvtBD6xZ8cSazW7VQ20eHlYwnYZx2Dyo+IfMA7NdcUmr2676 ddud/ejXJUhKHSxhNC+Xxj1R2ZSMhEKNCGhvnpLruo5Hq8hM+oHJF9dTl17gU+nHv0WypzkAJzd/ kkU9QbA7zaroIFecZNjdJtvdxsLuggbJrVk3b/me7ajGpG0e/TfyXZvJYCqOkDwheSLwg8YlNC6F xw2AOIC4LUqe6gfijGR/5eXpVf++w6KxSyIMVaHU9qmiqoa+JYtQ0kFxvzme7c8Y9TopiTHwAPAA 8AA9gdfEA/XzS6qIo7mW+ja2xIPlf97m9FKFnVAIG2MxMBYDYzHUE3jNaAJlDpQ5FUU1lOZIS/JJ RKsALOJBTv1p4CQvffOySWVv/WgqQkCWv4HLEwtLBGaSXaYQJ29XzJBEvlRhpVySpmRQTknbZLir lswguSw3QnQToJsA3QTF3QSy0C1tUXLpCWc4uvODrU4vq4iEuuwwjpnZK/6w0g3XdNjSPXengj3t MC7BHtpjQtaDrKcccEGQmKY4lKYg6wG8kL0kedMcaQFTX9Nws5S2prtPZ/rO7ZynUhfY4VYP5opu ddNPQA/7T7H/9KkPwkALg8OPG+vvYARSB1IHUl+/3dVPZdJaoT4xc+SIxnarTVAB90gXF4/W1CAv PBI8EjwSPNLzhzmjNJGTKNd4rHPoOnbUZxyLqn/XwkrOo6gLZ5CUKpzKdV+1YA7yqcKdSoVrzd7t LSlM9f68Q6uqJVZ+VDS0Q8ACAQsELBCwfC15BL2k+cyuAkY1xogJ+/Ak5dka3PBuOhjEw2CtL0Lf n1WEjTe9yJQPFXP0LJpBgIACAQUCCgQUCCiS/9GEtmTiW1gKLUJqNRCepbew58SVGkMLbzpWU1Gd kBW2YUR6lh0WysCxpPvIXBoPgNiDpn/SAGII0Gu2adavHLtFxQ8lG9S86HbFHYgkc97vWpQ6ejs0 J4hmBZJcwvIDWsoyUfMTaZLunaMmCRExHqf0W6OOHU/cKkOvxxuvv6NgJMBIgJEAI7FyOl5AfCpM uGWjoPT0Ogco1JiQICYiFFKNf2hiGBSGQWEYFIZBJTwTRg1j1DBGDTdUTHi7W2ZogU4hjvttJLx0 hjAND57xgBa9MlvQ8Kcx7dUJ1QQooggkG/GQ0WeuIleZ74k5Z6Dl0UgwkWAiwUSC+fwEMxp6PnWl YymHE8+LiZ2R8kRqAvojpSR3gtxXICzh3Aub3T0yzlJF1g4cE+qhqIfSE0A9NFoe+JUexepClELE pLmVAh7oRvJAxnFwQ6eH9hYHfRbcaU2VnSr6PMFhKpgJqaCwYLckuPniCiadMeFkHoa+5dCkVJup jmSKRNySFIq0MwJMDEwMTAxM/HxMrLmVAodcg9AzCfwJH3K13nGVO970ENSjeRcndrzOkrvu4060 xYkiyWjOscQroBayIe3ZIMggyCDIIMggyKzYZ6B4bc2DFsTTTY8uBXlsOPKntD34jjIZGqAUUkNf IOydKMXRc5+rv97cUl4T1f+f8h/tySH2IPYg9iD2IPasGnsUeaS50O0KPkqLHocUCj8kKosSHsr6 YvKMZfI/So0uB1niTXtqCDwIPAg8CDwIPAg8NASdwkEiwirSO6n16LlxJpY3uVS/sR+pq9qfTKik Ix6ENVUsZJQXIfJATgA5AeQEsxhxhC8kJ8hhWxzPkQ53na8ikjPNFovOhJ5DJTB4clDwTfBN8E3w TS/smzS3UkBR1KDe7A9WudGaFgKyoibuDv2AdExjdPmhyw9dfujyI5/vh8cNdPmhy2+LuvxQVkBZ AWWF9ZcVYHewO9gd7I761fkdkTlRs5aGvIyDlll+Qsxu+6D8ilangxUoYoCVuTPkd8jv8rzMgdmu 8BCUECfDzAs9VbPZ7ZQ7IqyqDrGquuKIIN5p8R92126qqOXSaJ7rqSuOG3wq/fgMvd35Qyqv6weR PmeiePUJ3UEQOvb1caPZ7Jy2Di4u1E1FL/WDnBfPxIBT89vyd/qZl6KfrP6ZCD6GZQQ++EzNqhDv otMS0pCZaOvrER/Q+Cs6Wqmp0e4S2F3WTGF3nbZRkYl2W2ZFJgq7g90h3mWpiP32YUXSBLvLYcVa XQpPJIAuIc7aqN9lA9g17A52V24xJoXnCqOC3UVJJ/K7u9xqBVapY5X6Olapo26OunlFpDIOmxXJ qIF4t+p0UMQ7xDtSxaJ+h/pdBVsBvYoemVG/Qx0hS8OgjgA+E3zmaZjSB2ZE4xK+BK9SQmaDVwGv Al4ly98DZwJnQq9yDZ1YYecEcCZwJnBmNmaiD+hYD5rgM8Fngs/MNMZBnwl9JnRi2ZgJfaYaNaw1 T6BuvvJWTdTNUTdH3TyUJ8CZwJnAmdEZoJhALfTAmcCZwJnoR4hGsliEEU79aeDQgu1P4jtGGgNn AmcCZwJnYm6tTlWAz6w3ziTZWO4YFdUY/Hanw1AC0Hs/ddhPfDz5hX0QbigeWfbP+cPEoW2B7GQS OC4zzR1mNo1W9gr1+e99PhTMOPhDm+WvoIC6fYyciSd5Qzq3xN+iNSrB2eQ7AL1zho5ipKgOIwyM NvQ9qTTbPLQcR09W6VXBXw96by4EuPRo5pYn5O5ZQOO3FqN79LValZb757Ml/TvyYoQLTIR/KOfJ CKO9JVA0odKEShMqTag0YcJqwUYBKJqgaHp+pWlzYXdnjzGFq/s84GNBEDwEgAaABoB+5TwevLXO OYG3Bm+9jpbvjQ3k7GHsHqkJ9rQTYkLVMhHci0aP2LITL4rvAz+Y8cAmkmzMHU/SfyGTM5+FgphM f8BuA8f64go2meMARn+F0XZo4AHgAeCBV8YD9fNLmlshvjbw/cF5oAQM8nFCTmxI+ciN5IFMttvQ N5YXxLx9ZQPdF7ekc6+70YL7Pffsjb7bgiDEPZsFIn4MjJLMkW+HlHbejkRe2OGBYK4TSmFrRwSI GIgYQ27XvxwWkWdDI8+dcP2Z5kJrGnV6R9pdIlAgUCBQrD9QwO5gd7C79dtd/QBa//rzyent5d/O /1ML7AXwpQYkweXV5acoH17lfmtKEowdzxlPx3NGQDpjIquJqiYmm7s7jIfMFgPae2zTi9pzQuBB 4EHgQeBRQqZ4gPrsKPxaNOyS+OUCmjKSlmuepb4R5/fri9OO2ez8EVX55iQ1o88mfMil43t7qzyK JBjBBcMFwwWv3wXD7mB3sLv12x1y7o0vzF9enfx963Nu/oCcu4H+bj2Ior/7Av3d854Yqn4/eyoE cm415AY5d+F2GrhguOA4j3m7c6pUrt0PeooVw0ipTE85WnPQmoPWnO8pN2xdnfvDtifcgbCnns09 65FZvhdK7smFyjbTUKJWgkHg0UESAg8CDwLP9wQeqnRrnqW+de55ZXuV+62psqqwpo+AgoCC6uH6 q4ewO9gd7G79dlfnqv3t5dX59bbo5c//3r+8Prm9/PzpZtsZBW86VpOPMxNcZCScF2ppQqTjxEA3 NSWClsxRJZM6CRbWt4JEWHwiBhYikEGpxWMvUfpWWE9VjeoXe7aHRJAjLreYP/AtaxqwO0HzwASj dizq1KLA4g3VcLB5uxZ3h37gyNFYzRNdeFhq1tjsyLGPG4Z5qKyKT2kGTHDc8Nx7o9PqNtVrNpc0 9UdN8N81mrvm4W3z8Mg8OGo2/9HQrOe40WwedFsXrXfx64lxvT3JjpJ8nPyH9ijIGdCzULdjCzd9 JK3o9p/zSPJ2h54J8usb86TocdyKB9n7682temDpl+rzuOJOr2inQLvl6Dtv+RwUNBzdCTV+b/GE QFwAcUEJYAU8S/fCkgN9tjIR8GzzR+xJX3OhBcWseXGHQsk89BrPRSNaHKIfq0YUnm1i6C0IUZxR yjwVbEjz+wj6EeTjUfP9lkTo5sLJyiDZlvncs7NB+Ez2dths5FgjZjshv3NpG+e8sprtGdYe1xPa DRLLuNbM5c3Dtp7eAq1ihfqdsUsUu0Tv6EQvk4nAZj8Cm8HuUC5FuRTl0ufPd7k+x1yxCMHkDVuf J0gbitYKMhjMFfND4tW77YNyH9rqdNrlV6BUilIp9NbQW5c8gYUe5/nSh0IJcjlZB+QP5F8ek5Bx I+MuPyFAProPwXSXtycVUXGuniKx7cu4MVVsjKliyLiXhNaIO4g7U0wVe+kngIy7sLUDyB/IP84N MVRsnmBQH1QkQC/qhzo0OuX5tHFAyqd/VVWkoh8Bu4PdbYrd1a8ta9sybswUw0yxWI+IuIO4g7jz Iyv0hPkKVDbbtDsrrWprYvfyQnbdYEZhPR8Ve90HQzMFzdSP9Mhp5RB2B7srZ2WglPkRSpm6BXbG 5vwBJopFux6i2T2Ed/zBeaCU8fJxQnNKhgEf11Qwj4liZeQ2ZPILA9SM5uFhRUEAoQehhwBqUoUD hSB7mCj2jRPFTv6DBpBhWhI6tERmOBRCT+jw4wY6g5/fGbxFwyy/bVpSvZqBm0tjbFIyPzvFBmNf yjIgUNqgtEFpazgEkjg3+zxIQ9isIKObzW6VzhC8AsBdOmXLTM5T+LWk+bxQmvDb5aezz7/95/vP H8+2ZUOGIu+3fTVGOvnFdQZCLcVgNMCcha5jq9nlM8ez/RmjFZxSAO8B7zXI1UzUpByQCq9EKkDC AAlDBWrEZpofsJkGdge7g92tn0SH3cHuYHewu+JGWrTa6h4CvGI72hXmOp64nrokQ6StYX7sQ9Di jhb3vJUE3ZZZMfj3wGxXyEpgd7C71sHFheLI1IKjvtpc0zmNXlLMYTK7DqMlMtok2F3efpR2Zz8q +1Huk56WcMKtiJA/4gPaMEVHSx0zFeJoajnsDnaXrSx32kaF1hx2B7vDmq6szUCvBb0W9FpZiwCv Al4FOPP6TAz41JWZZA75XSICAc7MWW7Z6lI6Vjr50UB+F7MiiSHp+27TF2F3haNDYXewuyKFr6qX qyUZqJvr6A35HfI75HfI74p1BKjfoY6AOkLWQwBnAmcCZ2YtAnOtMNfqqblA8FCeoA+oqkUZfd/o +4ZeBXwm+EzituPuWZPkpBVFAtQRIrE2+Mw7OjXLeQj4TPCZ6+AzN3Z0d+/91GE/8fHkF/ZBuKF4 jJavpP87f5g4gQjZySRwXGaaO8xsGq30u+nH3/t8KJhx+Ie2xASlFZRWKoI3WvCfsmSLxoWc+k9L jSNtRPg1jWrVQ4sAAQABMHLm9aimTYUALtFz18KzRSBsFcjf0RTTL7Eyq3fpUReNJ+TuWUANNWm8 1z5e9T9qX8+/+GxJ/478GyEGE8CgZMUxchTkKOvIUQDIAcgByDEjpFjbg14W3UNA67TJWqdNBeSy 191j7MT64vkzV9hDMRaeDAGhAaHnhTGMM3+dceaA0HqAROqK1HUdqevGhvLCNQK3I8Fo4NrID0I2 86euzVzni2DSZ/wp8DNJV42EOxlMXWb54wgIMH/ArhWzJgEJAAkACegJvKbCtH6uSXMrJMVaXFcd ToTr3kgeyJhNCugdUJPc9AZlNcvt7c6RJA6kdxrwoSNWuttN387d22Hn4RefnTn/9WWHXXN3MmJn gT8Od1ifxjaws+lg8LjDPs+Exz44wR19/qsfCrrqWtj24472kACCAYLBI6+fR65fpDnjgeMzzbnU ON7cCluE1shZ6X5rEHG4Z7O+IAEBu+ceI30Bu5E+hZ/ZyLFGbEgyA+k+MmdMAONe2CrX0Z4MwgzC DMIMwszz93FrbiUnwAwDPq5BPmP71lQxRKvc7saHF6xZxJpFNdsbaxZfk/wCRgNGA0ZbP0aD3cHu YHewO0g5YwCItVOhSgew/ibdJJWWJDFOBONE5lkixonEEzLQS5zfKYyxdRhb99SQD16FusmpA6Yi z8DYOoytw9g64EzgTOBMzKyhkGl22xVLsoEzgTOBMxdhE3CmnBe0wWeCz+yr9eXgMxOJx377sCIT xRqO5fG3BsYjYzwymiTnmRnmJmBuAnAmcKY6A6ShkvwOOBM4M7u6CjhT9VtoubmBujnq5mXdBuAz Fy0GOBM4EzgTOBM480Jx2svTYdIXUTdH3XzOzgBnAmcCZ87NodnsVpQ8DOBM4EzgTOBM4EzgzPye BvCZ4DMDJ1GbQZ8JfeayOQBn+rRfg2A3Dy3H0bdw0qvoA0If0GJJDPpM1M1RN0fdPF6TyvOhN+rm M/CZ4DPBZ77dNQhqjlg/iLRwE3VSJ/RmRcW6nNYDxDvEO8S7mapnW5QRnfpT8CpZi0Df64JsErwK eJVUYU4fyW8sN2hhvoomNQavAl4FODMbVVG/Wy5YQCcGXgW8CngV8CoJffPUyQicSal5t2VWTGAC zgTOBM4EzgSfCT6zKGSCzwSfGWvrgTOBM/PIW+DMHEbbaHf2o7YlzFdB3+tywQN8JvhM1M2zmRdw JnAmcObBxUUjUqApORr4TK0qDpwJnHkEfebgqc+7vX/QLO97B84EzgTOBM4s2ZALfSb0mdBnZqIq cCZwJnBmNmYCZy52vhvGYbNCXIO+V/S9lgorMC8a86Kx/06j+NAHpD0O6DOhz4Q+M4tEwWeCzwSf mbUI1M1RN0fdHHXzYoYffCb4TPCZ2ZgJPhN8pqcmGI1OvHB51O2LzTWiKWL0jyyv/VHSrrfbTUGR pPd+6rCf+HjyC/sg3FA8suyf84eJE4iQnUwCx2WmucPMptHKXqE+/73Ph4K+80e0YjQaroYRa0vZ G1wRXNE6XJEacRgJS1OHhNGGkM5pZDNKmul+CDIRQIDepSdF4Am5exbwgVyM7tHXV/2Pua+zz5b0 76i2RbjARPiPhfx0qpb7wBD+Ef4R/rO5uXHQMss17WC8wXiD8QbjDcb7qRPIaHXbFfnMVk0k2Fzm 7WCPscuTTyfs1Cdu0hYBlw59BhQNFE0ZxMSnwX7Ydxxi33E5RgaK1jEyCUurwiP64N5sH9zGRnP2 MHaPwgm3xHFjQiUzEdyLRo84s9uRYLeBY31xBbuautKxeCiZP1GxngXin9OowMY9dtm/77DP8euf pmMi1fYABQAFAAXoCWAlLVbSLtLHaJlAywRaJrKEOlomlkQ3aM1Fay5ac5UAMuGTmt1oVm0xow7K 6ZUop/qlvu/P/z4XjWipLJ3GwPcH54ESzcrHCeXMw4CPbyQPZFLvo29sopqWW6SfsUbDVW733LM3 +maLKA9iP6R2/1Ak6hQlpECLuRwUiVAkkpdIOiVkkWdhu7u784gSfZ7+b3cXHgdc6RPMPTyskJbB 48DjrOJxGDudexzWNNTnmqepL5RtUu3q3dkqN5sAWcA8wLwKrQJm6T2NAXuxxhPYHewOdnfrjKlR +ZOYsWt/zNFpkS0MQSOmewhoxEhCTsmS63jieuoS/cqn0k/IyHgfTXDxZjViiHf6aQadCDpxHfGu fgUqpc0cOAHpMeXMZ3eODJnj2aTQlILJEaeX6YJIl+n5Nsk3/3pzy2wntHhgq29puTG8ErwSUPj6 UXj9vJLmVurLL5JW/ovQC8UFN1vTQrkzYI5kti9C72dJrQCWP/ScryryiLQ/QGkjdhj3onBD33Ao 8FCY0k4IAg8CDwIPAo/SvppJ61v49TSk/D6aQhO/Rl6isrquuZUCX1wDjVYK8fVO64L7rWnsmWc3 ScPZGZc8zm8+fb4lARv3aKKj8HYDfyoF+tCSDc2pSWnT1EC/gH5ZB/0CnAecB5y3fpwHu4Pdwe5g dyUtUxhkqCFilNdRXm+pqYWUL6kmrn5mAnk0mTyWGGAVOVaRVwTWdmc/alclDJaeFjVjx/GGdLRo VrUI6GilShaiv2B3sLus8K3TNir6QLAyK2dW+VYNEEV+h/yuIgyhbQFtC6VTRDCoXvchBkZsQj6d Inb6mFs4I5qgwu+CVwGvgvzuTAw4DY7NkCjgVUitoeajI79bXjSFBRGx0knldYpoRH6nYzPoVaBX gV4lyxKiPVb3EKjfoY6AOkLWQwBnAmcWKeqBM/PpHeBM4EzgzGwUAc4EzoRe5Rp8phIz5ZZEgDOB M4EzszGz1em0y6uEwJnAmcCZWZsBzgTOBM4EzizuWALOBM4EzszGTODMYz1oYg/cK+2Bg15FP4jI 75DfIb/Lxirkd7qHgF4FehXoVbIeAvkd8jvkd1mLQH6H/O6piVXwUJ4gv0P/XWYCy4HZrqg0AmcC ZwJnZqMqcCZwJnBm1iKAM4EzgTMXxxaUK7jAZ4LPhF4FehXoVdQoy2iwhWFSOlrhNVtdSsdKx1Jh jl/nNJuwXffVvNDmwovoR0A/AuwuciTh17QtpXqTFPpe83t4oFeBXgV6lSwngvwO+R3yO+R3yO+Q 38UJK3Bm+6A8dUcdAXUE1BFQRyiOmdCrhGqZFPYBgc9MSPP99mGFog16FehVoFfJcjPAmcCZbwNn 0q5IKj6ofZF6mU4F+SDeGBlcvLmtKoTPeu+nDvuJjye/sA/CDcUjy/45f5g4gQjZySRwXGaaO8xs Gq3sFerz3/t8KJhp/KHG1ctoaD1G1/PFQgJKK4tPxMBqsifvZdFGkFN/GjjJSyhp0gPBajK9+ILV ZG8viKZSgs2FAJce7SL2hNw9C2gt8WJ0j76+6n/MfZ19tqR/Ry6LcIGJ8E9or2g6KsI/wj+UFdns HcoKPbijQxMdmlnBbz8j91U8QrQQLgowUe2gKNDQMSqvzsLuYHf1UTRtLuw+3GPsRliU8stHdup7 RB6KgEuHPgOSBpKeq/qbh4dmhUcHkQYirbSZCkSaHvNBpIFIe+LaydU+m34nYM4exm4k6RHHjQmV zURwLxo94s20cE5APvD9wXmgKobycUIXDwM+vpE8kLGb39RS4u3ns897q9zruWerO8WwYN0pgSIE RQiKEBRhcREBFCEoQlCEWQ8BUSxEsRDFZi0ColiIYp/YMAwLJhkZSmJaLxqar9B8hWFS2ZiJ5qsl uTqGuM2OImiNYVJ3RFQvZxnAmcCZwJkasALO1B4HcCZwJnAmcGapMgU4Eziz9IAAZwJnAmdqwAo4 U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdq wAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJn AmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAA ZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz 9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4 Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJml MAI4Eziz9IAAZwJnAmdqwAo4U3scwJnAmcCZwJmlMAI4Eziz9IAAZwJnvg2cOTsKGP0XOva1FtZ6 /0av9oPow4XvyZCu4qHlOMeNU38aOK/728+OZO/91GE/8fHkF/ZBuKF4ZNk/5w8TJxAhO5kEjstM c4eZTaOVvUJ9/nufDwV9949/+1f1E9X/6Y7p/xN135P0wRw3ms3Oaevg4qKRvqQ9q/TFMzHgU1cu X97PvBT95PjBSn4XgSn6SD/inrsLRgHoDejd2e80KJSo85mclnDCLccb0onhAykCOlrqVLqOJ44b Znv+xfXUpRf4VPrq779lY1b2pgwCdtfQznt7/6AZv3dFDmK/fRidjuhw5LqQTtswy39Gt2UelF+B lLfeKS/5Bjo7mwgBLj1ygJ6Qu2cB+cLF6B59fdX/mPs6+2xJ/45QDOECM3KvCP/5KARuaBGXGcZh s8JnggEAAwAGQAHTiR8eN4xms1uBVIzm4WEFVIHdZdJuix5rNhOPTlv4NUWBZgIdw6+nKnWPksv4 NYLZUWIP2I14F5km7I4fN26dMdFFn8SMXftj7inPNTrxwmW668XsblNht8tDeS08WwTCVvzZu0Dw L3Gs6xnNPcauxYC+51kiBK4m4qUoeQeuBq5eh58BrQZarZzgA67+Ebh6U+O7VFHc0EI3ZXGB7w/O g4BgkXycUGFhGPDxjeSBjI+W+sYmMogEVz75wZhL516scsvnnr3RN8wexu6RqiDRWzihAqkI7kWj B8imSAqIMhbqz6BkQudVUkNANkA2QDZQMkoRVE3kEiQrCOukcLq+ODUOD8w/GKuCN+FEuG4NIN25 +3WlW910KNfbYdd7jHu2+vBuGo52WONGBA532afpWJW2TwJHjsZCOlaDrr04Zeok7GgPB5EGkQaR BpHm+ZEmo7I5mQ6noSRvc9jZg7dBCYC4oUQFgFIj8slSWYxx0KoQgZjddoX2CjwOeJzXbU9JpTUb WwIozSdNqhdtUT75LuC2JwINyOQURKL0uQY55c0e5ZEfqJ1q5gd2yAZ+wKahYI6nMsiQSZ9derZj canXS5BIIpFEIolE8kUTyWvxzym1cY6FJ9lHcU9tnkRkvTvtM6MdE1oqFO2wKx5YI5VudpFuqlY/ KM6QbgpSaZ6gfFnVdIB0U2s5pY7zipZTdHK8vWkINU83qUGZ0s0r/3GH/aqSk883/Qv2N0FyM99j JiGCm9sztp8iArp6Jxn7QIjgAIgAiEA1cwARABGQxg8jVbR4j9EOGO3w9vBMlaDJbHeaW0RAnwlS 9XjDrSCg8wsPBPHmSqeVHkMNZGzvHWqx9Fa62xpUHRrpKBfWD3zpW767M4f4He0hoNCAQgMKDSg0 vGih4U+X/fvOn9nNRFjOQBU3iVpINLMKbOywM2GJSFMLTqHTLjc/9LWjrx197dkJ6RC16ZAFVYZN HtNaU1Fbu9vaIk7hlEZ6cy2vqqukrYhROIkZBSIWVnoMNWAUtolHoua4xl8EyTYdi/W59UVIdjv1 PEFjsoekZdTecjAKengGgAeAXweArx+QyPTAKUKhgE/otsAnzEvyaNZBs87baNYBDAAMKGc2MScP c/LISyRrscqHrrTbbfAJCzMDa9EiV8wn7IBJ0GdE1uL9JiZBtUSqOTtXe+wv04nkxC3M5QqKSAt8 F4QC+o6gMqYn8Joq41oTClciDNW2ylQfxf50eXoVqRZUi7YcCerLjrdhzS+BU4JTglOCU5rFae23 LAcqk2BnWM60C6tD3qhQQaVSobRJ26RNumjJQkvWnP/FjGk0aaNJeyDnBoGWLLRkbV5LVsdsdkg+ RUNanHCH9YkwOXU5zY3ydtgtffF+6sTN21pKUiQ5qoHW5i8en3HXWel2N719p4gR/ZzQZr9+u8Sq rutmPvjfdiJyn8Omn5ceRpAjAZjjHSQAr5QA1JotbdwSIXpL6s8vrmAn7tCPViEkLV0KrDwREoYB QgL+CP5IPYHXrN5AfwX9FfRXP76xe3bkcmqCmB3dqxZqz9399FE99lTYpMywH6iAENA1G7jTMz8d paLFQuq1SbdX8Z5RtaanNn119vfVYJzfHFUJjpmX29GUVkHJmJOhUeaeTZ+fZCmZDzRWV9Bsves9 5GXAQcBBr42DNsvxVnumQn+cqSNvsGtO42ZhxTzDifedMHLMH8j/LtzyEtMXiSdrwITfyGDqfFnp bjed2Mw/6VFkZX/jYSimFJSrnkRNFqv/SjWgVW61nu95spZTewDIb5HfIr/98fltGpDrm8hmgNOJ Kx4op1PZXuO6//GIRX3H1/5UqkEHc62wkgh/9Ge7fX9GzZb0F6o9k3nQbJrvFBjOcAALL56JAZ+6 8rhBqr7T1sHFRXp5X72UXKxyqoRRmNzIR+LjE+rh/e3Vx34g6HcbcymFnbAQlexDceNV5sF89MPw kX0SktZYfVFrY9T+Y5UfZ4h/cwXif+GO+0HmztJnk3kM+uXf/RgITPK7SAeT2eViuYIH8/wsb5K1 fkXu2Cn9ktxlivoluQ3a+iW5AyP0S/bbh8sqL/2STttYXv2oX9Kl4f5LLlS/JFc+pV+SO35KvyR/ y8XiNXnbTBeuMQ6bVb+xYdLvXHFXRqtLI6MWN2cu/Fvtzv7yM9bGfZtmZz+xsvh8pT4yF5voZ/n6 RY5+zrHWfsO8U61dkHuotStyz7R2Re6R1q7IPdHaFbkHWrsi9zxrV+QeZ+2K3NOsXZF7mLUr8s/y wiV5R1m/JPck65fkHmT9ktxzrF+SHmM6k+lpCSfcUvFsdsQHlECTC1ZukGb5iOOGWTlLzfFCutqx jxtGq6X+Ip/KkU8/xXPvjU6rG/0wmxYa0g9rGuau0dw1O7eGeWQcHDWb/4jNLnh7mrxvMd4fEaKS Pujs421/7+O9i3zb3WmYW4nI/hP73/FPRNWMiNvNT9EJNyj6vNWKRIwaNlpFoxj95N57TkT7mHsr /fWntLfs13r3PTxR/Nvcjrj7zUtLy36XM/pd/u+//2fh7gIyp2V8qH5Ocjry3thCquyvHs3eDeWu QoXOw+4dD4UdI9orgpnR93T+hEyAzkZUvJqof3SS/jprQmk5JtD5jvMZH/6VTaD7Hf9E9JZUvy9c vV/0VOMC4Ldenz59DSpU/5DeiW0H1N4owsXTtcLf/b///t8Y3CvrpdLWdDgNJaM+o2V0v/JR0X7/ 9KZ+hAtNAxx9pH8mKsjqoC4PD+lX5AIi/ZJcRKRfkguJ9EtyMZF+SS4o0i/JRUX6JbmwSL8kFxfp l+QCI/2SfGS0eE0eNFq4JhcbLVyTC44WrslFRwvXpPAoQkfpodEQ1BLKV07SpksHThDKjxFq6ppJ OpHjwQ6+w71Uhu3D7/ihkfWr/5F5zN3St7j8F7HjHBvVHneeiWoX5FqodkWugWpX5NqndkWueWpX 5FqndkWucWpX5NqmdkWuaWpX5FqmdkW+YS5ckmeX+iW5ZqlfkmuV+iW5Rqlfktoknc30tCylLMb+ NyUtG55vfIflJQyisveEAkyfJX3MdXSwPO0YwvLq3TlI3mU5ydF59+vY7hZezCBX/TsRPw27ixKv IieDiBfnJZqrMVaJeLWOd7ohwe604wGkqaTV2iPJr/Lol7wQ0qyL3RELRbAvwy5mIlWStr5BlEwp QM9o7pkLVNaSvq8mOq89RnPH4hK+cy9Wuekn6nsz392CEsK1GIhAeNYCiQnQpvtB0BRLkeFN0RR1 CR6wO9hdozSxwzR3THMnL5EgyWJR4e+Xu1Wwpi69Gmd7jpCDle5201Fcb5emdru7pCYaO57v+sPH P7T7RvxA/ED8gFr/RdeMz5vAfiUxVeP2yffQSkKlz2eTSJ9/QtX6SL8OjxQX/3Orf8gkkUliTeGp 0jZHwrFY0bMKos20yWQaZOyAxNW7CgAuQaPdJg34Vo00WJ1ajgngk+CT4JOe6ZM01JOjv69J5YQq QkOlel7ldjc+2/4zbdESEynG1CNB4mzMXEQcycy8xwzYV5oBC5YLLFe5J0KV5EdUSWB3sDvY3frZ Zdgd7A52B7srbp5Es57uIbazWQ8quNLJXhkhNlr1ouKLJuRHyxBahtCqJzIEH+piqIutoy6G/E5H b7A72B3sLhuJkN/pHgL5XeX8yDfYZKrinFrShHinn2bEO8Q7xDvEu2J+F/EO8W5pUwH4zNJOWfCZ 4DPBZ2ajKnAmcCZwZtYiwKvomShwJnAmcGbWQ2C49LJSIH+vkyYmwKhNjNos6YLHqE2M2gzSFoUo iw+/6h3hs6Pwa1FHZlpH2NxRm++nDvuJjye/sA/CDcVjpredsfOHiUMtluxkEjguM80d1XrY0i5R q5/6fCiY2cIAoGTXRnp+tDiElBcpL1LeLKBFyouU9xtXUb5hKcHmQoBLj6b4eULunqkJNovRPfr6 qv8x93X22ZJ+MpJAn9gNZYVu3Aj/CP8I/wj/UFY8YxP1Gw7/iHeId+iMXn9n9ObC7pOpHPlB+DPL 394MhwKHAoeyfocCu4Pdwe7Wb3cbG8gL9pkx9qvvcTniHvttj1GZTZtTCi8DLwMvAy/z/PUYp05o +fAtJRIfUO+g3tdBvdcPwRjdJvtNhJLd8nBMQOYsWNxRCxwDHAMcAxzzfBxzQ/7lVz8UO+yUuw5t xPYcztjhvtFqA90A3ZCmcuKHxw2sOnilVQf1Qzd/vTmBZ4FngWehJyB4KE9eybMgh0AOgRwCOcTz c4j+yPfEEfuXdvOAtc02M/bbXYR4hHiE+FcO8fVLHs7H3HGP2H/53mjq/LulijB7lj+Gt4G3gbd5 ZW+DhAIJBRKK9ScUsDvYHexu/XZXP3R97VgjHtjJTBKAaoBqgOpXBtX1czI3jutYvsc+8rsQLgYu Bi4GLmYW49dvmQFHHf2FLSDmPrsd+eOQvEzf5ZaAm4GbgZuBm3lhN/POD6Xv7bArHobcGk1DIWXI WNM0jSZcDlwOXA5czgu7HIgny5lONJ2h6WwdTWeouaDmUu6JDOOweVBxiXlgtisuaXVpIUnpmrOt 2rRQPzo0FU92jK5qu2KGae4jeUDygOQBycMLJw+JeDKIq7x7X6LNE/8eOi5VYqCirIjEyCyQWSCz wCRpTJLGJOnshsTrMzHgU1fSSo2mvvKtn3lJrSia9INkU1FYtrGIVnBWJHwHLbP8CrPbrkg9W50O 4p3mzJqHhxVPFRl9urCNkLlFQyFO/enzd7iBSQOTVu7NYHewu/ITgnin+xCj2exWgQjEO4cfN9bf NYB4p59V8CrgVcCraKkI8jtthS8lxFUlUMQ73yPp4eyIh5bj6JnZK5dREO8Q78rRO/I75HflJwT5 ne5DkN9dIN5JqtqjjpDMJ+62zIqKB0ntKioewJkkNSS06Dr/z94drEQMQ1EYfhXxDSqjYMGFuBeZ NygYQRAdmo4DPr1J6jjNWKc7N37bLNsk/e8959y+hvX2Jdycd9vhbbyZ+1G78ifYIv86d2mblLng zl37ngdoVgXrv3Lkqu/ql6+f+eM4cMKH/uw+7PLHlW4+c2Gq7+o7RH2nvmvVd09DvjFxZtoJ6Tng zE1xUaZH0cfnx/XEXblfeuhnFvkz81Uyu4GuVs2C51F959y1zt3kS6S+U9/xq/CryAHJAckB5X+D Xq6uF8zGOHOmeDPZo4iKWT/I4iIdoe4B4kyciTNxJs7EmTgTZ842cBsT5Mb+7MVXQiR+3OUYRMHt cS1xJc40Ti1tiiIkNnKvcq+n0waN/F1lZ+SL5oueEqi5RvqZ+pk4c9qbMU/sOAOAM3Emzjw4OOXv Smosbjr9zClNmp/5e4cfZ+JMnIkzT7Rv9TMjzsSZODPvgaR17VNjOPNoGjvOxJnfcUK6eaWR71q6 ee2+1M/UzzwMbQhdHG5x5oLL/490808AAAD//+xVwW7bMAz9FcOHnQbUkhXHbusAQbZswLDBSHsb dlBsxRFgW4YkL2u/fqRso+7a2ZcddmgOiUiRzCNFPq7iwL/a3F6uLT96l+ufvEr9SpysD0KrTOqv WBLNW0SM0HmLdUjjeYuYMjZvkZBoASkJgvUCVBIkyQJWQpJgASyhAHceLQnXbAkui1YO7pUrvsFH MC3PZVNC7fnJCp36Ab5DJRuR+hQCDsKhq0DBO6t6FDrT6K33qrEGnU0uZervVKel0N43cUFPwY3d GslT/17WwqDaO6iaN3h53jbmpUsODTCN4jrFPIK9axQ6pGged/i3Ex3k5EDBbzuAAwNtZHHIMK0g 2oXxfu872P8teniYzedOeu943d54X0RlxIM3/Xz81UoNpdy2WlYepe89GpBwaoHn7xkvhUfZj1t8 6g1+w3thaTD9dizMpCyj6lmtRuUHceJdZV+aZxOVi9wXFibbNdffJhwma6GZ43BhaOiaLcxMGEUL I8PeqOgP6n2jogl7/TMqenXu4iDaswSJ0HHUZMSGm575RG4zPRrhtD33u4P7idbNYHmHdHlJfUIH Bj/DeRWP66Etv3IMaVULetaTvJblGSKN4lFZq+onGRf0k3QWvMBdsYa9BYFOSrnVMYhlZ4dN4lLI VYVUjYsGVgjaOHWh8k9aFnCDyyaTNgeUYb9xoWDGJe4466iKB3cAl64Wjd38BgAA//8DAFBLAwQU AAYACAAAACEAcQvak8cCAADGBgAAEQAAAHdvcmQvY29tbWVudHMueG1szFVNb9swDL0P2H8QdG5i O/02mhRYswIFVqBou8tuqkXHwizJk2S7+fcjZTtdt6ILdtrFlkXykXx8ki8un3XNOnBeWbPk2Tzl DExhpTKbJf/6eD0748wHYaSorYEl34Lnl6uPHy76vLBagwmeIYTxeYfWKoQmTxJfVKCFn9sGDBpL 67QI+Ok2iRbue9vMMLYRQT2pWoVtskjTEz7C2CVvnclHiJlWhbPeloFCcluWqoDxNUW4ffIOkWtb tFRzzJg4qLEGa3ylGj+h6X9FwxarCaR7r4lO15Nf3+yTTTrR4zx0PZTdWycbZwvwHnfXg3GHmKXv 5R4JJIhdxD4lvM45VaKFMjsYUsdv898Nb47DS4bcCUG9NIJcrF60xPpcySU/57gQbagsztbUXXZy eIrC7HMpAmZZpNlilqWzxfljluZHJ3mafiOrMiooUXuMiaAN7qGw5f2Sp+np9cn56RG5xa01lKKt wy8WKqO5c/H1ELY1oGsn6iW/GnT+CM+BJ6uLZOcWfd0Q4t4KuYcSHB4nGONGX2GMDVF56DAgDlCU O9A5yH0jCuy0ceDBdcBXN0wqyTCOFdYUdSuBlc5qFirlWVM54QHXIuADmEZpiA0wNHlUOwuWCcNE XbPbuy8Mj2MvnMQzz26vmJASk/g5uykZHu4DRg2G2OZQ1MQYUZUdp2eLT/ydOhEOh2ANJtv+ARXj VlvbMgMgqSx4phY9LftKFRVVtHG2bV71Qd7R5wmmhrBeCoYiMI1zVA3Oa4r1rFfIi2F4Y9GmtCTU OXuIMAVSgazE9LvQmNMjx2WcGIIOFPr5Kzpo9pEa1DPdI9TQuESaSLrHeF/uq90sz/bT7ufD48V6 8ZZ2RwvV8T9od/XQbjbgo+IcaNvBAf1ctiTasqXrCoUokX7QcZ7wo8UTPQ6I0VdNUvAF/jn+QjyO YmTer34CAAD//wMAUEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVt ZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV 2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTx eUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7M RYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WN kFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcb rStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJY ogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPt SvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHN C0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LR F9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScj cb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46 XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S 6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6 nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byB OS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqX UKqdChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI 8/mN513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklx YkojeMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLA Dq/o4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsC Vl6F87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbc zuKkMrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74S NuxPTWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D4 16QAO7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwl Xfn2yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4 AiOdr22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0o Syb6TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS 7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRe bubCgRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJ WdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIq f3Xio3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQClxl0k WwMAADEIAAARAAAAd29yZC9zZXR0aW5ncy54bWycVduO2zYQfS/QfxD0XK+pq2Uh3mB9UZtity2i 5AMoibaFJUWCpK11v75DSYzWKBsEfTJ1zszhcDg8/vDxjVHvSqRqebfxgwfke6SredN2p43/9Uux yHxPadw1mPKObPwbUf7Hx59/+tDnimgNYcoDiU7lfONfZJer+kwYVgvW1pIrftSLmrOcH49tTaYf f8qQG/+stciXyynpgQvSgdqRS4a1euDytBwz97y+MNLpZYhQupSEYg0Fq3MrlFVj/1cNtjpbkev3 DnFl1Mb1Afpe5HTcnsvmW8aPlGcShOQ1UQo6y+h4XIbbzsoo+iM6Yz+f20pieXsn8gjX9jfnzOtz QWQNDYU7R8hfGgI25sdSY02AVoJQOgxBTQmG7fv8JDFjGC5tRIYcLXH9+plcWzM/aoAacsQXqr/g qtRcQN4VQ82rcNqlPmPI0USWAtewwY53WnJq4xr+B9c7zoSEHox1wfwIrAdtGNNGmVrN4jPn2qbB VOyirCjGDMPODDqE6W7nYoIEZeHWxYRh+JQcnEyGkDsnDcLiaTrlfQX/XdvqKcnWmWufVZGuV7GL yVBaxGsns4qKyHmebI3C/d6ZcwhWYeBi1hFCKHIycbjeOzu63SeHJHHl7EK03jrVDlES7kNXToFQ gNxMFqbb1JmzTdfRk5PZRUE89Ho5DhBMEsvN6/9L2lUB0+ixcWR3mFWyxd6L8QcYP5ZX8nXbdpav CPgUec+Ul8qSi8VIKIYpLWDiLQHWMDJNq8SeHAdh+oLlaVYehojl0onC+/r9m5p5wkT+KvlFjKq9 xOJT1wBsNwzieNJrO/3cMourS1XarA5s4h116Zo/r9IILucG9bkGZyemQ8+4O9n3RbrF19KE9nlN ZWncn7xgIeBpQ0h1CjY+bU9nHRgL0fDVYPk6fFSncOLCgYMvww0fuDYng+hpYQLGJURNixmLLBbN WGyxeMYSiyUzllosNdj5Br4IvvcKLmuXBj9ySnlPmt8suPH/BY1NUGcsCNyr8UAYMJ4PwGSKyrvm 5A1MlzSthj9W0TYMv238GI0mMEVTfOMXfRdrlEywuEO9BmsMFj5c1V0yXB2Y+H0tfd6QuoWBLG+s mi33YSyctkqXRIA7ay7hyINt/zIoz//1j/8AAAD//wMAUEsDBBQABgAIAAAAIQC5+c+mcAEAANQF AAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVMFugkAQvTfpP5C9V1ZEpEQwMcZTT639gBUW2YTd IbsrVL++I5iKqU3k0Jsnhnkzw5t5zMwXX7J0aq6NABWT8YgSh6sUMqF2MfncrF9C4hjLVMZKUDwm B27IInl+mjdRw7cf3FqMNA5WUSbSMSmsrSLXNWnBJTMjqLhCLActmcVXvXMhz0XKV5DuJVfW9SgN XM1LZpGBKURlyLlac0+1BnRWaUi5MUhEll09yYQiCXLMRG3OT6eJRBaT0BvPZmHoBy2+heywEjVi NSuxf+KeoiXTbzy3P94p/fG/i11xE9hAdSt+CdaC/IUgr2WmT9+ylzyFEyYYao4xQR3QqFiKM2/t FErA+bK9hY5M2WM4LHN7xWlYru73PyTVbcVom+7Ma1nGdOrRme9P6EOX7l8cMtwm+jddgiCYeH5I X+/X5Y9tubh7u3JxXm/K2f/YkzqZd/vS3jGorJDiyNeglxoawzUeLMR7tzj5BgAA//8DAFBLAwQU AAYACAAAACEA6s4W0noBAADnAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAjFJRT4MwEH438T+QvkMLJKgEWKJmTy4xEaPxrba3rQ5K03ZD /r0FNjaiD7717vvuu7vvmi2+68o7gDaikTkKA4I8kKzhQm5y9Fou/VvkGUslp1UjIUcdGLQorq8y plLWaHjWjQJtBRjPKUmTMpWjrbUqxdiwLdTUBI4hHbhudE2tC/UGK8p2dAM4IiTBNVjKqaW4F/TV pIiOkpxNkmqvq0GAMwwV1CCtwWEQ4jPXgq7NnwUDcsGshe2U2+k47qU2ZyM4sb+NmIht2wZtPIzh 5g/x++rpZVjVF7L3igEqMs5SK2wFRYbPT/cy+88vYHZMT4EDmAZqG13I6hAm8Q0Z6k7J3u4ddG2j uXGls8jVcjBMC2XdEUfhWcKxK2rsyl11LYDfdxc9fmN9Kw0H0f+IIhl6TaHbajBxHBa452xJRxNP yFv88FguURGRMPJD4kdJSZI0TlJCPvqVZvW9TWOiPg73H8W7MiRpFM8VTwKjO/OvWfwAAAD//wMA UEsDBBQABgAIAAAAIQB/V40DqAkAAD5KAAAPAAAAd29yZC9zdHlsZXMueG1s3Fzbcts2EH3vTP+B w/fUulmyM1U6iVI3mUlSN5LbZ4qCLDYUoZJUHOfru1iAFEQSxMKkpzN9kgkCexZ7OQvZWP/8y7d9 7H1laRbxZO4Pfxr4HktCvomS+7l/t7p5ceV7WR4kmyDmCZv7jyzzf3n14w8/P7zM8seYZR4ISLKX 6dzf5fnh5cVFFu7YPsh+4geWwLstT/dBDo/p/QXfbqOQveXhcc+S/GI0GEwvUhYHOYBnu+iQ+Ura A0XaA083h5SHLMtA230s5e2DKPFfgXobHr5l2+AY55l4TG9T9aie8OOGJ3nmPbwMsjCKVqA4bHEf JTx99zrJIh/esCDLX2dR0PhyJ2Y1vgmzXJP2JtpE/oVAzL6DzK9BPPdHo2JkITQ4G4uD5L4YY8mL u6Wuydwvh9Ygd+4H6YvlayHsArdZfGrbPZxtHp5QlUMQguEAJ9jmDBwI/hA4cSQcPZpNi4fPxxgG gmPOFQgKADBdLDxWLA5+BS8vZZTAW7b9wMMvbLPM4cXcRywYvHt/m0Y8jfLHuX99LTBhcMn20bto s2EiKNXYXbKLNuyvHUvuMrY5jf9xgyGmJIb8mOSg/nSGURBnm1+/hewgQgxEJ4Hw8CexIBZiMw0H FTpGJ23kQAUVB/8pIIfSh40oOxaINPJQ/1Yg3PWxM9BI7EjfAMp10nXcXcSku4jL7iIweLvZYtZd CyDPrh6RsaFFJd2pOQ9l8Ol2GF+3hKxYUYsi64pa0FhX1GLEuqIWEtYVtQiwrqg53Lqi5l/ripo7 W1eEARJXNYrGaA1SYq+iPGZifSsBDTtSnSo13m2QBvdpcNh5orBW1W4jy+VxndNURTp9Olku85Qn 91aLQHUWqftkTv51f9gFWQQnGovpRx1NvwrWMfN+S6ONFepSBl9tT3gwaSxht3EQsh2PNyz1Vuyb 9KjD+k/cW8pThlW5jm79EN3vcm+5w5JrBZsajG62hJT/IcrQBq3JNDVsxSac5MOpIS7Nwj+yTXTc F6YhnEamks8d3FyBQBXbTTQRLqpnl3UXwgGULchy4b4FlE/QXxYXd/nCxxT9ZSl6onyC/rJwPVE+ xke7f52Z5m2QfvFI6TVzzt0Fj3m6PcZFDljpYeacwSUEbQvOSVzKJ5HEzDmDz+jTex2G8M2NEqfO vjjxqAOKszskCiYbfS/OTqnQ3tBhR84OqmCNHLC6ca0DkDPpfmZfI/GLJ9digCxdnjWt6Tw2WABK EOkM/ceR5/Yz9MjAeVSU9wn8uiRjHg1tbMg8KpqKJ1nvHHzcrfA5AHWrgA5A3UqhA5AhPsxnnrIm 0kG6F0cHLGdaLqsYhh2ZmWfOzFwCuZWAnuom4fxlyF5zLNTrJgHF2UH1uklAcfZOpZaVdZOA1Vvd JGAZqobZRzqnumzKuW7qQOVJgLCjfsibANQPeROA+iFvAlB38raD9EfeBCxnbig5VSdvAhBOcfmq XwLp5E0AcuYGyXbqd0ZF3UMp7V9ueyBvAoqzg+rkTUBx9o6JvAlYOMUlEipYJdURsPohbwJQP+RN AOqHvAlA/ZA3Aagf8iYAdSdvO0h/5E3AcuaGklN18iYAOdNDCaSTNwEIp7hwQyN5Y9Y/O3kTUJwd VCdvAoqzdyqEWh5SCVjODqpgleRNwMIpLsGgsDC4XTbVD3kTdtQPeROA+iFvAlA/5E0A6k7edpD+ yJuA5cwNJafq5E0AcqaHEkgnbwKQMzc0kjcm47OTNwHF2UF18iagOHunQqglzxGwnB1UwSrJm4CF 8dKZvAlAOOWpQC476oe8CTvqh7wJQP2QNwGoO3nbQfojbwKWMzeUnKqTNwHImR5KIJ28CUDO3NBI 3pgjz07eBBRnB9XJm4Di7J0KoZbkTcBydlAFq6Q6AlY/5E0AwsDsTN4EIJzyBCDMIhc39UPehB31 Q94EoO7kbQfpj7wJWM7cUHKqTt4EIGd6KIF08iYAOXODuGcL90XJ11OHhiCg3jMobjWQAUcGJ1EB 1QY/sy1LoZOJ2W+HdAQsduiAaAgP6hbfcP7Fo13sHhsChAwVreOI45XuR7ylozUijGctnQSr3xfe O9kAU1uHIXV+8wa6h/R2IWxPEo1DoGf+eICWnUNxs1xIgwYh0delWoCwD+09NASpth6xWPT5wERs qlLD+HdbhYo/Q8/bppgzGFwNpjcT7I0AXVBkXYlwB1qE0CvVooS6Cl/eTsKL8FWVDPflUa1Ts0ah nLo3fzpdyXlntzdhyKx3Lu6It+iMd8hbrefhFOnvuoLQtoUq2TQs71vh7Hwdy0Y0+OF9IlwBbX/4 tzXp8s23QIqF9wsWxx8DbFvL+cE8NWbbXL4dDrBOVkSteZ7zvXl9itfIUZMmAWBiXRn5KDZhtn1y 3K9ZCn1gLfb/xEV9wX6188CVN2Klu8vMA+0xrqlWN+t2llRlGr1bffxwmzLZuJmzTU0vMcE7m4Ea rgNoy/tddNnV0g5aCr8U41XxC0gqW2Cdn98Q7Tx7p4vx1c2NFKPaGyHosfETPgtoER3CDQeeQa/h cKrCyzBheDVWLZomEaPZ5Kpdxng6nbTPmFxeDdpnXE6uLZpOJ0OLprPxyKLp1Whi0RQMZtF0OBhA 16hMbpNRB9fXFl2Hw2vI3XYpI1DXMmU8m9jUnUwvUV2RxypasmpTLBKSaokFgRA94qG5JVa138LH WV/x3F/wYxpBD80n9iAkFD3Fc38V7aGFGoa9z3wf4EVY7CmuLQkhYnUpaB6tmVhtNfuuNRPjGOwN Wp/bGOqsqoXHDAgSm3ar5bUxcauVrcYN3im/KwTRWClxX210Ib1urkFmXkAz/E99sxsOazQtxtCc ZLuf2250NRiM3kgRNNvRQhcSYBeJHm11jFNKSlUXGX5+DZIo28FMLCUquB/YWvaEV8a1NFCkcJYG xdiBhX/Wxdrzo7lKvgnimPMEu+KqSaDeyZa5JhfoR1I92DWhp7Qxx7r9vGX2qKqSz8N3q2AHdCao ToXEaUAQmXpCy5ycV9Rj3XlyzO4jKodVDdzmua7MpWHZSKviSLPXDHl4Mu9/Ye/y5Ljge/GPPU7f hKvmDZKEw39/EP+LAQ6Y6gt6U4KYa0N/2TC7mV7PFDkou/YTjM2EoYzTSBiaXXLRZttkEhNnaHKf gzN0K9U4w/VcdLIvtD2r9H++A0vVMtVoVO+Rprsmu4bVKdl1c9eCsovRWoMSfmn2Nwvr30C1uMzU lKbQrG0+gSAuinTtpV7w1EuF/9zxqwy6lnvAo0Z/paVhK6aAU9s1x5xms5NNzHbrO+LaDQQmQ8bP Xv0LAAD//wMAUEsDBBQABgAIAAAAIQAMM6swwAEAABwGAAASAAAAd29yZC9mb250VGFibGUueG1s xJTfToMwFMbvTXwH0nulMNzmIjP+26UXZj5AB4fRhLakpxv69p5S1Ji5RBKNJWnCd9rD4dfv9Or6 RTXRHixKo3OWnHMWgS5MKfU2Z8/r1dmcReiELkVjNOTsFZBdL09PrrpFZbTDiPZrXNic1c61izjG ogYl8Ny0oClWGauEo1e7jU1VyQLuTbFToF2ccj6NLTTC0bexli2yIVv3k2ydsWVrTQGIVKxqQj4l pGbLobqoW2ihqOo70ciNlX2gFdogJBTbiyZnPOUrfkGzfzI+8TOLfYaiFhbBfSzkQa6Eks3ru4qd RAyBVrqiftf3wkqxaSCEUG4psMMNz9kNp5E+rFhQkpxlXuCz20FJqahhDMrkq1L0ecKSyz4PKZTn YxeVH4fzOSCxlgoweoQuejJKBFSHRFI+JRIXxMOTmYwiYvu8PcEfEiEj8PRmPvskMv/6/59EyI09 x+NEktVIIndmZyVYz+SIP2ZE4JI4pD2NbBQNZUqw+huDVPIFykN3/C+Ltajp9I5guCVT+AbxtsgI xt+2yTT5NVMkfLwphKL74hgJ3xaBg2+TcSTGt8f3Fwbn2d9cGMPNgcs3AAAA//8DAFBLAwQUAAYA CAAAACEAeriCou8BAADuAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/YPxi+N4rdJMgCRcWQYuhhWwPEbc+qTMfCZEmQ2KDZ 14+ym9TZdqpP5CPx+PxI8ZvXzmQHCFE7u86LyTTPwCpXa7tf5w/Vt6tlnkWUtpbGWVjnR4j5jfj8 iW+D8xBQQ8yIwsZ13iL6FWNRtdDJOKGypUrjQieR0rBnrmm0glunXjqwyMrpdMHgFcHWUF/5M2E+ MK4O+FHS2qmkLz5WR0+CBa+g80YiiJ9JjpnUDjvOziivHEpT6Q5EMZ9T4ZzyrdxDFCWBQ8SfXKij WCzLgrMh5ptWBqmQXBTXy+VyxtkI4V+9N1pJJIfFD62Ci67B7L73IksMnI1bOPmzA/USNB7FlLNx yr9rS2quSxoxhKQvyH2Qvo3iCykapXynpIEN+SAaaSJw9g7wO5Bpx1upSTQ/4OoACl3Iov5NWy7z 7FlGSO6t84MMWlokF1PbkPSx8RGDqDQa4qbakPfhuG0c65kgkdRLwWVjAgcNVLhU10+I9w39G/5H bDEW22sYpI7kjMLzjL9YN67z0h7FttVG+0grfAOS57/ig6/cbTqgNysvwdEFPGlsd14qWtNsvigu bmFU4zu6GahpuSfGd4Dfke/BpLF0R3YP9ann30K6rsfh+YqinEzp68/phNFFnN+V+AMAAP//AwBQ SwECLQAUAAYACAAAACEA69NSqHQBAACjBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAAAK0DAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQCbO7XDCQEAALQDAAAcAAAAAAAAAAAAAAAAANEGAAB3b3Jk L19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAE/VGdt53gAAHNoZABEAAAAA AAAAAAAAAAAAHAkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAHEL2pPHAgAAxgYA ABEAAAAAAAAAAAAAAAAAxOcAAHdvcmQvY29tbWVudHMueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKW BgAAUBsAABUAAAAAAAAAAAAAAAAAuuoAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAI AAAAIQClxl0kWwMAADEIAAARAAAAAAAAAAAAAAAAAIPxAAB3b3JkL3NldHRpbmdzLnhtbFBLAQIt ABQABgAIAAAAIQC5+c+mcAEAANQFAAAUAAAAAAAAAAAAAAAAAA31AAB3b3JkL3dlYlNldHRpbmdz LnhtbFBLAQItABQABgAIAAAAIQDqzhbSegEAAOcCAAARAAAAAAAAAAAAAAAAAK/2AABkb2NQcm9w cy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQB/V40DqAkAAD5KAAAPAAAAAAAAAAAAAAAAAGD5AAB3 b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEADDOrMMABAAAcBgAAEgAAAAAAAAAAAAAAAAA1 AwEAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAHq4gqLvAQAA7gMAABAAAAAAAAAA AAAAAAAAJQUBAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAwADAAAAwAASggBAAAA --=_5933f1d47f4f72ec9b3450dcd231ee76-- From d.sturek@att.net Mon Oct 29 08:56:48 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 DD51A21F871D for ; Mon, 29 Oct 2012 08:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McsM5Tz8R71F for ; Mon, 29 Oct 2012 08:56:48 -0700 (PDT) Received: from nm1-vm0.access.bullet.mail.mud.yahoo.com (nm1-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.27]) by ietfa.amsl.com (Postfix) with ESMTP id EA35821F86CA for ; Mon, 29 Oct 2012 08:56:47 -0700 (PDT) Received: from [66.94.237.196] by nm1.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 15:56:47 -0000 Received: from [68.142.198.106] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 15:56:47 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 15:56:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351526207; bh=qSwbIJmJi2+8Gg9mnJaoWDPH8ZIAnhOJr1TMz8D7PkA=; 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:Content-transfer-encoding; b=iBdndkKNI/w529l+0n7GqIqZasOLhLKHfTUAmZnRqefg8BaekS522szXoDuFH/TyMD+M4LzMTnYrCkfDVJDhPGoy+g3oLcl1Gndbjp2PAhav5YjPQGJad+30ueuwcE0N0QYp4GZAirJi1lgS6ZUH8n6fBSeWEZOPkRBs/gafHH4= X-Yahoo-Newman-Id: 330769.71257.bm@smtp108.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Z0nG_kAVM1lmoSwLrDW8iue940bsrxGNjbPya5n1AyL.Hzf qJT4cFohVB81AGdrgUPDutDiAUDFmYCKrxBhZGAWXLz47ee8CuKF2AztOPj0 jERiA1_l1XaKsDRws3lerqq3vMlB59gqE6mPFV1ZmaARGwhab261Qj8szQY6 JmcfjcdnaxBCIUpwNaQesPc_TWW2UddIFmMS0fMcc82KTq4.y4UYF0OAF8eR UNdiiEcfqn54xz7EFWZ.rURQVaOeNPnv5tIAX4Ydf5YFs0RXc7dC26WVYzjZ 04B7.W3_H5bsxVWzlF9_YP1CZrfdURbKuNcMMpbNl6xP6taLvOgPFwnolHJN pUpnlFumev6DaQOAl83fPG2KuhH76vb.00YAoTENa_kkQAuFDHXyj2IXtwEe rtz0vn4iw41C7Co3nBHuIUwgZumpVYun_rnHfAqf7HDlNfZw3HyUVEN2ZdBr DYD.GjsW15X0P78dCaqo- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.105.137.208 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 29 Oct 2012 08:56:47 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 29 Oct 2012 08:56:42 -0700 From: Don Sturek To: , Message-ID: Thread-Topic: [Roll] Fwd: Re: WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: <49c0b45be05cf97ba606deae2b3288a3@xs4all.nl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] Fwd: 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, 29 Oct 2012 15:56:49 -0000 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 From qiuying@i2r.a-star.edu.sg Mon Oct 29 08:56: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 04CDB21F871D; Mon, 29 Oct 2012 08:56:50 -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 1m7MtgTZzRoI; Mon, 29 Oct 2012 08:56:49 -0700 (PDT) Received: from gw3.scei.a-star.edu.sg (gw3.scei.a-star.edu.sg [192.122.140.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4021F86CA; Mon, 29 Oct 2012 08:56:48 -0700 (PDT) Received: from pps.filterd (gw3 [127.0.0.1]) by gw3.scei.a-star.edu.sg (8.14.4/8.14.4) with SMTP id q9TFtsnH013787; Mon, 29 Oct 2012 23:56:44 +0800 Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw3.scei.a-star.edu.sg with ESMTP id 189se9g36r-1; Mon, 29 Oct 2012 23:56:44 +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; Mon, 29 Oct 2012 23:56:43 +0800 From: QIU Ying To: , <6lowpan@ietf.org> References: In-Reply-To: Date: Tue, 30 Oct 2012 00:03:08 +0800 Message-ID: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wkf59C4jlyJFSRzOqX2NnRKc2WQAPaWDQAUeD8xA= 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-10-29_02:2012-10-29, 2012-10-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=9 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210290156 Content-Type: text/plain; charset="UTF-8" Subject: Re: [Roll] 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: Mon, 29 Oct 2012 15:56:50 -0000 Dear all, Do need an alternative security design instead of the current public key pr= otocols in key establishment? It's one of arguments in previous WG meeting. My answer is yes. Actually, the similar discussion had been raised in mobil= e IPv6 WG (RFC4225). Besides the authentication, another major check is the reachability checkin= g 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 a= ccepted in mobile IPv6 (section 5.2). =20=20 Frankly, the scheme used in KEMP is not fresh new. It is in style of the po= pular Kerberos. Instead of sending the ticket to visiting server from clien= t directly in Kerberos, the ticket is sent to the visiting server (new near= by 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 Strui= k, 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 >=20 > Hi, >=20 > 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. >=20 > Regards > Qiu Ying >=20 >=20 > -----Original Message----- >=20 > 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. >=20 > 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=3Ddraft-qiu-roll-kemp- > 02 >=20 > 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. >=20 >=20 >=20 >=20 > The IETF Secretariat Institute for Infocomm Research disclaimer: "This email is confidential an= d may be privileged. If you are not the intended recipient, please delete i= t 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 ulrich@herberg.name Mon Oct 29 09:38: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 B732021F873E for ; Mon, 29 Oct 2012 09:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.752 X-Spam-Level: X-Spam-Status: No, score=0.752 tagged_above=-999 required=5 tests=[AWL=-3.729, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, J_CHICKENPOX_12=0.6, 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 hvrysmy1gazW for ; Mon, 29 Oct 2012 09:38:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C417721F8705 for ; Mon, 29 Oct 2012 09:38:13 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5890361vcb.31 for ; Mon, 29 Oct 2012 09:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aLfYfeWsh+IDj0yw6IFsZ6MIYefUtD32MZbJ8f+bWEY=; b=eTbhtHMLp9Uy2mk++ou9vqDGxNRS8QpAmpzuNjH7OkAHsfSAm/3NHl8ft4Ss4j1sOD zm411Xch35t5dpHgE2grv5B8PTy6qOAM5lu1ZDOcpIxMvKSRsamswvfEBMyDzVCvZT61 8vGvuZpgGEoO2E7FKhCrE8ivHPRW6Qmxd/A00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aLfYfeWsh+IDj0yw6IFsZ6MIYefUtD32MZbJ8f+bWEY=; b=cVnstcnyF2U5SAqrfeXaWWvanHLxm6HgKfjVHRHR+r0QVN2Hvw9X1nLGiOWnadSrBp J054AaUKooGfDvonJ4bVM+fsOi0PjhAdMC9hVsXhb+Z8Nnr7PAIxBbFm3hv1Jma3TSFu P8bONxcuxg3hmEEQtl7bRbh1UdBuLk8pTurw2ks21MuwUNYx1gCa7U4N3V5OZayTBSvH 3+hIR86F4IEqNktD5LC9niBhKdECO03KMBW608kvNjatUXT9OJFiEmxYLsDoqxM+guKU cVuhMGM4ncxyVOFbOJtTiamW77yyhgPgAfspgOorlmd+GoWl7LIH7IxjFSY5hqmxIoEn 4Q4A== MIME-Version: 1.0 Received: by 10.58.187.234 with SMTP id fv10mr53364033vec.8.1351528692907; Mon, 29 Oct 2012 09:38:12 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 29 Oct 2012 09:38:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Oct 2012 09:38:12 -0700 Message-ID: From: Ulrich Herberg To: Don Sturek Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm97c9aLKgX//lPgfDs1onV7B2A1OuUgxGcRAflGhYioYOOq2eGD2xnLjAk7rsjx/5W9/Oq Cc: "" , "roll@ietf.org WG" , Michael Richardson 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, 29 Oct 2012 16:38:17 -0000 Hi Don, thanks, that's good to know. To your knowledge, are there any public results about delivery ratio of packets, overhead, delay, state requirements and/or a comparison to other flooding mechanisms such as classic flooding? Best Ulrich On Oct 26, 2012, at 20:50, Don Sturek wrote: > Hi Ulrich, > > For ZigBee IP, we are using the trickle multicast draft. We have 7 > platforms interoperating using the draft. > > Don > > > On 10/26/12 8:33 PM, "Ulrich Herberg" wrote: > >> Hi, >> >> below is my review. >> >> My major comment is that the IANA section needs to be fixed and a >> security considerations section needs to be written. Without that >> section, the document should not go forward in my opinion. >> Then I have multiple questions for clarity (see the detailed review). >> Also, as a standards track document, I think it should give some >> guidelines about which values for the parameters to use, as well as >> some indications about the state requirements of the protocol. >> Are there any implementations and/or deployments of the protocol out >> there? >> >> Best regards >> Ulrich >> >> >> >> >> ROLL J. Hui >> Internet-Draft Cisco >> Intended status: Standards Track R. Kelsey >> Expires: April 22, 2013 Silicon Labs >> October 19, 2012 >> >> >> Multicast Protocol for Low power and Lossy Networks (MPL) >> draft-ietf-roll-trickle-mcast-02 >> >> Abstract >> >> This document specifies the Multicast Protocol for Low power and >> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >> constrained networks. MPL avoids the need to construct or maintain >> any multicast forwarding topology, disseminating messages to all MPL >> forwarders in an MPL domain. MPL uses the Trickle algorithm to drive >> packet transmissions for both control and data-plane packets. >> Specific Trickle parameter configurations allow MPL to trade between >> dissemination latency and transmission efficiency. >> >> Status of this Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on April 22, 2013. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 1] >> Internet-Draft MPL October 2012 >> >> >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 >> 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 >> 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8 >> 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9 >> 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11 >> 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11 >> 5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12 >> 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12 >> 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13 >> 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13 >> 5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15 >> 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16 >> 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16 >> 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17 >> 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 >> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 >> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 >> 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 >> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 >> 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 >> 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 2] >> Internet-Draft MPL October 2012 >> >> >> 1. Introduction >> >> Low power and Lossy Networks typically operate with strict resource >> constraints in communication, computation, memory, and energy. Such >> resource constraints may preclude the use of existing IPv6 multicast >> topology and forwarding mechanisms. Traditional IP multicast >> forwarding typically relies on topology maintenance mechanisms to >> forward multicast messages to all subscribers of a multicast group. >> However, maintaining such topologies in LLNs is costly and may not be >> feasible given the available resources. >> >> Memory constraints may limit devices to maintaining links/routes to >> one or a few neighbors. For this reason, the Routing Protocol for >> LLNs (RPL) >> >> UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and >> Lossy Networks" >> >> specifies both storing and non-storing modes [RFC6550]. >> The latter allows RPL routers to maintain only one or a few default >> routes towards a LLN Border Router (LBR) >> >> UH> I did not find LBR in the terminology section. >> >> and use source routing to >> forward packets away from the LBR. For the same reasons, a LLN >> device may not be able to maintain a multicast forwarding topology >> when operating with limited memory. >> >> Furthermore, the dynamic properties of wireless networks can make the >> cost of maintaining a multicast forwarding topology prohibitively >> expensive. In wireless environments, topology maintenance may >> involve selecting a connected dominating set used to forward >> multicast messages to all nodes in an administrative domain. >> However, existing mechanisms often require two-hop topology >> information and the cost of maintaining such information grows >> polynomially with network density. >> >> This document specifies the Multicast Protocol for Low power and >> Lossy Networks (MPL), which provides IPv6 multicast forwarding in >> constrained networks. MPL avoids the need to construct or maintain >> any multicast forwarding topology, disseminating multicast messages >> to all MPL forwarders in an MPL domain. By using the Trickle >> algorithm [RFC6206], MPL requires only small, constant state for each >> MPL device that initiates disseminations. The Trickle algorithm also >> allows MPL to be density-aware, allowing the communication rate to >> scale logarithmically with density. >> >> UH> I am not sure I understand the last sentence. What does it mean? >> How is that achieved? >> >> UH> By the way, since this is a standards track document, is there any >> deployment experience? Implementations? >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 3] >> Internet-Draft MPL October 2012 >> >> >> 2. Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119 >> >> >> The following terms are used throughout this document: >> >> MPL forwarder An IPv6 router that subscribes to the MPL >> multicast group and participates in disseminating >> MPL multicast packets. >> >> MPL multicast scope The multicast scope that MPL uses when forwarding >> MPL multicast packets. In other words, the >> multicast scope of the IPv6 Destination Address >> of an MPL multicast packet. >> >> UH> An RFC reference to "scope" could be helpful. >> >> MPL domain A connected set of MPL forwarders that define the >> extent of the MPL dissemination process. >> >> UH> What does connected mean? What if a the network is split in two parts? >> >> As a >> form of flood, all MPL forwarders in an MPL >> domain will receive MPL multicast packets. >> >> UH> Probably not *all* forwards will receive it (assuming packets can >> be lost) >> >> >> The >> MPL domain MUST be composed of at least one MPL >> multicast scope and MAY be composed of multiple >> MPL multicast scopes. >> >> UH> Why is that? Anyway, I am unsure whether one can say that a >> routing domain "consists" of multicast scopes. If I understand that >> correctly, the multicast scope just determines how far a message >> propagates. >> >> >> MPL seed A MPL forwarder that begins the dissemination >> process for an MPL multicast packet. The MPL >> seed may be different than the source of the >> original multicast packet. >> >> MPL seed identifier An identifier that uniquely identifies an MPL >> forwarder within its MPL domain. >> >> UH> How is the uniqueness guaranteed? What kind of identifier is that? >> An IP address? I see it's defined later, but maybe it would be helpful >> to mention it here, too. >> >> >> original multicast packet An IPv6 multicast packet that is >> disseminated using MPL. >> >> UH> That terminology sounds a bit confusing; I would have imagined >> that the above description matches the following term "MPL multicast >> packet". What's the difference between an "original multicast packet" >> and an "MPL multicast packet"? I assume the one is the inner packet >> when using IPv6-in-IPv6 tunnels, the other one is the outer packet >> with the options header. >> >> >> MPL multicast packet An IPv6 multicast packet that contains an MPL >> Hop-by-Hop Option. When either source or >> destinations are beyond the MPL multicast scope, >> >> UH> Above it was said there may be multiple scopes in a domain. Here >> you talk about "the" scope. Which one? >> >> the MPL multicast packet is an IPv6-in-IPv6 >> packet that contains an MPL Hop-by-Hop Option in >> the outer IPv6 header and encapsulates an >> original multicast packet. When both source and >> destinations are within the MPL multicast scope, >> the MPL Hop-by-Hop Option may be included >> directly within the original multicast packet. >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 4] >> Internet-Draft MPL October 2012 >> >> >> 3. Overview >> >> MPL delivers IPv6 multicast packets by disseminating them to all MPL >> forwarders within an MPL domain. MPL dissemination is a form of >> flood. An MPL forwarder may broadcast/multicast an MPL multicast >> packet out of the same physical interface on which it was received. >> Using link-layer broadcast/multicast allows MPL to forward multicast >> packets without explicitly identifying next-hop destinations. An MPL >> forwarder may also broadcast/multicast MPL multicast packets out >> other interfaces to disseminate the message across different links. >> MPL does not build or maintain a multicast forwarding topology to >> forward multicast packets. >> >> Any MPL forwarder may initiate the dissemination process by serving >> as an MPL seed for an original multicast packet. The MPL seed may or >> may not be the same device as the source of the original multicast >> packet. When the original multicast packet's source is outside the >> LLN, >> >> UH> LLN or MPL domain? How can a router determine if an incoming >> packet is inside our outside the MPL domain? >> >> the MPL seed may be the ingress router. Even if an original >> multicast packet source is within the LLN, the source may first >> forward the multicast packet to the MPL seed using IPv6-in-IPv6 >> tunneling. >> >> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a >> title not related to "IPv6 tunneling". I suggest to make an own >> section. >> >> Because MPL state requirements grows with the number of >> active MPL seeds, >> >> UH> In section 1 it was written that the state is constant. Here you >> say it grows. Which one is it? >> >> limiting the number of MPL seeds reduces the amount >> of state that MPL forwarders must maintain. >> >> Because MPL typically broadcasts/multicasts MPL packets out of the >> same interface on which they were received, >> >> UH> Why typically? Doesn't that depend on the scenario that this >> specification is used in? >> >> MPL forwarders are likely >> to receive an MPL multicast packet more than once. >> >> UH> I am not sure if that is the only reason. Isn't the reason that it >> may be received from multiple neighbors? >> >> The MPL seed tags >> each original multicast packet with an MPL seed identifier and a >> sequence number. The sequence number provides a total ordering of >> MPL multicast packets disseminated by the MPL seed. >> >> MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include >> MPL-specific information along with the original multicast packet. >> Each IPv6 multicast packet that MPL disseminates includes the MPL >> Option. Because the original multicast packet's source and the MPL >> seed may not be the same device, the MPL Option may be added to the >> original multicast packet en-route. To allow Path MTU discovery to >> work properly, MPL encapsulates the original multicast packet in >> another IPv6 header that includes the MPL Option. >> >> Upon receiving a new MPL multicast packet for forwarding, the MPL >> forwarder may proactively transmit the MPL multicast packet packet a >> limited number of times and then falls back into an optional reactive >> mode. In maintenance mode, an MPL forwarder buffers recently >> received MPL multicast packets and advertises a summary of recently >> received MPL multicast packets from time to time, allowing >> neighboring MPL forwarders to determine if they have any new >> multicast packets to offer or receive. >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 5] >> Internet-Draft MPL October 2012 >> >> >> MPL forwarders schedule their packet (control and data) transmissions >> using the Trickle algorithm [RFC6206]. Trickle's adaptive >> transmission interval allows MPL to quickly disseminate messages when >> there are new MPL multicast packets, but reduces transmission >> overhead as the dissemination process completes. Trickle's >> suppression mechanism and transmission time selection allow MPL's >> communication rate to scale logarithmically with density. >> >> UH> I think the whole introduction is not very easy to read. There is >> a lot of text about some details (IPv6-in-IPv6 tunnels, multiple >> interfaces), but the essential mechanism is hard to identify from the >> text. Also, there is nothing mentioned about what kind of state is >> required to be stored on each router (which information sets etc). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 6] >> Internet-Draft MPL October 2012 >> >> >> 4. Message Formats >> >> 4.1. MPL Option >> >> The MPL Option is carried in an IPv6 Hop-by-Hop Options header, >> >> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options header" >> >> UH> More importantly, RFC6564 specifies: >> >> New options for the existing Hop-by-Hop Header SHOULD NOT be >> created or specified unless no alternative solution is feasible. >> Any proposal to create a new option for the existing Hop-by-Hop >> Header MUST include a detailed explanation of why the hop-by-hop >> behavior is absolutely essential in the document proposing the new >> option with hop-by-hop behavior. >> >> UH> I did not see such an explanation. >> >> >> immediately following the IPv6 header. The MPL Option has the >> following format: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Type | Opt Data Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | S |M| rsv | sequence | seed-id (optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> UH> It could help to mention that this is formatted in network byte order >> >> Option Type XX (to be confirmed by IANA). >> >> Opt Data Len Length of the Option Data field in octets. MUST >> be set to either 2 or 4. >> >> UH> 2 or 4 depending on what? >> >> S 2-bit unsigned integer. Identifies the length of >> seed-id. 0 indicates that the seed-id is 0 and >> not included in the MPL Option. 1 indicates that >> the seed-id is a 16-bit unsigned integer. 2 >> indicates that the seed-id is a 64-bit unsigned >> integer. 3 indicates that the seed-id is a 128- >> bit unsigned integer. >> >> M 1-bit flag. 0 indicates that the value in >> sequence is not the greatest sequence number that >> was received from the MPL seed. >> >> rsv 5-bit reserved field. MUST be set to zero and >> incoming MPL multicast packets in which they are >> not zero MUST be dropped. >> >> sequence 8-bit unsigned integer. Identifies relative >> ordering of MPL multicast packets from the source >> identified by seed-id. >> >> seed-id Uniquely identifies the MPL seed that initiated >> dissemination of the MPL multicast packet. The >> size of seed-id is indicated by the S field. >> >> The Option Data of the Trickle Multicast option MUST NOT change as >> the MPL multicast packet is forwarded. Nodes that do not understand >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 7] >> Internet-Draft MPL October 2012 >> >> >> the Trickle Multicast option MUST discard the packet. Thus, >> according to [RFC2460] the three high order bits of the Option Type >> must be set to '010'. The Option Data length is variable. >> >> The seed-id uniquely identifies an MPL seed within the MPL domain. >> When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address >> assigned to one of its interfaces that is unique within the MPL >> domain. Managing MPL seed identifiers is not within scope of this >> document. >> >> The sequence field establishes a total ordering of MPL multicast >> packets from the same MPL seed. The MPL seed MUST increment the >> sequence field's value on each new MPL multicast packet that it >> disseminates. Implementations MUST follow the Serial Number >> Arithmetic as defined in [RFC1982] when incrementing a sequence value >> or comparing two sequence values. >> >> Future updates to this specification may define additional fields >> following the seed-id field. >> >> 4.2. ICMPv6 MPL Message >> >> The MPL forwarder uses ICMPv6 MPL messages to advertise information >> about recently received MPL multicast packets. The ICMPv6 MPL >> message has the following format: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Code | Checksum | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . MPL Window[1..n] . >> . . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> IP Fields: >> >> Source Address A link-local address assigned to the sending >> interface. >> >> Destination Address The link-local all-nodes MPL forwarders multicast >> address (FF02::TBD). >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 8] >> Internet-Draft MPL October 2012 >> >> >> Hop Limit 255 >> >> ICMPv6 Fields: >> >> Type XX (to be confirmed by IANA). >> >> Code 0 >> >> Checksum The ICMP checksum. See [RFC4443]. >> >> MPL Window[1..n] List of one or more MPL Windows (defined in >> Section 4.2.1). >> >> An MPL forwarder transmits an ICMPv6 MPL message to advertise >> information about buffered MPL multicast packets. More explicitly, >> the ICMPv6 MPL message encodes the sliding window state (described in >> Section 5.2) that the MPL forwarder maintains for each MPL seed. The >> advertisement serves to indicate to neighboring MPL forwarders >> regarding newer messages that it may send or the neighboring MPL >> forwarders have yet to receive. >> >> 4.2.1. MPL Window >> >> An MPL Window encodes the sliding window state (described in >> Section 5.2 that the MPL forwarder maintains for an MPL seed. >> >> UH> missing ")" >> >> Each >> MPL Window has the following format: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | w-min | w-len | S | seed-id (0, 2 or 16 octets) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . buffered-mpl-packets (0 to 8 octets) . >> . . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> w-min 8-bit unsigned integer. Indicates the first >> sequence number associated with the first bit in >> buffered-mpl-packets. >> >> w-len 6-bit unsigned integer. Indicates the size of >> the sliding window and the number of valid bits >> in buffered-mpl-packets. The sliding window's >> upper bound is the sum of w-min and w-len. >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 9] >> Internet-Draft MPL October 2012 >> >> >> S 2-bit unsigned integer. Identifies the length of >> seed-id. 0 indicates that the seed-id value is 0 >> and not included in the MPL Option. 1 indicates >> that the seed-id value is a 16-bit unsigned >> integer. 2 indicates that the seed-id value is a >> 128-bit unsigned integer. 3 is reserved. >> >> seed-id Indicates the MPL seed associated with this >> sliding window. >> >> buffered-mpl-packets Variable-length bit vector. Identifies the >> sequence numbers of MPL multicast packets that >> the MPL forwarder has buffered. The sequence >> number is determined by w-min + i, where i is the >> offset within buffered-mpl-packets. >> >> The MPL Window does not have any octet alignment requirement. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 10] >> Internet-Draft MPL October 2012 >> >> >> 5. MPL Forwarder Behavior >> >> An MPL forwarder implementation needs to manage sliding windows for >> each active MPL seed. The sliding window allows the MPL forwarder to >> determine what multicast packets to accept and what multicast packets >> are buffered. An MPL forwarder must also manage MPL packet >> transmissions. >> >> 5.1. Multicast Packet Dissemination >> >> MPL uses the Trickle algorithm to control packet transmissions when >> disseminating MPL multicast packets [RFC6206]. MPL provides two >> propagation mechanisms for disseminating MPL multicast packets. >> >> 1. With proactive propagation, an MPL forwarder transmits buffered >> MPL multicast packets using the Trickle algorithm. This method >> is called proactive propagation since an MPL forwarder actively >> transmits MPL multicast packets without discovering that a >> neighboring MPL forwarder has yet to receive the message. >> >> 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL >> messages using the Trickle algorithm. An MPL forwarder only >> transmits buffered MPL multicast packets upon discovering that >> neighboring devices have not yet to receive the corresponding MPL >> multicast packets. >> >> When receiving a new multicast packet, an MPL forwarder first >> utilizes proactive propagation to forward the MPL multicast packet. >> Proactive propagation reduces dissemination latency since it does not >> require discovering that neighboring devices have not yet received >> the MPL multicast packet. MPL forwarders utilize proactive >> propagation for newly received MPL multicast packets since they can >> assume that some neighboring MPL forwarders have yet to receive the >> MPL multicast packet. After a limited number of MPL multicast packet >> transmissions, the MPL forwarder may terminate proactive propagation >> for the MPL multicast packet. >> >> An MPL forwarder may optionally use reactive propagation to continue >> the dissemination process with lower communication overhead. With >> reactive propagation, neighboring MPL forwarders use ICMPv6 MPL >> messages to discover new MPL multicast messages that have not yet >> been received. When discovering that a neighboring MPL forwarder has >> not yet received a new MPL multicast packet, the MPL forwarder >> enables proactive propagation again. >> >> UH> There is not a lot of RFC2119 language in the above. Or is that >> defined later? Is this above section more like an introduction? >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 11] >> Internet-Draft MPL October 2012 >> >> >> 5.1.1. Trickle Parameters and Variables >> >> As specified in RFC 6206 [RFC6206], a Trickle timer runs for a >> defined interval and has three configuration parameters: the minimum >> interval size Imin, the maximum interval size Imax, and a redundancy >> constant k. >> >> MPL defines a fourth configuration parameter, TimerExpirations, which >> indicates the number of Trickle timer expiration events that occur >> before terminating the Trickle algorithm. >> >> Each MPL forwarder maintains a separate Trickle parameter set for the >> proactive and reactive propagation methods. TimerExpirations MUST be >> greater than 0 for proactive propagation. TimerExpirations MAY be >> set to 0 for reactive propagation, which effectively disables >> reactive propagation. >> >> As specified in RFC 6206 [RFC6206], a Trickle timer has three >> variables: the current interval size I, a time within the current >> interval t, and a counter c. >> >> UH> This sentence starts confusing, as it looks very similar to the >> first paragraph in this section. "a Trickle timer has three variables" >> How about using the same language as in RFC6206: >> "In addition to these three parameters, Trickle maintains three >> variables: >> o I, the current interval size, >> o t, a time within the current interval, and >> o c, a counter." >> >> >> MPL defines a fourth variable, e, which counts the number of Trickle >> timer expiration events since the Trickle timer was last reset. >> >> 5.1.2. Proactive Propagation >> >> With proactive propagation, the MPL forwarder transmits buffered MPL >> multicast packets using the Trickle algorithm. Each buffered MPL >> multicast packet that is proactively being disseminated with >> proactive propagation has an associated Trickle timer. >> >> UH> I think that somewhere the state requirements need to be >> mentioned. How does that affect scalability of the algorithm etc. >> Density is mentioned somewhere in the beginning, but not explained how >> that would affect scalability and state requirements. >> >> Adhering to >> Section 5 of RFC 6206 [RFC6206], this document defines the following: >> >> o This document defines a "consistent" transmission for proactive >> propagation as receiving an MPL multicast packet that has the same >> MPL seed identifier and sequence number as a buffered MPL packet. >> >> o This document defines an "inconsistent" transmission for proactive >> propagation as receiving an MPL multicast packet that has the same >> MPL seed identifier, the M flag set, and has a sequence number >> less than the buffered MPL multicast packet's sequence number. >> >> o This document does not define any external "events". >> >> o This document defines both MPL multicast packets and ICMPv6 MPL >> multicast packets as Trickle messages. These messages are defined >> in the sections below. >> >> UH> I don't see the term Trickle message used anywhere else. >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 12] >> Internet-Draft MPL October 2012 >> >> >> o The actions outside the Trickle algorithm that the protocol takes >> involve managing sliding window state, and is specified in >> Section 5.2. >> >> 5.1.3. Reactive Propagation >> >> With reactive propagation, the MPL forwarder transmits ICMPv6 MPL >> messages using the Trickle algorithm. A MPL forwarder maintains a >> single Trickle timer for reactive propagation with each MPL domain. >> When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not >> execute the Trickle algorithm for reactive propagation and reactive >> propagation is disabled. Adhering to Section 5 of RFC 6206 >> [RFC6206], this document defines the following: >> >> o This document defines a "consistent" transmission for reactive >> propagation as receiving an ICMPv6 MPL message that indicates >> neither the receiving nor transmitting node has new MPL multicast >> packets to offer. >> >> o This document defines an "inconsistent" transmission for reactive >> propagation as receiving an ICMPv6 MPL message that indicates >> either the receiving or transmitting node has at least one new MPL >> multicast packet to offer. >> >> o This document defines an "event" for reactive propagation as >> updating any sliding window (i.e. changing the value of WindowMin, >> WindowMax, or the set of buffered MPL multicast packets) in >> response to receiving an MPL multicast packet. >> >> o This document defines both MPL multicast packets and ICMPv6 MPL >> multicast packets as Trickle messages. These messages are defined >> in the sections below. >> >> UH> I don't see the term "Trickle message" anywhere else (other than >> in 5.1.2) >> >> >> o The actions outside the Trickle algorithm that the protocol takes >> involve managing sliding window state, and is specified in >> Section 5.2. >> >> 5.2. Sliding Windows >> >> Every MPL forwarder MUST maintain a sliding window of sequence >> numbers for each MPL seed of recently received MPL packets. The >> sliding window performs two functions: >> >> 1. Indicate what MPL multicast packets the MPL forwarder should >> accept. >> >> 2. Indicate what MPL multicast packets are buffered and may be >> transmitted to neighboring MPL forwarders. >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 13] >> Internet-Draft MPL October 2012 >> >> >> Each sliding window logically consists of: >> >> 1. A lower-bound sequence number, WindowMin, that represents the >> sequence number of the oldest MPL multicast packet the MPL >> forwarder is willing to receive or has buffered. An MPL >> forwarder MUST ignore any MPL multicast packet that has sequence >> value less than than WindowMin. >> >> 2. An upper-bound sequence value, WindowMax, that represents the >> sequence number of the next MPL multicast packet that the MPL >> forwarder expects to receive. An MPL forwarder MUST accept any >> MPL multicast packet that has sequence number greater than or >> equal to WindowMax. >> >> 3. A list of MPL multicast packets, BufferedPackets, buffered by the >> MPL forwarder. Each entry in BufferedPackets MUST have a >> sequence number in the range [WindowMin, WindowMax). >> >> 4. A timer, HoldTimer, that indicates the minimum lifetime of the >> sliding window. The MPL forwarder MUST NOT free a sliding window >> before HoldTimer expires. >> >> When receiving an MPL multicast packet, if no existing sliding window >> exists for the MPL seed, the MPL forwarder MUST create a new sliding >> window before accepting the MPL multicast packet. The MPL forwarder >> may reclaim memory resources by freeing a sliding window for another >> MPL seed if its HoldTimer has expired. If, for any reason, the MPL >> forwarder cannot create a new sliding window, it MUST discard the >> packet. >> >> If a sliding window exists for the MPL seed, the MPL forwarder MUST >> ignore the MPL multicast packet if the packet's sequence number is >> less than WindowMin or appears in BufferedPackets. Otherwise, the >> MPL forwarder MUST accept the packet and determine whether or not to >> forward the packet and/or pass the packet to the next higher layer. >> >> When accepting an MPL multicast packet, the MPL forwarder MUST update >> the sliding window based on the packet's sequence number. If the >> sequence number is not less than WindowMax, the MPL forwarder MUST >> set WindowMax to 1 greater than the packet's sequence number. If >> WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST >> increment WindowMin such that WindowMax - WindowMin <= >> MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free >> any entries in BufferedPackets that have a sequence number less than >> WindowMin. >> >> If the MPL forwarder has available memory resources, it MUST buffer >> the MPL multicast packet for proactive propagation. If not enough >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 14] >> Internet-Draft MPL October 2012 >> >> >> memory resources are available to buffer the packet, the MPL >> forwarder MUST increment WindowMin and free entries in >> BufferedPackets that have a sequence number less than WindowMin until >> enough memory resources are available. Incrementing WindowMin will >> ensure that the MPL forwarder does not accept previously received >> packets. >> >> An MPL forwarder MAY reclaim memory resources from sliding windows >> for other MPL seeds. If a sliding window for another MPL seed is >> actively disseminating messages and has more than one entry in its >> BufferedPackets, the MPL forwarder may free entries for that MPL seed >> by incrementing WindowMin as described above. >> >> If the MPL forwarder cannot free enough memory resources to buffer >> the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1 >> greater than the packet's sequence number. >> >> When memory resources are available, an MPL forwarder SHOULD buffer a >> MPL multicast packet until the proactive propagation completes (i.e. >> the Trickle algorithm stops execution) and MAY buffer for longer. >> After proactive propagation completes, the MPL forwarder may advance >> WindowMin to the packet's sequence number to reclaim memory >> resources. When the MPL forwarder no longer buffers any packets, it >> MAY set WindowMin equal to WindowMax. When setting WindowMin equal >> to WindowMax, the MPL forwarder MUST initialize HoldTimer to >> WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the >> MPL forwarder MAY free the sliding window to reclaim memory >> resources. >> >> 5.3. Transmission of MPL Multicast Packets >> >> The MPL forwarder manages buffered MPL multicast packet transmissions >> using the Trickle algorithm. When adding a packet to >> BufferedPackets, the MPL forwarder MUST create a Trickle timer for >> the packet and start execution of the Trickle algorithm. >> >> After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL >> forwarder MUST stop executing the Trickle algorithm. When a buffered >> MPL multicast packet does not have an active Trickle timer, the MPL >> forwarder MAY free the buffered packet by advancing WindowMin to 1 >> greater than the packet's sequence number. >> >> Each interface that supports MPL is configured with exactly one MPL >> multicast scope. The MPL multicast scope MUST be site-local or >> smaller and defaults to link-local. A scope larger than link-local >> MAY be used only when that scope corresponds exactly to the MPL >> domain. >> >> UH> Why is this written in a section called "Transmission of MPL >> Multicast Packets"? Seems more like an initial configuration. Same for >> the below IPv6.. I would have expected that in a dedicated section >> about IPv6 tunneling >> UH> How would the router now that the scope corresponds exactly to the >> MPL domain? >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 15] >> Internet-Draft MPL October 2012 >> >> >> An MPL domain may therefore be composed of one or more MPL multicast >> scopes. For example, the MPL domain may be composed of a single MPL >> multicast scope when using a site-local scope. Alternatively, the >> MPL domain may be composed of multiple MPL multicast scopes when >> using a link-local scope. >> >> UH> I am not quite sure how the scope works in this specification. Is >> that used somewhere when deciding whether to forward packets? >> >> IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an >> original multicast packet whose source or destination address is >> outside the MPL multicast scope. >> >> UH> The source address is a unicast address, right? How can that be >> outside a multicast scope? How would you know? >> >> IPv6-in-IPv6 encapsulation is >> necessary to support Path MTU discovery when the MPL forwarder is not >> the source of the original multicast packet. 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. >> >> UH> That should be specified more clearly. What does "remove" mean? I >> suppose you mean decapsulate the inner IPv6 packet. >> >> The destination address scope for the outer IPv6 >> header MUST be the MPL multicast scope. >> >> UH> Again, which one? I thought there can be several scopes? >> >> When an MPL domain is composed of multiple MPL multicast scopes (e.g. >> when the MPL multicast scope is link-local), an MPL forwarder MUST >> decapsulate and encapsulate the original multicast packet when >> crossing between different MPL multicast scopes. >> >> UH> When would you know when to cross a multicast scope? Do you mean >> routing domain? >> >> In doing so, the >> MPL forwarder MUST duplicate the MPL Option, unmodified, in the new >> outer IPv6 header. >> >> The IPv6 destination address of the MPL multicast packet is the all- >> MPL-forwarders multicast address (TBD). >> >> UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest >> to define the variable and use the value only in the IANA section. >> >> The scope of the IPv6 >> destination address is set to the MPL multicast scope. >> >> UH> which one? >> >> 5.4. Reception of MPL Multicast Packets >> >> Upon receiving an MPL multicast packet, the MPL forwarder first >> determines whether or not to accept and buffer the MPL multicast >> packet based on its MPL seed and sequence value, as specified in >> Section 5.2. >> >> If the MPL forwarder accepts the MPL multicast packet, the MPL >> forwarder determines whether or not to deliver the original multicast >> packet to the next higher layer. >> >> UH> How would it determine that? >> >> For example, if the MPL multicast >> packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the >> outer IPv6 header, which also removes MPL Option. >> >> UH> For example? What exactly needs to be done? >> >> 5.5. Transmission of ICMPv6 MPL Messages >> >> The MPL forwarder generates and transmits a new ICMPv6 MPL message >> whenever Trickle requests a transmission. >> >> UH> So for each data packet there would be a new ICMPv6 message? >> Wouldn't that create a lot of overhead? >> >> UH> To which address is the ICMP message sent? On which interface? >> >> The MPL forwarder includes >> an encoding of each sliding window in the ICMPv6 MPL message. >> >> Each sliding window is encoded using an MPL Window entry, defined in >> Section 5.2. The MPL forwarder sets the MPL Window fields as >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 16] >> Internet-Draft MPL October 2012 >> >> >> follows: >> >> S If the MPL seed identifier is 0, set S to 0. If the MPL seed >> identifier is within the range [1, 65535], set S to 2. Otherwise, >> set S to 3. >> >> w-min Set to the lower bound of the sliding window (i.e. >> WindowMin). >> >> w-len Set to the length of the window (i.e. WindowMax - WindowMin). >> >> seed-id If S is non-zero, set to the MPL seed identifier. >> >> buffered-mpl-packets Set each bit that represents a sequence number >> of a packet in BufferedPackets to 1. Set all other bits to 0. >> The i'th bit in buffered-mpl-packets represents a sequence number >> of w-min + i. >> >> 5.6. Reception of ICMPv6 MPL Messages >> >> An MPL forwarder processes each ICMPv6 MPL message that it receives >> to determine if it has any new MPL multicast packets to receive or >> offer. >> >> An MPL forwarder determines if a new MPL multicast packet has not >> been received from a neighboring node if any of the following >> conditions hold true: >> >> 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed >> that does not have a corresponding sliding window entry on the >> MPL forwarder. >> >> 2. The neighbor has a packet in its BufferedPackets that has >> sequence value greater than or equal to WindowMax (i.e. w-min + >> w-len >= WindowMax). >> >> 3. The neighbor has a packet in its BufferedPackets that has >> sequence number within range of the sliding window but is not >> included in BufferedPackets (i.e. the i'th bit in buffered-mpl- >> packets is set to 1, where the sequence number is w-min + i). >> >> When an MPL forwarder determines that it has not yet received a new >> MPL multicast packet buffered by a neighboring device, the MPL >> forwarder resets the Trickle timer associated with reactive >> propagation. >> >> An MPL forwarder determines if an entry in BufferedPackets has not >> been received by a neighboring MPL forwarder if any of the following >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 17] >> Internet-Draft MPL October 2012 >> >> >> conditions hold true: >> >> 1. The ICMPv6 MPL message does not include an MPL Window for the >> packet's MPL seed. >> >> 2. The packet's sequence number is greater than or equal to the >> neighbor's WindowMax value (i.e. the packet's sequence number is >> greater than or equal to w-min + w-len). >> >> 3. The packet's sequence number is within the range of the >> neighbor's sliding window [WindowMin, WindowMax), but not >> included in the neighbor's BufferedPacket (i.e. the packet's >> sequence number is greater than or equal to w-min, strictly less >> than w-min + w-len, and the corresponding bit in buffered-mpl- >> packets is set to 0. >> >> When an MPL forwarder determines that it has at least one buffered >> MPL multicast packet that has not yet been received by a neighbor, >> the MPL forwarder resets the Trickle timer associated with reactive >> propagation. Additionally, for each buffered MPL multicast packet >> that should be transferred, the MPL forwarder MUST reset the Trickle >> timer and reset e to 0 for proactive propagation. If the Trickle >> timer for proactive propagation has already stopped execution, >> >> UH> Which timer? I thought there is one timer per packet in the >> proactive mode? >> >> the >> MPL forwarder MUST initialize a new Trickle timer and start execution >> of the Trickle algorithm. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 18] >> Internet-Draft MPL October 2012 >> >> >> 6. MPL Parameters >> >> An MPL forwarder maintains two sets of Trickle parameters for the >> proactive and reactive methods. The Trickle parameters are listed >> below: >> >> PROACTIVE_IMIN The minimum Trickle timer interval, as defined in >> [RFC6206] for proactive propagation. >> >> PROACTIVE_IMAX The maximum Trickle timer interval, as defined in >> [RFC6206] for proactive propagation. >> >> PROACTIVE_K The redundancy constant, as defined in [RFC6206] for >> proactive propagation. >> >> PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations >> that occur before terminating the Trickle algorithm. MUST be set >> to a value greater than 0. >> >> REACTIVE_IMIN The minimum Trickle timer interval, as defined in >> [RFC6206] for reactive propagation. >> >> REACTIVE_IMAX The maximum Trickle timer interval, as defined in >> [RFC6206] for reactive propagation. >> >> REACTIVE_K The redundancy constant, as defined in [RFC6206] for >> reactive propagation. >> >> REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations >> that occur before terminating the Trickle algorithm. MAY be set >> to 0, which disables reactive propagation. >> >> WINDOW_HOLD_TIME The minimum lifetime for sliding window state. >> >> >> UH> I don't see any recommendations for these values. That is >> typically requested in the IESG evaluation for standards track >> documents (either default values and/or guideslines on the values). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 19] >> Internet-Draft MPL October 2012 >> >> >> 7. Acknowledgements >> >> The authors would like to acknowledge the helpful comments of Robert >> Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy, >> Dario Tedeschi, and Peter van der Stok, which greatly improved the >> document. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 20] >> Internet-Draft MPL October 2012 >> >> >> 8. IANA Considerations >> >> The Trickle Multicast option requires an IPv6 Option Number. >> >> >> >> HEX act chg rest >> --- --- --- ----- >> C 01 0 TBD >> >> >> >> The first two bits indicate that the IPv6 node MUST discard the >> packet if it doesn't recognize the option type, and the third bit >> indicates that the Option Data MUST NOT change en-route. >> >> >> UH> That does not look like a valid IANA section. RFC 5226 give some >> good guidelines. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 21] >> Internet-Draft MPL October 2012 >> >> >> 9. Security Considerations >> >> TODO. >> >> >> UH> This document needs a security considerations section. Refer to RFC >> 3552. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 22] >> Internet-Draft MPL October 2012 >> >> >> 10. References >> >> 10.1. Normative References >> >> [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, >> August 1996. >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >> >> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 >> (IPv6) Specification", RFC 2460, December 1998. >> >> [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in >> IPv6 Specification", RFC 2473, December 1998. >> >> [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control >> Message Protocol (ICMPv6) for the Internet Protocol >> Version 6 (IPv6) Specification", RFC 4443, March 2006. >> >> [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, >> "The Trickle Algorithm", RFC 6206, March 2011. >> >> [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., >> Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. >> Alexander, "RPL: IPv6 Routing Protocol for Low-Power and >> Lossy Networks", RFC 6550, March 2012. >> >> 10.2. Informative References >> >> [I-D.ietf-roll-terminology] >> Vasseur, J., "Terminology in Low power And Lossy >> Networks", draft-ietf-roll-terminology-06 (work in >> progress), September 2011. >> >> UH> That document is never actually cited. Also, it has not been >> updated in over a year. >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 23] >> Internet-Draft MPL October 2012 >> >> >> Authors' Addresses >> >> Jonathan W. Hui >> Cisco >> 170 West Tasman Drive >> San Jose, California 95134 >> USA >> >> Phone: +408 424 1547 >> Email: jonhui@cisco.com >> >> >> Richard Kelsey >> Silicon Labs >> 25 Thomson Place >> Boston, Massachusetts 02210 >> USA >> >> Phone: +617 951 1225 >> Email: richard.kelsey@silabs.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hui & Kelsey Expires April 22, 2013 [Page 24] >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From qiuying@i2r.a-star.edu.sg Mon Oct 29 09:42:55 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 C9CBB21F86F0; Mon, 29 Oct 2012 09:42:55 -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 8Gv5GSQZqe97; Mon, 29 Oct 2012 09:42:55 -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 91CF521F86E5; Mon, 29 Oct 2012 09:42:54 -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 q9TGcVH5001928; Tue, 30 Oct 2012 00:42:45 +0800 Received: from s3-cas05.shared-svc.local ([10.217.253.201]) by gw2.scei.a-star.edu.sg with ESMTP id 189vx1018p-1; Tue, 30 Oct 2012 00:42:45 +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; Tue, 30 Oct 2012 00:42:45 +0800 From: QIU Ying To: "'Michael Richardson'" , References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> In-Reply-To: <1116.1351177270@sandelman.ca> Date: Tue, 30 Oct 2012 00:49:09 +0800 Message-ID: <02a101cdb5f5$51109a70$f331cf50$@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: Ac2y+eJ8zB/KFlDFQnGBF/2JcO4RVwC9yeiA 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-10-29_02:2012-10-29, 2012-10-29, 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-1210290171 Cc: roll@ietf.org, "'Keoh, Sye Loong'" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-kemp-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: Mon, 29 Oct 2012 16:42:55 -0000 Hi, Behcet Initially, I was also confusing which WG is best for this kind solution. The draft finally settled down in the ROLL WG because, at that time, there were many RFCs in ROLL WG about the requirements for LL networks and the KEMP draft is designed to provide a security solution to meet the requirements mentioned in these RFCs. Regards Qiu Ying > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Thursday, October 25, 2012 11:01 PM > To: sarikaya@ieee.org > Cc: roll@ietf.org; Keoh, Sye Loong; 6lowpan@ietf.org > Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll- > kemp-02.txt > > > Behcet Sarikaya wrote: > BS> There is some overlap with this draft and our work on Secure > BS> Bootstrapping that was being pursued until recently in Core WG. > > BS> It is still not clear to me which WG should be home for this > activity, > BS> can you please clarify? > > I thought that this was the point of SOLACE. > > -- > Michael Richardson > -on the road- > From cabo@tzi.org Mon Oct 29 09:56: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 7485A21F8703; Mon, 29 Oct 2012 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 y-NEfLvJ9glD; Mon, 29 Oct 2012 09:56:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4021F86E7; Mon, 29 Oct 2012 09:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9TGuRQw003860; Mon, 29 Oct 2012 17:56:27 +0100 (CET) Received: from eduroam-0380.wlan.uni-bremen.de (eduroam-0380.wlan.uni-bremen.de [134.102.17.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40B57B5; Mon, 29 Oct 2012 17:56:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> Date: Mon, 29 Oct 2012 17:56:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> To: QIU Ying X-Mailer: Apple Mail (2.1499) Cc: "'Keoh, Sye Loong'" , roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-kemp-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: Mon, 29 Oct 2012 16:56:46 -0000 On Oct 29, 2012, at 17:49, QIU Ying wrote: > which WG is best I think right now we don't know that. All WGs in the CN/N cluster have the problem and have some unfulfilled = charter item in this space. So we can continue to play tourists and use the WG that happens to have = the largest amount of space on the agenda... In SOLACE, we are discussing right now when to meet during the Atlanta = IETF. It looks like we will meet on Sunday before the reception for some = brainstorming and maybe on Monday during lunchtime for getting = organized. If you are interested, please join the SOLACE mailing list: https://www.ietf.org/mailman/admin/solace Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Mon Oct 29 10:31:48 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 5756721F86F3; Mon, 29 Oct 2012 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 c4wftrsxB20w; Mon, 29 Oct 2012 10:31:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD34921F86E8; Mon, 29 Oct 2012 10:31:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D760C781; Mon, 29 Oct 2012 17:31:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFTlVnDAqwCX; Mon, 29 Oct 2012 17:31:24 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0694FC77B; Mon, 29 Oct 2012 17:31:24 +0000 (GMT) Message-ID: <508EBD6B.1070606@cs.tcd.ie> Date: Mon, 29 Oct 2012 17:31:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <015901cdb0d3$d38cf1f0$7aa6d5d0$@a-star.edu.sg> <1116.1351177270@sandelman.ca> <02a101cdb5f5$51109a70$f331cf50$@a-star.edu.sg> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Turner, Sean P." , "'Keoh, Sye Loong'" , roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-kemp-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: Mon, 29 Oct 2012 17:31:48 -0000 Carsten, all, On 10/29/2012 04:56 PM, Carsten Bormann wrote: > On Oct 29, 2012, at 17:49, QIU Ying wrote: > >> which WG is best > > I think right now we don't know that. > All WGs in the CN/N cluster have the problem and have some unfulfilled charter item in this space. > So we can continue to play tourists and use the WG that happens to have the largest amount of space on the agenda... > > In SOLACE, we are discussing right now when to meet during the Atlanta IETF. Would it be timely to spend 10 minutes on this during the saag session? I'd really like that the security area not end up being surprised by whatever is eventually decided so getting a presentation at saag would be useful at the point where you more or less know the direction, but are still flexible enough to deal with someone who e.g. points out significant security issues. It might be that waiting another meeting cycle or two would be better if the basic ideas aren't yet firmed up. So, is this work far enough advanced already for that to be productive now or is it still so early it'd be counter-productive? (And presenting at saag before you're ready could very well be counter-productive - it can be a tough audience;-) Ta, S. > It looks like we will meet on Sunday before the reception for some brainstorming and maybe on Monday during lunchtime for getting organized. > If you are interested, please join the SOLACE mailing list: > > https://www.ietf.org/mailman/admin/solace > > Grüße, Carsten > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From cabo@tzi.org Mon Oct 29 10:48: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 75B1F21F86EA; Mon, 29 Oct 2012 10:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ENR-w95KubpX; Mon, 29 Oct 2012 10:48:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 96D7421F86CD; Mon, 29 Oct 2012 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9THlOWB026270; Mon, 29 Oct 2012 18:47:24 +0100 (CET) Received: from eduroam-0380.wlan.uni-bremen.de (eduroam-0380.wlan.uni-bremen.de [134.102.17.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 93CC4F6; Mon, 29 Oct 2012 18:47:24 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <508EBD6B.1070606@cs.tcd.ie> Date: Mon, 29 Oct 2012 18:47:24 +0100 Content-Transfer-Encoding: quoted-printable 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> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) Cc: "Turner, Sean P." , 6lowpan@ietf.org, "roll@ietf.org WG" , "solace@ietf.org" Subject: Re: [Roll] [6lowpan] slot for New Version of draft-qiu-roll-kemp-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: Mon, 29 Oct 2012 17:48:58 -0000 On Oct 29, 2012, at 18:31, Stephen Farrell = wrote: >=20 > Carsten, all, >=20 > On 10/29/2012 04:56 PM, Carsten Bormann wrote: >> On Oct 29, 2012, at 17:49, QIU Ying = wrote: >>=20 >>> which WG is best >>=20 >> I think right now we don't know that. >> All WGs in the CN/N cluster have the problem and have some = unfulfilled charter item in this space. >> So we can continue to play tourists and use the WG that happens to = have the largest amount of space on the agenda... >>=20 >> In SOLACE, we are discussing right now when to meet during the = Atlanta IETF. >=20 > Would it be timely to spend 10 minutes on this during the saag > session? Splendid idea! By Thursday, we should have a somewhat clearer idea of what we want to = do. > I'd really like that the security area not end up being surprised > by whatever is eventually decided so getting a presentation at > saag would be useful at the point where you more or less know > the direction, but are still flexible enough to deal with someone > who e.g. points out significant security issues. >=20 > It might be that waiting another meeting cycle or two would be > better if the basic ideas aren't yet firmed up. >=20 > So, is this work far enough advanced already for that to be > productive now or is it still so early it'd be counter-productive? > (And presenting at saag before you're ready could very well > be counter-productive - it can be a tough audience;-) Oh, there will be no technical presentation at this point. These 10 minutes would be about alerting the security community about = this activity. (See my ROLL slides from Vancouver -- = http://www.ietf.org/proceedings/84/slides/slides-84-roll-11.pdf) What we want to do first is=20 a) collecting more fleshed out approaches, documenting how precisely = they work, and b) identifying gaps in the existing standards, if any. If we are successful in getting structure into this, then there might be 1) "system standards" that explain how to tie things together, as well = as=20 2) potentially point activities addressing these gaps (but these will = not be "SOLACE"). Gr=FC=DFe, Carsten From d.sturek@att.net Mon Oct 29 11:07: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 5972721F873D for ; Mon, 29 Oct 2012 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.601 X-Spam-Level: *** X-Spam-Status: No, score=3.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=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 nlXlT+9MpEFp for ; Mon, 29 Oct 2012 11:06:58 -0700 (PDT) Received: from nm25.access.bullet.mail.mud.yahoo.com (nm25.access.bullet.mail.mud.yahoo.com [66.94.237.90]) by ietfa.amsl.com (Postfix) with ESMTP id B4E5C21F873E for ; Mon, 29 Oct 2012 11:06:57 -0700 (PDT) Received: from [66.94.237.198] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 18:06:56 -0000 Received: from [98.139.221.51] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 18:06:55 -0000 Received: from [127.0.0.1] by smtp104.sbc.mail.bf1.yahoo.com with NNFMP; 29 Oct 2012 18:06:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351534015; bh=dYut8UgNQdC53QEQagTLD4FytTjg+3RnRGaq2L4zY90=; 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=aATsv3OohjnKIDlerxEonIvlonOKboDxNhFokhWqZFSqPSLWz3cJHAynH7NrHz68aUCZvFd9JJeu7BMp++jq1As0C+hmuBHTZMj00rOSjjGbH1l6Xz8YNimHOGLsQfdrOZNr4K9DpOt5+LaQrnUBBi8UXK503pNUHtXdn7xQYew= X-Yahoo-Newman-Id: 715099.36993.bm@smtp104.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4szj2IsVM1nzEkAphV6_7c9Kwu5jhbpJtn3QYQqSzd3UCxz 7OnOHhEVMPmiUbdCXN7qo_1X6QYfk8l7Z1toZCaqTv64SEQhnV8VtGsVbA81 m0UVu50s9M0E36w0fETwQxD9vop0bv_IegszP_cwvX9SdiHXrvC4bopt8P4i BkrSVn5gJhE5I1wmKwla_HoUvuAyc77aY7YCc0HkYBvROflf8Dc1lcpkw7vx b52maQnb6munQrxKx95xwLi8B3V_bxhmlmwYQsoIe2DBCOBCEpIcVE2nHunE zGsGTt5w2W4O5FuHS1zeIFh.a.A2rHHppOvFa4FYop5_SztFuEZUSHEqZGjQ icjpQnIRoDwiMLNGDtST_AnczYung.rvB0h5IdE2f42YXWNJQDt1fGYyseQt ycXceKlwydZGE_dNKFvfAkWG0yP01flB6pot8ANM2tzdUBWZQs0uEeuApZ4w gVy1OaVthz12QYhMq_rGY6eGq0AgXiXyUGtchbJhdoKShFj.M6Tn70gA2z3b jOukKaJjtUHPl16McqQZVUoYPI37goQtE 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; 29 Oct 2012 11:06:55 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 29 Oct 2012 11:06:51 -0700 From: Don Sturek To: Ulrich Herberg Message-ID: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "roll@ietf.org WG" , Michael Richardson 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, 29 Oct 2012 18:07:01 -0000 Hi Ulrich, We did quite a lot of testing using 30 nodes (our messaging profile) and using specific multicast parameter settings as follows: 1. iMin = 128ms, iMax=128ms, k=infinity, TAct=3, TDwell=16s 2. iMin = 128ms, iMax=128ms, k=infinity, TAct=1, TDwell=3s 3. iMin = 512ms, iMax=512ms, k=infinity, TAct=1, TDwell=3s 4. iMin = 512ms, iMax=512ms, k=infinity, TAct=3, TDwell=3s First thing to note is we always set k=infinity since we could not identify anything in our multicast streams to suppress (basically, we just wanted every device to see each multicast message at least once and hopefully only once) Next, the main purpose of our multicast traffic was for resource discovery using mDNS so there is no driving requirement around low latency applications (eg, other applications would be more sensitive to the iMin and iMax settings than we were). We ended up using parameter settings (4) above. I think something like trickle multicast is a MUST for mesh routing solutions like ROLL. The issue you get into using multicast is how the messages are propagated. If every device that sees a multicast simply forwards, then you end up with broadcast storms where nothing is heard. The randomization of re-broadcast is essential. I think our results are being incorporated into the ROLL deployment experience draft (http://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment/). By the way, someone noted the lack of a Security Considerations section. We force Link Layer security on so did not plan any additional security than that..... Don On 10/29/12 9:38 AM, "Ulrich Herberg" wrote: >Hi Don, > >thanks, that's good to know. To your knowledge, are there any public >results about delivery ratio of packets, overhead, delay, state >requirements and/or a comparison to other flooding mechanisms such as >classic flooding? > >Best >Ulrich > >On Oct 26, 2012, at 20:50, Don Sturek wrote: > >> Hi Ulrich, >> >> For ZigBee IP, we are using the trickle multicast draft. We have 7 >> platforms interoperating using the draft. >> >> Don >> >> >> On 10/26/12 8:33 PM, "Ulrich Herberg" wrote: >> >>> Hi, >>> >>> below is my review. >>> >>> My major comment is that the IANA section needs to be fixed and a >>> security considerations section needs to be written. Without that >>> section, the document should not go forward in my opinion. >>> Then I have multiple questions for clarity (see the detailed review). >>> Also, as a standards track document, I think it should give some >>> guidelines about which values for the parameters to use, as well as >>> some indications about the state requirements of the protocol. >>> Are there any implementations and/or deployments of the protocol out >>> there? >>> >>> Best regards >>> Ulrich >>> >>> >>> >>> >>> ROLL J. >>>Hui >>> Internet-Draft >>>Cisco >>> Intended status: Standards Track R. >>>Kelsey >>> Expires: April 22, 2013 Silicon >>>Labs >>> October 19, 2012 >>> >>> >>> Multicast Protocol for Low power and Lossy Networks (MPL) >>> draft-ietf-roll-trickle-mcast-02 >>> >>> Abstract >>> >>> This document specifies the Multicast Protocol for Low power and >>> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >>> constrained networks. MPL avoids the need to construct or maintain >>> any multicast forwarding topology, disseminating messages to all MPL >>> forwarders in an MPL domain. MPL uses the Trickle algorithm to drive >>> packet transmissions for both control and data-plane packets. >>> Specific Trickle parameter configurations allow MPL to trade between >>> dissemination latency and transmission efficiency. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on April 22, 2013. >>> >>> Copyright Notice >>> >>> Copyright (c) 2012 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>1] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 >>> 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>> 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8 >>> 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9 >>> 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11 >>> 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11 >>> 5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12 >>> 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12 >>> 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13 >>> 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13 >>> 5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15 >>> 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16 >>> 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16 >>> 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17 >>> 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 >>> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 >>> 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>2] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 1. Introduction >>> >>> Low power and Lossy Networks typically operate with strict resource >>> constraints in communication, computation, memory, and energy. Such >>> resource constraints may preclude the use of existing IPv6 multicast >>> topology and forwarding mechanisms. Traditional IP multicast >>> forwarding typically relies on topology maintenance mechanisms to >>> forward multicast messages to all subscribers of a multicast group. >>> However, maintaining such topologies in LLNs is costly and may not be >>> feasible given the available resources. >>> >>> Memory constraints may limit devices to maintaining links/routes to >>> one or a few neighbors. For this reason, the Routing Protocol for >>> LLNs (RPL) >>> >>> UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and >>> Lossy Networks" >>> >>> specifies both storing and non-storing modes [RFC6550]. >>> The latter allows RPL routers to maintain only one or a few default >>> routes towards a LLN Border Router (LBR) >>> >>> UH> I did not find LBR in the terminology section. >>> >>> and use source routing to >>> forward packets away from the LBR. For the same reasons, a LLN >>> device may not be able to maintain a multicast forwarding topology >>> when operating with limited memory. >>> >>> Furthermore, the dynamic properties of wireless networks can make the >>> cost of maintaining a multicast forwarding topology prohibitively >>> expensive. In wireless environments, topology maintenance may >>> involve selecting a connected dominating set used to forward >>> multicast messages to all nodes in an administrative domain. >>> However, existing mechanisms often require two-hop topology >>> information and the cost of maintaining such information grows >>> polynomially with network density. >>> >>> This document specifies the Multicast Protocol for Low power and >>> Lossy Networks (MPL), which provides IPv6 multicast forwarding in >>> constrained networks. MPL avoids the need to construct or maintain >>> any multicast forwarding topology, disseminating multicast messages >>> to all MPL forwarders in an MPL domain. By using the Trickle >>> algorithm [RFC6206], MPL requires only small, constant state for each >>> MPL device that initiates disseminations. The Trickle algorithm also >>> allows MPL to be density-aware, allowing the communication rate to >>> scale logarithmically with density. >>> >>> UH> I am not sure I understand the last sentence. What does it mean? >>> How is that achieved? >>> >>> UH> By the way, since this is a standards track document, is there any >>> deployment experience? Implementations? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>3] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 2. Terminology >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in RFC 2119 [RFC2119]. >>> >>> UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119 >>> >>> >>> The following terms are used throughout this document: >>> >>> MPL forwarder An IPv6 router that subscribes to the MPL >>> multicast group and participates in disseminating >>> MPL multicast packets. >>> >>> MPL multicast scope The multicast scope that MPL uses when forwarding >>> MPL multicast packets. In other words, the >>> multicast scope of the IPv6 Destination Address >>> of an MPL multicast packet. >>> >>> UH> An RFC reference to "scope" could be helpful. >>> >>> MPL domain A connected set of MPL forwarders that define the >>> extent of the MPL dissemination process. >>> >>> UH> What does connected mean? What if a the network is split in two >>>parts? >>> >>> As a >>> form of flood, all MPL forwarders in an MPL >>> domain will receive MPL multicast packets. >>> >>> UH> Probably not *all* forwards will receive it (assuming packets can >>> be lost) >>> >>> >>> The >>> MPL domain MUST be composed of at least one MPL >>> multicast scope and MAY be composed of multiple >>> MPL multicast scopes. >>> >>> UH> Why is that? Anyway, I am unsure whether one can say that a >>> routing domain "consists" of multicast scopes. If I understand that >>> correctly, the multicast scope just determines how far a message >>> propagates. >>> >>> >>> MPL seed A MPL forwarder that begins the dissemination >>> process for an MPL multicast packet. The MPL >>> seed may be different than the source of the >>> original multicast packet. >>> >>> MPL seed identifier An identifier that uniquely identifies an MPL >>> forwarder within its MPL domain. >>> >>> UH> How is the uniqueness guaranteed? What kind of identifier is that? >>> An IP address? I see it's defined later, but maybe it would be helpful >>> to mention it here, too. >>> >>> >>> original multicast packet An IPv6 multicast packet that is >>> disseminated using MPL. >>> >>> UH> That terminology sounds a bit confusing; I would have imagined >>> that the above description matches the following term "MPL multicast >>> packet". What's the difference between an "original multicast packet" >>> and an "MPL multicast packet"? I assume the one is the inner packet >>> when using IPv6-in-IPv6 tunnels, the other one is the outer packet >>> with the options header. >>> >>> >>> MPL multicast packet An IPv6 multicast packet that contains an MPL >>> Hop-by-Hop Option. When either source or >>> destinations are beyond the MPL multicast scope, >>> >>> UH> Above it was said there may be multiple scopes in a domain. Here >>> you talk about "the" scope. Which one? >>> >>> the MPL multicast packet is an IPv6-in-IPv6 >>> packet that contains an MPL Hop-by-Hop Option in >>> the outer IPv6 header and encapsulates an >>> original multicast packet. When both source and >>> destinations are within the MPL multicast scope, >>> the MPL Hop-by-Hop Option may be included >>> directly within the original multicast packet. >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>4] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 3. Overview >>> >>> MPL delivers IPv6 multicast packets by disseminating them to all MPL >>> forwarders within an MPL domain. MPL dissemination is a form of >>> flood. An MPL forwarder may broadcast/multicast an MPL multicast >>> packet out of the same physical interface on which it was received. >>> Using link-layer broadcast/multicast allows MPL to forward multicast >>> packets without explicitly identifying next-hop destinations. An MPL >>> forwarder may also broadcast/multicast MPL multicast packets out >>> other interfaces to disseminate the message across different links. >>> MPL does not build or maintain a multicast forwarding topology to >>> forward multicast packets. >>> >>> Any MPL forwarder may initiate the dissemination process by serving >>> as an MPL seed for an original multicast packet. The MPL seed may or >>> may not be the same device as the source of the original multicast >>> packet. When the original multicast packet's source is outside the >>> LLN, >>> >>> UH> LLN or MPL domain? How can a router determine if an incoming >>> packet is inside our outside the MPL domain? >>> >>> the MPL seed may be the ingress router. Even if an original >>> multicast packet source is within the LLN, the source may first >>> forward the multicast packet to the MPL seed using IPv6-in-IPv6 >>> tunneling. >>> >>> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a >>> title not related to "IPv6 tunneling". I suggest to make an own >>> section. >>> >>> Because MPL state requirements grows with the number of >>> active MPL seeds, >>> >>> UH> In section 1 it was written that the state is constant. Here you >>> say it grows. Which one is it? >>> >>> limiting the number of MPL seeds reduces the amount >>> of state that MPL forwarders must maintain. >>> >>> Because MPL typically broadcasts/multicasts MPL packets out of the >>> same interface on which they were received, >>> >>> UH> Why typically? Doesn't that depend on the scenario that this >>> specification is used in? >>> >>> MPL forwarders are likely >>> to receive an MPL multicast packet more than once. >>> >>> UH> I am not sure if that is the only reason. Isn't the reason that it >>> may be received from multiple neighbors? >>> >>> The MPL seed tags >>> each original multicast packet with an MPL seed identifier and a >>> sequence number. The sequence number provides a total ordering of >>> MPL multicast packets disseminated by the MPL seed. >>> >>> MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include >>> MPL-specific information along with the original multicast packet. >>> Each IPv6 multicast packet that MPL disseminates includes the MPL >>> Option. Because the original multicast packet's source and the MPL >>> seed may not be the same device, the MPL Option may be added to the >>> original multicast packet en-route. To allow Path MTU discovery to >>> work properly, MPL encapsulates the original multicast packet in >>> another IPv6 header that includes the MPL Option. >>> >>> Upon receiving a new MPL multicast packet for forwarding, the MPL >>> forwarder may proactively transmit the MPL multicast packet packet a >>> limited number of times and then falls back into an optional reactive >>> mode. In maintenance mode, an MPL forwarder buffers recently >>> received MPL multicast packets and advertises a summary of recently >>> received MPL multicast packets from time to time, allowing >>> neighboring MPL forwarders to determine if they have any new >>> multicast packets to offer or receive. >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>5] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> MPL forwarders schedule their packet (control and data) transmissions >>> using the Trickle algorithm [RFC6206]. Trickle's adaptive >>> transmission interval allows MPL to quickly disseminate messages when >>> there are new MPL multicast packets, but reduces transmission >>> overhead as the dissemination process completes. Trickle's >>> suppression mechanism and transmission time selection allow MPL's >>> communication rate to scale logarithmically with density. >>> >>> UH> I think the whole introduction is not very easy to read. There is >>> a lot of text about some details (IPv6-in-IPv6 tunnels, multiple >>> interfaces), but the essential mechanism is hard to identify from the >>> text. Also, there is nothing mentioned about what kind of state is >>> required to be stored on each router (which information sets etc). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>6] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 4. Message Formats >>> >>> 4.1. MPL Option >>> >>> The MPL Option is carried in an IPv6 Hop-by-Hop Options header, >>> >>> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options >>>header" >>> >>> UH> More importantly, RFC6564 specifies: >>> >>> New options for the existing Hop-by-Hop Header SHOULD NOT be >>> created or specified unless no alternative solution is feasible. >>> Any proposal to create a new option for the existing Hop-by-Hop >>> Header MUST include a detailed explanation of why the hop-by-hop >>> behavior is absolutely essential in the document proposing the new >>> option with hop-by-hop behavior. >>> >>> UH> I did not see such an explanation. >>> >>> >>> immediately following the IPv6 header. The MPL Option has the >>> following format: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Option Type | Opt Data Len | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | S |M| rsv | sequence | seed-id (optional) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> UH> It could help to mention that this is formatted in network byte >>>order >>> >>> Option Type XX (to be confirmed by IANA). >>> >>> Opt Data Len Length of the Option Data field in octets. MUST >>> be set to either 2 or 4. >>> >>> UH> 2 or 4 depending on what? >>> >>> S 2-bit unsigned integer. Identifies the length of >>> seed-id. 0 indicates that the seed-id is 0 and >>> not included in the MPL Option. 1 indicates that >>> the seed-id is a 16-bit unsigned integer. 2 >>> indicates that the seed-id is a 64-bit unsigned >>> integer. 3 indicates that the seed-id is a 128- >>> bit unsigned integer. >>> >>> M 1-bit flag. 0 indicates that the value in >>> sequence is not the greatest sequence number that >>> was received from the MPL seed. >>> >>> rsv 5-bit reserved field. MUST be set to zero and >>> incoming MPL multicast packets in which they are >>> not zero MUST be dropped. >>> >>> sequence 8-bit unsigned integer. Identifies relative >>> ordering of MPL multicast packets from the source >>> identified by seed-id. >>> >>> seed-id Uniquely identifies the MPL seed that initiated >>> dissemination of the MPL multicast packet. The >>> size of seed-id is indicated by the S field. >>> >>> The Option Data of the Trickle Multicast option MUST NOT change as >>> the MPL multicast packet is forwarded. Nodes that do not understand >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>7] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> the Trickle Multicast option MUST discard the packet. Thus, >>> according to [RFC2460] the three high order bits of the Option Type >>> must be set to '010'. The Option Data length is variable. >>> >>> The seed-id uniquely identifies an MPL seed within the MPL domain. >>> When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address >>> assigned to one of its interfaces that is unique within the MPL >>> domain. Managing MPL seed identifiers is not within scope of this >>> document. >>> >>> The sequence field establishes a total ordering of MPL multicast >>> packets from the same MPL seed. The MPL seed MUST increment the >>> sequence field's value on each new MPL multicast packet that it >>> disseminates. Implementations MUST follow the Serial Number >>> Arithmetic as defined in [RFC1982] when incrementing a sequence value >>> or comparing two sequence values. >>> >>> Future updates to this specification may define additional fields >>> following the seed-id field. >>> >>> 4.2. ICMPv6 MPL Message >>> >>> The MPL forwarder uses ICMPv6 MPL messages to advertise information >>> about recently received MPL multicast packets. The ICMPv6 MPL >>> message has the following format: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Code | Checksum | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . MPL Window[1..n] . >>> . . >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> IP Fields: >>> >>> Source Address A link-local address assigned to the sending >>> interface. >>> >>> Destination Address The link-local all-nodes MPL forwarders multicast >>> address (FF02::TBD). >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>8] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> Hop Limit 255 >>> >>> ICMPv6 Fields: >>> >>> Type XX (to be confirmed by IANA). >>> >>> Code 0 >>> >>> Checksum The ICMP checksum. See [RFC4443]. >>> >>> MPL Window[1..n] List of one or more MPL Windows (defined in >>> Section 4.2.1). >>> >>> An MPL forwarder transmits an ICMPv6 MPL message to advertise >>> information about buffered MPL multicast packets. More explicitly, >>> the ICMPv6 MPL message encodes the sliding window state (described in >>> Section 5.2) that the MPL forwarder maintains for each MPL seed. The >>> advertisement serves to indicate to neighboring MPL forwarders >>> regarding newer messages that it may send or the neighboring MPL >>> forwarders have yet to receive. >>> >>> 4.2.1. MPL Window >>> >>> An MPL Window encodes the sliding window state (described in >>> Section 5.2 that the MPL forwarder maintains for an MPL seed. >>> >>> UH> missing ")" >>> >>> Each >>> MPL Window has the following format: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | w-min | w-len | S | seed-id (0, 2 or 16 octets) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . buffered-mpl-packets (0 to 8 octets) . >>> . . >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> w-min 8-bit unsigned integer. Indicates the first >>> sequence number associated with the first bit in >>> buffered-mpl-packets. >>> >>> w-len 6-bit unsigned integer. Indicates the size of >>> the sliding window and the number of valid bits >>> in buffered-mpl-packets. The sliding window's >>> upper bound is the sum of w-min and w-len. >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>9] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> S 2-bit unsigned integer. Identifies the length of >>> seed-id. 0 indicates that the seed-id value is 0 >>> and not included in the MPL Option. 1 indicates >>> that the seed-id value is a 16-bit unsigned >>> integer. 2 indicates that the seed-id value is a >>> 128-bit unsigned integer. 3 is reserved. >>> >>> seed-id Indicates the MPL seed associated with this >>> sliding window. >>> >>> buffered-mpl-packets Variable-length bit vector. Identifies the >>> sequence numbers of MPL multicast packets that >>> the MPL forwarder has buffered. The sequence >>> number is determined by w-min + i, where i is the >>> offset within buffered-mpl-packets. >>> >>> The MPL Window does not have any octet alignment requirement. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>10] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 5. MPL Forwarder Behavior >>> >>> An MPL forwarder implementation needs to manage sliding windows for >>> each active MPL seed. The sliding window allows the MPL forwarder to >>> determine what multicast packets to accept and what multicast packets >>> are buffered. An MPL forwarder must also manage MPL packet >>> transmissions. >>> >>> 5.1. Multicast Packet Dissemination >>> >>> MPL uses the Trickle algorithm to control packet transmissions when >>> disseminating MPL multicast packets [RFC6206]. MPL provides two >>> propagation mechanisms for disseminating MPL multicast packets. >>> >>> 1. With proactive propagation, an MPL forwarder transmits buffered >>> MPL multicast packets using the Trickle algorithm. This method >>> is called proactive propagation since an MPL forwarder actively >>> transmits MPL multicast packets without discovering that a >>> neighboring MPL forwarder has yet to receive the message. >>> >>> 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL >>> messages using the Trickle algorithm. An MPL forwarder only >>> transmits buffered MPL multicast packets upon discovering that >>> neighboring devices have not yet to receive the corresponding MPL >>> multicast packets. >>> >>> When receiving a new multicast packet, an MPL forwarder first >>> utilizes proactive propagation to forward the MPL multicast packet. >>> Proactive propagation reduces dissemination latency since it does not >>> require discovering that neighboring devices have not yet received >>> the MPL multicast packet. MPL forwarders utilize proactive >>> propagation for newly received MPL multicast packets since they can >>> assume that some neighboring MPL forwarders have yet to receive the >>> MPL multicast packet. After a limited number of MPL multicast packet >>> transmissions, the MPL forwarder may terminate proactive propagation >>> for the MPL multicast packet. >>> >>> An MPL forwarder may optionally use reactive propagation to continue >>> the dissemination process with lower communication overhead. With >>> reactive propagation, neighboring MPL forwarders use ICMPv6 MPL >>> messages to discover new MPL multicast messages that have not yet >>> been received. When discovering that a neighboring MPL forwarder has >>> not yet received a new MPL multicast packet, the MPL forwarder >>> enables proactive propagation again. >>> >>> UH> There is not a lot of RFC2119 language in the above. Or is that >>> defined later? Is this above section more like an introduction? >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>11] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 5.1.1. Trickle Parameters and Variables >>> >>> As specified in RFC 6206 [RFC6206], a Trickle timer runs for a >>> defined interval and has three configuration parameters: the minimum >>> interval size Imin, the maximum interval size Imax, and a redundancy >>> constant k. >>> >>> MPL defines a fourth configuration parameter, TimerExpirations, which >>> indicates the number of Trickle timer expiration events that occur >>> before terminating the Trickle algorithm. >>> >>> Each MPL forwarder maintains a separate Trickle parameter set for the >>> proactive and reactive propagation methods. TimerExpirations MUST be >>> greater than 0 for proactive propagation. TimerExpirations MAY be >>> set to 0 for reactive propagation, which effectively disables >>> reactive propagation. >>> >>> As specified in RFC 6206 [RFC6206], a Trickle timer has three >>> variables: the current interval size I, a time within the current >>> interval t, and a counter c. >>> >>> UH> This sentence starts confusing, as it looks very similar to the >>> first paragraph in this section. "a Trickle timer has three variables" >>> How about using the same language as in RFC6206: >>> "In addition to these three parameters, Trickle maintains three >>> variables: >>> o I, the current interval size, >>> o t, a time within the current interval, and >>> o c, a counter." >>> >>> >>> MPL defines a fourth variable, e, which counts the number of Trickle >>> timer expiration events since the Trickle timer was last reset. >>> >>> 5.1.2. Proactive Propagation >>> >>> With proactive propagation, the MPL forwarder transmits buffered MPL >>> multicast packets using the Trickle algorithm. Each buffered MPL >>> multicast packet that is proactively being disseminated with >>> proactive propagation has an associated Trickle timer. >>> >>> UH> I think that somewhere the state requirements need to be >>> mentioned. How does that affect scalability of the algorithm etc. >>> Density is mentioned somewhere in the beginning, but not explained how >>> that would affect scalability and state requirements. >>> >>> Adhering to >>> Section 5 of RFC 6206 [RFC6206], this document defines the following: >>> >>> o This document defines a "consistent" transmission for proactive >>> propagation as receiving an MPL multicast packet that has the same >>> MPL seed identifier and sequence number as a buffered MPL packet. >>> >>> o This document defines an "inconsistent" transmission for proactive >>> propagation as receiving an MPL multicast packet that has the same >>> MPL seed identifier, the M flag set, and has a sequence number >>> less than the buffered MPL multicast packet's sequence number. >>> >>> o This document does not define any external "events". >>> >>> o This document defines both MPL multicast packets and ICMPv6 MPL >>> multicast packets as Trickle messages. These messages are defined >>> in the sections below. >>> >>> UH> I don't see the term Trickle message used anywhere else. >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>12] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> o The actions outside the Trickle algorithm that the protocol takes >>> involve managing sliding window state, and is specified in >>> Section 5.2. >>> >>> 5.1.3. Reactive Propagation >>> >>> With reactive propagation, the MPL forwarder transmits ICMPv6 MPL >>> messages using the Trickle algorithm. A MPL forwarder maintains a >>> single Trickle timer for reactive propagation with each MPL domain. >>> When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not >>> execute the Trickle algorithm for reactive propagation and reactive >>> propagation is disabled. Adhering to Section 5 of RFC 6206 >>> [RFC6206], this document defines the following: >>> >>> o This document defines a "consistent" transmission for reactive >>> propagation as receiving an ICMPv6 MPL message that indicates >>> neither the receiving nor transmitting node has new MPL multicast >>> packets to offer. >>> >>> o This document defines an "inconsistent" transmission for reactive >>> propagation as receiving an ICMPv6 MPL message that indicates >>> either the receiving or transmitting node has at least one new MPL >>> multicast packet to offer. >>> >>> o This document defines an "event" for reactive propagation as >>> updating any sliding window (i.e. changing the value of WindowMin, >>> WindowMax, or the set of buffered MPL multicast packets) in >>> response to receiving an MPL multicast packet. >>> >>> o This document defines both MPL multicast packets and ICMPv6 MPL >>> multicast packets as Trickle messages. These messages are defined >>> in the sections below. >>> >>> UH> I don't see the term "Trickle message" anywhere else (other than >>> in 5.1.2) >>> >>> >>> o The actions outside the Trickle algorithm that the protocol takes >>> involve managing sliding window state, and is specified in >>> Section 5.2. >>> >>> 5.2. Sliding Windows >>> >>> Every MPL forwarder MUST maintain a sliding window of sequence >>> numbers for each MPL seed of recently received MPL packets. The >>> sliding window performs two functions: >>> >>> 1. Indicate what MPL multicast packets the MPL forwarder should >>> accept. >>> >>> 2. Indicate what MPL multicast packets are buffered and may be >>> transmitted to neighboring MPL forwarders. >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>13] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> Each sliding window logically consists of: >>> >>> 1. A lower-bound sequence number, WindowMin, that represents the >>> sequence number of the oldest MPL multicast packet the MPL >>> forwarder is willing to receive or has buffered. An MPL >>> forwarder MUST ignore any MPL multicast packet that has sequence >>> value less than than WindowMin. >>> >>> 2. An upper-bound sequence value, WindowMax, that represents the >>> sequence number of the next MPL multicast packet that the MPL >>> forwarder expects to receive. An MPL forwarder MUST accept any >>> MPL multicast packet that has sequence number greater than or >>> equal to WindowMax. >>> >>> 3. A list of MPL multicast packets, BufferedPackets, buffered by the >>> MPL forwarder. Each entry in BufferedPackets MUST have a >>> sequence number in the range [WindowMin, WindowMax). >>> >>> 4. A timer, HoldTimer, that indicates the minimum lifetime of the >>> sliding window. The MPL forwarder MUST NOT free a sliding window >>> before HoldTimer expires. >>> >>> When receiving an MPL multicast packet, if no existing sliding window >>> exists for the MPL seed, the MPL forwarder MUST create a new sliding >>> window before accepting the MPL multicast packet. The MPL forwarder >>> may reclaim memory resources by freeing a sliding window for another >>> MPL seed if its HoldTimer has expired. If, for any reason, the MPL >>> forwarder cannot create a new sliding window, it MUST discard the >>> packet. >>> >>> If a sliding window exists for the MPL seed, the MPL forwarder MUST >>> ignore the MPL multicast packet if the packet's sequence number is >>> less than WindowMin or appears in BufferedPackets. Otherwise, the >>> MPL forwarder MUST accept the packet and determine whether or not to >>> forward the packet and/or pass the packet to the next higher layer. >>> >>> When accepting an MPL multicast packet, the MPL forwarder MUST update >>> the sliding window based on the packet's sequence number. If the >>> sequence number is not less than WindowMax, the MPL forwarder MUST >>> set WindowMax to 1 greater than the packet's sequence number. If >>> WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST >>> increment WindowMin such that WindowMax - WindowMin <= >>> MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free >>> any entries in BufferedPackets that have a sequence number less than >>> WindowMin. >>> >>> If the MPL forwarder has available memory resources, it MUST buffer >>> the MPL multicast packet for proactive propagation. If not enough >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>14] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> memory resources are available to buffer the packet, the MPL >>> forwarder MUST increment WindowMin and free entries in >>> BufferedPackets that have a sequence number less than WindowMin until >>> enough memory resources are available. Incrementing WindowMin will >>> ensure that the MPL forwarder does not accept previously received >>> packets. >>> >>> An MPL forwarder MAY reclaim memory resources from sliding windows >>> for other MPL seeds. If a sliding window for another MPL seed is >>> actively disseminating messages and has more than one entry in its >>> BufferedPackets, the MPL forwarder may free entries for that MPL seed >>> by incrementing WindowMin as described above. >>> >>> If the MPL forwarder cannot free enough memory resources to buffer >>> the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1 >>> greater than the packet's sequence number. >>> >>> When memory resources are available, an MPL forwarder SHOULD buffer a >>> MPL multicast packet until the proactive propagation completes (i.e. >>> the Trickle algorithm stops execution) and MAY buffer for longer. >>> After proactive propagation completes, the MPL forwarder may advance >>> WindowMin to the packet's sequence number to reclaim memory >>> resources. When the MPL forwarder no longer buffers any packets, it >>> MAY set WindowMin equal to WindowMax. When setting WindowMin equal >>> to WindowMax, the MPL forwarder MUST initialize HoldTimer to >>> WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the >>> MPL forwarder MAY free the sliding window to reclaim memory >>> resources. >>> >>> 5.3. Transmission of MPL Multicast Packets >>> >>> The MPL forwarder manages buffered MPL multicast packet transmissions >>> using the Trickle algorithm. When adding a packet to >>> BufferedPackets, the MPL forwarder MUST create a Trickle timer for >>> the packet and start execution of the Trickle algorithm. >>> >>> After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL >>> forwarder MUST stop executing the Trickle algorithm. When a buffered >>> MPL multicast packet does not have an active Trickle timer, the MPL >>> forwarder MAY free the buffered packet by advancing WindowMin to 1 >>> greater than the packet's sequence number. >>> >>> Each interface that supports MPL is configured with exactly one MPL >>> multicast scope. The MPL multicast scope MUST be site-local or >>> smaller and defaults to link-local. A scope larger than link-local >>> MAY be used only when that scope corresponds exactly to the MPL >>> domain. >>> >>> UH> Why is this written in a section called "Transmission of MPL >>> Multicast Packets"? Seems more like an initial configuration. Same for >>> the below IPv6.. I would have expected that in a dedicated section >>> about IPv6 tunneling >>> UH> How would the router now that the scope corresponds exactly to the >>> MPL domain? >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>15] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> An MPL domain may therefore be composed of one or more MPL multicast >>> scopes. For example, the MPL domain may be composed of a single MPL >>> multicast scope when using a site-local scope. Alternatively, the >>> MPL domain may be composed of multiple MPL multicast scopes when >>> using a link-local scope. >>> >>> UH> I am not quite sure how the scope works in this specification. Is >>> that used somewhere when deciding whether to forward packets? >>> >>> IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an >>> original multicast packet whose source or destination address is >>> outside the MPL multicast scope. >>> >>> UH> The source address is a unicast address, right? How can that be >>> outside a multicast scope? How would you know? >>> >>> IPv6-in-IPv6 encapsulation is >>> necessary to support Path MTU discovery when the MPL forwarder is not >>> the source of the original multicast packet. 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. >>> >>> UH> That should be specified more clearly. What does "remove" mean? I >>> suppose you mean decapsulate the inner IPv6 packet. >>> >>> The destination address scope for the outer IPv6 >>> header MUST be the MPL multicast scope. >>> >>> UH> Again, which one? I thought there can be several scopes? >>> >>> When an MPL domain is composed of multiple MPL multicast scopes (e.g. >>> when the MPL multicast scope is link-local), an MPL forwarder MUST >>> decapsulate and encapsulate the original multicast packet when >>> crossing between different MPL multicast scopes. >>> >>> UH> When would you know when to cross a multicast scope? Do you mean >>> routing domain? >>> >>> In doing so, the >>> MPL forwarder MUST duplicate the MPL Option, unmodified, in the new >>> outer IPv6 header. >>> >>> The IPv6 destination address of the MPL multicast packet is the all- >>> MPL-forwarders multicast address (TBD). >>> >>> UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest >>> to define the variable and use the value only in the IANA section. >>> >>> The scope of the IPv6 >>> destination address is set to the MPL multicast scope. >>> >>> UH> which one? >>> >>> 5.4. Reception of MPL Multicast Packets >>> >>> Upon receiving an MPL multicast packet, the MPL forwarder first >>> determines whether or not to accept and buffer the MPL multicast >>> packet based on its MPL seed and sequence value, as specified in >>> Section 5.2. >>> >>> If the MPL forwarder accepts the MPL multicast packet, the MPL >>> forwarder determines whether or not to deliver the original multicast >>> packet to the next higher layer. >>> >>> UH> How would it determine that? >>> >>> For example, if the MPL multicast >>> packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the >>> outer IPv6 header, which also removes MPL Option. >>> >>> UH> For example? What exactly needs to be done? >>> >>> 5.5. Transmission of ICMPv6 MPL Messages >>> >>> The MPL forwarder generates and transmits a new ICMPv6 MPL message >>> whenever Trickle requests a transmission. >>> >>> UH> So for each data packet there would be a new ICMPv6 message? >>> Wouldn't that create a lot of overhead? >>> >>> UH> To which address is the ICMP message sent? On which interface? >>> >>> The MPL forwarder includes >>> an encoding of each sliding window in the ICMPv6 MPL message. >>> >>> Each sliding window is encoded using an MPL Window entry, defined in >>> Section 5.2. The MPL forwarder sets the MPL Window fields as >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>16] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> follows: >>> >>> S If the MPL seed identifier is 0, set S to 0. If the MPL seed >>> identifier is within the range [1, 65535], set S to 2. Otherwise, >>> set S to 3. >>> >>> w-min Set to the lower bound of the sliding window (i.e. >>> WindowMin). >>> >>> w-len Set to the length of the window (i.e. WindowMax - WindowMin). >>> >>> seed-id If S is non-zero, set to the MPL seed identifier. >>> >>> buffered-mpl-packets Set each bit that represents a sequence number >>> of a packet in BufferedPackets to 1. Set all other bits to 0. >>> The i'th bit in buffered-mpl-packets represents a sequence number >>> of w-min + i. >>> >>> 5.6. Reception of ICMPv6 MPL Messages >>> >>> An MPL forwarder processes each ICMPv6 MPL message that it receives >>> to determine if it has any new MPL multicast packets to receive or >>> offer. >>> >>> An MPL forwarder determines if a new MPL multicast packet has not >>> been received from a neighboring node if any of the following >>> conditions hold true: >>> >>> 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed >>> that does not have a corresponding sliding window entry on the >>> MPL forwarder. >>> >>> 2. The neighbor has a packet in its BufferedPackets that has >>> sequence value greater than or equal to WindowMax (i.e. w-min + >>> w-len >= WindowMax). >>> >>> 3. The neighbor has a packet in its BufferedPackets that has >>> sequence number within range of the sliding window but is not >>> included in BufferedPackets (i.e. the i'th bit in buffered-mpl- >>> packets is set to 1, where the sequence number is w-min + i). >>> >>> When an MPL forwarder determines that it has not yet received a new >>> MPL multicast packet buffered by a neighboring device, the MPL >>> forwarder resets the Trickle timer associated with reactive >>> propagation. >>> >>> An MPL forwarder determines if an entry in BufferedPackets has not >>> been received by a neighboring MPL forwarder if any of the following >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>17] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> conditions hold true: >>> >>> 1. The ICMPv6 MPL message does not include an MPL Window for the >>> packet's MPL seed. >>> >>> 2. The packet's sequence number is greater than or equal to the >>> neighbor's WindowMax value (i.e. the packet's sequence number is >>> greater than or equal to w-min + w-len). >>> >>> 3. The packet's sequence number is within the range of the >>> neighbor's sliding window [WindowMin, WindowMax), but not >>> included in the neighbor's BufferedPacket (i.e. the packet's >>> sequence number is greater than or equal to w-min, strictly less >>> than w-min + w-len, and the corresponding bit in buffered-mpl- >>> packets is set to 0. >>> >>> When an MPL forwarder determines that it has at least one buffered >>> MPL multicast packet that has not yet been received by a neighbor, >>> the MPL forwarder resets the Trickle timer associated with reactive >>> propagation. Additionally, for each buffered MPL multicast packet >>> that should be transferred, the MPL forwarder MUST reset the Trickle >>> timer and reset e to 0 for proactive propagation. If the Trickle >>> timer for proactive propagation has already stopped execution, >>> >>> UH> Which timer? I thought there is one timer per packet in the >>> proactive mode? >>> >>> the >>> MPL forwarder MUST initialize a new Trickle timer and start execution >>> of the Trickle algorithm. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>18] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 6. MPL Parameters >>> >>> An MPL forwarder maintains two sets of Trickle parameters for the >>> proactive and reactive methods. The Trickle parameters are listed >>> below: >>> >>> PROACTIVE_IMIN The minimum Trickle timer interval, as defined in >>> [RFC6206] for proactive propagation. >>> >>> PROACTIVE_IMAX The maximum Trickle timer interval, as defined in >>> [RFC6206] for proactive propagation. >>> >>> PROACTIVE_K The redundancy constant, as defined in [RFC6206] for >>> proactive propagation. >>> >>> PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations >>> that occur before terminating the Trickle algorithm. MUST be set >>> to a value greater than 0. >>> >>> REACTIVE_IMIN The minimum Trickle timer interval, as defined in >>> [RFC6206] for reactive propagation. >>> >>> REACTIVE_IMAX The maximum Trickle timer interval, as defined in >>> [RFC6206] for reactive propagation. >>> >>> REACTIVE_K The redundancy constant, as defined in [RFC6206] for >>> reactive propagation. >>> >>> REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations >>> that occur before terminating the Trickle algorithm. MAY be set >>> to 0, which disables reactive propagation. >>> >>> WINDOW_HOLD_TIME The minimum lifetime for sliding window state. >>> >>> >>> UH> I don't see any recommendations for these values. That is >>> typically requested in the IESG evaluation for standards track >>> documents (either default values and/or guideslines on the values). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>19] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 7. Acknowledgements >>> >>> The authors would like to acknowledge the helpful comments of Robert >>> Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy, >>> Dario Tedeschi, and Peter van der Stok, which greatly improved the >>> document. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>20] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 8. IANA Considerations >>> >>> The Trickle Multicast option requires an IPv6 Option Number. >>> >>> >>> >>> HEX act chg rest >>> --- --- --- ----- >>> C 01 0 TBD >>> >>> >>> >>> The first two bits indicate that the IPv6 node MUST discard the >>> packet if it doesn't recognize the option type, and the third bit >>> indicates that the Option Data MUST NOT change en-route. >>> >>> >>> UH> That does not look like a valid IANA section. RFC 5226 give some >>> good guidelines. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>21] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 9. Security Considerations >>> >>> TODO. >>> >>> >>> UH> This document needs a security considerations section. Refer to RFC >>> 3552. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>22] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> 10. References >>> >>> 10.1. Normative References >>> >>> [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, >>> August 1996. >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>> >>> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 >>> (IPv6) Specification", RFC 2460, December 1998. >>> >>> [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in >>> IPv6 Specification", RFC 2473, December 1998. >>> >>> [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control >>> Message Protocol (ICMPv6) for the Internet Protocol >>> Version 6 (IPv6) Specification", RFC 4443, March 2006. >>> >>> [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, >>> "The Trickle Algorithm", RFC 6206, March 2011. >>> >>> [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., >>> Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. >>> Alexander, "RPL: IPv6 Routing Protocol for Low-Power and >>> Lossy Networks", RFC 6550, March 2012. >>> >>> 10.2. Informative References >>> >>> [I-D.ietf-roll-terminology] >>> Vasseur, J., "Terminology in Low power And Lossy >>> Networks", draft-ietf-roll-terminology-06 (work in >>> progress), September 2011. >>> >>> UH> That document is never actually cited. Also, it has not been >>> updated in over a year. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>23] >>> Internet-Draft MPL October >>>2012 >>> >>> >>> Authors' Addresses >>> >>> Jonathan W. Hui >>> Cisco >>> 170 West Tasman Drive >>> San Jose, California 95134 >>> USA >>> >>> Phone: +408 424 1547 >>> Email: jonhui@cisco.com >>> >>> >>> Richard Kelsey >>> Silicon Labs >>> 25 Thomson Place >>> Boston, Massachusetts 02210 >>> USA >>> >>> Phone: +617 951 1225 >>> Email: richard.kelsey@silabs.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hui & Kelsey Expires April 22, 2013 [Page >>>24] >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> From ulrich@herberg.name Mon Oct 29 11:18:16 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 7DC9021F85A5 for ; Mon, 29 Oct 2012 11:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.988 X-Spam-Level: * X-Spam-Status: No, score=1.988 tagged_above=-999 required=5 tests=[AWL=-1.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=0.6, 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 OPfS8orvUDM3 for ; Mon, 29 Oct 2012 11:18:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC0AE21F86CA for ; Mon, 29 Oct 2012 11:18:08 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6012601vcb.31 for ; Mon, 29 Oct 2012 11:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4N87R0iVZ6ANufJ/xwb5/6LexjDMdSWhsXfCmfgMOoY=; b=vLbTIKkvhHSjUrNjhiilHQme4XQKsrA2DDNLYj6C1O97axw3oEQYyOhKb6qkr42GVD lT6L/pucxtWpQs71Gz32n8fB0NKk6L20pI0OzyBudSKX/TgQn/06QtRywrcVp+dbT8SN WoUuANtM5j4wxQpjGiCH4HbXcvRwxgXx0KTlA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4N87R0iVZ6ANufJ/xwb5/6LexjDMdSWhsXfCmfgMOoY=; b=LT/oYxC4lz9d7I/1/VxwrLoy9zGB0S+4enbRpYp8Vseg4PXPd6BWt1yudx88XEa0fm cCwOGaySczfi6uTgU5PEzJsp8hdRNMV0YdAqk6PVLxi1Pw4EJ+ELPmyoKFaGa8+/zmHV 1j+WT56H+Z2i/SWUHTpIlqH9y0tQQUiX8txA1eAOKcnuJQBI0T7MqkjBkmkkL9nri9qG 6rTjCFhKjhIlHhzkI0q/YeKvmZVtC4enpGR7CthMvTGMcrmXL/3VsneSJVzehMTfwLhu /vJbQvFRcY3TBPZgZe+tYl52PKxqd3FwzaDRFzrBWjlAZHpFjsSxSWAA/5FeFKoRO8uz oAyg== MIME-Version: 1.0 Received: by 10.52.67.44 with SMTP id k12mr39707958vdt.15.1351534688065; Mon, 29 Oct 2012 11:18:08 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Mon, 29 Oct 2012 11:18:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Oct 2012 11:18:07 -0700 Message-ID: From: Ulrich Herberg To: Don Sturek Content-Type: multipart/alternative; boundary=20cf307abeb5fbd71404cd36b00b X-Gm-Message-State: ALoCoQlWfpwlA3q58hjv4Pi770RnDUPV5vD/+loOiBCybolZsB7vHf6OPstl2aUCKtoTC/0VUU6U Cc: "" , "roll@ietf.org WG" , Michael Richardson 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, 29 Oct 2012 18:18:16 -0000 --20cf307abeb5fbd71404cd36b00b Content-Type: text/plain; charset=ISO-8859-1 Hi Don, thanks for this information. See below On Mon, Oct 29, 2012 at 11:06 AM, Don Sturek wrote: > Hi Ulrich, > > We did quite a lot of testing using 30 nodes (our messaging profile) and > using specific multicast parameter settings as follows: > 1. iMin = 128ms, iMax=128ms, k=infinity, TAct=3, TDwell=16s > 2. iMin = 128ms, iMax=128ms, k=infinity, TAct=1, TDwell=3s > 3. iMin = 512ms, iMax=512ms, k=infinity, TAct=1, TDwell=3s > 4. iMin = 512ms, iMax=512ms, k=infinity, TAct=3, TDwell=3s > > First thing to note is we always set k=infinity since we could not > identify anything in our multicast streams to suppress (basically, we just > wanted every device to see each multicast message at least once and > hopefully only once) > My understanding is that if you set k to infinity, you would probably see each message many more times than just once. RFC6206 states: "In general, this approach [setting k to infinity] is highly dangerous and it is NOT RECOMMENDED. Disabling suppression means that every node will always send on every interval; this can lead to congestion in dense networks. This approach is especially dangerous if many nodes reset their intervals at the same time. In general, it is much more desirable to set k to a high value (e.g., 5 or 10) than infinity. Typical values for k are 1-5: these achieve a good balance between redundancy and low cost[Levis08 ]." I assume that with k = infinity, the performance would be much worse than classic flooding and you would have a lot of bandwidth consumption in the LLN. Did you observe that? > Next, the main purpose of our multicast traffic was for resource discovery > using mDNS so there is no driving requirement around low latency > applications (eg, other applications would be more sensitive to the iMin > and iMax settings than we were). > I think this is important to point out in the draft. I agree that there are certain applications where delay is less important than others. For mDNS, whether it is delay-critical may also depend on the application that uses mDNS to discover the service. > > We ended up using parameter settings (4) above. > > I think something like trickle multicast is a MUST for mesh routing > solutions like ROLL. The issue you get into using multicast is how the > messages are propagated. If every device that sees a multicast simply > forwards, then you end up with broadcast storms where nothing is heard. > The randomization of re-broadcast is essential. > But since you don't use suppression, the overhead is likely more substantial than in classic flooding. Using a decent jitter value in classic flooding, or more advanced flooding mechanisms such as MPR flooding would likely lead to much lower channel use. Have you compared to MPR flooding or classic flooding with jitter ? > > I think our results are being incorporated into the ROLL deployment > experience draft > (http://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment/). > > By the way, someone noted the lack of a Security Considerations section. > We force Link Layer security on so did not plan any additional security > than that..... > That may work in some deployments, but will not suffice for the draft to only rely on link-layer security, and to not even have a security considerations section. Best Ulrich > On 10/29/12 9:38 AM, "Ulrich Herberg" wrote: > > >Hi Don, > > > >thanks, that's good to know. To your knowledge, are there any public > >results about delivery ratio of packets, overhead, delay, state > >requirements and/or a comparison to other flooding mechanisms such as > >classic flooding? > > > >Best > >Ulrich > > > >On Oct 26, 2012, at 20:50, Don Sturek wrote: > > > >> Hi Ulrich, > >> > >> For ZigBee IP, we are using the trickle multicast draft. We have 7 > >> platforms interoperating using the draft. > >> > >> Don > >> > >> > >> On 10/26/12 8:33 PM, "Ulrich Herberg" wrote: > >> > >>> Hi, > >>> > >>> below is my review. > >>> > >>> My major comment is that the IANA section needs to be fixed and a > >>> security considerations section needs to be written. Without that > >>> section, the document should not go forward in my opinion. > >>> Then I have multiple questions for clarity (see the detailed review). > >>> Also, as a standards track document, I think it should give some > >>> guidelines about which values for the parameters to use, as well as > >>> some indications about the state requirements of the protocol. > >>> Are there any implementations and/or deployments of the protocol out > >>> there? > >>> > >>> Best regards > >>> Ulrich > >>> > >>> > >>> > >>> > >>> ROLL J. > >>>Hui > >>> Internet-Draft > >>>Cisco > >>> Intended status: Standards Track R. > >>>Kelsey > >>> Expires: April 22, 2013 Silicon > >>>Labs > >>> October 19, 2012 > >>> > >>> > >>> Multicast Protocol for Low power and Lossy Networks (MPL) > >>> draft-ietf-roll-trickle-mcast-02 > >>> > >>> Abstract > >>> > >>> This document specifies the Multicast Protocol for Low power and > >>> Lossy Networks (MPL) that provides IPv6 multicast forwarding in > >>> constrained networks. MPL avoids the need to construct or maintain > >>> any multicast forwarding topology, disseminating messages to all MPL > >>> forwarders in an MPL domain. MPL uses the Trickle algorithm to drive > >>> packet transmissions for both control and data-plane packets. > >>> Specific Trickle parameter configurations allow MPL to trade between > >>> dissemination latency and transmission efficiency. > >>> > >>> Status of this Memo > >>> > >>> This Internet-Draft is submitted in full conformance with the > >>> provisions of BCP 78 and BCP 79. > >>> > >>> Internet-Drafts are working documents of the Internet Engineering > >>> Task Force (IETF). Note that other groups may also distribute > >>> working documents as Internet-Drafts. The list of current Internet- > >>> Drafts is at http://datatracker.ietf.org/drafts/current/. > >>> > >>> Internet-Drafts are draft documents valid for a maximum of six months > >>> and may be updated, replaced, or obsoleted by other documents at any > >>> time. It is inappropriate to use Internet-Drafts as reference > >>> material or to cite them other than as "work in progress." > >>> > >>> This Internet-Draft will expire on April 22, 2013. > >>> > >>> Copyright Notice > >>> > >>> Copyright (c) 2012 IETF Trust and the persons identified as the > >>> document authors. All rights reserved. > >>> > >>> This document is subject to BCP 78 and the IETF Trust's Legal > >>> Provisions Relating to IETF Documents > >>> (http://trustee.ietf.org/license-info) in effect on the date of > >>> publication of this document. Please review these documents > >>> carefully, as they describe your rights and restrictions with respect > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>1] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> to this document. Code Components extracted from this document must > >>> include Simplified BSD License text as described in Section 4.e of > >>> the Trust Legal Provisions and are provided without warranty as > >>> described in the Simplified BSD License. > >>> > >>> > >>> Table of Contents > >>> > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > >>> 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > >>> 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 > >>> 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7 > >>> 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8 > >>> 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9 > >>> 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11 > >>> 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11 > >>> 5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12 > >>> 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12 > >>> 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13 > >>> 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13 > >>> 5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15 > >>> 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16 > >>> 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16 > >>> 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17 > >>> 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 > >>> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > >>> 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 > >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>2] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 1. Introduction > >>> > >>> Low power and Lossy Networks typically operate with strict resource > >>> constraints in communication, computation, memory, and energy. Such > >>> resource constraints may preclude the use of existing IPv6 multicast > >>> topology and forwarding mechanisms. Traditional IP multicast > >>> forwarding typically relies on topology maintenance mechanisms to > >>> forward multicast messages to all subscribers of a multicast group. > >>> However, maintaining such topologies in LLNs is costly and may not be > >>> feasible given the available resources. > >>> > >>> Memory constraints may limit devices to maintaining links/routes to > >>> one or a few neighbors. For this reason, the Routing Protocol for > >>> LLNs (RPL) > >>> > >>> UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and > >>> Lossy Networks" > >>> > >>> specifies both storing and non-storing modes [RFC6550]. > >>> The latter allows RPL routers to maintain only one or a few default > >>> routes towards a LLN Border Router (LBR) > >>> > >>> UH> I did not find LBR in the terminology section. > >>> > >>> and use source routing to > >>> forward packets away from the LBR. For the same reasons, a LLN > >>> device may not be able to maintain a multicast forwarding topology > >>> when operating with limited memory. > >>> > >>> Furthermore, the dynamic properties of wireless networks can make the > >>> cost of maintaining a multicast forwarding topology prohibitively > >>> expensive. In wireless environments, topology maintenance may > >>> involve selecting a connected dominating set used to forward > >>> multicast messages to all nodes in an administrative domain. > >>> However, existing mechanisms often require two-hop topology > >>> information and the cost of maintaining such information grows > >>> polynomially with network density. > >>> > >>> This document specifies the Multicast Protocol for Low power and > >>> Lossy Networks (MPL), which provides IPv6 multicast forwarding in > >>> constrained networks. MPL avoids the need to construct or maintain > >>> any multicast forwarding topology, disseminating multicast messages > >>> to all MPL forwarders in an MPL domain. By using the Trickle > >>> algorithm [RFC6206], MPL requires only small, constant state for each > >>> MPL device that initiates disseminations. The Trickle algorithm also > >>> allows MPL to be density-aware, allowing the communication rate to > >>> scale logarithmically with density. > >>> > >>> UH> I am not sure I understand the last sentence. What does it mean? > >>> How is that achieved? > >>> > >>> UH> By the way, since this is a standards track document, is there any > >>> deployment experience? Implementations? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>3] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 2. Terminology > >>> > >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > >>> document are to be interpreted as described in RFC 2119 [RFC2119]. > >>> > >>> UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119 > >>> > >>> > >>> The following terms are used throughout this document: > >>> > >>> MPL forwarder An IPv6 router that subscribes to the MPL > >>> multicast group and participates in disseminating > >>> MPL multicast packets. > >>> > >>> MPL multicast scope The multicast scope that MPL uses when forwarding > >>> MPL multicast packets. In other words, the > >>> multicast scope of the IPv6 Destination Address > >>> of an MPL multicast packet. > >>> > >>> UH> An RFC reference to "scope" could be helpful. > >>> > >>> MPL domain A connected set of MPL forwarders that define the > >>> extent of the MPL dissemination process. > >>> > >>> UH> What does connected mean? What if a the network is split in two > >>>parts? > >>> > >>> As a > >>> form of flood, all MPL forwarders in an MPL > >>> domain will receive MPL multicast packets. > >>> > >>> UH> Probably not *all* forwards will receive it (assuming packets can > >>> be lost) > >>> > >>> > >>> The > >>> MPL domain MUST be composed of at least one MPL > >>> multicast scope and MAY be composed of multiple > >>> MPL multicast scopes. > >>> > >>> UH> Why is that? Anyway, I am unsure whether one can say that a > >>> routing domain "consists" of multicast scopes. If I understand that > >>> correctly, the multicast scope just determines how far a message > >>> propagates. > >>> > >>> > >>> MPL seed A MPL forwarder that begins the dissemination > >>> process for an MPL multicast packet. The MPL > >>> seed may be different than the source of the > >>> original multicast packet. > >>> > >>> MPL seed identifier An identifier that uniquely identifies an MPL > >>> forwarder within its MPL domain. > >>> > >>> UH> How is the uniqueness guaranteed? What kind of identifier is that? > >>> An IP address? I see it's defined later, but maybe it would be helpful > >>> to mention it here, too. > >>> > >>> > >>> original multicast packet An IPv6 multicast packet that is > >>> disseminated using MPL. > >>> > >>> UH> That terminology sounds a bit confusing; I would have imagined > >>> that the above description matches the following term "MPL multicast > >>> packet". What's the difference between an "original multicast packet" > >>> and an "MPL multicast packet"? I assume the one is the inner packet > >>> when using IPv6-in-IPv6 tunnels, the other one is the outer packet > >>> with the options header. > >>> > >>> > >>> MPL multicast packet An IPv6 multicast packet that contains an MPL > >>> Hop-by-Hop Option. When either source or > >>> destinations are beyond the MPL multicast scope, > >>> > >>> UH> Above it was said there may be multiple scopes in a domain. Here > >>> you talk about "the" scope. Which one? > >>> > >>> the MPL multicast packet is an IPv6-in-IPv6 > >>> packet that contains an MPL Hop-by-Hop Option in > >>> the outer IPv6 header and encapsulates an > >>> original multicast packet. When both source and > >>> destinations are within the MPL multicast scope, > >>> the MPL Hop-by-Hop Option may be included > >>> directly within the original multicast packet. > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>4] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 3. Overview > >>> > >>> MPL delivers IPv6 multicast packets by disseminating them to all MPL > >>> forwarders within an MPL domain. MPL dissemination is a form of > >>> flood. An MPL forwarder may broadcast/multicast an MPL multicast > >>> packet out of the same physical interface on which it was received. > >>> Using link-layer broadcast/multicast allows MPL to forward multicast > >>> packets without explicitly identifying next-hop destinations. An MPL > >>> forwarder may also broadcast/multicast MPL multicast packets out > >>> other interfaces to disseminate the message across different links. > >>> MPL does not build or maintain a multicast forwarding topology to > >>> forward multicast packets. > >>> > >>> Any MPL forwarder may initiate the dissemination process by serving > >>> as an MPL seed for an original multicast packet. The MPL seed may or > >>> may not be the same device as the source of the original multicast > >>> packet. When the original multicast packet's source is outside the > >>> LLN, > >>> > >>> UH> LLN or MPL domain? How can a router determine if an incoming > >>> packet is inside our outside the MPL domain? > >>> > >>> the MPL seed may be the ingress router. Even if an original > >>> multicast packet source is within the LLN, the source may first > >>> forward the multicast packet to the MPL seed using IPv6-in-IPv6 > >>> tunneling. > >>> > >>> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a > >>> title not related to "IPv6 tunneling". I suggest to make an own > >>> section. > >>> > >>> Because MPL state requirements grows with the number of > >>> active MPL seeds, > >>> > >>> UH> In section 1 it was written that the state is constant. Here you > >>> say it grows. Which one is it? > >>> > >>> limiting the number of MPL seeds reduces the amount > >>> of state that MPL forwarders must maintain. > >>> > >>> Because MPL typically broadcasts/multicasts MPL packets out of the > >>> same interface on which they were received, > >>> > >>> UH> Why typically? Doesn't that depend on the scenario that this > >>> specification is used in? > >>> > >>> MPL forwarders are likely > >>> to receive an MPL multicast packet more than once. > >>> > >>> UH> I am not sure if that is the only reason. Isn't the reason that it > >>> may be received from multiple neighbors? > >>> > >>> The MPL seed tags > >>> each original multicast packet with an MPL seed identifier and a > >>> sequence number. The sequence number provides a total ordering of > >>> MPL multicast packets disseminated by the MPL seed. > >>> > >>> MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include > >>> MPL-specific information along with the original multicast packet. > >>> Each IPv6 multicast packet that MPL disseminates includes the MPL > >>> Option. Because the original multicast packet's source and the MPL > >>> seed may not be the same device, the MPL Option may be added to the > >>> original multicast packet en-route. To allow Path MTU discovery to > >>> work properly, MPL encapsulates the original multicast packet in > >>> another IPv6 header that includes the MPL Option. > >>> > >>> Upon receiving a new MPL multicast packet for forwarding, the MPL > >>> forwarder may proactively transmit the MPL multicast packet packet a > >>> limited number of times and then falls back into an optional reactive > >>> mode. In maintenance mode, an MPL forwarder buffers recently > >>> received MPL multicast packets and advertises a summary of recently > >>> received MPL multicast packets from time to time, allowing > >>> neighboring MPL forwarders to determine if they have any new > >>> multicast packets to offer or receive. > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>5] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> MPL forwarders schedule their packet (control and data) transmissions > >>> using the Trickle algorithm [RFC6206]. Trickle's adaptive > >>> transmission interval allows MPL to quickly disseminate messages when > >>> there are new MPL multicast packets, but reduces transmission > >>> overhead as the dissemination process completes. Trickle's > >>> suppression mechanism and transmission time selection allow MPL's > >>> communication rate to scale logarithmically with density. > >>> > >>> UH> I think the whole introduction is not very easy to read. There is > >>> a lot of text about some details (IPv6-in-IPv6 tunnels, multiple > >>> interfaces), but the essential mechanism is hard to identify from the > >>> text. Also, there is nothing mentioned about what kind of state is > >>> required to be stored on each router (which information sets etc). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>6] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 4. Message Formats > >>> > >>> 4.1. MPL Option > >>> > >>> The MPL Option is carried in an IPv6 Hop-by-Hop Options header, > >>> > >>> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options > >>>header" > >>> > >>> UH> More importantly, RFC6564 specifies: > >>> > >>> New options for the existing Hop-by-Hop Header SHOULD NOT be > >>> created or specified unless no alternative solution is feasible. > >>> Any proposal to create a new option for the existing Hop-by-Hop > >>> Header MUST include a detailed explanation of why the hop-by-hop > >>> behavior is absolutely essential in the document proposing the new > >>> option with hop-by-hop behavior. > >>> > >>> UH> I did not see such an explanation. > >>> > >>> > >>> immediately following the IPv6 header. The MPL Option has the > >>> following format: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Option Type | Opt Data Len | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | S |M| rsv | sequence | seed-id (optional) | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> UH> It could help to mention that this is formatted in network byte > >>>order > >>> > >>> Option Type XX (to be confirmed by IANA). > >>> > >>> Opt Data Len Length of the Option Data field in octets. MUST > >>> be set to either 2 or 4. > >>> > >>> UH> 2 or 4 depending on what? > >>> > >>> S 2-bit unsigned integer. Identifies the length of > >>> seed-id. 0 indicates that the seed-id is 0 and > >>> not included in the MPL Option. 1 indicates that > >>> the seed-id is a 16-bit unsigned integer. 2 > >>> indicates that the seed-id is a 64-bit unsigned > >>> integer. 3 indicates that the seed-id is a 128- > >>> bit unsigned integer. > >>> > >>> M 1-bit flag. 0 indicates that the value in > >>> sequence is not the greatest sequence number that > >>> was received from the MPL seed. > >>> > >>> rsv 5-bit reserved field. MUST be set to zero and > >>> incoming MPL multicast packets in which they are > >>> not zero MUST be dropped. > >>> > >>> sequence 8-bit unsigned integer. Identifies relative > >>> ordering of MPL multicast packets from the source > >>> identified by seed-id. > >>> > >>> seed-id Uniquely identifies the MPL seed that initiated > >>> dissemination of the MPL multicast packet. The > >>> size of seed-id is indicated by the S field. > >>> > >>> The Option Data of the Trickle Multicast option MUST NOT change as > >>> the MPL multicast packet is forwarded. Nodes that do not understand > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>7] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> the Trickle Multicast option MUST discard the packet. Thus, > >>> according to [RFC2460] the three high order bits of the Option Type > >>> must be set to '010'. The Option Data length is variable. > >>> > >>> The seed-id uniquely identifies an MPL seed within the MPL domain. > >>> When seed-id is 128 bits (S=3), the MPL seed MAY use an IPv6 address > >>> assigned to one of its interfaces that is unique within the MPL > >>> domain. Managing MPL seed identifiers is not within scope of this > >>> document. > >>> > >>> The sequence field establishes a total ordering of MPL multicast > >>> packets from the same MPL seed. The MPL seed MUST increment the > >>> sequence field's value on each new MPL multicast packet that it > >>> disseminates. Implementations MUST follow the Serial Number > >>> Arithmetic as defined in [RFC1982] when incrementing a sequence value > >>> or comparing two sequence values. > >>> > >>> Future updates to this specification may define additional fields > >>> following the seed-id field. > >>> > >>> 4.2. ICMPv6 MPL Message > >>> > >>> The MPL forwarder uses ICMPv6 MPL messages to advertise information > >>> about recently received MPL multicast packets. The ICMPv6 MPL > >>> message has the following format: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Type | Code | Checksum | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | | > >>> . MPL Window[1..n] . > >>> . . > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> > >>> IP Fields: > >>> > >>> Source Address A link-local address assigned to the sending > >>> interface. > >>> > >>> Destination Address The link-local all-nodes MPL forwarders multicast > >>> address (FF02::TBD). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>8] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> Hop Limit 255 > >>> > >>> ICMPv6 Fields: > >>> > >>> Type XX (to be confirmed by IANA). > >>> > >>> Code 0 > >>> > >>> Checksum The ICMP checksum. See [RFC4443]. > >>> > >>> MPL Window[1..n] List of one or more MPL Windows (defined in > >>> Section 4.2.1). > >>> > >>> An MPL forwarder transmits an ICMPv6 MPL message to advertise > >>> information about buffered MPL multicast packets. More explicitly, > >>> the ICMPv6 MPL message encodes the sliding window state (described in > >>> Section 5.2) that the MPL forwarder maintains for each MPL seed. The > >>> advertisement serves to indicate to neighboring MPL forwarders > >>> regarding newer messages that it may send or the neighboring MPL > >>> forwarders have yet to receive. > >>> > >>> 4.2.1. MPL Window > >>> > >>> An MPL Window encodes the sliding window state (described in > >>> Section 5.2 that the MPL forwarder maintains for an MPL seed. > >>> > >>> UH> missing ")" > >>> > >>> Each > >>> MPL Window has the following format: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | w-min | w-len | S | seed-id (0, 2 or 16 octets) | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | | > >>> . buffered-mpl-packets (0 to 8 octets) . > >>> . . > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> > >>> w-min 8-bit unsigned integer. Indicates the first > >>> sequence number associated with the first bit in > >>> buffered-mpl-packets. > >>> > >>> w-len 6-bit unsigned integer. Indicates the size of > >>> the sliding window and the number of valid bits > >>> in buffered-mpl-packets. The sliding window's > >>> upper bound is the sum of w-min and w-len. > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>9] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> S 2-bit unsigned integer. Identifies the length of > >>> seed-id. 0 indicates that the seed-id value is 0 > >>> and not included in the MPL Option. 1 indicates > >>> that the seed-id value is a 16-bit unsigned > >>> integer. 2 indicates that the seed-id value is a > >>> 128-bit unsigned integer. 3 is reserved. > >>> > >>> seed-id Indicates the MPL seed associated with this > >>> sliding window. > >>> > >>> buffered-mpl-packets Variable-length bit vector. Identifies the > >>> sequence numbers of MPL multicast packets that > >>> the MPL forwarder has buffered. The sequence > >>> number is determined by w-min + i, where i is the > >>> offset within buffered-mpl-packets. > >>> > >>> The MPL Window does not have any octet alignment requirement. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>10] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 5. MPL Forwarder Behavior > >>> > >>> An MPL forwarder implementation needs to manage sliding windows for > >>> each active MPL seed. The sliding window allows the MPL forwarder to > >>> determine what multicast packets to accept and what multicast packets > >>> are buffered. An MPL forwarder must also manage MPL packet > >>> transmissions. > >>> > >>> 5.1. Multicast Packet Dissemination > >>> > >>> MPL uses the Trickle algorithm to control packet transmissions when > >>> disseminating MPL multicast packets [RFC6206]. MPL provides two > >>> propagation mechanisms for disseminating MPL multicast packets. > >>> > >>> 1. With proactive propagation, an MPL forwarder transmits buffered > >>> MPL multicast packets using the Trickle algorithm. This method > >>> is called proactive propagation since an MPL forwarder actively > >>> transmits MPL multicast packets without discovering that a > >>> neighboring MPL forwarder has yet to receive the message. > >>> > >>> 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL > >>> messages using the Trickle algorithm. An MPL forwarder only > >>> transmits buffered MPL multicast packets upon discovering that > >>> neighboring devices have not yet to receive the corresponding MPL > >>> multicast packets. > >>> > >>> When receiving a new multicast packet, an MPL forwarder first > >>> utilizes proactive propagation to forward the MPL multicast packet. > >>> Proactive propagation reduces dissemination latency since it does not > >>> require discovering that neighboring devices have not yet received > >>> the MPL multicast packet. MPL forwarders utilize proactive > >>> propagation for newly received MPL multicast packets since they can > >>> assume that some neighboring MPL forwarders have yet to receive the > >>> MPL multicast packet. After a limited number of MPL multicast packet > >>> transmissions, the MPL forwarder may terminate proactive propagation > >>> for the MPL multicast packet. > >>> > >>> An MPL forwarder may optionally use reactive propagation to continue > >>> the dissemination process with lower communication overhead. With > >>> reactive propagation, neighboring MPL forwarders use ICMPv6 MPL > >>> messages to discover new MPL multicast messages that have not yet > >>> been received. When discovering that a neighboring MPL forwarder has > >>> not yet received a new MPL multicast packet, the MPL forwarder > >>> enables proactive propagation again. > >>> > >>> UH> There is not a lot of RFC2119 language in the above. Or is that > >>> defined later? Is this above section more like an introduction? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>11] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 5.1.1. Trickle Parameters and Variables > >>> > >>> As specified in RFC 6206 [RFC6206], a Trickle timer runs for a > >>> defined interval and has three configuration parameters: the minimum > >>> interval size Imin, the maximum interval size Imax, and a redundancy > >>> constant k. > >>> > >>> MPL defines a fourth configuration parameter, TimerExpirations, which > >>> indicates the number of Trickle timer expiration events that occur > >>> before terminating the Trickle algorithm. > >>> > >>> Each MPL forwarder maintains a separate Trickle parameter set for the > >>> proactive and reactive propagation methods. TimerExpirations MUST be > >>> greater than 0 for proactive propagation. TimerExpirations MAY be > >>> set to 0 for reactive propagation, which effectively disables > >>> reactive propagation. > >>> > >>> As specified in RFC 6206 [RFC6206], a Trickle timer has three > >>> variables: the current interval size I, a time within the current > >>> interval t, and a counter c. > >>> > >>> UH> This sentence starts confusing, as it looks very similar to the > >>> first paragraph in this section. "a Trickle timer has three variables" > >>> How about using the same language as in RFC6206: > >>> "In addition to these three parameters, Trickle maintains three > >>> variables: > >>> o I, the current interval size, > >>> o t, a time within the current interval, and > >>> o c, a counter." > >>> > >>> > >>> MPL defines a fourth variable, e, which counts the number of Trickle > >>> timer expiration events since the Trickle timer was last reset. > >>> > >>> 5.1.2. Proactive Propagation > >>> > >>> With proactive propagation, the MPL forwarder transmits buffered MPL > >>> multicast packets using the Trickle algorithm. Each buffered MPL > >>> multicast packet that is proactively being disseminated with > >>> proactive propagation has an associated Trickle timer. > >>> > >>> UH> I think that somewhere the state requirements need to be > >>> mentioned. How does that affect scalability of the algorithm etc. > >>> Density is mentioned somewhere in the beginning, but not explained how > >>> that would affect scalability and state requirements. > >>> > >>> Adhering to > >>> Section 5 of RFC 6206 [RFC6206], this document defines the following: > >>> > >>> o This document defines a "consistent" transmission for proactive > >>> propagation as receiving an MPL multicast packet that has the same > >>> MPL seed identifier and sequence number as a buffered MPL packet. > >>> > >>> o This document defines an "inconsistent" transmission for proactive > >>> propagation as receiving an MPL multicast packet that has the same > >>> MPL seed identifier, the M flag set, and has a sequence number > >>> less than the buffered MPL multicast packet's sequence number. > >>> > >>> o This document does not define any external "events". > >>> > >>> o This document defines both MPL multicast packets and ICMPv6 MPL > >>> multicast packets as Trickle messages. These messages are defined > >>> in the sections below. > >>> > >>> UH> I don't see the term Trickle message used anywhere else. > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>12] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> o The actions outside the Trickle algorithm that the protocol takes > >>> involve managing sliding window state, and is specified in > >>> Section 5.2. > >>> > >>> 5.1.3. Reactive Propagation > >>> > >>> With reactive propagation, the MPL forwarder transmits ICMPv6 MPL > >>> messages using the Trickle algorithm. A MPL forwarder maintains a > >>> single Trickle timer for reactive propagation with each MPL domain. > >>> When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not > >>> execute the Trickle algorithm for reactive propagation and reactive > >>> propagation is disabled. Adhering to Section 5 of RFC 6206 > >>> [RFC6206], this document defines the following: > >>> > >>> o This document defines a "consistent" transmission for reactive > >>> propagation as receiving an ICMPv6 MPL message that indicates > >>> neither the receiving nor transmitting node has new MPL multicast > >>> packets to offer. > >>> > >>> o This document defines an "inconsistent" transmission for reactive > >>> propagation as receiving an ICMPv6 MPL message that indicates > >>> either the receiving or transmitting node has at least one new MPL > >>> multicast packet to offer. > >>> > >>> o This document defines an "event" for reactive propagation as > >>> updating any sliding window (i.e. changing the value of WindowMin, > >>> WindowMax, or the set of buffered MPL multicast packets) in > >>> response to receiving an MPL multicast packet. > >>> > >>> o This document defines both MPL multicast packets and ICMPv6 MPL > >>> multicast packets as Trickle messages. These messages are defined > >>> in the sections below. > >>> > >>> UH> I don't see the term "Trickle message" anywhere else (other than > >>> in 5.1.2) > >>> > >>> > >>> o The actions outside the Trickle algorithm that the protocol takes > >>> involve managing sliding window state, and is specified in > >>> Section 5.2. > >>> > >>> 5.2. Sliding Windows > >>> > >>> Every MPL forwarder MUST maintain a sliding window of sequence > >>> numbers for each MPL seed of recently received MPL packets. The > >>> sliding window performs two functions: > >>> > >>> 1. Indicate what MPL multicast packets the MPL forwarder should > >>> accept. > >>> > >>> 2. Indicate what MPL multicast packets are buffered and may be > >>> transmitted to neighboring MPL forwarders. > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>13] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> Each sliding window logically consists of: > >>> > >>> 1. A lower-bound sequence number, WindowMin, that represents the > >>> sequence number of the oldest MPL multicast packet the MPL > >>> forwarder is willing to receive or has buffered. An MPL > >>> forwarder MUST ignore any MPL multicast packet that has sequence > >>> value less than than WindowMin. > >>> > >>> 2. An upper-bound sequence value, WindowMax, that represents the > >>> sequence number of the next MPL multicast packet that the MPL > >>> forwarder expects to receive. An MPL forwarder MUST accept any > >>> MPL multicast packet that has sequence number greater than or > >>> equal to WindowMax. > >>> > >>> 3. A list of MPL multicast packets, BufferedPackets, buffered by the > >>> MPL forwarder. Each entry in BufferedPackets MUST have a > >>> sequence number in the range [WindowMin, WindowMax). > >>> > >>> 4. A timer, HoldTimer, that indicates the minimum lifetime of the > >>> sliding window. The MPL forwarder MUST NOT free a sliding window > >>> before HoldTimer expires. > >>> > >>> When receiving an MPL multicast packet, if no existing sliding window > >>> exists for the MPL seed, the MPL forwarder MUST create a new sliding > >>> window before accepting the MPL multicast packet. The MPL forwarder > >>> may reclaim memory resources by freeing a sliding window for another > >>> MPL seed if its HoldTimer has expired. If, for any reason, the MPL > >>> forwarder cannot create a new sliding window, it MUST discard the > >>> packet. > >>> > >>> If a sliding window exists for the MPL seed, the MPL forwarder MUST > >>> ignore the MPL multicast packet if the packet's sequence number is > >>> less than WindowMin or appears in BufferedPackets. Otherwise, the > >>> MPL forwarder MUST accept the packet and determine whether or not to > >>> forward the packet and/or pass the packet to the next higher layer. > >>> > >>> When accepting an MPL multicast packet, the MPL forwarder MUST update > >>> the sliding window based on the packet's sequence number. If the > >>> sequence number is not less than WindowMax, the MPL forwarder MUST > >>> set WindowMax to 1 greater than the packet's sequence number. If > >>> WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST > >>> increment WindowMin such that WindowMax - WindowMin <= > >>> MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free > >>> any entries in BufferedPackets that have a sequence number less than > >>> WindowMin. > >>> > >>> If the MPL forwarder has available memory resources, it MUST buffer > >>> the MPL multicast packet for proactive propagation. If not enough > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>14] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> memory resources are available to buffer the packet, the MPL > >>> forwarder MUST increment WindowMin and free entries in > >>> BufferedPackets that have a sequence number less than WindowMin until > >>> enough memory resources are available. Incrementing WindowMin will > >>> ensure that the MPL forwarder does not accept previously received > >>> packets. > >>> > >>> An MPL forwarder MAY reclaim memory resources from sliding windows > >>> for other MPL seeds. If a sliding window for another MPL seed is > >>> actively disseminating messages and has more than one entry in its > >>> BufferedPackets, the MPL forwarder may free entries for that MPL seed > >>> by incrementing WindowMin as described above. > >>> > >>> If the MPL forwarder cannot free enough memory resources to buffer > >>> the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1 > >>> greater than the packet's sequence number. > >>> > >>> When memory resources are available, an MPL forwarder SHOULD buffer a > >>> MPL multicast packet until the proactive propagation completes (i.e. > >>> the Trickle algorithm stops execution) and MAY buffer for longer. > >>> After proactive propagation completes, the MPL forwarder may advance > >>> WindowMin to the packet's sequence number to reclaim memory > >>> resources. When the MPL forwarder no longer buffers any packets, it > >>> MAY set WindowMin equal to WindowMax. When setting WindowMin equal > >>> to WindowMax, the MPL forwarder MUST initialize HoldTimer to > >>> WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the > >>> MPL forwarder MAY free the sliding window to reclaim memory > >>> resources. > >>> > >>> 5.3. Transmission of MPL Multicast Packets > >>> > >>> The MPL forwarder manages buffered MPL multicast packet transmissions > >>> using the Trickle algorithm. When adding a packet to > >>> BufferedPackets, the MPL forwarder MUST create a Trickle timer for > >>> the packet and start execution of the Trickle algorithm. > >>> > >>> After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL > >>> forwarder MUST stop executing the Trickle algorithm. When a buffered > >>> MPL multicast packet does not have an active Trickle timer, the MPL > >>> forwarder MAY free the buffered packet by advancing WindowMin to 1 > >>> greater than the packet's sequence number. > >>> > >>> Each interface that supports MPL is configured with exactly one MPL > >>> multicast scope. The MPL multicast scope MUST be site-local or > >>> smaller and defaults to link-local. A scope larger than link-local > >>> MAY be used only when that scope corresponds exactly to the MPL > >>> domain. > >>> > >>> UH> Why is this written in a section called "Transmission of MPL > >>> Multicast Packets"? Seems more like an initial configuration. Same for > >>> the below IPv6.. I would have expected that in a dedicated section > >>> about IPv6 tunneling > >>> UH> How would the router now that the scope corresponds exactly to the > >>> MPL domain? > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>15] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> An MPL domain may therefore be composed of one or more MPL multicast > >>> scopes. For example, the MPL domain may be composed of a single MPL > >>> multicast scope when using a site-local scope. Alternatively, the > >>> MPL domain may be composed of multiple MPL multicast scopes when > >>> using a link-local scope. > >>> > >>> UH> I am not quite sure how the scope works in this specification. Is > >>> that used somewhere when deciding whether to forward packets? > >>> > >>> IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an > >>> original multicast packet whose source or destination address is > >>> outside the MPL multicast scope. > >>> > >>> UH> The source address is a unicast address, right? How can that be > >>> outside a multicast scope? How would you know? > >>> > >>> IPv6-in-IPv6 encapsulation is > >>> necessary to support Path MTU discovery when the MPL forwarder is not > >>> the source of the original multicast packet. 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. > >>> > >>> UH> That should be specified more clearly. What does "remove" mean? I > >>> suppose you mean decapsulate the inner IPv6 packet. > >>> > >>> The destination address scope for the outer IPv6 > >>> header MUST be the MPL multicast scope. > >>> > >>> UH> Again, which one? I thought there can be several scopes? > >>> > >>> When an MPL domain is composed of multiple MPL multicast scopes (e.g. > >>> when the MPL multicast scope is link-local), an MPL forwarder MUST > >>> decapsulate and encapsulate the original multicast packet when > >>> crossing between different MPL multicast scopes. > >>> > >>> UH> When would you know when to cross a multicast scope? Do you mean > >>> routing domain? > >>> > >>> In doing so, the > >>> MPL forwarder MUST duplicate the MPL Option, unmodified, in the new > >>> outer IPv6 header. > >>> > >>> The IPv6 destination address of the MPL multicast packet is the all- > >>> MPL-forwarders multicast address (TBD). > >>> > >>> UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest > >>> to define the variable and use the value only in the IANA section. > >>> > >>> The scope of the IPv6 > >>> destination address is set to the MPL multicast scope. > >>> > >>> UH> which one? > >>> > >>> 5.4. Reception of MPL Multicast Packets > >>> > >>> Upon receiving an MPL multicast packet, the MPL forwarder first > >>> determines whether or not to accept and buffer the MPL multicast > >>> packet based on its MPL seed and sequence value, as specified in > >>> Section 5.2. > >>> > >>> If the MPL forwarder accepts the MPL multicast packet, the MPL > >>> forwarder determines whether or not to deliver the original multicast > >>> packet to the next higher layer. > >>> > >>> UH> How would it determine that? > >>> > >>> For example, if the MPL multicast > >>> packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the > >>> outer IPv6 header, which also removes MPL Option. > >>> > >>> UH> For example? What exactly needs to be done? > >>> > >>> 5.5. Transmission of ICMPv6 MPL Messages > >>> > >>> The MPL forwarder generates and transmits a new ICMPv6 MPL message > >>> whenever Trickle requests a transmission. > >>> > >>> UH> So for each data packet there would be a new ICMPv6 message? > >>> Wouldn't that create a lot of overhead? > >>> > >>> UH> To which address is the ICMP message sent? On which interface? > >>> > >>> The MPL forwarder includes > >>> an encoding of each sliding window in the ICMPv6 MPL message. > >>> > >>> Each sliding window is encoded using an MPL Window entry, defined in > >>> Section 5.2. The MPL forwarder sets the MPL Window fields as > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>16] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> follows: > >>> > >>> S If the MPL seed identifier is 0, set S to 0. If the MPL seed > >>> identifier is within the range [1, 65535], set S to 2. Otherwise, > >>> set S to 3. > >>> > >>> w-min Set to the lower bound of the sliding window (i.e. > >>> WindowMin). > >>> > >>> w-len Set to the length of the window (i.e. WindowMax - WindowMin). > >>> > >>> seed-id If S is non-zero, set to the MPL seed identifier. > >>> > >>> buffered-mpl-packets Set each bit that represents a sequence number > >>> of a packet in BufferedPackets to 1. Set all other bits to 0. > >>> The i'th bit in buffered-mpl-packets represents a sequence number > >>> of w-min + i. > >>> > >>> 5.6. Reception of ICMPv6 MPL Messages > >>> > >>> An MPL forwarder processes each ICMPv6 MPL message that it receives > >>> to determine if it has any new MPL multicast packets to receive or > >>> offer. > >>> > >>> An MPL forwarder determines if a new MPL multicast packet has not > >>> been received from a neighboring node if any of the following > >>> conditions hold true: > >>> > >>> 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed > >>> that does not have a corresponding sliding window entry on the > >>> MPL forwarder. > >>> > >>> 2. The neighbor has a packet in its BufferedPackets that has > >>> sequence value greater than or equal to WindowMax (i.e. w-min + > >>> w-len >= WindowMax). > >>> > >>> 3. The neighbor has a packet in its BufferedPackets that has > >>> sequence number within range of the sliding window but is not > >>> included in BufferedPackets (i.e. the i'th bit in buffered-mpl- > >>> packets is set to 1, where the sequence number is w-min + i). > >>> > >>> When an MPL forwarder determines that it has not yet received a new > >>> MPL multicast packet buffered by a neighboring device, the MPL > >>> forwarder resets the Trickle timer associated with reactive > >>> propagation. > >>> > >>> An MPL forwarder determines if an entry in BufferedPackets has not > >>> been received by a neighboring MPL forwarder if any of the following > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>17] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> conditions hold true: > >>> > >>> 1. The ICMPv6 MPL message does not include an MPL Window for the > >>> packet's MPL seed. > >>> > >>> 2. The packet's sequence number is greater than or equal to the > >>> neighbor's WindowMax value (i.e. the packet's sequence number is > >>> greater than or equal to w-min + w-len). > >>> > >>> 3. The packet's sequence number is within the range of the > >>> neighbor's sliding window [WindowMin, WindowMax), but not > >>> included in the neighbor's BufferedPacket (i.e. the packet's > >>> sequence number is greater than or equal to w-min, strictly less > >>> than w-min + w-len, and the corresponding bit in buffered-mpl- > >>> packets is set to 0. > >>> > >>> When an MPL forwarder determines that it has at least one buffered > >>> MPL multicast packet that has not yet been received by a neighbor, > >>> the MPL forwarder resets the Trickle timer associated with reactive > >>> propagation. Additionally, for each buffered MPL multicast packet > >>> that should be transferred, the MPL forwarder MUST reset the Trickle > >>> timer and reset e to 0 for proactive propagation. If the Trickle > >>> timer for proactive propagation has already stopped execution, > >>> > >>> UH> Which timer? I thought there is one timer per packet in the > >>> proactive mode? > >>> > >>> the > >>> MPL forwarder MUST initialize a new Trickle timer and start execution > >>> of the Trickle algorithm. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>18] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 6. MPL Parameters > >>> > >>> An MPL forwarder maintains two sets of Trickle parameters for the > >>> proactive and reactive methods. The Trickle parameters are listed > >>> below: > >>> > >>> PROACTIVE_IMIN The minimum Trickle timer interval, as defined in > >>> [RFC6206] for proactive propagation. > >>> > >>> PROACTIVE_IMAX The maximum Trickle timer interval, as defined in > >>> [RFC6206] for proactive propagation. > >>> > >>> PROACTIVE_K The redundancy constant, as defined in [RFC6206] for > >>> proactive propagation. > >>> > >>> PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations > >>> that occur before terminating the Trickle algorithm. MUST be set > >>> to a value greater than 0. > >>> > >>> REACTIVE_IMIN The minimum Trickle timer interval, as defined in > >>> [RFC6206] for reactive propagation. > >>> > >>> REACTIVE_IMAX The maximum Trickle timer interval, as defined in > >>> [RFC6206] for reactive propagation. > >>> > >>> REACTIVE_K The redundancy constant, as defined in [RFC6206] for > >>> reactive propagation. > >>> > >>> REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations > >>> that occur before terminating the Trickle algorithm. MAY be set > >>> to 0, which disables reactive propagation. > >>> > >>> WINDOW_HOLD_TIME The minimum lifetime for sliding window state. > >>> > >>> > >>> UH> I don't see any recommendations for these values. That is > >>> typically requested in the IESG evaluation for standards track > >>> documents (either default values and/or guideslines on the values). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>19] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 7. Acknowledgements > >>> > >>> The authors would like to acknowledge the helpful comments of Robert > >>> Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy, > >>> Dario Tedeschi, and Peter van der Stok, which greatly improved the > >>> document. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>20] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 8. IANA Considerations > >>> > >>> The Trickle Multicast option requires an IPv6 Option Number. > >>> > >>> > >>> > >>> HEX act chg rest > >>> --- --- --- ----- > >>> C 01 0 TBD > >>> > >>> > >>> > >>> The first two bits indicate that the IPv6 node MUST discard the > >>> packet if it doesn't recognize the option type, and the third bit > >>> indicates that the Option Data MUST NOT change en-route. > >>> > >>> > >>> UH> That does not look like a valid IANA section. RFC 5226 give some > >>> good guidelines. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>21] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 9. Security Considerations > >>> > >>> TODO. > >>> > >>> > >>> UH> This document needs a security considerations section. Refer to RFC > >>> 3552. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>22] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> 10. References > >>> > >>> 10.1. Normative References > >>> > >>> [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, > >>> August 1996. > >>> > >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >>> Requirement Levels", BCP 14, RFC 2119, March 1997. > >>> > >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. > >>> > >>> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 > >>> (IPv6) Specification", RFC 2460, December 1998. > >>> > >>> [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in > >>> IPv6 Specification", RFC 2473, December 1998. > >>> > >>> [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control > >>> Message Protocol (ICMPv6) for the Internet Protocol > >>> Version 6 (IPv6) Specification", RFC 4443, March 2006. > >>> > >>> [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, > >>> "The Trickle Algorithm", RFC 6206, March 2011. > >>> > >>> [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., > >>> Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. > >>> Alexander, "RPL: IPv6 Routing Protocol for Low-Power and > >>> Lossy Networks", RFC 6550, March 2012. > >>> > >>> 10.2. Informative References > >>> > >>> [I-D.ietf-roll-terminology] > >>> Vasseur, J., "Terminology in Low power And Lossy > >>> Networks", draft-ietf-roll-terminology-06 (work in > >>> progress), September 2011. > >>> > >>> UH> That document is never actually cited. Also, it has not been > >>> updated in over a year. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>23] > >>> Internet-Draft MPL October > >>>2012 > >>> > >>> > >>> Authors' Addresses > >>> > >>> Jonathan W. Hui > >>> Cisco > >>> 170 West Tasman Drive > >>> San Jose, California 95134 > >>> USA > >>> > >>> Phone: +408 424 1547 > >>> Email: jonhui@cisco.com > >>> > >>> > >>> Richard Kelsey > >>> Silicon Labs > >>> 25 Thomson Place > >>> Boston, Massachusetts 02210 > >>> USA > >>> > >>> Phone: +617 951 1225 > >>> Email: richard.kelsey@silabs.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hui & Kelsey Expires April 22, 2013 [Page > >>>24] > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > >> > >> > > > --20cf307abeb5fbd71404cd36b00b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Don,

thanks for this information. See below

On Mon, Oct 29, 2012 at 11:06 AM, Don Sturek <d.st= urek@att.net> wrote:
Hi Ulrich,

We did quite a lot of testing using 30 nodes (our messaging profile) and using specific multicast parameter settings as follows:
1. =A0 iMin =3D 128ms, iMax=3D128ms, k=3Dinfinity, TAct=3D3, TDwell=3D16s 2. =A0 iMin =3D 128ms, iMax=3D128ms, k=3Dinfinity, TAct=3D1, TDwell=3D3s 3. =A0 iMin =3D 512ms, iMax=3D512ms, k=3Dinfinity, TAct=3D1, TDwell=3D3s 4. =A0 iMin =3D 512ms, iMax=3D512ms, k=3Dinfinity, TAct=3D3, TDwell=3D3s
First thing to note is we always set k=3Dinfinity since we could not
identify anything in our multicast streams to suppress (basically, we just<= br> wanted every device to see each multicast message at least once and
hopefully only once)

My understanding i= s that if you set k to infinity, you would probably see each message many m= ore times than just once.=A0
RFC6206 states:
=A0 "= In general,=A0this approach [setting=A0k to in= finity]=A0is highly dangerous and it i= s NOT RECOMMENDED.=A0Disabling suppres= sion means that every node will always send on every=A0interval; this can lead to congestion in dense networks. = This=A0approach is especially dangerou= s if many nodes reset their intervals= =A0at the same time. In general, it is much more desirable to set k to=A0a high value (e.g., 5 or 10) than infin= ity. Typical values for k=A0are 1-5: = these achieve a good balance between redundancy and low cost[Levis08]." 


I assu=
me that with k =3D infinity, the performance would be much worse than class=
ic flooding and you would have a lot of bandwidth consumption in the LLN. D=
id you observe=A0that?
=A0


Next, the main purpose of our multicast traffic was for resource discovery<= br> using mDNS so there is no driving requirement around low latency
applications (eg, other applications would be more sensitive to the iMin and iMax settings than we were).


I think this is important to point out in the draft. I agree that = there are certain applications where delay is less important than others. F= or mDNS, whether it is delay-critical may also depend on the application th= at uses mDNS to discover the service.

=A0

We ended up using parameter settings (4) above.

I think something like trickle multicast is a MUST for mesh routing
solutions like ROLL. =A0The issue you get into using multicast is how the messages are propagated. =A0If every device that sees a multicast simply forwards, then you end up with broadcast storms where nothing is heard.
The randomization of re-broadcast is essential.
=A0

But since you don't use suppression, the overhea= d is likely more substantial than in classic flooding. Using a decent jitte= r value in classic flooding, or more advanced flooding mechanisms such as M= PR flooding would likely lead to much lower channel use. Have you compared = to MPR flooding or classic flooding with jitter ?

=A0

I think our results are being incorporated into the ROLL deployment
experience draft
(http://datatracker.ietf.org/doc/draft-hui-vasseu= r-roll-rpl-deployment/).

By the way, someone noted the lack of a Security Considerations section. We force Link Layer security on so did not plan any additional security
than that.....


That may = work in some deployments, but will not suffice for the draft to only rely o= n link-layer security, and to not even have a security considerations secti= on.=A0

Best
Ulrich



On 10/29/12 9:38 AM, "Ulrich Herberg" <ulrich@herberg.name> wrote:

>Hi Don,
>
>thanks, that's good to know. To your knowledge, are there any publi= c
>results about delivery ratio of packets, overhead, delay, state
>requirements and/or a comparison to other flooding mechanisms such as >classic flooding?
>
>Best
>Ulrich
>
>On Oct 26, 2012, at 20:50, Don Sturek <d.sturek@att.net> wrote:
>
>> Hi Ulrich,
>>
>> For ZigBee IP, we are using the trickle multicast draft. =A0We hav= e 7
>> platforms interoperating using the draft.
>>
>> Don
>>
>>
>> On 10/26/12 8:33 PM, "Ulrich Herberg" <ulrich@herberg.name> wrote:
>>
>>> Hi,
>>>
>>> below is my review.
>>>
>>> My major comment is that the IANA section needs to be fixed an= d a
>>> security considerations section needs to be written. Without t= hat
>>> section, the document should not go forward in my opinion.
>>> Then I have multiple questions for clarity (see the detailed r= eview).
>>> Also, as a standards track document, I think it should give so= me
>>> guidelines about which values for the parameters to use, as we= ll as
>>> some indications about the state requirements of the protocol.=
>>> Are there any implementations and/or deployments of the protoc= ol out
>>> there?
>>>
>>> Best regards
>>> Ulrich
>>>
>>>
>>>
>>>
>>> ROLL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0J.
>>>Hui
>>> Internet-Draft
>>>Cisco
>>> Intended status: Standards Track =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 R.
>>>Kelsey
>>> Expires: April 22, 2013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Silicon
>>>Labs
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 October 19, 2012
>>>
>>>
>>> =A0 =A0 =A0Multicast Protocol for Low power and Lossy Networks= (MPL)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-roll-trickle-mc= ast-02
>>>
>>> Abstract
>>>
>>> =A0This document specifies the Multicast Protocol for Low powe= r and
>>> =A0Lossy Networks (MPL) that provides IPv6 multicast forwardin= g in
>>> =A0constrained networks. =A0MPL avoids the need to construct o= r maintain
>>> =A0any multicast forwarding topology, disseminating messages t= o all MPL
>>> =A0forwarders in an MPL domain. =A0MPL uses the Trickle algori= thm to drive
>>> =A0packet transmissions for both control and data-plane packet= s.
>>> =A0Specific Trickle parameter configurations allow MPL to trad= e between
>>> =A0dissemination latency and transmission efficiency.
>>>
>>> Status of this Memo
>>>
>>> =A0This Internet-Draft is submitted in full conformance with t= he
>>> =A0provisions of BCP 78 and BCP 79.
>>>
>>> =A0Internet-Drafts are working documents of the Internet Engin= eering
>>> =A0Task Force (IETF). =A0Note that other groups may also distr= ibute
>>> =A0working documents as Internet-Drafts. =A0The list of curren= t Internet-
>>> =A0Drafts is at http://datatracker.ietf.org/drafts/current/= .
>>>
>>> =A0Internet-Drafts are draft documents valid for a maximum of = six months
>>> =A0and may be updated, replaced, or obsoleted by other documen= ts at any
>>> =A0time. =A0It is inappropriate to use Internet-Drafts as refe= rence
>>> =A0material or to cite them other than as "work in progre= ss."
>>>
>>> =A0This Internet-Draft will expire on April 22, 2013.
>>>
>>> Copyright Notice
>>>
>>> =A0Copyright (c) 2012 IETF Trust and the persons identified as= the
>>> =A0document authors. =A0All rights reserved.
>>>
>>> =A0This document is subject to BCP 78 and the IETF Trust's= Legal
>>> =A0Provisions Relating to IETF Documents
>>> =A0(http://trustee.ietf.org/license-info) in effect on the date of=
>>> =A0publication of this document. =A0Please review these docume= nts
>>> =A0carefully, as they describe your rights and restrictions wi= th respect
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>1]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0to this document. =A0Code Components extracted from this do= cument must
>>> =A0include Simplified BSD License text as described in Section= 4.e of
>>> =A0the Trust Legal Provisions and are provided without warrant= y as
>>> =A0described in the Simplified BSD License.
>>>
>>>
>>> Table of Contents
>>>
>>> =A01. =A0Introduction . . . . . . . . . . . . . . . . . . . . = . . . . . =A03
>>> =A02. =A0Terminology =A0. . . . . . . . . . . . . . . . . . . = . . . . . . =A04
>>> =A03. =A0Overview . . . . . . . . . . . . . . . . . . . . . . = . . . . . =A05
>>> =A04. =A0Message Formats =A0. . . . . . . . . . . . . . . . . = . . . . . . =A07
>>> =A0 =A04.1. =A0MPL Option . . . . . . . . . . . . . . . . . . = . . . . . . =A07
>>> =A0 =A04.2. =A0ICMPv6 MPL Message . . . . . . . . . . . . . . = . . . . . . =A08
>>> =A0 =A0 =A04.2.1. =A0MPL Window . . . . . . . . . . . . . . . = . . . . . . . =A09
>>> =A05. =A0MPL Forwarder Behavior . . . . . . . . . . . . . . . = . . . . . 11
>>> =A0 =A05.1. =A0Multicast Packet Dissemination . . . . . . . . = . . . . . . 11
>>> =A0 =A0 =A05.1.1. =A0Trickle Parameters and Variables . . . . = . . . . . . . 12
>>> =A0 =A0 =A05.1.2. =A0Proactive Propagation =A0. . . . . . . . = . . . . . . . . 12
>>> =A0 =A0 =A05.1.3. =A0Reactive Propagation . . . . . . . . . . = . . . . . . . 13
>>> =A0 =A05.2. =A0Sliding Windows =A0. . . . . . . . . . . . . . = . . . . . . . 13
>>> =A0 =A05.3. =A0Transmission of MPL Multicast Packets =A0. . . = . . . . . . . 15
>>> =A0 =A05.4. =A0Reception of MPL Multicast Packets . . . . . . = . . . . . . 16
>>> =A0 =A05.5. =A0Transmission of ICMPv6 MPL Messages =A0. . . . = . . . . . . . 16
>>> =A0 =A05.6. =A0Reception of ICMPv6 MPL Messages . . . . . . . = . . . . . . 17
>>> =A06. =A0MPL Parameters . . . . . . . . . . . . . . . . . . . = . . . . . 19
>>> =A07. =A0Acknowledgements . . . . . . . . . . . . . . . . . . = . . . . . 20
>>> =A08. =A0IANA Considerations =A0. . . . . . . . . . . . . . . = . . . . . . 21
>>> =A09. =A0Security Considerations =A0. . . . . . . . . . . . . = . . . . . . 22
>>> =A010. References . . . . . . . . . . . . . . . . . . . . . . = . . . . 23
>>> =A0 =A010.1. Normative References . . . . . . . . . . . . . . = . . . . . 23
>>> =A0 =A010.2. Informative References . . . . . . . . . . . . . = . . . . . 23
>>> =A0Authors' Addresses . . . . . . . . . . . . . . . . . . = . . . . . . 24
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>2]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 1. =A0Introduction
>>>
>>> =A0Low power and Lossy Networks typically operate with strict = resource
>>> =A0constraints in communication, computation, memory, and ener= gy. =A0Such
>>> =A0resource constraints may preclude the use of existing IPv6 = multicast
>>> =A0topology and forwarding mechanisms. =A0Traditional IP multi= cast
>>> =A0forwarding typically relies on topology maintenance mechani= sms to
>>> =A0forward multicast messages to all subscribers of a multicas= t group.
>>> =A0However, maintaining such topologies in LLNs is costly and = may not be
>>> =A0feasible given the available resources.
>>>
>>> =A0Memory constraints may limit devices to maintaining links/r= outes to
>>> =A0one or a few neighbors. =A0For this reason, the Routing Pro= tocol for
>>> =A0LLNs (RPL)
>>>
>>> UH> The correct title is "RPL: IPv6 Routing Protocol f= or Low-Power and
>>> Lossy Networks"
>>>
>>> =A0 specifies both storing and non-storing modes [RFC6550]. >>> =A0The latter allows RPL routers to maintain only one or a few= default
>>> =A0routes towards a LLN Border Router (LBR)
>>>
>>> UH> I did not find LBR in the terminology section.
>>>
>>> =A0and use source routing to
>>> =A0forward packets away from the LBR. =A0For the same reasons,= a LLN
>>> =A0device may not be able to maintain a multicast forwarding t= opology
>>> =A0when operating with limited memory.
>>>
>>> =A0Furthermore, the dynamic properties of wireless networks ca= n make the
>>> =A0cost of maintaining a multicast forwarding topology prohibi= tively
>>> =A0expensive. =A0In wireless environments, topology maintenanc= e may
>>> =A0involve selecting a connected dominating set used to forwar= d
>>> =A0multicast messages to all nodes in an administrative domain= .
>>> =A0However, existing mechanisms often require two-hop topology=
>>> =A0information and the cost of maintaining such information gr= ows
>>> =A0polynomially with network density.
>>>
>>> =A0This document specifies the Multicast Protocol for Low powe= r and
>>> =A0Lossy Networks (MPL), which provides IPv6 multicast forward= ing in
>>> =A0constrained networks. =A0MPL avoids the need to construct o= r maintain
>>> =A0any multicast forwarding topology, disseminating multicast = messages
>>> =A0to all MPL forwarders in an MPL domain. =A0By using the Tri= ckle
>>> =A0algorithm [RFC6206], MPL requires only small, constant stat= e for each
>>> =A0MPL device that initiates disseminations. =A0The Trickle al= gorithm also
>>> =A0allows MPL to be density-aware, allowing the communication = rate to
>>> =A0scale logarithmically with density.
>>>
>>> UH> I am not sure I understand the last sentence. What does= it mean?
>>> How is that achieved?
>>>
>>> UH> By the way, since this is a standards track document, i= s there any
>>> deployment experience? Implementations?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>3]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 2. =A0Terminology
>>>
>>> =A0The key words "MUST", "MUST NOT", "= ;REQUIRED", "SHALL", "SHALL NOT",
>>> =A0"SHOULD", "SHOULD NOT", "RECOMMEND= ED", "MAY", and "OPTIONAL" in this
>>> =A0document are to be interpreted as described in RFC 2119 [RF= C2119].
>>>
>>> UH> "NOT RECOMMENDED" is missing as per the errat= a of RFC2119
>>>
>>>
>>> =A0The following terms are used throughout this document:
>>>
>>> =A0MPL forwarder =A0 =A0 =A0 An IPv6 router that subscribes to= the MPL
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multicast group and= participates in disseminating
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPL multicast packe= ts.
>>>
>>> =A0MPL multicast scope The multicast scope that MPL uses when = forwarding
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPL multicast packe= ts. =A0In other words, the
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multicast scope of = the IPv6 Destination Address
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of an MPL multicast= packet.
>>>
>>> UH> An RFC reference to "scope" could be helpful.=
>>>
>>> =A0MPL domain =A0 =A0 =A0 =A0 =A0A connected set of MPL forwar= ders that define the
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0extent of the MPL d= issemination process.
>>>
>>> UH> What does connected mean? What if a the network is spli= t in two
>>>parts?
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0As a
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0form of flood, all = MPL forwarders in an MPL
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain will receive= MPL multicast packets.
>>>
>>> UH> Probably not *all* forwards will receive it (assuming p= ackets can
>>> be lost)
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPL domain MUST be = composed of at least one MPL
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multicast scope and= MAY be composed of multiple
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPL multicast scope= s.
>>>
>>> UH> Why is that? Anyway, I am unsure whether one can say th= at a
>>> routing domain "consists" of multicast scopes. If I = understand that
>>> correctly, the multicast scope just determines how far a messa= ge
>>> propagates.
>>>
>>>
>>> =A0MPL seed =A0 =A0 =A0 =A0 =A0 =A0A MPL forwarder that begins= the dissemination
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process for an MPL = multicast packet. =A0The MPL
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seed may be differe= nt than the source of the
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0original multicast = packet.
>>>
>>> =A0MPL seed identifier An identifier that uniquely identifies = an MPL
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0forwarder within it= s MPL domain.
>>>
>>> UH> How is the uniqueness guaranteed? What kind of identifi= er is that?
>>> An IP address? I see it's defined later, but maybe it woul= d be helpful
>>> to mention it here, too.
>>>
>>>
>>> =A0original multicast packet =A0An IPv6 multicast packet that = is
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0disseminated using = MPL.
>>>
>>> UH> That terminology sounds a bit confusing; I would have i= magined
>>> that the above description matches the following term "MP= L multicast
>>> packet". What's the difference between an "origi= nal multicast packet"
>>> and an "MPL multicast packet"? I assume the one is t= he inner packet
>>> when using IPv6-in-IPv6 tunnels, the other one is the outer pa= cket
>>> with the options header.
>>>
>>>
>>> =A0MPL multicast packet =A0An IPv6 multicast packet that conta= ins an MPL
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hop-by-Hop Option. = =A0When either source or
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0destinations are be= yond the MPL multicast scope,
>>>
>>> UH> Above it was said there may be multiple scopes in a dom= ain. Here
>>> you talk about "the" scope. Which one?
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the MPL multicast p= acket is an IPv6-in-IPv6
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0packet that contain= s an MPL Hop-by-Hop Option in
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the outer IPv6 head= er and encapsulates an
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0original multicast = packet. =A0When both source and
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0destinations are wi= thin the MPL multicast scope,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the MPL Hop-by-Hop = Option may be included
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0directly within the= original multicast packet.
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>4]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 3. =A0Overview
>>>
>>> =A0MPL delivers IPv6 multicast packets by disseminating them t= o all MPL
>>> =A0forwarders within an MPL domain. =A0MPL dissemination is a = form of
>>> =A0flood. =A0An MPL forwarder may broadcast/multicast an MPL m= ulticast
>>> =A0packet out of the same physical interface on which it was r= eceived.
>>> =A0Using link-layer broadcast/multicast allows MPL to forward = multicast
>>> =A0packets without explicitly identifying next-hop destination= s. =A0An MPL
>>> =A0forwarder may also broadcast/multicast MPL multicast packet= s out
>>> =A0other interfaces to disseminate the message across differen= t links.
>>> =A0MPL does not build or maintain a multicast forwarding topol= ogy to
>>> =A0forward multicast packets.
>>>
>>> =A0Any MPL forwarder may initiate the dissemination process by= serving
>>> =A0as an MPL seed for an original multicast packet. =A0The MPL= seed may or
>>> =A0may not be the same device as the source of the original mu= lticast
>>> =A0packet. =A0When the original multicast packet's source = is outside the
>>> =A0LLN,
>>>
>>> UH> LLN or MPL domain? How can a router determine if an inc= oming
>>> packet is inside our outside the MPL domain?
>>>
>>> =A0the MPL seed may be the ingress router. =A0Even if an origi= nal
>>> =A0multicast packet source is within the LLN, the source may f= irst
>>> =A0forward the multicast packet to the MPL seed using IPv6-in-= IPv6
>>> =A0tunneling.
>>>
>>> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a sec= tion with a
>>> title not related to "IPv6 tunneling". I suggest to = make an own
>>> section.
>>>
>>> =A0Because MPL state requirements grows with the number of
>>> =A0active MPL seeds,
>>>
>>> UH> In section 1 it was written that the state is constant.= Here you
>>> say it grows. Which one is it?
>>>
>>> =A0 limiting the number of MPL seeds reduces the amount
>>> =A0of state that MPL forwarders must maintain.
>>>
>>> =A0Because MPL typically broadcasts/multicasts MPL packets out= of the
>>> =A0same interface on which they were received,
>>>
>>> UH> Why typically? Doesn't that depend on the scenario = that this
>>> specification is used in?
>>>
>>> =A0MPL forwarders are likely
>>> =A0to receive an MPL multicast packet more than once.
>>>
>>> UH> I am not sure if that is the only reason. Isn't the= reason that it
>>> may be received from multiple neighbors?
>>>
>>> =A0The MPL seed tags
>>> =A0each original multicast packet with an MPL seed identifier = and a
>>> =A0sequence number. =A0The sequence number provides a total or= dering of
>>> =A0MPL multicast packets disseminated by the MPL seed.
>>>
>>> =A0MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, t= o include
>>> =A0MPL-specific information along with the original multicast = packet.
>>> =A0Each IPv6 multicast packet that MPL disseminates includes t= he MPL
>>> =A0Option. =A0Because the original multicast packet's sour= ce and the MPL
>>> =A0seed may not be the same device, the MPL Option may be adde= d to the
>>> =A0original multicast packet en-route. =A0To allow Path MTU di= scovery to
>>> =A0work properly, MPL encapsulates the original multicast pack= et in
>>> =A0another IPv6 header that includes the MPL Option.
>>>
>>> =A0Upon receiving a new MPL multicast packet for forwarding, t= he MPL
>>> =A0forwarder may proactively transmit the MPL multicast packet= packet a
>>> =A0limited number of times and then falls back into an optiona= l reactive
>>> =A0mode. =A0In maintenance mode, an MPL forwarder buffers rece= ntly
>>> =A0received MPL multicast packets and advertises a summary of = recently
>>> =A0received MPL multicast packets from time to time, allowing<= br> >>> =A0neighboring MPL forwarders to determine if they have any ne= w
>>> =A0multicast packets to offer or receive.
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>5]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0MPL forwarders schedule their packet (control and data) tra= nsmissions
>>> =A0using the Trickle algorithm [RFC6206]. =A0Trickle's ada= ptive
>>> =A0transmission interval allows MPL to quickly disseminate mes= sages when
>>> =A0there are new MPL multicast packets, but reduces transmissi= on
>>> =A0overhead as the dissemination process completes. =A0Trickle= 's
>>> =A0suppression mechanism and transmission time selection allow= MPL's
>>> =A0communication rate to scale logarithmically with density. >>>
>>> UH> I think the whole introduction is not very easy to read= . There is
>>> a lot of text about some details (IPv6-in-IPv6 tunnels, multip= le
>>> interfaces), but the essential mechanism is hard to identify f= rom the
>>> text. Also, there is nothing mentioned about what kind of stat= e is
>>> required to be stored on each router (which information sets e= tc).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>6]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 4. =A0Message Formats
>>>
>>> 4.1. =A0MPL Option
>>>
>>> =A0The MPL Option is carried in an IPv6 Hop-by-Hop Options hea= der,
>>>
>>> UH> I think the correct term is "IPv6 Extension Hop-by= -Hop Options
>>>header"
>>>
>>> UH> More importantly, =A0RFC6564 specifies:
>>>
>>> =A0 =A0 New options for the existing Hop-by-Hop Header SHOULD = NOT be
>>> =A0 =A0 created or specified unless no alternative solution is= feasible.
>>> =A0 =A0 Any proposal to create a new option for the existing H= op-by-Hop
>>> =A0 =A0 Header MUST include a detailed explanation of why the = hop-by-hop
>>> =A0 =A0 behavior is absolutely essential in the document propo= sing the new
>>> =A0 =A0 option with hop-by-hop behavior.
>>>
>>> UH> I did not see such an explanation.
>>>
>>>
>>> =A0immediately following the IPv6 header. =A0The MPL Option ha= s the
>>> =A0following format:
>>>
>>> =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
>>> =A0 =A0 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
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0Option Type =A0| =A0Opt Data Len |
>>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>> =A0 =A0| S |M| =A0 rsv =A0 | =A0 sequence =A0 =A0| =A0 =A0 =A0= seed-id (optional) =A0 =A0 =A0 |
>>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>>
>>> UH> It could help to mention that this is formatted in netw= ork byte
>>>order
>>>
>>> =A0Option Type =A0 =A0 =A0 =A0 XX (to be confirmed by IANA). >>>
>>> =A0Opt Data Len =A0 =A0 =A0 =A0Length of the Option Data field= in octets. =A0MUST
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be set to either 2 = or 4.
>>>
>>> UH> 2 or 4 depending on what?
>>>
>>> =A0S =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2-bit unsigned intege= r. =A0Identifies the length of
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seed-id. 0 indicate= s that the seed-id is 0 and
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not included in the= MPL Option. 1 indicates that
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the seed-id is a 16= -bit unsigned integer. 2
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0indicates that the = seed-id is a 64-bit unsigned
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0integer. 3 indicate= s that the seed-id is a 128-
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bit unsigned intege= r.
>>>
>>> =A0M =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1-bit flag. 0 indicat= es that the value in
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sequence is not the= greatest sequence number that
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0was received from t= he MPL seed.
>>>
>>> =A0rsv =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5-bit reserved field. = =A0MUST be set to zero and
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0incoming MPL multic= ast packets in which they are
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not zero MUST be dr= opped.
>>>
>>> =A0sequence =A0 =A0 =A0 =A0 =A0 =A08-bit unsigned integer. =A0= Identifies relative
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ordering of MPL mul= ticast packets from the source
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0identified by seed-= id.
>>>
>>> =A0seed-id =A0 =A0 =A0 =A0 =A0 =A0 Uniquely identifies the MPL= seed that initiated
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dissemination of th= e MPL multicast packet. =A0The
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0size of seed-id is = indicated by the S field.
>>>
>>> =A0The Option Data of the Trickle Multicast option MUST NOT ch= ange as
>>> =A0the MPL multicast packet is forwarded. =A0Nodes that do not= understand
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>7]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0the Trickle Multicast option MUST discard the packet. =A0Th= us,
>>> =A0according to [RFC2460] the three high order bits of the Opt= ion Type
>>> =A0must be set to '010'. =A0The Option Data length is = variable.
>>>
>>> =A0The seed-id uniquely identifies an MPL seed within the MPL = domain.
>>> =A0When seed-id is 128 bits (S=3D3), the MPL seed MAY use an I= Pv6 address
>>> =A0assigned to one of its interfaces that is unique within the= MPL
>>> =A0domain. =A0Managing MPL seed identifiers is not within scop= e of this
>>> =A0document.
>>>
>>> =A0The sequence field establishes a total ordering of MPL mult= icast
>>> =A0packets from the same MPL seed. =A0The MPL seed MUST increm= ent the
>>> =A0sequence field's value on each new MPL multicast packet= that it
>>> =A0disseminates. =A0Implementations MUST follow the Serial Num= ber
>>> =A0Arithmetic as defined in [RFC1982] when incrementing a sequ= ence value
>>> =A0or comparing two sequence values.
>>>
>>> =A0Future updates to this specification may define additional = fields
>>> =A0following the seed-id field.
>>>
>>> 4.2. =A0ICMPv6 MPL Message
>>>
>>> =A0The MPL forwarder uses ICMPv6 MPL messages to advertise inf= ormation
>>> =A0about recently received MPL multicast packets. =A0The ICMPv= 6 MPL
>>> =A0message has the following format:
>>>
>>> =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
>>> =A0 =A0 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
>>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>> =A0 =A0| =A0 =A0 Type =A0 =A0 =A0| =A0 =A0 Code =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0Checksum =A0 =A0 =A0 =A0 =A0 =A0 |
>>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0 =A0. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL Windo= w[1..n] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.
>>> =A0 =A0. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>>
>>>
>>> =A0IP Fields:
>>>
>>> =A0Source Address =A0 =A0 =A0A link-local address assigned to = the sending
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interface.
>>>
>>> =A0Destination Address The link-local all-nodes MPL forwarders= multicast
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0address (FF02::TBD)= .
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>8]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0Hop Limit =A0 =A0 =A0 =A0 =A0 255
>>>
>>> =A0ICMPv6 Fields:
>>>
>>> =A0Type =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XX (to be confirmed by = IANA).
>>>
>>> =A0Code =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00
>>>
>>> =A0Checksum =A0 =A0 =A0 =A0 =A0 =A0The ICMP checksum. =A0See [= RFC4443].
>>>
>>> =A0MPL Window[1..n] =A0 =A0List of one or more MPL Windows (de= fined in
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 4.2.1).
>>>
>>> =A0An MPL forwarder transmits an ICMPv6 MPL message to adverti= se
>>> =A0information about buffered MPL multicast packets. =A0More e= xplicitly,
>>> =A0the ICMPv6 MPL message encodes the sliding window state (de= scribed in
>>> =A0Section 5.2) that the MPL forwarder maintains for each MPL = seed. =A0The
>>> =A0advertisement serves to indicate to neighboring MPL forward= ers
>>> =A0regarding newer messages that it may send or the neighborin= g MPL
>>> =A0forwarders have yet to receive.
>>>
>>> 4.2.1. =A0MPL Window
>>>
>>> =A0An MPL Window encodes the sliding window state (described i= n
>>> =A0Section 5.2 that the MPL forwarder maintains for an MPL see= d.
>>>
>>> UH> missing ")"
>>>
>>> =A0Each
>>> =A0MPL Window has the following format:
>>>
>>> =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
>>> =A0 =A0 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
>>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>> =A0 =A0| =A0 =A0 w-min =A0 =A0 | =A0 w-len =A0 | S | =A0seed-i= d (0, 2 or 16 octets) =A0|
>>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>> =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0 =A0. =A0 =A0 =A0 =A0 =A0 =A0 =A0buffered-mpl-packets (0 to= 8 octets) =A0 =A0 =A0 =A0 =A0 =A0 .
>>> =A0 =A0. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
>>>
>>>
>>> =A0w-min =A0 =A0 =A0 =A0 =A0 =A0 =A0 8-bit unsigned integer. = =A0Indicates the first
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sequence number ass= ociated with the first bit in
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0buffered-mpl-packet= s.
>>>
>>> =A0w-len =A0 =A0 =A0 =A0 =A0 =A0 =A0 6-bit unsigned integer. = =A0Indicates the size of
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the sliding window = and the number of valid bits
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in buffered-mpl-pac= kets. =A0The sliding window's
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0upper bound is the = sum of w-min and w-len.
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>>>9]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0S =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2-bit unsigned intege= r. =A0Identifies the length of
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seed-id. 0 indicate= s that the seed-id value is 0
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and not included in= the MPL Option. 1 indicates
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that the seed-id va= lue is a 16-bit unsigned
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0integer. 2 indicate= s that the seed-id value is a
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0128-bit unsigned in= teger. 3 is reserved.
>>>
>>> =A0seed-id =A0 =A0 =A0 =A0 =A0 =A0 Indicates the MPL seed asso= ciated with this
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sliding window.
>>>
>>> =A0buffered-mpl-packets =A0Variable-length bit vector. =A0Iden= tifies the
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sequence numbers of= MPL multicast packets that
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the MPL forwarder h= as buffered. =A0The sequence
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number is determine= d by w-min + i, where i is the
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0offset within buffe= red-mpl-packets.
>>>
>>> =A0The MPL Window does not have any octet alignment requiremen= t.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>10]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 5. =A0MPL Forwarder Behavior
>>>
>>> =A0An MPL forwarder implementation needs to manage sliding win= dows for
>>> =A0each active MPL seed. =A0The sliding window allows the MPL = forwarder to
>>> =A0determine what multicast packets to accept and what multica= st packets
>>> =A0are buffered. =A0An MPL forwarder must also manage MPL pack= et
>>> =A0transmissions.
>>>
>>> 5.1. =A0Multicast Packet Dissemination
>>>
>>> =A0MPL uses the Trickle algorithm to control packet transmissi= ons when
>>> =A0disseminating MPL multicast packets [RFC6206]. =A0MPL provi= des two
>>> =A0propagation mechanisms for disseminating MPL multicast pack= ets.
>>>
>>> =A01. =A0With proactive propagation, an MPL forwarder transmit= s buffered
>>> =A0 =A0 =A0MPL multicast packets using the Trickle algorithm. = =A0This method
>>> =A0 =A0 =A0is called proactive propagation since an MPL forwar= der actively
>>> =A0 =A0 =A0transmits MPL multicast packets without discovering= that a
>>> =A0 =A0 =A0neighboring MPL forwarder has yet to receive the me= ssage.
>>>
>>> =A02. =A0With reactive propagation, an MPL forwarder transmits= ICMPv6 MPL
>>> =A0 =A0 =A0messages using the Trickle algorithm. =A0An MPL for= warder only
>>> =A0 =A0 =A0transmits buffered MPL multicast packets upon disco= vering that
>>> =A0 =A0 =A0neighboring devices have not yet to receive the cor= responding MPL
>>> =A0 =A0 =A0multicast packets.
>>>
>>> =A0When receiving a new multicast packet, an MPL forwarder fir= st
>>> =A0utilizes proactive propagation to forward the MPL multicast= packet.
>>> =A0Proactive propagation reduces dissemination latency since i= t does not
>>> =A0require discovering that neighboring devices have not yet r= eceived
>>> =A0the MPL multicast packet. =A0MPL forwarders utilize proacti= ve
>>> =A0propagation for newly received MPL multicast packets since = they can
>>> =A0assume that some neighboring MPL forwarders have yet to rec= eive the
>>> =A0MPL multicast packet. =A0After a limited number of MPL mult= icast packet
>>> =A0transmissions, the MPL forwarder may terminate proactive pr= opagation
>>> =A0for the MPL multicast packet.
>>>
>>> =A0An MPL forwarder may optionally use reactive propagation to= continue
>>> =A0the dissemination process with lower communication overhead= . =A0With
>>> =A0reactive propagation, neighboring MPL forwarders use ICMPv6= MPL
>>> =A0messages to discover new MPL multicast messages that have n= ot yet
>>> =A0been received. =A0When discovering that a neighboring MPL f= orwarder has
>>> =A0not yet received a new MPL multicast packet, the MPL forwar= der
>>> =A0enables proactive propagation again.
>>>
>>> UH> There is not a lot of RFC2119 language in the above. Or= is that
>>> defined later? Is this above section more like an introduction= ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>11]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 5.1.1. =A0Trickle Parameters and Variables
>>>
>>> =A0As specified in RFC 6206 [RFC6206], a Trickle timer runs fo= r a
>>> =A0defined interval and has three configuration parameters: th= e minimum
>>> =A0interval size Imin, the maximum interval size Imax, and a r= edundancy
>>> =A0constant k.
>>>
>>> =A0MPL defines a fourth configuration parameter, TimerExpirati= ons, which
>>> =A0indicates the number of Trickle timer expiration events tha= t occur
>>> =A0before terminating the Trickle algorithm.
>>>
>>> =A0Each MPL forwarder maintains a separate Trickle parameter s= et for the
>>> =A0proactive and reactive propagation methods. =A0TimerExpirat= ions MUST be
>>> =A0greater than 0 for proactive propagation. =A0TimerExpiratio= ns MAY be
>>> =A0set to 0 for reactive propagation, which effectively disabl= es
>>> =A0reactive propagation.
>>>
>>> =A0As specified in RFC 6206 [RFC6206], a Trickle timer has thr= ee
>>> =A0variables: the current interval size I, a time within the c= urrent
>>> =A0interval t, and a counter c.
>>>
>>> UH> This sentence starts confusing, as it looks very simila= r to the
>>> first paragraph in this section. "a Trickle timer has thr= ee variables"
>>> How about using the same language as in RFC6206:
>>> "In addition to these three parameters, Trickle maintains= three
>>> =A0variables:
>>> =A0o =A0I, the current interval size,
>>> =A0o =A0t, a time within the current interval, and
>>> =A0o =A0c, a counter."
>>>
>>>
>>> =A0MPL defines a fourth variable, e, which counts the number o= f Trickle
>>> =A0timer expiration events since the Trickle timer was last re= set.
>>>
>>> 5.1.2. =A0Proactive Propagation
>>>
>>> =A0With proactive propagation, the MPL forwarder transmits buf= fered MPL
>>> =A0multicast packets using the Trickle algorithm. =A0Each buff= ered MPL
>>> =A0multicast packet that is proactively being disseminated wit= h
>>> =A0proactive propagation has an associated Trickle timer.
>>>
>>> UH> I think that somewhere the state requirements need to b= e
>>> mentioned. How does that affect scalability of the algorithm e= tc.
>>> Density is mentioned somewhere in the beginning, but not expla= ined how
>>> that would affect scalability and state requirements.
>>>
>>> =A0 Adhering to
>>> =A0Section 5 of RFC 6206 [RFC6206], this document defines the = following:
>>>
>>> =A0o =A0This document defines a "consistent" transmi= ssion for proactive
>>> =A0 =A0 propagation as receiving an MPL multicast packet that = has the same
>>> =A0 =A0 MPL seed identifier and sequence number as a buffered = MPL packet.
>>>
>>> =A0o =A0This document defines an "inconsistent" tran= smission for proactive
>>> =A0 =A0 propagation as receiving an MPL multicast packet that = has the same
>>> =A0 =A0 MPL seed identifier, the M flag set, and has a sequenc= e number
>>> =A0 =A0 less than the buffered MPL multicast packet's sequ= ence number.
>>>
>>> =A0o =A0This document does not define any external "event= s".
>>>
>>> =A0o =A0This document defines both MPL multicast packets and I= CMPv6 MPL
>>> =A0 =A0 multicast packets as Trickle messages. =A0These messag= es are defined
>>> =A0 =A0 in the sections below.
>>>
>>> UH> I don't see the term Trickle message used anywhere = else.
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>12]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0o =A0The actions outside the Trickle algorithm that the pro= tocol takes
>>> =A0 =A0 involve managing sliding window state, and is specifie= d in
>>> =A0 =A0 Section 5.2.
>>>
>>> 5.1.3. =A0Reactive Propagation
>>>
>>> =A0With reactive propagation, the MPL forwarder transmits ICMP= v6 MPL
>>> =A0messages using the Trickle algorithm. =A0A MPL forwarder ma= intains a
>>> =A0single Trickle timer for reactive propagation with each MPL= domain.
>>> =A0When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder doe= s not
>>> =A0execute the Trickle algorithm for reactive propagation and = reactive
>>> =A0propagation is disabled. =A0Adhering to Section 5 of RFC 62= 06
>>> =A0[RFC6206], this document defines the following:
>>>
>>> =A0o =A0This document defines a "consistent" transmi= ssion for reactive
>>> =A0 =A0 propagation as receiving an ICMPv6 MPL message that in= dicates
>>> =A0 =A0 neither the receiving nor transmitting node has new MP= L multicast
>>> =A0 =A0 packets to offer.
>>>
>>> =A0o =A0This document defines an "inconsistent" tran= smission for reactive
>>> =A0 =A0 propagation as receiving an ICMPv6 MPL message that in= dicates
>>> =A0 =A0 either the receiving or transmitting node has at least= one new MPL
>>> =A0 =A0 multicast packet to offer.
>>>
>>> =A0o =A0This document defines an "event" for reactiv= e propagation as
>>> =A0 =A0 updating any sliding window (i.e. changing the value o= f WindowMin,
>>> =A0 =A0 WindowMax, or the set of buffered MPL multicast packet= s) in
>>> =A0 =A0 response to receiving an MPL multicast packet.
>>>
>>> =A0o =A0This document defines both MPL multicast packets and I= CMPv6 MPL
>>> =A0 =A0 multicast packets as Trickle messages. =A0These messag= es are defined
>>> =A0 =A0 in the sections below.
>>>
>>> UH> I don't see the term "Trickle message" an= ywhere else =A0(other than
>>> in 5.1.2)
>>>
>>>
>>> =A0o =A0The actions outside the Trickle algorithm that the pro= tocol takes
>>> =A0 =A0 involve managing sliding window state, and is specifie= d in
>>> =A0 =A0 Section 5.2.
>>>
>>> 5.2. =A0Sliding Windows
>>>
>>> =A0Every MPL forwarder MUST maintain a sliding window of seque= nce
>>> =A0numbers for each MPL seed of recently received MPL packets.= =A0The
>>> =A0sliding window performs two functions:
>>>
>>> =A01. =A0Indicate what MPL multicast packets the MPL forwarder= should
>>> =A0 =A0 =A0accept.
>>>
>>> =A02. =A0Indicate what MPL multicast packets are buffered and = may be
>>> =A0 =A0 =A0transmitted to neighboring MPL forwarders.
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>13]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0Each sliding window logically consists of:
>>>
>>> =A01. =A0A lower-bound sequence number, WindowMin, that repres= ents the
>>> =A0 =A0 =A0sequence number of the oldest MPL multicast packet = the MPL
>>> =A0 =A0 =A0forwarder is willing to receive or has buffered. = =A0An MPL
>>> =A0 =A0 =A0forwarder MUST ignore any MPL multicast packet that= has sequence
>>> =A0 =A0 =A0value less than than WindowMin.
>>>
>>> =A02. =A0An upper-bound sequence value, WindowMax, that repres= ents the
>>> =A0 =A0 =A0sequence number of the next MPL multicast packet th= at the MPL
>>> =A0 =A0 =A0forwarder expects to receive. =A0An MPL forwarder M= UST accept any
>>> =A0 =A0 =A0MPL multicast packet that has sequence number great= er than or
>>> =A0 =A0 =A0equal to WindowMax.
>>>
>>> =A03. =A0A list of MPL multicast packets, BufferedPackets, buf= fered by the
>>> =A0 =A0 =A0MPL forwarder. =A0Each entry in BufferedPackets MUS= T have a
>>> =A0 =A0 =A0sequence number in the range [WindowMin, WindowMax)= .
>>>
>>> =A04. =A0A timer, HoldTimer, that indicates the minimum lifeti= me of the
>>> =A0 =A0 =A0sliding window. =A0The MPL forwarder MUST NOT free = a sliding window
>>> =A0 =A0 =A0before HoldTimer expires.
>>>
>>> =A0When receiving an MPL multicast packet, if no existing slid= ing window
>>> =A0exists for the MPL seed, the MPL forwarder MUST create a ne= w sliding
>>> =A0window before accepting the MPL multicast packet. =A0The MP= L forwarder
>>> =A0may reclaim memory resources by freeing a sliding window fo= r another
>>> =A0MPL seed if its HoldTimer has expired. =A0If, for any reaso= n, the MPL
>>> =A0forwarder cannot create a new sliding window, it MUST disca= rd the
>>> =A0packet.
>>>
>>> =A0If a sliding window exists for the MPL seed, the MPL forwar= der MUST
>>> =A0ignore the MPL multicast packet if the packet's sequenc= e number is
>>> =A0less than WindowMin or appears in BufferedPackets. =A0Other= wise, the
>>> =A0MPL forwarder MUST accept the packet and determine whether = or not to
>>> =A0forward the packet and/or pass the packet to the next highe= r layer.
>>>
>>> =A0When accepting an MPL multicast packet, the MPL forwarder M= UST update
>>> =A0the sliding window based on the packet's sequence numbe= r. =A0If the
>>> =A0sequence number is not less than WindowMax, the MPL forward= er MUST
>>> =A0set WindowMax to 1 greater than the packet's sequence n= umber. =A0If
>>> =A0WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL for= warder MUST
>>> =A0increment WindowMin such that WindowMax - WindowMin <=3D=
>>> =A0MPL_MAX_WINDOW_SIZE. =A0At the same time, the MPL forwarder= MUST free
>>> =A0any entries in BufferedPackets that have a sequence number = less than
>>> =A0WindowMin.
>>>
>>> =A0If the MPL forwarder has available memory resources, it MUS= T buffer
>>> =A0the MPL multicast packet for proactive propagation. =A0If n= ot enough
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>14]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0memory resources are available to buffer the packet, the MP= L
>>> =A0forwarder MUST increment WindowMin and free entries in
>>> =A0BufferedPackets that have a sequence number less than Windo= wMin until
>>> =A0enough memory resources are available. =A0Incrementing Wind= owMin will
>>> =A0ensure that the MPL forwarder does not accept previously re= ceived
>>> =A0packets.
>>>
>>> =A0An MPL forwarder MAY reclaim memory resources from sliding = windows
>>> =A0for other MPL seeds. =A0If a sliding window for another MPL= seed is
>>> =A0actively disseminating messages and has more than one entry= in its
>>> =A0BufferedPackets, the MPL forwarder may free entries for tha= t MPL seed
>>> =A0by incrementing WindowMin as described above.
>>>
>>> =A0If the MPL forwarder cannot free enough memory resources to= buffer
>>> =A0the MPL multicast packet, the MPL forwarder MUST set Window= Min to 1
>>> =A0greater than the packet's sequence number.
>>>
>>> =A0When memory resources are available, an MPL forwarder SHOUL= D buffer a
>>> =A0MPL multicast packet until the proactive propagation comple= tes (i.e.
>>> =A0the Trickle algorithm stops execution) and MAY buffer for l= onger.
>>> =A0After proactive propagation completes, the MPL forwarder ma= y advance
>>> =A0WindowMin to the packet's sequence number to reclaim me= mory
>>> =A0resources. =A0When the MPL forwarder no longer buffers any = packets, it
>>> =A0MAY set WindowMin equal to WindowMax. =A0When setting Windo= wMin equal
>>> =A0to WindowMax, the MPL forwarder MUST initialize HoldTimer t= o
>>> =A0WINDOW_HOLD_TIME and start HoldTimer. =A0After HoldTimer ex= pires, the
>>> =A0MPL forwarder MAY free the sliding window to reclaim memory=
>>> =A0resources.
>>>
>>> 5.3. =A0Transmission of MPL Multicast Packets
>>>
>>> =A0The MPL forwarder manages buffered MPL multicast packet tra= nsmissions
>>> =A0using the Trickle algorithm. =A0When adding a packet to
>>> =A0BufferedPackets, the MPL forwarder MUST create a Trickle ti= mer for
>>> =A0the packet and start execution of the Trickle algorithm. >>>
>>> =A0After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the= MPL
>>> =A0forwarder MUST stop executing the Trickle algorithm. =A0Whe= n a buffered
>>> =A0MPL multicast packet does not have an active Trickle timer,= the MPL
>>> =A0forwarder MAY free the buffered packet by advancing WindowM= in to 1
>>> =A0greater than the packet's sequence number.
>>>
>>> =A0Each interface that supports MPL is configured with exactly= one MPL
>>> =A0multicast scope. =A0The MPL multicast scope MUST be site-lo= cal or
>>> =A0smaller and defaults to link-local. =A0A scope larger than = link-local
>>> =A0MAY be used only when that scope corresponds exactly to the= MPL
>>> =A0domain.
>>>
>>> UH> Why is this written in a section called "Transmiss= ion of MPL
>>> Multicast Packets"? Seems more like an initial configurat= ion. Same for
>>> the below IPv6.. I would have expected that in a dedicated sec= tion
>>> about IPv6 tunneling
>>> UH> How would the router now that the scope corresponds exa= ctly to the
>>> MPL domain?
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>15]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0An MPL domain may therefore be composed of one or more MPL = multicast
>>> =A0scopes. =A0For example, the MPL domain may be composed of a= single MPL
>>> =A0multicast scope when using a site-local scope. =A0Alternati= vely, the
>>> =A0MPL domain may be composed of multiple MPL multicast scopes= when
>>> =A0using a link-local scope.
>>>
>>> UH> I am not quite sure how the scope works in this specifi= cation. Is
>>> that used somewhere when deciding whether to forward packets?<= br> >>>
>>> =A0IPv6-in-IPv6 encapsulation MUST be used when using MPL to f= orward an
>>> =A0original multicast packet whose source or destination addre= ss is
>>> =A0outside the MPL multicast scope.
>>>
>>> UH> The source address is a unicast address, right? How can= that be
>>> outside a multicast scope? How would you know?
>>>
>>> =A0 IPv6-in-IPv6 encapsulation is
>>> =A0necessary to support Path MTU discovery when the MPL forwar= der is not
>>> =A0the source of the original multicast packet. =A0IPv6-in-IPv= 6
>>> =A0encapsulation also allows an MPL forwarder to remove the MP= L Option
>>> =A0when forwarding the original multicast packet over a link t= hat does
>>> =A0not support MPL.
>>>
>>> UH> That should be specified more clearly. What does "= remove" mean? I
>>> suppose you mean decapsulate the inner IPv6 packet.
>>>
>>> =A0 The destination address scope for the outer IPv6
>>> =A0header MUST be the MPL multicast scope.
>>>
>>> UH> Again, which one? I thought there can be several scopes= ?
>>>
>>> =A0When an MPL domain is composed of multiple MPL multicast sc= opes (e.g.
>>> =A0when the MPL multicast scope is link-local), an MPL forward= er MUST
>>> =A0decapsulate and encapsulate the original multicast packet w= hen
>>> =A0crossing between different MPL multicast scopes.
>>>
>>> UH> When would you know when to cross a multicast scope? Do= you mean
>>> routing domain?
>>>
>>> =A0 In doing so, the
>>> =A0MPL forwarder MUST duplicate the MPL Option, unmodified, in= the new
>>> =A0outer IPv6 header.
>>>
>>> =A0The IPv6 destination address of the MPL multicast packet is= the all-
>>> =A0MPL-forwarders multicast address (TBD).
>>>
>>> UH> The TBD will be hard to spot by the RFC editor / IANA. = I suggest
>>> to define the variable and use the value only in the IANA sect= ion.
>>>
>>> =A0 The scope of the IPv6
>>> =A0destination address is set to the MPL multicast scope.
>>>
>>> UH> which one?
>>>
>>> 5.4. =A0Reception of MPL Multicast Packets
>>>
>>> =A0Upon receiving an MPL multicast packet, the MPL forwarder f= irst
>>> =A0determines whether or not to accept and buffer the MPL mult= icast
>>> =A0packet based on its MPL seed and sequence value, as specifi= ed in
>>> =A0Section 5.2.
>>>
>>> =A0If the MPL forwarder accepts the MPL multicast packet, the = MPL
>>> =A0forwarder determines whether or not to deliver the original= multicast
>>> =A0packet to the next higher layer.
>>>
>>> UH> How would it determine that?
>>>
>>> =A0 For example, if the MPL multicast
>>> =A0packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder r= emoves the
>>> =A0outer IPv6 header, which also removes MPL Option.
>>>
>>> UH> For example? What exactly needs to be done?
>>>
>>> 5.5. =A0Transmission of ICMPv6 MPL Messages
>>>
>>> =A0The MPL forwarder generates and transmits a new ICMPv6 MPL = message
>>> =A0whenever Trickle requests a transmission.
>>>
>>> UH> So for each data packet there would be a new ICMPv6 mes= sage?
>>> Wouldn't that create a lot of overhead?
>>>
>>> UH> To which address is the ICMP message sent? On which int= erface?
>>>
>>> =A0The MPL forwarder includes
>>> =A0an encoding of each sliding window in the ICMPv6 MPL messag= e.
>>>
>>> =A0Each sliding window is encoded using an MPL Window entry, d= efined in
>>> =A0Section 5.2. =A0The MPL forwarder sets the MPL Window field= s as
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>16]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0follows:
>>>
>>> =A0S =A0If the MPL seed identifier is 0, set S to 0. =A0If the= MPL seed
>>> =A0 =A0 identifier is within the range [1, 65535], set S to 2.= =A0Otherwise,
>>> =A0 =A0 set S to 3.
>>>
>>> =A0w-min =A0Set to the lower bound of the sliding window (i.e.=
>>> =A0 =A0 WindowMin).
>>>
>>> =A0w-len =A0Set to the length of the window (i.e. =A0WindowMax= - WindowMin).
>>>
>>> =A0seed-id =A0If S is non-zero, set to the MPL seed identifier= .
>>>
>>> =A0buffered-mpl-packets =A0Set each bit that represents a sequ= ence number
>>> =A0 =A0 of a packet in BufferedPackets to 1. =A0Set all other = bits to 0.
>>> =A0 =A0 The i'th bit in buffered-mpl-packets represents a = sequence number
>>> =A0 =A0 of w-min + i.
>>>
>>> 5.6. =A0Reception of ICMPv6 MPL Messages
>>>
>>> =A0An MPL forwarder processes each ICMPv6 MPL message that it = receives
>>> =A0to determine if it has any new MPL multicast packets to rec= eive or
>>> =A0offer.
>>>
>>> =A0An MPL forwarder determines if a new MPL multicast packet h= as not
>>> =A0been received from a neighboring node if any of the followi= ng
>>> =A0conditions hold true:
>>>
>>> =A01. =A0The ICMPv6 MPL message includes an MPL Window for an = MPL seed
>>> =A0 =A0 =A0that does not have a corresponding sliding window e= ntry on the
>>> =A0 =A0 =A0MPL forwarder.
>>>
>>> =A02. =A0The neighbor has a packet in its BufferedPackets that= has
>>> =A0 =A0 =A0sequence value greater than or equal to WindowMax (= i.e. w-min +
>>> =A0 =A0 =A0w-len >=3D WindowMax).
>>>
>>> =A03. =A0The neighbor has a packet in its BufferedPackets that= has
>>> =A0 =A0 =A0sequence number within range of the sliding window = but is not
>>> =A0 =A0 =A0included in BufferedPackets (i.e. the i'th bit = in buffered-mpl-
>>> =A0 =A0 =A0packets is set to 1, where the sequence number is w= -min + i).
>>>
>>> =A0When an MPL forwarder determines that it has not yet receiv= ed a new
>>> =A0MPL multicast packet buffered by a neighboring device, the = MPL
>>> =A0forwarder resets the Trickle timer associated with reactive=
>>> =A0propagation.
>>>
>>> =A0An MPL forwarder determines if an entry in BufferedPackets = has not
>>> =A0been received by a neighboring MPL forwarder if any of the = following
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>17]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> =A0conditions hold true:
>>>
>>> =A01. =A0The ICMPv6 MPL message does not include an MPL Window= for the
>>> =A0 =A0 =A0packet's MPL seed.
>>>
>>> =A02. =A0The packet's sequence number is greater than or e= qual to the
>>> =A0 =A0 =A0neighbor's WindowMax value (i.e. the packet'= ;s sequence number is
>>> =A0 =A0 =A0greater than or equal to w-min + w-len).
>>>
>>> =A03. =A0The packet's sequence number is within the range = of the
>>> =A0 =A0 =A0neighbor's sliding window [WindowMin, WindowMax= ), but not
>>> =A0 =A0 =A0included in the neighbor's BufferedPacket (i.e.= the packet's
>>> =A0 =A0 =A0sequence number is greater than or equal to w-min, = strictly less
>>> =A0 =A0 =A0than w-min + w-len, and the corresponding bit in bu= ffered-mpl-
>>> =A0 =A0 =A0packets is set to 0.
>>>
>>> =A0When an MPL forwarder determines that it has at least one b= uffered
>>> =A0MPL multicast packet that has not yet been received by a ne= ighbor,
>>> =A0the MPL forwarder resets the Trickle timer associated with = reactive
>>> =A0propagation. =A0Additionally, for each buffered MPL multica= st packet
>>> =A0that should be transferred, the MPL forwarder MUST reset th= e Trickle
>>> =A0timer and reset e to 0 for proactive propagation. =A0If the= Trickle
>>> =A0timer for proactive propagation has already stopped executi= on,
>>>
>>> UH> Which timer? I thought there is one timer per packet in= the
>>> proactive mode?
>>>
>>> =A0the
>>> =A0MPL forwarder MUST initialize a new Trickle timer and start= execution
>>> =A0of the Trickle algorithm.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>18]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 6. =A0MPL Parameters
>>>
>>> =A0An MPL forwarder maintains two sets of Trickle parameters f= or the
>>> =A0proactive and reactive methods. =A0The Trickle parameters a= re listed
>>> =A0below:
>>>
>>> =A0PROACTIVE_IMIN =A0The minimum Trickle timer interval, as de= fined in
>>> =A0 =A0 [RFC6206] for proactive propagation.
>>>
>>> =A0PROACTIVE_IMAX =A0The maximum Trickle timer interval, as de= fined in
>>> =A0 =A0 [RFC6206] for proactive propagation.
>>>
>>> =A0PROACTIVE_K =A0The redundancy constant, as defined in [RFC6= 206] for
>>> =A0 =A0 proactive propagation.
>>>
>>> =A0PROACTIVE_TIMER_EXPIRATIONS =A0The number of Trickle timer = expirations
>>> =A0 =A0 that occur before terminating the Trickle algorithm. = =A0MUST be set
>>> =A0 =A0 to a value greater than 0.
>>>
>>> =A0REACTIVE_IMIN =A0The minimum Trickle timer interval, as def= ined in
>>> =A0 =A0 [RFC6206] for reactive propagation.
>>>
>>> =A0REACTIVE_IMAX =A0The maximum Trickle timer interval, as def= ined in
>>> =A0 =A0 [RFC6206] for reactive propagation.
>>>
>>> =A0REACTIVE_K =A0The redundancy constant, as defined in [RFC62= 06] for
>>> =A0 =A0 reactive propagation.
>>>
>>> =A0REACTIVE_TIMER_EXPIRATIONS =A0The number of Trickle timer e= xpirations
>>> =A0 =A0 that occur before terminating the Trickle algorithm. = =A0MAY be set
>>> =A0 =A0 to 0, which disables reactive propagation.
>>>
>>> =A0WINDOW_HOLD_TIME =A0The minimum lifetime for sliding window= state.
>>>
>>>
>>> UH> I don't see any recommendations for these values. T= hat is
>>> typically requested in the IESG evaluation for standards track=
>>> documents (either default values and/or guideslines on the val= ues).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>19]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 7. =A0Acknowledgements
>>>
>>> =A0The authors would like to acknowledge the helpful comments = of Robert
>>> =A0Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Jos= eph Reddy,
>>> =A0Dario Tedeschi, and Peter van der Stok, which greatly impro= ved the
>>> =A0document.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>20]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 8. =A0IANA Considerations
>>>
>>> =A0The Trickle Multicast option requires an IPv6 Option Number= .
>>>
>>>
>>>
>>> =A0HEX =A0 =A0 =A0 =A0 act =A0chg =A0rest
>>> =A0--- =A0 =A0 =A0 =A0 --- =A0--- =A0-----
>>> =A0 =A0C =A0 =A0 =A0 =A0 =A001 =A0 =A00 =A0TBD
>>>
>>>
>>>
>>> =A0The first two bits indicate that the IPv6 node MUST discard= the
>>> =A0packet if it doesn't recognize the option type, and the= third bit
>>> =A0indicates that the Option Data MUST NOT change en-route. >>>
>>>
>>> UH> That does not look like a valid IANA section. RFC 5226 = give some
>>> good guidelines.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>21]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 9. =A0Security Considerations
>>>
>>> =A0TODO.
>>>
>>>
>>> UH> This document needs a security considerations section. = Refer to RFC
>>> 3552.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>22]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> 10. =A0References
>>>
>>> 10.1. =A0Normative References
>>>
>>> =A0[RFC1982] =A0Elz, R. and R. Bush, "Serial Number Arith= metic", RFC 1982,
>>> =A0 =A0 =A0 =A0 =A0 =A0 August 1996.
>>>
>>> =A0[RFC2119] =A0Bradner, S., "Key words for use in RFCs t= o Indicate
>>> =A0 =A0 =A0 =A0 =A0 =A0 Requirement Levels", BCP 14, RFC = 2119, March 1997.
>>>
>>> =A0[RFC2328] =A0Moy, J., "OSPF Version 2", STD 54, R= FC 2328, April 1998.
>>>
>>> =A0[RFC2460] =A0Deering, S. and R. Hinden, "Internet Prot= ocol, Version 6
>>> =A0 =A0 =A0 =A0 =A0 =A0 (IPv6) Specification", RFC 2460, = December 1998.
>>>
>>> =A0[RFC2473] =A0Conta, A. and S. Deering, "Generic Packet= Tunneling in
>>> =A0 =A0 =A0 =A0 =A0 =A0 IPv6 Specification", RFC 2473, De= cember 1998.
>>>
>>> =A0[RFC4443] =A0Conta, A., Deering, S., and M. Gupta, "In= ternet Control
>>> =A0 =A0 =A0 =A0 =A0 =A0 Message Protocol (ICMPv6) for the Inte= rnet Protocol
>>> =A0 =A0 =A0 =A0 =A0 =A0 Version 6 (IPv6) Specification", = RFC 4443, March 2006.
>>>
>>> =A0[RFC6206] =A0Levis, P., Clausen, T., Hui, J., Gnawali, O., = and J. Ko,
>>> =A0 =A0 =A0 =A0 =A0 =A0 "The Trickle Algorithm", RFC= 6206, March 2011.
>>>
>>> =A0[RFC6550] =A0Winter, T., Thubert, P., Brandt, A., Hui, J., = Kelsey, R.,
>>> =A0 =A0 =A0 =A0 =A0 =A0 Levis, P., Pister, K., Struik, R., Vas= seur, JP., and R.
>>> =A0 =A0 =A0 =A0 =A0 =A0 Alexander, "RPL: IPv6 Routing Pro= tocol for Low-Power and
>>> =A0 =A0 =A0 =A0 =A0 =A0 Lossy Networks", RFC 6550, March = 2012.
>>>
>>> 10.2. =A0Informative References
>>>
>>> =A0[I-D.ietf-roll-terminology]
>>> =A0 =A0 =A0 =A0 =A0 =A0 Vasseur, J., "Terminology in Low = power And Lossy
>>> =A0 =A0 =A0 =A0 =A0 =A0 Networks", draft-ietf-roll-termin= ology-06 (work in
>>> =A0 =A0 =A0 =A0 =A0 =A0 progress), September 2011.
>>>
>>> UH> That document is never actually cited. Also, it has not= been
>>> updated in over a year.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>23]
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October
>>>2012
>>>
>>>
>>> Authors' Addresses
>>>
>>> =A0Jonathan W. Hui
>>> =A0Cisco
>>> =A0170 West Tasman Drive
>>> =A0San Jose, California =A095134
>>> =A0USA
>>>
>>> =A0Phone: +408 424 1547
>>> =A0Email: jonhui@cisco.com=
>>>
>>>
>>> =A0Richard Kelsey
>>> =A0Silicon Labs
>>> =A025 Thomson Place
>>> =A0Boston, Massachusetts =A002210
>>> =A0USA
>>>
>>> =A0Phone: +617 951 1225
>>> =A0Email: richard= .kelsey@silabs.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 201= 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>>>24]
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>>



--20cf307abeb5fbd71404cd36b00b-- From d.sturek@att.net Mon Oct 29 11:25: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 4EB8821F8735 for ; Mon, 29 Oct 2012 11:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.944 X-Spam-Level: * X-Spam-Status: No, score=1.944 tagged_above=-999 required=5 tests=[AWL=-3.054, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=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 SOxGH8f3YfSY for ; Mon, 29 Oct 2012 11:24:54 -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 8371D21F86EE for ; Mon, 29 Oct 2012 11:24:53 -0700 (PDT) Received: from [66.94.237.196] by nm18.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 18:24:52 -0000 Received: from [68.142.198.200] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 18:24:52 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.mud.yahoo.com with NNFMP; 29 Oct 2012 18:24:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351535092; bh=kqpYiy8J3Pkb4KYANarcq0DLbS/jLPlF1+wElKGF4ic=; 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; b=6Uu0L+juAIUhsLRT38rQ8g84kgF6OwY2XcOY91O1h1DVOBqNN/qEP7U6x2CRV3TiU3OdlNlRVpZhuv1H+Hg33+NmruLb2VkY9iIW69tYIruvbwedUvKusUun4jmdrp0jeXuDC7KGdRORAqVG4f1ugaNryZwD6ez3D6q/9sf50Ds= X-Yahoo-Newman-Id: 495440.1528.bm@smtp101.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5JazUVEVM1maTKiD8JP_jlpQwt92CoGIlIKJERk1DpOLW37 .nEmEciu8wToEwL.V7Z8xz_XyY7XM_r1B3LziugOsV.yhTIZ0ihjMB2WIfZB HDfIl7SLbdVCqeiPJBwKxQ2KES0GRmfHQ2f.zPD8bj1QgKIJJDlgN9K.Js4. ICdHhtPOJizyiKww9ISOgemO1Wqth09HldvD_5fkmeDEVd4k.W9mcAS7IN5r Ow.0eQA60ixkYglW.8WPHdMsh4Njtzt8ffZJHHPE.TyNh_cQhf6O6dwA91s9 hhF5LMXH903PE_hsxeysDx0iU8CO_xDE3nOLP5S5FmX8pr9Dris6oubWfxaH tmmp8yKbgIJHbjyPmo_VxW31oYQIgo4qbqDqohUDJjQOUIxAQGWW7kmKQ_SS zAtjcDLsNemw8bfSq3raqt0V.r0YenLr_fXHgeOpzlZZCvIMm0iOrDnMYatH .XAzVldUZvCuSJH6sVA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 29 Oct 2012 11:24:52 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 29 Oct 2012 11:24:46 -0700 From: Don Sturek To: Ulrich Herberg Message-ID: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434354689_320905" Cc: "" , "roll@ietf.org WG" , Michael Richardson 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, 29 Oct 2012 18:25:03 -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_3434354689_320905 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Ulrich, A few notes=8A.. 1) We did the testing sometime ago and you are exactly correct on setting k=3Dinfinity. I believe that each node resends the message for each interval (so you do get many more transmissions that I said below) 2) We did not try just using jitter so don't have any results to share/compare What would have been interesting to test is using suppression but measuring to ensure that suppression never denied access to multicast messages missed by downstream devices (where the upstream device already saw the message an= d was using suppression). I think we may have taken the more "brute force" approach in ensuring all devices got their message. There is not much penalty to that in a network of 30 but with many more, that approach would not work. Don From: Ulrich Herberg Date: Monday, October 29, 2012 11:18 AM To: Don Sturek Cc: "JP Vasseur (jvasseur)" , "" , "roll@ietf.org WG" , Michael Richardson Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Hi Don, thanks for this information. See below On Mon, Oct 29, 2012 at 11:06 AM, Don Sturek wrote: > Hi Ulrich, >=20 > We did quite a lot of testing using 30 nodes (our messaging profile) and > using specific multicast parameter settings as follows: > 1. iMin =3D 128ms, iMax=3D128ms, k=3Dinfinity, TAct=3D3, TDwell=3D16s > 2. iMin =3D 128ms, iMax=3D128ms, k=3Dinfinity, TAct=3D1, TDwell=3D3s > 3. iMin =3D 512ms, iMax=3D512ms, k=3Dinfinity, TAct=3D1, TDwell=3D3s > 4. iMin =3D 512ms, iMax=3D512ms, k=3Dinfinity, TAct=3D3, TDwell=3D3s >=20 > First thing to note is we always set k=3Dinfinity since we could not > identify anything in our multicast streams to suppress (basically, we jus= t > wanted every device to see each multicast message at least once and > hopefully only once) My understanding is that if you set k to infinity, you would probably see each message many more times than just once. RFC6206 states: "In general, this approach [setting k to infinity] is highly dangerous an= d it is NOT RECOMMENDED. Disabling suppression means that every node will always send on every interval; this can lead to congestion in dense networks. This approach is especially dangerous if many nodes reset their intervals at the same time. In general, it is much more desirable to set k to a high value (e.g., 5 or 10) than infinity. Typical values for k are 1-5: these achieve a good balance between redundancy and low cost[Levis08 ]." I assume that with k =3D infinity, the performance would be much worse than classic flooding and you would have a lot of bandwidth consumption in the LLN. Did you observe that? =20 >=20 > Next, the main purpose of our multicast traffic was for resource discover= y > using mDNS so there is no driving requirement around low latency > applications (eg, other applications would be more sensitive to the iMin > and iMax settings than we were). I think this is important to point out in the draft. I agree that there are certain applications where delay is less important than others. For mDNS, whether it is delay-critical may also depend on the application that uses mDNS to discover the service. =20 >=20 > We ended up using parameter settings (4) above. >=20 > I think something like trickle multicast is a MUST for mesh routing > solutions like ROLL. The issue you get into using multicast is how the > messages are propagated. If every device that sees a multicast simply > forwards, then you end up with broadcast storms where nothing is heard. > The randomization of re-broadcast is essential. =20 But since you don't use suppression, the overhead is likely more substantia= l than in classic flooding. Using a decent jitter value in classic flooding, or more advanced flooding mechanisms such as MPR flooding would likely lead to much lower channel use. Have you compared to MPR flooding or classic flooding with jitter ? =20 >=20 > I think our results are being incorporated into the ROLL deployment > experience draft > (http://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment/). >=20 > By the way, someone noted the lack of a Security Considerations section. > We force Link Layer security on so did not plan any additional security > than that..... That may work in some deployments, but will not suffice for the draft to only rely on link-layer security, and to not even have a security considerations section. Best Ulrich >=20 > On 10/29/12 9:38 AM, "Ulrich Herberg" wrote: >=20 >> >Hi Don, >> > >> >thanks, that's good to know. To your knowledge, are there any public >> >results about delivery ratio of packets, overhead, delay, state >> >requirements and/or a comparison to other flooding mechanisms such as >> >classic flooding? >> > >> >Best >> >Ulrich >> > >> >On Oct 26, 2012, at 20:50, Don Sturek wrote: >> > >>> >> Hi Ulrich, >>> >> >>> >> For ZigBee IP, we are using the trickle multicast draft. We have 7 >>> >> platforms interoperating using the draft. >>> >> >>> >> Don >>> >> >>> >> >>> >> On 10/26/12 8:33 PM, "Ulrich Herberg" wrote: >>> >> >>>> >>> Hi, >>>> >>> >>>> >>> below is my review. >>>> >>> >>>> >>> My major comment is that the IANA section needs to be fixed and a >>>> >>> security considerations section needs to be written. Without that >>>> >>> section, the document should not go forward in my opinion. >>>> >>> Then I have multiple questions for clarity (see the detailed revie= w). >>>> >>> Also, as a standards track document, I think it should give some >>>> >>> guidelines about which values for the parameters to use, as well a= s >>>> >>> some indications about the state requirements of the protocol. >>>> >>> Are there any implementations and/or deployments of the protocol o= ut >>>> >>> there? >>>> >>> >>>> >>> Best regards >>>> >>> Ulrich >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> ROLL = J. >>>> >>>Hui >>>> >>> Internet-Draft >>>> >>>Cisco >>>> >>> Intended status: Standards Track R. >>>> >>>Kelsey >>>> >>> Expires: April 22, 2013 Silico= n >>>> >>>Labs >>>> >>> October 19, = 2012 >>>> >>> >>>> >>> >>>> >>> Multicast Protocol for Low power and Lossy Networks (MPL) >>>> >>> draft-ietf-roll-trickle-mcast-02 >>>> >>> >>>> >>> Abstract >>>> >>> >>>> >>> This document specifies the Multicast Protocol for Low power and >>>> >>> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >>>> >>> constrained networks. MPL avoids the need to construct or mainta= in >>>> >>> any multicast forwarding topology, disseminating messages to all = MPL >>>> >>> forwarders in an MPL domain. MPL uses the Trickle algorithm to d= rive >>>> >>> packet transmissions for both control and data-plane packets. >>>> >>> Specific Trickle parameter configurations allow MPL to trade betw= een >>>> >>> dissemination latency and transmission efficiency. >>>> >>> >>>> >>> Status of this Memo >>>> >>> >>>> >>> This Internet-Draft is submitted in full conformance with the >>>> >>> provisions of BCP 78 and BCP 79. >>>> >>> >>>> >>> Internet-Drafts are working documents of the Internet Engineering >>>> >>> Task Force (IETF). Note that other groups may also distribute >>>> >>> working documents as Internet-Drafts. The list of current Intern= et- >>>> >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>> >>> >>>> >>> Internet-Drafts are draft documents valid for a maximum of six mo= nths >>>> >>> and may be updated, replaced, or obsoleted by other documents at = any >>>> >>> time. It is inappropriate to use Internet-Drafts as reference >>>> >>> material or to cite them other than as "work in progress." >>>> >>> >>>> >>> This Internet-Draft will expire on April 22, 2013. >>>> >>> >>>> >>> Copyright Notice >>>> >>> >>>> >>> Copyright (c) 2012 IETF Trust and the persons identified as the >>>> >>> document authors. All rights reserved. >>>> >>> >>>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> >>> Provisions Relating to IETF Documents >>>> >>> (http://trustee.ietf.org/license-info) in effect on the date of >>>> >>> publication of this document. Please review these documents >>>> >>> carefully, as they describe your rights and restrictions with res= pect >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>1] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> to this document. Code Components extracted from this document m= ust >>>> >>> include Simplified BSD License text as described in Section 4.e o= f >>>> >>> the Trust Legal Provisions and are provided without warranty as >>>> >>> described in the Simplified BSD License. >>>> >>> >>>> >>> >>>> >>> Table of Contents >>>> >>> >>>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = . 3 >>>> >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . = . 4 >>>> >>> 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . = . 5 >>>> >>> 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . = . 7 >>>> >>> 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . = . 7 >>>> >>> 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . = . 8 >>>> >>> 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . = . 9 >>>> >>> 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . = . 11 >>>> >>> 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . = . 11 >>>> >>> 5.1.1. Trickle Parameters and Variables . . . . . . . . . . = . 12 >>>> >>> 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . = . 12 >>>> >>> 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . = . 13 >>>> >>> 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . = . 13 >>>> >>> 5.3. Transmission of MPL Multicast Packets . . . . . . . . . = . 15 >>>> >>> 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . = . 16 >>>> >>> 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . = . 16 >>>> >>> 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . = . 17 >>>> >>> 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . = . 19 >>>> >>> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = . 20 >>>> >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . = . 21 >>>> >>> 9. Security Considerations . . . . . . . . . . . . . . . . . . = . 22 >>>> >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = . 23 >>>> >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = . 23 >>>> >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = . 23 >>>> >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = . 24 >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>2] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 1. Introduction >>>> >>> >>>> >>> Low power and Lossy Networks typically operate with strict resour= ce >>>> >>> constraints in communication, computation, memory, and energy. S= uch >>>> >>> resource constraints may preclude the use of existing IPv6 multic= ast >>>> >>> topology and forwarding mechanisms. Traditional IP multicast >>>> >>> forwarding typically relies on topology maintenance mechanisms to >>>> >>> forward multicast messages to all subscribers of a multicast grou= p. >>>> >>> However, maintaining such topologies in LLNs is costly and may no= t be >>>> >>> feasible given the available resources. >>>> >>> >>>> >>> Memory constraints may limit devices to maintaining links/routes = to >>>> >>> one or a few neighbors. For this reason, the Routing Protocol fo= r >>>> >>> LLNs (RPL) >>>> >>> >>>> >>> UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power= and >>>> >>> Lossy Networks" >>>> >>> >>>> >>> specifies both storing and non-storing modes [RFC6550]. >>>> >>> The latter allows RPL routers to maintain only one or a few defau= lt >>>> >>> routes towards a LLN Border Router (LBR) >>>> >>> >>>> >>> UH> I did not find LBR in the terminology section. >>>> >>> >>>> >>> and use source routing to >>>> >>> forward packets away from the LBR. For the same reasons, a LLN >>>> >>> device may not be able to maintain a multicast forwarding topolog= y >>>> >>> when operating with limited memory. >>>> >>> >>>> >>> Furthermore, the dynamic properties of wireless networks can make= the >>>> >>> cost of maintaining a multicast forwarding topology prohibitively >>>> >>> expensive. In wireless environments, topology maintenance may >>>> >>> involve selecting a connected dominating set used to forward >>>> >>> multicast messages to all nodes in an administrative domain. >>>> >>> However, existing mechanisms often require two-hop topology >>>> >>> information and the cost of maintaining such information grows >>>> >>> polynomially with network density. >>>> >>> >>>> >>> This document specifies the Multicast Protocol for Low power and >>>> >>> Lossy Networks (MPL), which provides IPv6 multicast forwarding in >>>> >>> constrained networks. MPL avoids the need to construct or mainta= in >>>> >>> any multicast forwarding topology, disseminating multicast messag= es >>>> >>> to all MPL forwarders in an MPL domain. By using the Trickle >>>> >>> algorithm [RFC6206], MPL requires only small, constant state for = each >>>> >>> MPL device that initiates disseminations. The Trickle algorithm = also >>>> >>> allows MPL to be density-aware, allowing the communication rate t= o >>>> >>> scale logarithmically with density. >>>> >>> >>>> >>> UH> I am not sure I understand the last sentence. What does it mea= n? >>>> >>> How is that achieved? >>>> >>> >>>> >>> UH> By the way, since this is a standards track document, is there= any >>>> >>> deployment experience? Implementations? >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>3] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 2. Terminology >>>> >>> >>>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT= ", >>>> >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in t= his >>>> >>> document are to be interpreted as described in RFC 2119 [RFC2119]= . >>>> >>> >>>> >>> UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119 >>>> >>> >>>> >>> >>>> >>> The following terms are used throughout this document: >>>> >>> >>>> >>> MPL forwarder An IPv6 router that subscribes to the MPL >>>> >>> multicast group and participates in dissemina= ting >>>> >>> MPL multicast packets. >>>> >>> >>>> >>> MPL multicast scope The multicast scope that MPL uses when forwar= ding >>>> >>> MPL multicast packets. In other words, the >>>> >>> multicast scope of the IPv6 Destination Addre= ss >>>> >>> of an MPL multicast packet. >>>> >>> >>>> >>> UH> An RFC reference to "scope" could be helpful. >>>> >>> >>>> >>> MPL domain A connected set of MPL forwarders that define= the >>>> >>> extent of the MPL dissemination process. >>>> >>> >>>> >>> UH> What does connected mean? What if a the network is split in tw= o >>>> >>>parts? >>>> >>> >>>> >>> As a >>>> >>> form of flood, all MPL forwarders in an MPL >>>> >>> domain will receive MPL multicast packets. >>>> >>> >>>> >>> UH> Probably not *all* forwards will receive it (assuming packets = can >>>> >>> be lost) >>>> >>> >>>> >>> >>>> >>> The >>>> >>> MPL domain MUST be composed of at least one M= PL >>>> >>> multicast scope and MAY be composed of multip= le >>>> >>> MPL multicast scopes. >>>> >>> >>>> >>> UH> Why is that? Anyway, I am unsure whether one can say that a >>>> >>> routing domain "consists" of multicast scopes. If I understand tha= t >>>> >>> correctly, the multicast scope just determines how far a message >>>> >>> propagates. >>>> >>> >>>> >>> >>>> >>> MPL seed A MPL forwarder that begins the dissemination >>>> >>> process for an MPL multicast packet. The MPL >>>> >>> seed may be different than the source of the >>>> >>> original multicast packet. >>>> >>> >>>> >>> MPL seed identifier An identifier that uniquely identifies an MPL >>>> >>> forwarder within its MPL domain. >>>> >>> >>>> >>> UH> How is the uniqueness guaranteed? What kind of identifier is t= hat? >>>> >>> An IP address? I see it's defined later, but maybe it would be hel= pful >>>> >>> to mention it here, too. >>>> >>> >>>> >>> >>>> >>> original multicast packet An IPv6 multicast packet that is >>>> >>> disseminated using MPL. >>>> >>> >>>> >>> UH> That terminology sounds a bit confusing; I would have imagined >>>> >>> that the above description matches the following term "MPL multica= st >>>> >>> packet". What's the difference between an "original multicast pack= et" >>>> >>> and an "MPL multicast packet"? I assume the one is the inner packe= t >>>> >>> when using IPv6-in-IPv6 tunnels, the other one is the outer packet >>>> >>> with the options header. >>>> >>> >>>> >>> >>>> >>> MPL multicast packet An IPv6 multicast packet that contains an M= PL >>>> >>> Hop-by-Hop Option. When either source or >>>> >>> destinations are beyond the MPL multicast sco= pe, >>>> >>> >>>> >>> UH> Above it was said there may be multiple scopes in a domain. He= re >>>> >>> you talk about "the" scope. Which one? >>>> >>> >>>> >>> the MPL multicast packet is an IPv6-in-IPv6 >>>> >>> packet that contains an MPL Hop-by-Hop Option= in >>>> >>> the outer IPv6 header and encapsulates an >>>> >>> original multicast packet. When both source = and >>>> >>> destinations are within the MPL multicast sco= pe, >>>> >>> the MPL Hop-by-Hop Option may be included >>>> >>> directly within the original multicast packet= . >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>4] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 3. Overview >>>> >>> >>>> >>> MPL delivers IPv6 multicast packets by disseminating them to all = MPL >>>> >>> forwarders within an MPL domain. MPL dissemination is a form of >>>> >>> flood. An MPL forwarder may broadcast/multicast an MPL multicast >>>> >>> packet out of the same physical interface on which it was receive= d. >>>> >>> Using link-layer broadcast/multicast allows MPL to forward multic= ast >>>> >>> packets without explicitly identifying next-hop destinations. An= MPL >>>> >>> forwarder may also broadcast/multicast MPL multicast packets out >>>> >>> other interfaces to disseminate the message across different link= s. >>>> >>> MPL does not build or maintain a multicast forwarding topology to >>>> >>> forward multicast packets. >>>> >>> >>>> >>> Any MPL forwarder may initiate the dissemination process by servi= ng >>>> >>> as an MPL seed for an original multicast packet. The MPL seed ma= y or >>>> >>> may not be the same device as the source of the original multicas= t >>>> >>> packet. When the original multicast packet's source is outside t= he >>>> >>> LLN, >>>> >>> >>>> >>> UH> LLN or MPL domain? How can a router determine if an incoming >>>> >>> packet is inside our outside the MPL domain? >>>> >>> >>>> >>> the MPL seed may be the ingress router. Even if an original >>>> >>> multicast packet source is within the LLN, the source may first >>>> >>> forward the multicast packet to the MPL seed using IPv6-in-IPv6 >>>> >>> tunneling. >>>> >>> >>>> >>> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section wi= th a >>>> >>> title not related to "IPv6 tunneling". I suggest to make an own >>>> >>> section. >>>> >>> >>>> >>> Because MPL state requirements grows with the number of >>>> >>> active MPL seeds, >>>> >>> >>>> >>> UH> In section 1 it was written that the state is constant. Here y= ou >>>> >>> say it grows. Which one is it? >>>> >>> >>>> >>> limiting the number of MPL seeds reduces the amount >>>> >>> of state that MPL forwarders must maintain. >>>> >>> >>>> >>> Because MPL typically broadcasts/multicasts MPL packets out of th= e >>>> >>> same interface on which they were received, >>>> >>> >>>> >>> UH> Why typically? Doesn't that depend on the scenario that this >>>> >>> specification is used in? >>>> >>> >>>> >>> MPL forwarders are likely >>>> >>> to receive an MPL multicast packet more than once. >>>> >>> >>>> >>> UH> I am not sure if that is the only reason. Isn't the reason tha= t it >>>> >>> may be received from multiple neighbors? >>>> >>> >>>> >>> The MPL seed tags >>>> >>> each original multicast packet with an MPL seed identifier and a >>>> >>> sequence number. The sequence number provides a total ordering o= f >>>> >>> MPL multicast packets disseminated by the MPL seed. >>>> >>> >>>> >>> MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to incl= ude >>>> >>> MPL-specific information along with the original multicast packet= . >>>> >>> Each IPv6 multicast packet that MPL disseminates includes the MPL >>>> >>> Option. Because the original multicast packet's source and the M= PL >>>> >>> seed may not be the same device, the MPL Option may be added to t= he >>>> >>> original multicast packet en-route. To allow Path MTU discovery = to >>>> >>> work properly, MPL encapsulates the original multicast packet in >>>> >>> another IPv6 header that includes the MPL Option. >>>> >>> >>>> >>> Upon receiving a new MPL multicast packet for forwarding, the MPL >>>> >>> forwarder may proactively transmit the MPL multicast packet packe= t a >>>> >>> limited number of times and then falls back into an optional reac= tive >>>> >>> mode. In maintenance mode, an MPL forwarder buffers recently >>>> >>> received MPL multicast packets and advertises a summary of recent= ly >>>> >>> received MPL multicast packets from time to time, allowing >>>> >>> neighboring MPL forwarders to determine if they have any new >>>> >>> multicast packets to offer or receive. >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>5] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> MPL forwarders schedule their packet (control and data) transmiss= ions >>>> >>> using the Trickle algorithm [RFC6206]. Trickle's adaptive >>>> >>> transmission interval allows MPL to quickly disseminate messages = when >>>> >>> there are new MPL multicast packets, but reduces transmission >>>> >>> overhead as the dissemination process completes. Trickle's >>>> >>> suppression mechanism and transmission time selection allow MPL's >>>> >>> communication rate to scale logarithmically with density. >>>> >>> >>>> >>> UH> I think the whole introduction is not very easy to read. There= is >>>> >>> a lot of text about some details (IPv6-in-IPv6 tunnels, multiple >>>> >>> interfaces), but the essential mechanism is hard to identify from = the >>>> >>> text. Also, there is nothing mentioned about what kind of state is >>>> >>> required to be stored on each router (which information sets etc). >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>6] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 4. Message Formats >>>> >>> >>>> >>> 4.1. MPL Option >>>> >>> >>>> >>> The MPL Option is carried in an IPv6 Hop-by-Hop Options header, >>>> >>> >>>> >>> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options >>>> >>>header" >>>> >>> >>>> >>> UH> More importantly, RFC6564 specifies: >>>> >>> >>>> >>> New options for the existing Hop-by-Hop Header SHOULD NOT be >>>> >>> created or specified unless no alternative solution is feasibl= e. >>>> >>> Any proposal to create a new option for the existing Hop-by-Ho= p >>>> >>> Header MUST include a detailed explanation of why the hop-by-h= op >>>> >>> behavior is absolutely essential in the document proposing the= new >>>> >>> option with hop-by-hop behavior. >>>> >>> >>>> >>> UH> I did not see such an explanation. >>>> >>> >>>> >>> >>>> >>> immediately following the IPv6 header. The MPL Option has the >>>> >>> following format: >>>> >>> >>>> >>> 0 1 2 3 >>>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> | Option Type | Opt Data Len= | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> | S |M| rsv | sequence | seed-id (optional) = | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> >>>> >>> UH> It could help to mention that this is formatted in network byt= e >>>> >>>order >>>> >>> >>>> >>> Option Type XX (to be confirmed by IANA). >>>> >>> >>>> >>> Opt Data Len Length of the Option Data field in octets. M= UST >>>> >>> be set to either 2 or 4. >>>> >>> >>>> >>> UH> 2 or 4 depending on what? >>>> >>> >>>> >>> S 2-bit unsigned integer. Identifies the lengt= h of >>>> >>> seed-id. 0 indicates that the seed-id is 0 an= d >>>> >>> not included in the MPL Option. 1 indicates t= hat >>>> >>> the seed-id is a 16-bit unsigned integer. 2 >>>> >>> indicates that the seed-id is a 64-bit unsign= ed >>>> >>> integer. 3 indicates that the seed-id is a 12= 8- >>>> >>> bit unsigned integer. >>>> >>> >>>> >>> M 1-bit flag. 0 indicates that the value in >>>> >>> sequence is not the greatest sequence number = that >>>> >>> was received from the MPL seed. >>>> >>> >>>> >>> rsv 5-bit reserved field. MUST be set to zero an= d >>>> >>> incoming MPL multicast packets in which they = are >>>> >>> not zero MUST be dropped. >>>> >>> >>>> >>> sequence 8-bit unsigned integer. Identifies relative >>>> >>> ordering of MPL multicast packets from the so= urce >>>> >>> identified by seed-id. >>>> >>> >>>> >>> seed-id Uniquely identifies the MPL seed that initiat= ed >>>> >>> dissemination of the MPL multicast packet. T= he >>>> >>> size of seed-id is indicated by the S field. >>>> >>> >>>> >>> The Option Data of the Trickle Multicast option MUST NOT change a= s >>>> >>> the MPL multicast packet is forwarded. Nodes that do not underst= and >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>7] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> the Trickle Multicast option MUST discard the packet. Thus, >>>> >>> according to [RFC2460] the three high order bits of the Option Ty= pe >>>> >>> must be set to '010'. The Option Data length is variable. >>>> >>> >>>> >>> The seed-id uniquely identifies an MPL seed within the MPL domain= . >>>> >>> When seed-id is 128 bits (S=3D3), the MPL seed MAY use an IPv6 addr= ess >>>> >>> assigned to one of its interfaces that is unique within the MPL >>>> >>> domain. Managing MPL seed identifiers is not within scope of thi= s >>>> >>> document. >>>> >>> >>>> >>> The sequence field establishes a total ordering of MPL multicast >>>> >>> packets from the same MPL seed. The MPL seed MUST increment the >>>> >>> sequence field's value on each new MPL multicast packet that it >>>> >>> disseminates. Implementations MUST follow the Serial Number >>>> >>> Arithmetic as defined in [RFC1982] when incrementing a sequence v= alue >>>> >>> or comparing two sequence values. >>>> >>> >>>> >>> Future updates to this specification may define additional fields >>>> >>> following the seed-id field. >>>> >>> >>>> >>> 4.2. ICMPv6 MPL Message >>>> >>> >>>> >>> The MPL forwarder uses ICMPv6 MPL messages to advertise informati= on >>>> >>> about recently received MPL multicast packets. The ICMPv6 MPL >>>> >>> message has the following format: >>>> >>> >>>> >>> 0 1 2 3 >>>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> | Type | Code | Checksum = | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> | = | >>>> >>> . MPL Window[1..n] = . >>>> >>> . = . >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> >>>> >>> >>>> >>> IP Fields: >>>> >>> >>>> >>> Source Address A link-local address assigned to the sending >>>> >>> interface. >>>> >>> >>>> >>> Destination Address The link-local all-nodes MPL forwarders multi= cast >>>> >>> address (FF02::TBD). >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>8] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> Hop Limit 255 >>>> >>> >>>> >>> ICMPv6 Fields: >>>> >>> >>>> >>> Type XX (to be confirmed by IANA). >>>> >>> >>>> >>> Code 0 >>>> >>> >>>> >>> Checksum The ICMP checksum. See [RFC4443]. >>>> >>> >>>> >>> MPL Window[1..n] List of one or more MPL Windows (defined in >>>> >>> Section 4.2.1). >>>> >>> >>>> >>> An MPL forwarder transmits an ICMPv6 MPL message to advertise >>>> >>> information about buffered MPL multicast packets. More explicitl= y, >>>> >>> the ICMPv6 MPL message encodes the sliding window state (describe= d in >>>> >>> Section 5.2) that the MPL forwarder maintains for each MPL seed. = The >>>> >>> advertisement serves to indicate to neighboring MPL forwarders >>>> >>> regarding newer messages that it may send or the neighboring MPL >>>> >>> forwarders have yet to receive. >>>> >>> >>>> >>> 4.2.1. MPL Window >>>> >>> >>>> >>> An MPL Window encodes the sliding window state (described in >>>> >>> Section 5.2 that the MPL forwarder maintains for an MPL seed. >>>> >>> >>>> >>> UH> missing ")" >>>> >>> >>>> >>> Each >>>> >>> MPL Window has the following format: >>>> >>> >>>> >>> 0 1 2 3 >>>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> | w-min | w-len | S | seed-id (0, 2 or 16 octets) = | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> | = | >>>> >>> . buffered-mpl-packets (0 to 8 octets) = . >>>> >>> . = . >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+ >>>> >>> >>>> >>> >>>> >>> w-min 8-bit unsigned integer. Indicates the first >>>> >>> sequence number associated with the first bit= in >>>> >>> buffered-mpl-packets. >>>> >>> >>>> >>> w-len 6-bit unsigned integer. Indicates the size o= f >>>> >>> the sliding window and the number of valid bi= ts >>>> >>> in buffered-mpl-packets. The sliding window'= s >>>> >>> upper bound is the sum of w-min and w-len. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [P= age >>>> >>>9] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> S 2-bit unsigned integer. Identifies the lengt= h of >>>> >>> seed-id. 0 indicates that the seed-id value i= s 0 >>>> >>> and not included in the MPL Option. 1 indicat= es >>>> >>> that the seed-id value is a 16-bit unsigned >>>> >>> integer. 2 indicates that the seed-id value i= s a >>>> >>> 128-bit unsigned integer. 3 is reserved. >>>> >>> >>>> >>> seed-id Indicates the MPL seed associated with this >>>> >>> sliding window. >>>> >>> >>>> >>> buffered-mpl-packets Variable-length bit vector. Identifies the >>>> >>> sequence numbers of MPL multicast packets tha= t >>>> >>> the MPL forwarder has buffered. The sequence >>>> >>> number is determined by w-min + i, where i is= the >>>> >>> offset within buffered-mpl-packets. >>>> >>> >>>> >>> The MPL Window does not have any octet alignment requirement. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>10] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 5. MPL Forwarder Behavior >>>> >>> >>>> >>> An MPL forwarder implementation needs to manage sliding windows f= or >>>> >>> each active MPL seed. The sliding window allows the MPL forwarde= r to >>>> >>> determine what multicast packets to accept and what multicast pac= kets >>>> >>> are buffered. An MPL forwarder must also manage MPL packet >>>> >>> transmissions. >>>> >>> >>>> >>> 5.1. Multicast Packet Dissemination >>>> >>> >>>> >>> MPL uses the Trickle algorithm to control packet transmissions wh= en >>>> >>> disseminating MPL multicast packets [RFC6206]. MPL provides two >>>> >>> propagation mechanisms for disseminating MPL multicast packets. >>>> >>> >>>> >>> 1. With proactive propagation, an MPL forwarder transmits buffer= ed >>>> >>> MPL multicast packets using the Trickle algorithm. This meth= od >>>> >>> is called proactive propagation since an MPL forwarder active= ly >>>> >>> transmits MPL multicast packets without discovering that a >>>> >>> neighboring MPL forwarder has yet to receive the message. >>>> >>> >>>> >>> 2. With reactive propagation, an MPL forwarder transmits ICMPv6 = MPL >>>> >>> messages using the Trickle algorithm. An MPL forwarder only >>>> >>> transmits buffered MPL multicast packets upon discovering tha= t >>>> >>> neighboring devices have not yet to receive the corresponding= MPL >>>> >>> multicast packets. >>>> >>> >>>> >>> When receiving a new multicast packet, an MPL forwarder first >>>> >>> utilizes proactive propagation to forward the MPL multicast packe= t. >>>> >>> Proactive propagation reduces dissemination latency since it does= not >>>> >>> require discovering that neighboring devices have not yet receive= d >>>> >>> the MPL multicast packet. MPL forwarders utilize proactive >>>> >>> propagation for newly received MPL multicast packets since they c= an >>>> >>> assume that some neighboring MPL forwarders have yet to receive t= he >>>> >>> MPL multicast packet. After a limited number of MPL multicast pa= cket >>>> >>> transmissions, the MPL forwarder may terminate proactive propagat= ion >>>> >>> for the MPL multicast packet. >>>> >>> >>>> >>> An MPL forwarder may optionally use reactive propagation to conti= nue >>>> >>> the dissemination process with lower communication overhead. Wit= h >>>> >>> reactive propagation, neighboring MPL forwarders use ICMPv6 MPL >>>> >>> messages to discover new MPL multicast messages that have not yet >>>> >>> been received. When discovering that a neighboring MPL forwarder= has >>>> >>> not yet received a new MPL multicast packet, the MPL forwarder >>>> >>> enables proactive propagation again. >>>> >>> >>>> >>> UH> There is not a lot of RFC2119 language in the above. Or is tha= t >>>> >>> defined later? Is this above section more like an introduction? >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>11] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 5.1.1. Trickle Parameters and Variables >>>> >>> >>>> >>> As specified in RFC 6206 [RFC6206], a Trickle timer runs for a >>>> >>> defined interval and has three configuration parameters: the mini= mum >>>> >>> interval size Imin, the maximum interval size Imax, and a redunda= ncy >>>> >>> constant k. >>>> >>> >>>> >>> MPL defines a fourth configuration parameter, TimerExpirations, w= hich >>>> >>> indicates the number of Trickle timer expiration events that occu= r >>>> >>> before terminating the Trickle algorithm. >>>> >>> >>>> >>> Each MPL forwarder maintains a separate Trickle parameter set for= the >>>> >>> proactive and reactive propagation methods. TimerExpirations MUS= T be >>>> >>> greater than 0 for proactive propagation. TimerExpirations MAY b= e >>>> >>> set to 0 for reactive propagation, which effectively disables >>>> >>> reactive propagation. >>>> >>> >>>> >>> As specified in RFC 6206 [RFC6206], a Trickle timer has three >>>> >>> variables: the current interval size I, a time within the current >>>> >>> interval t, and a counter c. >>>> >>> >>>> >>> UH> This sentence starts confusing, as it looks very similar to th= e >>>> >>> first paragraph in this section. "a Trickle timer has three variab= les" >>>> >>> How about using the same language as in RFC6206: >>>> >>> "In addition to these three parameters, Trickle maintains three >>>> >>> variables: >>>> >>> o I, the current interval size, >>>> >>> o t, a time within the current interval, and >>>> >>> o c, a counter." >>>> >>> >>>> >>> >>>> >>> MPL defines a fourth variable, e, which counts the number of Tric= kle >>>> >>> timer expiration events since the Trickle timer was last reset. >>>> >>> >>>> >>> 5.1.2. Proactive Propagation >>>> >>> >>>> >>> With proactive propagation, the MPL forwarder transmits buffered = MPL >>>> >>> multicast packets using the Trickle algorithm. Each buffered MPL >>>> >>> multicast packet that is proactively being disseminated with >>>> >>> proactive propagation has an associated Trickle timer. >>>> >>> >>>> >>> UH> I think that somewhere the state requirements need to be >>>> >>> mentioned. How does that affect scalability of the algorithm etc. >>>> >>> Density is mentioned somewhere in the beginning, but not explained= how >>>> >>> that would affect scalability and state requirements. >>>> >>> >>>> >>> Adhering to >>>> >>> Section 5 of RFC 6206 [RFC6206], this document defines the follow= ing: >>>> >>> >>>> >>> o This document defines a "consistent" transmission for proactiv= e >>>> >>> propagation as receiving an MPL multicast packet that has the = same >>>> >>> MPL seed identifier and sequence number as a buffered MPL pack= et. >>>> >>> >>>> >>> o This document defines an "inconsistent" transmission for proac= tive >>>> >>> propagation as receiving an MPL multicast packet that has the = same >>>> >>> MPL seed identifier, the M flag set, and has a sequence number >>>> >>> less than the buffered MPL multicast packet's sequence number. >>>> >>> >>>> >>> o This document does not define any external "events". >>>> >>> >>>> >>> o This document defines both MPL multicast packets and ICMPv6 MP= L >>>> >>> multicast packets as Trickle messages. These messages are def= ined >>>> >>> in the sections below. >>>> >>> >>>> >>> UH> I don't see the term Trickle message used anywhere else. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>12] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> o The actions outside the Trickle algorithm that the protocol ta= kes >>>> >>> involve managing sliding window state, and is specified in >>>> >>> Section 5.2. >>>> >>> >>>> >>> 5.1.3. Reactive Propagation >>>> >>> >>>> >>> With reactive propagation, the MPL forwarder transmits ICMPv6 MPL >>>> >>> messages using the Trickle algorithm. A MPL forwarder maintains = a >>>> >>> single Trickle timer for reactive propagation with each MPL domai= n. >>>> >>> When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not >>>> >>> execute the Trickle algorithm for reactive propagation and reacti= ve >>>> >>> propagation is disabled. Adhering to Section 5 of RFC 6206 >>>> >>> [RFC6206], this document defines the following: >>>> >>> >>>> >>> o This document defines a "consistent" transmission for reactive >>>> >>> propagation as receiving an ICMPv6 MPL message that indicates >>>> >>> neither the receiving nor transmitting node has new MPL multic= ast >>>> >>> packets to offer. >>>> >>> >>>> >>> o This document defines an "inconsistent" transmission for react= ive >>>> >>> propagation as receiving an ICMPv6 MPL message that indicates >>>> >>> either the receiving or transmitting node has at least one new= MPL >>>> >>> multicast packet to offer. >>>> >>> >>>> >>> o This document defines an "event" for reactive propagation as >>>> >>> updating any sliding window (i.e. changing the value of Window= Min, >>>> >>> WindowMax, or the set of buffered MPL multicast packets) in >>>> >>> response to receiving an MPL multicast packet. >>>> >>> >>>> >>> o This document defines both MPL multicast packets and ICMPv6 MP= L >>>> >>> multicast packets as Trickle messages. These messages are def= ined >>>> >>> in the sections below. >>>> >>> >>>> >>> UH> I don't see the term "Trickle message" anywhere else (other t= han >>>> >>> in 5.1.2) >>>> >>> >>>> >>> >>>> >>> o The actions outside the Trickle algorithm that the protocol ta= kes >>>> >>> involve managing sliding window state, and is specified in >>>> >>> Section 5.2. >>>> >>> >>>> >>> 5.2. Sliding Windows >>>> >>> >>>> >>> Every MPL forwarder MUST maintain a sliding window of sequence >>>> >>> numbers for each MPL seed of recently received MPL packets. The >>>> >>> sliding window performs two functions: >>>> >>> >>>> >>> 1. Indicate what MPL multicast packets the MPL forwarder should >>>> >>> accept. >>>> >>> >>>> >>> 2. Indicate what MPL multicast packets are buffered and may be >>>> >>> transmitted to neighboring MPL forwarders. >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>13] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> Each sliding window logically consists of: >>>> >>> >>>> >>> 1. A lower-bound sequence number, WindowMin, that represents the >>>> >>> sequence number of the oldest MPL multicast packet the MPL >>>> >>> forwarder is willing to receive or has buffered. An MPL >>>> >>> forwarder MUST ignore any MPL multicast packet that has seque= nce >>>> >>> value less than than WindowMin. >>>> >>> >>>> >>> 2. An upper-bound sequence value, WindowMax, that represents the >>>> >>> sequence number of the next MPL multicast packet that the MPL >>>> >>> forwarder expects to receive. An MPL forwarder MUST accept a= ny >>>> >>> MPL multicast packet that has sequence number greater than or >>>> >>> equal to WindowMax. >>>> >>> >>>> >>> 3. A list of MPL multicast packets, BufferedPackets, buffered by= the >>>> >>> MPL forwarder. Each entry in BufferedPackets MUST have a >>>> >>> sequence number in the range [WindowMin, WindowMax). >>>> >>> >>>> >>> 4. A timer, HoldTimer, that indicates the minimum lifetime of th= e >>>> >>> sliding window. The MPL forwarder MUST NOT free a sliding wi= ndow >>>> >>> before HoldTimer expires. >>>> >>> >>>> >>> When receiving an MPL multicast packet, if no existing sliding wi= ndow >>>> >>> exists for the MPL seed, the MPL forwarder MUST create a new slid= ing >>>> >>> window before accepting the MPL multicast packet. The MPL forwar= der >>>> >>> may reclaim memory resources by freeing a sliding window for anot= her >>>> >>> MPL seed if its HoldTimer has expired. If, for any reason, the M= PL >>>> >>> forwarder cannot create a new sliding window, it MUST discard the >>>> >>> packet. >>>> >>> >>>> >>> If a sliding window exists for the MPL seed, the MPL forwarder MU= ST >>>> >>> ignore the MPL multicast packet if the packet's sequence number i= s >>>> >>> less than WindowMin or appears in BufferedPackets. Otherwise, th= e >>>> >>> MPL forwarder MUST accept the packet and determine whether or not= to >>>> >>> forward the packet and/or pass the packet to the next higher laye= r. >>>> >>> >>>> >>> When accepting an MPL multicast packet, the MPL forwarder MUST up= date >>>> >>> the sliding window based on the packet's sequence number. If the >>>> >>> sequence number is not less than WindowMax, the MPL forwarder MUS= T >>>> >>> set WindowMax to 1 greater than the packet's sequence number. If >>>> >>> WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MU= ST >>>> >>> increment WindowMin such that WindowMax - WindowMin <=3D >>>> >>> MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST fr= ee >>>> >>> any entries in BufferedPackets that have a sequence number less t= han >>>> >>> WindowMin. >>>> >>> >>>> >>> If the MPL forwarder has available memory resources, it MUST buff= er >>>> >>> the MPL multicast packet for proactive propagation. If not enoug= h >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>14] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> memory resources are available to buffer the packet, the MPL >>>> >>> forwarder MUST increment WindowMin and free entries in >>>> >>> BufferedPackets that have a sequence number less than WindowMin u= ntil >>>> >>> enough memory resources are available. Incrementing WindowMin wi= ll >>>> >>> ensure that the MPL forwarder does not accept previously received >>>> >>> packets. >>>> >>> >>>> >>> An MPL forwarder MAY reclaim memory resources from sliding window= s >>>> >>> for other MPL seeds. If a sliding window for another MPL seed is >>>> >>> actively disseminating messages and has more than one entry in it= s >>>> >>> BufferedPackets, the MPL forwarder may free entries for that MPL = seed >>>> >>> by incrementing WindowMin as described above. >>>> >>> >>>> >>> If the MPL forwarder cannot free enough memory resources to buffe= r >>>> >>> the MPL multicast packet, the MPL forwarder MUST set WindowMin to= 1 >>>> >>> greater than the packet's sequence number. >>>> >>> >>>> >>> When memory resources are available, an MPL forwarder SHOULD buff= er a >>>> >>> MPL multicast packet until the proactive propagation completes (i= .e. >>>> >>> the Trickle algorithm stops execution) and MAY buffer for longer. >>>> >>> After proactive propagation completes, the MPL forwarder may adva= nce >>>> >>> WindowMin to the packet's sequence number to reclaim memory >>>> >>> resources. When the MPL forwarder no longer buffers any packets,= it >>>> >>> MAY set WindowMin equal to WindowMax. When setting WindowMin equ= al >>>> >>> to WindowMax, the MPL forwarder MUST initialize HoldTimer to >>>> >>> WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, t= he >>>> >>> MPL forwarder MAY free the sliding window to reclaim memory >>>> >>> resources. >>>> >>> >>>> >>> 5.3. Transmission of MPL Multicast Packets >>>> >>> >>>> >>> The MPL forwarder manages buffered MPL multicast packet transmiss= ions >>>> >>> using the Trickle algorithm. When adding a packet to >>>> >>> BufferedPackets, the MPL forwarder MUST create a Trickle timer fo= r >>>> >>> the packet and start execution of the Trickle algorithm. >>>> >>> >>>> >>> After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL >>>> >>> forwarder MUST stop executing the Trickle algorithm. When a buff= ered >>>> >>> MPL multicast packet does not have an active Trickle timer, the M= PL >>>> >>> forwarder MAY free the buffered packet by advancing WindowMin to = 1 >>>> >>> greater than the packet's sequence number. >>>> >>> >>>> >>> Each interface that supports MPL is configured with exactly one M= PL >>>> >>> multicast scope. The MPL multicast scope MUST be site-local or >>>> >>> smaller and defaults to link-local. A scope larger than link-loc= al >>>> >>> MAY be used only when that scope corresponds exactly to the MPL >>>> >>> domain. >>>> >>> >>>> >>> UH> Why is this written in a section called "Transmission of MPL >>>> >>> Multicast Packets"? Seems more like an initial configuration. Same= for >>>> >>> the below IPv6.. I would have expected that in a dedicated section >>>> >>> about IPv6 tunneling >>>> >>> UH> How would the router now that the scope corresponds exactly to= the >>>> >>> MPL domain? >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>15] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> An MPL domain may therefore be composed of one or more MPL multic= ast >>>> >>> scopes. For example, the MPL domain may be composed of a single = MPL >>>> >>> multicast scope when using a site-local scope. Alternatively, th= e >>>> >>> MPL domain may be composed of multiple MPL multicast scopes when >>>> >>> using a link-local scope. >>>> >>> >>>> >>> UH> I am not quite sure how the scope works in this specification.= Is >>>> >>> that used somewhere when deciding whether to forward packets? >>>> >>> >>>> >>> IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward= an >>>> >>> original multicast packet whose source or destination address is >>>> >>> outside the MPL multicast scope. >>>> >>> >>>> >>> UH> The source address is a unicast address, right? How can that b= e >>>> >>> outside a multicast scope? How would you know? >>>> >>> >>>> >>> IPv6-in-IPv6 encapsulation is >>>> >>> necessary to support Path MTU discovery when the MPL forwarder is= not >>>> >>> the source of the original multicast packet. IPv6-in-IPv6 >>>> >>> encapsulation also allows an MPL forwarder to remove the MPL Opti= on >>>> >>> when forwarding the original multicast packet over a link that do= es >>>> >>> not support MPL. >>>> >>> >>>> >>> UH> That should be specified more clearly. What does "remove" mean= ? I >>>> >>> suppose you mean decapsulate the inner IPv6 packet. >>>> >>> >>>> >>> The destination address scope for the outer IPv6 >>>> >>> header MUST be the MPL multicast scope. >>>> >>> >>>> >>> UH> Again, which one? I thought there can be several scopes? >>>> >>> >>>> >>> When an MPL domain is composed of multiple MPL multicast scopes (= e.g. >>>> >>> when the MPL multicast scope is link-local), an MPL forwarder MUS= T >>>> >>> decapsulate and encapsulate the original multicast packet when >>>> >>> crossing between different MPL multicast scopes. >>>> >>> >>>> >>> UH> When would you know when to cross a multicast scope? Do you me= an >>>> >>> routing domain? >>>> >>> >>>> >>> In doing so, the >>>> >>> MPL forwarder MUST duplicate the MPL Option, unmodified, in the n= ew >>>> >>> outer IPv6 header. >>>> >>> >>>> >>> The IPv6 destination address of the MPL multicast packet is the a= ll- >>>> >>> MPL-forwarders multicast address (TBD). >>>> >>> >>>> >>> UH> The TBD will be hard to spot by the RFC editor / IANA. I sugge= st >>>> >>> to define the variable and use the value only in the IANA section. >>>> >>> >>>> >>> The scope of the IPv6 >>>> >>> destination address is set to the MPL multicast scope. >>>> >>> >>>> >>> UH> which one? >>>> >>> >>>> >>> 5.4. Reception of MPL Multicast Packets >>>> >>> >>>> >>> Upon receiving an MPL multicast packet, the MPL forwarder first >>>> >>> determines whether or not to accept and buffer the MPL multicast >>>> >>> packet based on its MPL seed and sequence value, as specified in >>>> >>> Section 5.2. >>>> >>> >>>> >>> If the MPL forwarder accepts the MPL multicast packet, the MPL >>>> >>> forwarder determines whether or not to deliver the original multi= cast >>>> >>> packet to the next higher layer. >>>> >>> >>>> >>> UH> How would it determine that? >>>> >>> >>>> >>> For example, if the MPL multicast >>>> >>> packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes= the >>>> >>> outer IPv6 header, which also removes MPL Option. >>>> >>> >>>> >>> UH> For example? What exactly needs to be done? >>>> >>> >>>> >>> 5.5. Transmission of ICMPv6 MPL Messages >>>> >>> >>>> >>> The MPL forwarder generates and transmits a new ICMPv6 MPL messag= e >>>> >>> whenever Trickle requests a transmission. >>>> >>> >>>> >>> UH> So for each data packet there would be a new ICMPv6 message? >>>> >>> Wouldn't that create a lot of overhead? >>>> >>> >>>> >>> UH> To which address is the ICMP message sent? On which interface? >>>> >>> >>>> >>> The MPL forwarder includes >>>> >>> an encoding of each sliding window in the ICMPv6 MPL message. >>>> >>> >>>> >>> Each sliding window is encoded using an MPL Window entry, defined= in >>>> >>> Section 5.2. The MPL forwarder sets the MPL Window fields as >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>16] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> follows: >>>> >>> >>>> >>> S If the MPL seed identifier is 0, set S to 0. If the MPL seed >>>> >>> identifier is within the range [1, 65535], set S to 2. Otherw= ise, >>>> >>> set S to 3. >>>> >>> >>>> >>> w-min Set to the lower bound of the sliding window (i.e. >>>> >>> WindowMin). >>>> >>> >>>> >>> w-len Set to the length of the window (i.e. WindowMax - WindowM= in). >>>> >>> >>>> >>> seed-id If S is non-zero, set to the MPL seed identifier. >>>> >>> >>>> >>> buffered-mpl-packets Set each bit that represents a sequence num= ber >>>> >>> of a packet in BufferedPackets to 1. Set all other bits to 0. >>>> >>> The i'th bit in buffered-mpl-packets represents a sequence num= ber >>>> >>> of w-min + i. >>>> >>> >>>> >>> 5.6. Reception of ICMPv6 MPL Messages >>>> >>> >>>> >>> An MPL forwarder processes each ICMPv6 MPL message that it receiv= es >>>> >>> to determine if it has any new MPL multicast packets to receive o= r >>>> >>> offer. >>>> >>> >>>> >>> An MPL forwarder determines if a new MPL multicast packet has not >>>> >>> been received from a neighboring node if any of the following >>>> >>> conditions hold true: >>>> >>> >>>> >>> 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed >>>> >>> that does not have a corresponding sliding window entry on th= e >>>> >>> MPL forwarder. >>>> >>> >>>> >>> 2. The neighbor has a packet in its BufferedPackets that has >>>> >>> sequence value greater than or equal to WindowMax (i.e. w-min= + >>>> >>> w-len >=3D WindowMax). >>>> >>> >>>> >>> 3. The neighbor has a packet in its BufferedPackets that has >>>> >>> sequence number within range of the sliding window but is not >>>> >>> included in BufferedPackets (i.e. the i'th bit in buffered-mp= l- >>>> >>> packets is set to 1, where the sequence number is w-min + i). >>>> >>> >>>> >>> When an MPL forwarder determines that it has not yet received a n= ew >>>> >>> MPL multicast packet buffered by a neighboring device, the MPL >>>> >>> forwarder resets the Trickle timer associated with reactive >>>> >>> propagation. >>>> >>> >>>> >>> An MPL forwarder determines if an entry in BufferedPackets has no= t >>>> >>> been received by a neighboring MPL forwarder if any of the follow= ing >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>17] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> conditions hold true: >>>> >>> >>>> >>> 1. The ICMPv6 MPL message does not include an MPL Window for the >>>> >>> packet's MPL seed. >>>> >>> >>>> >>> 2. The packet's sequence number is greater than or equal to the >>>> >>> neighbor's WindowMax value (i.e. the packet's sequence number= is >>>> >>> greater than or equal to w-min + w-len). >>>> >>> >>>> >>> 3. The packet's sequence number is within the range of the >>>> >>> neighbor's sliding window [WindowMin, WindowMax), but not >>>> >>> included in the neighbor's BufferedPacket (i.e. the packet's >>>> >>> sequence number is greater than or equal to w-min, strictly l= ess >>>> >>> than w-min + w-len, and the corresponding bit in buffered-mpl= - >>>> >>> packets is set to 0. >>>> >>> >>>> >>> When an MPL forwarder determines that it has at least one buffere= d >>>> >>> MPL multicast packet that has not yet been received by a neighbor= , >>>> >>> the MPL forwarder resets the Trickle timer associated with reacti= ve >>>> >>> propagation. Additionally, for each buffered MPL multicast packe= t >>>> >>> that should be transferred, the MPL forwarder MUST reset the Tric= kle >>>> >>> timer and reset e to 0 for proactive propagation. If the Trickle >>>> >>> timer for proactive propagation has already stopped execution, >>>> >>> >>>> >>> UH> Which timer? I thought there is one timer per packet in the >>>> >>> proactive mode? >>>> >>> >>>> >>> the >>>> >>> MPL forwarder MUST initialize a new Trickle timer and start execu= tion >>>> >>> of the Trickle algorithm. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>18] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 6. MPL Parameters >>>> >>> >>>> >>> An MPL forwarder maintains two sets of Trickle parameters for the >>>> >>> proactive and reactive methods. The Trickle parameters are liste= d >>>> >>> below: >>>> >>> >>>> >>> PROACTIVE_IMIN The minimum Trickle timer interval, as defined in >>>> >>> [RFC6206] for proactive propagation. >>>> >>> >>>> >>> PROACTIVE_IMAX The maximum Trickle timer interval, as defined in >>>> >>> [RFC6206] for proactive propagation. >>>> >>> >>>> >>> PROACTIVE_K The redundancy constant, as defined in [RFC6206] for >>>> >>> proactive propagation. >>>> >>> >>>> >>> PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirati= ons >>>> >>> that occur before terminating the Trickle algorithm. MUST be = set >>>> >>> to a value greater than 0. >>>> >>> >>>> >>> REACTIVE_IMIN The minimum Trickle timer interval, as defined in >>>> >>> [RFC6206] for reactive propagation. >>>> >>> >>>> >>> REACTIVE_IMAX The maximum Trickle timer interval, as defined in >>>> >>> [RFC6206] for reactive propagation. >>>> >>> >>>> >>> REACTIVE_K The redundancy constant, as defined in [RFC6206] for >>>> >>> reactive propagation. >>>> >>> >>>> >>> REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expiratio= ns >>>> >>> that occur before terminating the Trickle algorithm. MAY be s= et >>>> >>> to 0, which disables reactive propagation. >>>> >>> >>>> >>> WINDOW_HOLD_TIME The minimum lifetime for sliding window state. >>>> >>> >>>> >>> >>>> >>> UH> I don't see any recommendations for these values. That is >>>> >>> typically requested in the IESG evaluation for standards track >>>> >>> documents (either default values and/or guideslines on the values)= . >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>19] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 7. Acknowledgements >>>> >>> >>>> >>> The authors would like to acknowledge the helpful comments of Rob= ert >>>> >>> Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Re= ddy, >>>> >>> Dario Tedeschi, and Peter van der Stok, which greatly improved th= e >>>> >>> document. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>20] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 8. IANA Considerations >>>> >>> >>>> >>> The Trickle Multicast option requires an IPv6 Option Number. >>>> >>> >>>> >>> >>>> >>> >>>> >>> HEX act chg rest >>>> >>> --- --- --- ----- >>>> >>> C 01 0 TBD >>>> >>> >>>> >>> >>>> >>> >>>> >>> The first two bits indicate that the IPv6 node MUST discard the >>>> >>> packet if it doesn't recognize the option type, and the third bit >>>> >>> indicates that the Option Data MUST NOT change en-route. >>>> >>> >>>> >>> >>>> >>> UH> That does not look like a valid IANA section. RFC 5226 give so= me >>>> >>> good guidelines. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>21] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 9. Security Considerations >>>> >>> >>>> >>> TODO. >>>> >>> >>>> >>> >>>> >>> UH> This document needs a security considerations section. Refer t= o RFC >>>> >>> 3552. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>22] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> 10. References >>>> >>> >>>> >>> 10.1. Normative References >>>> >>> >>>> >>> [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1= 982, >>>> >>> August 1996. >>>> >>> >>>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>> >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>> >>> >>>> >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. >>>> >>> >>>> >>> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version= 6 >>>> >>> (IPv6) Specification", RFC 2460, December 1998. >>>> >>> >>>> >>> [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in >>>> >>> IPv6 Specification", RFC 2473, December 1998. >>>> >>> >>>> >>> [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Contro= l >>>> >>> Message Protocol (ICMPv6) for the Internet Protocol >>>> >>> Version 6 (IPv6) Specification", RFC 4443, March 2006. >>>> >>> >>>> >>> [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. K= o, >>>> >>> "The Trickle Algorithm", RFC 6206, March 2011. >>>> >>> >>>> >>> [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, = R., >>>> >>> Levis, P., Pister, K., Struik, R., Vasseur, JP., and R= . >>>> >>> Alexander, "RPL: IPv6 Routing Protocol for Low-Power a= nd >>>> >>> Lossy Networks", RFC 6550, March 2012. >>>> >>> >>>> >>> 10.2. Informative References >>>> >>> >>>> >>> [I-D.ietf-roll-terminology] >>>> >>> Vasseur, J., "Terminology in Low power And Lossy >>>> >>> Networks", draft-ietf-roll-terminology-06 (work in >>>> >>> progress), September 2011. >>>> >>> >>>> >>> UH> That document is never actually cited. Also, it has not been >>>> >>> updated in over a year. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>23] >>>> >>> Internet-Draft MPL Octobe= r >>>> >>>2012 >>>> >>> >>>> >>> >>>> >>> Authors' Addresses >>>> >>> >>>> >>> Jonathan W. Hui >>>> >>> Cisco >>>> >>> 170 West Tasman Drive >>>> >>> San Jose, California 95134 >>>> >>> USA >>>> >>> >>>> >>> Phone: +408 424 1547 >>>> >>> Email: jonhui@cisco.com >>>> >>> >>>> >>> >>>> >>> Richard Kelsey >>>> >>> Silicon Labs >>>> >>> 25 Thomson Place >>>> >>> Boston, Massachusetts 02210 >>>> >>> USA >>>> >>> >>>> >>> Phone: +617 951 1225 >>>> >>> Email: richard.kelsey@silabs.com >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hui & Kelsey Expires April 22, 2013 [Pa= ge >>>> >>>24] >>>> >>> _______________________________________________ >>>> >>> Roll mailing list >>>> >>> Roll@ietf.org >>>> >>> https://www.ietf.org/mailman/listinfo/roll >>> >> >>> >> >=20 >=20 --B_3434354689_320905 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Ulrich,

<= /div>
A few notes…..
1)  We did the testing sometim= e ago and you are exactly correct on setting k=3Dinfinity.  I believe tha= t each node resends the message for each interval (so you do get many more t= ransmissions that I said below)
2)  We did not try just using= jitter so don't have any results to share/compare

= What would have been interesting to test is using suppression but measuring = to ensure that suppression never denied access to multicast messages missed = by downstream devices (where the upstream device already saw the message and= was using suppression).   I think we may have taken the more "brute fo= rce" approach in ensuring all devices got their message.  There is not = much penalty to that in a network of 30 but with many more, that approach wo= uld not work.

Don



From: Ulrich Herberg &l= t;ulrich@herberg.name>
Date: Monday, October 29, 2012 11:18 AM
= To: Don Sturek <d.sturek@att.net>
C= c: "JP Vasseur (jvasseur)" <j= vasseur@cisco.com>, "<r= ichard.kelsey@silabs.com>" <richard.kelsey@silabs.com>, "roll= @ietf.org WG" <roll@ietf.org>, = Michael Richardson <mcr@sandelman.ca>
Subject: Re: [Roll] WG Last = Call draft-ietf-roll-trickle-mcast-02

Hi Don,
thanks for this information. See below

On Mon, Oct 29, 2012 at 11:06 AM, Don Sturek <d.sturek@att.net> wrote:
Hi Ulrich,

We did quite a lot of testing using 30 nodes (our messaging profile) and using specific multicast parameter settings as follows:
1.   iMin =3D 128ms, iMax=3D128ms, k=3Dinfinity, TAct=3D3, TDwell=3D16s
2.   iMin =3D 128ms, iMax=3D128ms, k=3Dinfinity, TAct=3D1, TDwell=3D3s
3.   iMin =3D 512ms, iMax=3D512ms, k=3Dinfinity, TAct=3D1, TDwell=3D3s
4.   iMin =3D 512ms, iMax=3D512ms, k=3Dinfinity, TAct=3D3, TDwell=3D3s

First thing to note is we always set k=3Dinfinity since we could not
identify anything in our multicast streams to suppress (basically, we just<= br> wanted every device to see each multicast message at least once and
hopefully only once)

My understanding i= s that if you set k to infinity, you would probably see each message many mo= re times than just once. 
RFC6206 states:
  "<= span style=3D"font-size:1em">In general,&nb= sp;this approach [setting k to infin= ity] is highly dangerous and it is N= OT RECOMMENDED. Disabling suppressio= n means that every node will always send on every interval; this can lead to congestion in dense networks. This=  approach is especially dangerous if= many nodes reset their intervals at= the same time. In general, it is much more desirable to set k to a high value (e.g., 5 or 10) than infinity. = Typical values for k are 1-5: these = achieve a good balance between redundancy and low cost[Levis08]."


= 
=
I assume =
that with k =3D infinity, the performance would be much worse than classic flo=
oding and you would have a lot of bandwidth consumption in the LLN. Did you =
observe that?
 


Next, the main purpose of our multicast traffic was for resource discovery<= br> using mDNS so there is no driving requirement around low latency
applications (eg, other applications would be more sensitive to the iMin and iMax settings than we were).


I think this is important to point out in the draft. I agree that t= here are certain applications where delay is less important than others. For= mDNS, whether it is delay-critical may also depend on the application that = uses mDNS to discover the service.

 

We ended up using parameter settings (4) above.

I think something like trickle multicast is a MUST for mesh routing
solutions like ROLL.  The issue you get into using multicast is how th= e
messages are propagated.  If every device that sees a multicast simply=
forwards, then you end up with broadcast storms where nothing is heard.
= The randomization of re-broadcast is essential.
 =

But since you don't use suppression, the overhead = is likely more substantial than in classic flooding. Using a decent jitter v= alue in classic flooding, or more advanced flooding mechanisms such as MPR f= looding would likely lead to much lower channel use. Have you compared to MP= R flooding or classic flooding with jitter ?

 =

I think our results are being incorporated into the ROLL deployment
experience draft
(http://datatracker.ietf.org/doc/draft-hui-vasseur-rol= l-rpl-deployment/).

By the way, someone noted the lack of a Security Considerations section. We force Link Layer security on so did not plan any additional security
= than that.....


That may = work in some deployments, but will not suffice for the draft to only rely on= link-layer security, and to not even have a security considerations section= . 

Best
Ulrich

<= div>
=
On 10/29/12 9:38 AM, "Ulrich Herberg" <ulrich@herberg.name> wrote:

>Hi Don,
>
>thanks, that's good to know. To your knowledge, are there any public >results about delivery ratio of packets, overhead, delay, state
>requirements and/or a comparison to other flooding mechanisms such as >classic flooding?
>
>Best
>Ulrich
>
>On Oct 26, 2012, at 20:50, Don Sturek <d.sturek@att.net> wrote:
>
>> Hi Ulrich,
>>
>> For ZigBee IP, we are using the trickle multicast draft.  We = have 7
>> platforms interoperating using the draft.
>>
>> Don
>>
>>
>> On 10/26/12 8:33 PM, "Ulrich Herberg" <ulrich@herberg.name> wrote:
>>
>>> Hi,
>>>
>>> below is my review.
>>>
>>> My major comment is that the IANA section needs to be fixed an= d a
>>> security considerations section needs to be written. Without t= hat
>>> section, the document should not go forward in my opinion.
= >>> Then I have multiple questions for clarity (see the detailed r= eview).
>>> Also, as a standards track document, I think it should give so= me
>>> guidelines about which values for the parameters to use, as we= ll as
>>> some indications about the state requirements of the protocol.=
>>> Are there any implementations and/or deployments of the protoc= ol out
>>> there?
>>>
>>> Best regards
>>> Ulrich
>>>
>>>
>>>
>>>
>>> ROLL                 &= nbsp;                     =                      =  J.
>>>Hui
>>> Internet-Draft
>>>Cisco
>>> Intended status: Standards Track         &= nbsp;                     = R.
>>>Kelsey
>>> Expires: April 22, 2013           &nb= sp;                     &n= bsp;   Silicon
>>>Labs
>>>                  =                      = ;               October 19, 2012
>>>
>>>
>>>      Multicast Protocol for Low power and Lossy= Networks (MPL)
>>>                  = draft-ietf-roll-trickle-mcast-02
>>>
>>> Abstract
>>>
>>>  This document specifies the Multicast Protocol for Low p= ower and
>>>  Lossy Networks (MPL) that provides IPv6 multicast forwar= ding in
>>>  constrained networks.  MPL avoids the need to const= ruct or maintain
>>>  any multicast forwarding topology, disseminating message= s to all MPL
>>>  forwarders in an MPL domain.  MPL uses the Trickle = algorithm to drive
>>>  packet transmissions for both control and data-plane pac= kets.
>>>  Specific Trickle parameter configurations allow MPL to t= rade between
>>>  dissemination latency and transmission efficiency.
>>>
>>> Status of this Memo
>>>
>>>  This Internet-Draft is submitted in full conformance wit= h the
>>>  provisions of BCP 78 and BCP 79.
>>>
>>>  Internet-Drafts are working documents of the Internet En= gineering
>>>  Task Force (IETF).  Note that other groups may also= distribute
>>>  working documents as Internet-Drafts.  The list of = current Internet-
>>>  Drafts is at http://datatracker.ietf.org/drafts/current/.<= br> >>>
>>>  Internet-Drafts are draft documents valid for a maximum = of six months
>>>  and may be updated, replaced, or obsoleted by other docu= ments at any
>>>  time.  It is inappropriate to use Internet-Drafts a= s reference
>>>  material or to cite them other than as "work in progress= ."
>>>
>>>  This Internet-Draft will expire on April 22, 2013.
>>>
>>> Copyright Notice
>>>
>>>  Copyright (c) 2012 IETF Trust and the persons identified= as the
>>>  document authors.  All rights reserved.
>>>
>>>  This document is subject to BCP 78 and the IETF Trust's = Legal
>>>  Provisions Relating to IETF Documents
>>>  (http://trustee.ietf.org/license-info) in effect on the date of >>>  publication of this document.  Please review these = documents
>>>  carefully, as they describe your rights and restrictions= with respect
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>1]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  to this document.  Code Components extracted from t= his document must
>>>  include Simplified BSD License text as described in Sect= ion 4.e of
>>>  the Trust Legal Provisions and are provided without warr= anty as
>>>  described in the Simplified BSD License.
>>>
>>>
>>> Table of Contents
>>>
>>>  1.  Introduction . . . . . . . . . . . . . . . . . = . . . . . . . .  3
>>>  2.  Terminology  . . . . . . . . . . . . . . .= . . . . . . . . . .  4
>>>  3.  Overview . . . . . . . . . . . . . . . . . . . = . . . . . . . .  5
>>>  4.  Message Formats  . . . . . . . . . . . . .= . . . . . . . . . .  7
>>>    4.1.  MPL Option . . . . . . . . . . . . . .= . . . . . . . . . .  7
>>>    4.2.  ICMPv6 MPL Message . . . . . . . . . .= . . . . . . . . . .  8
>>>      4.2.1.  MPL Window . . . . . . . . . = . . . . . . . . . . . . .  9
>>>  5.  MPL Forwarder Behavior . . . . . . . . . . . . = . . . . . . . . 11
>>>    5.1.  Multicast Packet Dissemination . . . .= . . . . . . . . . . 11
>>>      5.1.1.  Trickle Parameters and Variab= les . . . . . . . . . . . 12
>>>      5.1.2.  Proactive Propagation  .= . . . . . . . . . . . . . . . 12
>>>      5.1.3.  Reactive Propagation . . . . = . . . . . . . . . . . . . 13
>>>    5.2.  Sliding Windows  . . . . . . . . = . . . . . . . . . . . . . 13
>>>    5.3.  Transmission of MPL Multicast Packets =  . . . . . . . . . . 15
>>>    5.4.  Reception of MPL Multicast Packets . .= . . . . . . . . . . 16
>>>    5.5.  Transmission of ICMPv6 MPL Messages &n= bsp;. . . . . . . . . . . 16
>>>    5.6.  Reception of ICMPv6 MPL Messages . . .= . . . . . . . . . . 17
>>>  6.  MPL Parameters . . . . . . . . . . . . . . . . = . . . . . . . . 19
>>>  7.  Acknowledgements . . . . . . . . . . . . . . . = . . . . . . . . 20
>>>  8.  IANA Considerations  . . . . . . . . . . .= . . . . . . . . . . 21
>>>  9.  Security Considerations  . . . . . . . . .= . . . . . . . . . . 22
>>>  10. References . . . . . . . . . . . . . . . . . . . . .= . . . . . 23
>>>    10.1. Normative References . . . . . . . . . . . = . . . . . . . . 23
>>>    10.2. Informative References . . . . . . . . . . = . . . . . . . . 23
>>>  Authors' Addresses . . . . . . . . . . . . . . . . . . .= . . . . . 24
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>2]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 1.  Introduction
>>>
>>>  Low power and Lossy Networks typically operate with stri= ct resource
>>>  constraints in communication, computation, memory, and e= nergy.  Such
>>>  resource constraints may preclude the use of existing IP= v6 multicast
>>>  topology and forwarding mechanisms.  Traditional IP= multicast
>>>  forwarding typically relies on topology maintenance mech= anisms to
>>>  forward multicast messages to all subscribers of a multi= cast group.
>>>  However, maintaining such topologies in LLNs is costly a= nd may not be
>>>  feasible given the available resources.
>>>
>>>  Memory constraints may limit devices to maintaining link= s/routes to
>>>  one or a few neighbors.  For this reason, the Routi= ng Protocol for
>>>  LLNs (RPL)
>>>
>>> UH> The correct title is "RPL: IPv6 Routing Protocol for Lo= w-Power and
>>> Lossy Networks"
>>>
>>>   specifies both storing and non-storing modes [RFC6550].=
>>>  The latter allows RPL routers to maintain only one or a = few default
>>>  routes towards a LLN Border Router (LBR)
>>>
>>> UH> I did not find LBR in the terminology section.
>>>
>>>  and use source routing to
>>>  forward packets away from the LBR.  For the same re= asons, a LLN
>>>  device may not be able to maintain a multicast forwardin= g topology
>>>  when operating with limited memory.
>>>
>>>  Furthermore, the dynamic properties of wireless networks= can make the
>>>  cost of maintaining a multicast forwarding topology proh= ibitively
>>>  expensive.  In wireless environments, topology main= tenance may
>>>  involve selecting a connected dominating set used to for= ward
>>>  multicast messages to all nodes in an administrative dom= ain.
>>>  However, existing mechanisms often require two-hop topol= ogy
>>>  information and the cost of maintaining such information= grows
>>>  polynomially with network density.
>>>
>>>  This document specifies the Multicast Protocol for Low p= ower and
>>>  Lossy Networks (MPL), which provides IPv6 multicast forw= arding in
>>>  constrained networks.  MPL avoids the need to const= ruct or maintain
>>>  any multicast forwarding topology, disseminating multica= st messages
>>>  to all MPL forwarders in an MPL domain.  By using t= he Trickle
>>>  algorithm [RFC6206], MPL requires only small, constant s= tate for each
>>>  MPL device that initiates disseminations.  The Tric= kle algorithm also
>>>  allows MPL to be density-aware, allowing the communicati= on rate to
>>>  scale logarithmically with density.
>>>
>>> UH> I am not sure I understand the last sentence. What does= it mean?
>>> How is that achieved?
>>>
>>> UH> By the way, since this is a standards track document, i= s there any
>>> deployment experience? Implementations?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>3]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 2.  Terminology
>>>
>>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "= SHALL NOT",
>>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIO= NAL" in this
>>>  document are to be interpreted as described in RFC 2119 = [RFC2119].
>>>
>>> UH> "NOT RECOMMENDED" is missing as per the errata of RFC21= 19
>>>
>>>
>>>  The following terms are used throughout this document: >>>
>>>  MPL forwarder       An IPv6 router that s= ubscribes to the MPL
>>>                  =    multicast group and participates in disseminating
>>>                  =    MPL multicast packets.
>>>
>>>  MPL multicast scope The multicast scope that MPL uses wh= en forwarding
>>>                  =    MPL multicast packets.  In other words, the
>>>                  =    multicast scope of the IPv6 Destination Address
>>>                  =    of an MPL multicast packet.
>>>
>>> UH> An RFC reference to "scope" could be helpful.
>>>
>>>  MPL domain          A connected= set of MPL forwarders that define the
>>>                  =    extent of the MPL dissemination process.
>>>
>>> UH> What does connected mean? What if a the network is spli= t in two
>>>parts?
>>>
>>>                  =    As a
>>>                  =    form of flood, all MPL forwarders in an MPL
>>>                  =    domain will receive MPL multicast packets.
>>>
>>> UH> Probably not *all* forwards will receive it (assuming p= ackets can
>>> be lost)
>>>
>>>
>>>                  =    The
>>>                  =    MPL domain MUST be composed of at least one MPL
>>>                  =    multicast scope and MAY be composed of multiple
>>>                  =    MPL multicast scopes.
>>>
>>> UH> Why is that? Anyway, I am unsure whether one can say th= at a
>>> routing domain "consists" of multicast scopes. If I understand= that
>>> correctly, the multicast scope just determines how far a messa= ge
>>> propagates.
>>>
>>>
>>>  MPL seed            A MPL = forwarder that begins the dissemination
>>>                  =    process for an MPL multicast packet.  The MPL
>>>                  =    seed may be different than the source of the
>>>                  =    original multicast packet.
>>>
>>>  MPL seed identifier An identifier that uniquely identifi= es an MPL
>>>                  =    forwarder within its MPL domain.
>>>
>>> UH> How is the uniqueness guaranteed? What kind of identifi= er is that?
>>> An IP address? I see it's defined later, but maybe it would be= helpful
>>> to mention it here, too.
>>>
>>>
>>>  original multicast packet  An IPv6 multicast packet= that is
>>>                  =    disseminated using MPL.
>>>
>>> UH> That terminology sounds a bit confusing; I would have i= magined
>>> that the above description matches the following term "MPL mul= ticast
>>> packet". What's the difference between an "original multicast = packet"
>>> and an "MPL multicast packet"? I assume the one is the inner p= acket
>>> when using IPv6-in-IPv6 tunnels, the other one is the outer pa= cket
>>> with the options header.
>>>
>>>
>>>  MPL multicast packet  An IPv6 multicast packet that= contains an MPL
>>>                  =    Hop-by-Hop Option.  When either source or
>>>                  =    destinations are beyond the MPL multicast scope,
>>>
>>> UH> Above it was said there may be multiple scopes in a dom= ain. Here
>>> you talk about "the" scope. Which one?
>>>
>>>                  =    the MPL multicast packet is an IPv6-in-IPv6
>>>                  =    packet that contains an MPL Hop-by-Hop Option in
>>>                  =    the outer IPv6 header and encapsulates an
>>>                  =    original multicast packet.  When both source and
>>>                  =    destinations are within the MPL multicast scope,
>>>                  =    the MPL Hop-by-Hop Option may be included
>>>                  =    directly within the original multicast packet.
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>4]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 3.  Overview
>>>
>>>  MPL delivers IPv6 multicast packets by disseminating the= m to all MPL
>>>  forwarders within an MPL domain.  MPL dissemination= is a form of
>>>  flood.  An MPL forwarder may broadcast/multicast an= MPL multicast
>>>  packet out of the same physical interface on which it wa= s received.
>>>  Using link-layer broadcast/multicast allows MPL to forwa= rd multicast
>>>  packets without explicitly identifying next-hop destinat= ions.  An MPL
>>>  forwarder may also broadcast/multicast MPL multicast pac= kets out
>>>  other interfaces to disseminate the message across diffe= rent links.
>>>  MPL does not build or maintain a multicast forwarding to= pology to
>>>  forward multicast packets.
>>>
>>>  Any MPL forwarder may initiate the dissemination process= by serving
>>>  as an MPL seed for an original multicast packet.  T= he MPL seed may or
>>>  may not be the same device as the source of the original= multicast
>>>  packet.  When the original multicast packet's sourc= e is outside the
>>>  LLN,
>>>
>>> UH> LLN or MPL domain? How can a router determine if an inc= oming
>>> packet is inside our outside the MPL domain?
>>>
>>>  the MPL seed may be the ingress router.  Even if an= original
>>>  multicast packet source is within the LLN, the source ma= y first
>>>  forward the multicast packet to the MPL seed using IPv6-= in-IPv6
>>>  tunneling.
>>>
>>> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a sec= tion with a
>>> title not related to "IPv6 tunneling". I suggest to make an ow= n
>>> section.
>>>
>>>  Because MPL state requirements grows with the number of<= br> >>>  active MPL seeds,
>>>
>>> UH> In section 1 it was written that the state is constant.= Here you
>>> say it grows. Which one is it?
>>>
>>>   limiting the number of MPL seeds reduces the amount
= >>>  of state that MPL forwarders must maintain.
>>>
>>>  Because MPL typically broadcasts/multicasts MPL packets = out of the
>>>  same interface on which they were received,
>>>
>>> UH> Why typically? Doesn't that depend on the scenario that= this
>>> specification is used in?
>>>
>>>  MPL forwarders are likely
>>>  to receive an MPL multicast packet more than once.
>>>
>>> UH> I am not sure if that is the only reason. Isn't the rea= son that it
>>> may be received from multiple neighbors?
>>>
>>>  The MPL seed tags
>>>  each original multicast packet with an MPL seed identifi= er and a
>>>  sequence number.  The sequence number provides a to= tal ordering of
>>>  MPL multicast packets disseminated by the MPL seed.
>>>
>>>  MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option= , to include
>>>  MPL-specific information along with the original multica= st packet.
>>>  Each IPv6 multicast packet that MPL disseminates include= s the MPL
>>>  Option.  Because the original multicast packet's so= urce and the MPL
>>>  seed may not be the same device, the MPL Option may be a= dded to the
>>>  original multicast packet en-route.  To allow Path = MTU discovery to
>>>  work properly, MPL encapsulates the original multicast p= acket in
>>>  another IPv6 header that includes the MPL Option.
>>>
>>>  Upon receiving a new MPL multicast packet for forwarding= , the MPL
>>>  forwarder may proactively transmit the MPL multicast pac= ket packet a
>>>  limited number of times and then falls back into an opti= onal reactive
>>>  mode.  In maintenance mode, an MPL forwarder buffer= s recently
>>>  received MPL multicast packets and advertises a summary = of recently
>>>  received MPL multicast packets from time to time, allowi= ng
>>>  neighboring MPL forwarders to determine if they have any= new
>>>  multicast packets to offer or receive.
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>5]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  MPL forwarders schedule their packet (control and data) = transmissions
>>>  using the Trickle algorithm [RFC6206].  Trickle's a= daptive
>>>  transmission interval allows MPL to quickly disseminate = messages when
>>>  there are new MPL multicast packets, but reduces transmi= ssion
>>>  overhead as the dissemination process completes.  T= rickle's
>>>  suppression mechanism and transmission time selection al= low MPL's
>>>  communication rate to scale logarithmically with density= .
>>>
>>> UH> I think the whole introduction is not very easy to read= . There is
>>> a lot of text about some details (IPv6-in-IPv6 tunnels, multip= le
>>> interfaces), but the essential mechanism is hard to identify f= rom the
>>> text. Also, there is nothing mentioned about what kind of stat= e is
>>> required to be stored on each router (which information sets e= tc).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>6]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 4.  Message Formats
>>>
>>> 4.1.  MPL Option
>>>
>>>  The MPL Option is carried in an IPv6 Hop-by-Hop Options = header,
>>>
>>> UH> I think the correct term is "IPv6 Extension Hop-by-Hop = Options
>>>header"
>>>
>>> UH> More importantly,  RFC6564 specifies:
>>>
>>>     New options for the existing Hop-by-Hop Header S= HOULD NOT be
>>>     created or specified unless no alternative solut= ion is feasible.
>>>     Any proposal to create a new option for the exis= ting Hop-by-Hop
>>>     Header MUST include a detailed explanation of wh= y the hop-by-hop
>>>     behavior is absolutely essential in the document= proposing the new
>>>     option with hop-by-hop behavior.
>>>
>>> UH> I did not see such an explanation.
>>>
>>>
>>>  immediately following the IPv6 header.  The MPL Opt= ion has the
>>>  following format:
>>>
>>>     0             &nbs= p;     1                 &= nbsp; 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
>>>                  =                  +-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>                  =                  |  Optio= n Type  |  Opt Data Len |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>    | S |M|   rsv   |   sequence  = ;  |      seed-id (optional)       |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>
>>> UH> It could help to mention that this is formatted in netw= ork byte
>>>order
>>>
>>>  Option Type         XX (to be confir= med by IANA).
>>>
>>>  Opt Data Len        Length of the Op= tion Data field in octets.  MUST
>>>                  =    be set to either 2 or 4.
>>>
>>> UH> 2 or 4 depending on what?
>>>
>>>  S                = ;   2-bit unsigned integer.  Identifies the length of
>>>                  =    seed-id. 0 indicates that the seed-id is 0 and
>>>                  =    not included in the MPL Option. 1 indicates that
>>>                  =    the seed-id is a 16-bit unsigned integer. 2
>>>                  =    indicates that the seed-id is a 64-bit unsigned
>>>                  =    integer. 3 indicates that the seed-id is a 128-
>>>                  =    bit unsigned integer.
>>>
>>>  M                = ;   1-bit flag. 0 indicates that the value in
>>>                  =    sequence is not the greatest sequence number that
>>>                  =    was received from the MPL seed.
>>>
>>>  rsv               &nb= sp; 5-bit reserved field.  MUST be set to zero and
>>>                  =    incoming MPL multicast packets in which they are
>>>                  =    not zero MUST be dropped.
>>>
>>>  sequence            8-bit = unsigned integer.  Identifies relative
>>>                  =    ordering of MPL multicast packets from the source
>>>                  =    identified by seed-id.
>>>
>>>  seed-id             Unique= ly identifies the MPL seed that initiated
>>>                  =    dissemination of the MPL multicast packet.  The
>>>                  =    size of seed-id is indicated by the S field.
>>>
>>>  The Option Data of the Trickle Multicast option MUST NOT= change as
>>>  the MPL multicast packet is forwarded.  Nodes that = do not understand
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>7]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  the Trickle Multicast option MUST discard the packet. &n= bsp;Thus,
>>>  according to [RFC2460] the three high order bits of the = Option Type
>>>  must be set to '010'.  The Option Data length is va= riable.
>>>
>>>  The seed-id uniquely identifies an MPL seed within the M= PL domain.
>>>  When seed-id is 128 bits (S=3D3), the MPL seed MAY use an = IPv6 address
>>>  assigned to one of its interfaces that is unique within = the MPL
>>>  domain.  Managing MPL seed identifiers is not withi= n scope of this
>>>  document.
>>>
>>>  The sequence field establishes a total ordering of MPL m= ulticast
>>>  packets from the same MPL seed.  The MPL seed MUST = increment the
>>>  sequence field's value on each new MPL multicast packet = that it
>>>  disseminates.  Implementations MUST follow the Seri= al Number
>>>  Arithmetic as defined in [RFC1982] when incrementing a s= equence value
>>>  or comparing two sequence values.
>>>
>>>  Future updates to this specification may define addition= al fields
>>>  following the seed-id field.
>>>
>>> 4.2.  ICMPv6 MPL Message
>>>
>>>  The MPL forwarder uses ICMPv6 MPL messages to advertise = information
>>>  about recently received MPL multicast packets.  The= ICMPv6 MPL
>>>  message has the following format:
>>>
>>>     0             &nbs= p;     1                 &= nbsp; 2                   3
= >>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>    |     Type      |  =   Code      |          Checksu= m             |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>    |              = ;                     &nbs= p;                     &nb= sp;     |
>>>    .              = ;         MPL Window[1..n]         &= nbsp;              .
>>>    .              = ;                     &nbs= p;                     &nb= sp;     .
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>
>>>
>>>  IP Fields:
>>>
>>>  Source Address      A link-local address = assigned to the sending
>>>                  =    interface.
>>>
>>>  Destination Address The link-local all-nodes MPL forward= ers multicast
>>>                  =    address (FF02::TBD).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>8]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  Hop Limit           255
>>>
>>>  ICMPv6 Fields:
>>>
>>>  Type               &n= bsp;XX (to be confirmed by IANA).
>>>
>>>  Code               &n= bsp;0
>>>
>>>  Checksum            The IC= MP checksum.  See [RFC4443].
>>>
>>>  MPL Window[1..n]    List of one or more MPL Wi= ndows (defined in
>>>                  =    Section 4.2.1).
>>>
>>>  An MPL forwarder transmits an ICMPv6 MPL message to adve= rtise
>>>  information about buffered MPL multicast packets.  = More explicitly,
>>>  the ICMPv6 MPL message encodes the sliding window state = (described in
>>>  Section 5.2) that the MPL forwarder maintains for each M= PL seed.  The
>>>  advertisement serves to indicate to neighboring MPL forw= arders
>>>  regarding newer messages that it may send or the neighbo= ring MPL
>>>  forwarders have yet to receive.
>>>
>>> 4.2.1.  MPL Window
>>>
>>>  An MPL Window encodes the sliding window state (describe= d in
>>>  Section 5.2 that the MPL forwarder maintains for an MPL = seed.
>>>
>>> UH> missing ")"
>>>
>>>  Each
>>>  MPL Window has the following format:
>>>
>>>     0             &nbs= p;     1                 &= nbsp; 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
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>    |     w-min     |   w-le= n   | S |  seed-id (0, 2 or 16 octets)  |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>    |              = ;                     &nbs= p;                     &nb= sp;     |
>>>    .              = ;buffered-mpl-packets (0 to 8 octets)           &nb= sp; .
>>>    .              = ;                     &nbs= p;                     &nb= sp;     .
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>>>
>>>
>>>  w-min               8= -bit unsigned integer.  Indicates the first
>>>                  =    sequence number associated with the first bit in
>>>                  =    buffered-mpl-packets.
>>>
>>>  w-len               6= -bit unsigned integer.  Indicates the size of
>>>                  =    the sliding window and the number of valid bits
>>>                  =    in buffered-mpl-packets.  The sliding window's
>>>                  =    upper bound is the sum of w-min and w-len.
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                 = [Page
>>>9]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  S                = ;   2-bit unsigned integer.  Identifies the length of
>>>                  =    seed-id. 0 indicates that the seed-id value is 0
>>>                  =    and not included in the MPL Option. 1 indicates
>>>                  =    that the seed-id value is a 16-bit unsigned
>>>                  =    integer. 2 indicates that the seed-id value is a
>>>                  =    128-bit unsigned integer. 3 is reserved.
>>>
>>>  seed-id             Indica= tes the MPL seed associated with this
>>>                  =    sliding window.
>>>
>>>  buffered-mpl-packets  Variable-length bit vector. &= nbsp;Identifies the
>>>                  =    sequence numbers of MPL multicast packets that
>>>                  =    the MPL forwarder has buffered.  The sequence
>>>                  =    number is determined by w-min + i, where i is the
>>>                  =    offset within buffered-mpl-packets.
>>>
>>>  The MPL Window does not have any octet alignment require= ment.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>10]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 5.  MPL Forwarder Behavior
>>>
>>>  An MPL forwarder implementation needs to manage sliding = windows for
>>>  each active MPL seed.  The sliding window allows th= e MPL forwarder to
>>>  determine what multicast packets to accept and what mult= icast packets
>>>  are buffered.  An MPL forwarder must also manage MP= L packet
>>>  transmissions.
>>>
>>> 5.1.  Multicast Packet Dissemination
>>>
>>>  MPL uses the Trickle algorithm to control packet transmi= ssions when
>>>  disseminating MPL multicast packets [RFC6206].  MPL= provides two
>>>  propagation mechanisms for disseminating MPL multicast p= ackets.
>>>
>>>  1.  With proactive propagation, an MPL forwarder tr= ansmits buffered
>>>      MPL multicast packets using the Trickle al= gorithm.  This method
>>>      is called proactive propagation since an M= PL forwarder actively
>>>      transmits MPL multicast packets without di= scovering that a
>>>      neighboring MPL forwarder has yet to recei= ve the message.
>>>
>>>  2.  With reactive propagation, an MPL forwarder tra= nsmits ICMPv6 MPL
>>>      messages using the Trickle algorithm. &nbs= p;An MPL forwarder only
>>>      transmits buffered MPL multicast packets u= pon discovering that
>>>      neighboring devices have not yet to receiv= e the corresponding MPL
>>>      multicast packets.
>>>
>>>  When receiving a new multicast packet, an MPL forwarder = first
>>>  utilizes proactive propagation to forward the MPL multic= ast packet.
>>>  Proactive propagation reduces dissemination latency sinc= e it does not
>>>  require discovering that neighboring devices have not ye= t received
>>>  the MPL multicast packet.  MPL forwarders utilize p= roactive
>>>  propagation for newly received MPL multicast packets sin= ce they can
>>>  assume that some neighboring MPL forwarders have yet to = receive the
>>>  MPL multicast packet.  After a limited number of MP= L multicast packet
>>>  transmissions, the MPL forwarder may terminate proactive= propagation
>>>  for the MPL multicast packet.
>>>
>>>  An MPL forwarder may optionally use reactive propagation= to continue
>>>  the dissemination process with lower communication overh= ead.  With
>>>  reactive propagation, neighboring MPL forwarders use ICM= Pv6 MPL
>>>  messages to discover new MPL multicast messages that hav= e not yet
>>>  been received.  When discovering that a neighboring= MPL forwarder has
>>>  not yet received a new MPL multicast packet, the MPL for= warder
>>>  enables proactive propagation again.
>>>
>>> UH> There is not a lot of RFC2119 language in the above. Or= is that
>>> defined later? Is this above section more like an introduction= ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>11]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 5.1.1.  Trickle Parameters and Variables
>>>
>>>  As specified in RFC 6206 [RFC6206], a Trickle timer runs= for a
>>>  defined interval and has three configuration parameters:= the minimum
>>>  interval size Imin, the maximum interval size Imax, and = a redundancy
>>>  constant k.
>>>
>>>  MPL defines a fourth configuration parameter, TimerExpir= ations, which
>>>  indicates the number of Trickle timer expiration events = that occur
>>>  before terminating the Trickle algorithm.
>>>
>>>  Each MPL forwarder maintains a separate Trickle paramete= r set for the
>>>  proactive and reactive propagation methods.  TimerE= xpirations MUST be
>>>  greater than 0 for proactive propagation.  TimerExp= irations MAY be
>>>  set to 0 for reactive propagation, which effectively dis= ables
>>>  reactive propagation.
>>>
>>>  As specified in RFC 6206 [RFC6206], a Trickle timer has = three
>>>  variables: the current interval size I, a time within th= e current
>>>  interval t, and a counter c.
>>>
>>> UH> This sentence starts confusing, as it looks very simila= r to the
>>> first paragraph in this section. "a Trickle timer has three va= riables"
>>> How about using the same language as in RFC6206:
>>> "In addition to these three parameters, Trickle maintains thre= e
>>>  variables:
>>>  o  I, the current interval size,
>>>  o  t, a time within the current interval, and
>>>  o  c, a counter."
>>>
>>>
>>>  MPL defines a fourth variable, e, which counts the numbe= r of Trickle
>>>  timer expiration events since the Trickle timer was last= reset.
>>>
>>> 5.1.2.  Proactive Propagation
>>>
>>>  With proactive propagation, the MPL forwarder transmits = buffered MPL
>>>  multicast packets using the Trickle algorithm.  Eac= h buffered MPL
>>>  multicast packet that is proactively being disseminated = with
>>>  proactive propagation has an associated Trickle timer. >>>
>>> UH> I think that somewhere the state requirements need to b= e
>>> mentioned. How does that affect scalability of the algorithm e= tc.
>>> Density is mentioned somewhere in the beginning, but not expla= ined how
>>> that would affect scalability and state requirements.
>>>
>>>   Adhering to
>>>  Section 5 of RFC 6206 [RFC6206], this document defines t= he following:
>>>
>>>  o  This document defines a "consistent" transmissio= n for proactive
>>>     propagation as receiving an MPL multicast packet= that has the same
>>>     MPL seed identifier and sequence number as a buf= fered MPL packet.
>>>
>>>  o  This document defines an "inconsistent" transmis= sion for proactive
>>>     propagation as receiving an MPL multicast packet= that has the same
>>>     MPL seed identifier, the M flag set, and has a s= equence number
>>>     less than the buffered MPL multicast packet's se= quence number.
>>>
>>>  o  This document does not define any external "even= ts".
>>>
>>>  o  This document defines both MPL multicast packets= and ICMPv6 MPL
>>>     multicast packets as Trickle messages.  The= se messages are defined
>>>     in the sections below.
>>>
>>> UH> I don't see the term Trickle message used anywhere else= .
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>12]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  o  The actions outside the Trickle algorithm that t= he protocol takes
>>>     involve managing sliding window state, and is sp= ecified in
>>>     Section 5.2.
>>>
>>> 5.1.3.  Reactive Propagation
>>>
>>>  With reactive propagation, the MPL forwarder transmits I= CMPv6 MPL
>>>  messages using the Trickle algorithm.  A MPL forwar= der maintains a
>>>  single Trickle timer for reactive propagation with each = MPL domain.
>>>  When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder = does not
>>>  execute the Trickle algorithm for reactive propagation a= nd reactive
>>>  propagation is disabled.  Adhering to Section 5 of = RFC 6206
>>>  [RFC6206], this document defines the following:
>>>
>>>  o  This document defines a "consistent" transmissio= n for reactive
>>>     propagation as receiving an ICMPv6 MPL message t= hat indicates
>>>     neither the receiving nor transmitting node has = new MPL multicast
>>>     packets to offer.
>>>
>>>  o  This document defines an "inconsistent" transmis= sion for reactive
>>>     propagation as receiving an ICMPv6 MPL message t= hat indicates
>>>     either the receiving or transmitting node has at= least one new MPL
>>>     multicast packet to offer.
>>>
>>>  o  This document defines an "event" for reactive pr= opagation as
>>>     updating any sliding window (i.e. changing the v= alue of WindowMin,
>>>     WindowMax, or the set of buffered MPL multicast = packets) in
>>>     response to receiving an MPL multicast packet. >>>
>>>  o  This document defines both MPL multicast packets= and ICMPv6 MPL
>>>     multicast packets as Trickle messages.  The= se messages are defined
>>>     in the sections below.
>>>
>>> UH> I don't see the term "Trickle message" anywhere else &n= bsp;(other than
>>> in 5.1.2)
>>>
>>>
>>>  o  The actions outside the Trickle algorithm that t= he protocol takes
>>>     involve managing sliding window state, and is sp= ecified in
>>>     Section 5.2.
>>>
>>> 5.2.  Sliding Windows
>>>
>>>  Every MPL forwarder MUST maintain a sliding window of se= quence
>>>  numbers for each MPL seed of recently received MPL packe= ts.  The
>>>  sliding window performs two functions:
>>>
>>>  1.  Indicate what MPL multicast packets the MPL for= warder should
>>>      accept.
>>>
>>>  2.  Indicate what MPL multicast packets are buffere= d and may be
>>>      transmitted to neighboring MPL forwarders.=
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>13]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  Each sliding window logically consists of:
>>>
>>>  1.  A lower-bound sequence number, WindowMin, that = represents the
>>>      sequence number of the oldest MPL multicas= t packet the MPL
>>>      forwarder is willing to receive or has buf= fered.  An MPL
>>>      forwarder MUST ignore any MPL multicast pa= cket that has sequence
>>>      value less than than WindowMin.
>>>
>>>  2.  An upper-bound sequence value, WindowMax, that = represents the
>>>      sequence number of the next MPL multicast = packet that the MPL
>>>      forwarder expects to receive.  An MPL= forwarder MUST accept any
>>>      MPL multicast packet that has sequence num= ber greater than or
>>>      equal to WindowMax.
>>>
>>>  3.  A list of MPL multicast packets, BufferedPacket= s, buffered by the
>>>      MPL forwarder.  Each entry in Buffere= dPackets MUST have a
>>>      sequence number in the range [WindowMin, W= indowMax).
>>>
>>>  4.  A timer, HoldTimer, that indicates the minimum = lifetime of the
>>>      sliding window.  The MPL forwarder MU= ST NOT free a sliding window
>>>      before HoldTimer expires.
>>>
>>>  When receiving an MPL multicast packet, if no existing s= liding window
>>>  exists for the MPL seed, the MPL forwarder MUST create a= new sliding
>>>  window before accepting the MPL multicast packet.  = The MPL forwarder
>>>  may reclaim memory resources by freeing a sliding window= for another
>>>  MPL seed if its HoldTimer has expired.  If, for any= reason, the MPL
>>>  forwarder cannot create a new sliding window, it MUST di= scard the
>>>  packet.
>>>
>>>  If a sliding window exists for the MPL seed, the MPL for= warder MUST
>>>  ignore the MPL multicast packet if the packet's sequence= number is
>>>  less than WindowMin or appears in BufferedPackets.  = ;Otherwise, the
>>>  MPL forwarder MUST accept the packet and determine wheth= er or not to
>>>  forward the packet and/or pass the packet to the next hi= gher layer.
>>>
>>>  When accepting an MPL multicast packet, the MPL forwarde= r MUST update
>>>  the sliding window based on the packet's sequence number= .  If the
>>>  sequence number is not less than WindowMax, the MPL forw= arder MUST
>>>  set WindowMax to 1 greater than the packet's sequence nu= mber.  If
>>>  WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL = forwarder MUST
>>>  increment WindowMin such that WindowMax - WindowMin <= =3D
>>>  MPL_MAX_WINDOW_SIZE.  At the same time, the MPL for= warder MUST free
>>>  any entries in BufferedPackets that have a sequence numb= er less than
>>>  WindowMin.
>>>
>>>  If the MPL forwarder has available memory resources, it = MUST buffer
>>>  the MPL multicast packet for proactive propagation. &nbs= p;If not enough
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>14]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  memory resources are available to buffer the packet, the= MPL
>>>  forwarder MUST increment WindowMin and free entries in >>>  BufferedPackets that have a sequence number less than Wi= ndowMin until
>>>  enough memory resources are available.  Incrementin= g WindowMin will
>>>  ensure that the MPL forwarder does not accept previously= received
>>>  packets.
>>>
>>>  An MPL forwarder MAY reclaim memory resources from slidi= ng windows
>>>  for other MPL seeds.  If a sliding window for anoth= er MPL seed is
>>>  actively disseminating messages and has more than one en= try in its
>>>  BufferedPackets, the MPL forwarder may free entries for = that MPL seed
>>>  by incrementing WindowMin as described above.
>>>
>>>  If the MPL forwarder cannot free enough memory resources= to buffer
>>>  the MPL multicast packet, the MPL forwarder MUST set Win= dowMin to 1
>>>  greater than the packet's sequence number.
>>>
>>>  When memory resources are available, an MPL forwarder SH= OULD buffer a
>>>  MPL multicast packet until the proactive propagation com= pletes (i.e.
>>>  the Trickle algorithm stops execution) and MAY buffer fo= r longer.
>>>  After proactive propagation completes, the MPL forwarder= may advance
>>>  WindowMin to the packet's sequence number to reclaim mem= ory
>>>  resources.  When the MPL forwarder no longer buffer= s any packets, it
>>>  MAY set WindowMin equal to WindowMax.  When setting= WindowMin equal
>>>  to WindowMax, the MPL forwarder MUST initialize HoldTime= r to
>>>  WINDOW_HOLD_TIME and start HoldTimer.  After HoldTi= mer expires, the
>>>  MPL forwarder MAY free the sliding window to reclaim mem= ory
>>>  resources.
>>>
>>> 5.3.  Transmission of MPL Multicast Packets
>>>
>>>  The MPL forwarder manages buffered MPL multicast packet = transmissions
>>>  using the Trickle algorithm.  When adding a packet = to
>>>  BufferedPackets, the MPL forwarder MUST create a Trickle= timer for
>>>  the packet and start execution of the Trickle algorithm.=
>>>
>>>  After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, = the MPL
>>>  forwarder MUST stop executing the Trickle algorithm. &nb= sp;When a buffered
>>>  MPL multicast packet does not have an active Trickle tim= er, the MPL
>>>  forwarder MAY free the buffered packet by advancing Wind= owMin to 1
>>>  greater than the packet's sequence number.
>>>
>>>  Each interface that supports MPL is configured with exac= tly one MPL
>>>  multicast scope.  The MPL multicast scope MUST be s= ite-local or
>>>  smaller and defaults to link-local.  A scope larger= than link-local
>>>  MAY be used only when that scope corresponds exactly to = the MPL
>>>  domain.
>>>
>>> UH> Why is this written in a section called "Transmission o= f MPL
>>> Multicast Packets"? Seems more like an initial configuration. = Same for
>>> the below IPv6.. I would have expected that in a dedicated sec= tion
>>> about IPv6 tunneling
>>> UH> How would the router now that the scope corresponds exa= ctly to the
>>> MPL domain?
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>15]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  An MPL domain may therefore be composed of one or more M= PL multicast
>>>  scopes.  For example, the MPL domain may be compose= d of a single MPL
>>>  multicast scope when using a site-local scope.  Alt= ernatively, the
>>>  MPL domain may be composed of multiple MPL multicast sco= pes when
>>>  using a link-local scope.
>>>
>>> UH> I am not quite sure how the scope works in this specifi= cation. Is
>>> that used somewhere when deciding whether to forward packets?<= br> >>>
>>>  IPv6-in-IPv6 encapsulation MUST be used when using MPL t= o forward an
>>>  original multicast packet whose source or destination ad= dress is
>>>  outside the MPL multicast scope.
>>>
>>> UH> The source address is a unicast address, right? How can= that be
>>> outside a multicast scope? How would you know?
>>>
>>>   IPv6-in-IPv6 encapsulation is
>>>  necessary to support Path MTU discovery when the MPL for= warder is not
>>>  the source of the original multicast packet.  IPv6-= in-IPv6
>>>  encapsulation also allows an MPL forwarder to remove the= MPL Option
>>>  when forwarding the original multicast packet over a lin= k that does
>>>  not support MPL.
>>>
>>> UH> That should be specified more clearly. What does "remov= e" mean? I
>>> suppose you mean decapsulate the inner IPv6 packet.
>>>
>>>   The destination address scope for the outer IPv6
>>>  header MUST be the MPL multicast scope.
>>>
>>> UH> Again, which one? I thought there can be several scopes= ?
>>>
>>>  When an MPL domain is composed of multiple MPL multicast= scopes (e.g.
>>>  when the MPL multicast scope is link-local), an MPL forw= arder MUST
>>>  decapsulate and encapsulate the original multicast packe= t when
>>>  crossing between different MPL multicast scopes.
>>>
>>> UH> When would you know when to cross a multicast scope? Do= you mean
>>> routing domain?
>>>
>>>   In doing so, the
>>>  MPL forwarder MUST duplicate the MPL Option, unmodified,= in the new
>>>  outer IPv6 header.
>>>
>>>  The IPv6 destination address of the MPL multicast packet= is the all-
>>>  MPL-forwarders multicast address (TBD).
>>>
>>> UH> The TBD will be hard to spot by the RFC editor / IANA. = I suggest
>>> to define the variable and use the value only in the IANA sect= ion.
>>>
>>>   The scope of the IPv6
>>>  destination address is set to the MPL multicast scope. >>>
>>> UH> which one?
>>>
>>> 5.4.  Reception of MPL Multicast Packets
>>>
>>>  Upon receiving an MPL multicast packet, the MPL forwarde= r first
>>>  determines whether or not to accept and buffer the MPL m= ulticast
>>>  packet based on its MPL seed and sequence value, as spec= ified in
>>>  Section 5.2.
>>>
>>>  If the MPL forwarder accepts the MPL multicast packet, t= he MPL
>>>  forwarder determines whether or not to deliver the origi= nal multicast
>>>  packet to the next higher layer.
>>>
>>> UH> How would it determine that?
>>>
>>>   For example, if the MPL multicast
>>>  packet uses IPv6-in-IPv6 encapsulation, the MPL forwarde= r removes the
>>>  outer IPv6 header, which also removes MPL Option.
>>>
>>> UH> For example? What exactly needs to be done?
>>>
>>> 5.5.  Transmission of ICMPv6 MPL Messages
>>>
>>>  The MPL forwarder generates and transmits a new ICMPv6 M= PL message
>>>  whenever Trickle requests a transmission.
>>>
>>> UH> So for each data packet there would be a new ICMPv6 mes= sage?
>>> Wouldn't that create a lot of overhead?
>>>
>>> UH> To which address is the ICMP message sent? On which int= erface?
>>>
>>>  The MPL forwarder includes
>>>  an encoding of each sliding window in the ICMPv6 MPL mes= sage.
>>>
>>>  Each sliding window is encoded using an MPL Window entry= , defined in
>>>  Section 5.2.  The MPL forwarder sets the MPL Window= fields as
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>16]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  follows:
>>>
>>>  S  If the MPL seed identifier is 0, set S to 0. &nb= sp;If the MPL seed
>>>     identifier is within the range [1, 65535], set S= to 2.  Otherwise,
>>>     set S to 3.
>>>
>>>  w-min  Set to the lower bound of the sliding window= (i.e.
>>>     WindowMin).
>>>
>>>  w-len  Set to the length of the window (i.e.  = WindowMax - WindowMin).
>>>
>>>  seed-id  If S is non-zero, set to the MPL seed iden= tifier.
>>>
>>>  buffered-mpl-packets  Set each bit that represents = a sequence number
>>>     of a packet in BufferedPackets to 1.  Set a= ll other bits to 0.
>>>     The i'th bit in buffered-mpl-packets represents = a sequence number
>>>     of w-min + i.
>>>
>>> 5.6.  Reception of ICMPv6 MPL Messages
>>>
>>>  An MPL forwarder processes each ICMPv6 MPL message that = it receives
>>>  to determine if it has any new MPL multicast packets to = receive or
>>>  offer.
>>>
>>>  An MPL forwarder determines if a new MPL multicast packe= t has not
>>>  been received from a neighboring node if any of the foll= owing
>>>  conditions hold true:
>>>
>>>  1.  The ICMPv6 MPL message includes an MPL Window f= or an MPL seed
>>>      that does not have a corresponding sliding= window entry on the
>>>      MPL forwarder.
>>>
>>>  2.  The neighbor has a packet in its BufferedPacket= s that has
>>>      sequence value greater than or equal to Wi= ndowMax (i.e. w-min +
>>>      w-len >=3D WindowMax).
>>>
>>>  3.  The neighbor has a packet in its BufferedPacket= s that has
>>>      sequence number within range of the slidin= g window but is not
>>>      included in BufferedPackets (i.e. the i'th= bit in buffered-mpl-
>>>      packets is set to 1, where the sequence nu= mber is w-min + i).
>>>
>>>  When an MPL forwarder determines that it has not yet rec= eived a new
>>>  MPL multicast packet buffered by a neighboring device, t= he MPL
>>>  forwarder resets the Trickle timer associated with react= ive
>>>  propagation.
>>>
>>>  An MPL forwarder determines if an entry in BufferedPacke= ts has not
>>>  been received by a neighboring MPL forwarder if any of t= he following
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>17]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>>  conditions hold true:
>>>
>>>  1.  The ICMPv6 MPL message does not include an MPL = Window for the
>>>      packet's MPL seed.
>>>
>>>  2.  The packet's sequence number is greater than or= equal to the
>>>      neighbor's WindowMax value (i.e. the packe= t's sequence number is
>>>      greater than or equal to w-min + w-len). >>>
>>>  3.  The packet's sequence number is within the rang= e of the
>>>      neighbor's sliding window [WindowMin, Wind= owMax), but not
>>>      included in the neighbor's BufferedPacket = (i.e. the packet's
>>>      sequence number is greater than or equal t= o w-min, strictly less
>>>      than w-min + w-len, and the corresponding = bit in buffered-mpl-
>>>      packets is set to 0.
>>>
>>>  When an MPL forwarder determines that it has at least on= e buffered
>>>  MPL multicast packet that has not yet been received by a= neighbor,
>>>  the MPL forwarder resets the Trickle timer associated wi= th reactive
>>>  propagation.  Additionally, for each buffered MPL m= ulticast packet
>>>  that should be transferred, the MPL forwarder MUST reset= the Trickle
>>>  timer and reset e to 0 for proactive propagation.  = If the Trickle
>>>  timer for proactive propagation has already stopped exec= ution,
>>>
>>> UH> Which timer? I thought there is one timer per packet in= the
>>> proactive mode?
>>>
>>>  the
>>>  MPL forwarder MUST initialize a new Trickle timer and st= art execution
>>>  of the Trickle algorithm.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>18]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 6.  MPL Parameters
>>>
>>>  An MPL forwarder maintains two sets of Trickle parameter= s for the
>>>  proactive and reactive methods.  The Trickle parame= ters are listed
>>>  below:
>>>
>>>  PROACTIVE_IMIN  The minimum Trickle timer interval,= as defined in
>>>     [RFC6206] for proactive propagation.
>>>
>>>  PROACTIVE_IMAX  The maximum Trickle timer interval,= as defined in
>>>     [RFC6206] for proactive propagation.
>>>
>>>  PROACTIVE_K  The redundancy constant, as defined in= [RFC6206] for
>>>     proactive propagation.
>>>
>>>  PROACTIVE_TIMER_EXPIRATIONS  The number of Trickle = timer expirations
>>>     that occur before terminating the Trickle algori= thm.  MUST be set
>>>     to a value greater than 0.
>>>
>>>  REACTIVE_IMIN  The minimum Trickle timer interval, = as defined in
>>>     [RFC6206] for reactive propagation.
>>>
>>>  REACTIVE_IMAX  The maximum Trickle timer interval, = as defined in
>>>     [RFC6206] for reactive propagation.
>>>
>>>  REACTIVE_K  The redundancy constant, as defined in = [RFC6206] for
>>>     reactive propagation.
>>>
>>>  REACTIVE_TIMER_EXPIRATIONS  The number of Trickle t= imer expirations
>>>     that occur before terminating the Trickle algori= thm.  MAY be set
>>>     to 0, which disables reactive propagation.
>>>
>>>  WINDOW_HOLD_TIME  The minimum lifetime for sliding = window state.
>>>
>>>
>>> UH> I don't see any recommendations for these values. That = is
>>> typically requested in the IESG evaluation for standards track=
>>> documents (either default values and/or guideslines on the val= ues).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>19]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 7.  Acknowledgements
>>>
>>>  The authors would like to acknowledge the helpful commen= ts of Robert
>>>  Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, = Joseph Reddy,
>>>  Dario Tedeschi, and Peter van der Stok, which greatly im= proved the
>>>  document.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>20]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 8.  IANA Considerations
>>>
>>>  The Trickle Multicast option requires an IPv6 Option Num= ber.
>>>
>>>
>>>
>>>  HEX         act  chg  rest=
>>>  ---         ---  ---  ----= -
>>>    C          01   &nb= sp;0  TBD
>>>
>>>
>>>
>>>  The first two bits indicate that the IPv6 node MUST disc= ard the
>>>  packet if it doesn't recognize the option type, and the = third bit
>>>  indicates that the Option Data MUST NOT change en-route.=
>>>
>>>
>>> UH> That does not look like a valid IANA section. RFC 5226 = give some
>>> good guidelines.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>21]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 9.  Security Considerations
>>>
>>>  TODO.
>>>
>>>
>>> UH> This document needs a security considerations section. = Refer to RFC
>>> 3552.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>22]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> 10.  References
>>>
>>> 10.1.  Normative References
>>>
>>>  [RFC1982]  Elz, R. and R. Bush, "Serial Number Arit= hmetic", RFC 1982,
>>>             August 1996.
>>>
>>>  [RFC2119]  Bradner, S., "Key words for use in RFCs = to Indicate
>>>             Requirement Levels",= BCP 14, RFC 2119, March 1997.
>>>
>>>  [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2= 328, April 1998.
>>>
>>>  [RFC2460]  Deering, S. and R. Hinden, "Internet Pro= tocol, Version 6
>>>             (IPv6) Specification= ", RFC 2460, December 1998.
>>>
>>>  [RFC2473]  Conta, A. and S. Deering, "Generic Packe= t Tunneling in
>>>             IPv6 Specification",= RFC 2473, December 1998.
>>>
>>>  [RFC4443]  Conta, A., Deering, S., and M. Gupta, "I= nternet Control
>>>             Message Protocol (IC= MPv6) for the Internet Protocol
>>>             Version 6 (IPv6) Spe= cification", RFC 4443, March 2006.
>>>
>>>  [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali= , O., and J. Ko,
>>>             "The Trickle Algorit= hm", RFC 6206, March 2011.
>>>
>>>  [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui= , J., Kelsey, R.,
>>>             Levis, P., Pister, K= ., Struik, R., Vasseur, JP., and R.
>>>             Alexander, "RPL: IPv= 6 Routing Protocol for Low-Power and
>>>             Lossy Networks", RFC= 6550, March 2012.
>>>
>>> 10.2.  Informative References
>>>
>>>  [I-D.ietf-roll-terminology]
>>>             Vasseur, J., "Termin= ology in Low power And Lossy
>>>             Networks", draft-iet= f-roll-terminology-06 (work in
>>>             progress), September= 2011.
>>>
>>> UH> That document is never actually cited. Also, it has not= been
>>> updated in over a year.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>23]
>>> Internet-Draft              = ;       MPL               =        October
>>>2012
>>>
>>>
>>> Authors' Addresses
>>>
>>>  Jonathan W. Hui
>>>  Cisco
>>>  170 West Tasman Drive
>>>  San Jose, California  95134
>>>  USA
>>>
>>>  Phone: +408 424 1547
>>>  Email: jonhui@cisco.co= m
>>>
>>>
>>>  Richard Kelsey
>>>  Silicon Labs
>>>  25 Thomson Place
>>>  Boston, Massachusetts  02210
>>>  USA
>>>
>>>  Phone: +617 951 1225
>>>  Email: richar= d.kelsey@silabs.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hui & Kelsey             Exp= ires April 22, 2013                [= Page
>>>24]
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>>



= --B_3434354689_320905-- From rstruik.ext@gmail.com Mon Oct 29 11:27: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 8BBCD21F8702; Mon, 29 Oct 2012 11:27:21 -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 K+0dQastVC0S; Mon, 29 Oct 2012 11:27:20 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0AA21F8741; Mon, 29 Oct 2012 11:27:20 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so2498278iak.31 for ; Mon, 29 Oct 2012 11:27:20 -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=ZP0ZjHkgf2qXokPgKLLVaDLCbP40pLS5VeHiSiZ6jJ8=; b=SvsMxLfHIMPYNTsFbPjzpmP3tHSiCFW214n8WSQyK0Ukvgru7Y88hl82lIHPaelAuf yK5sdzbA2gCdE3qU2R/yrTlcYREhX8Wr9XAtGodypTvUdrwtGBLDbtaIdMUpw6FM8V0f d12zph5zkoc+Fb+Oeolwi2hlc5iYkkZdqzQHxkSLlYSF+IvYRT20oUXSHpADdDtfOSPg DcdvjM4uZgN4wzNJgBeSFSTFjlwKVvRq2a0iWdny3BSHYq1JtY1X9rbx/dw5iVhPXIUI EdGrPCbZKR6X3YEQUgFEzsNab5n5Oor4LoS9TFYxVPQFbtcj2C8LyO1DngYfoR5w/Taw jyTg== Received: by 10.50.154.227 with SMTP id vr3mr10433261igb.43.1351535239877; Mon, 29 Oct 2012 11:27:19 -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 uz1sm6583031igb.16.2012.10.29.11.27.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 11:27:19 -0700 (PDT) Message-ID: <508ECA68.4030402@gmail.com> Date: Mon, 29 Oct 2012 14:26:48 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: QIU Ying References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> In-Reply-To: <02a001cdb5ee$e34164d0$a9c42e70$@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: Mon, 29 Oct 2012 18:27:22 -0000 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 From dat@exegin.com Mon Oct 29 12:07: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 2142421F8514 for ; Mon, 29 Oct 2012 12:07: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 ijwFn8v0-hh6 for ; Mon, 29 Oct 2012 12:07:44 -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 79A5521F84E4 for ; Mon, 29 Oct 2012 12:07:44 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4379884pbb.31 for ; Mon, 29 Oct 2012 12:07:44 -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:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=uzZz/NXgM4g9xVvKp77viuROluhDwHHAdc3axuEi8bc=; b=QPC+i5JfYQelN801tzhlR4gkbNIJ5V2hcfWw1rBg2FmxMW61yXK3IuTa0vkm4OXh7t 0oqKi6tQ2BwDo9LVzvMH4sxAewZgnyKiWybVrEsDrlCjdX8Tlf4sxWvo6VVyzi6jZRpU QEbJJC9mNtvK14blAj7M6RpDiQ5Cx8dwvlDuqmuwFZy3clgcBfr6grQRTJhju7PLShRA FUZdwRnX9H7Kt9CuKUD6nyYi1DsHhoZ/Y/TD87NHWVG6KREntdbwtbt5YP1PeKrMJvEo 666v4ZSeQnAqWlnimsrGTDlfhY4jofptGqUG9HiPzjuuC/sWmn6aVA33crhV3vrnVnQU 1AHw== Received: by 10.66.88.197 with SMTP id bi5mr85308990pab.58.1351537664101; Mon, 29 Oct 2012 12:07:44 -0700 (PDT) Received: from [172.16.16.110] ([184.71.143.130]) by mx.google.com with ESMTPS id ht5sm6397455pbc.18.2012.10.29.12.07.42 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 12:07:42 -0700 (PDT) Message-ID: <508ED3E6.3080704@exegin.com> Date: Mon, 29 Oct 2012 12:07:18 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkXtGjEnrAXNKIl3e9Ri3lI681YTaH6BTuBpZ+CoSNoTF7qtNG7flQPI3BYkVm9tY4RYiMv 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, 29 Oct 2012 19:07:45 -0000 I think others have covered most of what I wanted to say, but there is one point I want to highlight. The issue relates to the following text: A scope larger than link-local MAY be used only when that scope corresponds exactly to the 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. One solution might be for a RPL root to advertise RIOs (in its DIOs), that give the multicast prefixes reachable outside of the RPL/MPL Domain. For example, a RPL root could advertise FF05::/16 to effectively indicate that site-local scope is wider than just the RPL Domain and that a router should encapsulate site-local multicasts, whether forwarding or sourcing them. Other multicasts could be sent un-encapsulated, however an implementation may still choose to encapsulate all non-link-local multicasts. Of course, all this would be greatly simplified if IPv6-in-IPv6 encapsulation of non-link-local multicasts was made mandatory within a "non-storing RPL domain" (MPL domain). Then there would be only one way to forward multicasts within such a domain and there would be no need for additional routing information. - Dario On 12-10-24 11:55 PM, JP Vasseur (jvasseur) wrote: > Dear all, > > 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 > 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 > and copy the mailing list and the co-chairs. > > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From stephen.farrell@cs.tcd.ie Mon Oct 29 13: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 6C5A921F871D; Mon, 29 Oct 2012 13:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 wPjbcul9PEef; Mon, 29 Oct 2012 13:46:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4E321F870C; Mon, 29 Oct 2012 13:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7434FC77B; Mon, 29 Oct 2012 20:46:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pp2h1LZO0hf; Mon, 29 Oct 2012 20:45:59 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4325CBE25; Mon, 29 Oct 2012 20:45:59 +0000 (GMT) Message-ID: <508EEB07.8080807@cs.tcd.ie> Date: Mon, 29 Oct 2012 20:45:59 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Michael Richardson 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> In-Reply-To: <10703.1351542774@obiwan.sandelman.ca> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , roll@ietf.org, "'Keoh, Sye Loong'" , saag@ietf.org, "Turner, Sean P." , 6lowpan@ietf.org Subject: Re: [Roll] 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: Mon, 29 Oct 2012 20:46:25 -0000 Hiya, 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. 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. Cheers, S. On 10/29/2012 08:32 PM, Michael Richardson wrote: > >>>>>> "Stephen" == Stephen Farrell writes: > Stephen> Would it be timely to spend 10 minutes on this during the saag > Stephen> session? > > 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: > > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/slides/Cullen1.pdf > > Stephen> I'd really like that the security area not end up being surprised > Stephen> by whatever is eventually decided so getting a presentation at > 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 someone > Stephen> who e.g. points out significant security issues. > > Except that: > 1) the constrained devices are more constrained than the IP phones > described. > > 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" > > 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. > > 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. > > Stephen> It might be that waiting another meeting cycle or two would be > Stephen> better if the basic ideas aren't yet firmed up. > > One meeting cycle won't help. Four might. > From cabo@tzi.org Mon Oct 29 14:16:32 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 D83AD21F86E7; Mon, 29 Oct 2012 14:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.337 X-Spam-Level: X-Spam-Status: No, score=-107.337 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 p-OZ9WrV6y4B; Mon, 29 Oct 2012 14:16:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D721F86E1; Mon, 29 Oct 2012 14:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9TLFdsf029404; Mon, 29 Oct 2012 22:15:39 +0100 (CET) Received: from [192.168.217.105] (p54891A96.dip.t-dialin.net [84.137.26.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B04D194; Mon, 29 Oct 2012 22:15:38 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <508EEB07.8080807@cs.tcd.ie> Date: Mon, 29 Oct 2012 22:15:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AF21C42-1B84-4CD1-9904-AF4CA1AB16B5@tzi.org> 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> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) Cc: Cullen Jennings , roll@ietf.org, "'Keoh, Sye Loong'" , saag@ietf.org, "Turner, Sean P." , 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: Mon, 29 Oct 2012 21:16:33 -0000 On Oct 29, 2012, at 21:45, Stephen Farrell = wrote: > If he and Cullen want to arm-wrestle > that's fine:-) Well, Cullen's I-D (please have a look at = draft-jennings-core-transitive-trust-enrollment-01.txt,.pdf) is a very good example for the kind of input document that we are = looking for. But it is just one way of doing things. There are so many others. To a = large extent, the differences are not just based on technological = choices, but on what people are actually trying to do with the smart = objects, i.e., what purpose in life they have. After half a decade of kicking around half-baked solutions in this space = in various IETF working groups, I think it is a good idea to spend more = time understanding the design space. How, and where, to spend this time = in the most productive way is what I would like to discuss with = interested people before we do the SAAG slot: -> solace@ietf.org Gr=FC=DFe, Carsten PS. Here is section 3.3 of the CoRE roadmap I-D, which lists a couple = more related drafts: Several individual drafts analyze the issues around the security of constrained devices in constrained networks. | draft-garcia-core-security | | 2012-03-26 | | draft-sarikaya-core-sbootstrapping | -05 | 2012-07-10 | | draft-jennings-core-transitive-trust-enrollment | -01 | 2012-10-13 | [I-D.garcia-core-security] in particular describes the "Thing Lifecycle" and discusses resulting architectural considerations. [I-D.jennings-core-transitive-trust-enrollment] demonstrates a specific approach to securing the Thing Lifecycle based on defined roles of security players, including a Manufacturer, an Introducer, and a Transfer Agent. Further work around Thing Lifecycles is also expected to occur in the SOLACE initiative (Smart Object Lifecycle Architecture for Constrained Environments), with its early mailing list at solace@ietf.org -- developed after the model of the COMAN initiative (Management for Constrained Management Networks and Devices, coman@ietf.org, [I-D.ersue-constrained-mgmt]). From pal@cs.stanford.edu Mon Oct 29 15:09: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 A020921F871A for ; Mon, 29 Oct 2012 15:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvdgqes-2Q5r for ; Mon, 29 Oct 2012 15:09:50 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8621F8712 for ; Mon, 29 Oct 2012 15:09:50 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[10.111.222.25]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TSxWl-0003uU-C0; Mon, 29 Oct 2012 15:09:47 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <508AE1F9.1080600@merl.com> Date: Mon, 29 Oct 2012 15:09:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AAE0D.8030903@merl.com> <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AE1F9.1080600@merl.com> To: Jianlin Guo X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 55257a1a0ec20502294a0e86bc6a08bd Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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, 29 Oct 2012 22:09:51 -0000 I'd like to take a step back here and discuss MaxRankIncrease and the = notion of null parent sets. The two major cases where a RPL node has a null parent set are: 1) The node has no members in its neighbor set 2) The node has members of its neighbor set, but all of them advertise = a Rank of INFINITE_RANK. The major case we're concerned about here is = when rule 3 of 8.2.2.4 requires nodes to advertise INFINITE_RANK due to = the value of MaxRankIncrease. I don't think the local repair scheme will fix case 1. So we're really = talking about case 2.=20 MaxRankIncrease emerged in specifying RPL as a way to support both = ZigBee-style centralized periodic tree reconstruction triggers = (MaxRankIncrease =3D=3D 0) as well as CTP-style completely distributed = operation while simultaneously providing a cap to the count-to-infinity = problem. So really, the issue here is when you have a network with a = small MaxRankIncrease and don't want to reconstruct the entire tree, = there are valid parents that could be used, but a node does not have = them in its neighbor/parent set. Thinking about it this way (am I wrong?), I am a bit confused by the = claim that the draft is a local repair. Assuming a node has to follow = rule 3 in 8.2.2.4, this is not a repair mechanism, but rather a neighbor = discovery mechanism. Could you explain how DRQ/DRP solve a problem that = a DIS with a proper Solicited Information option can't solve? This was = the original intent of DIS with Solicited Information. Or perhaps I'm = not understanding DRQ/DRP correctly? Phil On Oct 26, 2012, at 12:18 PM, Jianlin Guo wrote: > Thank you for the paper. I agree with [1] on that "dismantling of the = sub-DAG, rooted at the node doing the rank increase, causes more turmoil = in the network than the routing loops themselves". >=20 > Now, consider a case in which a node's parent set becomes empty. In = this case, RPL provides following set of actions:=20 >=20 > 1) Start its own floating DODAG=20 > 2) Poison the broken path=20 > 3) Trigger a local repair=20 >=20 > Both 1) and 2) actions will increase packet delivery delay time (which = may be not acceptable for some applications) and possibly cause packet = dropping due to limited buffer size of a LLN node (which may also be not = acceptable for some applications). So, trigger a local repair is a = practical option. Our local repair mechanism is designed for this = purpose and it does not create any loops. >=20 > Jianlin >=20 > On 10/26/2012 12:10 PM, C Chauvenet wrote: >>=20 >> Le 26 oct. 2012 =E0 17:36, Jianlin Guo a =E9crit : >>=20 >>> We compared performance metrics such as packet delivery rate. >>=20 >> Ok. >>=20 >> In general do you have a document about your experiments that you = would like to share ? >> I think it could be a good way to defend your mechanism. >>=20 >> There are 2 sub questions related to your draft :=20 >>=20 >> - Is there a strong need for an additional mechanism to prevent = loops ? (the HbH header option mentioned by phil is already there). >> - Is your mechanism the good way to do so (overhead induced, = efficiency...) >>=20 >> As mentioned by Phil, this subject has been previously discussed = inside ROLL few years ago, and did not recommend to add such mechanisms. >>=20 >> For instance, [1] concludes that=20 >>=20 >> "the turmoil caused >> by dismantling of the sub-DAGs in order to increase ranks >> may be much more than what the routing loops themselves >> will cause. Consequently, the use of such loop avoidance >> mechanism in the operation of a DAG based routing protocol >> can not be universally recommended." >>=20 >> [1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf >>=20 >> Best, >>=20 >> C=E9dric. >>=20 >>> On 10/26/2012 11:21 AM, C Chauvenet wrote: >>>> Hi, >>>> Thank you for your answer. >>>> See inline. >>>>=20 >>>> Le 26 oct. 2012 =E0 15:27, Jianlin Guo a =E9crit : >>>>=20 >>>>> On 10/25/2012 12:06 PM, C Chauvenet wrote: >>>>>> Hi,=20 >>>>>>=20 >>>>>> Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit : >>>>>>=20 >>>>>>> Hi Michael, >>>>>>>=20 >>>>>>> For your first question, draft-clausen-lln-rpl-experiences-04 = pointed out that "it can be observed that with current implementations = of RPL, such as the ContikiRPL = implementation, loops do occur - and, frequently. During the same = experiments described in Section 13, a snapshot of the DODAG was made = every ten seconds. In 74.14% of the 4114 snapshots, at least one loop = was observed". >>>>>>=20 >>>>>> Is it something that you observed in your own deployments ? >>>>>> More specifically : did you find similar results ?=20 >>>>> We observed the occurrence of loops, unfortunately we did not = measure the percentage. >>>>=20 >>>> So how did you evaluate the benefit of the mechanism that you = proposed ? >>>>=20 >>>> C=E9dric. >>>>=20 >>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>>>=20 >>>>>>> For your second question, further investigation and experiments = are needed. >>>>>>>=20 >>>>>>> Jianlin >>>>>>>=20 >>>>>>> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>>>>>>> Jianlin Guo >>>>>>>> wrote: >>>>>>>> JG> Dear ROLL WG members, >>>>>>>>=20 >>>>>>>> JG> As we all know that loop is an open issue in RPL. = Experiment shows that loop >>>>>>>> JG> occurs quite often. We have proposed a loop free local = DODAG >>>>>>>>=20 >>>>>>>> Can you quantify "quite often"? >>>>>>>> Do you have any metrics for how often loops occur, and what the = cost is >>>>>>>> of their repair? >>>>>>>>=20 >>>>>>>> I think that the WG would be very very very interested in = additional -experiences >>>>>>>> draft, or pointers to papers explaining same, that gives a = repeateable >>>>>>>> experiment in which loops are observed. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Mon Oct 29 19:14: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 9697321F85E0 for ; Mon, 29 Oct 2012 19:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.005 X-Spam-Level: * X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_CHARSET_FARAWAY=2.45, 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 CAFQvK9FSMnL for ; Mon, 29 Oct 2012 19:14:09 -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 9ABBE21F85D4 for ; Mon, 29 Oct 2012 19:14:09 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4585520pbb.31 for ; Mon, 29 Oct 2012 19:14:09 -0700 (PDT) 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=VFzCH5q+magzZefKVosrky5PwDvO3zFrIBWl52IW9qM=; b=O4vyzePtQfAVqCIzh5J6DSPv3o19PUyCQw+s8KDp6AhkwPds6qwrZcFHg8qypxORI3 vQTBcAn87jsgm6axdC4lBn6T9B7nQKkzA/CU0LYxYw5yI9wSsOxSeaWl8USH5rGmchFr xSM5MB/I46iFzNIPVuLC1b8hMkdujlBI0JCOQeoFB7hRP2ziS8ADoEmV+QlOafDBkE4P kzJZNi4ok00qv/EFFaiQy98qdyW5eF+1e4Foeh5h00afiTZLCbjr5HeZHTTxeQSVwKf/ x+6/cCsj+2adlvnAPTTRQsWXx5kioT2aaLvGwU1Z6/c/FUIxPaDHp9E99vHmSt9B1MoX V+ZQ== Received: by 10.68.212.6 with SMTP id ng6mr97120662pbc.57.1351563249438; Mon, 29 Oct 2012 19:14:09 -0700 (PDT) Received: from [10.211.10.10] ([129.254.38.231]) by mx.google.com with ESMTPS id t1sm6877437paw.11.2012.10.29.19.14.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 19:14:07 -0700 (PDT) Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: JeongGil Ko In-Reply-To: Date: Tue, 30 Oct 2012 11:14:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <191F1E5D-977D-4381-85DE-148EF33C7DFA@gmail.com> References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1499) Cc: =?euc-kr?B?sO3BpLHm?= , "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 02:14:10 -0000 Dear WG Chairs, For some reason... this email seems to be ignored=A1=A6 any responses?=20= -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 26, 2012, at 9:39 PM, =C1=A4=C1=BE=BC=F6 = wrote: > JP, >=20 > John has requested a slot. But we've not been replied anything. Is the = agenda already fixed? >=20 > Regards, > -Jongsoo >=20 > 2012. 10. 25., =BF=C0=C0=FC 6:41, JeongGil Ko = =C0=DB=BC=BA: >=20 >>=20 >> JP, >>=20 >> I've also put in a request for a slot at the meeting in Atlanta for = presenting "draft-ko-roll-mix-network-pathology" but I do not see this = on the agenda. This draft discusses about a critical and practical = performance issue of RPL networks (both collection and downwards) when = they are intentionally or accidentally deployed with devices of = different MOPs. I believe that such an issue is important to discuss as = a group. >>=20 >> Thanks. >>=20 >> -John >>=20 >> ------ >> JeongGil Ko, Ph.D. >> Researcher >> Electronics and Telecommunications Research Institute (ETRI) >> http://sites.google.com/site/jeonggilko/ >>=20 >> On Oct 25, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote: >>=20 >>> Dear all, >>>=20 >>> please find bellow the draft agenda for ROLL's WG meeting in Atlanta = - let us know if you have any comment: >>>=20 >>> 1) Agenda/admin (Chairs - 5mn) [5] >>>=20 >>> 2) WG Status (Chairs - 10 mn) [15] >>>=20 >>> 3) Security Framework and Applicability Statement template >>> (Michael - 10m) [25] >>> draft=3Ddraft-richardson-roll-applicability-template-00 >>>=20 >>> 4) RPL applicability in industrial networks >>> draft-phinney-roll-rpl-industrial-applicability-01 >>> (Pascal - 10mn) [35] >>>=20 >>> 5) Industrial Deterministic Routing Extension for Low-Power >>> and Lossy Networks (M. Wei - 10mn) [45] >>>=20 >>> 6) RPL deployment experience in large scale networks >>> draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >>>=20 >>> 7) RPL applicability in industrial networks >>> draft-phinney-roll-rpl-industrial-applicability-01 >>> (Pascal - 10mn) [60] >>>=20 >>> 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] >>> draft-guo-roll-loop-free-dodag-repair >>>=20 >>> Thanks. >>>=20 >>> JP and Michael. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Mon Oct 29 20:13: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 6673721F85C5 for ; Mon, 29 Oct 2012 20:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_QP_LONG_LINE=1.396, 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 TJMaI5ghkg0Q for ; Mon, 29 Oct 2012 20:13:26 -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 EE15B21F84FD for ; Mon, 29 Oct 2012 20:13:21 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3788288pad.31 for ; Mon, 29 Oct 2012 20:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=iYHTrYYXglXhF/cnXESaMlaKbWb06S/wQOsB6rrKtU4=; b=tH3zsC3GOQ4kWRBc/VdjLeXIyuCgl77VhXApPLf55MWQPJY36T8A13I4bCrE59p1Gx 0KcpVuIRMFuFshTVcf/Nqvnwxjjr81EaKTZ+TOyvdZ9TBpgNX/qr9mJH3tTU+AXIfxvA cTLy9ium+IiouVSI4CMKF7y5mRLmogAjCxcnE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=iYHTrYYXglXhF/cnXESaMlaKbWb06S/wQOsB6rrKtU4=; b=gzy/Iejq8flmZl/aTfgxK9SwChvpS5vWpxirQZC0kr2unmMa2BFVdN03xIq1+BHGAZ DXi173uZghHxm8cCFxI4IUBExImnN1diUIERUc4H7mI+mPf/adJGiiS7NucJE0c3s6px B5RqcVd0sGMMf1lnu9DEBLaLoHxEYebZfvJREkOGhHmygt1G6AAwXXgvaoilJyJexEYc KDadMrErdVF/3n4FRf6mS+1ujNthbCIwTVZq8Rzk20wrjS9dfU6XLlFv19LalzxtGyBD 1wP/9St1E1vpW6AnWT5QfFOR4Dg2mGl+Z7ppT44hSfWQkGPJ+qkfk0wnUgdI89pVv6d0 jXBA== Received: by 10.66.86.65 with SMTP id n1mr88679346paz.48.1351566801651; Mon, 29 Oct 2012 20:13:21 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id vc2sm6973214pbc.64.2012.10.29.20.13.19 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 20:13:20 -0700 (PDT) References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Mon, 29 Oct 2012 20:13:23 -0700 To: "JP Vasseur (jvasseur)" X-Gm-Message-State: ALoCoQlT9dNzBN1VUPb7WM8JzQKOihfzT/vZ9n1BGBnd0iZAjzeyOXymTrbOHtNTXGvadpcy51Ua Cc: "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 03:13:27 -0000 Hi, item 4 and 7 are the same. Best Ulrich On Oct 24, 2012, at 11:06, "JP Vasseur (jvasseur)" wrot= e: > Dear all, >=20 > please find bellow the draft agenda for ROLL's WG meeting in Atlanta - let= us know if you have any comment: >=20 > 1) Agenda/admin (Chairs - 5mn) [5] >=20 > 2) WG Status (Chairs - 10 mn) [15] >=20 > 3) Security Framework and Applicability Statement template > (Michael - 10m) [25] > draft=3Ddraft-richardson-roll-applicability-template-00 >=20 > 4) RPL applicability in industrial networks > draft-phinney-roll-rpl-industrial-applicability-01 > (Pascal - 10mn) [35] >=20 > 5) Industrial Deterministic Routing Extension for Low-Power > and Lossy Networks (M. Wei - 10mn) [45] >=20 > 6) RPL deployment experience in large scale networks > draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >=20 > 7) RPL applicability in industrial networks > draft-phinney-roll-rpl-industrial-applicability-01 > (Pascal - 10mn) [60] >=20 > 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] > draft-guo-roll-loop-free-dodag-repair >=20 > Thanks. >=20 > JP and Michael. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 29 23:06: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 D18C121F84A1 for ; Mon, 29 Oct 2012 23:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.445 X-Spam-Level: X-Spam-Status: No, score=-8.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 lV8r9VNDuXX6 for ; Mon, 29 Oct 2012 23:06:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 999C721F8499 for ; Mon, 29 Oct 2012 23:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1423; q=dns/txt; s=iport; t=1351577186; x=1352786786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q9by9s8M1CfYgG4io8/TfkjefAbz/O6By1oELqoqaqg=; b=A/2yOzMeuBhrxhZAAk+1BXK6Ut0bG4VRa+hWev+4Kz+XPjE6jlyMAoOT zP7AtxwQSrU3p1nL0970MakCnzuJSMCOOG4jxFjEzyoc1+i167ZYDcVco 1olPGpY+vEw0nlthexW9RNjj6SMEcZ3GkV1p5Q80p769jKTvRg0eFb1x4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACVtj1CtJXG9/2dsb2JhbABEw0OBCIIeAQEBAwEBAQEPASc0CwULAgEIGAoUECcLJQIEDgUIGodeBgucII9nkBwEi3UbhWFhA6RLgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="136739655" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 30 Oct 2012 06:06:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9U66Pka010423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 06:06:25 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 01:06:25 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [Roll] Draft Agenda Thread-Index: AQHNshI/1lX/Rsr9DkGoyi2Nck5zRw== Date: Tue, 30 Oct 2012 06:06:25 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772203E4A3@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.226] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--38.167000-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: <5684F610653C3D4684E0CBDE336C5871@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 06:06:27 -0000 Thanks Ulrich. On Oct 30, 2012, at 4:13 AM, Ulrich Herberg wrote: > Hi, >=20 > item 4 and 7 are the same. >=20 > Best > Ulrich >=20 > On Oct 24, 2012, at 11:06, "JP Vasseur (jvasseur)" w= rote: >=20 >> Dear all, >>=20 >> please find bellow the draft agenda for ROLL's WG meeting in Atlanta - l= et us know if you have any comment: >>=20 >> 1) Agenda/admin (Chairs - 5mn) [5] >>=20 >> 2) WG Status (Chairs - 10 mn) [15] >>=20 >> 3) Security Framework and Applicability Statement template >> (Michael - 10m) [25] >> draft=3Ddraft-richardson-roll-applicability-template-00 >>=20 >> 4) RPL applicability in industrial networks >> draft-phinney-roll-rpl-industrial-applicability-01 >> (Pascal - 10mn) [35] >>=20 >> 5) Industrial Deterministic Routing Extension for Low-Power >> and Lossy Networks (M. Wei - 10mn) [45] >>=20 >> 6) RPL deployment experience in large scale networks >> draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >>=20 >> 7) RPL applicability in industrial networks >> draft-phinney-roll-rpl-industrial-applicability-01 >> (Pascal - 10mn) [60] >>=20 >> 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] >> draft-guo-roll-loop-free-dodag-repair >>=20 >> Thanks. >>=20 >> JP and Michael. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 29 23:45: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 9752C21F84C1 for ; Mon, 29 Oct 2012 23:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=-2.252, BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 FYQNuZmUZhSR for ; Mon, 29 Oct 2012 23:45:00 -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 A686721F84BD for ; Mon, 29 Oct 2012 23:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4308; q=dns/txt; s=iport; t=1351579500; x=1352789100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lCP74ArJjgqix0BiXLR8Zcki+KwrryHLmLFYfF+q2eU=; b=e3EQ0qvSSAJyuaKG6eAUSZopDzjA7AFph7idsIClF9GdUybRRA0SngHH FIilGvwIjHWC0JEKjs6elMPQZoAUli5vRsFlm+aFy70jktf3C0hRPdfGe 7QngCXAbVOuE2rJXx8iBbob45iztB60Z7OQ2MriF91Vq2H487vqDDmGfl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHB2j1CtJXG+/2dsb2JhbABEhhi8LXOBCIIeAQEBAwEBAQEPASE6CwULAgEGAhgEBiICAiULJQIEAQ0FCBqHXgYLnB+NJQWCPZAegRuKWhuFKjdhA5cOjT2Ba4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="136805724" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2012 06:45:00 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9U6ix1N023842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 06:44:59 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 01:44:59 -0500 From: "JP Vasseur (jvasseur)" To: JeongGil Ko , =?euc-kr?B?sO3BpLHm?= , =?euc-kr?B?waTBvrz2?= Thread-Topic: [Roll] Draft Agenda Thread-Index: AQHNshI/1lX/Rsr9DkGoyi2Nck5zRw== Date: Tue, 30 Oct 2012 06:44:58 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772203E79B@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> <191F1E5D-977D-4381-85DE-148EF33C7DFA@gmail.com> In-Reply-To: <191F1E5D-977D-4381-85DE-148EF33C7DFA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.226] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--46.734900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="euc-kr" Content-ID: <82F9AB5A1D26EB44B3192C788F498F6A@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 06:45:02 -0000 RGVhciBhbGwsDQoNCk1hbnkgVGhhbmtzIGZvciB5b3VyIGVtYWlsIC0gd2UgZGlkIGRpc2N1c3Mg YWJvdXQgaXQgYnV0IHRoZXJlIHByZXR0eSBtdWNoIG5vIHRyYWN0aW9uIG9uIHRoZSBtYWlsaW5n IGxpc3Qgb24gdGhpcyBpdGVtLg0KUGxlYXNlIGNvbnRpbnVlIHRvIHVzZSB0aGUgbWFpbGluZyBh dCB3aWxsLiBUaGlzIGlzIHdoeSB0aGUgaXRlbSBpcyBub3QgcGFydCBvZiB0aGUgYWdlbmRhIGlu ZGVlZC4NCg0KTWFueSBUaGFua3MuDQoNCkpQIGFuZCBNaWNoYWVsLg0KDQpPbiBPY3QgMzAsIDIw MTIsIGF0IDM6MTQgQU0sIEplb25nR2lsIEtvIHdyb3RlOg0KDQo+IERlYXIgV0cgQ2hhaXJzLA0K PiANCj4gRm9yIHNvbWUgcmVhc29uLi4uIHRoaXMgZW1haWwgc2VlbXMgdG8gYmUgaWdub3JlZKGm IGFueSByZXNwb25zZXM/IA0KPiANCj4gLUpvaG4NCj4gDQo+IC0tLS0tLQ0KPiBKZW9uZ0dpbCBL bywgUGguRC4NCj4gUmVzZWFyY2hlcg0KPiBFbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRp b25zIFJlc2VhcmNoIEluc3RpdHV0ZSAoRVRSSSkNCj4gaHR0cDovL3NpdGVzLmdvb2dsZS5jb20v c2l0ZS9qZW9uZ2dpbGtvLw0KPiANCj4gT24gT2N0IDI2LCAyMDEyLCBhdCA5OjM5IFBNLCDBpMG+ vPYgPGpzamVvbmdAZXRyaS5yZS5rcj4gd3JvdGU6DQo+IA0KPj4gSlAsDQo+PiANCj4+IEpvaG4g aGFzIHJlcXVlc3RlZCBhIHNsb3QuIEJ1dCB3ZSd2ZSBub3QgYmVlbiByZXBsaWVkIGFueXRoaW5n LiBJcyB0aGUgYWdlbmRhIGFscmVhZHkgZml4ZWQ/DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiAtSm9u Z3Nvbw0KPj4gDQo+PiAyMDEyLiAxMC4gMjUuLCC/wMD8IDY6NDEsIEplb25nR2lsIEtvIDxqZW9u Z2dpbC5rb0BldHJpLnJlLmtyPiDA27y6Og0KPj4gDQo+Pj4gDQo+Pj4gSlAsDQo+Pj4gDQo+Pj4g SSd2ZSBhbHNvIHB1dCBpbiBhIHJlcXVlc3QgZm9yIGEgc2xvdCBhdCB0aGUgbWVldGluZyBpbiBB dGxhbnRhIGZvciBwcmVzZW50aW5nICJkcmFmdC1rby1yb2xsLW1peC1uZXR3b3JrLXBhdGhvbG9n eSIgYnV0IEkgZG8gbm90IHNlZSB0aGlzIG9uIHRoZSBhZ2VuZGEuIFRoaXMgZHJhZnQgZGlzY3Vz c2VzIGFib3V0IGEgY3JpdGljYWwgYW5kIHByYWN0aWNhbCBwZXJmb3JtYW5jZSBpc3N1ZSBvZiBS UEwgbmV0d29ya3MgKGJvdGggY29sbGVjdGlvbiBhbmQgZG93bndhcmRzKSB3aGVuIHRoZXkgYXJl IGludGVudGlvbmFsbHkgb3IgYWNjaWRlbnRhbGx5IGRlcGxveWVkIHdpdGggZGV2aWNlcyBvZiBk aWZmZXJlbnQgTU9Qcy4gSSBiZWxpZXZlIHRoYXQgc3VjaCBhbiBpc3N1ZSBpcyBpbXBvcnRhbnQg dG8gZGlzY3VzcyBhcyBhIGdyb3VwLg0KPj4+IA0KPj4+IFRoYW5rcy4NCj4+PiANCj4+PiAtSm9o bg0KPj4+IA0KPj4+IC0tLS0tLQ0KPj4+IEplb25nR2lsIEtvLCBQaC5ELg0KPj4+IFJlc2VhcmNo ZXINCj4+PiBFbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3Rp dHV0ZSAoRVRSSSkNCj4+PiBodHRwOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2plb25nZ2lsa28v DQo+Pj4gDQo+Pj4gT24gT2N0IDI1LCAyMDEyLCBhdCAzOjA2IEFNLCBKUCBWYXNzZXVyIChqdmFz c2V1cikgd3JvdGU6DQo+Pj4gDQo+Pj4+IERlYXIgYWxsLA0KPj4+PiANCj4+Pj4gcGxlYXNlIGZp bmQgYmVsbG93IHRoZSBkcmFmdCBhZ2VuZGEgZm9yIFJPTEwncyBXRyBtZWV0aW5nIGluIEF0bGFu dGEgLSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudDoNCj4+Pj4gDQo+Pj4+IDEp IEFnZW5kYS9hZG1pbiAoQ2hhaXJzIC0gNW1uKSBbNV0NCj4+Pj4gDQo+Pj4+IDIpIFdHIFN0YXR1 cyAoQ2hhaXJzIC0gMTAgbW4pIFsxNV0NCj4+Pj4gDQo+Pj4+IDMpIFNlY3VyaXR5IEZyYW1ld29y ayBhbmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgdGVtcGxhdGUNCj4+Pj4gKE1pY2hhZWwgLSAx MG0pIFsyNV0NCj4+Pj4gZHJhZnQ9ZHJhZnQtcmljaGFyZHNvbi1yb2xsLWFwcGxpY2FiaWxpdHkt dGVtcGxhdGUtMDANCj4+Pj4gDQo+Pj4+IDQpIFJQTCBhcHBsaWNhYmlsaXR5IGluIGluZHVzdHJp YWwgbmV0d29ya3MNCj4+Pj4gZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxp Y2FiaWxpdHktMDENCj4+Pj4gKFBhc2NhbCAtIDEwbW4pIFszNV0NCj4+Pj4gDQo+Pj4+IDUpIElu ZHVzdHJpYWwgRGV0ZXJtaW5pc3RpYyBSb3V0aW5nIEV4dGVuc2lvbiBmb3IgTG93LVBvd2VyDQo+ Pj4+IGFuZCBMb3NzeSBOZXR3b3JrcyAoTS4gV2VpIC0gMTBtbikgWzQ1XQ0KPj4+PiANCj4+Pj4g NikgUlBMIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBpbiBsYXJnZSBzY2FsZSBuZXR3b3Jrcw0KPj4+ PiBkcmFmdC1odWktdmFzc2V1ci1yb2xsLXJwbC1kZXBsb3ltZW50IChUQkQgLSA1bW4pIFs1MF0N Cj4+Pj4gDQo+Pj4+IDcpIFJQTCBhcHBsaWNhYmlsaXR5IGluIGluZHVzdHJpYWwgbmV0d29ya3MN Cj4+Pj4gZHJhZnQtcGhpbm5leS1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHktMDEN Cj4+Pj4gKFBhc2NhbCAtIDEwbW4pIFs2MF0NCj4+Pj4gDQo+Pj4+IDgpIExvb3AgRnJlZSBET0RB RyBMb2NhbCBSZXBhaXIgKEppYW5saW4gR3VvIC0gMTBtbikgWzcwXQ0KPj4+PiBkcmFmdC1ndW8t cm9sbC1sb29wLWZyZWUtZG9kYWctcmVwYWlyDQo+Pj4+IA0KPj4+PiBUaGFua3MuDQo+Pj4+IA0K Pj4+PiBKUCBhbmQgTWljaGFlbC4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+Pj4gUm9sbEBpZXRm Lm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4+ PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+ IFJvbGxAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbA0KPiANCg0K From jeonggil.ko@gmail.com Tue Oct 30 00:50: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 9EA1021F84A2 for ; Tue, 30 Oct 2012 00:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.995 X-Spam-Level: X-Spam-Status: No, score=-98.995 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, 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 2vXfsd0b5XB9 for ; Tue, 30 Oct 2012 00:50:37 -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 E196A21F841A for ; Tue, 30 Oct 2012 00:50:36 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so3939180pad.31 for ; Tue, 30 Oct 2012 00:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JE4wPDXNemkDvZqhSdx0HpgzIrbVVGjngjl475Bp7f0=; b=FE3o1PnaWxyS0MZdk6s6YGhumXJbW796VVMoS8IxaQ8dXpL/Q8VstCscHA9GFsEr5W 8afGsCPYOVyOcwKXBYhtDvY4irc2dE/6KkZoQUB+OqXyfKnrlNeJTbUQDfaM25Ar9zZ/ XY50+pNZJ1B/WRwawdJAZWQTrHVMR5VOrJlXK8N0nQRKOkJy2jPOZf6CyAP5RGXimncL ZJeYDoaBoQcpkpa2547zVN+d33MiKfXX4RVWYV78yQ1yzJ6FqQEvUNHvVpW6Kc6sKhnx F7CBVjaKcDvkZ3E9u3KVye2LkkIIJmxN4AYkGIwLpMeFfoletP7bnu8BakXnr5dFV8ey U8iw== Received: by 10.68.137.136 with SMTP id qi8mr16431617pbb.148.1351583436596; Tue, 30 Oct 2012 00:50:36 -0700 (PDT) Received: from [10.211.10.10] ([129.254.38.231]) by mx.google.com with ESMTPS id tm8sm145271pbc.48.2012.10.30.00.50.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 00:50:35 -0700 (PDT) Sender: "JeongGil (John) Ko" Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: JeongGil Ko In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772203E79B@xmb-rcd-x02.cisco.com> Date: Tue, 30 Oct 2012 16:50:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <450856EA-1EF9-45A0-8987-3EDAB0EBDE98@etri.re.kr> References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> <191F1E5D-977D-4381-85DE-148EF33C7DFA@gmail.com> <03B78081B371D44390ED6E7BADBB4A772203E79B@xmb-rcd-x02.cisco.com> To: "JP Vasseur (jvasseur)" X-Mailer: Apple Mail (2.1499) Cc: "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 07:50:37 -0000 JP, Thanks for the response. As an author of an Internet draft, I was = waiting for a yes/no or some answer from the WG chairs. We can talk more = about the draft offline at the meeting in Atlanta. Thanks! -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 30, 2012, at 3:44 PM, "JP Vasseur (jvasseur)" = wrote: > Dear all, >=20 > Many Thanks for your email - we did discuss about it but there pretty = much no traction on the mailing list on this item. > Please continue to use the mailing at will. This is why the item is = not part of the agenda indeed. >=20 > Many Thanks. >=20 > JP and Michael. >=20 > On Oct 30, 2012, at 3:14 AM, JeongGil Ko wrote: >=20 >> Dear WG Chairs, >>=20 >> For some reason... this email seems to be ignored=A1=A6 any = responses?=20 >>=20 >> -John >>=20 >> ------ >> JeongGil Ko, Ph.D. >> Researcher >> Electronics and Telecommunications Research Institute (ETRI) >> http://sites.google.com/site/jeonggilko/ >>=20 >> On Oct 26, 2012, at 9:39 PM, =C1=A4=C1=BE=BC=F6 = wrote: >>=20 >>> JP, >>>=20 >>> John has requested a slot. But we've not been replied anything. Is = the agenda already fixed? >>>=20 >>> Regards, >>> -Jongsoo >>>=20 >>> 2012. 10. 25., =BF=C0=C0=FC 6:41, JeongGil Ko = =C0=DB=BC=BA: >>>=20 >>>>=20 >>>> JP, >>>>=20 >>>> I've also put in a request for a slot at the meeting in Atlanta for = presenting "draft-ko-roll-mix-network-pathology" but I do not see this = on the agenda. This draft discusses about a critical and practical = performance issue of RPL networks (both collection and downwards) when = they are intentionally or accidentally deployed with devices of = different MOPs. I believe that such an issue is important to discuss as = a group. >>>>=20 >>>> Thanks. >>>>=20 >>>> -John >>>>=20 >>>> ------ >>>> JeongGil Ko, Ph.D. >>>> Researcher >>>> Electronics and Telecommunications Research Institute (ETRI) >>>> http://sites.google.com/site/jeonggilko/ >>>>=20 >>>> On Oct 25, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> please find bellow the draft agenda for ROLL's WG meeting in = Atlanta - let us know if you have any comment: >>>>>=20 >>>>> 1) Agenda/admin (Chairs - 5mn) [5] >>>>>=20 >>>>> 2) WG Status (Chairs - 10 mn) [15] >>>>>=20 >>>>> 3) Security Framework and Applicability Statement template >>>>> (Michael - 10m) [25] >>>>> draft=3Ddraft-richardson-roll-applicability-template-00 >>>>>=20 >>>>> 4) RPL applicability in industrial networks >>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>> (Pascal - 10mn) [35] >>>>>=20 >>>>> 5) Industrial Deterministic Routing Extension for Low-Power >>>>> and Lossy Networks (M. Wei - 10mn) [45] >>>>>=20 >>>>> 6) RPL deployment experience in large scale networks >>>>> draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >>>>>=20 >>>>> 7) RPL applicability in industrial networks >>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>> (Pascal - 10mn) [60] >>>>>=20 >>>>> 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] >>>>> draft-guo-roll-loop-free-dodag-repair >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP and Michael. >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 From stokcons@xs4all.nl Tue Oct 30 01:35: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 02D6E21F84ED for ; Tue, 30 Oct 2012 01:35:38 -0700 (PDT) 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 UvoBk+A28dOK for ; Tue, 30 Oct 2012 01:35:37 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB5921F84EC for ; Tue, 30 Oct 2012 01:35:36 -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 q9U8Yvdv079996; Tue, 30 Oct 2012 09:34:58 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from [130.138.227.11] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 30 Oct 2012 09:34:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 30 Oct 2012 09:34:57 +0100 From: peter van der Stok To: Don Sturek Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (9UG5F5EjyVqQ3u2sPhI5wwT/QCPb6m8G) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: roll@ietf.org Subject: Re: [Roll] Fwd: Re: 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: Tue, 30 Oct 2012 08:35:38 -0000 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 From d.sturek@att.net Tue Oct 30 04:47:32 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 4867321F851B for ; Tue, 30 Oct 2012 04:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=2.272, 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 3Z+DlgD1k2GI for ; Tue, 30 Oct 2012 04:47:31 -0700 (PDT) Received: from nm15-vm0.access.bullet.mail.mud.yahoo.com (nm15-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.17]) by ietfa.amsl.com (Postfix) with ESMTP id A844C21F851A for ; Tue, 30 Oct 2012 04:47:31 -0700 (PDT) Received: from [66.94.237.197] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 11:47:31 -0000 Received: from [68.142.198.207] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 11:47:31 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 11:47:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351597651; bh=rT4m7d+MBzrTM2gWAz3GoOWih3TWoCZ2km+Vxsm+A4Q=; 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=LvzOPGTLDSpBjHxrTAL1C7lwmrVsO3XY+Lv/NSWIcsJIYiaMOHcl4v/7dLHW3DTbgJj8HDheQZEhgvw42Xl5uhVe03tyMGtYxwPBexNsq3X0mZ4evHiLFyk61+DqZ8/gJyIp1mMMmqezS9COQ7xQq6X1QDeG7NFOl6KdfU1Zp1g= X-Yahoo-Newman-Id: 46302.26535.bm@smtp111.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: UDt01_IVM1llJuNH77ZioAiZbDj2f0Km3uy9ZSd2R00wBrT yKoJkyrrjulyD8N3z.4buQpBqBqHck6ix.I9AXOpSqr7zVi0CPYpJQlKCdH3 bWuVe0NI.NVxRVkDzyYER0fmXCyqarT4uNiva7t8U53kKn2pRw0rsEYAfpwh fueNZsRcBIM9TXRnTXn50wM0HcZQokCUCtwr.xXTXfuMBMKGZ1k_BhUQSkLe 9X78KbUyoai.fdwXA.XPFhHtYHGPafwxiSUxdddkKbf5s6WK10t._qdo_Doo iQ2K_ZT7_9Gn5VDsSO.JRtD5ju6wvdHhejYz5aPyP.4NZdRbt24BvUng584m SdVGEf_LvOJMJun4_N2JWG.8vYnsKSMsN8dCjvl.jcoyRskHffS5dM_Bh26t 8OiKf1BdOobXCZ2N2.DDZ3xMDHS0tqAUre5rpsIaHBWvZS.2NyUeMHiUq4oJ uU17vHehGcJDcf.JuN2g- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.108.50.209 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 30 Oct 2012 04:47:30 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 30 Oct 2012 04:46:13 -0700 From: Don Sturek To: Message-ID: Thread-Topic: [Roll] Fwd: Re: WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Fwd: 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: Tue, 30 Oct 2012 11:47:32 -0000 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 > From pal@cs.stanford.edu Tue Oct 30 08:19: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 250BB21F8596 for ; Tue, 30 Oct 2012 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, MIME_CHARSET_FARAWAY=2.45, 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 qRR+NfLTu3eL for ; Tue, 30 Oct 2012 08:19:35 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4921F858F for ; Tue, 30 Oct 2012 08:19:34 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.106]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTDbG-0001N7-H0; Tue, 30 Oct 2012 08:19:31 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=euc-kr From: Philip Levis In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772203E79B@xmb-rcd-x02.cisco.com> Date: Tue, 30 Oct 2012 08:19:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5678DA35-B4AB-4875-A9AC-EF6A393EBF75@cs.stanford.edu> References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> <191F1E5D-977D-4381-85DE-148EF33C7DFA@gmail.com> <03B78081B371D44390ED6E7BADBB4A772203E79B@xmb-rcd-x02.cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1283) X-Scan-Signature: b78a464e305c82b41dcf341f2fb84a2b Cc: =?utf-8?B?6rOg7KCV6ri4?= , "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 15:19:36 -0000 I'm a little worried that the one draft which is based on a real, = documented problem encountered in a deployment is considered to have "no = traction on the mailing list", despite several discussions, while = "Industrial Deterministic Routing Extension for Low-Power and Lossy = Networks," which I have never seen mentioned on the mailing list (can = someone point out that I'm wrong) does have a slot. This doesn't mean = that the other draft shouldn't have a slot; I just don't understand the = process by which slots are being decided. Phil On Oct 29, 2012, at 11:44 PM, JP Vasseur (jvasseur) wrote: > Dear all, >=20 > Many Thanks for your email - we did discuss about it but there pretty = much no traction on the mailing list on this item. > Please continue to use the mailing at will. This is why the item is = not part of the agenda indeed. >=20 > Many Thanks. >=20 > JP and Michael. >=20 > On Oct 30, 2012, at 3:14 AM, JeongGil Ko wrote: >=20 >> Dear WG Chairs, >>=20 >> For some reason... this email seems to be ignored=A1=A6 any = responses?=20 >>=20 >> -John >>=20 >> ------ >> JeongGil Ko, Ph.D. >> Researcher >> Electronics and Telecommunications Research Institute (ETRI) >> http://sites.google.com/site/jeonggilko/ >>=20 >> On Oct 26, 2012, at 9:39 PM, =C1=A4=C1=BE=BC=F6 = wrote: >>=20 >>> JP, >>>=20 >>> John has requested a slot. But we've not been replied anything. Is = the agenda already fixed? >>>=20 >>> Regards, >>> -Jongsoo >>>=20 >>> 2012. 10. 25., =BF=C0=C0=FC 6:41, JeongGil Ko = =C0=DB=BC=BA: >>>=20 >>>>=20 >>>> JP, >>>>=20 >>>> I've also put in a request for a slot at the meeting in Atlanta for = presenting "draft-ko-roll-mix-network-pathology" but I do not see this = on the agenda. This draft discusses about a critical and practical = performance issue of RPL networks (both collection and downwards) when = they are intentionally or accidentally deployed with devices of = different MOPs. I believe that such an issue is important to discuss as = a group. >>>>=20 >>>> Thanks. >>>>=20 >>>> -John >>>>=20 >>>> ------ >>>> JeongGil Ko, Ph.D. >>>> Researcher >>>> Electronics and Telecommunications Research Institute (ETRI) >>>> http://sites.google.com/site/jeonggilko/ >>>>=20 >>>> On Oct 25, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> please find bellow the draft agenda for ROLL's WG meeting in = Atlanta - let us know if you have any comment: >>>>>=20 >>>>> 1) Agenda/admin (Chairs - 5mn) [5] >>>>>=20 >>>>> 2) WG Status (Chairs - 10 mn) [15] >>>>>=20 >>>>> 3) Security Framework and Applicability Statement template >>>>> (Michael - 10m) [25] >>>>> draft=3Ddraft-richardson-roll-applicability-template-00 >>>>>=20 >>>>> 4) RPL applicability in industrial networks >>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>> (Pascal - 10mn) [35] >>>>>=20 >>>>> 5) Industrial Deterministic Routing Extension for Low-Power >>>>> and Lossy Networks (M. Wei - 10mn) [45] >>>>>=20 >>>>> 6) RPL deployment experience in large scale networks >>>>> draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >>>>>=20 >>>>> 7) RPL applicability in industrial networks >>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>> (Pascal - 10mn) [60] >>>>>=20 >>>>> 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] >>>>> draft-guo-roll-loop-free-dodag-repair >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP and Michael. >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From guo@merl.com Tue Oct 30 09:01: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 B2F8721F85F0 for ; Tue, 30 Oct 2012 09:01:36 -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 7M7X7Qce9ZaV for ; Tue, 30 Oct 2012 09:01:34 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C85621F85A0 for ; Tue, 30 Oct 2012 09:01:34 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9UG1SAA013286; Tue, 30 Oct 2012 12:01:28 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9UG1NrV003184; Tue, 30 Oct 2012 12:01:28 -0400 Message-ID: <508FF9D3.40805@merl.com> Date: Tue, 30 Oct 2012 12:01:23 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Philip Levis References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AAE0D.8030903@merl.com> <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AE1F9.1080600@merl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 30 Oct 2012 16:01:36 -0000 Hi Phil, Thank you for your valuable comments. There may be one more major case where a RPL node has a null parent set, that is, parent node of a RPL node becomes unreachable. This is a typical case in lossy networks. For example, a mobile object could block wireless link between two RPL nodes. The key differences between DIS and DRQ/DRP are: 1) A DRQ message can travel multiple hops. # of hops is controlled by a parameter named MH (Maximum Hop) in DRQ message. 2) Upon receiving a DRQ message, a neighbor node responds with DRP message only if neighbor node has non-empty parent set and a rank lower than rank of the DRQ transmitting node. Otherwise, it may forward DRQ message to its parent node. 3) Receiving of a DRP message guarantees the discovery of a new parent node. 4) Value of MH parameter controls local repair. MH can be set to a small value, e.g. 1,2 or 3, so that DRQ message do not travel too far. Jianlin On 10/29/2012 6:09 PM, Philip Levis wrote: > I'd like to take a step back here and discuss MaxRankIncrease and the notion of null parent sets. > > The two major cases where a RPL node has a null parent set are: > 1) The node has no members in its neighbor set > 2) The node has members of its neighbor set, but all of them advertise a Rank of INFINITE_RANK. The major case we're concerned about here is when rule 3 of 8.2.2.4 requires nodes to advertise INFINITE_RANK due to the value of MaxRankIncrease. > > I don't think the local repair scheme will fix case 1. So we're really talking about case 2. > > MaxRankIncrease emerged in specifying RPL as a way to support both ZigBee-style centralized periodic tree reconstruction triggers (MaxRankIncrease == 0) as well as CTP-style completely distributed operation while simultaneously providing a cap to the count-to-infinity problem. So really, the issue here is when you have a network with a small MaxRankIncrease and don't want to reconstruct the entire tree, there are valid parents that could be used, but a node does not have them in its neighbor/parent set. > > Thinking about it this way (am I wrong?), I am a bit confused by the claim that the draft is a local repair. Assuming a node has to follow rule 3 in 8.2.2.4, this is not a repair mechanism, but rather a neighbor discovery mechanism. Could you explain how DRQ/DRP solve a problem that a DIS with a proper Solicited Information option can't solve? This was the original intent of DIS with Solicited Information. Or perhaps I'm not understanding DRQ/DRP correctly? > > Phil > > On Oct 26, 2012, at 12:18 PM, Jianlin Guo wrote: > >> Thank you for the paper. I agree with [1] on that "dismantling of the sub-DAG, rooted at the node doing the rank increase, causes more turmoil in the network than the routing loops themselves". >> >> Now, consider a case in which a node's parent set becomes empty. In this case, RPL provides following set of actions: >> >> 1) Start its own floating DODAG >> 2) Poison the broken path >> 3) Trigger a local repair >> >> Both 1) and 2) actions will increase packet delivery delay time (which may be not acceptable for some applications) and possibly cause packet dropping due to limited buffer size of a LLN node (which may also be not acceptable for some applications). So, trigger a local repair is a practical option. Our local repair mechanism is designed for this purpose and it does not create any loops. >> >> Jianlin >> >> On 10/26/2012 12:10 PM, C Chauvenet wrote: >>> Le 26 oct. 2012 à 17:36, Jianlin Guo a écrit : >>> >>>> We compared performance metrics such as packet delivery rate. >>> Ok. >>> >>> In general do you have a document about your experiments that you would like to share ? >>> I think it could be a good way to defend your mechanism. >>> >>> There are 2 sub questions related to your draft : >>> >>> - Is there a strong need for an additional mechanism to prevent loops ? (the HbH header option mentioned by phil is already there). >>> - Is your mechanism the good way to do so (overhead induced, efficiency...) >>> >>> As mentioned by Phil, this subject has been previously discussed inside ROLL few years ago, and did not recommend to add such mechanisms. >>> >>> For instance, [1] concludes that >>> >>> "the turmoil caused >>> by dismantling of the sub-DAGs in order to increase ranks >>> may be much more than what the routing loops themselves >>> will cause. Consequently, the use of such loop avoidance >>> mechanism in the operation of a DAG based routing protocol >>> can not be universally recommended." >>> >>> [1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf >>> >>> Best, >>> >>> Cédric. >>> >>>> On 10/26/2012 11:21 AM, C Chauvenet wrote: >>>>> Hi, >>>>> Thank you for your answer. >>>>> See inline. >>>>> >>>>> Le 26 oct. 2012 à 15:27, Jianlin Guo a écrit : >>>>> >>>>>> On 10/25/2012 12:06 PM, C Chauvenet wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit : >>>>>>> >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed". >>>>>>> Is it something that you observed in your own deployments ? >>>>>>> More specifically : did you find similar results ? >>>>>> We observed the occurrence of loops, unfortunately we did not measure the percentage. >>>>> So how did you evaluate the benefit of the mechanism that you proposed ? >>>>> >>>>> Cédric. >>>>> >>>>>>> Best, >>>>>>> >>>>>>> Cédric. >>>>>>> >>>>>>>> For your second question, further investigation and experiments are needed. >>>>>>>> >>>>>>>> Jianlin >>>>>>>> >>>>>>>> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>>>>>>>> Jianlin Guo >>>>>>>>> wrote: >>>>>>>>> JG> Dear ROLL WG members, >>>>>>>>> >>>>>>>>> JG> As we all know that loop is an open issue in RPL. Experiment shows that loop >>>>>>>>> JG> occurs quite often. We have proposed a loop free local DODAG >>>>>>>>> >>>>>>>>> Can you quantify "quite often"? >>>>>>>>> Do you have any metrics for how often loops occur, and what the cost is >>>>>>>>> of their repair? >>>>>>>>> >>>>>>>>> I think that the WG would be very very very interested in additional -experiences >>>>>>>>> draft, or pointers to papers explaining same, that gives a repeateable >>>>>>>>> experiment in which loops are observed. >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing 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 ietf@thomasclausen.org Tue Oct 30 09:14: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 B0C2D21F85EB for ; Tue, 30 Oct 2012 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.285 X-Spam-Level: * X-Spam-Status: No, score=1.285 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, IP_NOT_FRIENDLY=0.334, 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 q677l0gK1RzL for ; Tue, 30 Oct 2012 09:14:51 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EE36C21F85ED for ; Tue, 30 Oct 2012 09:14:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id A6EF5558AD9 for ; Tue, 30 Oct 2012 09:14:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A67C31BDC344; Tue, 30 Oct 2012 09:14:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.80.69.16] (37-8-187-70.coucou-networks.fr [37.8.187.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3B0A61BDC341; Tue, 30 Oct 2012 09:14:45 -0700 (PDT) References: <03B78081B371D44390ED6E7BADBB4A772201ED1C@xmb-rcd-x02.cisco.com> <191F1E5D-977D-4381-85DE-148EF33C7DFA@gmail.com> <03B78081B371D44390ED6E7BADBB4A772203E79B@xmb-rcd-x02.cisco.com> <5678DA35-B4AB-4875-A9AC-EF6A393EBF75@cs.stanford.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <5678DA35-B4AB-4875-A9AC-EF6A393EBF75@cs.stanford.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <898AFBCC-F5E0-4DC5-80C5-E39CAE602C86@thomasclausen.org> X-Mailer: iPhone Mail (10A403) From: Thomas Heide Clausen Date: Tue, 30 Oct 2012 17:14:15 +0100 To: Philip Levis Cc: =?utf-8?B?6rOg7KCV6ri4?= , "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 16:14:52 -0000 I find myself in perfect agreement with Phil here. Note that I neither agree nor disagree with either if the two I-Ds, but I do= think that Phil is right: it's incorrect to say that draft-ko-roll-mix-netw= ork-pathology is not to be discussed for the reason of "no traction on the m= ailing list". Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 30 oct. 2012, at 16:19, Philip Levis wrote: > I'm a little worried that the one draft which is based on a real, document= ed problem encountered in a deployment is considered to have "no traction on= the mailing list", despite several discussions, while "Industrial Determini= stic Routing Extension for Low-Power and Lossy Networks," which I have never= seen mentioned on the mailing list (can someone point out that I'm wrong) d= oes have a slot. This doesn't mean that the other draft shouldn't have a slo= t; I just don't understand the process by which slots are being decided. >=20 > Phil >=20 > On Oct 29, 2012, at 11:44 PM, JP Vasseur (jvasseur) wrote: >=20 >> Dear all, >>=20 >> Many Thanks for your email - we did discuss about it but there pretty muc= h no traction on the mailing list on this item. >> Please continue to use the mailing at will. This is why the item is not p= art of the agenda indeed. >>=20 >> Many Thanks. >>=20 >> JP and Michael. >>=20 >> On Oct 30, 2012, at 3:14 AM, JeongGil Ko wrote: >>=20 >>> Dear WG Chairs, >>>=20 >>> For some reason... this email seems to be ignored=E2=80=A6 any responses= ?=20 >>>=20 >>> -John >>>=20 >>> ------ >>> JeongGil Ko, Ph.D. >>> Researcher >>> Electronics and Telecommunications Research Institute (ETRI) >>> http://sites.google.com/site/jeonggilko/ >>>=20 >>> On Oct 26, 2012, at 9:39 PM, =EC=A0=95=EC=A2=85=EC=88=98 wrote: >>>=20 >>>> JP, >>>>=20 >>>> John has requested a slot. But we've not been replied anything. Is the a= genda already fixed? >>>>=20 >>>> Regards, >>>> -Jongsoo >>>>=20 >>>> 2012. 10. 25., =EC=98=A4=EC=A0=84 6:41, JeongGil Ko =EC=9E=91=EC=84=B1: >>>>=20 >>>>>=20 >>>>> JP, >>>>>=20 >>>>> I've also put in a request for a slot at the meeting in Atlanta for pr= esenting "draft-ko-roll-mix-network-pathology" but I do not see this on the a= genda. This draft discusses about a critical and practical performance issue= of RPL networks (both collection and downwards) when they are intentionally= or accidentally deployed with devices of different MOPs. I believe that suc= h an issue is important to discuss as a group. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> -John >>>>>=20 >>>>> ------ >>>>> JeongGil Ko, Ph.D. >>>>> Researcher >>>>> Electronics and Telecommunications Research Institute (ETRI) >>>>> http://sites.google.com/site/jeonggilko/ >>>>>=20 >>>>> On Oct 25, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote: >>>>>=20 >>>>>> Dear all, >>>>>>=20 >>>>>> please find bellow the draft agenda for ROLL's WG meeting in Atlanta -= let us know if you have any comment: >>>>>>=20 >>>>>> 1) Agenda/admin (Chairs - 5mn) [5] >>>>>>=20 >>>>>> 2) WG Status (Chairs - 10 mn) [15] >>>>>>=20 >>>>>> 3) Security Framework and Applicability Statement template >>>>>> (Michael - 10m) [25] >>>>>> draft=3Ddraft-richardson-roll-applicability-template-00 >>>>>>=20 >>>>>> 4) RPL applicability in industrial networks >>>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>>> (Pascal - 10mn) [35] >>>>>>=20 >>>>>> 5) Industrial Deterministic Routing Extension for Low-Power >>>>>> and Lossy Networks (M. Wei - 10mn) [45] >>>>>>=20 >>>>>> 6) RPL deployment experience in large scale networks >>>>>> draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >>>>>>=20 >>>>>> 7) RPL applicability in industrial networks >>>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>>> (Pascal - 10mn) [60] >>>>>>=20 >>>>>> 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] >>>>>> draft-guo-roll-loop-free-dodag-repair >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> JP and Michael. >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From johui@cisco.com Tue Oct 30 09:56: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 04A5821F8622 for ; Tue, 30 Oct 2012 09:56: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 t1pss5J5QgUB for ; Tue, 30 Oct 2012 09:56:25 -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 4E82121F861C for ; Tue, 30 Oct 2012 09:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34703; q=dns/txt; s=iport; t=1351616185; x=1352825785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YiyaWDiBfEEt9mJnF0UCw+NWO+5u4ofRgBrnhGDI674=; b=cObbua2Sn1DUnNeTXNlP7+xDIgnJsSaf4KeG61Q3fPqNpevmlAixZsQ3 7SqcMOKHZp+z56cS3j8Clbrd/ZmSDg3XMrP98mgo22ocRaBPVafnZpmuv TrhOZHuNE6LjBwyxozQlxDhZ9DkBjJq8N4NAsgysTs++7Ed1DJ5ft/92O 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA0GkFCtJXG//2dsb2JhbAA6CsNYgQiCHgEBAQMBEgEHAUwJCQULAgEIIiQyJQIECgQFCBMHh14GnQiPZ5A7i3cQBAEGhWFhA4gkih+SCYFrgm+BWwEEGx4 X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="136969696" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2012 16:56:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9UGuOLq011319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 16:56:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 11:56:24 -0500 From: "Jonathan Hui (johui)" To: Ulrich Herberg Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Thread-Index: AQHNtr99kFTVX5PHTEygnVQJnCHbDA== Date: Tue, 30 Oct 2012 16:56:22 +0000 Message-ID: References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> In-Reply-To: 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-19320.004 x-tm-as-result: No--57.423000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com" , "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 16:56:28 -0000 Ulrich, Thanks for your detailed review. Responses below. On Oct 26, 2012, at 8:33 PM, Ulrich Herberg wrote: [snip] > 1. Introduction >=20 > Low power and Lossy Networks typically operate with strict resource > constraints in communication, computation, memory, and energy. Such > resource constraints may preclude the use of existing IPv6 multicast > topology and forwarding mechanisms. Traditional IP multicast > forwarding typically relies on topology maintenance mechanisms to > forward multicast messages to all subscribers of a multicast group. > However, maintaining such topologies in LLNs is costly and may not be > feasible given the available resources. >=20 > Memory constraints may limit devices to maintaining links/routes to > one or a few neighbors. For this reason, the Routing Protocol for > LLNs (RPL) >=20 > UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and > Lossy Networks" Ack. > specifies both storing and non-storing modes [RFC6550]. > The latter allows RPL routers to maintain only one or a few default > routes towards a LLN Border Router (LBR) >=20 > UH> I did not find LBR in the terminology section. Ack. > and use source routing to > forward packets away from the LBR. For the same reasons, a LLN > device may not be able to maintain a multicast forwarding topology > when operating with limited memory. >=20 > Furthermore, the dynamic properties of wireless networks can make the > cost of maintaining a multicast forwarding topology prohibitively > expensive. In wireless environments, topology maintenance may > involve selecting a connected dominating set used to forward > multicast messages to all nodes in an administrative domain. > However, existing mechanisms often require two-hop topology > information and the cost of maintaining such information grows > polynomially with network density. >=20 > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL), which provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating multicast messages > to all MPL forwarders in an MPL domain. By using the Trickle > algorithm [RFC6206], MPL requires only small, constant state for each > MPL device that initiates disseminations. The Trickle algorithm also > allows MPL to be density-aware, allowing the communication rate to > scale logarithmically with density. >=20 > UH> I am not sure I understand the last sentence. What does it mean? > How is that achieved? This is borrowing the wording out of RFC 6206. I can reference the RFC her= e (again) and reference the academic papers (NSDI'04, CACM'08) that present= this result. > UH> By the way, since this is a standards track document, is there any > deployment experience? Implementations? As Don mentioned, there are a number of implementations on different platfo= rms. Peter van der Stok has also presented his implementation to the WG. = Cisco also has an implementation. The use of Trickle to disseminate messages has been implemented, deployed, = and published numerous times in the past. These implementations include sm= all message, medium message, and large message dissemination. Including NS= DI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, and TOSN'10. > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. >=20 > UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119 Ack. > The following terms are used throughout this document: >=20 > MPL forwarder An IPv6 router that subscribes to the MPL > multicast group and participates in disseminating > MPL multicast packets. >=20 > MPL multicast scope The multicast scope that MPL uses when forwarding > MPL multicast packets. In other words, the > multicast scope of the IPv6 Destination Address > of an MPL multicast packet. >=20 > UH> An RFC reference to "scope" could be helpful. I assume you mean RFC 4007. > MPL domain A connected set of MPL forwarders that define the > extent of the MPL dissemination process. >=20 > UH> What does connected mean? What if a the network is split in two parts= ? "MPL forwarding domain A MPL forwarding domain is a collection of forwar= ders that operate MPL and are under the control of a single administration.= " > As a > form of flood, all MPL forwarders in an MPL > domain will receive MPL multicast packets. >=20 > UH> Probably not *all* forwards will receive it (assuming packets can > be lost) How about: "As a form of flood, MPL strives to deliver MPL multicast packets to all MP= L forwarders." >=20 >=20 > The > MPL domain MUST be composed of at least one MPL > multicast scope and MAY be composed of multiple > MPL multicast scopes. >=20 > UH> Why is that? Anyway, I am unsure whether one can say that a > routing domain "consists" of multicast scopes. If I understand that > correctly, the multicast scope just determines how far a message > propagates. I think it would help to define "MPL multicast scope zone" in addition to "= MPL multicast scope". Then the correct wording for the text above is "MAY = be composed of multiple MPL multicast scope zones." Does that help? > MPL seed A MPL forwarder that begins the dissemination > process for an MPL multicast packet. The MPL > seed may be different than the source of the > original multicast packet. >=20 > MPL seed identifier An identifier that uniquely identifies an MPL > forwarder within its MPL domain. >=20 > UH> How is the uniqueness guaranteed? What kind of identifier is that? > An IP address? I see it's defined later, but maybe it would be helpful > to mention it here, too. Ack. >=20 >=20 > original multicast packet An IPv6 multicast packet that is > disseminated using MPL. >=20 > UH> That terminology sounds a bit confusing; I would have imagined > that the above description matches the following term "MPL multicast > packet". What's the difference between an "original multicast packet" > and an "MPL multicast packet"? I assume the one is the inner packet > when using IPv6-in-IPv6 tunnels, the other one is the outer packet > with the options header. The one subtlety here is that the original multicast packet does not necess= arily have to be encapsulated using IPv6-in-IPv6. How about: "An IPv6 multicast packet that is transported by MPL. In other words, it i= s an MPL multicast packet with the MPL Hop-by-Hop Option removed. When the= MPL multicast packet uses IPv6-in-IPv6 encapsulation to include the MPL Ho= p-by-Hop Option, the original multicast packet is the inner packet." > MPL multicast packet An IPv6 multicast packet that contains an MPL > Hop-by-Hop Option. When either source or > destinations are beyond the MPL multicast scope, >=20 > UH> Above it was said there may be multiple scopes in a domain. Here > you talk about "the" scope. Which one? Having "MPL multicast scope zones", as addressed above, should help here to= o. > the MPL multicast packet is an IPv6-in-IPv6 > packet that contains an MPL Hop-by-Hop Option in > the outer IPv6 header and encapsulates an > original multicast packet. When both source and > destinations are within the MPL multicast scope, > the MPL Hop-by-Hop Option may be included > directly within the original multicast packet. >=20 >=20 >=20 >=20 >=20 > Hui & Kelsey Expires April 22, 2013 [Page 4] > Internet-Draft MPL October 2012 >=20 >=20 > 3. Overview >=20 > MPL delivers IPv6 multicast packets by disseminating them to all MPL > forwarders within an MPL domain. MPL dissemination is a form of > flood. An MPL forwarder may broadcast/multicast an MPL multicast > packet out of the same physical interface on which it was received. > Using link-layer broadcast/multicast allows MPL to forward multicast > packets without explicitly identifying next-hop destinations. An MPL > forwarder may also broadcast/multicast MPL multicast packets out > other interfaces to disseminate the message across different links. > MPL does not build or maintain a multicast forwarding topology to > forward multicast packets. >=20 > Any MPL forwarder may initiate the dissemination process by serving > as an MPL seed for an original multicast packet. The MPL seed may or > may not be the same device as the source of the original multicast > packet. When the original multicast packet's source is outside the > LLN, >=20 > UH> LLN or MPL domain? How can a router determine if an incoming > packet is inside our outside the MPL domain? MPL forwarding domain. Generally, the packet is outside when received on a= n interface not used for MPL forwarding or when the original multicast pack= et does not contain an MPL Option. > the MPL seed may be the ingress router. Even if an original > multicast packet source is within the LLN, the source may first > forward the multicast packet to the MPL seed using IPv6-in-IPv6 > tunneling. >=20 > UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a > title not related to "IPv6 tunneling". I suggest to make an own > section. Ack. > Because MPL state requirements grows with the number of > active MPL seeds, >=20 > UH> In section 1 it was written that the state is constant. Here you > say it grows. Which one is it? Section 1 states: "MPL requires only small, constant state for each MPL dev= ice that initiates disseminations." That is consistent with the wording ab= ove. I can make the text the same in both locations. > limiting the number of MPL seeds reduces the amount > of state that MPL forwarders must maintain. >=20 > Because MPL typically broadcasts/multicasts MPL packets out of the > same interface on which they were received, >=20 > UH> Why typically? Doesn't that depend on the scenario that this > specification is used in? >=20 > MPL forwarders are likely > to receive an MPL multicast packet more than once. >=20 > UH> I am not sure if that is the only reason. Isn't the reason that it > may be received from multiple neighbors? How about: "As a form of flood, MPL forwarders are likely to receive an MPL multicast = packet more than once." > The MPL seed tags > each original multicast packet with an MPL seed identifier and a > sequence number. The sequence number provides a total ordering of > MPL multicast packets disseminated by the MPL seed. >=20 > MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include > MPL-specific information along with the original multicast packet. > Each IPv6 multicast packet that MPL disseminates includes the MPL > Option. Because the original multicast packet's source and the MPL > seed may not be the same device, the MPL Option may be added to the > original multicast packet en-route. To allow Path MTU discovery to > work properly, MPL encapsulates the original multicast packet in > another IPv6 header that includes the MPL Option. >=20 > Upon receiving a new MPL multicast packet for forwarding, the MPL > forwarder may proactively transmit the MPL multicast packet packet a > limited number of times and then falls back into an optional reactive > mode. In maintenance mode, an MPL forwarder buffers recently > received MPL multicast packets and advertises a summary of recently > received MPL multicast packets from time to time, allowing > neighboring MPL forwarders to determine if they have any new > multicast packets to offer or receive. >=20 >=20 >=20 > Hui & Kelsey Expires April 22, 2013 [Page 5] > Internet-Draft MPL October 2012 >=20 >=20 > MPL forwarders schedule their packet (control and data) transmissions > using the Trickle algorithm [RFC6206]. Trickle's adaptive > transmission interval allows MPL to quickly disseminate messages when > there are new MPL multicast packets, but reduces transmission > overhead as the dissemination process completes. Trickle's > suppression mechanism and transmission time selection allow MPL's > communication rate to scale logarithmically with density. >=20 > UH> I think the whole introduction is not very easy to read. There is > a lot of text about some details (IPv6-in-IPv6 tunnels, multiple > interfaces), but the essential mechanism is hard to identify from the > text. Also, there is nothing mentioned about what kind of state is > required to be stored on each router (which information sets etc). A lot of this is combined with text in Section 5. Would you prefer to see = that pulled up here? > Hui & Kelsey Expires April 22, 2013 [Page 6] > Internet-Draft MPL October 2012 >=20 >=20 > 4. Message Formats >=20 > 4.1. MPL Option >=20 > The MPL Option is carried in an IPv6 Hop-by-Hop Options header, >=20 > UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options header= " I was following the text of RFC 2675. > UH> More importantly, RFC6564 specifies: >=20 > New options for the existing Hop-by-Hop Header SHOULD NOT be > created or specified unless no alternative solution is feasible. > Any proposal to create a new option for the existing Hop-by-Hop > Header MUST include a detailed explanation of why the hop-by-hop > behavior is absolutely essential in the document proposing the new > option with hop-by-hop behavior. >=20 > UH> I did not see such an explanation. How about: "The MPL option is needed because the IPv6 header does not provide unique i= dentification of IPv6 packets from the source." > immediately following the IPv6 header. The MPL Option has the > following format: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Opt Data Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S |M| rsv | sequence | seed-id (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > UH> It could help to mention that this is formatted in network byte order >=20 > Option Type XX (to be confirmed by IANA). >=20 > Opt Data Len Length of the Option Data field in octets. MUST > be set to either 2 or 4. >=20 > UH> 2 or 4 depending on what? Depending on the size of seed-id. > S 2-bit unsigned integer. Identifies the length of > seed-id. 0 indicates that the seed-id is 0 and > not included in the MPL Option. 1 indicates that > the seed-id is a 16-bit unsigned integer. 2 > indicates that the seed-id is a 64-bit unsigned > integer. 3 indicates that the seed-id is a 128- > bit unsigned integer. >=20 > M 1-bit flag. 0 indicates that the value in > sequence is not the greatest sequence number that > was received from the MPL seed. >=20 > rsv 5-bit reserved field. MUST be set to zero and > incoming MPL multicast packets in which they are > not zero MUST be dropped. >=20 > sequence 8-bit unsigned integer. Identifies relative > ordering of MPL multicast packets from the source > identified by seed-id. >=20 > seed-id Uniquely identifies the MPL seed that initiated > dissemination of the MPL multicast packet. The > size of seed-id is indicated by the S field. >=20 [snip] > 4.2.1. MPL Window >=20 > An MPL Window encodes the sliding window state (described in > Section 5.2 that the MPL forwarder maintains for an MPL seed. >=20 > UH> missing ")" Ack. [snip] > 5. MPL Forwarder Behavior >=20 > An MPL forwarder implementation needs to manage sliding windows for > each active MPL seed. The sliding window allows the MPL forwarder to > determine what multicast packets to accept and what multicast packets > are buffered. An MPL forwarder must also manage MPL packet > transmissions. >=20 > 5.1. Multicast Packet Dissemination >=20 > MPL uses the Trickle algorithm to control packet transmissions when > disseminating MPL multicast packets [RFC6206]. MPL provides two > propagation mechanisms for disseminating MPL multicast packets. >=20 > 1. With proactive propagation, an MPL forwarder transmits buffered > MPL multicast packets using the Trickle algorithm. This method > is called proactive propagation since an MPL forwarder actively > transmits MPL multicast packets without discovering that a > neighboring MPL forwarder has yet to receive the message. >=20 > 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL > messages using the Trickle algorithm. An MPL forwarder only > transmits buffered MPL multicast packets upon discovering that > neighboring devices have not yet to receive the corresponding MPL > multicast packets. >=20 > When receiving a new multicast packet, an MPL forwarder first > utilizes proactive propagation to forward the MPL multicast packet. > Proactive propagation reduces dissemination latency since it does not > require discovering that neighboring devices have not yet received > the MPL multicast packet. MPL forwarders utilize proactive > propagation for newly received MPL multicast packets since they can > assume that some neighboring MPL forwarders have yet to receive the > MPL multicast packet. After a limited number of MPL multicast packet > transmissions, the MPL forwarder may terminate proactive propagation > for the MPL multicast packet. >=20 > An MPL forwarder may optionally use reactive propagation to continue > the dissemination process with lower communication overhead. With > reactive propagation, neighboring MPL forwarders use ICMPv6 MPL > messages to discover new MPL multicast messages that have not yet > been received. When discovering that a neighboring MPL forwarder has > not yet received a new MPL multicast packet, the MPL forwarder > enables proactive propagation again. >=20 > UH> There is not a lot of RFC2119 language in the above. Or is that > defined later? Is this above section more like an introduction? This is more like an intro. Would you prefer to see this moved to the over= view section? > Hui & Kelsey Expires April 22, 2013 [Page 11] > Internet-Draft MPL October 2012 >=20 >=20 > 5.1.1. Trickle Parameters and Variables >=20 > As specified in RFC 6206 [RFC6206], a Trickle timer runs for a > defined interval and has three configuration parameters: the minimum > interval size Imin, the maximum interval size Imax, and a redundancy > constant k. >=20 > MPL defines a fourth configuration parameter, TimerExpirations, which > indicates the number of Trickle timer expiration events that occur > before terminating the Trickle algorithm. >=20 > Each MPL forwarder maintains a separate Trickle parameter set for the > proactive and reactive propagation methods. TimerExpirations MUST be > greater than 0 for proactive propagation. TimerExpirations MAY be > set to 0 for reactive propagation, which effectively disables > reactive propagation. >=20 > As specified in RFC 6206 [RFC6206], a Trickle timer has three > variables: the current interval size I, a time within the current > interval t, and a counter c. >=20 > UH> This sentence starts confusing, as it looks very similar to the > first paragraph in this section. "a Trickle timer has three variables" > How about using the same language as in RFC6206: > "In addition to these three parameters, Trickle maintains three > variables: > o I, the current interval size, > o t, a time within the current interval, and > o c, a counter." Ack. > MPL defines a fourth variable, e, which counts the number of Trickle > timer expiration events since the Trickle timer was last reset. >=20 > 5.1.2. Proactive Propagation >=20 > With proactive propagation, the MPL forwarder transmits buffered MPL > multicast packets using the Trickle algorithm. Each buffered MPL > multicast packet that is proactively being disseminated with > proactive propagation has an associated Trickle timer. >=20 > UH> I think that somewhere the state requirements need to be > mentioned. How does that affect scalability of the algorithm etc. > Density is mentioned somewhere in the beginning, but not explained how > that would affect scalability and state requirements. Ack. > Adhering to > Section 5 of RFC 6206 [RFC6206], this document defines the following: >=20 > o This document defines a "consistent" transmission for proactive > propagation as receiving an MPL multicast packet that has the same > MPL seed identifier and sequence number as a buffered MPL packet. >=20 > o This document defines an "inconsistent" transmission for proactive > propagation as receiving an MPL multicast packet that has the same > MPL seed identifier, the M flag set, and has a sequence number > less than the buffered MPL multicast packet's sequence number. >=20 > o This document does not define any external "events". >=20 > o This document defines both MPL multicast packets and ICMPv6 MPL > multicast packets as Trickle messages. These messages are defined > in the sections below. >=20 > UH> I don't see the term Trickle message used anywhere else. Used in RFC 6206. > Hui & Kelsey Expires April 22, 2013 [Page 12] > Internet-Draft MPL October 2012 >=20 >=20 > o The actions outside the Trickle algorithm that the protocol takes > involve managing sliding window state, and is specified in > Section 5.2. >=20 > 5.1.3. Reactive Propagation >=20 > With reactive propagation, the MPL forwarder transmits ICMPv6 MPL > messages using the Trickle algorithm. A MPL forwarder maintains a > single Trickle timer for reactive propagation with each MPL domain. > When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not > execute the Trickle algorithm for reactive propagation and reactive > propagation is disabled. Adhering to Section 5 of RFC 6206 > [RFC6206], this document defines the following: >=20 > o This document defines a "consistent" transmission for reactive > propagation as receiving an ICMPv6 MPL message that indicates > neither the receiving nor transmitting node has new MPL multicast > packets to offer. >=20 > o This document defines an "inconsistent" transmission for reactive > propagation as receiving an ICMPv6 MPL message that indicates > either the receiving or transmitting node has at least one new MPL > multicast packet to offer. >=20 > o This document defines an "event" for reactive propagation as > updating any sliding window (i.e. changing the value of WindowMin, > WindowMax, or the set of buffered MPL multicast packets) in > response to receiving an MPL multicast packet. >=20 > o This document defines both MPL multicast packets and ICMPv6 MPL > multicast packets as Trickle messages. These messages are defined > in the sections below. >=20 > UH> I don't see the term "Trickle message" anywhere else (other than > in 5.1.2) Used in RFC 6206. [snip] > 5.3. Transmission of MPL Multicast Packets >=20 > The MPL forwarder manages buffered MPL multicast packet transmissions > using the Trickle algorithm. When adding a packet to > BufferedPackets, the MPL forwarder MUST create a Trickle timer for > the packet and start execution of the Trickle algorithm. >=20 > After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL > forwarder MUST stop executing the Trickle algorithm. When a buffered > MPL multicast packet does not have an active Trickle timer, the MPL > forwarder MAY free the buffered packet by advancing WindowMin to 1 > greater than the packet's sequence number. >=20 > Each interface that supports MPL is configured with exactly one MPL > multicast scope. The MPL multicast scope MUST be site-local or > smaller and defaults to link-local. A scope larger than link-local > MAY be used only when that scope corresponds exactly to the MPL > domain. >=20 > UH> Why is this written in a section called "Transmission of MPL > Multicast Packets"? Seems more like an initial configuration. Same for > the below IPv6.. I would have expected that in a dedicated section > about IPv6 tunneling Ack. > UH> How would the router now that the scope corresponds exactly to the > MPL domain? The intent is to have this configured, not dynamically determined. Will ma= ke this clearer in the next revision. > Hui & Kelsey Expires April 22, 2013 [Page 15] > Internet-Draft MPL October 2012 >=20 >=20 > An MPL domain may therefore be composed of one or more MPL multicast > scopes. For example, the MPL domain may be composed of a single MPL > multicast scope when using a site-local scope. Alternatively, the > MPL domain may be composed of multiple MPL multicast scopes when > using a link-local scope. >=20 > UH> I am not quite sure how the scope works in this specification. Is > that used somewhere when deciding whether to forward packets? Should be "multiple MPL multicast scope zones". > IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an > original multicast packet whose source or destination address is > outside the MPL multicast scope. >=20 > UH> The source address is a unicast address, right? How can that be > outside a multicast scope? How would you know? Source address should not be included in the text above. Instead, there sh= ould be text requiring a border router to encapsulate using IPv6-in-IPv6 wh= en forwarding into an MPL forwarding domain. > IPv6-in-IPv6 encapsulation is > necessary to support Path MTU discovery when the MPL forwarder is not > the source of the original multicast packet. 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. >=20 > UH> That should be specified more clearly. What does "remove" mean? I > suppose you mean decapsulate the inner IPv6 packet. How about: "Decapsulating the original multicast packet also serves to remove the MPL = Option contained in the outer header." > The destination address scope for the outer IPv6 > header MUST be the MPL multicast scope. >=20 > UH> Again, which one? I thought there can be several scopes? Again, only a single scope, but multiple scope zones. >=20 > When an MPL domain is composed of multiple MPL multicast scopes (e.g. > when the MPL multicast scope is link-local), an MPL forwarder MUST > decapsulate and encapsulate the original multicast packet when > crossing between different MPL multicast scopes. >=20 > UH> When would you know when to cross a multicast scope? Do you mean > routing domain? Crossing between different MPL multicast scope zones. An MPL forwarder sho= uld know by virtue of attempting to forward the packet beyond the current z= one. When the MPL multicast scope is link-local, then the MPL forwarder mu= st decapsulate and encapsulate when forwarding each packet. > In doing so, the > MPL forwarder MUST duplicate the MPL Option, unmodified, in the new > outer IPv6 header. >=20 > The IPv6 destination address of the MPL multicast packet is the all- > MPL-forwarders multicast address (TBD). >=20 > UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest > to define the variable and use the value only in the IANA section. Ack. > The scope of the IPv6 > destination address is set to the MPL multicast scope. >=20 > UH> which one? Only one MPL multicast scope - multiple MPL multicast scope zones. >=20 > 5.4. Reception of MPL Multicast Packets >=20 > Upon receiving an MPL multicast packet, the MPL forwarder first > determines whether or not to accept and buffer the MPL multicast > packet based on its MPL seed and sequence value, as specified in > Section 5.2. >=20 > If the MPL forwarder accepts the MPL multicast packet, the MPL > forwarder determines whether or not to deliver the original multicast > packet to the next higher layer. >=20 > UH> How would it determine that? That text doesn't seem quite right. How about: "If the MPL forwarder accepts the MPL multicast packet, the MPL forwarder p= rocesses the original multicast packet." > For example, if the MPL multicast > packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the > outer IPv6 header, which also removes MPL Option. >=20 > UH> For example? What exactly needs to be done? This sentence is no longer required with the proposed text above. >=20 > 5.5. Transmission of ICMPv6 MPL Messages >=20 > The MPL forwarder generates and transmits a new ICMPv6 MPL message > whenever Trickle requests a transmission. >=20 > UH> So for each data packet there would be a new ICMPv6 message? > Wouldn't that create a lot of overhead? Nope. The ICMPv6 message is a list of sliding windows. > UH> To which address is the ICMP message sent? On which interface? Destination Address is specified in Section 4.2. Sent on all interfaces th= at are used for forwarding MPL multicast packets. > The MPL forwarder includes > an encoding of each sliding window in the ICMPv6 MPL message. [snip] > When an MPL forwarder determines that it has at least one buffered > MPL multicast packet that has not yet been received by a neighbor, > the MPL forwarder resets the Trickle timer associated with reactive > propagation. Additionally, for each buffered MPL multicast packet > that should be transferred, the MPL forwarder MUST reset the Trickle > timer and reset e to 0 for proactive propagation. If the Trickle > timer for proactive propagation has already stopped execution, >=20 > UH> Which timer? I thought there is one timer per packet in the > proactive mode? How about: "the Trickle timer(s) associated with the buffered packet(s) and reset e as= sociated with the buffered packet(s) to 0 for proactive propagation". > the > MPL forwarder MUST initialize a new Trickle timer and start execution > of the Trickle algorithm. [snip] > 6. MPL Parameters >=20 > An MPL forwarder maintains two sets of Trickle parameters for the > proactive and reactive methods. The Trickle parameters are listed > below: >=20 > PROACTIVE_IMIN The minimum Trickle timer interval, as defined in > [RFC6206] for proactive propagation. >=20 > PROACTIVE_IMAX The maximum Trickle timer interval, as defined in > [RFC6206] for proactive propagation. >=20 > PROACTIVE_K The redundancy constant, as defined in [RFC6206] for > proactive propagation. >=20 > PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations > that occur before terminating the Trickle algorithm. MUST be set > to a value greater than 0. >=20 > REACTIVE_IMIN The minimum Trickle timer interval, as defined in > [RFC6206] for reactive propagation. >=20 > REACTIVE_IMAX The maximum Trickle timer interval, as defined in > [RFC6206] for reactive propagation. >=20 > REACTIVE_K The redundancy constant, as defined in [RFC6206] for > reactive propagation. >=20 > REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations > that occur before terminating the Trickle algorithm. MAY be set > to 0, which disables reactive propagation. >=20 > WINDOW_HOLD_TIME The minimum lifetime for sliding window state. >=20 >=20 > UH> I don't see any recommendations for these values. That is > typically requested in the IESG evaluation for standards track > documents (either default values and/or guideslines on the values). Ack. [snip] > 8. IANA Considerations >=20 > The Trickle Multicast option requires an IPv6 Option Number. >=20 >=20 >=20 > HEX act chg rest > --- --- --- ----- > C 01 0 TBD >=20 >=20 >=20 > The first two bits indicate that the IPv6 node MUST discard the > packet if it doesn't recognize the option type, and the third bit > indicates that the Option Data MUST NOT change en-route. >=20 >=20 > UH> That does not look like a valid IANA section. RFC 5226 give some > good guidelines. Ack. -- Jonathan Hui From pal@cs.stanford.edu Tue Oct 30 10:03: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 053CD21F8707 for ; Tue, 30 Oct 2012 10:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wleOGIHuUCxr for ; Tue, 30 Oct 2012 10:03:19 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id A634221F86F1 for ; Tue, 30 Oct 2012 10:03:19 -0700 (PDT) Received: from dn5221eb.sunet ([10.33.5.203]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTFDh-0004hT-RO; Tue, 30 Oct 2012 10:03:19 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <508FF9D3.40805@merl.com> Date: Tue, 30 Oct 2012 10:03:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B8958C3-3B39-4CA7-B570-BC7D6E8084AE@cs.stanford.edu> References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AAE0D.8030903@merl.com> <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AE1F9.1080600@merl.com> <508FF9D3.40805@merl.com> To: Jianlin Guo X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 4931b81c697f7235677bca146b457fc7 Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 30 Oct 2012 17:03:21 -0000 So it's basically a multihop DIS? How is that then a local repair? In = the case of a subtree becoming disconnected due to the top of the = subtree having a null parent set, those nodes at the top would issue a = DIS with Solicited Information to repair their local routes (next hop). = Nodes below them in the DODAG shouldn't have to trigger a local repair. Put another way, can you describe a concrete case where DIS with = Solicited Information can't solve the problem, yet DRQ/DRP can? Or is = this purely an efficiency optimization? If the latter, I'd love to see = concrete results indicating the savings (from a real LLN, not = simulation). Phil On Oct 30, 2012, at 9:01 AM, Jianlin Guo wrote: > Hi Phil, >=20 > Thank you for your valuable comments. There may be one more major case = where a RPL node has a null parent set, that is, parent node of a RPL = node becomes unreachable. This is a typical case in lossy networks. For = example, a mobile object could block wireless link between two RPL = nodes. >=20 > The key differences between DIS and DRQ/DRP are: > 1) A DRQ message can travel multiple hops. # of hops is controlled by = a parameter named MH (Maximum Hop) in DRQ message. > 2) Upon receiving a DRQ message, a neighbor node responds with DRP = message only if neighbor node has non-empty parent set and a rank lower = than rank of the DRQ transmitting node. Otherwise, it may forward DRQ = message to its parent node. > 3) Receiving of a DRP message guarantees the discovery of a new parent = node. > 4) Value of MH parameter controls local repair. MH can be set to a = small value, e.g. 1,2 or 3, so that DRQ message do not travel too far. >=20 > Jianlin > On 10/29/2012 6:09 PM, Philip Levis wrote: >> I'd like to take a step back here and discuss MaxRankIncrease and the = notion of null parent sets. >>=20 >> The two major cases where a RPL node has a null parent set are: >> 1) The node has no members in its neighbor set >> 2) The node has members of its neighbor set, but all of them = advertise a Rank of INFINITE_RANK. The major case we're concerned about = here is when rule 3 of 8.2.2.4 requires nodes to advertise INFINITE_RANK = due to the value of MaxRankIncrease. >>=20 >> I don't think the local repair scheme will fix case 1. So we're = really talking about case 2. >>=20 >> MaxRankIncrease emerged in specifying RPL as a way to support both = ZigBee-style centralized periodic tree reconstruction triggers = (MaxRankIncrease =3D=3D 0) as well as CTP-style completely distributed = operation while simultaneously providing a cap to the count-to-infinity = problem. So really, the issue here is when you have a network with a = small MaxRankIncrease and don't want to reconstruct the entire tree, = there are valid parents that could be used, but a node does not have = them in its neighbor/parent set. >>=20 >> Thinking about it this way (am I wrong?), I am a bit confused by the = claim that the draft is a local repair. Assuming a node has to follow = rule 3 in 8.2.2.4, this is not a repair mechanism, but rather a neighbor = discovery mechanism. Could you explain how DRQ/DRP solve a problem that = a DIS with a proper Solicited Information option can't solve? This was = the original intent of DIS with Solicited Information. Or perhaps I'm = not understanding DRQ/DRP correctly? >>=20 >> Phil >>=20 >> On Oct 26, 2012, at 12:18 PM, Jianlin Guo wrote: >>=20 >>> Thank you for the paper. I agree with [1] on that "dismantling of = the sub-DAG, rooted at the node doing the rank increase, causes more = turmoil in the network than the routing loops themselves". >>>=20 >>> Now, consider a case in which a node's parent set becomes empty. In = this case, RPL provides following set of actions: >>>=20 >>> 1) Start its own floating DODAG >>> 2) Poison the broken path >>> 3) Trigger a local repair >>>=20 >>> Both 1) and 2) actions will increase packet delivery delay time = (which may be not acceptable for some applications) and possibly cause = packet dropping due to limited buffer size of a LLN node (which may also = be not acceptable for some applications). So, trigger a local repair is = a practical option. Our local repair mechanism is designed for this = purpose and it does not create any loops. >>>=20 >>> Jianlin >>>=20 >>> On 10/26/2012 12:10 PM, C Chauvenet wrote: >>>> Le 26 oct. 2012 =E0 17:36, Jianlin Guo a =E9crit : >>>>=20 >>>>> We compared performance metrics such as packet delivery rate. >>>> Ok. >>>>=20 >>>> In general do you have a document about your experiments that you = would like to share ? >>>> I think it could be a good way to defend your mechanism. >>>>=20 >>>> There are 2 sub questions related to your draft : >>>>=20 >>>> - Is there a strong need for an additional mechanism to prevent = loops ? (the HbH header option mentioned by phil is already there). >>>> - Is your mechanism the good way to do so (overhead induced, = efficiency...) >>>>=20 >>>> As mentioned by Phil, this subject has been previously discussed = inside ROLL few years ago, and did not recommend to add such mechanisms. >>>>=20 >>>> For instance, [1] concludes that >>>>=20 >>>> "the turmoil caused >>>> by dismantling of the sub-DAGs in order to increase ranks >>>> may be much more than what the routing loops themselves >>>> will cause. Consequently, the use of such loop avoidance >>>> mechanism in the operation of a DAG based routing protocol >>>> can not be universally recommended." >>>>=20 >>>> [1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf >>>>=20 >>>> Best, >>>>=20 >>>> C=E9dric. >>>>=20 >>>>> On 10/26/2012 11:21 AM, C Chauvenet wrote: >>>>>> Hi, >>>>>> Thank you for your answer. >>>>>> See inline. >>>>>>=20 >>>>>> Le 26 oct. 2012 =E0 15:27, Jianlin Guo a =E9crit : >>>>>>=20 >>>>>>> On 10/25/2012 12:06 PM, C Chauvenet wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Le 25 oct. 2012 =E0 16:01, Jianlin Guo a =E9crit : >>>>>>>>=20 >>>>>>>>> Hi Michael, >>>>>>>>>=20 >>>>>>>>> For your first question, draft-clausen-lln-rpl-experiences-04 = pointed out that "it can be observed that with current implementations = of RPL, such as the ContikiRPL = implementation, loops do occur - and, frequently. During the same = experiments described in Section 13, a snapshot of the DODAG was made = every ten seconds. In 74.14% of the 4114 snapshots, at least one loop = was observed". >>>>>>>> Is it something that you observed in your own deployments ? >>>>>>>> More specifically : did you find similar results ? >>>>>>> We observed the occurrence of loops, unfortunately we did not = measure the percentage. >>>>>> So how did you evaluate the benefit of the mechanism that you = proposed ? >>>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> C=E9dric. >>>>>>>>=20 >>>>>>>>> For your second question, further investigation and = experiments are needed. >>>>>>>>>=20 >>>>>>>>> Jianlin >>>>>>>>>=20 >>>>>>>>> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>>>>>>>>> Jianlin Guo >>>>>>>>>> wrote: >>>>>>>>>> JG> Dear ROLL WG members, >>>>>>>>>>=20 >>>>>>>>>> JG> As we all know that loop is an open issue in RPL. = Experiment shows that loop >>>>>>>>>> JG> occurs quite often. We have proposed a loop free = local DODAG >>>>>>>>>>=20 >>>>>>>>>> Can you quantify "quite often"? >>>>>>>>>> Do you have any metrics for how often loops occur, and what = the cost is >>>>>>>>>> of their repair? >>>>>>>>>>=20 >>>>>>>>>> I think that the WG would be very very very interested in = additional -experiences >>>>>>>>>> draft, or pointers to papers explaining same, that gives a = repeateable >>>>>>>>>> experiment in which loops are observed. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Roll mailing list >>>>>>>>> Roll@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 From johui@cisco.com Tue Oct 30 10:21:39 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 B450721F8728 for ; Tue, 30 Oct 2012 10:21:39 -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 a+X2zBUwYuv2 for ; Tue, 30 Oct 2012 10:21:39 -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 E6D8421F8719 for ; Tue, 30 Oct 2012 10:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1710; q=dns/txt; s=iport; t=1351617699; x=1352827299; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iuhvmMId6iUW/fgSTeW0IXtjB8h6ZExIldr+XGnQTnw=; b=AgqMblvJA/BACZ51j68Z0i1MNz68b7qbAzP1AYOOOE+JMUv7hfVAv05N Je2HUv2lcBIizCgSzKcpK3ovdmz0Nec80qiURAMSPQc72g6FW7IjjyMmX 5w34/veMSntj0aL0UJVWYi08Rf5G3XpJSpv+2eOyFJ37cmlYeCwuAdIHp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADUMkFCtJXG9/2dsb2JhbABEw1yBCIIeAQEBAwESAScPMAULAgEIIgISCQcyFBECBA4FCBqHXgadCY9nkDeLdxQBhWdhA6RMgWuCb4FbAR8e X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="137015516" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2012 17:21:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9UHLc5Q000581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 17:21:38 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; Tue, 30 Oct 2012 12:21:38 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: MPL draft 2 Thread-Index: AQHNtsMEHcLYGZ8J2EujWKNAgfQKeA== Date: Tue, 30 Oct 2012 17:21:37 +0000 Message-ID: References: In-Reply-To: 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-19320.004 x-tm-as-result: No--31.775000-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: richard kelsey , "roll@ietf.org" Subject: Re: [Roll] MPL draft 2 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: Tue, 30 Oct 2012 17:21:39 -0000 Hi Peter, If I understand correctly, you would like to configure MPL multicast scope = zones by having MPL forwarding interfaces subscribe to different IPv6 multi= cast addresses. That is fine with me, but only works when using IPv6-in-IP= v6 encapsulation. If you want to limit the scope of MPL multicast packets = that do not use IPv6-in-IPv6 encapsulation, we can't rely on the IPv6 Desti= nation Address since that is set by the source of the original multicast pa= cket. Thoughts? -- Jonathan Hui On Oct 22, 2012, at 6:53 AM, peter van der Stok wrote: > Hi Jonathan and Richard, >=20 > thanks for the new MPL draft. During a first reading I had some problems = with the domain concept. > I understood that a domain may be composed of several link-local scopes. > When configuring an interface with one link-local scope I should like to = reject link-local multicasts which come from link-local neigbors that do no= t belong to the domain for which the interface is configured. For example: = closely spaced wireless nodes which have different edge routers. To express= the domain in the multicast address were you thinking of "transient" and "= unicast prefix based" mc addresses with format ff32::prefix:group?. Configu= ring the interface with a link-local scope limited to one prefix may cover = the domain concept adequately. >=20 > In my opinion some text on interface configuration to implement packet re= jection based on Mc domain will be useful. >=20 > Greetings >=20 > Peter >=20 > --=20 > Peter van der Stok > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 From johui@cisco.com Tue Oct 30 10:28: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 EDE9C21F8589 for ; Tue, 30 Oct 2012 10:28:01 -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 6I7pFGa0fqgU for ; Tue, 30 Oct 2012 10:28:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1417921F8550 for ; Tue, 30 Oct 2012 10:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4015; q=dns/txt; s=iport; t=1351618081; x=1352827681; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/boRCgKVt2l2falgdu3VjDsO+FSjXFLmJU6o4LgLE+8=; b=ipjlhi9GkxcWQZV7xRZA/uS7yWgNlTfHUPDYUiie9tWJhJcjkicCPI7c dYTCKOHcjyXKIDY63Yc6e9ucRF20PazWgrZMa0H4/rtRbVlF7yt6/JubS Azk99PbADcc7Rw/vhtYsqajeSurPs1P/v1X6isYBYyF32UJ+t4kdoGFq/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABcNkFCtJV2a/2dsb2JhbAA6CsNcgQiCHgEBAQMBAQEBDwEnNAsFCwIBCA4KChQQJwslAgQOBQgah1IDCQYLnQCPZ4ZWBYlYBIt3EIVsYQOkTIFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="136985455" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 30 Oct 2012 17:28:00 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9UHS0I3032641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 17:28:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 12:28:00 -0500 From: "Jonathan Hui (johui)" To: Don Sturek Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Thread-Index: AQHNtsPoCFDBKx0obUyzx8/7TlSyjQ== Date: Tue, 30 Oct 2012 17:27:59 +0000 Message-ID: References: In-Reply-To: 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-19320.004 x-tm-as-result: No--45.710300-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: <3EC4710AD3859B4FB43DFB9607B2646D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" 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: Tue, 30 Oct 2012 17:28:02 -0000 Yes, a goal of the current draft is to support both cases (use of IPv6-in-I= Pv6 encapsulation or not). The intent is as follows: 1) If the source of the multicast packet is within the MPL forwarding domai= n and the destination has a scope equal to or smaller than the MPL multicas= t scope, then no IPv6-in-IPv6 encapsulation is required. 2) If the source of the multicast packet is outside the MPL forwarding doma= in or the destination has scope greater than the MPL multicast scope, then = IPv6-in-IPv6 encapsulation is required. When using IPv6-in-IPv6 encapsulat= ion, then the all MPL forwarders multicast address with scope =3D MPL multi= cast scope is used as the destination address in the outer header. As mentioned in my other email, IPv6-in-IPv6 encapsulation is required if y= ou want to use the IPv6 Destination Address to identify MPL forwarding scop= e zones. Of course, this brings up Dario's practical point of how to configure the M= PL multicast scope if we allow that to dynamically change. He proposes a s= implifying suggestion of requiring IPv6-in-IPv6 encapsulation for all non-l= ink-local multicasts. In other words, setting the MPL multicast scope to l= ink-local. Thoughts? -- Jonathan Hui On Oct 30, 2012, at 4:46 AM, Don Sturek wrote: > Hi Peter, >=20 > I still need to read the latest draft so take what I say here with that i= n > 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 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. >=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 not >> 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 >>>>=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 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). >>>>=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 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From d.sturek@att.net Tue Oct 30 10:32: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 127A321F8734 for ; Tue, 30 Oct 2012 10:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=3.100, 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 7MG+uKSjxrwF for ; Tue, 30 Oct 2012 10:32:10 -0700 (PDT) Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D521F85E6 for ; Tue, 30 Oct 2012 10:32:10 -0700 (PDT) Received: from [66.94.237.127] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 17:32:09 -0000 Received: from [98.139.244.50] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 17:32:09 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.bf1.yahoo.com with NNFMP; 30 Oct 2012 17:32:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351618329; bh=bZayPGRH03iEGxGZusUTcKHTTTpB7BmJKMqFipmCRiQ=; 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=nQHe11mCJuqgzz6CP9pQ5UPvDLnKUKSFTGT9+AQvoj4zb6NLFv6AV7v20hPfK4M6iQshsyvYE7/5LISh8wifQyo7ls/oCAhIVqcjRvW4iEpMHHvk8hmr734+XAYb2L4eWwI2rtxIKKwA87yO6Qd1KRc4CRo4bNfjTnbIWmoxNcQ= X-Yahoo-Newman-Id: 678060.78394.bm@smtp112.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OHYwgksVM1leKz0L3BH5TiLWIktkNO5ZZ37MdcZn2ffQOS6 cczVgcv_BDqg75zi8iARYgJNwkgIlhuVB2bOqadj0GIMptzOGa1TR5N5kVS8 Kb9ringi6305KYOSdF6Sv4jujikSDq.KohPzkyBzA.9oCeV6MDDO1kn8YU98 myv8MjGwG062wYdAs8oUbT7yvzqBs6QK5SJp9HMmPjjvq.LUFwl055Reo5Ep jpvRPBqapwYe38CQ7uu.wJEm7qsa1sqtzybbTJjRlnVUOXMh9HtjtGbTGmKK 8jticUFNH7aXOxtTjqoHC0OSzfwhtKY5yVUd.RD8jpt8cgrSI5moQ74rZ1J0 NY_hkvxeUanWuHdJnB4STKmB7p34pR0C.Yq3bqxtDJA1vlGcBplP04902G9Z wuUMfGFDZj8Oaoz0YfN9bUGY2kGDl81paY93plORqs7kjkILeCahUBxFntjx k.MLHtMtf23Rn9Hum X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp112.sbc.mail.bf1.yahoo.com with SMTP; 30 Oct 2012 10:32:09 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 30 Oct 2012 10:31:58 -0700 From: Don Sturek To: Jonathan Hui Message-ID: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 In-Reply-To: <43B84D3E-3B20-4FBC-8AFE-A02FFCB913CE@gmail.com> 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: Tue, 30 Oct 2012 17:32:12 -0000 Hi Jonathan, What you wrote below sounds correct. For applications like Peter's that are sensitive to packet length and who may want to have application behavior similar to sending multicast requests from outside the multi-link subnet, they could utilize an application on the border router to ensure that IP in IP tunneling is not used (the application can support unicast commands to it targeting a collection of lamps or devices then the application can generate the MPL multicast locally to the multi-link subnet devices) Don On 10/30/12 10:15 AM, "Jonathan Hui" wrote: > >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. > >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 > From ulrich@herberg.name Tue Oct 30 13:46:30 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 CF16A21F8652 for ; Tue, 30 Oct 2012 13:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=2.276, 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 pHDmFezFFDsk for ; Tue, 30 Oct 2012 13:46:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B43921F860F for ; Tue, 30 Oct 2012 13:46:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so864172vbb.31 for ; Tue, 30 Oct 2012 13:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=58WDZeVwXVk0UCHH8FMIGYc4Ry7vUa6vbzKeT/3RY2M=; b=L9zuIpveh8cN4UWpigA00Xde3/9MEsTKmt8IGKC8Dqr8S+XyVRQlQ3SUXTaNl7EYnP kgeXbsm8NpvxXltpw6KCX8SEbfrkaSgp+WvgNKczsPBWn1JSd30UAyswk5J6iAjUquwT kfLbY20xavnGz2X2QjLJe80Ekdubf5cZvSyt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=58WDZeVwXVk0UCHH8FMIGYc4Ry7vUa6vbzKeT/3RY2M=; b=EOZUjUvHm38/mCO7mAbmi10E/o0SFcujW1RjGr2Czi7z/wO9U1ko7FTWpTPndmIFJI yA/7th1UqG7X1cLBh0IUrK+DFJQzjpy2XP2GhcqS7yJOiA8AR47fJuwbkaX56/436ZwN VmiSJWcYEK6M9Kqp0FEJ2MVJcvoPMaGVYenVt6CaJ41/4csk8DSDJg7EudfuLJ3eyOf9 cylepPZN0DtPZ3RUqYgeL315Fw/Ejx9CMXTcia7S3MNlRrrDo00rhbXTmfi+PXXSEYPY pdIogUh0NvcUDxP0x0HYit+RoQuJamnvcQd+jGGGBB7XsUbIHuCj3+M9iZiCsnnClvIj 82NA== MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr43781675vdb.33.1351629973712; Tue, 30 Oct 2012 13:46:13 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Tue, 30 Oct 2012 13:46:13 -0700 (PDT) In-Reply-To: References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> Date: Tue, 30 Oct 2012 13:46:13 -0700 Message-ID: From: Ulrich Herberg To: "Jonathan Hui (johui)" Content-Type: multipart/alternative; boundary=bcaec50162b573711a04cd4ce0b8 X-Gm-Message-State: ALoCoQn06eKfdMgozJAQYre6ZoRy+GVFkLxDFxBcG3zHAuoYy7K4KNlPq/ygtS56fb+JcCGRoHUM Cc: "richard.kelsey@silabs.com" , "roll@ietf.org WG" , Michael Richardson 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: Tue, 30 Oct 2012 20:46:30 -0000 --bcaec50162b573711a04cd4ce0b8 Content-Type: text/plain; charset=ISO-8859-1 Jonathan, thanks for addressing my comments. See below: On Tue, Oct 30, 2012 at 9:56 AM, Jonathan Hui (johui) wrote: > > [...] > > > > This document specifies the Multicast Protocol for Low power and > > Lossy Networks (MPL), which provides IPv6 multicast forwarding in > > constrained networks. MPL avoids the need to construct or maintain > > any multicast forwarding topology, disseminating multicast messages > > to all MPL forwarders in an MPL domain. By using the Trickle > > algorithm [RFC6206], MPL requires only small, constant state for each > > MPL device that initiates disseminations. The Trickle algorithm also > > allows MPL to be density-aware, allowing the communication rate to > > scale logarithmically with density. > > > > UH> I am not sure I understand the last sentence. What does it mean? > > How is that achieved? > > This is borrowing the wording out of RFC 6206. I can reference the RFC > here (again) and reference the academic papers (NSDI'04, CACM'08) that > present this result. > Yes, I think that would be a good idea. > > > UH> By the way, since this is a standards track document, is there any > > deployment experience? Implementations? > > As Don mentioned, there are a number of implementations on different > platforms. Peter van der Stok has also presented his implementation to the > WG. Cisco also has an implementation. > > The use of Trickle to disseminate messages has been implemented, deployed, > and published numerous times in the past. These implementations include > small message, medium message, and large message dissemination. Including > NSDI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, and TOSN'10. > Thanks! [...] > > > > MPL multicast scope The multicast scope that MPL uses when forwarding > > MPL multicast packets. In other words, the > > multicast scope of the IPv6 Destination Address > > of an MPL multicast packet. > > > > UH> An RFC reference to "scope" could be helpful. > > I assume you mean RFC 4007. > Yes, could be helpful to cite. > [...] > > > > > > > The > > MPL domain MUST be composed of at least one MPL > > multicast scope and MAY be composed of multiple > > MPL multicast scopes. > > > > UH> Why is that? Anyway, I am unsure whether one can say that a > > routing domain "consists" of multicast scopes. If I understand that > > correctly, the multicast scope just determines how far a message > > propagates. > > I think it would help to define "MPL multicast scope zone" in addition to > "MPL multicast scope". Then the correct wording for the text above is "MAY > be composed of multiple MPL multicast scope zones." Does that help? > I need to read the new revision to see if that is clearer. > [...] > > > > MPL delivers IPv6 multicast packets by disseminating them to all MPL > > forwarders within an MPL domain. MPL dissemination is a form of > > flood. An MPL forwarder may broadcast/multicast an MPL multicast > > packet out of the same physical interface on which it was received. > > Using link-layer broadcast/multicast allows MPL to forward multicast > > packets without explicitly identifying next-hop destinations. An MPL > > forwarder may also broadcast/multicast MPL multicast packets out > > other interfaces to disseminate the message across different links. > > MPL does not build or maintain a multicast forwarding topology to > > forward multicast packets. > > > > Any MPL forwarder may initiate the dissemination process by serving > > as an MPL seed for an original multicast packet. The MPL seed may or > > may not be the same device as the source of the original multicast > > packet. When the original multicast packet's source is outside the > > LLN, > > > > UH> LLN or MPL domain? How can a router determine if an incoming > > packet is inside our outside the MPL domain? > > MPL forwarding domain. Generally, the packet is outside when received on > an interface not used for MPL forwarding or when the original multicast > packet does not contain an MPL Option. > I think that should be spelled out in the draft. [...] > > > > UH> I think the whole introduction is not very easy to read. There is > > a lot of text about some details (IPv6-in-IPv6 tunnels, multiple > > interfaces), but the essential mechanism is hard to identify from the > > text. Also, there is nothing mentioned about what kind of state is > > required to be stored on each router (which information sets etc). > > A lot of this is combined with text in Section 5. Would you prefer to see > that pulled up here? > Yes, I think so. It could help to split the introduction section in subsections that illustrate the core mechanism (1.1), the required state (1.2), the message exchange (1.3) etc. in different subsections each. This would allow for easily understanding the core mechanism, before diving into IPv6 encapsulation etc. > > > Hui & Kelsey Expires April 22, 2013 [Page 6] > > Internet-Draft MPL October 2012 > > > > > > 4. Message Formats > > > > 4.1. MPL Option > > > > The MPL Option is carried in an IPv6 Hop-by-Hop Options header, > > > > UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options > header" > > I was following the text of RFC 2675. > Okay, you may be right. According to RFC2460, it is an IPv6 Extension header called "Hop-by-hop options header" ;-) > > > UH> More importantly, RFC6564 specifies: > > > > New options for the existing Hop-by-Hop Header SHOULD NOT be > > created or specified unless no alternative solution is feasible. > > Any proposal to create a new option for the existing Hop-by-Hop > > Header MUST include a detailed explanation of why the hop-by-hop > > behavior is absolutely essential in the document proposing the new > > option with hop-by-hop behavior. > > > > UH> I did not see such an explanation. > > How about: > > "The MPL option is needed because the IPv6 header does not provide unique > identification of IPv6 packets from the source." > Could you reuse a similar header, e.g., from RFC6621? It seems that multiple RFCs intend to define a header for identifying IPv6 packets with a sequence number. In addition, I think it could be helpful to argue why you cannot use a Destination Options header; the keyword from RFC6564 is "detailed explanation", so one sentence may not be enough. > > > [...] > > > > UH> 2 or 4 depending on what? > > Depending on the size of seed-id. > Maybe you can add that in this sentence to make that clearer. > [...] > > > > When receiving a new multicast packet, an MPL forwarder first > > utilizes proactive propagation to forward the MPL multicast packet. > > Proactive propagation reduces dissemination latency since it does not > > require discovering that neighboring devices have not yet received > > the MPL multicast packet. MPL forwarders utilize proactive > > propagation for newly received MPL multicast packets since they can > > assume that some neighboring MPL forwarders have yet to receive the > > MPL multicast packet. After a limited number of MPL multicast packet > > transmissions, the MPL forwarder may terminate proactive propagation > > for the MPL multicast packet. > > > > An MPL forwarder may optionally use reactive propagation to continue > > the dissemination process with lower communication overhead. With > > reactive propagation, neighboring MPL forwarders use ICMPv6 MPL > > messages to discover new MPL multicast messages that have not yet > > been received. When discovering that a neighboring MPL forwarder has > > not yet received a new MPL multicast packet, the MPL forwarder > > enables proactive propagation again. > > > > UH> There is not a lot of RFC2119 language in the above. Or is that > > defined later? Is this above section more like an introduction? > > This is more like an intro. Would you prefer to see this moved to the > overview section? > Yes. > [...] > > Adhering to > > Section 5 of RFC 6206 [RFC6206], this document defines the following: > > > > o This document defines a "consistent" transmission for proactive > > propagation as receiving an MPL multicast packet that has the same > > MPL seed identifier and sequence number as a buffered MPL packet. > > > > o This document defines an "inconsistent" transmission for proactive > > propagation as receiving an MPL multicast packet that has the same > > MPL seed identifier, the M flag set, and has a sequence number > > less than the buffered MPL multicast packet's sequence number. > > > > o This document does not define any external "events". > > > > o This document defines both MPL multicast packets and ICMPv6 MPL > > multicast packets as Trickle messages. These messages are defined > > in the sections below. > > > > UH> I don't see the term Trickle message used anywhere else. > > Used in RFC 6206. > A citation would help. > [...] > > 5.5. Transmission of ICMPv6 MPL Messages > > > > The MPL forwarder generates and transmits a new ICMPv6 MPL message > > whenever Trickle requests a transmission. > > > > UH> So for each data packet there would be a new ICMPv6 message? > > Wouldn't that create a lot of overhead? > > Nope. The ICMPv6 message is a list of sliding windows. > Okay, I guess I am not quite clear yet on how much bandwidth the ICMPv6 messages would consume (how often they are sent etc) in relation to the data traffic. > > > UH> To which address is the ICMP message sent? On which interface? > > Destination Address is specified in Section 4.2. Sent on all interfaces > that are used for forwarding MPL multicast packets. > Could be helpful to point to that section here. [...] > > When an MPL forwarder determines that it has at least one buffered > > MPL multicast packet that has not yet been received by a neighbor, > > the MPL forwarder resets the Trickle timer associated with reactive > > propagation. Additionally, for each buffered MPL multicast packet > > that should be transferred, the MPL forwarder MUST reset the Trickle > > timer and reset e to 0 for proactive propagation. If the Trickle > > timer for proactive propagation has already stopped execution, > > > > UH> Which timer? I thought there is one timer per packet in the > > proactive mode? > > How about: > > "the Trickle timer(s) associated with the buffered packet(s) and reset e > associated with the buffered packet(s) to 0 for proactive propagation". > Okay. That brings me to a point you mentioned above, the constant state requirement. It seems there is a timer for each packet in proactive mode. Wouldn't that mean the state requirement for these timers is O(n) for n packets? Or are the timers bound by the size of the sliding window? What is your plan regarding the security considerations section? Will that be added in the next revision? Best Ulrich --bcaec50162b573711a04cd4ce0b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jonathan,

thanks for addressing my comments. See below:<= br>
On Tue, Oct 30, 2012 at 9:56 AM, Jonathan= Hui (johui) <johui@cisco.com> wrote:

[...]
>
> =A0 This document specifies the Multicast Protocol for Low power and > =A0 Lossy Networks (MPL), which provides IPv6 multicast forwarding in<= br> > =A0 constrained networks. =A0MPL avoids the need to construct or maint= ain
> =A0 any multicast forwarding topology, disseminating multicast message= s
> =A0 to all MPL forwarders in an MPL domain. =A0By using the Trickle > =A0 algorithm [RFC6206], MPL requires only small, constant state for e= ach
> =A0 MPL device that initiates disseminations. =A0The Trickle algorithm= also
> =A0 allows MPL to be density-aware, allowing the communication rate to=
> =A0 scale logarithmically with density.
>
> UH> I am not sure I understand the last sentence. What does it mean= ?
> How is that achieved?

This is borrowing the wording out of RFC 6206. =A0I can reference the= RFC here (again) and reference the academic papers (NSDI'04, CACM'= 08) that present this result.

Yes, I th= ink that would =A0be a good idea.

=A0

> UH> By the way, since this is a standards track document, is there = any
> deployment experience? Implementations?

As Don mentioned, there are a number of implementations on different = platforms. =A0Peter van der Stok has also presented his implementation to t= he WG. =A0Cisco also has an implementation.

The use of Trickle to disseminate messages has been implemented, deployed, = and published numerous times in the past. =A0These implementations include = small message, medium message, and large message dissemination. =A0Includin= g NSDI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, an= d TOSN'10.


Thanks!

=A0[...]
>
> =A0 MPL multicast scope The multicast scope that MPL uses when forward= ing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL multicast packets. =A0= In other words, the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast scope of the IPv= 6 Destination Address
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of an MPL multicast packet= .
>
> UH> An RFC reference to "scope" could be helpful.

I assume you mean RFC 4007.


<= /div>
Yes, could be helpful to cite.

=A0
=
[...]

>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL domain MUST be compose= d of at least one MPL
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast scope and MAY be= composed of multiple
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL multicast scopes.
>
> UH> Why is that? Anyway, I am unsure whether one can say that a
> routing domain "consists" of multicast scopes. If I understa= nd that
> correctly, the multicast scope just determines how far a message
> propagates.

I think it would help to define "MPL multicast scope zone" = in addition to "MPL multicast scope". =A0Then the correct wording= for the text above is "MAY be composed of multiple MPL multicast scop= e zones." =A0Does that help?


I need to read the new revi= sion to see if that is clearer.

=A0
[...]
>
> =A0 MPL delivers IPv6 multicast packets by disseminating them to all M= PL
> =A0 forwarders within an MPL domain. =A0MPL dissemination is a form of=
> =A0 flood. =A0An MPL forwarder may broadcast/multicast an MPL multicas= t
> =A0 packet out of the same physical interface on which it was received= .
> =A0 Using link-layer broadcast/multicast allows MPL to forward multica= st
> =A0 packets without explicitly identifying next-hop destinations. =A0A= n MPL
> =A0 forwarder may also broadcast/multicast MPL multicast packets out > =A0 other interfaces to disseminate the message across different links= .
> =A0 MPL does not build or maintain a multicast forwarding topology to<= br> > =A0 forward multicast packets.
>
> =A0 Any MPL forwarder may initiate the dissemination process by servin= g
> =A0 as an MPL seed for an original multicast packet. =A0The MPL seed m= ay or
> =A0 may not be the same device as the source of the original multicast=
> =A0 packet. =A0When the original multicast packet's source is outs= ide the
> =A0 LLN,
>
> UH> LLN or MPL domain? How can a router determine if an incoming > packet is inside our outside the MPL domain?

MPL forwarding domain. =A0Generally, the packet is outside when= received on an interface not used for MPL forwarding or when the original = multicast packet does not contain an MPL Option.


I think that should be spelled out in the draft.<= /div>



=A0[...]
>
> UH> I think the whole introduction is not very easy to read. There = is
> a lot of text about some details (IPv6-in-IPv6 tunnels, multiple
> interfaces), but the essential mechanism is hard to identify from the<= br> > text. Also, there is nothing mentioned about what kind of state is
> required to be stored on each router (which information sets etc).

A lot of this is combined with text in Section 5. =A0Would you = prefer to see that pulled up here?

Yes,= I think so.=A0It could help to split the introduction section in subsectio= ns that illustrate the core mechanism (1.1), the required state (1.2), the = message exchange (1.3) etc. in different subsections each. This would allow= for easily understanding the core mechanism, before diving into IPv6 encap= sulation etc.


=A0

> Hui & Kelsey =A0 =A0 =A0 =A0 =A0 =A0 Expires April 22, 2013 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 6]
> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MPL =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October 2012
>
>
> 4. =A0Message Formats
>
> 4.1. =A0MPL Option
>
> =A0 The MPL Option is carried in an IPv6 Hop-by-Hop Options header, >
> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Opt= ions header"

I was following the text of RFC 2675.

=

Okay, you may be right. According to RFC2460, it is an = IPv6 Extension header called "Hop-by-hop options header" ;-)


=A0

> UH> More importantly, =A0RFC6564 specifies:
>
> =A0 =A0 =A0New options for the existing Hop-by-Hop Header SHOULD NOT b= e
> =A0 =A0 =A0created or specified unless no alternative solution is feas= ible.
> =A0 =A0 =A0Any proposal to create a new option for the existing Hop-by= -Hop
> =A0 =A0 =A0Header MUST include a detailed explanation of why the hop-b= y-hop
> =A0 =A0 =A0behavior is absolutely essential in the document proposing = the new
> =A0 =A0 =A0option with hop-by-hop behavior.
>
> UH> I did not see such an explanation.

How about:

"The MPL option is needed because the IPv6 header does not provide uni= que identification of IPv6 packets from the source."
<= div>
Could you reuse a similar header, e.g., from RFC6621? It= seems that multiple RFCs intend to define a header for identifying IPv6 pa= ckets with a sequence number.
In addition, I think it could be helpful to argue why you cannot use a= Destination Options header; the keyword from RFC6564 is "detailed exp= lanation", so one sentence may not be enough.

=A0

> [...]
>
> UH> 2 or 4 depending on what?

Depending on the size of seed-id.

Maybe you can add that in this sentence to make that clearer.
= =A0
[...]
>
> =A0 When receiving a new multicast packet, an MPL forwarder first
> =A0 utilizes proactive propagation to forward the MPL multicast packet= .
> =A0 Proactive propagation reduces dissemination latency since it does = not
> =A0 require discovering that neighboring devices have not yet received=
> =A0 the MPL multicast packet. =A0MPL forwarders utilize proactive
> =A0 propagation for newly received MPL multicast packets since they ca= n
> =A0 assume that some neighboring MPL forwarders have yet to receive th= e
> =A0 MPL multicast packet. =A0After a limited number of MPL multicast p= acket
> =A0 transmissions, the MPL forwarder may terminate proactive propagati= on
> =A0 for the MPL multicast packet.
>
> =A0 An MPL forwarder may optionally use reactive propagation to contin= ue
> =A0 the dissemination process with lower communication overhead. =A0Wi= th
> =A0 reactive propagation, neighboring MPL forwarders use ICMPv6 MPL > =A0 messages to discover new MPL multicast messages that have not yet<= br> > =A0 been received. =A0When discovering that a neighboring MPL forwarde= r has
> =A0 not yet received a new MPL multicast packet, the MPL forwarder
> =A0 enables proactive propagation again.
>
> UH> There is not a lot of RFC2119 language in the above. Or is that=
> defined later? Is this above section more like an introduction?

This is more like an intro. =A0Would you prefer to see this mov= ed to the overview section?

Yes.
<= div>
=A0
[...]
> =A0 =A0Adhering to
> =A0 Section 5 of RFC 6206 [RFC6206], this document defines the followi= ng:
>
> =A0 o =A0This document defines a "consistent" transmission f= or proactive
> =A0 =A0 =A0propagation as receiving an MPL multicast packet that has t= he same
> =A0 =A0 =A0MPL seed identifier and sequence number as a buffered MPL p= acket.
>
> =A0 o =A0This document defines an "inconsistent" transmissio= n for proactive
> =A0 =A0 =A0propagation as receiving an MPL multicast packet that has t= he same
> =A0 =A0 =A0MPL seed identifier, the M flag set, and has a sequence num= ber
> =A0 =A0 =A0less than the buffered MPL multicast packet's sequence = number.
>
> =A0 o =A0This document does not define any external "events"= .
>
> =A0 o =A0This document defines both MPL multicast packets and ICMPv6 M= PL
> =A0 =A0 =A0multicast packets as Trickle messages. =A0These messages ar= e defined
> =A0 =A0 =A0in the sections below.
>
> UH> I don't see the term Trickle message used anywhere else.
Used in RFC 6206.


= A citation would help.

=A0
[...]
> 5.5. =A0Transmission of ICMPv6 MPL Messages
>
> =A0 The MPL forwarder generates and transmits a new ICMPv6 MPL message=
> =A0 whenever Trickle requests a transmission.
>
> UH> So for each data packet there would be a new ICMPv6 message? > Wouldn't that create a lot of overhead?

Nope. =A0The ICMPv6 message is a list of sliding windows.


Okay, I guess I am not quite clear = yet on how much bandwidth the ICMPv6 messages would consume (how often they= are sent etc) in relation to the data traffic.


=A0

> UH> To which address is the ICMP message sent? On which interface?<= br>
Destination Address is specified in Section 4.2. =A0Sent on all inter= faces that are used for forwarding MPL multicast packets.
<= div>
Could be helpful to point to that section here.
=A0[...]


> =A0 When an MPL forwarder determines that it has at least one buffered=
> =A0 MPL multicast packet that has not yet been received by a neighbor,=
> =A0 the MPL forwarder resets the Trickle timer associated with reactiv= e
> =A0 propagation. =A0Additionally, for each buffered MPL multicast pack= et
> =A0 that should be transferred, the MPL forwarder MUST reset the Trick= le
> =A0 timer and reset e to 0 for proactive propagation. =A0If the Trickl= e
> =A0 timer for proactive propagation has already stopped execution,
>
> UH> Which timer? I thought there is one timer per packet in the
> proactive mode?

How about:

"the Trickle timer(s) associated with the buffered packet(s) and reset= e associated with the buffered packet(s) to 0 for proactive propagation&qu= ot;.

Okay. That brings me to a point yo= u mentioned above, the constant state requirement. It seems there is a time= r for each packet in proactive mode. Wouldn't that mean the state requi= rement for these timers is O(n) for n packets? Or are the timers bound by t= he size of the sliding window?


What is your plan regarding the security= considerations section? Will that be added in the next revision?


Best
Ulrich
--bcaec50162b573711a04cd4ce0b8-- From jblack.ietf@yahoo.com Tue Oct 30 13:41:57 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 B9F1821F864D for ; Tue, 30 Oct 2012 13:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.415 X-Spam-Level: * X-Spam-Status: No, score=1.415 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FRT_BELOW2=2.154, 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 7ExpUoBrgMaH for ; Tue, 30 Oct 2012 13:41:57 -0700 (PDT) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id BE2EC21F8556 for ; Tue, 30 Oct 2012 13:41:56 -0700 (PDT) Received: from [98.139.212.146] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2012 20:41:56 -0000 Received: from [98.139.212.231] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2012 20:41:56 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 30 Oct 2012 20:41:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 201633.60800.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 51114 invoked by uid 60001); 30 Oct 2012 20:41:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351629716; bh=r6alDQCSNBZriknshMbIP4rcPXldWPpZb2lObBGhSDI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=53uh8jOnNqAm7wfz07gCU62XLGENHdpWihHdRrZfoNIGOSn9Rd/MhJFU8CZC/yy4jOTep25pSJ7epu8IQHsklaCk2kiOrSF3UFAtW4j64P3j8lPeq9V+m0zwvAuP1e+IjUr4TtUzlgnJ2hVCyxNXecd3s4ZtDQL5fSw9z65ZJ64= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=S8fZoRdNkniEWL4XC1EnoIkzBF8h0PRwapBZb8ZtNNJ6orKOkg+TSs0I+K3jRi4JpmccdmjJnY8gi5k6OmXSSMG0HjdLM5HURcEaqv2f3huHZIvPQkGX5pf12R5SRz6wQu0UG0RR+9y4v+vz+bVGsRESZKoZ5HyX3SAsR3oO/jQ=; X-YMail-OSG: h3f.gRkVM1lqcGxzgiz9kEKp4KfLqJXZZVa3CXa_0SPiqXr 0Wq4UmepRx3fG_vDC7Uen5bAKnZZbw08Wn8DNP8B8TRRV4zHCUmVX_R_00eW n29eSCsh6AekMJ8Ggn0bgpMsYQgVarNPNwUw1PYvKScf1bKRPiwXwizu729W OumQ0jSQxjQajQdlMR0sNG7TJi66vEZ0rbrOppFAN3yoIQ316hw0lpyrxeid CgoyJXj11tw7NjDbXobTcO.C6sBALhPnnpdvqU9WEiMyIe11iZ3uAw3hH96O DiCcXLSPFfcV_TvAMbMKcSFioab5z.UyOXemwVysoJq2KYooeaHMIrb8nO8G xBz8D0G99odVD1fmEPthIty5Af6xPJrDf3q.BuQrc0Hxm8.TIbCY7t.WUtMU GXKuAgoeoYJDhV4Xt_b2XLy6158gh25uAJucAeXcTZvieFRYES2H2MpeRoP0 zptkFFQB3Yd5.v2.fqgkJ6Dcg1_iDBBXS7NZdQZ5O8dZYfJNjxuUeqXY.lLD lsD0UrFzuBDsQprgijMxwe.WdsioF7A-- Received: from [67.213.218.74] by web160605.mail.bf1.yahoo.com via HTTP; Tue, 30 Oct 2012 13:41:56 PDT X-Rocket-MIMEInfo: 001.001, RnJvbSBsb29raW5nIGF0IHRoZSBkcmFmdHMgLSBvbmUgaGFzIGEgY2lzY28gYXV0aG9yIGFuZCB0aGUgb3RoZXIgZG9lc24ndCAtIGhtbW0uCgrCoMKgwqAgSm9uCgoKUGhpbGwgTGV2aXMgc2FpZCBvbiBPY3RvYmVyIDMwLCAyMDEyIGF0IDg6MTkgYW06CgpJJ20gYSBsaXR0bGUgd29ycmllZCB0aGF0IHRoZSBvbmUgZHJhZnQgd2hpY2ggaXMgYmFzZWQgb24gYSByZWFsLCBkb2N1bWVudGVkIHByb2JsZW0gZW5jb3VudGVyZWQgaW4gYSBkZXBsb3ltZW50IGlzIGNvbnNpZGVyZWQgdG8gaGF2ZSAibm8gdHJhY3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Tue, 30 Oct 2012 13:41:56 -0700 (PDT) From: Jon Black To: "pal@cs.stanford.edu" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1933122451-1975512255-1351629716=:36391" Cc: "jeonggil.ko@etri.re.kr" , "roll@ietf.org" , "mcr@sandelman.ca" Subject: Re: [Roll] Draft Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jon Black List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 21:44:13 -0000 ---1933122451-1975512255-1351629716=:36391 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >From looking at the drafts - one has a cisco author and the other doesn't -= hmmm.=0A=0A=C2=A0=C2=A0=C2=A0 Jon=0A=0A=0APhill Levis said on October 30, = 2012 at 8:19 am:=0A=0AI'm a little worried that the one draft which is base= d on a real, documented problem encountered in a deployment is considered t= o have "no traction on the mailing list", despite several discussions, whil= e "Industrial Deterministic Routing Extension for Low-Power and Lossy Netwo= rks," which I have never seen mentioned on the mailing list (can someone po= int out that I'm wrong) does have a slot. This doesn't mean that the other = draft shouldn't have a slot; I just don't understand the process by which s= lots are being decided.=0A=0APhil=0A=0AOn Oct 29, 2012, at 11:44 PM, JP Vas= seur (jvasseur) wrote: =0ADear all, Many Thanks for your email - we did dis= cuss about it but there pretty much no traction on the mailing list on this= item.=0APlease continue to use the mailing at will. This is why the item i= s not part of the agenda indeed. Many Thanks. JP and Michael. On Oct 30, 20= 12, at 3:14 AM, JeongGil Ko wrote: =0A>Dear WG Chairs, For some reason... t= his email seems to be ignored=E2=80=A6 any responses? -John ------=0AJeong= Gil Ko, Ph.D.=0AResearcher=0AElectronics and Telecommunications Research In= stitute (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 26, 2012, at= 9:39 PM, =EC=A0=95=EC=A2=85=EC=88=98 wrote: =0A>>JP, = John has requested a slot. But we've not been replied anything. Is the agen= da already fixed? Regards,=0A-Jongsoo 2012. 10. 25., =EC=98=A4=EC=A0=84 6:4= 1, JeongGil Ko =EC=9E=91=EC=84=B1: =0A>>>JP, I've = also put in a request for a slot at the meeting in Atlanta for presenting "= draft-ko-roll-mix-network-pathology" but I do not see this on the agenda. T= his draft discusses about a critical and practical performance issue of RPL= networks (both collection and downwards) when they are intentionally or ac= cidentally deployed with devices of different MOPs. I believe that such an = issue is important to discuss as a group. Thanks. -John ------=0AJeongGil K= o, Ph.D.=0AResearcher=0AElectronics and Telecommunications Research Institu= te (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 25, 2012, at 3:06= AM, JP Vasseur (jvasseur) wrote: =0A>>>>Dear all, please find bellow the d= raft agenda for ROLL's WG meeting in Atlanta - let us know if you have any = comment: 1) Agenda/admin (Chairs - 5mn) [5] 2) WG Status (Chairs - 10 mn) [= 15] 3) Security Framework and Applicability Statement template=0A(Michael -= 10m) [25]=0Adraft=3Ddraft-richardson-roll-applicability-template-00 4) RPL= applicability in industrial networks=0Adraft-phinney-roll-rpl-industrial-a= pplicability-01=0A(Pascal - 10mn) [35] 5) Industrial Deterministic Routing = Extension for Low-Power=0Aand Lossy Networks (M. Wei - 10mn) [45] 6) RPL de= ployment experience in large scale networks=0Adraft-hui-vasseur-roll-rpl-de= ployment (TBD - 5mn) [50] 7) RPL applicability in industrial networks=0Adra= ft-phinney-roll-rpl-industrial-applicability-01=0A(Pascal - 10mn) [60] 8) L= oop Free DODAG Local Repair (Jianlin Guo - 10mn) [70]=0Adraft-guo-roll-loop= -free-dodag-repair Thanks. JP and Michael.=0A______________________________= _________________=0ARoll mailing list Roll@ietf.org https://www.ietf.org/ma= ilman/listinfo/roll =0A>>>>_______________________________________________= =0ARoll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/ro= ll =0A>>>_______________________________________________=0ARoll mailing lis= t Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =0A>____________= ___________________________________=0ARoll mailing list Roll@ietf.org https= ://www.ietf.org/mailman/listinfo/roll =0A__________________________________= _____________=0ARoll mailing list Roll@ietf.org https://www.ietf.org/mailma= n/listinfo/roll ---1933122451-1975512255-1351629716=:36391 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A
From looking at the drafts - one h=
as a cisco author and the other doesn't - hmmm.

=
    Jon

Phill Levis said on October 30, 2012 at 8:19 am:

I'm a l=
ittle worried that the one draft which is based on a real, documented probl=
em encountered in a deployment is considered to have "no traction on the ma=
iling list", despite several discussions, while "Industrial Deterministic R=
outing Extension for Low-Power and Lossy Networks," which I have never seen=
 mentioned on the mailing list (can someone point out that I'm wrong) does =
have a slot. This doesn't mean that the other draft shouldn't have a slot; =
I just don't understand the process by which slots are being decided.=0A=0A=
Phil=0A=0AOn Oct 29, 2012, at 11:44 PM, JP Vasseur (jvasseur) wrote:=0A=0A<=
/pre>
Dea=
r all,=0A=0AMany Thanks for your email - we did discuss about it but there =
pretty much no traction on the mailing list on this item.=0APlease continue=
 to use the mailing at will. This is why the item is not part of the agenda=
 indeed.=0A=0AMany Thanks.=0A=0AJP and Michael.=0A=0AOn Oct 30, 2012, at 3:=
14 AM, JeongGil Ko wrote:=0A=0A
Dear WG Chairs,=0A=0AFor some reason... this e=
mail seems to be ignored=E2=80=A6 any responses? =0A=0A-John=0A=0A------=0A=
JeongGil Ko, Ph.D.=0AResearcher=0AElectronics and Telecommunications Resear=
ch Institute (ETRI)=0Ahttp://sites.google.com/site/jeonggilko/=0A=0AOn Oct 26, 2012, at 9:39 PM, =EC=A0=95=EC=A2=85=EC=88=98 <jsjeong@etri=
.re.kr> wrote:=0A=0A
JP,=0A=0AJohn has requested a slot. But we've not =
been replied anything. Is the agenda already fixed?=0A=0ARegards,=0A-Jongso=
o=0A=0A2012. 10. 25., =EC=98=A4=EC=A0=84 6:41, JeongGil Ko <jeonggil.ko@e=
tri.re.kr> =EC=9E=91=EC=84=B1:=0A=0A
JP,=0A=0AI've also put in a reques=
t for a slot at the meeting in Atlanta for presenting "draft-ko-roll-mix-ne=
twork-pathology" but I do not see this on the agenda. This draft discusses =
about a critical and practical performance issue of RPL networks (both coll=
ection and downwards) when they are intentionally or accidentally deployed =
with devices of different MOPs. I believe that such an issue is important t=
o discuss as a group.=0A=0AThanks.=0A=0A-John=0A=0A------=0AJeongGil Ko, Ph=
.D.=0AResearcher=0AElectronics and Telecommunications Research Institute (E=
TRI)=0Ahttp://sites.google.com/site/jeonggilko/=0A=0AOn Oct 2=
5, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote:=0A=0A
Dear all,=0A=0Aplease =
find bellow the draft agenda for ROLL's WG meeting in Atlanta - let us know=
 if you have any comment:=0A=0A1) Agenda/admin (Chairs - 5mn) [5]=0A=0A2) W=
G Status (Chairs - 10 mn) [15]=0A=0A3) Security Framework and Applicability=
 Statement template=0A(Michael - 10m) [25]=0Adraft=3Ddraft-richardson-roll-=
applicability-template-00=0A=0A4) RPL applicability in industrial networks=
=0Adraft-phinney-roll-rpl-industrial-applicability-01=0A(Pascal - 10mn) [35=
]=0A=0A5) Industrial Deterministic Routing Extension for Low-Power=0Aand Lo=
ssy Networks (M. Wei - 10mn) [45]=0A=0A6) RPL deployment experience in larg=
e scale networks=0Adraft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50]=
=0A=0A7) RPL applicability in industrial networks=0Adraft-phinney-roll-rpl-=
industrial-applicability-01=0A(Pascal - 10mn) [60]=0A=0A8) Loop Free DODAG =
Local Repair (Jianlin Guo - 10mn) [70]=0Adraft-guo-roll-loop-free-dodag-rep=
air=0A=0AThanks.=0A=0AJP and Michael.=0A___________________________________=
____________=0ARoll mailing list=0ARoll@ietf.org=0Ahttps://www.iet=
f.org/mailman/listinfo/roll=0A
_______=
________________________________________=0ARoll mailing list=0ARoll@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/roll=0A
_______________________________________________=0ARo=
ll mailing list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/lis=
tinfo/roll=0A
___________=
____________________________________=0ARoll mailing list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll=0A
_______________________________________________=0ARoll mai=
ling list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/=
roll=0A
=0A=0A
---1933122451-1975512255-1351629716=:36391-- From guo@merl.com Tue Oct 30 15:09:39 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 2F75E21F85B3 for ; Tue, 30 Oct 2012 15:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUDa3qSansNK for ; Tue, 30 Oct 2012 15:09:38 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014E221F85AC for ; Tue, 30 Oct 2012 15:09:37 -0700 (PDT) Received: from tsumi.merl.com (tsumi.merl.com [137.203.134.9]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id q9UM9RaW016536; Tue, 30 Oct 2012 18:09:27 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by tsumi.merl.com (8.12.10/8.12.10) with ESMTP id q9UM9GrV011429; Tue, 30 Oct 2012 18:09:27 -0400 Message-ID: <5090500B.9050403@merl.com> Date: Tue, 30 Oct 2012 18:09:15 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Philip Levis References: <50194329.3040003@merl.com> <501945CC.5040801@merl.com> <5086A598.7030508@merl.com> <23378.1351166893@sandelman.ca> <50894640.1080804@merl.com> <97B69B30E0EF244B940B65EA541E3F2D21564932@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508A8FDA.4040104@merl.com> <97B69B30E0EF244B940B65EA541E3F2D2156744D@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AAE0D.8030903@merl.com> <97B69B30E0EF244B940B65EA541E3F2D215676A7@DBXPRD0510MB395.eurprd05.prod.outlook.com> <508AE1F9.1080600@merl.com> <508FF9D3.40805@merl.com> <6B8958C3-3B39-4CA7-B570-BC7D6E8084AE@cs.stanford.edu> In-Reply-To: <6B8958C3-3B39-4CA7-B570-BC7D6E8084AE@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [Roll] Loop free local DODAG repair solution 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: Tue, 30 Oct 2012 22:09:39 -0000 It is local in the sense that repair does not propagate far away from initiation node. It also depends on the definition of "local', 1 hop only or 2 hop still considered as local. Consider a case where a node N's parent node becomes unreachable. Ranks of all reachable neighbors are greater than node N's rank. Using DIS, node N has to increase its rank greater than its old rank. With this increased rank, node N needs to transmit a DIO. If any of node N's children does not receive this DIO (which is typical in lossy network), a loop may be created. Even though all children receive this DIO, this DIO may result in entire sub-tree to increase their ranks. DRQ/DRP repair does not increase rank of any node, therefore it is loop free. Jianlin On 10/30/2012 1:03 PM, Philip Levis wrote: > So it's basically a multihop DIS? How is that then a local repair? In the case of a subtree becoming disconnected due to the top of the subtree having a null parent set, those nodes at the top would issue a DIS with Solicited Information to repair their local routes (next hop). Nodes below them in the DODAG shouldn't have to trigger a local repair. > > Put another way, can you describe a concrete case where DIS with Solicited Information can't solve the problem, yet DRQ/DRP can? Or is this purely an efficiency optimization? If the latter, I'd love to see concrete results indicating the savings (from a real LLN, not simulation). > > Phil > > On Oct 30, 2012, at 9:01 AM, Jianlin Guo wrote: > >> Hi Phil, >> >> Thank you for your valuable comments. There may be one more major case where a RPL node has a null parent set, that is, parent node of a RPL node becomes unreachable. This is a typical case in lossy networks. For example, a mobile object could block wireless link between two RPL nodes. >> >> The key differences between DIS and DRQ/DRP are: >> 1) A DRQ message can travel multiple hops. # of hops is controlled by a parameter named MH (Maximum Hop) in DRQ message. >> 2) Upon receiving a DRQ message, a neighbor node responds with DRP message only if neighbor node has non-empty parent set and a rank lower than rank of the DRQ transmitting node. Otherwise, it may forward DRQ message to its parent node. >> 3) Receiving of a DRP message guarantees the discovery of a new parent node. >> 4) Value of MH parameter controls local repair. MH can be set to a small value, e.g. 1,2 or 3, so that DRQ message do not travel too far. >> >> Jianlin >> On 10/29/2012 6:09 PM, Philip Levis wrote: >>> I'd like to take a step back here and discuss MaxRankIncrease and the notion of null parent sets. >>> >>> The two major cases where a RPL node has a null parent set are: >>> 1) The node has no members in its neighbor set >>> 2) The node has members of its neighbor set, but all of them advertise a Rank of INFINITE_RANK. The major case we're concerned about here is when rule 3 of 8.2.2.4 requires nodes to advertise INFINITE_RANK due to the value of MaxRankIncrease. >>> >>> I don't think the local repair scheme will fix case 1. So we're really talking about case 2. >>> >>> MaxRankIncrease emerged in specifying RPL as a way to support both ZigBee-style centralized periodic tree reconstruction triggers (MaxRankIncrease == 0) as well as CTP-style completely distributed operation while simultaneously providing a cap to the count-to-infinity problem. So really, the issue here is when you have a network with a small MaxRankIncrease and don't want to reconstruct the entire tree, there are valid parents that could be used, but a node does not have them in its neighbor/parent set. >>> >>> Thinking about it this way (am I wrong?), I am a bit confused by the claim that the draft is a local repair. Assuming a node has to follow rule 3 in 8.2.2.4, this is not a repair mechanism, but rather a neighbor discovery mechanism. Could you explain how DRQ/DRP solve a problem that a DIS with a proper Solicited Information option can't solve? This was the original intent of DIS with Solicited Information. Or perhaps I'm not understanding DRQ/DRP correctly? >>> >>> Phil >>> >>> On Oct 26, 2012, at 12:18 PM, Jianlin Guo wrote: >>> >>>> Thank you for the paper. I agree with [1] on that "dismantling of the sub-DAG, rooted at the node doing the rank increase, causes more turmoil in the network than the routing loops themselves". >>>> >>>> Now, consider a case in which a node's parent set becomes empty. In this case, RPL provides following set of actions: >>>> >>>> 1) Start its own floating DODAG >>>> 2) Poison the broken path >>>> 3) Trigger a local repair >>>> >>>> Both 1) and 2) actions will increase packet delivery delay time (which may be not acceptable for some applications) and possibly cause packet dropping due to limited buffer size of a LLN node (which may also be not acceptable for some applications). So, trigger a local repair is a practical option. Our local repair mechanism is designed for this purpose and it does not create any loops. >>>> >>>> Jianlin >>>> >>>> On 10/26/2012 12:10 PM, C Chauvenet wrote: >>>>> Le 26 oct. 2012 à 17:36, Jianlin Guo a écrit : >>>>> >>>>>> We compared performance metrics such as packet delivery rate. >>>>> Ok. >>>>> >>>>> In general do you have a document about your experiments that you would like to share ? >>>>> I think it could be a good way to defend your mechanism. >>>>> >>>>> There are 2 sub questions related to your draft : >>>>> >>>>> - Is there a strong need for an additional mechanism to prevent loops ? (the HbH header option mentioned by phil is already there). >>>>> - Is your mechanism the good way to do so (overhead induced, efficiency...) >>>>> >>>>> As mentioned by Phil, this subject has been previously discussed inside ROLL few years ago, and did not recommend to add such mechanisms. >>>>> >>>>> For instance, [1] concludes that >>>>> >>>>> "the turmoil caused >>>>> by dismantling of the sub-DAGs in order to increase ranks >>>>> may be much more than what the routing loops themselves >>>>> will cause. Consequently, the use of such loop avoidance >>>>> mechanism in the operation of a DAG based routing protocol >>>>> can not be universally recommended." >>>>> >>>>> [1] : http://www.emmanuelbaccelli.org/publications/AINA_2010.pdf >>>>> >>>>> Best, >>>>> >>>>> Cédric. >>>>> >>>>>> On 10/26/2012 11:21 AM, C Chauvenet wrote: >>>>>>> Hi, >>>>>>> Thank you for your answer. >>>>>>> See inline. >>>>>>> >>>>>>> Le 26 oct. 2012 à 15:27, Jianlin Guo a écrit : >>>>>>> >>>>>>>> On 10/25/2012 12:06 PM, C Chauvenet wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Le 25 oct. 2012 à 16:01, Jianlin Guo a écrit : >>>>>>>>> >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> For your first question, draft-clausen-lln-rpl-experiences-04 pointed out that "it can be observed that with current implementations of RPL, such as the ContikiRPL implementation, loops do occur - and, frequently. During the same experiments described in Section 13, a snapshot of the DODAG was made every ten seconds. In 74.14% of the 4114 snapshots, at least one loop was observed". >>>>>>>>> Is it something that you observed in your own deployments ? >>>>>>>>> More specifically : did you find similar results ? >>>>>>>> We observed the occurrence of loops, unfortunately we did not measure the percentage. >>>>>>> So how did you evaluate the benefit of the mechanism that you proposed ? >>>>>>> >>>>>>> Cédric. >>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Cédric. >>>>>>>>> >>>>>>>>>> For your second question, further investigation and experiments are needed. >>>>>>>>>> >>>>>>>>>> Jianlin >>>>>>>>>> >>>>>>>>>> On 10/25/2012 8:08 AM, Michael Richardson wrote: >>>>>>>>>>> Jianlin Guo >>>>>>>>>>> wrote: >>>>>>>>>>> JG> Dear ROLL WG members, >>>>>>>>>>> >>>>>>>>>>> JG> As we all know that loop is an open issue in RPL. Experiment shows that loop >>>>>>>>>>> JG> occurs quite often. We have proposed a loop free local DODAG >>>>>>>>>>> >>>>>>>>>>> Can you quantify "quite often"? >>>>>>>>>>> Do you have any metrics for how often loops occur, and what the cost is >>>>>>>>>>> of their repair? >>>>>>>>>>> >>>>>>>>>>> I think that the WG would be very very very interested in additional -experiences >>>>>>>>>>> draft, or pointers to papers explaining same, that gives a repeateable >>>>>>>>>>> experiment in which loops are observed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Roll mailing 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 stokcons@xs4all.nl Wed Oct 31 01:38: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 C644621F8736 for ; Wed, 31 Oct 2012 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.425 X-Spam-Level: X-Spam-Status: No, score=0.425 tagged_above=-999 required=5 tests=[AWL=0.929, 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 lEe1HKKmTJdX for ; Wed, 31 Oct 2012 01:38:10 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id DDAC021F86C7 for ; Wed, 31 Oct 2012 01:38:09 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9V8b4AR000600; Wed, 31 Oct 2012 09:37:06 +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, 31 Oct 2012 09:37:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 31 Oct 2012 09:37:04 +0100 From: peter van der Stok To: Don Sturek Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (rRKb+KgROlucMoRaskapdB7JZvpkntpn) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Jonathan Hui , 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: 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, 31 Oct 2012 08:38:10 -0000 Hi Don, Jontahan, The constraints seem to be clear. Looking forward to the new text with more information about zones as suggested in the answer to Ulrich peter Don Sturek schreef op 2012-10-30 18:31: > Hi Jonathan, > > What you wrote below sounds correct. > > For applications like Peter's that are sensitive to packet length and > who > may want to have application behavior similar to sending multicast > requests from outside the multi-link subnet, they could utilize an > application on the border router to ensure that IP in IP tunneling is > not > used (the application can support unicast commands to it targeting a > collection of lamps or devices then the application can generate the > MPL > multicast locally to the multi-link subnet devices) > > Don > > > On 10/30/12 10:15 AM, "Jonathan Hui" wrote: > >> >>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. >> >>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 >> From stokcons@xs4all.nl Wed Oct 31 02:55:40 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 5934121F876F for ; Wed, 31 Oct 2012 02:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=0.465, 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 80zo4rXMIod5 for ; Wed, 31 Oct 2012 02:55:39 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9263D21F876E for ; Wed, 31 Oct 2012 02:55:39 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9V9t6Wk095429; Wed, 31 Oct 2012 10:55:06 +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, 31 Oct 2012 10:55:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 31 Oct 2012 10:55:06 +0100 From: peter van der Stok To: "Jonathan Hui (johui)" Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (3GO1r3SrOxf6Y2bj63ZifoHBFeNFmdbk) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: richard kelsey , roll@ietf.org Subject: Re: [Roll] MPL draft 2 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, 31 Oct 2012 09:55:40 -0000 Hi Jonathan, I'm afraid I misunderstood the domain concept, and we do not consider the same case Possibly my case is too specific, but let me explain in different words 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 with link-local addresses 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. Does this still merit the same answer? Peter Jonathan Hui (johui) schreef op 2012-10-30 18:21: > Hi Peter, > > If I understand correctly, you would like to configure MPL multicast > scope zones by having MPL forwarding interfaces subscribe to > different > IPv6 multicast addresses. That is fine with me, but only works when > using IPv6-in-IPv6 encapsulation. If you want to limit the scope of > MPL multicast packets that do not use IPv6-in-IPv6 encapsulation, we > can't rely on the IPv6 Destination Address since that is set by the > source of the original multicast packet. > > Thoughts? > > -- > Jonathan Hui > > On Oct 22, 2012, at 6:53 AM, peter van der Stok > wrote: > >> Hi Jonathan and Richard, >> >> thanks for the new MPL draft. During a first reading I had some >> problems with the domain concept. >> I understood that a domain may be composed of several link-local >> scopes. >> When configuring an interface with one link-local scope I should >> like to reject link-local multicasts which come from link-local >> neigbors that do not belong to the domain for which the interface is >> configured. For example: closely spaced wireless nodes which have >> different edge routers. To express the domain in the multicast address >> were you thinking of "transient" and "unicast prefix based" mc >> addresses with format ff32::prefix:group?. Configuring the interface >> with a link-local scope limited to one prefix may cover the domain >> concept adequately. >> >> In my opinion some text on interface configuration to implement >> packet rejection based on Mc domain will be useful. >> >> Greetings >> >> Peter >> >> -- >> Peter van der Stok >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 From pthubert@cisco.com Wed Oct 31 03:43: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 C4CB521F8696 for ; Wed, 31 Oct 2012 03:43:18 -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 W24SFNqDqw2V for ; Wed, 31 Oct 2012 03:43:18 -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 329F521F84D9 for ; Wed, 31 Oct 2012 03:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2060; q=dns/txt; s=iport; t=1351680198; x=1352889798; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BqYaobW5BarW/0xSKIdbus1oB1NRmKJvrzyL55RCE6E=; b=hn+aFsFL5WMkByI2r79tViuDJb9vgvodWYtMSvWABd6v2UcC8N8Dc+jo ZnhSv/26ir6CQOJoNZkQjheT999IKRC0XOpWx4ipcU6yE5yDx4NxE/D37 FsJlCivIx2ykZOZ+N3u5ekS7nqpX4oq8vWJFJHdU/YFCrp5IRiMqCKOfB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADQAkVCtJXG9/2dsb2JhbABEw22BCIIfAQEEEgEnPxACAQgOFBQQMiUBAQQODRqHZJtwoAeRUmEDkkSSCYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137270831" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 10:43:17 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9VAhHtd003813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 10:43:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.178]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 05:43:17 -0500 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: [Roll] using the flow label instead of hop by hop Thread-Index: Ac2zdAzMC8Y4/WcPS4SX3fcFVFCNpQALyiQAAOvaEvA= Date: Wed, 31 Oct 2012 10:43:17 +0000 Deferred-Delivery: Wed, 31 Oct 2012 10:43:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.93.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--42.517900-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: Wed, 31 Oct 2012 10:43:18 -0000 Hello Carsten, =20 [Carsten] Most of our current protocols are indeed designed to ignore v6 sp= ecific IP header fields. [Carsten] But just to give a very accessible example: A v6 specific version= of ESP (RFC4303) could use the label to transmit the SPI. [Pascal] Which I'd suggest exemplifies what must not be done. The SPI is = an end-to-end information that is useless to the network. Thus is does not = belong to the IPv6 header. I hope we are not discussing this are we? -- [Carsten] I'm not saying this because I want to rule out the use of the lab= el for forwarding fabric purposes; it's just that with more focus on IPv6, = hosts may find good uses for the label. But using the label from RPL-cogni= zant nodes, e.g for router-sourced packets or for the outer header of the R= PL tunnel, should be fine (if there is a way to detect that this has happen= ed). Overwriting the label when a previously formulated IPv6 packet enters= the RPL instance is bad for the same reasons adding the RFC 6553 RPL hop-b= y-hop option or the RFC 6554 routing header in the middle of the path would= be bad. [Pascal] The IP in IP encaps in the HbH case is actually required because o= f the ICMP errors. If no error relates to the flow label then there is no n= eed to save it. And so far there is no standard that I know of that would d= epend on the flow label in the ICMP error. For the standard use, the flow l= abel is consumed once it has passed the core. Considering the footprint con= straints in the IPv6 header, allowing to reuse the FL for network business = after the packet passed the core is actually a good idea.=20 [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 i= dentified and/or cost-justified. So, no, I do not see that we need IP in IP= when we use the flow label for the RPL information. -- Cheers, Pascal From stokcons@xs4all.nl Wed Oct 31 03:55: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 1A1C221F8512 for ; Wed, 31 Oct 2012 03:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=0.310, 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 uL+PMB9XROFU for ; Wed, 31 Oct 2012 03:55:00 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3F82921F850D for ; Wed, 31 Oct 2012 03:54:59 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9VAsOrg081230; Wed, 31 Oct 2012 11:54: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); Wed, 31 Oct 2012 11:54:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 31 Oct 2012 11:54:24 +0100 From: peter van der Stok To: "Jonathan Hui (johui)" Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (MY21G6WbAKQMDI4QQpQChd5yS0AP1mk7) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner 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: 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, 31 Oct 2012 10:55:01 -0000 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 From trac+roll@trac.tools.ietf.org Wed Oct 31 07:31:02 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 15B1E21F8990 for ; Wed, 31 Oct 2012 07:31:02 -0700 (PDT) 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 27rn8N8ifVyo for ; Wed, 31 Oct 2012 07:31:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5C00F21F892D for ; Wed, 31 Oct 2012 07:31:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:46507 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTZJn-0004at-4f; Wed, 31 Oct 2012 15:30: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: Wed, 31 Oct 2012 14:30:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103 Message-ID: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 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: <20121031143101.5C00F21F892D@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 07:31:01 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS 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, 31 Oct 2012 14:31:02 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS The draft describes that sending of ICMP messages can be suppressed by setting REACTIVE_TIMER_EXPIRATIONS to zero. I like to suggest the same possibility for PROACTIVE_TIMER_EXPIRATIONS. The motivation is the following: In rather dense networks, it would be beneficial to reduce the number of forwarders. However, the non-forwarders may not receive some messages in spite of the density. By allowing these nodes to use the sending of ICMP messages, the forwarding nodes can be informed of the missing message to trigger a retransmission http://www.ietf.org/mail-archive/web/roll/current/msg07424.html -- -----------------------------+--------------------------------------------- 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 Wed Oct 31 07:32: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 3CEAF21F8475 for ; Wed, 31 Oct 2012 07:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, 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 tUnAoAjkZar3 for ; Wed, 31 Oct 2012 07:32:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 39BFA21F84AF for ; Wed, 31 Oct 2012 07:32:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:46638 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTZLi-0005eB-D1; Wed, 31 Oct 2012 15:32: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: Wed, 31 Oct 2012 14:32:54 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/104 Message-ID: <058.955ce9de0a87bbb6918ebae344761d9b@trac.tools.ietf.org> X-Trac-Ticket-ID: 104 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: <20121031143258.39BFA21F84AF@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 07:32:58 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #104: trickle-mast: missing security considerations 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, 31 Oct 2012 14:32:59 -0000 #104: trickle-mast: missing security considerations -- -----------------------------+--------------------------------------------- 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 Wed Oct 31 07:37: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 E808F21F87F9 for ; Wed, 31 Oct 2012 07:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 nG1MQ4lxqLh8 for ; Wed, 31 Oct 2012 07:37:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4860E21F86A2 for ; Wed, 31 Oct 2012 07:37:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:47211 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTZQ2-0004Hx-Ub; Wed, 31 Oct 2012 15:37:22 +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, 31 Oct 2012 14:37:22 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/105 Message-ID: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 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: <20121031143728.4860E21F86A2@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 07:37:28 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [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, 31 Oct 2012 14:37:29 -0000 #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 From trac+roll@trac.tools.ietf.org Wed Oct 31 07:38:04 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 E1D8B21F8529 for ; Wed, 31 Oct 2012 07:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 z7u-FoFzDJy7 for ; Wed, 31 Oct 2012 07:38:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5C70F21F852D for ; Wed, 31 Oct 2012 07:38:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:47233 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTZQd-0006vS-NO; Wed, 31 Oct 2012 15:37:59 +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, 31 Oct 2012 14:37:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/105#comment:1 Message-ID: <073.890a11a3e401f332975cbaad044016d0@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: <20121031143804.5C70F21F852D@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 07:38:04 -0700 (PDT) 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, 31 Oct 2012 14:38:05 -0000 #105: trickle-mcast: how to determine scope of MPL domain Comment (by mcr@…): http://www.ietf.org/mail-archive/web/roll/current/msg07462.html -- ----------------------------+---------------------------------------------- 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 trac+roll@trac.tools.ietf.org Wed Oct 31 07:40: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 5C3A521F896E for ; Wed, 31 Oct 2012 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 mxWrfD+sigiq for ; Wed, 31 Oct 2012 07:40:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 704A221F88E3 for ; Wed, 31 Oct 2012 07:40:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:47378 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTZT8-0003hE-Ni; Wed, 31 Oct 2012 15:40:39 +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, 31 Oct 2012 14:40:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/106 Message-ID: <058.7c47b5382385323199505bfcf3e1c3f0@trac.tools.ietf.org> X-Trac-Ticket-ID: 106 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: <20121031144044.704A221F88E3@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 07:40:44 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #106: trickle-mcast: always use 6in6 encapsulation for non-link-local multicast 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, 31 Oct 2012 14:40:45 -0000 #106: trickle-mcast: always use 6in6 encapsulation for non-link-local multicast Of course, all this would be greatly simplified if IPv6-in-IPv6 encapsulation of non-link-local multicasts was made mandatory within a "non-storing RPL domain" (MPL domain). Then there would be only one way to forward multicasts within such a domain and there would be no need for additional routing information. http://www.ietf.org/mail-archive/web/roll/current/msg07462.html -- -----------------------------+--------------------------------------------- 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 johui@cisco.com Wed Oct 31 07:53: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 7E6DB21F855A for ; Wed, 31 Oct 2012 07:53:46 -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 61yvn+qECNq3 for ; Wed, 31 Oct 2012 07:53:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC621F852B for ; Wed, 31 Oct 2012 07:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5405; q=dns/txt; s=iport; t=1351695225; x=1352904825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YY8QgfpLxcZdz73+lAUIkTnw8LNr0A4KMLMCUf30hF4=; b=CQL9sOJCkK2qMxElpc1HUF2mSgM3WPfL+3/GVfXp18H95Q9Ea40vbXMa oWgU/K9tBMJBD0o2JZg7zXftrDz7nPj6bmYrn+JWgfRnJeAIUcztVZpSy irzAmTJ5NzrjxpadD7G7p8wtConDY0N1It5vbif/jyP9E7J5QyXGpyJo5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH06kVCtJXG//2dsb2JhbAA6CsNsgQiCHgEBAQMBAQEBDwEnNAsFCwIBCBgKFBAnCyUCBA4FCBqHUgMJBgucFZY2BYlYBIt4EIVKYQOkTYFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137336619" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2012 14:53:44 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9VErhhr012977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 14:53:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 09:53:43 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Thread-Index: AQHNtsPoCFDBKx0obUyzx8/7TlSyjQ== Date: Wed, 31 Oct 2012 14:53:42 +0000 Message-ID: References: In-Reply-To: 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-19324.001 x-tm-as-result: No--43.580800-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: <24EF2B3DDE44194D9D9396DEBD9A35A2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 31 Oct 2012 14:53:46 -0000 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, >=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 >>>>>>=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 >>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >=20 From stokcons@xs4all.nl Wed Oct 31 08:02: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 EF22621F87C7 for ; Wed, 31 Oct 2012 08:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=0.232, 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 hYSHsSDRVAxp for ; Wed, 31 Oct 2012 08:02:17 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9D21F8622 for ; Wed, 31 Oct 2012 08:02:16 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9VF1fbT094426; Wed, 31 Oct 2012 16:01:41 +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, 31 Oct 2012 16:01:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 31 Oct 2012 16:01:41 +0100 From: peter van der Stok To: "Jonathan Hui (johui)" Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: <9978f68d59c79b1dec0e655cd3d12bce@xs4all.nl> X-Sender: stokcons@xs4all.nl (jnlhHlGANJptpb7oKj2u+3ejZ7rnYixI) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner 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: 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, 31 Oct 2012 15:02:18 -0000 Hi Jonathan, things becone very clear for me by this explicit operational explanation. Could some text like this be added to the document? I think my important issues have been addressed. Looking forward to the new text. Many thanks, Peter Jonathan Hui (johui) schreef op 2012-10-31 15:53: > 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 >> From jeonggil.ko@gmail.com Wed Oct 31 08:20:42 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 C55D421F872A for ; Wed, 31 Oct 2012 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.445 X-Spam-Level: X-Spam-Status: No, score=-101.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, 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 u3uVMH4UqPLc for ; Wed, 31 Oct 2012 08:20:42 -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 0A07421F87D3 for ; Wed, 31 Oct 2012 08:20:42 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so691404dan.31 for ; Wed, 31 Oct 2012 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ruXzE0p7KV5eb6bZ+kWJuxvcBKFKUC0hU2nLIcCM60U=; b=ZPNh8IkoBGjmzWkhG4Bhmj46to4a8bi1Bd+YZjv1fCOBK7SDjqZGjphTgYdEt6xU3S SoLhXUC5UqiFQUpcfsguou17oPZuPZDrDfyF9JBm/vJlQsrsQefDC6m9NRJk6ISff6X4 qSbK2oKLmqv4sRax7wgEofJkf7UetDD0vFgUUndrHXXXNKERVeTiHanuV9KICRKoLfZY G9Q/ww+3hrPDBUDDmDk6TOnOB35Ly680NkEwv5VRm9gTQD3uWA7T1rCOQa5702Ngp+Mg VkuSuwbLmcygfSkRvCBQ5Q4EZa8iS+4tyE473U0lhISFxiSXURWMpefgqTpqTnPUESAP y9Bg== Received: by 10.66.90.36 with SMTP id bt4mr102848956pab.54.1351696841619; Wed, 31 Oct 2012 08:20:41 -0700 (PDT) Received: from [192.168.123.120] ([125.138.63.113]) by mx.google.com with ESMTPS id nu8sm2434810pbc.45.2012.10.31.08.20.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 08:20:40 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: JeongGil Ko In-Reply-To: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> Date: Thu, 1 Nov 2012 00:20:32 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <47B5B50A-369F-474A-A4C8-1A951C164E1B@etri.re.kr> References: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> To: Jon Black X-Mailer: Apple Mail (2.1278) Cc: "roll@ietf.org WG" , Michael Richardson 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: Wed, 31 Oct 2012 15:20:43 -0000 Hmmm... Looks like this question on the clarification of the slot = decision process is also lacking a reply? -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ On Oct 31, 2012, at 5:41 AM, Jon Black wrote: > =46rom looking at the drafts - one has a cisco author and the other = doesn't - hmmm. >=20 > Jon >=20 > Phill Levis said on October 30, 2012 at 8:19 am: >=20 > I'm a little worried that the one draft which is based on a real, = documented problem encountered in a deployment is considered to have "no = traction on the mailing list", despite several discussions, while = "Industrial Deterministic Routing Extension for Low-Power and Lossy = Networks," which I have never seen mentioned on the mailing list (can = someone point out that I'm wrong) does have a slot. This doesn't mean = that the other draft shouldn't have a slot; I just don't understand the = process by which slots are being decided. >=20 > Phil >=20 > On Oct 29, 2012, at 11:44 PM, JP Vasseur (jvasseur) wrote: >=20 >=20 >> Dear all, >>=20 >> Many Thanks for your email - we did discuss about it but there pretty = much no traction on the mailing list on this item. >> Please continue to use the mailing at will. This is why the item is = not part of the agenda indeed. >>=20 >> Many Thanks. >>=20 >> JP and Michael. >>=20 >> On Oct 30, 2012, at 3:14 AM, JeongGil Ko wrote: >>=20 >>=20 >>> Dear WG Chairs, >>>=20 >>> For some reason... this email seems to be ignored=E2=80=A6 any = responses?=20 >>>=20 >>> -John >>>=20 >>> ------ >>> JeongGil Ko, Ph.D. >>> Researcher >>> Electronics and Telecommunications Research Institute (ETRI) >>>=20 >>> http://sites.google.com/site/jeonggilko/ >>>=20 >>>=20 >>> On Oct 26, 2012, at 9:39 PM, =EC=A0=95=EC=A2=85=EC=88=98=20 >>> >>> wrote: >>>=20 >>>=20 >>>> JP, >>>>=20 >>>> John has requested a slot. But we've not been replied anything. Is = the agenda already fixed? >>>>=20 >>>> Regards, >>>> -Jongsoo >>>>=20 >>>> 2012. 10. 25., =EC=98=A4=EC=A0=84 6:41, JeongGil Ko=20 >>>> >>>> =EC=9E=91=EC=84=B1: >>>>=20 >>>>=20 >>>>> JP, >>>>>=20 >>>>> I've also put in a request for a slot at the meeting in Atlanta = for presenting "draft-ko-roll-mix-network-pathology" but I do not see = this on the agenda. This draft discusses about a critical and practical = performance issue of RPL networks (both collection and downwards) when = they are intentionally or accidentally deployed with devices of = different MOPs. I believe that such an issue is important to discuss as = a group. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> -John >>>>>=20 >>>>> ------ >>>>> JeongGil Ko, Ph.D. >>>>> Researcher >>>>> Electronics and Telecommunications Research Institute (ETRI) >>>>>=20 >>>>> http://sites.google.com/site/jeonggilko/ >>>>>=20 >>>>>=20 >>>>> On Oct 25, 2012, at 3:06 AM, JP Vasseur (jvasseur) wrote: >>>>>=20 >>>>>=20 >>>>>> Dear all, >>>>>>=20 >>>>>> please find bellow the draft agenda for ROLL's WG meeting in = Atlanta - let us know if you have any comment: >>>>>>=20 >>>>>> 1) Agenda/admin (Chairs - 5mn) [5] >>>>>>=20 >>>>>> 2) WG Status (Chairs - 10 mn) [15] >>>>>>=20 >>>>>> 3) Security Framework and Applicability Statement template >>>>>> (Michael - 10m) [25] >>>>>> draft=3Ddraft-richardson-roll-applicability-template-00 >>>>>>=20 >>>>>> 4) RPL applicability in industrial networks >>>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>>> (Pascal - 10mn) [35] >>>>>>=20 >>>>>> 5) Industrial Deterministic Routing Extension for Low-Power >>>>>> and Lossy Networks (M. Wei - 10mn) [45] >>>>>>=20 >>>>>> 6) RPL deployment experience in large scale networks >>>>>> draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] >>>>>>=20 >>>>>> 7) RPL applicability in industrial networks >>>>>> draft-phinney-roll-rpl-industrial-applicability-01 >>>>>> (Pascal - 10mn) [60] >>>>>>=20 >>>>>> 8) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [70] >>>>>> draft-guo-roll-loop-free-dodag-repair >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> JP and Michael. >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>>=20 >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> _______________________________________________ >>>>> Roll mailing list >>>>>=20 >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>>=20 >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >>=20 >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list >=20 > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From esko.dijk@philips.com Wed Oct 31 08:38: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 C77EA21F84CE for ; Wed, 31 Oct 2012 08:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kvwNajYsMPss for ; Wed, 31 Oct 2012 08:38:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id E68B821F84C1 for ; Wed, 31 Oct 2012 08:38:16 -0700 (PDT) Received: from mail247-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 15:38:16 +0000 Received: from mail247-ch1 (localhost [127.0.0.1]) by mail247-ch1-R.bigfish.com (Postfix) with ESMTP id 28B3B15A0102; Wed, 31 Oct 2012 15:38:16 +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(zz217bI98dI15d6O9371I9251J936eI542M1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail247-ch1 (localhost.localdomain [127.0.0.1]) by mail247-ch1 (MessageSwitch) id 1351697893512786_20439; Wed, 31 Oct 2012 15:38:13 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail247-ch1.bigfish.com (Postfix) with ESMTP id 7A8961400043; Wed, 31 Oct 2012 15:38:13 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 15:38:13 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.02.0309.003; Wed, 31 Oct 2012 15:37:52 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" , "roll@ietf.org" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Thread-Index: AQHNrh4EBfIsegKOz0GvSDMMHJeV6pfA4wQAgBKnvHA= Date: Wed, 31 Oct 2012 15:37:52 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B09936@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <20121019171938.9893.94358.idtracker@ietfa.amsl.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 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: Wed, 31 Oct 2012 15:38:25 -0000 Hi Jonathan, besides the points you mentioned, I see 3 more topics which are not yet dis= cussed: 1. Selection of the link-local all-nodes MPL forwarders multicast address. When IPv6-in-IPv6 encapsulation is applied, the "all-MPL-forwarders" MC add= ress 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 addre= ss when the multicast Group ID is in the range 0x00-0xFF. Therefore we shou= ld put in the IANA allocation request (and in the IANA section in the I-D t= oo) that we urgently request an allocation in this range. Going outside thi= s range to Group IP 0x100 and up, will incur 4 bytes extra overhead. (An ex= ample of a successful earlier registration in the 00-FF range is mDNS FF0X:= :FB). 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 mult= icast traffic) may lead to unpredictable behavior. For example, an MPL node= N1 application sends to FF05::1234, and a non-MPL neighbor node N2 listens= to FF05::1234. If MPL does use encapsulation, then node N2 will never rece= ive the packet from N1 (because N1 will send to either FF02::MPL or FF05::M= PL). If MPL happens to not use encapsulation, node N2 will receive the pack= et from N1. So depending on the encapsulation decision different nodes may get/not get = the packet - is this intentional? If not we should warn for this situation, perhaps? 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 t= he RPL router can remove the HbH option. (RFC 6550 Section 11.2.2.1, "A rou= ter that forwards a packet outside the RPL network MUST remove the RPL Pack= et Information.") Is there a reason that MPL cannot do it the RPL way? regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon= athan Hui (johui) Sent: Friday 19 October 2012 19:32 To: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt ROLL WG, This update includes the new text that was sent out during the last IETF me= eting and incorporates comments received since then (special thanks to Robe= rt Cragie, Esko Dijk, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter v= an der Stok). The following are some open discussion items that were raised in the commen= ts. Would be great to hear your thoughts. 1) MPL multicast scope. The current draft allows the MPL multicast scope t= o be link-local scope or something larger. On one hand, fixing the MPL mul= ticast scope to be link-local reduces the number of options, makes things s= impler, and improves interoperability. On the other hand, doing so will mak= e IPv6-in-IPv6 encapsulation a MUST even when the source and destinations a= re all in the MPL domain. 2) The S field. The current draft includes an S field in the MPL Hop-by-Ho= p Option to indicate the length of the seed identifier. On one hand, the l= ength of the seed identifier may be inferred by the Opt Data Len field. On= the other hand, if any future specification wants to define additional fie= lds following the seed identifier field, that specification would need some= way to indicate the length of the seed identifier. The S field was origin= ally included to allow the possibility of something like sub-TLVs, that are= extensively used throughout RPL. 3) Supporting different Trickle parameter sets. The latest draft removes a= flag that indicates which of two parameter sets to use when disseminating = MPL multicast packets. We removed the flag in attempt to simplify the draf= t. Furthermore, it wasn't clear that a single flag (2 parameter sets) was = sufficient. 4) Version number field. The current draft does not include a version fiel= d in the MPL Hop-by-Hop Option. Instead, it sets all reserved bits to zero= and requires all devices that implement this draft to drop the message if = any of those bits are non-zero. -- Jonathan Hui On Oct 19, 2012, at 10:19 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-02.txt > Pages : 24 > Date : 2012-10-19 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to drive > packet transmissions for both control and data-plane packets. > Specific Trickle parameter configurations allow MPL to trade between > dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Roll mailing 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. From johui@cisco.com Wed Oct 31 09:18:54 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 39D7921F8668 for ; Wed, 31 Oct 2012 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.294 X-Spam-Level: X-Spam-Status: No, score=-8.294 tagged_above=-999 required=5 tests=[AWL=-2.305, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8, 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 xGlzjC6iwKYB for ; Wed, 31 Oct 2012 09:18:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 720CB21F8667 for ; Wed, 31 Oct 2012 09:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2644; q=dns/txt; s=iport; t=1351700333; x=1352909933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e+H4jeRjFB8uDtNWDX4ZFl53y3SGybP1BFPKa4iHNSY=; b=PCfTHFAhi9cDJvCqMw4owi2kk8ki1zWjBz+0Rg1ZK+x1jAv+HMZiIdoE QxjMPm0vSxiDEzOWt3NCGMJAPVGiat0ths3kNvaik/0cKyhV0QvWh90xy CzpTtFE36xiFdWPVcWXXpJHQh5tqoWBUNgEprZWpyowQ2udjnSNjKvRf/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANdOkVCtJXG8/2dsb2JhbAA/BcNvgQiCHgEBAQMBEgEnPwULAgEIIhQQMiUCBA4FCBqHXgacSKAVi3gohTJhA5JEkgmBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137373292" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2012 16:18:53 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGIqAg003568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:18:53 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; Wed, 31 Oct 2012 11:18:52 -0500 From: "Jonathan Hui (johui)" To: "Dijk, Esko" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt Thread-Index: AQHNrh+gRb5TlPk7pUqtIMGVkE0DSw== Date: Wed, 31 Oct 2012 16:18:52 +0000 Message-ID: References: <20121019171938.9893.94358.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B09936@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B09936@011-DB3MPN2-082.MGDPHG.emi.philips.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-19324.001 x-tm-as-result: No--32.406400-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 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: Wed, 31 Oct 2012 16:18:54 -0000 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 From johui@cisco.com Wed Oct 31 09:21:30 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 D8BE221F870F for ; Wed, 31 Oct 2012 09:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.138 X-Spam-Level: X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=0.461, 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 KwmVUJXjJ53a for ; Wed, 31 Oct 2012 09:21:30 -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 C9FF921F8668 for ; Wed, 31 Oct 2012 09:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6272; q=dns/txt; s=iport; t=1351700489; x=1352910089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cw9rGpD0j5tHjrCKJwLUHt7YyajHO/pvj9rFKMaTXII=; b=OCJ8N6kxyFepE7l2SmabTFaQMcKuMFUHf2b3igQKTG6rfdDbEi/PA75i G+zV2OBhF2jgJcRMskGlq1WAo6fLRY+yWiBgeR/WX4pPdwAJeqZk1y3G8 QxQLHqIlsaMNS06iqA98AcfU0f1HNi/EbGYbVjMo5nQq6WKbz1Is4isqq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN9PkVCtJV2c/2dsb2JhbAA6CsNvgQiCHgEBAQMBAQEBDwEnNAsQAgEIGAoUECcLJQIEDgUIGodSAwkGC5w/ljQFiVgEi3gQhUphA6RNgWuCb4FkFx4 X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137394587" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 31 Oct 2012 16:21:27 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9VGLRHG003321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 16:21:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 11:21:27 -0500 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02 Thread-Index: AQHNtsPoCFDBKx0obUyzx8/7TlSyjQ== Date: Wed, 31 Oct 2012 16:21:26 +0000 Message-ID: References: <9978f68d59c79b1dec0e655cd3d12bce@xs4all.nl> In-Reply-To: <9978f68d59c79b1dec0e655cd3d12bce@xs4all.nl> 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-19324.001 x-tm-as-result: No--42.919200-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: <84DAB1CB1CC9BC4EB6ADDE8AB1972AFA@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: Wed, 31 Oct 2012 16:21:31 -0000 Hi Peter, Yes, I will attempt to clarify this point in the next revision. Thanks. -- Jonathan Hui On Oct 31, 2012, at 8:01 AM, peter van der Stok wrote: >=20 > Hi Jonathan, >=20 > things becone very clear for me by this explicit operational explanation. > Could some text like this be added to the document? >=20 > I think my important issues have been addressed. Looking forward to the n= ew text. >=20 > Many thanks, >=20 > Peter >=20 > Jonathan Hui (johui) schreef op 2012-10-31 15:53: >> Hi Peter, >>=20 >> The current draft does not place any restrictions on the MPL multicast s= cope. >>=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 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). >>=20 >> Does that address your question? >>=20 >> -- >> Jonathan Hui >>=20 >> On Oct 31, 2012, at 3:54 AM, peter van der Stok wro= te: >>=20 >>> Hi Jonathan, >>>=20 >>> To be absolutely sure: the MPL multicast scope can be link-local, ULA o= r site-local? meaning the LLN border router can be a MPL forwarder? >>> In the latter case the LLN border router can forward link-local multica= st 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 th= at in >>>>> mind...... >>>>>=20 >>>>> I was hoping that we could support not using IP in IP tunneling if th= e >>>>> scope of the multicast transmission was only within the multi-link su= bnet >>>>> 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 multicas= ts >>>>> generated in the multi-link subnet with scope outside). I haven't ye= t >>>>> 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 = not >>>>>> 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" wrot= e: >>>>>>>=20 >>>>>>>>=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 t= he >>>>>>>> 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 t= he >>>>>>>> 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 th= e >>>>>>>>> document. >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >=20 From pal@cs.stanford.edu Wed Oct 31 09:48: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 410C121F870F for ; Wed, 31 Oct 2012 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 Nx5nBURaSuUK for ; Wed, 31 Oct 2012 09:48:58 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9CF21F84A6 for ; Wed, 31 Oct 2012 09:48:58 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[10.111.222.25]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TTbTL-0000Si-FB; Wed, 31 Oct 2012 09:48:57 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 31 Oct 2012 09:22:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03D5F543-40BD-427C-9C53-EF5172DC0103@cs.stanford.edu> References: To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 3fe17504c5843e76b9e439a63759b02e 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: Wed, 31 Oct 2012 16:48:59 -0000 On Oct 31, 2012, at 3:43 AM, Pascal Thubert (pthubert) wrote: > Hello Carsten, >=20 > [Carsten] Most of our current protocols are indeed designed to ignore = v6 specific IP header fields. > [Carsten] But just to give a very accessible example: A v6 specific = version of ESP (RFC4303) could use the label to transmit the SPI. >=20 > [Pascal] Which I'd suggest exemplifies what must not be done. The = SPI is an end-to-end information that is useless to the network. Thus is = does not 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 = "useless" 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 transport header). Or the offset/MF in IPv4.=20 > [Carsten] I'm not saying this because I want to rule out the use of = the label for forwarding fabric purposes; it's just that with more focus = on IPv6, hosts may find good uses for the label. But using the label = from RPL-cognizant nodes, e.g for router-sourced packets or for the = outer header of the RPL tunnel, should be fine (if there is a way to = detect that this has happened). Overwriting the label when a previously = formulated IPv6 packet enters the RPL instance is bad for the same = reasons adding the RFC 6553 RPL hop-by-hop option or the RFC 6554 = routing header in the middle of the path would be bad. >=20 > [Pascal] The IP in IP encaps in the HbH case is actually required = because of the ICMP errors. If no error relates to the flow label then = there is no need to save it. And so far there is no standard that I know = of that would depend on the flow label in the ICMP error. For the = standard use, the flow label is consumed once it has passed the core. = Considering the footprint constraints in the IPv6 header, allowing to = reuse the FL for network business after the packet passed the core is = actually a good idea.=20 >=20 > [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 IP when we use the flow label for the RPL information. Pascal, I think the issue is really simple. IMHO, any reasonable = interpretation 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. Applications and other protocols using IPv6 and reading = RFC6537 might make this assumption: 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." Basically, if 6man is willing to change the flow label specification = such that 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 specification (in a way that can break interoperability) for an = as-of-yet-unsubstantiated optimization effort seems like poor = engineering to me. Phil From qiuying@i2r.a-star.edu.sg Wed Oct 31 09:49: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 2C3AF21F878E; Wed, 31 Oct 2012 09:49:56 -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 tQwmNjzO6nVZ; Wed, 31 Oct 2012 09:49:55 -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 AD76E21F878D; Wed, 31 Oct 2012 09:49:54 -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 q9VGnngP026253; Thu, 1 Nov 2012 00:49:50 +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; Thu, 1 Nov 2012 00:49:48 +0800 From: QIU Ying To: "'Rene Struik'" References: <02a001cdb5ee$e34164d0$a9c42e70$@a-star.edu.sg> <508ECA68.4030402@gmail.com> In-Reply-To: <508ECA68.4030402@gmail.com> Date: Thu, 1 Nov 2012 00:56:16 +0800 Message-ID: <036901cdb788$a481d5e0$ed8581a0$@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: Ac22Awuizrt3ftb5Rx6RXh5Wrj8ExwBg8lOw 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-10-31_03:2012-10-31, 2012-10-31, 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-1210310162 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: Wed, 31 Oct 2012 16:49:56 -0000 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." From jvasseur@cisco.com Wed Oct 31 11:44: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 142B621F884F for ; Wed, 31 Oct 2012 11:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 GhKzGe596lBp for ; Wed, 31 Oct 2012 11:44:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6621F8554 for ; Wed, 31 Oct 2012 11:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1066; q=dns/txt; s=iport; t=1351709062; x=1352918662; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=nBumta9yJLHyNEGiU+wdp35/vaSWETJpOl97qF6+bkU=; b=bU87THF/lwVQ12Nz2ZvcC0XV14aOer3mFmlcDhiN/xm62BTay3z5NzxU ZjUoY+cTQHuwhz3GaOKvZTDaXY2ZL7/xd+7tR6OfMJFg1nnq+s6a4ZKmN GIGXtDFpkxtEWVbrL/R0spm808AwK1wWRTqvGicZUjr5kGLULfCPafF07 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALJwkVCtJXG8/2dsb2JhbABEw1qBCIIgAQQSASc0HQEqFEInBBsah2SaI4EsoCOME4U/YQOkTYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="134450298" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 31 Oct 2012 18:44:22 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9VIiMRF028094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Oct 2012 18:44:22 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 13:44:21 -0500 From: "JP Vasseur (jvasseur)" To: "roll@ietf.org WG" Thread-Topic: Seems like we now see some interest in draft-ko-roll-mix-network-pathology-01 Thread-Index: AQHNt5e9dpiASBygPU+akxlPLVztOA== Date: Wed, 31 Oct 2012 18:44:21 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77220457B6@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.89] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--25.752500-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: <09D9332826AD8749B8D1F1A1AC85E5D3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] Seems like we now see some interest in draft-ko-roll-mix-network-pathology-01 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, 31 Oct 2012 18:44:23 -0000 Dear all, Several of them asked for this draft to be discussed (originally we had no = discussion on the mailing list) and as you know "Slots" are not there for "presentation" but discussion. So agenda has been= updated according: 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) RPL deployment experience in large scale networks draft-hui-vasseur-roll-rpl-deployment (TBD - 5mn) [50] 7) Loop Free DODAG Local Repair (Jianlin Guo - 10mn) [60] 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) [70] draft-ko-roll-mix-network-pathology-01= From robert.cragie@gridmerge.com Wed Oct 31 14:34:55 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 D167721F8734 for ; Wed, 31 Oct 2012 14:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_12=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 Jyd2AZmnqcvZ for ; Wed, 31 Oct 2012 14:34:52 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id B302521F8723 for ; Wed, 31 Oct 2012 14:34:48 -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 1TTfvw-0004PE-4N for roll@ietf.org; Wed, 31 Oct 2012 21:34:46 +0000 Message-ID: <509199B9.105@gridmerge.com> Date: Wed, 31 Oct 2012 21:35: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: <9978f68d59c79b1dec0e655cd3d12bce@xs4all.nl> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020109020908070109030905" 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: Wed, 31 Oct 2012 21:34:56 -0000 This is a cryptographically signed message in MIME format. --------------ms020109020908070109030905 Content-Type: multipart/mixed; boundary="------------060302020505080204030104" This is a multi-part message in MIME format. --------------060302020505080204030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jonathan, I see some of my comments to the authors were incorporated but not all.=20 I still think the packet definitions are too vague and lead to confusion = and there is still some clarity required regarding address scope and MPL = scope and domain. Maybe the 'zone' language will help. Attached are my=20 comments, bracketed by . Robert On 31/10/2012 4:21 PM, Jonathan Hui (johui) wrote: > Hi Peter, > > Yes, I will attempt to clarify this point in the next revision. > > Thanks. > > -- > Jonathan Hui > > On Oct 31, 2012, at 8:01 AM, peter van der Stok wr= ote: > >> Hi Jonathan, >> >> things becone very clear for me by this explicit operational explanati= on. >> Could some text like this be added to the document? >> >> I think my important issues have been addressed. Looking forward to th= e new text. >> >> Many thanks, >> >> Peter >> >> Jonathan Hui (johui) schreef op 2012-10-31 15:53: >>> Hi Peter, >>> >>> The current draft does not place any restrictions on the MPL multicas= t 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, UL= A 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 mult= icast 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 forwardi= ng >>>>> domain and the destination has a scope equal to or smaller than the= >>>>> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required= =2E >>>>> 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 identif= y >>>>> MPL forwarding scope zones. >>>>> >>>>> Of course, this brings up Dario's practical point of how to configu= re >>>>> 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 transmissio= n >>>>>> emanating from outside the multi-link subnet, received at the bord= er >>>>>> router, with scope that includes the devices in the multi-link sub= net >>>>>> would require IP in IP tunneling (and vice versa in terms of multi= casts >>>>>> 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" wro= te: >>>>>> >>>>>>> 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 po= int >>>>>>>> out >>>>>>>> why IP in IP tunneling is needed. >>>>>>>> >>>>>>>> Don >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10/29/12 3:44 AM, "peter van der Stok" w= rote: >>>>>>>> >>>>>>>>> Dear WG, >>>>>>>>> >>>>>>>>> >>>>>>>>> Attached my suggestions for text modifications including some n= its. I >>>>>>>>> used the facilities of word to edit and comment text with trace= s. >>>>>>>>> >>>>>>>>> When writing text about MC scope and MC domain, I was puzzled b= y the >>>>>>>>> all MPL forwarders multicast address which removes the possibil= ity 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 onc= e the >>>>>>>>> message was received by the seed. >>>>>>>>> To make it possible to configure the interface with one MC scop= e I >>>>>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicas= t >>>>>>>>> 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 > --------------060302020505080204030104 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-roll-trickle-mcast-02 - rcc comments.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-roll-trickle-mcast-02 - rcc comments.txt" ROLL J. Hui Internet-Draft Cisco Intended status: Standards Track R. Kelsey Expires: April 22, 2013 Silicon Labs October 19, 2012 Multicast Protocol for Low power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-02 Abstract This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL forwarders in an MPL domain. MPL uses the Trickle algorithm to drive packet transmissions for both control and data-plane packets. Specific Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Hui & Kelsey Expires April 22, 2013 [Page 1] =0C Internet-Draft MPL October 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. MPL Option . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. ICMPv6 MPL Message . . . . . . . . . . . . . . . . . . . . 8 4.2.1. MPL Window . . . . . . . . . . . . . . . . . . . . . . 9 5. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . . . 11 5.1. Multicast Packet Dissemination . . . . . . . . . . . . . . 11 5.1.1. Trickle Parameters and Variables . . . . . . . . . . . 12 5.1.2. Proactive Propagation . . . . . . . . . . . . . . . . 12 5.1.3. Reactive Propagation . . . . . . . . . . . . . . . . . 13 5.2. Sliding Windows . . . . . . . . . . . . . . . . . . . . . 13 5.3. Transmission of MPL Multicast Packets . . . . . . . . . . 15 5.4. Reception of MPL Multicast Packets . . . . . . . . . . . . 16 5.5. Transmission of ICMPv6 MPL Messages . . . . . . . . . . . 16 5.6. Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17 6. MPL Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Hui & Kelsey Expires April 22, 2013 [Page 2] =0C Internet-Draft MPL October 2012 1. Introduction Low power and Lossy Networks typically operate with strict resource constraints in communication, computation, memory, and energy. Such resource constraints may preclude the use of existing IPv6 multicast topology and forwarding mechanisms. Traditional IP multicast forwarding typically relies on topology maintenance mechanisms to forward multicast messages to all subscribers of a multicast group. However, maintaining such topologies in LLNs is costly and may not be feasible given the available resources. Memory constraints may limit devices to maintaining links/routes to one or a few neighbors. For this reason, the Routing Protocol for LLNs (RPL) specifies both storing and non-storing modes [RFC6550]. The latter allows RPL routers to maintain only one or a few default routes towards a LLN Border Router (LBR) and use source routing to forward packets away from the LBR. For the same reasons, a LLN device may not be able to maintain a multicast forwarding topology when operating with limited memory. Furthermore, the dynamic properties of wireless networks can make the cost of maintaining a multicast forwarding topology prohibitively expensive. In wireless environments, topology maintenance may involve selecting a connected dominating set used to forward multicast messages to all nodes in an administrative domain. However, existing mechanisms often require two-hop topology information and the cost of maintaining such information grows polynomially with network density. This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating multicast messages to all MPL forwarders in an MPL domain. By using the Trickle algorithm [RFC6206], MPL requires only small, constant state for each MPL device that initiates disseminations. The Trickle algorithm also allows MPL to be density-aware, allowing the communication rate to scale logarithmically with density. Hui & Kelsey Expires April 22, 2013 [Page 3] =0C Internet-Draft MPL October 2012 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terms are used throughout this document: MPL forwarder An IPv6 router that subscribes to the MPL multicast group and participates in disseminating MPL multicast packets. MPL multicast scope The multicast scope that MPL uses when forwarding MPL multicast packets. In other words, the multicast scope of the IPv6 Destination Address of an MPL multicast packet. MPL domain A connected set of MPL forwarders that define the extent of the MPL dissemination process. As a form of flood, all MPL forwarders in an MPL domain will receive MPL multicast packets. The MPL domain MUST be composed of at least one MPL multicast scope and MAY be composed of multiple MPL multicast scopes. MPL seed A MPL forwarder that begins the dissemination process for an MPL multicast packet. The MPL seed may be different than the source of the original multicast packet. MPL seed identifier An identifier that uniquely identifies an MPL forwarder within its MPL domain. original multicast packet An IPv6 multicast packet that is disseminated using MPL. MPL multicast packet An IPv6 multicast packet that contains an MPL Hop-by-Hop Option. When either source or destinations are beyond the MPL multicast scope, the MPL multicast packet is an IPv6-in-IPv6 packet that contains an MPL Hop-by-Hop Option in the outer IPv6 header and encapsulates an original multicast packet. When both source and s/destinations/destination/ are within = the MPL multicast scope, the MPL Hop-by-Hop Option may be included directly within the original multicast packet. My original suggestions to the authors were not included in the latest dr= aft. I think the definitions above don't quite encompass the types of multicas= t packet used in MPL. Although the change to the definition for MPL multi= cast packet no longer implies that an MPL multicast packet always encapsu= lates, it is still vague about whether an original multicast packet actua= lly contains an MPL HbH option or not. I would suggest the following defi= nitions for consideration: original non-MPL multicast packet An incoming or locally originated I= Pv6 multicast packet that MUST NOT contain an MPL Hop-by-Hop option. An o= riginal non-MPL multicast packet becomes further encapsulated in an encap= sulating MPL multicast packet for dissemination. original MPL multicast packet An incoming or locally originated IPv6 = multicast packet that MUST contain an MPL Hop-by-Hop option and is dissem= inated directly using MPL without further modification. original multicast packet An incoming or locally originated IPv6 mult= icast packet. encapsulating MPL multicast packet An IPv6 multicast packet that MUST= contain an MPL Hop-by-Hop Option, MUST encapsulate an original non-MPL m= ulticast packet and is disseminated using MPL. MPL multicast packet An IPv6 multicast packet that MUST contains an M= PL Hop-by-Hop Option and is disseminated using MPL, i.e. an original MPL = multicast packet or an encapsulating MPL multicast packet. =20 Diagrams may help to illustrate the possible combinations. The term "MPL multicast packet" can be used most often and the changes in= 02 are generally good with regard to use of this term but the other term= s help to clarify the other situations, especially regarding sending and = receiving outside of the MPL domain. =20 Hui & Kelsey Expires April 22, 2013 [Page 4] =0C Internet-Draft MPL October 2012 3. Overview MPL delivers IPv6 multicast packets by disseminating them to all MPL forwarders within an MPL domain. MPL dissemination is a form of flood. An MPL forwarder may broadcast/multicast an MPL multicast packet out of the same physical interface on which it was received. =20 Doesn't cover the case of a multicast received from outside the MPL domai= n which may not have a MPL Option. Using the above terminology, I would w= rite as: "An MPL forwarder may broadcast/multicast an MPL multicast packet out of = the same physical interface on which a corresponding original multicast p= acket was received" =20 Using link-layer broadcast/multicast allows MPL to forward multicast packets without explicitly identifying next-hop destinations. An MPL forwarder may also broadcast/multicast MPL multicast packets s/ou= t/out of/ other interfaces to disseminate the message across different links. =20 Doesn't cover the case of forwarding without a MPL Option. Using the abov= e terminology, I would write as: "An MPL forwarder may also broadcast/multicast multicast packets out of o= ther interfaces to disseminate the message across different links" MPL does not build or maintain a multicast forwarding topology to forward multicast packets. Any MPL forwarder may initiate the dissemination process by serving as an MPL seed for an original multicast packet. The MPL seed may or may not be the same device as the source of the original multicast packet. When the original multicast packet's source is outside the LLN, the MPL seed may be the ingress router. Even if an original multicast s/packet/packet's/ source is within the LLN, the = source may first forward the s/multicast/original multicast/ packet to the M= PL seed using IPv6-in-IPv6 tunneling. Because MPL state requirements grows with the number of active MPL seeds, limiting the number of MPL seeds reduces the amount of state that MPL forwarders must maintain. Because MPL typically broadcasts/multicasts MPL packets out of the same interface on which they were received, MPL forwarders are likely to receive an MPL multicast packet more than once. Simplistic with regard to the mechanism. Using the above terminology, I w= ould write as: "Because MPL often broadcasts/multicasts an MPL multicast packet out of t= he same interface on which a corresponding original multicast packet was = received," The MPL seed tags each original multicast packet with an MPL seed identifier and a sequence number. The sequence number provides a total ordering of MPL multicast packets disseminated by the MPL seed. MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include MPL-specific information along with the original multicast packet. Each IPv6 multicast packet that MPL disseminates includes the MPL Option. Because the original multicast packet's source and the MPL seed may not be the same device, the MPL Option may be added to the original multicast packet en-route. To allow Path MTU discovery to work properly, MPL encapsulates the original multicast packet in another IPv6 header that includes the MPL Option. Upon receiving a new MPL multicast packet for forwarding, the MPL forwarder may proactively transmit the MPL multicast packet packet a limited number of times Doesn't cover the case of forwarding without a MPL Option. Using the abov= e terminology, I would write as: "Upon receiving a new original multicast packet for forwarding, the MPL f= orwarder may actively transmit the corresponding MPL multicast packet a l= imited number of times" and then falls back into an optional s/reactive/reactive maintena= nce/ mode. In s/maintenance/this maintenance/ mode, an MPL forw= arder buffers recently received MPL multicast packets and advertises a summary of recently received MPL multicast packets from time to time, allowing neighboring MPL forwarders to determine if they have any new multicast packets to offer or receive. Hui & Kelsey Expires April 22, 2013 [Page 5] =0C Internet-Draft MPL October 2012 MPL forwarders schedule their packet (control and data) transmissions using the Trickle algorithm [RFC6206]. Not all their packet transmissions. I would rewrite as: "MPL forwarders schedule MPL multicast packet transmissions using the Tri= ckle algorithm [RFC6206]." =20 Trickle's adaptive transmission interval allows MPL to quickly disseminate messages when there are new MPL multicast packets, but reduces transmission overhead as the dissemination process completes. The meaning is not clear due to the limited definitions. I would rewrite = as: "Trickle's adaptive transmission interval allows MPL to quickly dissemina= te MPL multicast packets when there are new original multicast packets" Trickle's suppression mechanism and transmission time selection allow MPL's communication rate to scale logarithmically with density. Hui & Kelsey Expires April 22, 2013 [Page 6] =0C Internet-Draft MPL October 2012 4. Message Formats 4.1. MPL Option The MPL Option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. The MPL Option has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S |M| rsv | sequence | seed-id (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type XX (to be confirmed by IANA). Opt Data Len Length of the Option Data field in octets. MUST be set to s/either 2 or 4/2, 4, 10 or 18/. S 2-bit unsigned integer. Identifies the length of seed-id. 0 indicates that the seed-id is 0 and not included in the MPL Option. 1 indicates that the seed-id is a 16-bit unsigned integer. 2 indicates that the seed-id is a 64-bit unsigned integer. 3 indicates that the seed-id is a 128- bit unsigned integer. M 1-bit flag. 0 indicates that the value in sequence is not the greatest sequence number that was received from the MPL seed. rsv 5-bit reserved field. MUST be set to zero and incoming MPL multicast packets in which they are not zero MUST be dropped. This effectively becomes a version field. It would be better to expl= icitly state that this is a version field and this draft uses version =3D= 0 and any other version is dropped. Future revisions can then describe b= ehavior for versions less that the one they will specify. = =20 sequence 8-bit unsigned integer. Identifies relative ordering of MPL multicast packets from the source identified by seed-id. seed-id Uniquely identifies the MPL seed that initiated dissemination of the MPL multicast packet. The size of seed-id is indicated by the S field. The Option Data of the Trickle Multicast option MUST NOT change as the MPL multicast packet is forwarded. Nodes that do not understand Hui & Kelsey Expires April 22, 2013 [Page 7] =0C Internet-Draft MPL October 2012 the Trickle Multicast option MUST discard the packet. Thus, according to [RFC2460] the three high order bits of the Option Type must be set to '010'. The Option Data length is variable. The seed-id uniquely identifies an MPL seed within the MPL domain. When seed-id is 128 bits (S=3D3), the MPL seed MAY use an IPv6 address= assigned to one of its interfaces that is unique within the MPL domain. Managing MPL seed identifiers is not within scope of this document. What is the use case for 64-bits (S=3D2)? Also the use case for S=3D= 0 is not clear, as it implies that seed-id is 0. Is this meant for a sing= le MPL seed within the LLN? Or that the seed-id is implied from source ad= dress? =20 =20 The sequence field establishes a total ordering of MPL multicast packets from the same MPL seed. The MPL seed MUST increment the sequence field's value on each new MPL multicast packet that it disseminates. Implementations MUST follow the Serial Number Arithmetic as defined in [RFC1982] when incrementing a sequence value or comparing two sequence values. Future updates to this specification may define additional fields following the seed-id field. If a proper version number is used, this is more justifiable, otherw= ise it is difficult to justify this =20 4.2. ICMPv6 MPL Message The MPL forwarder uses ICMPv6 MPL messages to advertise information about recently received MPL multicast packets. The ICMPv6 MPL message has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . MPL Window[1..n] . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address A link-local address assigned to the sending interface. Destination Address The link-local all-nodes MPL forwarders multicast address (FF02::TBD). Hui & Kelsey Expires April 22, 2013 [Page 8] =0C Internet-Draft MPL October 2012 Hop Limit 255 ICMPv6 Fields: Type XX (to be confirmed by IANA). Code 0 Checksum The ICMP checksum. See [RFC4443]. MPL Window[1..n] List of one or more MPL Windows (defined in Section 4.2.1). An MPL forwarder transmits an ICMPv6 MPL message to advertise information about buffered MPL multicast packets. More explicitly, the ICMPv6 MPL message encodes the sliding window state (described in Section 5.2) that the MPL forwarder maintains for each MPL seed. The advertisement serves to indicate to neighboring MPL forwarders regarding newer messages that it may send or the neighboring MPL forwarders have yet to receive. 4.2.1. MPL Window An MPL Window encodes the sliding window state (described in Section 5.2 that the MPL forwarder maintains for an MPL seed. Each MPL Window has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | w-min | w-len | S | seed-id (0, 2 or 16 octets) | = 0, 2, 8 or 16 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . buffered-mpl-packets (0 to 8 octets) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ w-min 8-bit unsigned integer. Indicates the first sequence number associated with the first bit in buffered-mpl-packets. w-len 6-bit unsigned integer. Indicates the size of the sliding window and the number of valid bits in buffered-mpl-packets. The sliding window's upper bound is the sum of w-min and w-len. Hui & Kelsey Expires April 22, 2013 [Page 9] =0C Internet-Draft MPL October 2012 S 2-bit unsigned integer. Identifies the length of seed-id. 0 indicates that the seed-id value is 0 and not included in the MPL Option. 1 indicates that the seed-id value is a 16-bit unsigned integer. 2 indicates that the seed-id value is a 128-bit unsigned integer. 3 is reserved. =20 Different from the MPL Option =20 seed-id Indicates the MPL seed associated with this sliding window. buffered-mpl-packets Variable-length bit vector. Identifies the sequence numbers of MPL multicast packets that the MPL forwarder has buffered. The sequence number is determined by w-min + i, where i is the offset within buffered-mpl-packets. The MPL Window does not have any octet alignment requirement. Hui & Kelsey Expires April 22, 2013 [Page 10] =0C Internet-Draft MPL October 2012 5. MPL Forwarder Behavior An MPL forwarder implementation needs to manage sliding windows for each active MPL seed. The sliding window allows the MPL forwarder to determine what multicast packets to accept and what multicast packets are buffered. An MPL forwarder must also manage MPL packet transmissions. 5.1. Multicast Packet Dissemination MPL uses the Trickle algorithm to control packet transmissions when disseminating MPL multicast packets [RFC6206]. MPL provides two propagation mechanisms for disseminating MPL multicast packets. 1. With proactive propagation, an MPL forwarder transmits buffered MPL multicast packets=20 The buffered packets are stored in the conceptual variable BufferedPacket= s, so I would mention this to be unequivocal. I would say: "an MPL forwarder transmits MPL multicast packets from BufferedPackets". I would use this generally instead of the term "buffered MPL multicast pa= ckets", or at least clearly define what "buffered MPL multicast packet" m= eans. If forward referencing is an issue, add a reference. =20 =20 using the Trickle algorithm. This method is called proactive propagation since an MPL forwarder s/acti= vely/proactively/ transmits MPL multicast packets s/without/, i.e. without/ discovering that a neighboring MPL forwarder has yet to receive the s/message/co= rresponding MPL multicast packets/. 2. With reactive propagation, an MPL forwarder transmits ICMPv6 MPL messages using the Trickle algorithm. An MPL forwarder only transmits buffered MPL multicast packets upon discovering that neighboring devices have not yet s/to receive/received/= the corresponding MPL multicast packets. When receiving a new multicast packet, an MPL forwarder first utilizes proactive propagation to forward the MPL multicast packet. Proactive propagation reduces dissemination latency since it does not require discovering that neighboring devices have not yet received the MPL multicast packet. MPL forwarders utilize proactive propagation for newly received MPL multicast packets since they can assume that some neighboring MPL forwarders have yet to receive the MPL multicast packet. After a limited number of MPL multicast packet transmissions, the MPL forwarder may terminate proactive propagation for the MPL multicast packet. An MPL forwarder may optionally use reactive propagation to continue the dissemination process with lower communication overhead. With reactive propagation, neighboring MPL forwarders use ICMPv6 MPL messages to discover new MPL multicast messages that have not yet been received. When discovering that a neighboring MPL forwarder has not yet received a new MPL multicast packet, the MPL forwarder enables proactive propagation again. Hui & Kelsey Expires April 22, 2013 [Page 11] =0C Internet-Draft MPL October 2012 5.1.1. Trickle Parameters and Variables As specified in RFC 6206 [RFC6206], a Trickle timer runs for a defined interval and has three configuration parameters: the minimum interval size Imin, the maximum interval size Imax, and a redundancy constant k. MPL defines a fourth configuration parameter, TimerExpirations, which indicates the number of Trickle timer expiration events that occur before terminating the Trickle algorithm. Each MPL forwarder maintains a separate Trickle parameter set for s/the proactive and reactive propagation methods/proactive and reactive prop= agation/. It is simply called "proactive propagation" and "reactive propagatio= n" elsewhere - no need to call them "methods" TimerExpirations MUST be greater than 0 for proactive propagation. TimerExpirations MAY be set to 0 for reactive propagation, which effectively disables reactive propagation. As specified in RFC 6206 [RFC6206], a Trickle timer has three variables: the current interval size I, a time within the current interval t, and a counter c. MPL defines a fourth variable, e, which counts the number of Trickle timer expiration events since the Trickle timer was last reset. 5.1.2. Proactive Propagation With proactive propagation, the MPL forwarder transmits buffered MPL multicast packets using the Trickle algorithm. Each buffered MPL multicast packet that is proactively being disseminated with proactive propagation has an associated Trickle timer. Adhering to Section 5 of RFC 6206 [RFC6206], this document defines the following: o This document defines a "consistent" transmission for proactive propagation as receiving an MPL multicast packet that has the same MPL seed identifier and sequence number as a buffered MPL packet. o This document defines an "inconsistent" transmission for proactive propagation as receiving an MPL multicast packet that has the same MPL seed identifier, the M flag s/set, and/set and/ has = a sequence number less than the buffered MPL multicast packet's sequence number. o This document does not define any external "events". o This document defines both MPL multicast packets and ICMPv6 MPL multicast packets as Trickle messages. What is a "ICMPv6 MPL multicast packet"? Do you mean "ICMPv6 MPL mes= sage"? This is confusing - is the ICMPv6 MPL message actually a Trickle m= essage, i.e. sent out using a Trickle timer? I thought it was sent period= ically or is it in conjunction with the MPL multicast packet? Also it sho= uld mention only MPL multicast packets here (i.e. in the proactive propag= ation part) as the ICMPv6 MPL message plays no part in proactive propagat= ion. These messages are defined in the sections below. Hui & Kelsey Expires April 22, 2013 [Page 12] =0C Internet-Draft MPL October 2012 o The actions outside the Trickle algorithm that the protocol takes involve managing sliding window state, and is specified in Section 5.2. 5.1.3. Reactive Propagation With reactive propagation, the MPL forwarder transmits ICMPv6 MPL messages using the Trickle algorithm. A MPL forwarder maintains a single Trickle timer for reactive propagation with each MPL domain. When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not execute the Trickle algorithm for reactive propagation and reactive propagation is disabled. Adhering to Section 5 of RFC 6206 [RFC6206], this document defines the following: o This document defines a "consistent" transmission for reactive propagation as receiving an ICMPv6 MPL message that indicates neither the receiving nor transmitting node has new MPL multicast packets to offer. o This document defines an "inconsistent" transmission for reactive propagation as receiving an ICMPv6 MPL message that indicates either the receiving or transmitting node has at least one new MPL multicast packet to offer. o This document defines an "event" for reactive propagation as updating any sliding window (i.e. changing the value of WindowMin, WindowMax, or the set of buffered MPL multicast packets) in response to receiving an MPL multicast packet. We use WindowMax and WindowMin here so we should also use BufferedPa= ckets =20 o This document defines both MPL multicast packets and ICMPv6 MPL multicast packets as Trickle messages. These messages are defined in the sections below. =20 What is a "ICMPv6 MPL multicast packet"? Do you mean "ICMPv6 MPL mes= sage"? This is confusing - is the ICMPv6 MPL message actually a Trickle m= essage, i.e. sent out using a Trickle timer? I thought it was sent period= ically or is it in conjunction with the MPL multicast packet? = o The actions outside the Trickle algorithm that the protocol takes involve managing sliding window state, and is specified in Section 5.2. 5.2. Sliding Windows Every MPL forwarder MUST maintain a sliding window of sequence numbers for each MPL seed of recently received MPL packets. The sliding window performs two functions: 1. Indicate what MPL multicast packets the MPL forwarder should accept. 2. Indicate what MPL multicast packets are buffered and may be transmitted to neighboring MPL forwarders. Hui & Kelsey Expires April 22, 2013 [Page 13] =0C Internet-Draft MPL October 2012 Each sliding window logically consists of: 1. A lower-bound sequence number, WindowMin, that represents the sequence number of the oldest MPL multicast packet the MPL forwarder is willing to receive or has buffered. An MPL forwarder MUST ignore any MPL multicast packet that has sequence value less than than WindowMin. 2. An upper-bound sequence value, WindowMax, that represents the sequence number of the next MPL multicast packet that the MPL forwarder expects to receive. An MPL forwarder MUST accept any MPL multicast packet that has sequence number greater than or equal to WindowMax. 3. A list of MPL multicast packets, BufferedPackets, buffered by the MPL forwarder. Each entry in BufferedPackets MUST have a sequence number in the range [WindowMin, WindowMaxs/)/]/. 4. A timer, HoldTimer, that indicates the minimum lifetime of the sliding window. The MPL forwarder MUST NOT free a sliding window before HoldTimer expires. When receiving an MPL multicast packet, if no existing sliding window exists for the MPL seed, the MPL forwarder MUST create a new sliding window before accepting the MPL multicast packet. The MPL forwarder may reclaim memory resources by freeing a sliding window for another MPL seed if its HoldTimer has expired. If, for any reason, the MPL forwarder cannot create a new sliding window, it MUST discard the packet. If a sliding window exists for the MPL seed, the MPL forwarder MUST ignore the MPL multicast packet if the packet's sequence number is less than WindowMin or appears in BufferedPackets. Otherwise, the MPL forwarder MUST accept the packet and determine whether or not to forward the packet and/or pass the packet to the next higher layer. When accepting an MPL multicast packet, the MPL forwarder MUST update the sliding window based on the packet's sequence number. If the sequence number is not less than WindowMax, the MPL forwarder MUST set WindowMax to 1 greater than the packet's sequence number. If WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the MPL forwarder MUST increment WindowMin such that WindowMax - WindowMin <=3D MPL_MAX_WINDOW_SIZE. At the same time, the MPL forwarder MUST free any entries in BufferedPackets that have a sequence number less than WindowMin. If the MPL forwarder has available memory resources, it MUST buffer the MPL multicast packet for proactive propagation. If not enough Hui & Kelsey Expires April 22, 2013 [Page 14] =0C Internet-Draft MPL October 2012 memory resources are available to buffer the packet, the MPL forwarder MUST increment WindowMin and free entries in BufferedPackets that have a sequence number less than WindowMin until enough memory resources are available. Incrementing WindowMin will ensure that the MPL forwarder does not accept previously received packets. An MPL forwarder MAY reclaim memory resources from sliding windows for other MPL seeds. If a sliding window for another MPL seed is actively disseminating messages and has more than one entry in its BufferedPackets, the MPL forwarder may free entries for that MPL seed by incrementing WindowMin as described above. If the MPL forwarder cannot free enough memory resources to buffer the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1 greater than the packet's sequence number. When memory resources are available, an MPL forwarder SHOULD buffer a MPL multicast packet until the proactive propagation completes (i.e. the Trickle algorithm stops execution) and MAY buffer for longer. After proactive propagation completes, the MPL forwarder may advance WindowMin to the packet's sequence number to reclaim memory resources. When the MPL forwarder no longer buffers any packets, it MAY set WindowMin equal to WindowMax. When setting WindowMin equal to WindowMax, the MPL forwarder MUST initialize HoldTimer to WINDOW_HOLD_TIME and start HoldTimer. After HoldTimer expires, the MPL forwarder MAY free the sliding window to reclaim memory resources. 5.3. Transmission of MPL Multicast Packets The MPL forwarder manages buffered MPL multicast packet transmissions using the Trickle algorithm. When adding a packet to BufferedPackets, the MPL forwarder MUST create a Trickle timer for the packet and start execution of the Trickle algorithm. After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL forwarder MUST stop executing the Trickle algorithm. It would be better to use this with regard to incrementing 'e', i.e.= increment 'e' and stop when 'e' equals PROACTIVE_TIMER_EXPIRATIONS. Also= important to show how 'e' is used in reactive propagation. When a buffered MPL multicast packet does not have an active Trickle timer, the MPL forwarder MAY free the buffered packet by advancing WindowMin to 1 greater than the packet's sequence number. Should the text below be in a separate section? =20 Each interface that supports MPL is configured with exactly one MPL multicast scope. The MPL multicast scope MUST be site-local or smaller and defaults to link-local. A scope larger than link-local MAY be used only when that scope corresponds exactly to the MPL domain. The statement "A scope larger than link-local..." highlights the pro= blem of binding the address scope of the single MPL multicast scope to th= e MPL domain. In many cases, site-local may be wider than the MPL domain.= Hui & Kelsey Expires April 22, 2013 [Page 15] =0C Internet-Draft MPL October 2012 An MPL domain may therefore be composed of one or more MPL multicast scopes. For example, the MPL domain may be composed of a single MPL multicast scope when using a site-local scope. Alternatively, the MPL domain may be composed of multiple MPL multicast scopes when using a link-local scope. The two cases could seamlessly coexist as well, i.e. a single MPL mu= lticast scope bound to a "subnet-local" and multiple link-local MPL multi= cast scopes. If there is a defined scope which has the same "reach" as a = MPL multicast scope (e.g. a "subnet-local" scope) and the destination add= ress is known to be within that scope, then IPv6-in-IPv6 is not necessary= =2E However, the administrative problem of matching an address scope to t= he "reach" of a MPL multicast scope still remains. =20 IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an original multicast packet whose source or destination address is outside the MPL multicast scope. The above statement does not allow the use of subnet-local scope and forw= arding without encapsulation within the MPL domain. I would say: "IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an ori= ginal non-MPL multicast packet, or when forwarding a multicast packet whe= re the destination address scope is outside the reach of the MPL multicas= t scope." I'm not sure the case can exist but if an original multicast packet did h= ave an MPL Option, that should be removed before encapsulation as it will= be meaningless after it passes through the multicast "tunnel" IPv6-in-IPv6 encapsulation is necessary to support Path MTU discovery when the MPL forwarder is not the source of the original multicast packet. 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. The destination address scope for the outer IPv6 header MUST be the MPL multicast scope. When an MPL domain is composed of multiple MPL multicast scopes (e.g. when the MPL multicast scope is link-local), an MPL forwarder MUST decapsulate and encapsulate the original multicast packet when crossing between different MPL multicast scopes. In doing so, the MPL forwarder MUST duplicate the MPL Option, unmodified, in the new outer IPv6 header. The IPv6 destination address of the MPL multicast packet is the all- MPL-forwarders multicast address (TBD). The scope of the IPv6 destination address is set to the MPL multicast scope. =20 This probably needs more clarification. The group ID part of the add= ress will be set to some all-MPL-forwarders ID but the upper part could b= e link-local multicast or subnet-local multicast (i.e. where MPL domain i= s equivalent to single MPL multicast scope). 5.4. Reception of MPL Multicast Packets Upon receiving an MPL multicast packet, the MPL forwarder first determines whether or not to accept and buffer the MPL multicast packet based on its MPL seed and sequence value, as specified in Section 5.2. If the MPL forwarder accepts the MPL multicast packet, the MPL forwarder determines whether or not to deliver the original multicast packet to the next higher layer. For example, if the MPL multicast packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the outer IPv6 header, which also removes s/MPL Option/the MPL Option= /. 5.5. Transmission of ICMPv6 MPL Messages The MPL forwarder generates and transmits a new ICMPv6 MPL message whenever Trickle requests a transmission. The MPL forwarder includes an encoding of each sliding window in the ICMPv6 MPL message. Each sliding window is encoded using an MPL Window entry, defined in Section 5.2. The MPL forwarder sets the MPL Window fields as Hui & Kelsey Expires April 22, 2013 [Page 16] =0C Internet-Draft MPL October 2012 follows: S If the MPL seed identifier is 0, set S to 0. If the MPL seed identifier is within the range [1, 65535], set S to 2. Otherwise, set S to 3. w-min Set to the lower bound of the sliding window (i.e. WindowMin). w-len Set to the length of the window (i.e. WindowMax - WindowMin). seed-id If S is non-zero, set to the MPL seed identifier. buffered-mpl-packets Set each bit that represents a sequence number of a packet in BufferedPackets to 1. Set all other bits to 0. The i'th bit in buffered-mpl-packets represents a sequence number of w-min + i. 5.6. Reception of ICMPv6 MPL Messages An MPL forwarder processes each ICMPv6 MPL message that it receives to determine if it has any new MPL multicast packets to receive or offer. An MPL forwarder determines if a new MPL multicast packet has not been received from a neighboring node if any of the following conditions hold true: 1. The ICMPv6 MPL message includes an MPL Window for an MPL seed that does not have a corresponding sliding window entry on the MPL forwarder. 2. The neighbor has a packet in its BufferedPackets that has s/sequence value/a sequence number/ greater than or equ= al to WindowMax (i.e. w-min + w-len >=3D WindowMax). 3. The neighbor has a packet in its BufferedPackets that has s/sequence/a sequence/ number within range of the slidi= ng window but is not included in s/BufferedPackets/the MPL forwarder's BufferedPac= kets/ (i.e. the i'th bit in buffered-mpl- packets is set to 1, where the sequence number is w-min + i). It's important to be clear about which BufferedPackets we are talkin= g about here, otherwise it gets confusing. =20 When an MPL forwarder determines that it has not yet received a new MPL multicast packet buffered by a neighboring device, the MPL forwarder resets the Trickle timer associated with reactive propagation. An MPL forwarder determines if an entry in BufferedPackets has not been received by a neighboring MPL forwarder if any of the following Hui & Kelsey Expires April 22, 2013 [Page 17] =0C Internet-Draft MPL October 2012 conditions hold true: 1. The ICMPv6 MPL message does not include an MPL Window for the packet's MPL seed. 2. The packet's sequence number is greater than or equal to the neighbor's WindowMax value (i.e. the packet's sequence number is greater than or equal to w-min + w-len). 3. The packet's sequence number is within the range of the neighbor's sliding window [WindowMin, WindowMax), but not included in the neighbor's s/BufferedPacket/BufferedPackets/<= /RCC> (i.e. the packet's sequence number is greater than or equal to w-min, strictly less than w-min + w-len, and the corresponding bit in buffered-mpl- packets is set to 0. When an MPL forwarder determines that it has at least one buffered MPL multicast packet that has not yet been received by a neighbor, the MPL forwarder resets the Trickle timer associated with reactive propagation. Additionally, for each buffered MPL multicast packet that should be transferred, the MPL forwarder MUST reset the Trickle timer and reset s/e/the 'e' counter/ to 0 for proactive pro= pagation. If the Trickle timer for proactive propagation has already stopped execution, the MPL forwarder MUST initialize a new Trickle timer and start execution of the Trickle algorithm. Hui & Kelsey Expires April 22, 2013 [Page 18] =0C Internet-Draft MPL October 2012 6. MPL Parameters An MPL forwarder maintains two sets of Trickle parameters for the proactive and reactive methods. The Trickle parameters are listed below: PROACTIVE_IMIN The minimum Trickle timer interval, as defined in [RFC6206] for proactive propagation. PROACTIVE_IMAX The maximum Trickle timer interval, as defined in [RFC6206] for proactive propagation. PROACTIVE_K The redundancy constant, as defined in [RFC6206] for proactive propagation. PROACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations that occur before terminating the Trickle algorithm. MUST be set to a value greater than 0. May be worth stating it is used in conjunction with the 'e' counter<= /RCC> =20 REACTIVE_IMIN The minimum Trickle timer interval, as defined in [RFC6206] for reactive propagation. REACTIVE_IMAX The maximum Trickle timer interval, as defined in [RFC6206] for reactive propagation. REACTIVE_K The redundancy constant, as defined in [RFC6206] for reactive propagation. REACTIVE_TIMER_EXPIRATIONS The number of Trickle timer expirations that occur before terminating the Trickle algorithm. MAY be set to 0, which disables reactive propagation. May be worth stating it is used in conjunction with the 'e' counter<= /RCC> WINDOW_HOLD_TIME The minimum lifetime for sliding window state. Hui & Kelsey Expires April 22, 2013 [Page 19] =0C Internet-Draft MPL October 2012 7. Acknowledgements The authors would like to acknowledge the helpful comments of Robert Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter van der Stok, which greatly improved the document. Hui & Kelsey Expires April 22, 2013 [Page 20] =0C Internet-Draft MPL October 2012 8. IANA Considerations The Trickle Multicast option requires an IPv6 Option Number. HEX act chg rest --- --- --- ----- C 01 0 TBD The first two bits indicate that the IPv6 node MUST discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data MUST NOT change en-route. Hui & Kelsey Expires April 22, 2013 [Page 21] =0C Internet-Draft MPL October 2012 9. Security Considerations TODO. Agree with other comments this must be done and that last call is pr= emature Hui & Kelsey Expires April 22, 2013 [Page 22] =0C Internet-Draft MPL October 2012 10. References 10.1. Normative References [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. 10.2. Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-06 (work in progress), September 2011. Hui & Kelsey Expires April 22, 2013 [Page 23] =0C Internet-Draft MPL October 2012 Authors' Addresses Jonathan W. Hui Cisco 170 West Tasman Drive San Jose, California 95134 USA Phone: +408 424 1547 Email: jonhui@cisco.com Richard Kelsey Silicon Labs 25 Thomson Place Boston, Massachusetts 02210 USA Phone: +617 951 1225 Email: richard.kelsey@silabs.com Hui & Kelsey Expires April 22, 2013 [Page 24] =0C --------------060302020505080204030104-- --------------ms020109020908070109030905 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 Fw0xMjEwMzEyMTM1NTNaMCMGCSqGSIb3DQEJBDEWBBSCpdrKZOPhe9nrbmpXPuec1bFntTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAACZ2k3A9CeYbaDFZawsYK2fr703T+b+BAzv8UdVM0Zp9iZ2 0wzGBt5JegOaV6pv3AAZ1MHo4hqOBM7cGmY5yd17EIM1Dm42ciyJPMI/SYkt+qkYQ3hxzhhf 6GfMLrIueY3NBiLakN3lwjLSKBatsdUY9Tyz2DexVzpbUjXA1TFQq/qojC7R4YUFS2wHf1Jj qG5YlwVwBqa7xqZEPUTpUlsIKt5grSAQBTR+zEH911JB65LiYUM39Q6gGa7tSY3KZ4k8MEUG KbfubCnXMLN2rjJU3DKUuGQCM7AJsmcHtGMrSYm2J+qwZbOhg2chEpRSae4fX9QLgvITMPZs zYnFoRoAAAAAAAA= --------------ms020109020908070109030905-- From pal@cs.stanford.edu Wed Oct 31 16:17:16 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 3E51421F889B for ; Wed, 31 Oct 2012 16:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 bCYucUwh0WHw for ; Wed, 31 Oct 2012 16:17:15 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id BFDAB21F8899 for ; Wed, 31 Oct 2012 16:17:15 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[10.111.222.25]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TThX7-0001YO-2s; Wed, 31 Oct 2012 16:17:13 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8702.1351708776@obiwan.sandelman.ca> Date: Wed, 31 Oct 2012 16:17:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <50BC36AD-E4E2-4FD4-8BF1-B697EA86367C@cs.stanford.edu> References: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> <47B5B50A-369F-474A-A4C8-1A951C164E1B@etri.re.kr> <8702.1351708776@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1283) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: JeongGil Ko , "roll@ietf.org WG" 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: Wed, 31 Oct 2012 23:17:16 -0000 On Oct 31, 2012, at 11:39 AM, Michael Richardson wrote: >=20 > Please be aware that among JP and I, I'm the one pushing loudest to=20 > restrict our meeting slot time to (in order of priority): >=20 > 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. >=20 > You may have noticed how incredibly full the IETF meetings are. >=20 > The Area Directors have been pushing very hard on the WG chairs=20 > 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. =20 > If it's not controversial, then we don't need to discuss it. >=20 > 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= From dat@exegin.com Wed Oct 31 16:22: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 B2AB021F889B for ; Wed, 31 Oct 2012 16:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybnqdvYxHlUt for ; Wed, 31 Oct 2012 16:22:11 -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 C540B21F881F for ; Wed, 31 Oct 2012 16:22:11 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1313491pbb.31 for ; Wed, 31 Oct 2012 16:22:11 -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=j09QybtkFVSYZx/OHFuISxtixkSEujwrxbXlkVcvb/M=; b=ieWpb3uCv12g4/oBB7Qxl6rj/oCdANS+ockw+VU80GOb4p3IjXR/OOB3qUWLKZLlzp qX2dxvsft4KQFRWBvsjhk/RuI0pSG5CuB9+wLUzEK/oTMJnk3OjkiWMlMj2CPaKXYgW+ A0hqlQ3uVLyJaHnPsahDQa83Q5BW9fBp7d/xhvN8+0oZHvfWTvTwXUY7EZZq8gI4WVqK OMsNWwxHeOgCX0TKbpGNiisQ6Er9j6MVgDDsXV8iP7iKzEma3CKhQNwvyiJNWOXp1HF/ mUeFlna39WU5ejk2p9aWqfX0VKzpSKva4URIoOxwKoECNoYdLm7kw/PDF97WSdwCP+7l IfRQ== Received: by 10.68.226.71 with SMTP id rq7mr74931539pbc.65.1351725731586; Wed, 31 Oct 2012 16:22:11 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id c7sm2891979pay.10.2012.10.31.16.22.09 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 16:22:10 -0700 (PDT) Message-ID: <5091B2A3.1090205@exegin.com> Date: Wed, 31 Oct 2012 16:22:11 -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: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080404000705030205070404" X-Gm-Message-State: ALoCoQlbMFrJ2vcZ7U0IHm8XUqjJLWn3jzzNyyFFSmkDJ+zGbTg3g+m+EKCCzVZLCa6eKcc5L42j 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: Wed, 31 Oct 2012 23:22:13 -0000 This is a multi-part message in MIME format. --------------080404000705030205070404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. 2. 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. 3. 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. 4. 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 --------------080404000705030205070404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.
  2. 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.
  3. 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.
  4. 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 <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 = 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 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" <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 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" <stokcons@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/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


    

    

  


--------------080404000705030205070404--

From jreddy@ti.com  Wed Oct 31 17:00:57 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 DE60D21F88FC for ; Wed, 31 Oct 2012 17:00:57 -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 7pQurSrmQHPe for ; Wed, 31 Oct 2012 17:00:57 -0700 (PDT)
Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id CF14821F889C for ; Wed, 31 Oct 2012 17:00:49 -0700 (PDT)
Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id qA100nmM011425 for ; Wed, 31 Oct 2012 19:00:49 -0500
Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id qA100nEH007378 for ; Wed, 31 Oct 2012 19:00:49 -0500
Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE72.ent.ti.com ([fe80::5c48:b90d:af93:5822%30]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 19:00:48 -0500
From: "Reddy, Joseph" 
To: "roll@ietf.org" 
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Thread-Index: Ac23wx9aJxvWGboRQVq3thCnuLeLpw==
Date: Thu, 1 Nov 2012 00:00:49 +0000
Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CAE2DB8@DLEE10.ent.ti.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.247.5.50]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 00:00:58 -0000

Hi Jonathan,

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 encapsu=
lation even when it is not needed.=20
Regarding the practical aspects of determining the MPL scope, I think that =
can be left to "administrative configuration". Other multicast details (e.g=
., the zone boundaries for scopes greater than link local) have to be admin=
istratively configured anyway.

2. Supporting different Trickle parameter sets:
I think this is a useful feature and should be included even if it is a sin=
gle flag (2 parameter sets). Typical use cases for multicast in LLN's try t=
o achieve either high reliability or low latency and having two sets of tri=
ckle parameters for each of them should help

3. Version field:
I think adding an explicit version field ( 2 bits should be enough) will he=
lp.

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 pack=
et but don't understand the MPL option will discard it anyway.

-Regards, Joseph



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

Date: Fri, 19 Oct 2012 17:31:52 +0000
From: "Jonathan Hui (johui)" 
To: "roll@ietf.org" 
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Message-ID:
	
Content-Type: text/plain; charset=3D"us-ascii"


ROLL WG,

This update includes the new text that was sent out during the last IETF me=
eting and incorporates comments received since then (special thanks to Robe=
rt Cragie, Esko Dijk, Owen Kirby, Joseph Reddy, Dario Tedeschi, and Peter v=
an der Stok).

The following are some open discussion items that were raised in the commen=
ts.  Would be great to hear your thoughts.

1) MPL multicast scope.  The current draft allows the MPL multicast scope t=
o be link-local scope or something larger.  On one hand, fixing the MPL mul=
ticast scope to be link-local reduces the number of options, makes things s=
impler, and improves interoperability. On the other hand, doing so will mak=
e IPv6-in-IPv6 encapsulation a MUST even when the source and destinations a=
re all in the MPL domain.

2) The S field.  The current draft includes an S field in the MPL Hop-by-Ho=
p Option to indicate the length of the seed identifier.  On one hand, the l=
ength of the seed identifier may be inferred by the Opt Data Len field.  On=
 the other hand, if any future specification wants to define additional fie=
lds following the seed identifier field, that specification would need some=
 way to indicate the length of the seed identifier.  The S field was origin=
ally included to allow the possibility of something like sub-TLVs, that are=
 extensively used throughout RPL.

3) Supporting different Trickle parameter sets.  The latest draft removes a=
 flag that indicates which of two parameter sets to use when disseminating =
MPL multicast packets.  We removed the flag in attempt to simplify the draf=
t.  Furthermore, it wasn't clear that a single flag (2 parameter sets) was =
sufficient.

4) Version number field.  The current draft does not include a version fiel=
d in the MPL Hop-by-Hop Option.  Instead, it sets all reserved bits to zero=
 and requires all devices that implement this draft to drop the message if =
any of those bits are non-zero.

--
Jonathan Hui


From jeonggil.ko@gmail.com  Wed Oct 31 18:18: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 6E9D021F8646 for ; Wed, 31 Oct 2012 18:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pf0h15p5HMun for ; Wed, 31 Oct 2012 18:18:20 -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 BB70921F8669 for ; Wed, 31 Oct 2012 18:18:12 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb11so1355553pad.31 for ; Wed, 31 Oct 2012 18:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VWVZVg59zDTk6+xDnAn4Ik/YUTuoiewzJlWsng9qSMY=; b=BoRG5QqDeR8uxXGnrK1UC/9e0XWJH4nSM8DCKYcaDwTA8w4GENvkwjvAsaCWflTQyg KoWQB/eaDtRqBE19cNlqwbhB7bgvFKp2905E2+4LV/qYvh3oaLbQNu96Bz7l/yrKSHFq HrXSAmSkXWpvtn8O1n+wvcE2GzfNULy9OrfIYgwt9ShxvR4eQwtm+MMIZhtAcN460pfa JXpP8u8H+NthHjNNGkP0BmupUXkJ59UUsIdVL7qrcESV+Tpyti4B572fdkafPvRRS/7X zw1TPdPJ3epe2BgGo6md8/EwvNevKkQuy7NR701slDyawuHYtqKLTwdNXWNKmvwl/fq3 gkCg==
Received: by 10.66.83.201 with SMTP id s9mr106531476pay.74.1351732692138; Wed, 31 Oct 2012 18:18:12 -0700 (PDT)
Received: from 192.168.nate.com ([203.226.212.84]) by mx.google.com with ESMTPS id c1sm3032066pav.23.2012.10.31.18.18.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 18:18:10 -0700 (PDT)
Sender: "JeongGil (John) Ko" 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: JeongGil Ko 
In-Reply-To: <8702.1351708776@obiwan.sandelman.ca>
Date: Thu, 1 Nov 2012 10:18:06 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1351629716.36391.YahooMailNeo@web160605.mail.bf1.yahoo.com> <47B5B50A-369F-474A-A4C8-1A951C164E1B@etri.re.kr> <8702.1351708776@obiwan.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1499)
Cc: "roll@ietf.org WG" 
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 01:18:21 -0000

Michael,

Thanks for the clarification. However, this information still doesn't =
explain why Industrial Deterministic Routing Extension for Low-Power and =
Lossy Networks is on the agenda and draft-ko-roll-mix-network-pathology =
is not on the agenda. I believe draft-ko-roll-mix-network-pathology had =
more discussions that the other on the mailing list on whether or not =
this feature was needed in RPL.

-John

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

On Nov 1, 2012, at 3:39 AM, Michael Richardson 
wrote:

>=20
> Please be aware that among JP and I, I'm the one pushing loudest to=20
> restrict our meeting slot time to (in order of priority):
>=20
> 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.
>=20
> You may have noticed how incredibly full the IETF meetings are.
>=20
> The Area Directors have been pushing very hard on the WG chairs=20
> to make sure that we understand that the IETF sessions are *not* for
> presentations, but for discussion.
>=20
> So, again: If there is work that you think has relevance to the
> ROLL WG, then please bring it up on the list. =20
> If it's not controversial, then we don't need to discuss it.
>=20
> 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.
>=20
> --=20
> Michael Richardson , Sandelman Software Works=20=

> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>=20


From johui@cisco.com  Wed Oct 31 20:54: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 ADE8621F85E6 for ; Wed, 31 Oct 2012 20:54:52 -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=[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 n7KMBRPxMpQq for ; Wed, 31 Oct 2012 20:54:51 -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 04F3921F85BC for ; Wed, 31 Oct 2012 20:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19139; q=dns/txt; s=iport; t=1351742091; x=1352951691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9H1Ae1w7HHiUpKf8TxEx5TT/Fa1MMicF5lUUIkHI65E=; b=QGCSWofNjRt+xvcCZc1JOLe5WdAe29RrgjLI0yUNtNxvlauV/DIxxRoS CdjwucercQZJ6SU/g98JxFrr1PgVyOfFaouYE07+cS26/e4FiWjYru3yV qIg7RYOH9IeXGz0E2Nu7NwjQCHKCRsVOxCado4lNNHZ6HAD7yOY3YIicO E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACLykVCtJV2Y/2dsb2JhbAA6CsNkgQiCHwEBBAEBAQ8BWwsQAgEIDhQdBycLFBECBA4FCBMHh1IDDwubCpZEBYlYBIt7EAWFRWEDiCWKIJIJgWuCb4FcCBce
X-IronPort-AV: E=Sophos;i="4.80,691,1344211200";  d="scan'208,217";a="137595257"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2012 03:54:50 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA13sohL011476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 03:54:50 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 22:54:49 -0500
From: "Jonathan Hui (johui)" 
To: Dario Tedeschi 
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
Thread-Index: AQHNt+Sjjd3eM9iNy0mrVYgwyyr3Lg==
Date: Thu, 1 Nov 2012 03:54:48 +0000
Message-ID: 
References:     <5091B2A3.1090205@exegin.com>
In-Reply-To: <5091B2A3.1090205@exegin.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.91.87]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--37.994300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B50D0F163D52B74DA572DD345D5044AF0F6ECE93xmbrcdx04ciscoc_"
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: Thu, 01 Nov 2012 03:54:52 -0000

--_000_B50D0F163D52B74DA572DD345D5044AF0F6ECE93xmbrcdx04ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Dario,

You've made good points on why restricting to link-local scope would be sim=
pler overall.  Except for point 2, non-MPL aware routers will not simply fo=
rward encapsulated multicast datagrams as long as the MPL Option type has t=
he 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 dev=
ices within each MPL scope zone needs to be configured with an MPL multicas=
t address that identifies the MPL multicast scope zone.  One way forward is=
 to have the draft explicitly indicate that is a necessary configuration, a=
nd leave the actual configuration method out of scope.  Of course, there ar=
e many ways one could configure an interface (including manual configuratio=
n), so that is one argument for leaving it out of scope.

Another possible solution is to include an "MPL domain" identifier within t=
he 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 Limi=
t field in the Hop-by-Hop Option.  But that brought up complications with w=
hat happens with a devices first receives a messages with different Hop Lim=
it 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 cou=
ld 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 *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.
  2.  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.
  3.  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=
.
  4.  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.

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




--_000_B50D0F163D52B74DA572DD345D5044AF0F6ECE93xmbrcdx04ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <189C6630F5493440B9C7EC99C49BB39E@cisco.com>
Content-Transfer-Encoding: quoted-printable












Hi Dario,







You've made good points on why restricting to link-local scope would b=
e 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 recogn=
ize the option.







However, restricting to link-local scope does not solve Peter's use ca=
se of limiting the multicast dissemination to a subset of devices.  Ha=
ving a non-link-local MPL scope is one method to solve his problem.  G=
ranted, 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 ex=
plicitly indicate that is a necessary configuration, and leave the actual c=
onfiguration method out of scope.  Of
 course, there are many ways one could configure an interface (including ma=
nual configuration), so that is one argument for leaving it out of scope.






Another possible solution is to include an "MPL domain" iden=
tifier within the Hop-by-Hop Option itself rather than using the IPv6 Desti=
nation 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 complicati=
ons with what happens with a devices first receives a messages with differe=
nt 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.  Alternative=
ly, 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 <dat@exegin.com> 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 define=
d (i.e. on the link). Higher scopes are not well-defined and can cover wide=
 domains depending on network configuration and administration.

  2. 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.

  3. A higher scope complicates the forwarding logic that needs to be i=
mplemented in an MPL router. The complication comes when a router receives =
an MPL datagram and needs to figure out whether to decapsulate or not. Gran=
ted, 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.

  4. In conjunction with 3. Link-local scope also makes it easier for a=
n MPL router to determine if the inner multicast address is one that a high=
er 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 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 <stokcons@xs4all.nl> w=
rote:






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 (u=
se 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 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" <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 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" <stokcons@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 modi=
fy the
document.





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











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











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

















--_000_B50D0F163D52B74DA572DD345D5044AF0F6ECE93xmbrcdx04ciscoc_--

From johui@cisco.com  Wed Oct 31 21:59: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 0E74821F85DA for ; Wed, 31 Oct 2012 21:59:38 -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 7MT60vpRHDWt for ; Wed, 31 Oct 2012 21:59:37 -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 2C2D121F85D2 for ; Wed, 31 Oct 2012 21:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3057; q=dns/txt; s=iport; t=1351745977; x=1352955577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mC8KaBVWTNYPSqlz0Z+Yi15EHdgwUfJMHLAv3QLMpbg=; b=ThELkhhfp3eauGhaPzoF5mItOvjo3BYdVPxN5dlyiQfkgKpD83YzBUWZ 38YSUDmclXzNg47L/lzMm58QtCdSQBUzt7VjQNuVx4pQyla4uiQBBe0S7 JVjqv/yQcNcOt5+9ojjIoGT8gOYTFt9b6lW+OMn1bHcCqobTE5qGTOuvY Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAIMAklCtJXG8/2dsb2JhbAA6CsNlgQiCHgEBAQMBEgEnPwULAgEIIhQQMiUCBA4FCBMHh14GmxegIot7EIVKYQOkToFrgm+CGQ
X-IronPort-AV: E=Sophos;i="4.80,691,1344211200"; d="scan'208";a="137657485"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 04:59:36 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA14xa8e027813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 04:59:36 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 23:59:36 -0500
From: "Jonathan Hui (johui)" 
To: "Reddy, Joseph" 
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt
Thread-Index: AQHNt+2vRb5TlPk7pUqtIMGVkE0DSw==
Date: Thu, 1 Nov 2012 04:59:35 +0000
Message-ID: 
References: <2AA5AC69E924D149A8D63EB676AF87DB2CAE2DB8@DLEE10.ent.ti.com>
In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CAE2DB8@DLEE10.ent.ti.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.91.87]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--31.032300-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: <564F27437F41134A93322C5593AA5ED7@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 04:59:38 -0000

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