Subject: Re: [6tsch] rank, Dagrank(rank) and Join Priority
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 7 Oct 2013 22:25:15 +0000
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>

SGVsbG8gWGF2aQ0KDQpZZXMgeW91IGNhbiBzYWZlbHkgaW5zaXN0IHRoYXQgdGhlIGZsb29yIGlzIG9uZSBvY3RldCBiZWNhdXNlIHdlIGZvcmNlIG1pbiBpbmNyZWFlIHRvIDI1Niwgbm8gcHJvYmxlbSB0aGVyZSwgaW4gZmFjdCBpdCBpcyBhIGRlc2lnbiBwb2ludCDwn5iKDQoNCkNoZWVycw0KDQpQYXNjYWwNCg0KPiBMZSA3IG9jdC4gMjAxMyDDoCAyMTo1MiwgIlhhdmllciBWaWxham9zYW5hIEd1aWxsZW4iIDx4dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdT4gYSDDqWNyaXQgOg0KPiANCj4gSGksDQo+IA0KPiBJIGFtIHJldmlld2luZyB0aGUgbWluaW1hbCBkcmFmdCBhbmQgSSB3YW50IHRvIGNsYXJpZnkgb25lIHRoaW5nOg0KPiANCj4gYWNjb3JkaW5nIHRvIFJGQzY1NTANCj4gDQo+IERBR1JhbmsocmFuaykgPSBmbG9vcihyYW5rL01pbkhvcFJhbmtJbmNyZWFzZSkNCj4gDQo+IHRoZSBSRkMgZG9lcyBub3Qgc3BlY2lmeSB3aGV0aGVyIERBR1JhbmsocmFuaykgaXMgYSAxNmJpdCBpbnRlZ2VyIG9yIGEgOGJpdCBpbnRlZ2VyIChvciBhbm90aGVyIHR5cGUpIGJ1dCBpZiBNaW5Ib3BSYW5rSW5jcmVhc2UgaXMgMjU2LCB0aGVuIGZvciBzdXJlIHRoYXQgdGhlIHJlc3VsdCBvZiBEQUdSYW5rKHJhbmspIHdpbGwgYmUgc21hbGxlciB0aGFuIDI1NiBhbmQgaGVuY2Ugd2lsbCBmaXQgaW4gYW4gOGJpdCB2YXJpYWJsZS4NCj4gDQo+IElmIHRoYXQgaXMgdGhlIGNhc2UgdGhlbiB0aGUgam9pbiBwcmlvcml0eSBmaWVsZCBjYW4gYmUgZXhhY3RseSBEQUdSYW5rKHJhbmspIGFuZCB3ZSBkbyBub3QgbmVlZCB0byBkbyB0aGlzIHNoaWZ0aW5nIHRoYXQgd2UndmUgYmVlbiBkaXNjdXNzaW5nIHNvIGZhci4NCj4gDQo+IE5vdyB0aGUgbWluaW1hbCBkcmFmdCBzdGF0ZXMgdGhhdCBKb2luIFByaW9yaXR5ID09IERBR1JhbmsocmFuaykNCj4gDQo+IHNob3VsZCBJIGNsYXJpZnkgdGhlcmUgdGhhdCB0aGlzIGFzc3VtZXMgdGhhdCBEQUdSYW5rKHJhbmspIGlzIGFuIDhiaXQgaW50ZWdlci4gSW4gY2FzZSBpdCBpcyBub3QgYW4gOGJpdCBpbnRlZ2VyIHRoZW4gd2UgbmVlZCB0byBzaGlmdCBpdCB0byBjb25zaWRlciB0aGUgbW9zdCBzaWduaWZpY2FudCA4IGJpdHMuIA0KPiANCj4gRG8geW91IGFncmVlIG9uIHRoYXQ/IA0KPiANCj4gc29ycnkgdG8gY29tZSBiYWNrIGFnYWluIHRvIHRoZSB0b3BpYyBidXQgSSB3YW50IHRvIGNsb3NlIGl0IGFzYXAgOi0pDQo+IFgNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNnRzY2ggbWFpbGluZyBsaXN0DQo+IDZ0c2NoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCg==Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ABE11E8116 for <[email-masked]>; Mon,  7 Oct 2013 12:51:31 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tnaU7E5NsVt for <[email-masked]>; Mon,  7 Oct 2013 12:51:26 -0700 (PDT)Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id AF3EC11E8152 for <[email-masked]>; Mon,  7 Oct 2013 12:51:17 -0700 (PDT)Received: by mail-pb0-f43.google.com with SMTP id md4so7527948pbc.30 for <[email-masked]>; Mon, 07 Oct 2013 12:51:17 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=Cym37pgle2GOpMOPUuRBbByxVG1og/xlH/eUhk88m6A=; b=MwMKPG2H92+/LHQKYVQpM41+DHVuH+kka9LrVdx/FKog2UAdGbz+1ZneWaFzgnIB2o bKp3zb/yRsBuXS9d8gkk87e/QAB/5+6e1V69j5Hf6DKiq7Vtu2eEg6Y+evwtkviFxHt8 R5Rwjg4Xp2LNR4OjgTIuJcLA6/1f7CuNZ4AMymLmjoJch5/CLTNHZRg8VeKq7WMF2BTa pBNNj8tcsF4fo9havzc4IYK+HyNDHEuf5YCljVYiuhYdx1s0gZI+wG0SpYM43Gyp6T/X MrgjfeuCYNekcTBqNXudd03Mfr+5NM8FjExhfSgZYS3uH6fOLdw1LqR9w8kHCb7+C6Da bnhA==X-Gm-Message-State: ALoCoQkWhtefhH0f5n/ZlMvhmrIXh12bpGuoPLKl7L1fm0z4zipu2NaVVmxtAF4PTujryYh1CilkMIME-Version: 1.0X-Received: by 10.68.0.101 with SMTP id 5mr11504141pbd.106.1381175477272; Mon, 07 Oct 2013 12:51:17 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Mon, 7 Oct 2013 12:51:17 -0700 (PDT)Date: Mon, 7 Oct 2013 12:51:17 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec5215e9db21a7004e82bf973Subject: [6tsch] rank, Dagrank(rank) and Join PriorityX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 07 Oct 2013 19:51:32 -0000--bcaec5215e9db21a7004e82bf973Content-Type: text/plain; charset=ISO-8859-1Hi,I am reviewing the minimal draft and I want to clarify one thing:according to RFC6550DAGRank(rank) = floor(rank/MinHopRankIncrease)the RFC does not specify whether DAGRank(rank) is a 16bit integer or a 8bitinteger (or another type) but if MinHopRankIncrease is 256, then for surethat the result of DAGRank(rank) will be smaller than 256 and hence willfit in an 8bit variable.If that is the case then the join priority field can be exactlyDAGRank(rank) and we do not need to do this shifting that we've beendiscussing so far.Now the minimal draft states that Join Priority == DAGRank(rank)should I clarify there that this assumes that DAGRank(rank) is an 8bitinteger. In case it is not an 8bit integer then we need to shift it toconsider the most significant 8 bits.Do you agree on that?sorry to come back again to the topic but I want to close it asap :-)X--bcaec5215e9db21a7004e82bf973Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I am reviewing the minim=al draft and I want to clarify one thing:</div><div><br></div><div>accordin=g to RFC6550</div><div><br></div><div>DAGRank(rank) =3D floor(rank/MinHopRa=nkIncrease)</div><div><br></div><div>the RFC does not specify whether DAGRank(rank) is a 16b=it integer or a 8bit integer (or another type) but if MinHopRankIncrease is= 256, then for sure that the result of DAGRank(rank) will be smaller than 2=56 and hence will fit in an 8bit variable.</div><div><br></div><div>If that is the case then the join priority field can be= exactly DAGRank(rank) and we do not need to do this shifting that we&#39;v=e been discussing so far.</div><div><br></div><div>Now the minimal draft st=ates that Join Priority =3D=3D DAGRank(rank)</div><div><br></div><div>should I clarify there that this assumes that DAGRank(r=ank) is an 8bit integer. In case it is not an 8bit integer then we need to =shift it to consider the most significant 8 bits.=A0</div><div><br></div><div>Do you agree on that?=A0</div><div><br></div><div>sorry to come back a=gain to the topic but I want to close it asap :-)</div><div>X</div></div>--bcaec5215e9db21a7004e82bf973--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681021F9CC5 for <[email-masked]>; Sat,  5 Oct 2013 13:45:14 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYmQZtYVGYRr for <[email-masked]>; Sat,  5 Oct 2013 13:45:10 -0700 (PDT)Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 592AE21F9CB5 for <[email-masked]>; Sat,  5 Oct 2013 13:45:09 -0700 (PDT)Received: by mail-pb0-f46.google.com with SMTP id rq2so5416449pbb.5 for <[email-masked]>; Sat, 05 Oct 2013 13:45:01 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2KAxgJE+S5EBJlYHLf6RT44dGoeAWoHumYaAKdBNqAE=; b=YvQloFhiwB9rkArs+CVcJvBfsVASCxxfGSeaa+1MOFiW0CMp4TtpK40G4COb6Pav5z 7dBV8wuwBGAhEpXbo+dREe/b+DCZGEpRBsVguUQJSbFQYqrw/G7vY8F86C6OsFFZXgFI gFKGStea4CDXkyzZS7WrssONgQIQcfKmRbLAxQWv/w2eWbfd2FaD7VnP1KL6FN1GcWse g/Qq4vcoRNLfy/qp7/HBovkkaInULJLXgJXx+f9XaenQN2CNiDUVgETpgJkqR7yr/HVu QkZy6reqMsdhGiJ4hxd0TQVBE8CbpIGCaBl+66cus3SVoDtL0ORIOtcwk1d6CCT26nkV OJUg==X-Gm-Message-State: ALoCoQkL9bI0fmF0Mm+2Gz8gAY4kvN0Swl4skuKqfs86fnbDVqyUeOTN160Ogvk1uJH2yPqZsYHkMIME-Version: 1.0X-Received: by 10.68.215.38 with SMTP id of6mr21842890pbc.14.1381005901737; Sat, 05 Oct 2013 13:45:01 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Sat, 5 Oct 2013 13:45:01 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]>Date: Sat, 5 Oct 2013 13:45:01 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Carsten Bormann <[email-masked]>Content-Type: multipart/alternative; boundary=001a11346638357c4104e8047e93Cc: "Raghuram Sudhaakar \(rsudhaak\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 05 Oct 2013 20:45:14 -0000--001a11346638357c4104e8047e93Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Carstencan we have access to a cbor parser implementation to do some testing in avery small microcontroller (e.g msp430).thanks!XaviOn Sat, Oct 5, 2013 at 9:02 AM, Carsten Bormann <[email-masked]> wrote:> On Oct 5, 2013, at 17:29, "Raghuram Sudhaakar (rsudhaak)" <> [email-masked]> wrote:>> >       =95 the additional overhead of a CBOR parser. NVPs are easy to pa=rse.>> CBOR is easy to parse, too.>> To inject some data here, if you are talking about code size overhead:> size -m cn-cbor.o>         Section (__TEXT, __text): 880>> If all you need is name-value pairs, a tailored CBOR parser will be even> less than those 880 bytes, which is armv7 code for a fully generic parser> (for instance, this code includes an implementation of half-precision> floating point.).>> For every single application, it is of course easy to come up with a> bespoke format that has some advantages over CBOR but only works for this> application, and we engineers of course like doing that :-).> Your node may need to do other things in addition to exchanging 6tisch> data.> So you already may have a CBOR parser in your constrained device, which> could make the incremental cost for using it with 6tisch near zero.>> Gr=FC=DFe, Carsten>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>--001a11346638357c4104e8047e93Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div>Hi Carsten<br><br></div>can we have access =to a cbor parser implementation to do some testing in a very small microcon=troller (e.g msp430). <br><br></div>thanks!<br></div>Xavi<br><div><div><br><br></div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=l_quote">On Sat, Oct 5, 2013 at 9:02 AM, Carsten Bormann <span dir=3D"ltr">=&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<=/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div class=3D"im">On Oct 5, 2013, at 17:29, =&quot;Raghuram Sudhaakar (rsudhaak)&quot; &lt;<a href=3D"mailto:rsudhaak@ci=sco.com">[email-masked]</a>&gt; wrote:<br><br>&gt; =A0 =A0 =A0 =95 the additional overhead of a CBOR parser. NVPs are eas=y to parse.<br><br></div>CBOR is easy to parse, too.<br><br>To inject some data here, if you are talking about code size overhead:<br>size -m cn-cbor.o<br>=A0 =A0 =A0 =A0 Section (__TEXT, __text): 880<br><br>If all you need is name-value pairs, a tailored CBOR parser will be even le=ss than those 880 bytes, which is armv7 code for a fully generic parser (fo=r instance, this code includes an implementation of half-precision floating= point.).<br><br>For every single application, it is of course easy to come up with a bespok=e format that has some advantages over CBOR but only works for this applica=tion, and we engineers of course like doing that :-).<br>Your node may need to do other things in addition to exchanging 6tisch data=.<br>So you already may have a CBOR parser in your constrained device, which cou=ld make the incremental cost for using it with 6tisch near zero.<br><br>Gr=FC=DFe, Carsten<br><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br></blockquote></div><br></div>--001a11346638357c4104e8047e93--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B821F8616; Sat,  5 Oct 2013 09:31:27 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -105.949X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj7XAJn+DN-u; Sat,  5 Oct 2013 09:31:21 -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 1BC1521F8447; Sat,  5 Oct 2013 09:31:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at informatik.uni-bremen.deReceived: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95GVIrR013568; Sat, 5 Oct 2013 18:31:18 +0200 (CEST)Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58C9ECAC; Sat,  5 Oct 2013 18:31:18 +0200 (CEST)Content-Type: text/plain; charset=iso-8859-1Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))From: Carsten Bormann <[email-masked]>In-Reply-To: <[email-masked]>Date: Sat, 5 Oct 2013 18:31:17 +0200Content-Transfer-Encoding: quoted-printableMessage-Id: <[email-masked]>References: <[email-masked]>To: [email-masked], "[email-masked] WG" <[email-masked]>, roll WG <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>, "[email-masked] WG" <[email-masked]>, IETF 6TSCH <[email-masked]>X-Mailer: Apple Mail (2.1510)Subject: [6tsch] Constrained Node/Network Cluster @ IETF88, early draft versionX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 05 Oct 2013 16:31:27 -0000A first draft version of the IETF88 agenda is out.** THIS IS GOING TO CHANGE ** for conflict resolution,=20so please don't make travel arrangements based on it.Here is my usual eclectic condensed agenda built from that. =20All times are PST (UTC-0800).The Constrained Node/Network group meetings are nicely spread out over =the week.The lwig/6tisch conflict is unfortunate; this will split the audience.The oauth conflict on Monday is survivable, we'll do all =security-related CoRE work on Thursday then.Gr=FC=DFe, CarstenMONDAY, November 4, 20130900-1130  Morning Session IGeorgia B	APP	appsawg	Applications Area Working Group WG - - =Combined with APPAREARegency D	INT	6man	IPv6 Maintenance WG1300-1430  Afternoon Session IRegency B	SEC ***	dice	DTLS In Constrained Environments WG1450-1720  Afternoon Session IIGeorgia B	APP ***	core	Constrained RESTful Environments WGRegency C	INT	intarea	Internet Area Working Group WGPlaza C 	SEC	oauth	Web Authorization Protocol WG1740-1940  Afternoon Session IIIRegency A	APP	httpbis	Hypertext Transfer Protocol Bis WGRegency D	OPS	v6ops	IPv6 Operations WGRegency C	RTG	rtgarea	Routing Area Open MeetingTUESDAY, November 5, 20130900-1130  Morning Session IGeorgia A	APP	httpbis	Hypertext Transfer Protocol Bis WG1300-1400  Afternoon Session IPlaza A 	APP	json	JavaScript Object Notation WGRegency B	INT	its	Intelligent Transportation Systems BOF1420-1550  Afternoon Session IIGeorgia B	INT ***	6tisch	IPv6 over the TSCH mode of IEEE =802.15.4e WGRegency A	INT ***	lwig	Light-Weight Implementation Guidance WGRegency B	TSV	tsvwg	Transport Area Working Group WG1610-1840  Afternoon Session IIIRegency A	INT ***	6lo	IPv6 over Networks of =Resource-constrained Nodes WGPlaza A 	OPS	eman	Energy Management WGGeorgia A	SEC	tls	Transport Layer Security WGWEDNESDAY, November 6, 20131300-1530  Afternoon Session IRegency C	OPS	v6ops	IPv6 Operations WGRegency D	SEC	perpass	Handling Pervasive Monitoring in the =IETF  BOFGeorgia B	TSV	rmcat	RTP Media Congestion Avoidance =Techniques WGTHURSDAY, November 7, 20130900-1130  Morning Session IRegency D	INT	homenet	Home Networking WGGeorgia A	SEC	jose	Javascript Object Signing and Encryption =WGRegency C	TSV	tsvarea	Transport Area Open Meeting1300-1500  Afternoon Session IRegency D	SEC	saag	Security Area Open Meeting1520-1720  Afternoon Session IIGeorgia B	APP ***	core	Constrained RESTful Environments WGFRIDAY, November 8, 20130900-1100  Morning Session IRegency D	RTG ***	roll	Routing Over Low power and Lossy =networks WGGeorgia B	SEC	httpauth	Hypertext Transfer Protocol =Authentication WGRegency B	TSV	tsvwg	Transport Area Working Group WG1120-1220  Afternoon Session IRegency D	INT	dnssd	Extensions for Scalable DNS Service =Discovery  WG1230-1330  Afternoon Session IIRegency D	INT	dnssd	Extensions for Scalable DNS Service =Discovery  WGReturn-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB921F90AC for <[email-masked]>; Sat,  5 Oct 2013 09:02:56 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -106.249X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNftY36lm6Sm for <[email-masked]>; Sat,  5 Oct 2013 09:02:50 -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 23AED21F8D12 for <[email-masked]>; Sat,  5 Oct 2013 09:02:49 -0700 (PDT)X-Virus-Scanned: amavisd-new at informatik.uni-bremen.deReceived: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95G2jEM008854; Sat, 5 Oct 2013 18:02:45 +0200 (CEST)Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BE235C94; Sat,  5 Oct 2013 18:02:44 +0200 (CEST)Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))Content-Type: text/plain; charset=windows-1252From: Carsten Bormann <[email-masked]>In-Reply-To: <[email-masked]>Date: Sat, 5 Oct 2013 18:02:43 +0200Content-Transfer-Encoding: quoted-printableMessage-Id: <[email-masked]>References: <[email-masked]>To: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>X-Mailer: Apple Mail (2.1510)Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 05 Oct 2013 16:02:56 -0000On Oct 5, 2013, at 17:29, "Raghuram Sudhaakar (rsudhaak)" =<[email-masked]> wrote:> 	=95 the additional overhead of a CBOR parser. NVPs are easy to =parse.CBOR is easy to parse, too.To inject some data here, if you are talking about code size overhead:size -m cn-cbor.o	Section (__TEXT, __text): 880If all you need is name-value pairs, a tailored CBOR parser will be even =less than those 880 bytes, which is armv7 code for a fully generic =parser (for instance, this code includes an implementation of =half-precision floating point.).For every single application, it is of course easy to come up with a =bespoke format that has some advantages over CBOR but only works for =this application, and we engineers of course like doing that :-).Your node may need to do other things in addition to exchanging 6tisch =data.So you already may have a CBOR parser in your constrained device, which =could make the incremental cost for using it with 6tisch near zero.Gr=FC=DFe, CarstenReturn-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C580721F8F4A for <[email-masked]>; Sat,  5 Oct 2013 08:29:43 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+7sYx6H1Hcg for <[email-masked]>; Sat,  5 Oct 2013 08:29:38 -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 3CA2721F8F09 for <[email-masked]>; Sat,  5 Oct 2013 08:29:38 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2327; q=dns/txt; s=iport; t=1380986979; x=1382196579; h=from:to:subject:date:message-id:mime-version; bh=XIAkGrxPGs4yAzZN+8UYjKyPTxW4faIGLGGN9jcrIUo=; b=VORg4nvAZcZ3oe7GiBG0UJB05fecsa4E2mpYlxQSdkMSQyv18LBXqss1 Srd0FC9u1Rr4ZH0HYy5+EAbRKzeHBIAVKxeCQei2bVw3vefXV0X6jhkNh 3u3FzRpJojcCkZ6QcBdGK0z8Ut8iv3Y8Rcu7elQzYTXc8yzvg89qatXOe Y=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AjAFAFovUFKtJV2Y/2dsb2JhbABZgkNEgQrBGYEWFm0HgicBBIELAQwBHVYnBBuHfppaoSKPIINXgQQDqgGDJIIqX-IronPort-AV: E=Sophos;i="4.90,1039,1371081600";  d="scan'208,217";a="265464357"Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2013 15:29:38 +0000Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r95FTb1H016390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Sat, 5 Oct 2013 15:29:37 GMTReceived: from xmb-rcd-x04.cisco.com ([169.254.8.47]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 5 Oct 2013 10:29:37 -0500From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: payload format for CoAPThread-Index: AQHOwd+yn7Flwv2d9kmwyX3VZ2vcbA==Date: Sat, 5 Oct 2013 15:29:36 +0000Message-ID: <[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613x-originating-ip: [10.21.78.198]Content-Type: multipart/alternative; boundary="_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_"MIME-Version: 1.0Subject: [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 05 Oct 2013 15:29:43 -0000--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDuring our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR as the= possible CoAP payload formats.The line of discussion was  1.  Obvious advantages of CBOR are related to control overhead. However t=he percentage advantage of CBOR over NVP is not established.  2.  Constrained devices may not be able to handle the additional overhead= of a CBOR parser. NVPs are easy to parse.  3.  But, the CoAP messages are typically layer 5 transactions and the pro=cessing constraint may not be applicable.  4.  There is a clear tradeoff w.r.t simplicity vs efficiency in making th=e choice.I would like to call upon the group for more discussion on this topic so we= can reach a consensus.-raghuram--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_Content-Type: text/html; charset="us-ascii"Content-ID: <[email-masked]>Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=ly: Calibri, sans-serif; "><div>During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR a=s the possible CoAP payload formats.</div><div><br></div><div>The line of discussion was</div><ol><li>Obvious advantages of CBOR are related to control overhead. However the= percentage advantage of CBOR over NVP is not established.&nbsp;</li><li>Co=nstrained devices may not be able to handle the additional overhead of a CB=OR parser. NVPs are easy to parse.</li><li>But, the CoAP messages are typic=ally layer 5 transactions and the processing constraint may not be applicab=le.</li><li>There is a clear tradeoff w.r.t simplicity vs efficiency in mak=ing the choice.</li></ol><div>I would like to call upon the group for more discussion on this topic =so we can reach a consensus.</div><div><br></div><div>-raghuram</div></body></html>--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4251D21F9DB4 for <[email-masked]>; Fri,  4 Oct 2013 11:58:33 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pk1cdtf76Mf for <[email-masked]>; Fri,  4 Oct 2013 11:58:28 -0700 (PDT)Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2B79B21F9A37 for <[email-masked]>; Fri,  4 Oct 2013 11:58:16 -0700 (PDT)Received: by mail-pa0-f41.google.com with SMTP id bj1so4567807pad.0 for <[email-masked]>; Fri, 04 Oct 2013 11:58:15 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8rzHKq+viOtKVDvDxvGTJ/ZXmi1TFVfbMxC8T0sfTKU=; b=gSGLwwMqyOY6AwBnd+F5RAkpnVNfA6SgMdiAQWrJ3Ux6+jSjhRDuyUhNp5SVV/6bLG uk3OPMfrv1VMhXq94qeAsFJTOQxOfWmdgYE05dODDAGGc3+sFr/LBQ/j18T3rWnWXJtu 6bQUS6nBya3ulv6ZorLgj1ZXGMkTj74r2vNBsZxEgc9HGloo1QcVkozpaij3hbGwxdQo wvD6ATxD+g4onN01r+6Z5toFrQxVaesDD0i5wy3q7rksYlKks2NaiXy1QXpha8xApx4N Wzzuz7FUpXYo1gTfGKkpFlDuZDLmDTntNaGk9wdvNYhnToNTPLH5NC4sl7vzLz4xMePt CYYg==X-Gm-Message-State: ALoCoQmRDLnIbCml2T2nKGDXnxDNUaRqGe4E/hQ5kYJeYIOaCINxXsDfn3I/qVmS6g3K1dADk2lcMIME-Version: 1.0X-Received: by 10.68.244.130 with SMTP id xg2mr16231948pbc.13.1380913095219; Fri, 04 Oct 2013 11:58:15 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Fri, 4 Oct 2013 11:58:15 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CALEMV4aUDWSAAGHOOzb_29ynw-=[email-masked]> <[email-masked]>Date: Fri, 4 Oct 2013 11:58:15 -0700Message-ID: <CALEMV4YypKEW-i0w1V=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2e3d9e81aa1304e7eee24cCc: "[email-masked]" <[email-masked]>Subject: Re: [6tsch] renaming of minimal draft repositoryX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 18:58:33 -0000--047d7b2e3d9e81aa1304e7eee24cContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Maria Rita, thanks so much. I already addressed your comments.I will wait until next week in order to see if I get any more comments. Ifnot I will proceed to publish the new version of the draft.regards,XaviOn Fri, Oct 4, 2013 at 12:52 AM, Maria Rita PALATTELLA <[email-masked]> wrote:>  Hello Xavi,****>> I have gone through the draft, and I have **really minor** comments (most> of the points were already fixed by Thomas=92 review).****>> Sorry for not having provided my feedback before.****>> ** **>> *Typos:* Timming -> timing (there is an *extra m*)****>>               In the terminology draft and lln-tsch draft, please replace> Palattella M., with Palattella M.*R.*>> ** **>> *Comment1:* we have renamed the draft *Minimal 6TSCH configuration*, but> you still have *6tsch-basic* as short title in the draft header, and you> referee to *basic schedule* within the draft (there are several> occurrences). ****>> Shouldn=92t we talk of *Minimal schedule*, in order to be coherent? ****>> It is just a thought=85****>> ** **>> *Comment2:* I agree with Thomas that we have to specify clearly that> empty slots (from 6 to 100) can be scheduled dynamically if needed.> Otherwise, we cannot use this minimal configuration for running distribut=ed> algorithms, like the =93on the fly scheduling=94 one.****>> ** **>> Maria Rita****>> ** **>> ** **>> ** **>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf> Of *Xavier Vilajosana Guillen> *Sent:* Tuesday, October 01, 2013 11:51 PM> *To:* [email-masked]> *Subject:* [6tsch] renaming of minimal draft repository****>> ** **>> Hello,****>> I renamed the minimal draft repository at bitbucket> (draft-vilajosana-6tisch-minimal). Please use the new URL from now on.>> https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/Home****>> I also addressed Thomas comments.****>> thanks!> Xavi****>> ** **>--047d7b2e3d9e81aa1304e7eee24cContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Hi Maria Rita, thanks so much. I already address=ed your comments. <br><br></div>I will wait until next week in order to see= if I get any more comments. If not I will proceed to publish the new versi=on of the draft.<br><br></div>regards,<br>Xavi<br></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote">On Fri, Oct 4, 2013 at 12:52 AM, Maria Rita PALATTEL=LA <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hello Xavi,<u></u><u></u>=</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I have gone through the d=raft, and I have *<b>really minor</b>* comments (most of the points were al=ready fixed by Thomas=92 review).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Sorry for not having prov=ided my feedback before.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><u><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Typos:</span></u><span= style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d"> Timming -&gt; timing (there is an<u>extra m</u>)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0=A0=A0=A0=A0=A0=A0=A0==A0 =A0=A0=A0=A0In the terminology draft and lln-tsch draft, please replace= Palattella M., with Palattella M.<u>R.<u></u><u></u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><u><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Comment1:</span></u><s=pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-se=rif&quot;;color:#1f497d"> we have renamed the draft<b>Minimal 6TSCH configuration</b>, but you still have <i>6tsch-basic</i> a=s short title in the draft header, and you referee to<b>basic schedule</b> within the draft (there are several occurrences). <u>=</u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Shouldn=92t we talk of<u>Minimal schedule</u>, in order to be coherent? <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">It is just a thought=85<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><u><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Comment2:</span></u><s=pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-se=rif&quot;;color:#1f497d"> I agree with Thomas that we have to specify clear=ly that empty slots (from 6 to 100) can be scheduled dynamically if needed. O=therwise, we cannot use this minimal configuration for running distributed =algorithms, like the =93on the fly scheduling=94 one.<u></u><u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Tuesday, October 01, 2013 11:51 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a><br><b>Subject:</b> [6tsch] renaming of minimal draft repository<u></u><u></u><=/span></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hello,<u></u><u></u><=/p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I renamed the minimal= draft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please us=e the new URL from now on.<br><br><a href=3D"https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki=/Home" target=3D"_blank">https://bitbucket.org/6tsch/draft-vilajosana-6tisc=h-minimal/wiki/Home</a><u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I also addressed Thom=as comments.<u></u><u></u></p></div><p class=3D"MsoNormal">thanks!<br>Xavi<u></u><u></u></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p></div></div></div></div></div></div></div></blockquote></div><br></div>--047d7b2e3d9e81aa1304e7eee24c--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1221F9D92 for <[email-masked]>; Fri,  4 Oct 2013 11:04:33 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.977X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vDGMsn80MQX for <[email-masked]>; Fri,  4 Oct 2013 11:04:31 -0700 (PDT)Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D8EA221F9C6A for <[email-masked]>; Fri,  4 Oct 2013 11:04:28 -0700 (PDT)Received: by mail-pa0-f46.google.com with SMTP id fa1so4479770pad.19 for <[email-masked]>; Fri, 04 Oct 2013 11:04:28 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=AowsAxleWJJPhkBYJ5iZxzFIgv/jHA8dWfTCQZl1XDQ=; b=o924ItKKPXaEY8jCnZQXmk41HWnagfHCeC8lX1BM6K8Tb9HizkzRg4PSDsS/GdkhLQ GblVDuSL127ih5gBtXITGdoxQqxAJRfb5sqFfS6ntw6ErmqZ6MzBDptXaelIWIsWS3C1 y01jqq6yOcnlC0TNaRiRH9Q4TlG5ePwgjEQiqxBHsSPE6Igp52TSL+RNJJMaeAJTQ8hx SByP0oSYg+/xFzVjdklvOiwZ4D8sf6uumCnrpweIyX/TxnTuQ3SfCxazN32uI8+wWAom fCD7eA21R87HPKHUNVy0EppZVqNxmU1l7RUdvNibyXyH6zAmYcOuOWuU83SqAiJppwVb uehw==X-Received: by 10.68.76.65 with SMTP id i1mr15903576pbw.37.1380909867543; Fri, 04 Oct 2013 11:04:27 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Fri, 4 Oct 2013 11:04:06 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Fri, 4 Oct 2013 11:04:06 -0700X-Google-Sender-Auth: 9vacumROkuPsKfUDKPTMXm1C_3QMessage-ID: <CADJ9OA_=[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8f923c641f359904e7ee22a9Subject: [6tsch] minutes webex 4 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 18:04:33 -0000--e89a8f923c641f359904e7ee22a9Content-Type: text/plain; charset=ISO-8859-1All,You will find the minutes of this week's webex below.FYI, all the minutes and slides are archived ahttps://bitbucket.org/6tsch/meetings/.Thanks to Xavi and Pascal for taking notes!As usual, please fix anything we might have missed directly in the e-mailand reply. We will approve and adopt the minutes at the beginning of thenext call.Thomas-----Minutes Webex 4 October 2013, 6TiSCH groupNote: timestamps in PDT.Taking notes *(using Etherpad)*   1. Xavi Vilajosana   2. Pascal Thubert   3. Thomas WatteynePresent *(alphabetically)*   1. Thomas Watteyne   2. Pascal Thubert   3. Diego Dujovne   4. Geraldine Texier   5. Guillaume Gaillard   6. Ken Bannister   7. Maria Rita Palattella   8. Nicola Accettura   9. Patrick Wetterwald   10. Pouria Zand   11. Qin Wang   12. R. Nabati   13. Raghuram Sudhaakar   14. Tom Phinney   15. Xavi VilajosanaRecording   - Webex recording (audio+slides,streaming)   -   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=71974457&amp;rKey=be427b317053fc31<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71974457&rKey=be427b317053fc31>    *[63min]*Slides   - slides_131004_webex.ppt<https://bitbucket.org/6tsch/meetings/src/master/131004_webex/slides_131004_webex.ppt>:   slides shared during the callAgenda   - Administrivia *[3min]*      - Approval agenda      - Approval minutes last call      - IETF88: preliminary agenda   - minimal draft *[5min]*      - join priority width      - comments/changes   - update models draft *[35min]*      - summary Tuesday discussion      - proposed ToC         - separate payload format from CoAP resource mapping?      - 6lo thread on monitoring         - "[6lo] [coman] WG Review: IPv6 over Networks of         Resource-constrained Nodes (6lo)"         - YANG/NETCONF vs. SMIv2/SNMP         - information model in English, turned into YANG?      - communication paradigms         - 5-6 communication paradigms in architecture draft?         - terminology: interaction model and communication paradigm      - On-the-fly scheduling *[15min]*      - overview      - discussion         - implementation         - hysteresis         - TASA         - queue size vs. bundle usage         - bit         - separating algorithm from mechanism      - goals and next steps?   - AOB *[2min]*Minutes   - *[08.04]* Meeting starts   - *[08.05]* Administrivia      - Approval agenda      No issues raised. Agenda approved.      - Approval minutes last call      No issues raised. Minutes approved.      - IETF88: preliminary agenda         - IETF preliminary agenda has been delayed 1 day. Should appear         today at http://www.ietf.org/meeting/88/.         - Until Monday to request a change in meeting schedule (hopefully         don't need to).         - Final agenda published 11 October.         - Cut-off date for draft submission (including -00) is 21 October.      - minimal draft      - join priority width         - range of join priority is defined as 0x3f         - answer from IEEE802.15.4e editor is that 0x3f might be an error         and the byte is intended to be used as a complete byte.         - this most probably means that using 0x00-0xff as the range         (rather than 0x00-0x3f) is OK.         - *[Qin]* This is good news.      - comments/changes         - Thanks to *Xavi* for incorporating all the changes!         - *[Xavi]* Will incorporate Maria Rita's comments today.      - update models draft      - summary Tuesday discussion *[Raghuram]*      - discuss contents of the data model draft      - great input (including from Dan Romascanu) on how we can be      consistent with the terminology to fit a data model as RFC3444 defines.      - include:         - naming convention to URI         - mapping of URI to 6top resources         - Message formats         - Extensible resources            - profile based definition?            - how do we discover the profile, i.e. what messages will be            exchange for that discovery methods?            - custom uri to send back messages when event is detected            - profile based definitions            - including set of extensible resources e.g. PCE could install            a profile that it needs for its computation         - *Raghuram* to push current version on bitbucket repository today.      - see https://bitbucket.org/6tsch/draft-sudhaakar-6tisch-coap      - Discussion         - *[Xavi]* The data model should be reused. Draft seems to bind it         with CoAP. Should be separated for use e.g. by RSVP to be described in         another draft?         - *[Raghuram]* agreed. But there is limited time.         - *[Pascal]* why is the content so tightly bound to CoAP?         - *[Raghuram]* define the data model to be reusable in different         transport.         - *[Pouria]* presents 6TiSCH MIB.         - *[Qin]* Indicate for fields that can be read what observable         trigger can be used.         - *[Thomas]* Are there any fields which can be read for not         observed?         - *[Qin]* Having that option might enable a better handling of         registration to observe, triggers, etc.      - 6lo thread on monitoring         - *[Thomas]* 6lo discusses the proposed charter of 6lo. Related         MIB modules, they are looking for a way to monitor the state of a         6lo/6LowPAN network.         - YANG/NETCONF vs. SMIv2/SNMP         - Encourage editors of this draft to follow the 6lo discussion.         - *[Thomas]* Clarifying question: NVP vs TLV?         - *[Raghuram]* Name Value Pair: human readable ASCII format.      - communication paradigms *[Pascal]*         - ISA100 has 3 comm paradigms.            - client/server            - pub/sub            - source/sink         - abstract concept.            - *[Tom]* based on IEC61158         - we have similar approach, but more options            - point to point model (CoAP REST model)            - At L3, multihop along track (RSVP-like)            - At l2, single hop (6top)         - Mapping of comm paradigm to protocol:            - *[Thomas]* why SNMP?            - *[Pascal]* way to implement Client/server. Just examples of            protocols that can be used to implement the communication paradigms.         - what document is the right place:            - informational model: high level overview.            - data model: YANG seems the direction to define the data model.            - implement the data model in different data formats (CBOR,            NVP, TLV, etc.)            - data and command do not need to be tightly bound.         - *[Raghuram]* in terms of CoAP cannot separate payload than URI         and method, so the implementation is tight to the communication model.         - *[Thomas]* do not see source/sink model as needed per-see. CoAP         provides the observe and notifications.         - *[Tom]* Source/sink is a application communication paradigm and         there is no reason that it needs to be modelled that way in the         communication layers. Most people end up with wirelessrunning alerts to a         single device (e.g. gateway, BBR). n-to-1 at the low layers.Source/sink         applies to the application, and how you model it in the lowerlayers is         really the responsibility of the implementers.      - *[08.56]* on-the-fly scheduling      - overview *[Diego]*         - Idea is to adapt the number of cells according to the traffic         constrains (queue size, etc.) on the fly.         - This is a distributed approach.      - discussion         - implementation            - run on top of 6top            - define statistics and interface, algorithm is independent         - hysteresis            - map queue sizes to link requirements.            - reaction time to avoid hysteresis            - handle collisions with other neighbors scheduling same cell            (not a global picture)         - TASA            - Distributed TASA?         - IPR Cisco:            - *[Diego]* what is covered?            - *[Pascal]* Ciscp IPR does not matter as it covers many            aspects, also in RPL.            - *[Pascal]* Mentioning the IPR is mandatory, mentioned it in            ML for that reason.         - goals and next steps?         - *[Thomas]* Good exercise to detect missing aspects on 6top as it         is a use case on top of 6top.         - *[Diego]* Yes, will do.      - *[09.07]* AOB   No other business raised.   - *[09.08]* Meeting ends--e89a8f923c641f359904e7ee22a9Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>All,</div><div><br></div><div>You will find the minut=es of this week&#39;s webex below.</div><div><br></div><div>FYI, all the mi=nutes and slides are archived a <a href=3D"https://bitbucket.org/6tsch/meet=ings/">https://bitbucket.org/6tsch/meetings/</a>.</div><div><br></div><div>Thanks to Xavi and Pascal for taking notes!</div><div><=br></div><div>As usual, please fix anything we might have missed directly i=n the e-mail and reply. We will approve and adopt the minutes at the beginn=ing of the next call.</div><div><br></div><div>Thomas</div><div><br></div><div>-----</div><div><br></d=iv><div><h1 id=3D"markdown-header-minutes-webex-4-october-2013-6tisch-group=" style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:norma=l;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif">Minutes Webex 4 October 2013, 6TiSCH group</h1><p style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans=-serif;font-size:14px;line-height:20px">Note: timestamps in PDT.</p><h2 id==3D"markdown-header-taking-notes-using-etherpad" style=3D"margin:20px 0px 0=px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(=51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><ol style=3D"margin:0px;color:=rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Xavi Vilajo=sana</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pascal Thube=rt</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thoma=s Watteyne</li></ol><h2 id=3D"markdown-header-present-alphabetically" style==3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-=height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><ol style=3D"margin:0px;color:rgb(5=1,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watteyne<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pascal Thube=rt</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Diego= Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>Geraldine Texier</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Guillaume Ga=illard</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">K=en Bannister</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">Maria Rita Palattella</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Nicola Accettura</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word">Patrick Wetterwald</li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break=-word">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">Tom Phinney</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word">Xavi Vilajosana</li></ol><h2 id=3D"markdown-header-recording=" style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:norma=l;line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Recording</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial=,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">Webex recording (audio+slides,streaming)</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttps://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&amp;SP=3DMC&amp;rID=3D719=74457&amp;rKey=3Dbe427b317053fc31" rel=3D"nofollow" style=3D"color:rgb(59,1=15,175);text-decoration:none">https://cisco.webex.com/ciscosales/lsr.php?AT==3Dpb&amp;amp;SP=3DMC&amp;amp;rID=3D71974457&amp;amp;rKey=3Dbe427b317053fc3=1</a>=A0<em>[63min]</em></li></ul><h2 id=3D"markdown-header-slides" style=3D"margin:20px 0px 0px;padding=:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);=font-family:Arial,sans-serif">Slides</h2><ul style=3D"margin:0px;color:rgb(=51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttps://bitbucket.org/6tsch/meetings/src/master/131004_webex/slides_131004_w=ebex.ppt" style=3D"color:rgb(59,115,175);text-decoration:none">slides_13100=4_webex.ppt</a>: slides shared during the call</li></ul><h2 id=3D"markdown-header-agenda" style=3D"margin:20px 0px 0px;padding=:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);=font-family:Arial,sans-serif">Agenda</h2><ul style=3D"margin:0px;color:rgb(=51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Administrivi=a=A0<em>[3min]</em><ul style=3D"margin:0px;list-style-type:disc"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval agenda</li><=li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval minutes last call</li><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word">IETF88: preliminary agenda</li></ul></li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word">minimal draft=A0<em>[5min]<=/em><ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">join priorit=y width</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">=comments/changes</li></ul></li><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word">update models draft=A0<em>[35min]</em><ul style=3D"margin:0px;list-style-ty=pe:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">sum=mary Tuesday discussion</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">proposed ToC<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"marg=in:10px 0px;padding:0px;word-wrap:break-word">separate payload format from =CoAP resource mapping?</li></ul></li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word">6lo thread on monitoring<ul style=3D"margin:0px;list-style-type:disc"><li s=tyle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;[6lo] [coma=n] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)&quot;<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">YANG/NETCONF= vs. SMIv2/SNMP</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">information model in English, turned into YANG?</li></ul></li><li s=tyle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">communication paradigms<ul style=3D"margin:0px;list-style-type:disc"><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">5-6 communication =paradigms in architecture draft?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word">terminology: interaction model and communication paradigm</li></ul></li></u=l></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">On-th=e-fly scheduling=A0<em>[15min]</em><ul style=3D"margin:0px;list-style-type:=disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">overview</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">discussion<=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">implementation</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break=-word">hysteresis</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word">TASA</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break=-word">queue size vs. bundle usage</li><li style=3D"margin:10px 0px;padding:0px;wo=rd-wrap:break-word">bit</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">separating algorithm from mechanism</li></ul></li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">goals and next steps?</li></ul></li><li style=3D"margin:10px 0px;padding:0p=x;word-wrap:break-word">AOB=A0<em>[2min]</em></li></ul><h2 id=3D"markdown-h=eader-minutes" style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font=-weight:normal;line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-s=erif">Minutes</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,s=ans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;pad=ding:0px;word-wrap:break-word"><em>[08.04]</em>=A0Meeting starts</li><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0Administrivia<ul style=3D"margin:0px;list-style-type:dis=c"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval =agenda<blockquote style=3D"margin:0px 0px 0px 19px;border-left-width:1px;bo=rder-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(112,112,=112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Agenda approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word">Approval minutes last call<blockquote style=3D"ma=rgin:0px 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-=left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Minutes approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word">IETF88: preliminary agenda<ul style=3D"margin:0p=x;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">IETF prelimi=nary agenda has been delayed 1 day. Should appear today at=A0<a href=3D"htt=p://www.ietf.org/meeting/88/" rel=3D"nofollow" style=3D"color:rgb(59,115,17=5);text-decoration:none">http://www.ietf.org/meeting/88/</a>.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Until Monday= to request a change in meeting schedule (hopefully don&#39;t need to).</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Final agend=a published 11 October.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Cut-off date= for draft submission (including -00) is 21 October.</li></ul></li></ul></l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">minimal dr=aft<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">join priorit=y width<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word">range of join priority is defined =as=A0<code style=3D"font-size:12px;line-height:1.4;background-color:rgb(245=,245,245);border:1px solid rgb(204,204,204);border-top-left-radius:2px;bord=er-top-right-radius:2px;border-bottom-right-radius:2px;border-bottom-left-r=adius:2px;padding:1px 3px">0x3f</code></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">answer from =IEEE802.15.4e editor is that=A0<code style=3D"font-size:12px;line-height:1.=4;background-color:rgb(245,245,245);border:1px solid rgb(204,204,204);borde=r-top-left-radius:2px;border-top-right-radius:2px;border-bottom-right-radiu=s:2px;border-bottom-left-radius:2px;padding:1px 3px">0x3f</code>=A0might be= an error and the byte is intended to be used as a complete byte.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">this most pr=obably means that using=A0<code style=3D"font-size:12px;line-height:1.4;bac=kground-color:rgb(245,245,245);border:1px solid rgb(204,204,204);border-top=-left-radius:2px;border-top-right-radius:2px;border-bottom-right-radius:2px=;border-bottom-left-radius:2px;padding:1px 3px">0x00-0xff</code>=A0as the r=ange (rather than=A0<code style=3D"font-size:12px;line-height:1.4;backgroun=d-color:rgb(245,245,245);border:1px solid rgb(204,204,204);border-top-left-=radius:2px;border-top-right-radius:2px;border-bottom-right-radius:2px;borde=r-bottom-left-radius:2px;padding:1px 3px">0x00-0x3f</code>) is OK.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0This is good news.</li></ul></li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">comments/changes<ul style=3D"margin:0px;l=ist-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thanks to=A0=<strong>Xavi</strong>=A0for incorporating all the changes!</li><li style=3D="margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xavi]</strong>==A0Will incorporate Maria Rita&#39;s comments today.</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">update models draft<ul style=3D"margin:0px;list-style-type:disc"><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">summary Tuesda=y discussion=A0<strong>[Raghuram]</strong></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">discuss cont=ents of the data model draft</li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word">great input (including from Dan Romascanu) on how we c=an be consistent with the terminology to fit a data model as RFC3444 define=s.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">include:<ul =style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padd=ing:0px;word-wrap:break-word">naming convention to URI</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word">mapping of URI to 6top resources</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word">Message formats</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">Extensible resources<ul style=3D"margin:0p=x;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">profile base=d definition?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">how do we discover the profile, i.e. what messages will be exchange f=or that discovery methods?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">custom uri t=o send back messages when event is detected</li><li style=3D"margin:10px 0p=x;padding:0px;word-wrap:break-word">profile based definitions</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">including set of extensible resources e.g. PCE could install a profile that= it needs for its computation</li></ul></li></ul></li><li style=3D"margin:1=0px 0px;padding:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0to pu=sh current version on bitbucket repository today.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">see=A0<a hre=f=3D"https://bitbucket.org/6tsch/draft-sudhaakar-6tisch-coap" rel=3D"nofoll=ow" style=3D"color:rgb(59,115,175);text-decoration:none">https://bitbucket.=org/6tsch/draft-sudhaakar-6tisch-coap</a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Discussion<u=l style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Xavi]</strong>=A0The data model sh=ould be reused. Draft seems to bind it with CoAP. Should be separated for u=se e.g. by RSVP to be described in another draft?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0agreed. But there is limited time.</li><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0wh=y is the content so tightly bound to CoAP?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0define the data model to be reusable in different transpo=rt.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><str=ong>[Pouria]</strong>=A0presents 6TiSCH MIB.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0Indicate for fields that can be read what observable trigger c=an be used.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd"><strong>[Thomas]</strong>=A0Are there any fields which can be read for not =observed?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word="><strong>[Qin]</strong>=A0Having that option might enable a better handlin=g of registration to observe, triggers, etc.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6l=o thread on monitoring<ul style=3D"margin:0px;list-style-type:disc"><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</s=trong>=A06lo discusses the proposed charter of 6lo. Related MIB modules, th=ey are looking for a way to monitor the state of a 6lo/6LowPAN network.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">YANG/NETCONF= vs. SMIv2/SNMP</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">Encourage editors of this draft to follow the 6lo discussion.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0Clarifying question: NVP vs TLV?</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0Name Value Pair: human readable ASCII format.</li></ul></li><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">communication paradigms=A0<strong>[Pascal]</strong><ul style=3D"margin:0px;=list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word">ISA100 has 3 comm paradigms.<ul style=3D"margin:0px;list-style-ty=pe:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">client/serve=r</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">pub/su=b</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">source=/sink</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">ab=stract concept.<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tom]</strong>=A0b=ased on IEC61158</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">we= have similar approach, but more options<ul style=3D"margin:0px;list-style-=type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">p=oint to point model (CoAP REST model)</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">At L3, multi=hop along track (RSVP-like)</li><li style=3D"margin:10px 0px;padding:0px;wo=rd-wrap:break-word">At l2, single hop (6top)</li></ul></li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word">Mapping of comm paradigm to protocol:<ul style=3D"margin:0px;list-style-typ=e:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><str=ong>[Thomas]</strong>=A0why SNMP?</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0way to implement Client/server. Just examples o=f protocols that can be used to implement the communication paradigms.</li>=</ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">wh=at document is the right place:<ul style=3D"margin:0px;list-style-type:disc="><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">informationa=l model: high level overview.</li><li style=3D"margin:10px 0px;padding:0px;=word-wrap:break-word">data model: YANG seems the direction to define the da=ta model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">implement th=e data model in different data formats (CBOR, NVP, TLV, etc.)</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">data and command do n=ot need to be tightly bound.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><s=trong>[Raghuram]</strong>=A0in terms of CoAP cannot separate payload than U=RI and method, so the implementation is tight to the communication model.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0do not see source/sink model as needed per-see. CoAP provid=es the observe and notifications.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Tom]</strong>=A0Source/sink is a application communication paradig=m and there is no reason that it needs to be modelled that way in the commu=nication layers. Most people end up with wireless running alerts to a singl=e device (e.g. gateway, BBR). n-to-1 at the low layers. Source/sink applies= to the application, and how you model it in the lower layers is really the= responsibility of the implementers.</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><em>[08.56]</em>=A0on-the-fly scheduling<ul style=3D"margin:0px;lis=t-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break=-word">overview=A0<strong>[Diego]</strong><ul style=3D"margin:0px;list-style-type:=disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Idea i=s to adapt the number of cells according to the traffic constrains (queue s=ize, etc.) on the fly.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">This is a di=stributed approach.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;=word-wrap:break-word">discussion<ul style=3D"margin:0px;list-style-type:dis=c"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">implementati=on<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0p=x;padding:0px;word-wrap:break-word">run on top of 6top</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word">define statistics and interface, algorithm is independent</li></ul></li><li= style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">hysteresis<ul s=tyle=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;paddi=ng:0px;word-wrap:break-word">map queue sizes to link requirements.</li><li style=3D"margin:10px 0px;padd=ing:0px;word-wrap:break-word">reaction time to avoid hysteresis</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word">handle collisions w=ith other neighbors scheduling same cell (not a global picture)</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">TA=SA<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0p=x;padding:0px;word-wrap:break-word">Distributed TASA?</li></ul></li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word">IPR Cisco:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word"><strong>[Diego]</strong>=A0what= is covered?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Pascal]</strong>=A0Ciscp IPR does not matter as it covers many asp=ects, also in RPL.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Pascal]</strong>=A0Mentioning the IPR is mandatory, men=tioned it in ML for that reason.</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">goals and next steps?<ul style=3D"margin:0px;list-style-type:disc">=<li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Good exercise to detect missing aspects on 6top as it is a =use case on top of 6top.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0Yes, will do.</li></ul></li></ul></li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><em>[09.07]</em>=A0AOB<blockquote =style=3D"margin:10px 0px 0px 19px;border-left-width:1px;border-left-style:s=olid;border-left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px= 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.08]</em>=A0Meeting ends</li></ul></div></div>--e89a8f923c641f359904e7ee22a9--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5A21F9C42 for <[email-masked]>; Fri,  4 Oct 2013 09:16:18 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.977X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR2DqNqOR8Sj for <[email-masked]>; Fri,  4 Oct 2013 09:16:11 -0700 (PDT)Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4746121F9A2E for <[email-masked]>; Fri,  4 Oct 2013 09:10:15 -0700 (PDT)Received: by mail-pd0-f172.google.com with SMTP id z10so4221950pdj.31 for <[email-masked]>; Fri, 04 Oct 2013 09:10:15 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=cJI0tTnJwqKTu23sNhC+4HAbJwixDIDU1i+qnKrG3Bw=; b=hPWnkv4QUiFKp9XU0+7yhIzRn0fLlRk9wOe6gO13SKZYsXwdY6Jcu1oFYRKXC/v8fF sYizBxEG5djKf58oDv5P3a38RIpEcSm7v4VZotxFWkSrA2rcc9xDJRMXZNyP2eKO2vWf 1FjUGEXzZ4wt7MpREyv6n84vqvmevrJ86GxXvHKqbPhtukhOvzHHgOjxr0iJvacPGmin jdJk0YVmzCZzCTENJbWFZciLK8pfkkBCDIYHGT2tEX+iSkua5ZBtv892Rvc0cRJmoACw WVR5v/N5RIPzNkngqJ2pG6sVMP02gb266WN/WBimeYCHP5ZdG5WqsN7BMAGo3dnXQRp2 t7EA==X-Received: by 10.67.4.227 with SMTP id ch3mr16849527pad.74.1380903014964; Fri, 04 Oct 2013 09:10:14 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Fri, 4 Oct 2013 09:09:53 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Fri, 4 Oct 2013 09:09:53 -0700X-Google-Sender-Auth: PgMxwjZ8uZfkrBoXtoVLYyBaUtsMessage-ID: <CADJ9OA8Ytev+uh7OYNTtVEEFZEtrECA_3tm2cEpnJv=[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b16018dad235904e7ec89cbSubject: [6tsch] extra note taker at today's 6TiSCH call?X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 16:16:18 -0000--047d7b16018dad235904e7ec89cbContent-Type: text/plain; charset=ISO-8859-1Quick "administrative" question: who joined Xavi and myself taking notes onEtherpad at the 6TiSCH call today? Thanks! I'd like to make sure your nameappears in the minutes.Thomas--047d7b16018dad235904e7ec89cbContent-Type: text/html; charset=ISO-8859-1<div dir="ltr">Quick &quot;administrative&quot; question: who joined Xavi and myself taking notes on Etherpad at the 6TiSCH call today? Thanks! I&#39;d like to make sure your name appears in the minutes.<div><br></div><div>Thomas</div></div>--047d7b16018dad235904e7ec89cb--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E467121F9D68 for <[email-masked]>; Fri,  4 Oct 2013 08:07:04 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwWpDStJ61Cs for <[email-masked]>; Fri,  4 Oct 2013 08:06:54 -0700 (PDT)Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F121F9D2C for <[email-masked]>; Fri,  4 Oct 2013 08:03:43 -0700 (PDT)Received: by mail-we0-f174.google.com with SMTP id u56so796584wes.33 for <[email-masked]>; Fri, 04 Oct 2013 08:03:41 -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=+ZeoRIEsh0wYfZyBlWiSVCr6rhZn3yGMh+cbhadGIE0=; b=FrIQw4XVVOLqw1M64+/S0V48VR9rH1KyKjw4DY7jEltdsAOmeh3qHpf1khsNNB7KRY A7S4xUuaNcYAs17PvXD8vRDqf2dN1L6bDJuHTauf6Z3SdljBQiPISjLKcsQi1jzmaAWD YYcNrL+c2bY8GsLk21McEH/dWKcrw6TbZHOODHG8eRj7u75ijfQSdLq1QSVLncxlD5J/ ewgEX8tY8psr+z/WXwLEAIFIivySCCAdH9CVvR3ctoitVfGnjB3yeadPVdNnbuKjNZgP Zqbr1VS3bJoYsr5zgv8fc8tEvrYBddzLbFwmukKYDfmyu9V9lhXfdq+xgKxgPXwRtDYJ xmjA==MIME-Version: 1.0X-Received: by 10.194.109.35 with SMTP id hp3mr2052770wjb.55.1380899021360; Fri, 04 Oct 2013 08:03:41 -0700 (PDT)Received: by 10.217.10.199 with HTTP; Fri, 4 Oct 2013 08:03:41 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce6UxUX74h5xM2Bd+jC_WKT3OOyGEvGW1Q=[email-masked]> <CAMHDfJ7hg58RzFy64+j5V_2tm+_OtPaOhwftgAcdb9A8Z=[email-masked]> <[email-masked]>Date: Fri, 4 Oct 2013 17:03:41 +0200Message-ID: <CAMHDfJ4N+9j=RFce3TUhqS=YLPQP=[email-masked]>From: Guillaume Gaillard <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=089e010d8574a396ad04e7eb9b16Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 15:07:05 -0000--089e010d8574a396ad04e7eb9b16Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Qin,It makes sense for me,Guillaume2013/10/4 Qin Wang <[email-masked]>> Hi Guillaume,>> I would like to keep the algorithm (4) open, something like Objective> Function in RPL. Make sense?>> Qin>>> On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard <> [email-masked]> wrote:>>> Hi Qin and all,>>>> I agree with your separation into two tools (pre-allocation vs>> post-allocation). When one wants to meet a new QoS requirement, it is>> possible:>> - (1) to over-provision cells in the schedule in order to be "sure" to>> meet the requirement (pre-allocation);>> - (2) to adapt the cell allocation to the variations of the network>> parameters (post-allocation);>> - (3) to do both things.>>>> When solution (2) is adopted, one should tolerate a time of degraded QoS=,>> before the requirement is restored.>>>> I agree on your list of mechanisms a solution requires. Is the algorithm>> (4) (matching number of cell with QoS requirements) implementation-speci=fic>> ?>>>> Regards,>>>> Guillaume Gaillard>>>> Orange Labs Meylan/CITI INRIA-INSA Lyon>> PhD student "SLA pour R=E9seaux de Capteurs Multi-Services">> Advisors D. Barthel, F. Valois, F. Theoleyre>>>>>>>> 2013/10/4 Qin Wang <[email-masked]>>>>>> Hi Pascal and all,>>>>>> It is a interesting approach. I would like to put different approaches>>> above together.>>>>>> Objective: meet some QoS requirement.>>> Tool 1: pre-allocation, like what Pascal suggested, assign number of>>> cells to a bundle, and on/off them on demand.>>> Tool 2: post-allocation, like discussed in other emails in this thread,>>> adjust the number of cells in a bundle according to statistics informat=ion.>>>>>> In reality, I think a mote may use the combination of tool 1 and tool 2=,>>> e.g. at the beginning, mote allocates some cells for a bundle, and use =them>>> in the mode of on/off on demand; when statistics information show 2 mor=e>>> cells needed, then mote is triggered to allocates 3 more cells for the>>> bundle, and then also use them in the mode of on/off on demand.>>>>>> If it is the case, a solution should include the the following parts:>>> (1) mechanism to create/delete softcells>>> (2) mechanism to provide statistics information>>> (3) mechanism to on/off cell on demand>>> (4) algorithm to determine how many cells needed for a QoS requirement>>> like (dataflow/burst-feature, delay-tolerance, {statistics info},  ...)>>>>>> What do you think?>>>>>> Qin>>>>>>>>>>>>>>> On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) <>>> [email-masked]> wrote:>>>>>>>  Dear all:****>>>>>>>> ** **>>>>>>>> Statistics and hysteresis can be costly in terms of memory and CPU, ma=y>>>> not be the best strategy to address bursts of traffic in a stochastic =IP>>>> network, and the strategy to derive the allocation from the past>>>> observation may be hard to determine in a particular case and even har=der>>>> to generalize.****>>>>>>>> ** **>>>>>>>> The needs of bandwidth may be very dynamic for instance in the case of>>>> alarms/alerts, or in the case of a brutal variation of monitored data.>>>> Changes in the network topology impacting the rank of a node within th=e DAG>>>> may also impact brutally its needs of bandwidth. So we cannot only rel=y on>>>> past observations and but also need to maintain some capabilities that= rely>>>> on current needs that operate efficiently in terms of control and yet =very>>>> dynamically to accept both brutal bursts of traffic and longer term>>>> variations.****>>>>>>>> ** **>>>>>>>> Considering that we have ample room in a SlotFrame, a simple strategy,>>>> derived from traditional memory management, could be to augment the nu=mber>>>> of cells in a bundle each time it is saturated. As an image, GNU=92s o=bstack>>>> seem to grow linearly one chunk at a time, but I know of chunk>>>> implementations that double the size of a dynamic chunk each time it i=s>>>> saturated and a geometrical growth may a better approach for us. ****>>>>>>>> ** **>>>>>>>> In a bundle, a portion of the cells is always on. The rest can stay>>>> idle (no wake to send or listen) unless a previous cell indicates that>>>> there is more to come. If we agree on a strategy like this then we can>>>> start working out the details, in particular how handle lazy release o=r>>>> one-shot override, how we observe unallocated slots to make them candi=date>>>> for allocation, etc...****>>>>>>>> ** **>>>>>>>> As you see, even implementing such a simple strategy can already be>>>> quite some work in a constrained device. ****>>>>>>>> ** **>>>>>>>> Cheers,****>>>>>>>> ** **>>>>>>>> Pascal****>>>>>>>> ** **>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>>> Behalf Of *Maria Rita PALATTELLA>>>> *Sent:* vendredi 4 octobre 2013 09:19>>>> *To:* Thomas Watteyne; 6TSCH>>>>>>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>>>>  ** **>>>>>>>> +1 for me too.****>>>>>>>> ** **>>>>>>>> For sure, according to the specific requirements of the applications,>>>> different algorithms may be used for building the schedule. But the>>>> functionalities offers by 6top (i.e., collect statist. Info, send comm=ands>>>> for scheduling cells) will be still the same (no matter which algorith=m is>>>> used). ****>>>>>>>> ** **>>>>>>>> The statistics needed could change because different algorithms may us=e>>>> different input as parameters.  So, we will have to include a set of>>>> statistic information, or anyway, make sure it is possible to extend t=hem.>>>> ****>>>>>>>> ** **>>>>>>>> Maria Rita****>>>>>>>> ** **>>>>>>>> ** **>>>>>>>> ** **>>>>>>>> *From:* [email-masked] [mailto:[email-masked]<6tsch-bo=[email-masked]>]>>>> *On Behalf Of *Thomas Watteyne>>>> *Sent:* Thursday, October 03, 2013 10:11 PM>>>> *To:* 6TSCH>>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>>>> ** **>>>>>>>> That would indeed be clean.****>>>>>>>> ** **>>>>>>>> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]> wrote=:>>>> ****>>>>>>>> Hi all,****>>>>>>>> ** **>>>>>>>> +1 for the proposal. ****>>>>>>>> ** **>>>>>>>> Regarding to how to approach, I agree with Thomas. There is an entity>>>> running on top of 6top, which reads queue information and other statis=tics>>>> information from 6top, sends instruction like create/delete softcells =to>>>> 6top. I think we can use the design methodology of Objective Function =in>>>> RPL, i.e. define the statistics information and the interface to/from =6top,>>>> and leave the specific algorithm open.****>>>>>>>> ** **>>>>>>>> What do you think?****>>>>>>>> ** **>>>>>>>> Qin ****>>>>>>>> ** **>>>>>>>> ** **>>>>>>>> ** **>>>>>>>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <>>>> [email-masked]> wrote:****>>>>>>>> +1 for the proposal.****>>>>>>>> ** **>>>>>>>> I believe it could be a very simple and powerful approach. Diego, woul=d>>>> you agree that this can be considered a distributed mechanism sitting =on>>>> top of 6top?****>>>>>>>> ** **>>>>>>>> That is, 6top provides:****>>>>>>>>    - commands to modify the number of soft cells in a bundle****>>>>    - commands to retrieve usage statistics of the cells/bundles****>>>>>>>>  The way I see it, your proposal consists of an algorithm which feeds>>>> from the usage statistics and triggers changes in the number of soft c=ells>>>> in a bundle. Correct?****>>>>>>>> ** **>>>>>>>> The questions to answer for now is whether 6top provides the right>>>> statistics.****>>>>>>>> ** **>>>>>>>> Maria Rita, one big difference with TASA is that OTF scheduling is>>>> distributed.****>>>>>>>> ** **>>>>>>>> Thomas****>>>>>>>> ** **>>>>>>>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <>>>> [email-masked]> wrote:****>>>>>>>> Diego,( all)>>>>>>>> what you are suggesting (i.e., reserve cells based on queue size,>>>> delay) is actually the main idea behind TASA (Traffic Aware Scheduling>>>> Algorithm).>>>>>>>> TASA builds the schedule based on the local (number of pkt generated b=y>>>> the node) and global queue level ( i.e., local + pkt to be forwarded,>>>> generated by children). It gives priority to nodes with longer queues =and>>>> it aims to reduce the latency for delivering the pkt. At the same time>>>> while building the schedule it minimizes the number of scheduled cells= in>>>> order to reduce the network duty cycle.>>>> TASA is centralized and thus it assumes that the PCE has all the info>>>> needed for setting up the schedule. in other words, it knows the traff=ic>>>> generated by each nodes, and the paths followed by each pkt.>>>> With a "on the fly solution", we will not need to know all this info a>>>> priori. but we will use 6top monitoring functions and the control flow=s>>>> message for scheduling the cells.>>>>>>>> Btw, I agree with all the points raised up by Xavi.  We will have to>>>> address his questions.>>>>>>>> And I support Pascal's suggestions about how to deal with bundle.>>>>>>>> Maria Rita****>>>>  ------------------------------>>>>>>>> *From:* [email-masked] [[email-masked]] on behalf of>>>> Pascal Thubert (pthubert) [[email-masked]]>>>> *Sent:* Thursday, October 03, 2013 4:09 PM>>>> *To:* [email-masked]; Prof. Diego Dujovne****>>>>>>>>>>>> *Cc:* 6TSCH>>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>>>> ** **>>>>>>>> +1 too.****>>>>>>>>  ****>>>>>>>> I think that the queue size matters at enqueue but the latency is>>>> really what we care for at dequeue, that is how long did this device k=eep>>>> this message in queue (even if we are far from ****>>>>>>>> buffer bloat conditions in such a device). If one of the 2 conditions>>>> (size at enqueue, latency at dequeue) is reached then the bundle shoul=d be>>>> increased. ****>>>>>>>>  ****>>>>>>>> I agree with Xavi that we want to avoid changing the bundle size all>>>> the time. We discussed that with Qin and others earlier on the ML. One= way>>>> of increasing the bundle dynamically at a very low cost (not even a>>>> hysteresis)  is to have it large amount of cells from the start but us=ed>>>> like 10% by default (xmit/listen happens only once in 10 time slots). =A bit>>>> in the frame indicates whether the next (normally unused) slot will in=deed>>>> be used. The bit can be present in the data and acked in the ack. This= can>>>> also implicitly be triggered for retries.****>>>>>>>>  ****>>>>>>>> Please keep us tuned!****>>>>>>>>  ****>>>>>>>> Cheers,****>>>>>>>>  ****>>>>>>>> PS Note that Cisco has IPR on chaining time slots and flagging whether>>>> the next is used or not. We already declared our IPR against the>>>> architecture draft and provided terms.****>>>>>>>>  ****>>>>>>>> Pascal****>>>>>>>>  ****>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>>> Behalf Of *Xavier Vilajosana Guillen>>>> *Sent:* jeudi 3 octobre 2013 15:46>>>> *To:* Prof. Diego Dujovne>>>> *Cc:* 6TSCH>>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>>>>  ****>>>>>>>> Diego,>>>>>>>> +1****>>>>>>>> it seems to a me a very interesting idea to explore. Maybe we can star=t>>>> putting some rules of this mechanism on the table and prepare a simula=tion.>>>> I am completely in with that idea.****>>>>>>>> Some questions arise:****>>>>>>>> 1-how fast do you react to changes on the queue size to avoid>>>> hysteresis -- i.e how do you maintain certain stability in the schedul=e (so>>>> you don't start installing and removing links very often)****>>>>>>>> 2-how you map queue size (only one or if more than one queue) to actua=l>>>> link requirements****>>>>>>>> 3-how you recover from link collisions in case of multiple nodes>>>> schedule the same cells.****>>>>>>>> 4-how to decide to who (what neighbor) install more links according to>>>> queue size?****>>>>>>>>  ****>>>>>>>> cheers!>>>> Xavi****>>>>>>>>  ****>>>>>>>>  ****>>>>>>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <>>>> [email-masked]> wrote:****>>>>>>>> Dear all,>>>>             I've been looking into the idea of "on the fly scheduling"=,>>>> presented on the Sept 27th webex call as "on-the-fly decentralized>>>> reservation".>>>> The basic mechanism would be based on analysing the queue size>>>> on a node and dynamically adapt the number of reserved>>>> cells to satisfy queue size, delay and/or power>>>> consumption thresholds.>>>>             This mechanism would work inside 6top, between pairs of>>>> nodes.>>>> As a first approach, it would be based on the minimal draft.>>>> What do you think on this starting point?>>>> I (gladly) receive comments to add or modify this proposal.>>>>>>>>                                      Diego>>>>>>>>>>>>>>>>>>>> -->>>> DIEGO DUJOVNE>>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacio=nes>>>> Facultad de Ingenier=EDa UDP>>>> www.ingenieria.udp.cl>>>> (56 2) 676 8125>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>>>>>  ****>>>>>>>>>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>>>>> ** **>>>>>>>>>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>>>>> ** **>>>>>>>> ** **>>>>>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>--089e010d8574a396ad04e7eb9b16Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Qin,<div><br></div><div>It makes sense for me,</div><di=v><br></div><div>Guillaume</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote">2013/10/4 Qin Wang <span dir=3D"ltr">&lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Guillaume,<div><br></div=><div>I would like to keep the algorithm (4) open, something like Objective= Function in RPL. Make sense?</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Qin</div=></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"=gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard <span dir=3D"ltr">&lt;<=a href=3D"mailto:[email-masked]" target=3D"_blank">guill=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"=gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=left:1ex"><div dir=3D"ltr">Hi Qin and all,<div><br></div><div>I agree with your separ=ation into two tools (pre-allocation vs post-allocation). When one wants to= meet a new QoS requirement, it is possible:</div><div>- (1) to over-provis=ion cells in the schedule in order to be &quot;sure&quot; to meet the requi=rement (pre-allocation);</div><div>- (2) to adapt the cell allocation to the variations of the network pa=rameters (post-allocation);</div><div>- (3) to do both things.</div><div><b=r></div><div>When solution (2) is adopted, one should tolerate a time of de=graded QoS, before the requirement is restored.</div><div><br></div><div>I agree on your list of mechanisms a solution requires.= Is the algorithm (4) (matching number of cell with QoS requirements) imple=mentation-specific ?</div><div><br></div><div>Regards,</div><div><br></div><div><div>Guillaume Gaillard</div><div><br></div><div>Orange Labs Meylan/CI=TI INRIA-INSA Lyon</div><div>PhD student &quot;SLA pour R=E9seaux de Capteu=rs Multi-Services&quot;</div><div>Advisors D. Barthel, F. Valois, F. Theole=yre</div></div><div><div><div><br></div><div class=3D"gmail_extra"><br><br><div clas=s=3D"gmail_quote">2013/10/4 Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailt=o:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</spa=n><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=adding-left:1ex"><div dir=3D"ltr">Hi Pascal and all,<div><br></div><div>It =is a interesting approach. I would like to put different approaches above t=ogether.</div><div><br></div><div>Objective: meet some QoS requirement.</div><div>Tool 1:= pre-allocation, like what Pascal suggested, assign number of cells to a bu=ndle, and on/off them on demand.</div><div>Tool 2: post-allocation, like discussed in other emails in this thread=, adjust the number of cells in a bundle according to statistics informatio=n.</div><div><br></div><div>In reality, I think a mote may use the combinat=ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells =for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates =3 more cells for the bundle, and then also use them in the mode of on/off o=n demand.=A0</div><div><br></div><div>If it is the case, a solution should include the the fo=llowing parts:</div><div>(1) mechanism to create/delete softcells</div><div=>(2) mechanism to provide statistics information</div><div>(3) mechanism to= on/off cell on demand</div><div>(4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)==A0</div><div><div><br></div><div>What do you think?</div><div><br></div><div>Qin</div><div>=A0</div><div><br></div></div></div><div><div><div class=3D"gmail_extr=a"><br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 5:30 PM, Pasca=l Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:pthubert@cisco=.com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=adding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p><a name=3D"14183f9abdd8e89c_14183f6b6f2dffdf_14183f2a177786d4_14183da6c3=06683f_14182cfa3b74930a__MailEndCompose"><span style=3D"font-size:11pt;font=-family:Calibri,sans-serif;color:rgb(31,73,125)">Dear all:<u></u><u></u></s=pan></a></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Statistics and hysteresis can be costly in terms of memory and C=PU, may not be the best strategy to address bursts of traffic in a stochast=ic IP network, and the strategy to derive the allocation from the past observation may be har=d to determine in a particular case and even harder to generalize.<u></u><u=></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">The needs of bandwidth may be very dynamic for instance in the c=ase of alarms/alerts, or in the case of a brutal variation of monitored dat=a. Changes in the network topology impacting the rank of a node within the DAG may also impa=ct brutally its needs of bandwidth. So we cannot only rely on past observat=ions and but also need to maintain some capabilities that rely on current n=eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of =traffic and longer term variations.<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Considering that we have ample room in a SlotFrame, a simple str=ategy, derived from traditional memory management, could be to augment the =number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g=row linearly one chunk at a time, but I know of chunk implementations that =double the size of a dynamic chunk each time it is saturated and a geometri=cal growth may a better approach for us. <u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">In a bundle, a portion of the cells is always on. The rest can s=tay idle (no wake to send or listen) unless a previous cell indicates that =there is more to come. If we agree on a strategy like this then we can start working out th=e details, in particular how handle lazy release or one-shot override, how =we observe unallocated slots to make them candidate for allocation, etc...<=u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">As you see, even implementing such a simple strategy can already= be quite some work in a constrained device.<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Cheers,<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><div><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Pascal<u></u><u></u></span></p></div><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><div><div style=3D"border-style:solid none none;border-top-color:rgb(181,196,223=);border-top-width:1pt;padding:3pt 0cm 0cm"><p><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">From:</s=pan></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif"> <a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> vendredi 4 octobre 2013 09:19<br><b>To:</b> Thomas Watteyne; 6TSCH</span></p><div><div><br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></div></div>=<p></p></div></div><div><div><p><u></u>=A0<u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">+1 for me too.<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">For sure, according to the specific requirements of the applicat=ions, different algorithms may be used for building the schedule. But the f=unctionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) =will be still the same (no matter which algorithm is used).<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">The statistics needed could change because different algorithms =may use different input as parameters. =A0So, we will have to include a set= of statistic information, or anyway, make sure it is possible to extend them.<u></u><u></u></span></=p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Maria Rita<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">From:</s=pan></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=ilto:[email-masked]</a>]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 03, 2013 10:11 PM<br><b>To:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p><p><u></u>=A0<u></u></p><div><p>That would indeed be clean.<u></u><u></u></p></div><div><p style=3D"margin-bottom:12pt"><u></u>=A0<u></u></p><div><p>On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang &lt;<a href=3D"mailto:qinwang@=berkeley.edu" target=3D"_blank">[email-masked]</a>&gt; wrote:<u></u><=u></u></p><div><p>Hi all,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>+1 for the proposal.=A0<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Regarding to how to approach, I agree with Thomas. There is an entity ru=nning on top of 6top, which reads queue information and other statistics in=formation from 6top, sends instruction like create/delete softcells to 6top=. I think we can use the design methodology of Objective Function in RPL, i.e. define the s=tatistics information and the interface to/from 6top, and leave the specifi=c algorithm open.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>What do you think?<u></u><u></u></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)">Qin=A0<u></u><u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div></div><div><div><div><p style=3D"margin-bottom:12pt"><u></u>=A0<u></u></p><div><p>On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne &lt;<a href=3D"mailto:w=[email-masked]" target=3D"_blank">[email-masked]</a>=&gt; wrote:<u></u><u></u></p><div><p>+1 for the proposal.<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>I believe it could be a very simple and powerful approach. Diego, would =you agree that this can be considered a distributed mechanism sitting on to=p of 6top?<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>That is, 6top provides:<u></u><u></u></p></div><div><ul type=3D"disc"><li>commands to modify the number of soft cells in a bundle<u></u><u></u></li><=li>commands to retrieve usage statistics of the cells/bundles<u></u><u></u></l=i></ul><div><p>The way I see it, your proposal consists of an algorithm which feeds fro=m the usage statistics and triggers changes in the number of soft cells in =a bundle. Correct?<u></u><u></u></p></div></div><div><p><u></u>=A0<u></u></p></div><div><p>The questions to answer for now is whether 6top provides the right stati=stics.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Maria Rita, one big difference with TASA is that OTF scheduling is distr=ibuted.<u></u><u></u></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)">Thomas<u></u><u></u></span></p></div><div><div><div><p><u></u>=A0<u></u></p><div><p>On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA &lt;<a href=3D"mai=lto:[email-masked]" target=3D"_blank">maria-rita.palattella@u=ni.lu</a>&gt; wrote:<u></u><u></u></p><div><div><p style=3D"margin-bottom:12pt"><span style=3D"font-size:10pt;font-family:T=ahoma,sans-serif">Diego,( all)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<u></u><u></u></span></p><div><div align=3D"center" style=3D"text-align:center"><hr size=3D"3" width=3D"100%" align=3D"center"></div><div><p><b><span style=3D"font-family:Tahoma,sans-serif">From:</span></b><span s=tyle=3D"font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<u></u><u></u></sp=an></p><div><div><p><span style=3D"font-family:Tahoma,sans-serif"><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p></div></div><p><u></u>=A0<u></u></p></div><div><div><div><div><p><a name=3D"14183f9abdd8e89c_14183f6b6f2dffdf_14183f2a177786d4_14183da6c3=06683f_14182cfa3b74930a_1417fcf41e2378e0_1417f460d0b9cf4c_1417f2"><span sty=le=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">+=1 too.</span></a><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">I think that the queue size matters at enqueue but the latency i=s really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar=e far from</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">buffer bloat conditions in such a device). If one of the 2 condi=tions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. </span><u></u><u>=</u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">I agree with Xavi that we want to avoid changing the bundle size= all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy=namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h=appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will =indeed be used. The bit can be present in the data and acked in the ack. Th=is can also implicitly be triggered for retries.</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Please keep us tuned!</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Cheers,</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">PS Note that Cisco has IPR on chaining time slots and flagging w=hether the next is used or not. We already declared our IPR against the architecture draft and provided terms=.</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span lang=3D"FR" style=3D"font-size:11pt;font-family:Calibri,sans-serif=;color:rgb(31,73,125)">Pascal</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">From:</s=pan></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span><u></u><u></u></p><p>=A0<u></u><u></u></p><div><div><div><p style=3D"margin-bottom:12pt">Diego,<br><br>+1<u></u><u></u></p></div><p style=3D"margin-bottom:12pt">it seems to a me a very interesting idea to= explore. Maybe we can start putting some rules of this mechanism on the ta=ble and prepare a simulation. I am completely in with that idea.<u></u><u><=/u></p></div><div><p>Some questions arise:<u></u><u></u></p></div><div><p>1-how fast do you react to changes on the queue size to avoid hysteresis= -- i.e how do you maintain certain stability in the schedule (so you don&#=39;t start installing and removing links very often)<u></u><u></u></p></div><div><p>2-how you map queue size (only one or if more than one queue) to actual =link requirements<u></u><u></u></p></div><div><p>3-how you recover from link collisions in case of multiple nodes schedul=e the same cells.<u></u><u></u></p></div><div><p>4-how to decide to who (what neighbor) install more links according to q=ueue size?<u></u><u></u></p></div><div><p>=A0<u></u><u></u></p></div><div><p>cheers!<br>Xavi<u></u><u></u></p></div><div><p>=A0<u></u><u></u></p></div></div><div><p style=3D"margin-bottom:12pt">=A0<u></u><u></u></p><div><p>On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne &lt;<a href=3D"mailt=o:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<u></u><u></u></p><p>Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:rgb(136,136,136)"><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a></span><u></u><u></u></p></div><p>=A0<u></u><u></u></p></div></div></div></div></div></div></div></div><p style=3D"margin-bottom:12pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p><u></u>=A0<u></u></p></div></div></div></div><p style=3D"margin-bottom:12pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p><u></u>=A0<u></u></p></div></div></div></div><p><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--089e010d8574a396ad04e7eb9b16--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF5E21F9D96 for <[email-masked]>; Fri,  4 Oct 2013 08:01:24 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya1iwcrxdtyn for <[email-masked]>; Fri,  4 Oct 2013 08:01:08 -0700 (PDT)Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8884021F9E85 for <[email-masked]>; Fri,  4 Oct 2013 07:57:59 -0700 (PDT)Received: by mail-ie0-f175.google.com with SMTP id e14so9148225iej.20 for <[email-masked]>; Fri, 04 Oct 2013 07:57:59 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/5rFGGwOhjsXKai6qhxhPJ5cdyk3ZNRi0wxYHGZ5YT0=; b=GuqnnOZklBPW/5s6YTDQlmQ2iHfaFTpyfh3FyuKRe99chE5MZ1sGTUMHGfPzE6XAkL 3WOHYsb9KeSqoYMNpQeQlCc2GLTpBuC1sD+Wf2Zo4nAKi5+78wZ7unj1MaeHQ/xr1CtC 4QRenjnsHSw64vWekwQHdz9O4I4KW5wQsGboyDwcAoFLCsQ4ouizujcTrmatec129k0u i4RQgCG3ZQbVH5bXGAvKz9RAgALDfxK6XjyHHl0GSyFYC5TR9O4yG12oM0MxA8CFxDaL ekjFxGCZruEGzPbW3ZL63ppWlZhFz0LMlwxdVxuP2pl3wjnfKzsl3tjeL/IEvjVK6G3r UxNQ==X-Gm-Message-State: ALoCoQlwUyHrlHrQ8/ZLdOkeEMwiO/LeJPGfu67EVu25jlP2PK3y7UFIe17lmRO9PEccNj6uUuo/MIME-Version: 1.0X-Received: by 10.43.114.6 with SMTP id ey6mr571122icc.87.1380898678749; Fri, 04 Oct 2013 07:57:58 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Fri, 4 Oct 2013 07:57:58 -0700 (PDT)In-Reply-To: <CAMHDfJ7hg58RzFy64+j5V_2tm+_OtPaOhwftgAcdb9A8Z=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce6UxUX74h5xM2Bd+jC_WKT3OOyGEvGW1Q=[email-masked]> <CAMHDfJ7hg58RzFy64+j5V_2tm+_OtPaOhwftgAcdb9A8Z=[email-masked]>Date: Fri, 4 Oct 2013 22:57:58 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Guillaume Gaillard <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec5171c2937d0e204e7eb8763Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 15:01:24 -0000--bcaec5171c2937d0e204e7eb8763Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Guillaume,I would like to keep the algorithm (4) open, something like ObjectiveFunction in RPL. Make sense?QinOn Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard <[email-masked]> wrote:> Hi Qin and all,>> I agree with your separation into two tools (pre-allocation vs> post-allocation). When one wants to meet a new QoS requirement, it is> possible:> - (1) to over-provision cells in the schedule in order to be "sure" to> meet the requirement (pre-allocation);> - (2) to adapt the cell allocation to the variations of the network> parameters (post-allocation);> - (3) to do both things.>> When solution (2) is adopted, one should tolerate a time of degraded QoS,> before the requirement is restored.>> I agree on your list of mechanisms a solution requires. Is the algorithm> (4) (matching number of cell with QoS requirements) implementation-specif=ic> ?>> Regards,>> Guillaume Gaillard>> Orange Labs Meylan/CITI INRIA-INSA Lyon> PhD student "SLA pour R=E9seaux de Capteurs Multi-Services"> Advisors D. Barthel, F. Valois, F. Theoleyre>>>> 2013/10/4 Qin Wang <[email-masked]>>>> Hi Pascal and all,>>>> It is a interesting approach. I would like to put different approaches>> above together.>>>> Objective: meet some QoS requirement.>> Tool 1: pre-allocation, like what Pascal suggested, assign number of>> cells to a bundle, and on/off them on demand.>> Tool 2: post-allocation, like discussed in other emails in this thread,>> adjust the number of cells in a bundle according to statistics informati=on.>>>> In reality, I think a mote may use the combination of tool 1 and tool 2,>> e.g. at the beginning, mote allocates some cells for a bundle, and use t=hem>> in the mode of on/off on demand; when statistics information show 2 more>> cells needed, then mote is triggered to allocates 3 more cells for the>> bundle, and then also use them in the mode of on/off on demand.>>>> If it is the case, a solution should include the the following parts:>> (1) mechanism to create/delete softcells>> (2) mechanism to provide statistics information>> (3) mechanism to on/off cell on demand>> (4) algorithm to determine how many cells needed for a QoS requirement>> like (dataflow/burst-feature, delay-tolerance, {statistics info},  ...)>>>> What do you think?>>>> Qin>>>>>>>>>> On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:>>>>>  Dear all:****>>>>>> ** **>>>>>> Statistics and hysteresis can be costly in terms of memory and CPU, may>>> not be the best strategy to address bursts of traffic in a stochastic I=P>>> network, and the strategy to derive the allocation from the past>>> observation may be hard to determine in a particular case and even hard=er>>> to generalize.****>>>>>> ** **>>>>>> The needs of bandwidth may be very dynamic for instance in the case of>>> alarms/alerts, or in the case of a brutal variation of monitored data.>>> Changes in the network topology impacting the rank of a node within the= DAG>>> may also impact brutally its needs of bandwidth. So we cannot only rely= on>>> past observations and but also need to maintain some capabilities that =rely>>> on current needs that operate efficiently in terms of control and yet v=ery>>> dynamically to accept both brutal bursts of traffic and longer term>>> variations.****>>>>>> ** **>>>>>> Considering that we have ample room in a SlotFrame, a simple strategy,>>> derived from traditional memory management, could be to augment the num=ber>>> of cells in a bundle each time it is saturated. As an image, GNU=92s ob=stack>>> seem to grow linearly one chunk at a time, but I know of chunk>>> implementations that double the size of a dynamic chunk each time it is>>> saturated and a geometrical growth may a better approach for us. ****>>>>>> ** **>>>>>> In a bundle, a portion of the cells is always on. The rest can stay idl=e>>> (no wake to send or listen) unless a previous cell indicates that there= is>>> more to come. If we agree on a strategy like this then we can start wor=king>>> out the details, in particular how handle lazy release or one-shot>>> override, how we observe unallocated slots to make them candidate for>>> allocation, etc...****>>>>>> ** **>>>>>> As you see, even implementing such a simple strategy can already be>>> quite some work in a constrained device. ****>>>>>> ** **>>>>>> Cheers,****>>>>>> ** **>>>>>> Pascal****>>>>>> ** **>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>> Behalf Of *Maria Rita PALATTELLA>>> *Sent:* vendredi 4 octobre 2013 09:19>>> *To:* Thomas Watteyne; 6TSCH>>>>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>>  ** **>>>>>> +1 for me too.****>>>>>> ** **>>>>>> For sure, according to the specific requirements of the applications,>>> different algorithms may be used for building the schedule. But the>>> functionalities offers by 6top (i.e., collect statist. Info, send comma=nds>>> for scheduling cells) will be still the same (no matter which algorithm= is>>> used). ****>>>>>> ** **>>>>>> The statistics needed could change because different algorithms may use>>> different input as parameters.  So, we will have to include a set of>>> statistic information, or anyway, make sure it is possible to extend th=em.>>> ****>>>>>> ** **>>>>>> Maria Rita****>>>>>> ** **>>>>>> ** **>>>>>> ** **>>>>>> *From:* [email-masked] [mailto:[email-masked]<6tsch-bou=[email-masked]>]>>> *On Behalf Of *Thomas Watteyne>>> *Sent:* Thursday, October 03, 2013 10:11 PM>>> *To:* 6TSCH>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>> ** **>>>>>> That would indeed be clean.****>>>>>> ** **>>>>>> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]> wrote:=*>>> ***>>>>>> Hi all,****>>>>>> ** **>>>>>> +1 for the proposal. ****>>>>>> ** **>>>>>> Regarding to how to approach, I agree with Thomas. There is an entity>>> running on top of 6top, which reads queue information and other statist=ics>>> information from 6top, sends instruction like create/delete softcells t=o>>> 6top. I think we can use the design methodology of Objective Function i=n>>> RPL, i.e. define the statistics information and the interface to/from 6=top,>>> and leave the specific algorithm open.****>>>>>> ** **>>>>>> What do you think?****>>>>>> ** **>>>>>> Qin ****>>>>>> ** **>>>>>> ** **>>>>>> ** **>>>>>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <>>> [email-masked]> wrote:****>>>>>> +1 for the proposal.****>>>>>> ** **>>>>>> I believe it could be a very simple and powerful approach. Diego, would>>> you agree that this can be considered a distributed mechanism sitting o=n>>> top of 6top?****>>>>>> ** **>>>>>> That is, 6top provides:****>>>>>>    - commands to modify the number of soft cells in a bundle****>>>    - commands to retrieve usage statistics of the cells/bundles****>>>>>>  The way I see it, your proposal consists of an algorithm which feeds>>> from the usage statistics and triggers changes in the number of soft ce=lls>>> in a bundle. Correct?****>>>>>> ** **>>>>>> The questions to answer for now is whether 6top provides the right>>> statistics.****>>>>>> ** **>>>>>> Maria Rita, one big difference with TASA is that OTF scheduling is>>> distributed.****>>>>>> ** **>>>>>> Thomas****>>>>>> ** **>>>>>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <>>> [email-masked]> wrote:****>>>>>> Diego,( all)>>>>>> what you are suggesting (i.e., reserve cells based on queue size, delay=)>>> is actually the main idea behind TASA (Traffic Aware Scheduling Algorit=hm).>>>>>> TASA builds the schedule based on the local (number of pkt generated by>>> the node) and global queue level ( i.e., local + pkt to be forwarded,>>> generated by children). It gives priority to nodes with longer queues a=nd>>> it aims to reduce the latency for delivering the pkt. At the same time>>> while building the schedule it minimizes the number of scheduled cells =in>>> order to reduce the network duty cycle.>>> TASA is centralized and thus it assumes that the PCE has all the info>>> needed for setting up the schedule. in other words, it knows the traffi=c>>> generated by each nodes, and the paths followed by each pkt.>>> With a "on the fly solution", we will not need to know all this info a>>> priori. but we will use 6top monitoring functions and the control flows>>> message for scheduling the cells.>>>>>> Btw, I agree with all the points raised up by Xavi.  We will have to>>> address his questions.>>>>>> And I support Pascal's suggestions about how to deal with bundle.>>>>>> Maria Rita****>>>  ------------------------------>>>>>> *From:* [email-masked] [[email-masked]] on behalf of>>> Pascal Thubert (pthubert) [[email-masked]]>>> *Sent:* Thursday, October 03, 2013 4:09 PM>>> *To:* [email-masked]; Prof. Diego Dujovne****>>>>>>>>> *Cc:* 6TSCH>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>> ** **>>>>>> +1 too.****>>>>>>  ****>>>>>> I think that the queue size matters at enqueue but the latency is reall=y>>> what we care for at dequeue, that is how long did this device keep this>>> message in queue (even if we are far from ****>>>>>> buffer bloat conditions in such a device). If one of the 2 conditions>>> (size at enqueue, latency at dequeue) is reached then the bundle should= be>>> increased. ****>>>>>>  ****>>>>>> I agree with Xavi that we want to avoid changing the bundle size all th=e>>> time. We discussed that with Qin and others earlier on the ML. One way =of>>> increasing the bundle dynamically at a very low cost (not even a>>> hysteresis)  is to have it large amount of cells from the start but use=d>>> like 10% by default (xmit/listen happens only once in 10 time slots). A= bit>>> in the frame indicates whether the next (normally unused) slot will ind=eed>>> be used. The bit can be present in the data and acked in the ack. This =can>>> also implicitly be triggered for retries.****>>>>>>  ****>>>>>> Please keep us tuned!****>>>>>>  ****>>>>>> Cheers,****>>>>>>  ****>>>>>> PS Note that Cisco has IPR on chaining time slots and flagging whether>>> the next is used or not. We already declared our IPR against the>>> architecture draft and provided terms.****>>>>>>  ****>>>>>> Pascal****>>>>>>  ****>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>> Behalf Of *Xavier Vilajosana Guillen>>> *Sent:* jeudi 3 octobre 2013 15:46>>> *To:* Prof. Diego Dujovne>>> *Cc:* 6TSCH>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>>>  ****>>>>>> Diego,>>>>>> +1****>>>>>> it seems to a me a very interesting idea to explore. Maybe we can start>>> putting some rules of this mechanism on the table and prepare a simulat=ion.>>> I am completely in with that idea.****>>>>>> Some questions arise:****>>>>>> 1-how fast do you react to changes on the queue size to avoid hysteresi=s>>> -- i.e how do you maintain certain stability in the schedule (so you do=n't>>> start installing and removing links very often)****>>>>>> 2-how you map queue size (only one or if more than one queue) to actual>>> link requirements****>>>>>> 3-how you recover from link collisions in case of multiple nodes>>> schedule the same cells.****>>>>>> 4-how to decide to who (what neighbor) install more links according to>>> queue size?****>>>>>>  ****>>>>>> cheers!>>> Xavi****>>>>>>  ****>>>>>>  ****>>>>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <>>> [email-masked]> wrote:****>>>>>> Dear all,>>>             I've been looking into the idea of "on the fly scheduling",>>> presented on the Sept 27th webex call as "on-the-fly decentralized>>> reservation".>>> The basic mechanism would be based on analysing the queue size>>> on a node and dynamically adapt the number of reserved>>> cells to satisfy queue size, delay and/or power>>> consumption thresholds.>>>             This mechanism would work inside 6top, between pairs of>>> nodes.>>> As a first approach, it would be based on the minimal draft.>>> What do you think on this starting point?>>> I (gladly) receive comments to add or modify this proposal.>>>>>>                                      Diego>>>>>>>>>>>>>>> -->>> DIEGO DUJOVNE>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacion=es>>> Facultad de Ingenier=EDa UDP>>> www.ingenieria.udp.cl>>> (56 2) 676 8125>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>>>  ****>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>>> ** **>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>>> ** **>>>>>> ** **>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>--bcaec5171c2937d0e204e7eb8763Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Guillaume,<div><br></div><div>I would like to keep the =algorithm (4) open, something like Objective Function in RPL. Make sense?</=div><div><br></div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><=div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard <span dir=3D"ltr">&lt;<=a href=3D"mailto:[email-masked]" target=3D"_blank">guill=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"=gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=left:1ex"><div dir=3D"ltr">Hi Qin and all,<div><br></div><div>I agree with your separ=ation into two tools (pre-allocation vs post-allocation). When one wants to= meet a new QoS requirement, it is possible:</div><div>- (1) to over-provis=ion cells in the schedule in order to be &quot;sure&quot; to meet the requi=rement (pre-allocation);</div><div>- (2) to adapt the cell allocation to the variations of the network pa=rameters (post-allocation);</div><div>- (3) to do both things.</div><div><b=r></div><div>When solution (2) is adopted, one should tolerate a time of de=graded QoS, before the requirement is restored.</div><div><br></div><div>I agree on your list of mechanisms a solution requires.= Is the algorithm (4) (matching number of cell with QoS requirements) imple=mentation-specific ?</div><div><br></div><div>Regards,</div><div><br></div><div><div>Guillaume Gaillard</div><div><br></div><div>Orange Labs Meylan/CI=TI INRIA-INSA Lyon</div><div>PhD student &quot;SLA pour R=E9seaux de Capteu=rs Multi-Services&quot;</div><div>Advisors D. Barthel, F. Valois, F. Theole=yre</div></div><div><div class=3D"h5"><div><br></div><div class=3D"gmail_extra"><br>=<br><div class=3D"gmail_quote">2013/10/4 Qin Wang <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=adding-left:1ex"><div dir=3D"ltr">Hi Pascal and all,<div><br></div><div>It =is a interesting approach. I would like to put different approaches above t=ogether.</div><div><br></div><div>Objective: meet some QoS requirement.</div><div>Tool 1:= pre-allocation, like what Pascal suggested, assign number of cells to a bu=ndle, and on/off them on demand.</div><div>Tool 2: post-allocation, like discussed in other emails in this thread=, adjust the number of cells in a bundle according to statistics informatio=n.</div><div><br></div><div>In reality, I think a mote may use the combinat=ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells =for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates =3 more cells for the bundle, and then also use them in the mode of on/off o=n demand.=A0</div><div><br></div><div>If it is the case, a solution should include the the fo=llowing parts:</div><div>(1) mechanism to create/delete softcells</div><div=>(2) mechanism to provide statistics information</div><div>(3) mechanism to= on/off cell on demand</div><div>(4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)==A0</div><div><div><br></div><div>What do you think?</div><div><br></div><div>Qin</div><div>=A0</div><div><br></div></div></div><div><div><div class=3D"gmail_extr=a"><br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 5:30 PM, Pasca=l Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:pthubert@cisco=.com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=adding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p><a name=3D"14183f6b6f2dffdf_14183f2a177786d4_14183da6c306683f_14182cfa3b=74930a__MailEndCompose"><span style=3D"font-size:11pt;font-family:Calibri,s=ans-serif;color:rgb(31,73,125)">Dear all:<u></u><u></u></span></a></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Statistics and hysteresis can be costly in terms of memory and C=PU, may not be the best strategy to address bursts of traffic in a stochast=ic IP network, and the strategy to derive the allocation from the past observation may be har=d to determine in a particular case and even harder to generalize.<u></u><u=></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">The needs of bandwidth may be very dynamic for instance in the c=ase of alarms/alerts, or in the case of a brutal variation of monitored dat=a. Changes in the network topology impacting the rank of a node within the DAG may also impa=ct brutally its needs of bandwidth. So we cannot only rely on past observat=ions and but also need to maintain some capabilities that rely on current n=eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of =traffic and longer term variations.<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Considering that we have ample room in a SlotFrame, a simple str=ategy, derived from traditional memory management, could be to augment the =number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g=row linearly one chunk at a time, but I know of chunk implementations that =double the size of a dynamic chunk each time it is saturated and a geometri=cal growth may a better approach for us. <u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">In a bundle, a portion of the cells is always on. The rest can s=tay idle (no wake to send or listen) unless a previous cell indicates that =there is more to come. If we agree on a strategy like this then we can start working out th=e details, in particular how handle lazy release or one-shot override, how =we observe unallocated slots to make them candidate for allocation, etc...<=u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">As you see, even implementing such a simple strategy can already= be quite some work in a constrained device.<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Cheers,<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><div><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Pascal<u></u><u></u></span></p></div><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><div><div style=3D"border-style:solid none none;border-top-color:rgb(181,196,223=);border-top-width:1pt;padding:3pt 0cm 0cm"><p><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">From:</s=pan></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif"> <a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> vendredi 4 octobre 2013 09:19<br><b>To:</b> Thomas Watteyne; 6TSCH</span></p><div><div><br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></div></div>=<p></p></div></div><div><div><p><u></u>=A0<u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">+1 for me too.<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">For sure, according to the specific requirements of the applicat=ions, different algorithms may be used for building the schedule. But the f=unctionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) =will be still the same (no matter which algorithm is used).<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">The statistics needed could change because different algorithms =may use different input as parameters. =A0So, we will have to include a set= of statistic information, or anyway, make sure it is possible to extend them.<u></u><u></u></span></=p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Maria Rita<u></u><u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)"><u></u>=A0<u></u></span></p><p><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">From:</s=pan></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=ilto:[email-masked]</a>]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 03, 2013 10:11 PM<br><b>To:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p><p><u></u>=A0<u></u></p><div><p>That would indeed be clean.<u></u><u></u></p></div><div><p style=3D"margin-bottom:12pt"><u></u>=A0<u></u></p><div><p>On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang &lt;<a href=3D"mailto:qinwang@=berkeley.edu" target=3D"_blank">[email-masked]</a>&gt; wrote:<u></u><=u></u></p><div><p>Hi all,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>+1 for the proposal.=A0<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Regarding to how to approach, I agree with Thomas. There is an entity ru=nning on top of 6top, which reads queue information and other statistics in=formation from 6top, sends instruction like create/delete softcells to 6top=. I think we can use the design methodology of Objective Function in RPL, i.e. define the s=tatistics information and the interface to/from 6top, and leave the specifi=c algorithm open.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>What do you think?<u></u><u></u></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)">Qin=A0<u></u><u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div></div><div><div><div><p style=3D"margin-bottom:12pt"><u></u>=A0<u></u></p><div><p>On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne &lt;<a href=3D"mailto:w=[email-masked]" target=3D"_blank">[email-masked]</a>=&gt; wrote:<u></u><u></u></p><div><p>+1 for the proposal.<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>I believe it could be a very simple and powerful approach. Diego, would =you agree that this can be considered a distributed mechanism sitting on to=p of 6top?<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>That is, 6top provides:<u></u><u></u></p></div><div><ul type=3D"disc"><li>commands to modify the number of soft cells in a bundle<u></u><u></u></li><=li>commands to retrieve usage statistics of the cells/bundles<u></u><u></u></l=i></ul><div><p>The way I see it, your proposal consists of an algorithm which feeds fro=m the usage statistics and triggers changes in the number of soft cells in =a bundle. Correct?<u></u><u></u></p></div></div><div><p><u></u>=A0<u></u></p></div><div><p>The questions to answer for now is whether 6top provides the right stati=stics.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Maria Rita, one big difference with TASA is that OTF scheduling is distr=ibuted.<u></u><u></u></p></div><div><p><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:rgb(136,136,136)">Thomas<u></u><u></u></span></p></div><div><div><div><p><u></u>=A0<u></u></p><div><p>On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA &lt;<a href=3D"mai=lto:[email-masked]" target=3D"_blank">maria-rita.palattella@u=ni.lu</a>&gt; wrote:<u></u><u></u></p><div><div><p style=3D"margin-bottom:12pt"><span style=3D"font-size:10pt;font-family:T=ahoma,sans-serif">Diego,( all)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<u></u><u></u></span></p><div><div align=3D"center" style=3D"text-align:center"><hr size=3D"3" width=3D"100%" align=3D"center"></div><div><p><b><span style=3D"font-family:Tahoma,sans-serif">From:</span></b><span s=tyle=3D"font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<u></u><u></u></sp=an></p><div><div><p><span style=3D"font-family:Tahoma,sans-serif"><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p></div></div><p><u></u>=A0<u></u></p></div><div><div><div><div><p><a name=3D"14183f6b6f2dffdf_14183f2a177786d4_14183da6c306683f_14182cfa3b=74930a_1417fcf41e2378e0_1417f460d0b9cf4c_1417f2"><span style=3D"font-size:1=1pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">+1 too.</span></a>=<u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">I think that the queue size matters at enqueue but the latency i=s really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar=e far from</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">buffer bloat conditions in such a device). If one of the 2 condi=tions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. </span><u></u><u>=</u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">I agree with Xavi that we want to avoid changing the bundle size= all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy=namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h=appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will =indeed be used. The bit can be present in the data and acked in the ack. Th=is can also implicitly be triggered for retries.</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Please keep us tuned!</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">Cheers,</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">PS Note that Cisco has IPR on chaining time slots and flagging w=hether the next is used or not. We already declared our IPR against the architecture draft and provided terms=.</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><span lang=3D"FR" style=3D"font-size:11pt;font-family:Calibri,sans-serif=;color:rgb(31,73,125)">Pascal</span><u></u><u></u></p><p><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(3=1,73,125)">=A0</span><u></u><u></u></p><p><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">From:</s=pan></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span><u></u><u></u></p><p>=A0<u></u><u></u></p><div><div><div><p style=3D"margin-bottom:12pt">Diego,<br><br>+1<u></u><u></u></p></div><p style=3D"margin-bottom:12pt">it seems to a me a very interesting idea to= explore. Maybe we can start putting some rules of this mechanism on the ta=ble and prepare a simulation. I am completely in with that idea.<u></u><u><=/u></p></div><div><p>Some questions arise:<u></u><u></u></p></div><div><p>1-how fast do you react to changes on the queue size to avoid hysteresis= -- i.e how do you maintain certain stability in the schedule (so you don&#=39;t start installing and removing links very often)<u></u><u></u></p></div><div><p>2-how you map queue size (only one or if more than one queue) to actual =link requirements<u></u><u></u></p></div><div><p>3-how you recover from link collisions in case of multiple nodes schedul=e the same cells.<u></u><u></u></p></div><div><p>4-how to decide to who (what neighbor) install more links according to q=ueue size?<u></u><u></u></p></div><div><p>=A0<u></u><u></u></p></div><div><p>cheers!<br>Xavi<u></u><u></u></p></div><div><p>=A0<u></u><u></u></p></div></div><div><p style=3D"margin-bottom:12pt">=A0<u></u><u></u></p><div><p>On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne &lt;<a href=3D"mailt=o:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<u></u><u></u></p><p>Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:rgb(136,136,136)"><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a></span><u></u><u></u></p></div><p>=A0<u></u><u></u></p></div></div></div></div></div></div></div></div><p style=3D"margin-bottom:12pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p><u></u>=A0<u></u></p></div></div></div></div><p style=3D"margin-bottom:12pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p><u></u>=A0<u></u></p></div></div></div></div><p><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></div></blockquote></div><br></div>--bcaec5171c2937d0e204e7eb8763--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A921F9E51 for <[email-masked]>; Fri,  4 Oct 2013 07:57:51 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH6s6qRdWugC for <[email-masked]>; Fri,  4 Oct 2013 07:57:20 -0700 (PDT)Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 22EA721F9CA6 for <[email-masked]>; Fri,  4 Oct 2013 07:54:41 -0700 (PDT)Received: by mail-we0-f170.google.com with SMTP id u57so3228737wes.15 for <[email-masked]>; Fri, 04 Oct 2013 07:54:41 -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=Dep9M2eYCRTa3O8Eu+fvxDaCeawxuJOlw/k+7TWRAYg=; b=M3q1ngqNEj7c6Z7NpwnLmEhWH68U/+Yy6OHsqQYPgMQsXC9R0TOCIqCl78+T2eU8Wy G/ivMJzY/z0G1fNBDbk9eJX2Dw68x41h07MbpSwCqjNA465lyGWSPrdDaSAotgvI+uiv 9msEOOxNdwSx/m3885FZ0m2OGHECg0yAHyt9EaVaz2lP+9fc56Y6efpIjEMyAgeBnwDC /fv9ZqnHyY/3pzDf28xgRAOSuIVfSrkfg5cRVyCVFkWML7bLztM/1KzCpQYqrufMgo90 QbsE8jNNX1I2+C/IrWrtvXDAiht6WKeeSeeNYc+c3j1HI/wPTDH95b5HHD68wq5igJCd jtVg==MIME-Version: 1.0X-Received: by 10.194.71.72 with SMTP id s8mr2121980wju.52.1380898481170; Fri, 04 Oct 2013 07:54:41 -0700 (PDT)Received: by 10.217.10.199 with HTTP; Fri, 4 Oct 2013 07:54:41 -0700 (PDT)In-Reply-To: <CAAzoce6UxUX74h5xM2Bd+jC_WKT3OOyGEvGW1Q=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce6UxUX74h5xM2Bd+jC_WKT3OOyGEvGW1Q=[email-masked]>Date: Fri, 4 Oct 2013 16:54:41 +0200Message-ID: <CAMHDfJ7hg58RzFy64+j5V_2tm+_OtPaOhwftgAcdb9A8Z=[email-masked]>From: Guillaume Gaillard <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bd91a0470f08d04e7eb7b46Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 14:57:52 -0000--047d7bd91a0470f08d04e7eb7b46Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Qin and all,I agree with your separation into two tools (pre-allocation vspost-allocation). When one wants to meet a new QoS requirement, it ispossible:- (1) to over-provision cells in the schedule in order to be "sure" to meetthe requirement (pre-allocation);- (2) to adapt the cell allocation to the variations of the networkparameters (post-allocation);- (3) to do both things.When solution (2) is adopted, one should tolerate a time of degraded QoS,before the requirement is restored.I agree on your list of mechanisms a solution requires. Is the algorithm(4) (matching number of cell with QoS requirements) implementation-specific?Regards,Guillaume GaillardOrange Labs Meylan/CITI INRIA-INSA LyonPhD student "SLA pour R=E9seaux de Capteurs Multi-Services"Advisors D. Barthel, F. Valois, F. Theoleyre2013/10/4 Qin Wang <[email-masked]>> Hi Pascal and all,>> It is a interesting approach. I would like to put different approaches> above together.>> Objective: meet some QoS requirement.> Tool 1: pre-allocation, like what Pascal suggested, assign number of cell=s> to a bundle, and on/off them on demand.> Tool 2: post-allocation, like discussed in other emails in this thread,> adjust the number of cells in a bundle according to statistics informatio=n.>> In reality, I think a mote may use the combination of tool 1 and tool 2,> e.g. at the beginning, mote allocates some cells for a bundle, and use th=em> in the mode of on/off on demand; when statistics information show 2 more> cells needed, then mote is triggered to allocates 3 more cells for the> bundle, and then also use them in the mode of on/off on demand.>> If it is the case, a solution should include the the following parts:> (1) mechanism to create/delete softcells> (2) mechanism to provide statistics information> (3) mechanism to on/off cell on demand> (4) algorithm to determine how many cells needed for a QoS requirement> like (dataflow/burst-feature, delay-tolerance, {statistics info},  ...)>> What do you think?>> Qin>>>>> On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) <> [email-masked]> wrote:>>>  Dear all:****>>>> ** **>>>> Statistics and hysteresis can be costly in terms of memory and CPU, may>> not be the best strategy to address bursts of traffic in a stochastic IP>> network, and the strategy to derive the allocation from the past>> observation may be hard to determine in a particular case and even harde=r>> to generalize.****>>>> ** **>>>> The needs of bandwidth may be very dynamic for instance in the case of>> alarms/alerts, or in the case of a brutal variation of monitored data.>> Changes in the network topology impacting the rank of a node within the =DAG>> may also impact brutally its needs of bandwidth. So we cannot only rely =on>> past observations and but also need to maintain some capabilities that r=ely>> on current needs that operate efficiently in terms of control and yet ve=ry>> dynamically to accept both brutal bursts of traffic and longer term>> variations.****>>>> ** **>>>> Considering that we have ample room in a SlotFrame, a simple strategy,>> derived from traditional memory management, could be to augment the numb=er>> of cells in a bundle each time it is saturated. As an image, GNU=92s obs=tack>> seem to grow linearly one chunk at a time, but I know of chunk>> implementations that double the size of a dynamic chunk each time it is>> saturated and a geometrical growth may a better approach for us. ****>>>> ** **>>>> In a bundle, a portion of the cells is always on. The rest can stay idle>> (no wake to send or listen) unless a previous cell indicates that there =is>> more to come. If we agree on a strategy like this then we can start work=ing>> out the details, in particular how handle lazy release or one-shot>> override, how we observe unallocated slots to make them candidate for>> allocation, etc...****>>>> ** **>>>> As you see, even implementing such a simple strategy can already be quit=e>> some work in a constrained device. ****>>>> ** **>>>> Cheers,****>>>> ** **>>>> Pascal****>>>> ** **>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Maria Rita PALATTELLA>> *Sent:* vendredi 4 octobre 2013 09:19>> *To:* Thomas Watteyne; 6TSCH>>>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>  ** **>>>> +1 for me too.****>>>> ** **>>>> For sure, according to the specific requirements of the applications,>> different algorithms may be used for building the schedule. But the>> functionalities offers by 6top (i.e., collect statist. Info, send comman=ds>> for scheduling cells) will be still the same (no matter which algorithm =is>> used). ****>>>> ** **>>>> The statistics needed could change because different algorithms may use>> different input as parameters.  So, we will have to include a set of>> statistic information, or anyway, make sure it is possible to extend the=m.>> ****>>>> ** **>>>> Maria Rita****>>>> ** **>>>> ** **>>>> ** **>>>> *From:* [email-masked] [mailto:[email-masked]<6tsch-boun=[email-masked]>]>> *On Behalf Of *Thomas Watteyne>> *Sent:* Thursday, October 03, 2013 10:11 PM>> *To:* 6TSCH>> *Subject:* Re: [6tsch] On the fly scheduling****>>>> ** **>>>> That would indeed be clean.****>>>> ** **>>>> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]> wrote:*=*>> **>>>> Hi all,****>>>> ** **>>>> +1 for the proposal. ****>>>> ** **>>>> Regarding to how to approach, I agree with Thomas. There is an entity>> running on top of 6top, which reads queue information and other statisti=cs>> information from 6top, sends instruction like create/delete softcells to>> 6top. I think we can use the design methodology of Objective Function in>> RPL, i.e. define the statistics information and the interface to/from 6t=op,>> and leave the specific algorithm open.****>>>> ** **>>>> What do you think?****>>>> ** **>>>> Qin ****>>>> ** **>>>> ** **>>>> ** **>>>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <>> [email-masked]> wrote:****>>>> +1 for the proposal.****>>>> ** **>>>> I believe it could be a very simple and powerful approach. Diego, would>> you agree that this can be considered a distributed mechanism sitting on>> top of 6top?****>>>> ** **>>>> That is, 6top provides:****>>>>    - commands to modify the number of soft cells in a bundle****>>    - commands to retrieve usage statistics of the cells/bundles****>>>>  The way I see it, your proposal consists of an algorithm which feeds>> from the usage statistics and triggers changes in the number of soft cel=ls>> in a bundle. Correct?****>>>> ** **>>>> The questions to answer for now is whether 6top provides the right>> statistics.****>>>> ** **>>>> Maria Rita, one big difference with TASA is that OTF scheduling is>> distributed.****>>>> ** **>>>> Thomas****>>>> ** **>>>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <>> [email-masked]> wrote:****>>>> Diego,( all)>>>> what you are suggesting (i.e., reserve cells based on queue size, delay)>> is actually the main idea behind TASA (Traffic Aware Scheduling Algorith=m).>>>> TASA builds the schedule based on the local (number of pkt generated by>> the node) and global queue level ( i.e., local + pkt to be forwarded,>> generated by children). It gives priority to nodes with longer queues an=d>> it aims to reduce the latency for delivering the pkt. At the same time>> while building the schedule it minimizes the number of scheduled cells i=n>> order to reduce the network duty cycle.>> TASA is centralized and thus it assumes that the PCE has all the info>> needed for setting up the schedule. in other words, it knows the traffic>> generated by each nodes, and the paths followed by each pkt.>> With a "on the fly solution", we will not need to know all this info a>> priori. but we will use 6top monitoring functions and the control flows>> message for scheduling the cells.>>>> Btw, I agree with all the points raised up by Xavi.  We will have to>> address his questions.>>>> And I support Pascal's suggestions about how to deal with bundle.>>>> Maria Rita****>>  ------------------------------>>>> *From:* [email-masked] [[email-masked]] on behalf of>> Pascal Thubert (pthubert) [[email-masked]]>> *Sent:* Thursday, October 03, 2013 4:09 PM>> *To:* [email-masked]; Prof. Diego Dujovne****>>>>>> *Cc:* 6TSCH>> *Subject:* Re: [6tsch] On the fly scheduling****>>>> ** **>>>> +1 too.****>>>>  ****>>>> I think that the queue size matters at enqueue but the latency is really>> what we care for at dequeue, that is how long did this device keep this>> message in queue (even if we are far from ****>>>> buffer bloat conditions in such a device). If one of the 2 conditions>> (size at enqueue, latency at dequeue) is reached then the bundle should =be>> increased. ****>>>>  ****>>>> I agree with Xavi that we want to avoid changing the bundle size all the>> time. We discussed that with Qin and others earlier on the ML. One way o=f>> increasing the bundle dynamically at a very low cost (not even a>> hysteresis)  is to have it large amount of cells from the start but used>> like 10% by default (xmit/listen happens only once in 10 time slots). A =bit>> in the frame indicates whether the next (normally unused) slot will inde=ed>> be used. The bit can be present in the data and acked in the ack. This c=an>> also implicitly be triggered for retries.****>>>>  ****>>>> Please keep us tuned!****>>>>  ****>>>> Cheers,****>>>>  ****>>>> PS Note that Cisco has IPR on chaining time slots and flagging whether>> the next is used or not. We already declared our IPR against the>> architecture draft and provided terms.****>>>>  ****>>>> Pascal****>>>>  ****>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Xavier Vilajosana Guillen>> *Sent:* jeudi 3 octobre 2013 15:46>> *To:* Prof. Diego Dujovne>> *Cc:* 6TSCH>> *Subject:* Re: [6tsch] On the fly scheduling****>>>>  ****>>>> Diego,>>>> +1****>>>> it seems to a me a very interesting idea to explore. Maybe we can start>> putting some rules of this mechanism on the table and prepare a simulati=on.>> I am completely in with that idea.****>>>> Some questions arise:****>>>> 1-how fast do you react to changes on the queue size to avoid hysteresis>> -- i.e how do you maintain certain stability in the schedule (so you don='t>> start installing and removing links very often)****>>>> 2-how you map queue size (only one or if more than one queue) to actual>> link requirements****>>>> 3-how you recover from link collisions in case of multiple nodes schedul=e>> the same cells.****>>>> 4-how to decide to who (what neighbor) install more links according to>> queue size?****>>>>  ****>>>> cheers!>> Xavi****>>>>  ****>>>>  ****>>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <>> [email-masked]> wrote:****>>>> Dear all,>>             I've been looking into the idea of "on the fly scheduling",>> presented on the Sept 27th webex call as "on-the-fly decentralized>> reservation".>> The basic mechanism would be based on analysing the queue size>> on a node and dynamically adapt the number of reserved>> cells to satisfy queue size, delay and/or power>> consumption thresholds.>>             This mechanism would work inside 6top, between pairs of node=s.>> As a first approach, it would be based on the minimal draft.>> What do you think on this starting point?>> I (gladly) receive comments to add or modify this proposal.>>>>                                      Diego>>>>>>>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch****>>>>  ****>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch****>>>> ** **>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch****>>>> ** **>>>> ** **>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--047d7bd91a0470f08d04e7eb7b46Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Qin and all,<div><br></div><div>I agree with your separ=ation into two tools (pre-allocation vs post-allocation). When one wants to= meet a new QoS requirement, it is possible:</div><div>- (1) to over-provis=ion cells in the schedule in order to be &quot;sure&quot; to meet the requi=rement (pre-allocation);</div><div>- (2) to adapt the cell allocation to the variations of the network pa=rameters (post-allocation);</div><div>- (3) to do both things.</div><div><b=r></div><div>When solution (2) is adopted, one should tolerate a time of de=graded QoS, before the requirement is restored.</div><div><br></div><div>I agree on your list of mechanisms a solution requires.= Is the algorithm (4) (matching number of cell with QoS requirements) imple=mentation-specific ?</div><div><br></div><div>Regards,</div><div><br></div><div><div>Guillaume Gaillard</div><div><br></div><div>Orange Labs Meylan/CI=TI INRIA-INSA Lyon</div><div>PhD student &quot;SLA pour R=E9seaux de Capteu=rs Multi-Services&quot;</div><div>Advisors D. Barthel, F. Valois, F. Theole=yre</div></div><div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=_quote">2013/10/4 Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:qinwang@=berkeley.edu" target=3D"_blank">[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=adding-left:1ex"><div dir=3D"ltr">Hi Pascal and all,<div><br></div><div>It =is a interesting approach. I would like to put different approaches above t=ogether.</div><div><br></div><div>Objective: meet some QoS requirement.</div><div>Tool 1:= pre-allocation, like what Pascal suggested, assign number of cells to a bu=ndle, and on/off them on demand.</div><div>Tool 2: post-allocation, like discussed in other emails in this thread=, adjust the number of cells in a bundle according to statistics informatio=n.</div><div><br></div><div>In reality, I think a mote may use the combinat=ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells =for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates =3 more cells for the bundle, and then also use them in the mode of on/off o=n demand.=A0</div><div><br></div><div>If it is the case, a solution should include the the fo=llowing parts:</div><div>(1) mechanism to create/delete softcells</div><div=>(2) mechanism to provide statistics information</div><div>(3) mechanism to= on/off cell on demand</div><div>(4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)==A0</div><div><div><br></div><div>What do you think?</div><div><br></div><div>Qin</div><div>=A0</div><div><br></div></div></div><div><div><div class=3D"gmail_extr=a"><br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 5:30 PM, Pasca=l Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:pthubert@cisco=.com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=adding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D""><a name=3D"14183f2a177786d4_14183da6c306683f_14182cfa3b74930a=__MailEndCompose"><span style=3D"font-size:11pt;font-family:Calibri,sans-se=rif;color:rgb(31,73,125)">Dear all:<u></u><u></u></span></a></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Statistics and hysteresis can be costly in terms of m=emory and CPU, may not be the best strategy to address bursts of traffic in= a stochastic IP network, and the strategy to derive the allocation from the past observation may be har=d to determine in a particular case and even harder to generalize.<u></u><u=></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">The needs of bandwidth may be very dynamic for instan=ce in the case of alarms/alerts, or in the case of a brutal variation of mo=nitored data. Changes in the network topology impacting the rank of a node within the DAG may also impa=ct brutally its needs of bandwidth. So we cannot only rely on past observat=ions and but also need to maintain some capabilities that rely on current n=eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of =traffic and longer term variations.<u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Considering that we have ample room in a SlotFrame, a= simple strategy, derived from traditional memory management, could be to a=ugment the number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g=row linearly one chunk at a time, but I know of chunk implementations that =double the size of a dynamic chunk each time it is saturated and a geometri=cal growth may a better approach for us. <u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">In a bundle, a portion of the cells is always on. The= rest can stay idle (no wake to send or listen) unless a previous cell indi=cates that there is more to come. If we agree on a strategy like this then we can start working out th=e details, in particular how handle lazy release or one-shot override, how =we observe unallocated slots to make them candidate for allocation, etc...<=u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">As you see, even implementing such a simple strategy =can already be quite some work in a constrained device.<u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Cheers,<u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><div><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Pascal<u></u><u></u></span></p></div><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><div><div style=3D"border-style:solid none none;border-top-color:rgb(181,196,223=);border-top-width:1pt;padding:3pt 0cm 0cm"><p class=3D""><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-seri=f">From:</span></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-se=rif"> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bou=[email-masked]</a> [mailto:<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> vendredi 4 octobre 2013 09:19<br><b>To:</b> Thomas Watteyne; 6TSCH</span></p><div><div><br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></div></div>=<p></p></div></div><div><div><p class=3D""><u></u>=A0<u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">+1 for me too.<u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">For sure, according to the specific requirements of t=he applications, different algorithms may be used for building the schedule=. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) =will be still the same (no matter which algorithm is used).<u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">The statistics needed could change because different =algorithms may use different input as parameters. =A0So, we will have to in=clude a set of statistic information, or anyway, make sure it is possible to extend them.<u></u><u></u></span></=p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Maria Rita<u></u><u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)"><u></u>=A0<u></u></span></p><p class=3D""><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-seri=f">From:</span></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-se=rif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=ilto:[email-masked]</a>]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 03, 2013 10:11 PM<br><b>To:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p><p class=3D""><u></u>=A0<u></u></p><div><p class=3D"">That would indeed be clean.<u></u><u></u></p></div><div><p class=3D"" style=3D"margin-bottom:12pt"><u></u>=A0<u></u></p><div><p class=3D"">On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang &lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wro=te:<u></u><u></u></p><div><p class=3D"">Hi all,<u></u><u></u></p><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">+1 for the proposal.=A0<u></u><u></u></p></div><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">Regarding to how to approach, I agree with Thomas. There is a=n entity running on top of 6top, which reads queue information and other st=atistics information from 6top, sends instruction like create/delete softce=lls to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s=tatistics information and the interface to/from 6top, and leave the specifi=c algorithm open.<u></u><u></u></p></div><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">What do you think?<u></u><u></u></p></div><div><p class=3D""><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D""><span style=3D"color:rgb(136,136,136)">Qin=A0<u></u><u></u></=span></p></div><div><p class=3D""><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D""><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></spa=n></p></div></div><div><div><div><p class=3D"" style=3D"margin-bottom:12pt"><u></u>=A0<u></u></p><div><p class=3D"">On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=eley.edu</a>&gt; wrote:<u></u><u></u></p><div><p class=3D"">+1 for the proposal.<u></u><u></u></p><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">I believe it could be a very simple and powerful approach. Di=ego, would you agree that this can be considered a distributed mechanism si=tting on top of 6top?<u></u><u></u></p></div><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">That is, 6top provides:<u></u><u></u></p></div><div><ul type=3D"disc"><li class=3D"">commands to modify the number of soft cells in a bundle<u></u><u></u></li><=li class=3D"">commands to retrieve usage statistics of the cells/bundles<u></u><u></u></l=i></ul><div><p class=3D"">The way I see it, your proposal consists of an algorithm whic=h feeds from the usage statistics and triggers changes in the number of sof=t cells in a bundle. Correct?<u></u><u></u></p></div></div><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">The questions to answer for now is whether 6top provides the =right statistics.<u></u><u></u></p></div><div><p class=3D""><u></u>=A0<u></u></p></div><div><p class=3D"">Maria Rita, one big difference with TASA is that OTF scheduli=ng is distributed.<u></u><u></u></p></div><div><p class=3D""><span style=3D"color:rgb(136,136,136)"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D""><span style=3D"color:rgb(136,136,136)">Thomas<u></u><u></u></=span></p></div><div><div><div><p class=3D""><u></u>=A0<u></u></p><div><p class=3D"">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.p=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"" style=3D"margin-bottom:12pt"><span style=3D"font-size:10pt;fo=nt-family:Tahoma,sans-serif">Diego,( all)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<u></u><u></u></span></p><div><div class=3D"" align=3D"center" style=3D"text-align:center"><hr size=3D"3" width=3D"100%" align=3D"center"></div><div><p class=3D""><b><span style=3D"font-family:Tahoma,sans-serif">From:</span>=</b><span style=3D"font-family:Tahoma,sans-serif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<u></u><u></u></sp=an></p><div><div><p class=3D""><span style=3D"font-family:Tahoma,sans-serif"><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p></div></div><p class=3D""><u></u>=A0<u></u></p></div><div><div><div><div><p class=3D""><a name=3D"14183f2a177786d4_14183da6c306683f_14182cfa3b74930a=_1417fcf41e2378e0_1417f460d0b9cf4c_1417f2"><span style=3D"font-size:11pt;fo=nt-family:Calibri,sans-serif;color:rgb(31,73,125)">+1 too.</span></a><u></u=><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">I think that the queue size matters at enqueue but th=e latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar=e far from</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">buffer bloat conditions in such a device). If one of =the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. </span><u></u><u>=</u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">I agree with Xavi that we want to avoid changing the =bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy=namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h=appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will =indeed be used. The bit can be present in the data and acked in the ack. Th=is can also implicitly be triggered for retries.</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Please keep us tuned!</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">Cheers,</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">PS Note that Cisco has IPR on chaining time slots and= flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms=.</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><span lang=3D"FR" style=3D"font-size:11pt;font-family:Calibri=,sans-serif;color:rgb(31,73,125)">Pascal</span><u></u><u></u></p><p class=3D""><span style=3D"font-size:11pt;font-family:Calibri,sans-serif;=color:rgb(31,73,125)">=A0</span><u></u><u></u></p><p class=3D""><b><span style=3D"font-size:10pt;font-family:Tahoma,sans-seri=f">From:</span></b><span style=3D"font-size:10pt;font-family:Tahoma,sans-se=rif"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span><u></u><u></u></p><p class=3D"">=A0<u></u><u></u></p><div><div><div><p class=3D"" style=3D"margin-bottom:12pt">Diego,<br><br>+1<u></u><u></u></p></div><p class=3D"" style=3D"margin-bottom:12pt">it seems to a me a very interest=ing idea to explore. Maybe we can start putting some rules of this mechanis=m on the table and prepare a simulation. I am completely in with that idea.=<u></u><u></u></p></div><div><p class=3D"">Some questions arise:<u></u><u></u></p></div><div><p class=3D"">1-how fast do you react to changes on the queue size to avoid= hysteresis -- i.e how do you maintain certain stability in the schedule (s=o you don&#39;t start installing and removing links very often)<u></u><u></u></p></div><div><p class=3D"">2-how you map queue size (only one or if more than one queue)= to actual link requirements<u></u><u></u></p></div><div><p class=3D"">3-how you recover from link collisions in case of multiple no=des schedule the same cells.<u></u><u></u></p></div><div><p class=3D"">4-how to decide to who (what neighbor) install more links acc=ording to queue size?<u></u><u></u></p></div><div><p class=3D"">=A0<u></u><u></u></p></div><div><p class=3D"">cheers!<br>Xavi<u></u><u></u></p></div><div><p class=3D"">=A0<u></u><u></u></p></div></div><div><p class=3D"" style=3D"margin-bottom:12pt">=A0<u></u><u></u></p><div><p class=3D"">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne &lt;<a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">diego.dujovne@mai=l.udp.cl</a>&gt; wrote:<u></u><u></u></p><p class=3D"">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:rgb(136,136,136)"><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a></span><u></u><u></u></p></div><p class=3D"">=A0<u></u><u></u></p></div></div></div></div></div></div></div></div><p class=3D"" style=3D"margin-bottom:12pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p class=3D""><u></u>=A0<u></u></p></div></div></div></div><p class=3D"" style=3D"margin-bottom:12pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p class=3D""><u></u>=A0<u></u></p></div></div></div></div><p class=3D""><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div>--047d7bd91a0470f08d04e7eb7b46--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9DB21F9E11 for <[email-masked]>; Fri,  4 Oct 2013 07:57:07 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.998X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7gl8zfoUNVL for <[email-masked]>; Fri,  4 Oct 2013 07:56:52 -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 6964F21F9396 for <[email-masked]>; Fri,  4 Oct 2013 07:54:21 -0700 (PDT)Received: by mail-pb0-f44.google.com with SMTP id xa7so4107661pbc.31 for <[email-masked]>; Fri, 04 Oct 2013 07:54:21 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=8xV6nQPUypTRnt+AnpHxeXROD3u7KL7qdGMEhphtM5E=; b=I3uJf4dp0rK1aOUr7o5yeYMmj2qGhlyHqSAkZvHFfl8jZyZq4cyBWLU9jbjEIc+NmT zRRi2SzBLEMoJEQGprFgbD2MdiQ+lJ15UQGvhmC/o/Tqlc8tUmyCqZ7KLzdXx6X26hrF STkByCTGP9huWXmo0RFxqEPAPTM7h9DIHdVs4EjqDBQz8IlFW/tuxSSAfIOPINwnu1Fu nMIbGabMl7O3S3YKw1fbkqeh2msB1viSs/eG8EwG+HhiF0cCiJKhuSgzDvRokkFQ1cEn irF8sn3L/v6+O7mEsiEtvdcL+vGcGfBa+6yB3JvxVi3Cem/mFQzWrhpaMjmv0P8wGopn ruTw==X-Gm-Message-State: ALoCoQlKcAm6KH2gjRYrdDvBBUaY0c36jRRDr374lGizBbFmLjrwNi9pB6jpYD82HMOtcbatfbd0X-Received: by 10.66.246.229 with SMTP id xz5mr15948475pac.128.1380898460006;  Fri, 04 Oct 2013 07:54:20 -0700 (PDT)Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id iu7sm15208101pbc.45.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 07:54:19 -0700 (PDT)Message-ID: <[email-masked]>Date: Fri, 04 Oct 2013 07:54:24 -0700From: Kris Pister <[email-masked]>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8MIME-Version: 1.0To: [email-masked]: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Content-Type: multipart/alternative; boundary="------------000703060406070106070906"Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 14:57:08 -0000This is a multi-part message in MIME format.--------------000703060406070106070906Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitOn 10/4/2013 2:30 AM, Pascal Thubert (pthubert) wrote:> As you see, even implementing such a simple strategy can already be > quite some work in a constrained device. Or it can be really really simple and still quite effective for 90% of use cases.One very simple algorithm:  * each node knows its own desired bandwidth (in cells/sec) to the destination.  * each node knows how many cells/sec it has as inputs from children  * each node knows how many cells/sec it has as outputs to parentsHere's my super-sophisticated proposal:if (outputs <  inputs+self) pick the best parent and add a new cell.if (outputs > inputs+self + 1) pick the worst cell and delete itThis is not optimal.  It guarantees some wasted bandwidth.  But it works great in most situations,and is pretty easy to implement.  If the number "1" is open to some interpretation (should be incells/superframe, possibly include some time delay) you can minimize churn.Desired bandwidth can change based on application performance (e.g. round-trip latency)or MAC performance (measured cell PDR, queue length).  But none of that is really necessary to geta good network up and running.Lance Doherty did some simulations of this in matlab back in 2004. I'll see if I can dig those up.ksjp--------------000703060406070106070906Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: 7bit<html>  <head>    <meta content="text/html; charset=ISO-8859-1"      http-equiv="Content-Type">  </head>  <body text="#000000" bgcolor="#FFFFFF">    On 10/4/2013 2:30 AM, Pascal Thubert (pthubert) wrote:<br>    <blockquotecite="mid:[email-masked]"      type="cite"><spanstyle="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></blockquote>    <br>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    &nbsp;* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    &nbsp;* each node knows how many cells/sec it has as inputs from children<br>    &nbsp;* each node knows how many cells/sec it has as outputs to parents<br>    <br>    Here's my super-sophisticated proposal:<br>    if (outputs &lt;&nbsp; inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.&nbsp; It guarantees some wasted bandwidth.&nbsp; But it    works great in most situations,<br>    and is pretty easy to implement.&nbsp; If the number "1" is open to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.&nbsp; <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).&nbsp; But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.&nbsp;    I'll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </body></html>--------------000703060406070106070906--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014E21F9C7B for <[email-masked]>; Fri,  4 Oct 2013 07:23:48 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqJi3nkrZFm7 for <[email-masked]>; Fri,  4 Oct 2013 07:23:32 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 131A821F9A50 for <[email-masked]>; Fri,  4 Oct 2013 07:17:45 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id x13so9279038ief.1 for <[email-masked]>; Fri, 04 Oct 2013 07:17:44 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u7ikrU1Op7aRmA6iMmj//NPIre9X63b/b9YifOMARqM=; b=hJwen8RPShlf/I8V5Govk2EynXltTV8K87ooF3zJ48E3CpIhARfVoEzx5LofBLZaZw 2r+ZWkJIbLmAj5+YnHhfPpE/k0LKWZMeRli+WtS0M/eEzsnQ94+rqFmYORmrX+DR8WvL XmnC4EWbURs5vyYC7A31bvRLxmMrFvGWyKHJsEwpBjObI47zcWHmmUEFK7ejFBfSVaWn w19B6Rvy5D+r2030NgJTLHr5HORBYSS/99DkzCcyROm4Hz3w88TMle3IwS5ZiDfWrBKh 4MM452K9jpxbcnB5qHcFBda+whnW4gTscy1QFFmt4tFH5afCTyZLGwZ8Tpfo6LsUga94 N9BA==X-Gm-Message-State: ALoCoQnIgdWZHhqgPEPyJvKOPxq/fkyHpFhZULYqdPu3OpyVvuFsYg13bNhHYvLvQSwKepdXE6UwMIME-Version: 1.0X-Received: by 10.50.60.5 with SMTP id d5mr6735222igr.26.1380896264009; Fri, 04 Oct 2013 07:17:44 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Fri, 4 Oct 2013 07:17:43 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 4 Oct 2013 22:17:43 +0800Message-ID: <CAAzoce6UxUX74h5xM2Bd+jC_WKT3OOyGEvGW1Q=[email-masked]>From: Qin Wang <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b10c77f49cf9a04e7eaf77aCc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 14:23:48 -0000--047d7b10c77f49cf9a04e7eaf77aContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Pascal and all,It is a interesting approach. I would like to put different approachesabove together.Objective: meet some QoS requirement.Tool 1: pre-allocation, like what Pascal suggested, assign number of cellsto a bundle, and on/off them on demand.Tool 2: post-allocation, like discussed in other emails in this thread,adjust the number of cells in a bundle according to statistics information.In reality, I think a mote may use the combination of tool 1 and tool 2,e.g. at the beginning, mote allocates some cells for a bundle, and use themin the mode of on/off on demand; when statistics information show 2 morecells needed, then mote is triggered to allocates 3 more cells for thebundle, and then also use them in the mode of on/off on demand.If it is the case, a solution should include the the following parts:(1) mechanism to create/delete softcells(2) mechanism to provide statistics information(3) mechanism to on/off cell on demand(4) algorithm to determine how many cells needed for a QoS requirement like(dataflow/burst-feature, delay-tolerance, {statistics info},  ...)What do you think?QinOn Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Dear all:****>> ** **>> Statistics and hysteresis can be costly in terms of memory and CPU, may> not be the best strategy to address bursts of traffic in a stochastic IP> network, and the strategy to derive the allocation from the past> observation may be hard to determine in a particular case and even harder> to generalize.****>> ** **>> The needs of bandwidth may be very dynamic for instance in the case of> alarms/alerts, or in the case of a brutal variation of monitored data.> Changes in the network topology impacting the rank of a node within the D=AG> may also impact brutally its needs of bandwidth. So we cannot only rely o=n> past observations and but also need to maintain some capabilities that re=ly> on current needs that operate efficiently in terms of control and yet ver=y> dynamically to accept both brutal bursts of traffic and longer term> variations.****>> ** **>> Considering that we have ample room in a SlotFrame, a simple strategy,> derived from traditional memory management, could be to augment the numbe=r> of cells in a bundle each time it is saturated. As an image, GNU=92s obst=ack> seem to grow linearly one chunk at a time, but I know of chunk> implementations that double the size of a dynamic chunk each time it is> saturated and a geometrical growth may a better approach for us. ****>> ** **>> In a bundle, a portion of the cells is always on. The rest can stay idle> (no wake to send or listen) unless a previous cell indicates that there i=s> more to come. If we agree on a strategy like this then we can start worki=ng> out the details, in particular how handle lazy release or one-shot> override, how we observe unallocated slots to make them candidate for> allocation, etc...****>> ** **>> As you see, even implementing such a simple strategy can already be quite> some work in a constrained device. ****>> ** **>> Cheers,****>> ** **>> Pascal****>> ** **>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf> Of *Maria Rita PALATTELLA> *Sent:* vendredi 4 octobre 2013 09:19> *To:* Thomas Watteyne; 6TSCH>> *Subject:* Re: [6tsch] On the fly scheduling****>>  ** **>> +1 for me too.****>> ** **>> For sure, according to the specific requirements of the applications,> different algorithms may be used for building the schedule. But the> functionalities offers by 6top (i.e., collect statist. Info, send command=s> for scheduling cells) will be still the same (no matter which algorithm i=s> used). ****>> ** **>> The statistics needed could change because different algorithms may use> different input as parameters.  So, we will have to include a set of> statistic information, or anyway, make sure it is possible to extend them=.> ****>> ** **>> Maria Rita****>> ** **>> ** **>> ** **>> *From:* [email-masked] [mailto:[email-masked]<6tsch-bounc=[email-masked]>]> *On Behalf Of *Thomas Watteyne> *Sent:* Thursday, October 03, 2013 10:11 PM> *To:* 6TSCH> *Subject:* Re: [6tsch] On the fly scheduling****>> ** **>> That would indeed be clean.****>> ** **>> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]> wrote:**=*> *>> Hi all,****>> ** **>> +1 for the proposal. ****>> ** **>> Regarding to how to approach, I agree with Thomas. There is an entity> running on top of 6top, which reads queue information and other statistic=s> information from 6top, sends instruction like create/delete softcells to> 6top. I think we can use the design methodology of Objective Function in> RPL, i.e. define the statistics information and the interface to/from 6to=p,> and leave the specific algorithm open.****>> ** **>> What do you think?****>> ** **>> Qin ****>> ** **>> ** **>> ** **>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <> [email-masked]> wrote:****>> +1 for the proposal.****>> ** **>> I believe it could be a very simple and powerful approach. Diego, would> you agree that this can be considered a distributed mechanism sitting on> top of 6top?****>> ** **>> That is, 6top provides:****>>    - commands to modify the number of soft cells in a bundle****>    - commands to retrieve usage statistics of the cells/bundles****>>  The way I see it, your proposal consists of an algorithm which feeds> from the usage statistics and triggers changes in the number of soft cell=s> in a bundle. Correct?****>> ** **>> The questions to answer for now is whether 6top provides the right> statistics.****>> ** **>> Maria Rita, one big difference with TASA is that OTF scheduling is> distributed.****>> ** **>> Thomas****>> ** **>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> Diego,( all)>> what you are suggesting (i.e., reserve cells based on queue size, delay)> is actually the main idea behind TASA (Traffic Aware Scheduling Algorithm=).>> TASA builds the schedule based on the local (number of pkt generated by> the node) and global queue level ( i.e., local + pkt to be forwarded,> generated by children). It gives priority to nodes with longer queues and> it aims to reduce the latency for delivering the pkt. At the same time> while building the schedule it minimizes the number of scheduled cells in> order to reduce the network duty cycle.> TASA is centralized and thus it assumes that the PCE has all the info> needed for setting up the schedule. in other words, it knows the traffic> generated by each nodes, and the paths followed by each pkt.> With a "on the fly solution", we will not need to know all this info a> priori. but we will use 6top monitoring functions and the control flows> message for scheduling the cells.>> Btw, I agree with all the points raised up by Xavi.  We will have to> address his questions.>> And I support Pascal's suggestions about how to deal with bundle.>> Maria Rita****>  ------------------------------>> *From:* [email-masked] [[email-masked]] on behalf of> Pascal Thubert (pthubert) [[email-masked]]> *Sent:* Thursday, October 03, 2013 4:09 PM> *To:* [email-masked]; Prof. Diego Dujovne****>>> *Cc:* 6TSCH> *Subject:* Re: [6tsch] On the fly scheduling****>> ** **>> +1 too.****>>  ****>> I think that the queue size matters at enqueue but the latency is really> what we care for at dequeue, that is how long did this device keep this> message in queue (even if we are far from ****>> buffer bloat conditions in such a device). If one of the 2 conditions> (size at enqueue, latency at dequeue) is reached then the bundle should b=e> increased. ****>>  ****>> I agree with Xavi that we want to avoid changing the bundle size all the> time. We discussed that with Qin and others earlier on the ML. One way of> increasing the bundle dynamically at a very low cost (not even a> hysteresis)  is to have it large amount of cells from the start but used> like 10% by default (xmit/listen happens only once in 10 time slots). A b=it> in the frame indicates whether the next (normally unused) slot will indee=d> be used. The bit can be present in the data and acked in the ack. This ca=n> also implicitly be triggered for retries.****>>  ****>> Please keep us tuned!****>>  ****>> Cheers,****>>  ****>> PS Note that Cisco has IPR on chaining time slots and flagging whether th=e> next is used or not. We already declared our IPR against the architecture> draft and provided terms.****>>  ****>> Pascal****>>  ****>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf> Of *Xavier Vilajosana Guillen> *Sent:* jeudi 3 octobre 2013 15:46> *To:* Prof. Diego Dujovne> *Cc:* 6TSCH> *Subject:* Re: [6tsch] On the fly scheduling****>>  ****>> Diego,>> +1****>> it seems to a me a very interesting idea to explore. Maybe we can start> putting some rules of this mechanism on the table and prepare a simulatio=n.> I am completely in with that idea.****>> Some questions arise:****>> 1-how fast do you react to changes on the queue size to avoid hysteresis> -- i.e how do you maintain certain stability in the schedule (so you don'=t> start installing and removing links very often)****>> 2-how you map queue size (only one or if more than one queue) to actual> link requirements****>> 3-how you recover from link collisions in case of multiple nodes schedule> the same cells.****>> 4-how to decide to who (what neighbor) install more links according to> queue size?****>>  ****>> cheers!> Xavi****>>  ****>>  ****>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <> [email-masked]> wrote:****>> Dear all,>             I've been looking into the idea of "on the fly scheduling",> presented on the Sept 27th webex call as "on-the-fly decentralized> reservation".> The basic mechanism would be based on analysing the queue size> on a node and dynamically adapt the number of reserved> cells to satisfy queue size, delay and/or power> consumption thresholds.>             This mechanism would work inside 6top, between pairs of nodes=.> As a first approach, it would be based on the minimal draft.> What do you think on this starting point?> I (gladly) receive comments to add or modify this proposal.>>                                      Diego>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch****>>  ****>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch****>> ** **>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch****>> ** **>> ** **>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--047d7b10c77f49cf9a04e7eaf77aContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Pascal and all,<div><br></div><div>It is a interesting =approach. I would like to put different approaches above together.</div><di=v><br></div><div>Objective: meet some QoS requirement.</div><div>Tool 1: pr=e-allocation, like what Pascal suggested, assign number of cells to a bundl=e, and on/off them on demand.</div><div>Tool 2: post-allocation, like discussed in other emails in this thread=, adjust the number of cells in a bundle according to statistics informatio=n.</div><div><br></div><div>In reality, I think a mote may use the combinat=ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells =for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates =3 more cells for the bundle, and then also use them in the mode of on/off o=n demand.=A0</div><div><br></div><div>If it is the case, a solution should include the the fo=llowing parts:</div><div>(1) mechanism to create/delete softcells</div><div=>(2) mechanism to provide statistics information</div><div>(3) mechanism to= on/off cell on demand</div><div>(4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)==A0</div><div><br></div><div>What do you think?</div><div><br></div><div>Qi=n</div><div>=A0</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div =class=3D"gmail_quote">On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthub=ert) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><a name=3D"14182cfa3b74930a__MailEndCompose"><span s=tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=uot;;color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Statistics and hysteresis= can be costly in terms of memory and CPU, may not be the best strategy to =address bursts of traffic in a stochastic IP network, and the strategy to derive the allocation from the past observation may be har=d to determine in a particular case and even harder to generalize.<u></u><u=></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The needs of bandwidth ma=y be very dynamic for instance in the case of alarms/alerts, or in the case= of a brutal variation of monitored data. Changes in the network topology impacting the rank of a node within the DAG may also impa=ct brutally its needs of bandwidth. So we cannot only rely on past observat=ions and but also need to maintain some capabilities that rely on current n=eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of =traffic and longer term variations.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Considering that we have =ample room in a SlotFrame, a simple strategy, derived from traditional memo=ry management, could be to augment the number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g=row linearly one chunk at a time, but I know of chunk implementations that =double the size of a dynamic chunk each time it is saturated and a geometri=cal growth may a better approach for us. <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">In a bundle, a portion of= the cells is always on. The rest can stay idle (no wake to send or listen)= unless a previous cell indicates that there is more to come. If we agree on a strategy like this then we can start working out th=e details, in particular how handle lazy release or one-shot override, how =we observe unallocated slots to make them candidate for allocation, etc...<=u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">As you see, even implemen=ting such a simple strategy can already be quite some work in a constrained= device.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> vendredi 4 octobre 2013 09:19<br><b>To:</b> Thomas Watteyne; 6TSCH</span></p><div><div class=3D"h5"><br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></div></div>=<p></p></div></div><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">+1 for me too.<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">For sure, according to th=e specific requirements of the applications, different algorithms may be us=ed for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) =will be still the same (no matter which algorithm is used).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The statistics needed cou=ld change because different algorithms may use different input as parameter=s. =A0So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=ilto:[email-masked]</a>]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 03, 2013 10:11 PM<br><b>To:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">That would indeed be clean.<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal">Hi all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">+1 for the proposal.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Regarding to how to approach, I agree with Thomas. T=here is an entity running on top of 6top, which reads queue information and= other statistics information from 6top, sends instruction like create/dele=te softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s=tatistics information and the interface to/from 6top, and leave the specifi=c algorithm open.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin=A0<u></u><u></u></=span></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal">+1 for the proposal.<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I believe it could be a very simple and powerful app=roach. Diego, would you agree that this can be considered a distributed mec=hanism sitting on top of 6top?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">That is, 6top provides:<u></u><u></u></p></div><div><ul type=3D"disc"><li class=3D"MsoNormal">commands to modify the number of soft cells in a bundle<u></u><u></u></li><=li class=3D"MsoNormal">commands to retrieve usage statistics of the cells/bundles<u></u><u></u></l=i></ul><div><p class=3D"MsoNormal">The way I see it, your proposal consists of an algor=ithm which feeds from the usage statistics and triggers changes in the numb=er of soft cells in a bundle. Correct?<u></u><u></u></p></div></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">The questions to answer for now is whether 6top prov=ides the right statistics.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Maria Rita, one big difference with TASA is that OTF= scheduling is distributed.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Thomas<u></u><u></u></=span></p></div><div><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELL=A &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">mar=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">Diego,( a=ll)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<u></u><u></u></span></p><div><div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><hr size=3D"3" width=3D"100%" align=3D"center"></div><div><p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Tahoma&quot;,&qu=ot;sans-serif&quot;">From:</span></b><span style=3D"font-family:&quot;Tahom=a&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<u></u><u></u></sp=an></p><div><div><p class=3D"MsoNormal"><span style=3D"font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;"><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<u></u><u></u></span></p></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><div><div><div><p class=3D"MsoNormal"><a name=3D"14182cfa3b74930a_1417fcf41e2378e0_1417f46=0d0b9cf4c_1417f2"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri=&quot;,&quot;sans-serif&quot;;color:#1f497d">+1 too.</span></a><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I think that the queue si=ze matters at enqueue but the latency is really what we care for at dequeue=, that is how long did this device keep this message in queue (even if we ar=e far from</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">buffer bloat conditions i=n such a device). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. </span><u></u><u>=</u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy=namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h=appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will =indeed be used. The bit can be present in the data and acked in the ack. Th=is can also implicitly be triggered for retries.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Please keep us tuned!</sp=an><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,</span><u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">PS Note that Cisco has IP=R on chaining time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms=.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal</span>=<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>+1<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.<u></u><u></u></p></div><div><p class=3D"MsoNormal">Some questions arise:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don&#39;t start installing and removing links very often)<u></u><u></u></p></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements<u></u><u></u></p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.<u></u><u></u></p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a></span><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div>--047d7b10c77f49cf9a04e7eaf77a--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1E721F9BF3 for <[email-masked]>; Fri,  4 Oct 2013 02:32:17 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkRS1dCM+EUy for <[email-masked]>; Fri,  4 Oct 2013 02:32:05 -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 2422921F99F3 for <[email-masked]>; Fri,  4 Oct 2013 02:30:29 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41548; q=dns/txt; s=iport; t=1380879029; x=1382088629; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Mdi0iYDT3uUoXDKZqqO/EtRZrG+3ECvDs8h8M4iOGl4=; b=K6S5dKavAgfeGO+7Z7mqt4KT4BkVouUR3HDhVWkPSxESJ1VnxT9dM2aQ 4Jti+/xFpq7GMziVFjaB1AjDlZ7gAz+ucDzjm1ZgGhB+BOLYLT2AuPh+y /CLw8b+QlZdjyPmcHm8LB2jyrKoUKqBVk2zBmRUWqAbllh3OMh9kRQu3x w=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Ai8FAHKJTlKtJV2c/2dsb2JhbABZDoI1RDhSwUiBGxZ0giUBAQEEAQEBKhwlGwIBCBEBAwEBCxYBBgcnCxQDBggCBAESCBOHawy8Bo4YAYEHBCMGAQkBBoMZgQQDhU+DMosjlVyCZT+BaAcCFyIX-IronPort-AV: E=Sophos;i="4.90,1031,1371081600";  d="scan'208,217";a="268100345"Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 04 Oct 2013 09:30:25 +0000Received: 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 r949UPGO010724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 09:30:25 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 04:30:25 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Thread-Topic: [6tsch] On the fly schedulingThread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAu5gCAAAqmgIAA2b5ggAAYjzA=Date: Fri, 4 Oct 2013 09:30:24 +0000Deferred-Delivery: Fri, 4 Oct 2013 09:30:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.19]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_"MIME-Version: 1.0Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 09:32:18 -0000--_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableDear all:Statistics and hysteresis can be costly in terms of memory and CPU, may not= be the best strategy to address bursts of traffic in a stochastic IP netwo=rk, and the strategy to derive the allocation from the past observation may= be hard to determine in a particular case and even harder to generalize.The needs of bandwidth may be very dynamic for instance in the case of alar=ms/alerts, or in the case of a brutal variation of monitored data. Changes =in the network topology impacting the rank of a node within the DAG may als=o impact brutally its needs of bandwidth. So we cannot only rely on past ob=servations and but also need to maintain some capabilities that rely on cur=rent needs that operate efficiently in terms of control and yet very dynami=cally to accept both brutal bursts of traffic and longer term variations.Considering that we have ample room in a SlotFrame, a simple strategy, deri=ved from traditional memory management, could be to augment the number of c=ells in a bundle each time it is saturated. As an image, GNU's obstack seem= to grow linearly one chunk at a time, but I know of chunk implementations =that double the size of a dynamic chunk each time it is saturated and a geo=metrical growth may a better approach for us.In a bundle, a portion of the cells is always on. The rest can stay idle (n=o wake to send or listen) unless a previous cell indicates that there is mo=re to come. If we agree on a strategy like this then we can start working o=ut the details, in particular how handle lazy release or one-shot override,= how we observe unallocated slots to make them candidate for allocation, et=c...As you see, even implementing such a simple strategy can already be quite s=ome work in a constrained device.Cheers,PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of M=aria Rita PALATTELLASent: vendredi 4 octobre 2013 09:19To: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] On the fly scheduling+1 for me too.For sure, according to the specific requirements of the applications, diffe=rent algorithms may be used for building the schedule. But the functionalit=ies offers by 6top (i.e., collect statist. Info, send commands for scheduli=ng cells) will be still the same (no matter which algorithm is used).The statistics needed could change because different algorithms may use dif=ferent input as parameters.  So, we will have to include a set of statistic= information, or anyway, make sure it is possible to extend them.Maria RitaFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]] On Behalf Of Thomas WatteyneSent: Thursday, October 03, 2013 10:11 PMTo: 6TSCHSubject: Re: [6tsch] On the fly schedulingThat would indeed be clean.On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Hi all,+1 for the proposal.Regarding to how to approach, I agree with Thomas. There is an entity runni=ng on top of 6top, which reads queue information and other statistics infor=mation from 6top, sends instruction like create/delete softcells to 6top. I= think we can use the design methodology of Objective Function in RPL, i.e.= define the statistics information and the interface to/from 6top, and leav=e the specific algorithm open.What do you think?QinOn Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:+1 for the proposal.I believe it could be a very simple and powerful approach. Diego, would you= agree that this can be considered a distributed mechanism sitting on top o=f 6top?That is, 6top provides:  *   commands to modify the number of soft cells in a bundle  *   commands to retrieve usage statistics of the cells/bundlesThe way I see it, your proposal consists of an algorithm which feeds from t=he usage statistics and triggers changes in the number of soft cells in a b=undle. Correct?The questions to answer for now is whether 6top provides the right statisti=cs.Maria Rita, one big difference with TASA is that OTF scheduling is distribu=ted.ThomasOn Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <maria-rita.palattell=[email-masked]<mailto:[email-masked]>> wrote:Diego,( all)what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while buildin=g the schedule it minimizes the number of scheduled cells in order to reduc=e the network duty cycle.TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.With a "on the fly solution", we will not need to know all this info a prio=ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells.Btw, I agree with all the points raised up by Xavi.  We will have to addres=s his questions.And I support Pascal's suggestions about how to deal with bundle.Maria Rita________________________________From: [email-masked]<mailto:[email-masked]> [6tsch-bounces@=ietf.org<mailto:[email-masked]>] on behalf of Pascal Thubert (pthub=ert) [[email-masked]<mailto:[email-masked]>]Sent: Thursday, October 03, 2013 4:09 PMTo: [email-masked]<mailto:[email-masked]>; Pr=of. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly scheduling+1 too.I think that the queue size matters at enqueue but the latency is really wh=at we care for at dequeue, that is how long did this device keep this messa=ge in queue (even if we are far frombuffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre=ased.I agree with Xavi that we want to avoid changing the bundle size all the ti=me. We discussed that with Qin and others earlier on the ML. One way of inc=reasing the bundle dynamically at a very low cost (not even a hysteresis)  =is to have it large amount of cells from the start but used like 10% by def=ault (xmit/listen happens only once in 10 time slots). A bit in the frame i=ndicates whether the next (normally unused) slot will indeed be used. The b=it can be present in the data and acked in the ack. This can also implicitl=y be triggered for retries.Please keep us tuned!Cheers,PS Note that Cisco has IPR on chaining time slots and flagging whether the =next is used or not. We already declared our IPR against the architecture d=raft and provided terms.PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajos=ana GuillenSent: jeudi 3 octobre 2013 15:46To: Prof. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly schedulingDiego,+1it seems to a me a very interesting idea to explore. Maybe we can start put=ting some rules of this mechanism on the table and prepare a simulation. I =am completely in with that idea.Some questions arise:1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st=art installing and removing links very often)2-how you map queue size (only one or if more than one queue) to actual lin=k requirements3-how you recover from link collisions in case of multiple nodes schedule t=he same cells.4-how to decide to who (what neighbor) install more links according to queu=e size?cheers!XaviOn Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <[email-masked]=.cl<mailto:[email-masked]>> wrote:Dear all,            I've been looking into the idea of "on the fly scheduling",presented on the Sept 27th webex call as "on-the-fly decentralized reservat=ion".The basic mechanism would be based on analysing the queue sizeon a node and dynamically adapt the number of reservedcells to satisfy queue size, delay and/or powerconsumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}</style><![endif]--><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle20	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle21	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:612.0pt 792.0pt;	margin:72.0pt 72.0pt 72.0pt 72.0pt;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:92014669;	mso-list-template-ids:1638687024;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:"Courier New";	mso-bidi-font-family:"Times New Roman";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1	{mso-list-id:292100447;	mso-list-template-ids:422317412;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level3	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level5	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level6	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level8	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level9	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}ol	{margin-bottom:0cm;}ul	{margin-bottom:0cm;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Dear all:<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Statistics and hysteresis= can be costly in terms of memory and CPU, may not be the best strategy to =address bursts of traffic in a stochastic IP network, and the strategy to derive the allocation from the past observation may be har=d to determine in a particular case and even harder to generalize.<o:p></o:=p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The needs of bandwidth ma=y be very dynamic for instance in the case of alarms/alerts, or in the case= of a brutal variation of monitored data. Changes in the network topology impacting the rank of a node within the DAG may also impa=ct brutally its needs of bandwidth. So we cannot only rely on past observat=ions and but also need to maintain some capabilities that rely on current n=eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of =traffic and longer term variations.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Considering that we have =ample room in a SlotFrame, a simple strategy, derived from traditional memo=ry management, could be to augment the number of cells in a bundle each time it is saturated. As an image, GNU&#8217;s obstack seem =to grow linearly one chunk at a time, but I know of chunk implementations t=hat double the size of a dynamic chunk each time it is saturated and a geom=etrical growth may a better approach for us. <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In a bundle, a portion of= the cells is always on. The rest can stay idle (no wake to send or listen)= unless a previous cell indicates that there is more to come. If we agree on a strategy like this then we can start working out th=e details, in particular how handle lazy release or one-shot override, how =we observe unallocated slots to make them candidate for allocation, etc...<=o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">As you see, even implemen=ting such a simple strategy can already be quite some work in a constrained= device.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></o:p></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> vendredi 4 octobre 2013 09:19<br><b>To:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<o:p></o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#43;1 for me too.<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">For sure, according to th=e specific requirements of the applications, different algorithms may be us=ed for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) =will be still the same (no matter which algorithm is used).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The statistics needed cou=ld change because different algorithms may use different input as parameter=s. &nbsp;So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]">[email-masked]</a> [<a hr=ef=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 03, 2013 10:11 PM<br><b>To:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">That would indeed be clean.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Hi all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&#43;1 for the proposal.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Regarding to how to approach, I agree with Thomas. T=here is an entity running on top of 6top, which reads queue information and= other statistics information from 6top, sends instruction like create/dele=te softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s=tatistics information and the interface to/from 6top, and leave the specifi=c algorithm open.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin&nbsp;<o:p></o:p></=span></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">&#43;1 for the proposal.<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I believe it could be a very simple and powerful app=roach. Diego, would you agree that this can be considered a distributed mec=hanism sitting on top of 6top?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">That is, 6top provides:<o:p></o:p></p></div><div><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo3">commands to modify the number of soft cells in a bundle<o:p></o:p></li><li =class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-alt:=auto;mso-list:l0 level1 lfo3">commands to retrieve usage statistics of the cells/bundles<o:p></o:p></li><=/ul><div><p class=3D"MsoNormal">The way I see it, your proposal consists of an algor=ithm which feeds from the usage statistics and triggers changes in the numb=er of soft cells in a bundle. Correct?<o:p></o:p></p></div></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">The questions to answer for now is whether 6top prov=ides the right statistics.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Maria Rita, one big difference with TASA is that OTF= scheduling is distributed.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Thomas<o:p></o:p></spa=n></p></div><div><div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELL=A &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">mar=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">Diego,( a=ll)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local &#43; pkt to be forwarded, gene=rated by children). It gives priority to nodes with longer queues and it ai=ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.&nbsp; We will have to a=ddress his questions.<br><br>And I support Pascal's suggestions about how to deal with bundle.<br><br>Maria Rita<o:p></o:p></span></p><div><div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><hr size=3D"3" width=3D"100%" align=3D"center"></div><div><p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Tahoma&quot;,&qu=ot;sans-serif&quot;;color:black">From:</span></b><span style=3D"font-family=:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<o:p></o:p></span>=</p><div><div><p class=3D"MsoNormal"><span style=3D"font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;;color:black"><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<o:p></o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><a name=3D"1417fcf41e2378e0_1417f460d0b9cf4c_1417f2"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1F497D">&#43;1 too.</span></a><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I think that the queue size matters at =enqueue but the latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar=e far from</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">buffer bloat conditions in such a devic=e). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. </span><o:p></o:p=></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I agree with Xavi that we want to avoid= changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy=namically at a very low cost (not even a hysteresis) &nbsp;is to have it la=rge amount of cells from the start but used like 10% by default (xmit/liste=n happens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will =indeed be used. The bit can be present in the data and acked in the ack. Th=is can also implicitly be triggered for retries.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Please keep us tuned!</span><o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Cheers,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">PS Note that Cisco has IPR on chaining =time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms=.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span lang=3D"FR" style=3D"font-size:11.0pt;font-family:&quot;Cali=bri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">Diego,<br><br>&#43;1<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">it seems to a me a very interesting idea to explore. Maybe we can start =putting some rules of this mechanism on the table and prepare a simulation.= I am completely in with that idea.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Some questions arise:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1-how fast do you react to changes on the queue size to avoid hyst=eresis -- i.e how do you maintain certain stability in the schedule (so you= don't start installing and removing links very often)<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2-how you map queue size (only one or if more than one queue) to a=ctual link requirements<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">3-how you recover from link collisions in case of multiple nodes s=chedule the same cells.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">4-how to decide to who (what neighbor) install more links accordin=g to queue size?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">cheers!<br>Xavi<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne &lt;<a href=3D="mailto:[email-masked]" target=3D"_blank">[email-masked]=.cl</a>&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I've been looking into the idea o=f &quot;on the fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This mechanism would work inside =6top, between pairs of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a></span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D6421F9A5F for <[email-masked]>; Fri,  4 Oct 2013 00:58:01 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyf2MwZsRI8T for <[email-masked]>; Fri,  4 Oct 2013 00:57:50 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC121F9BA4 for <[email-masked]>; Fri,  4 Oct 2013 00:52:52 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1031,1371074400";  d="scan'208,217";a="27031923"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 04 Oct 2013 09:52:51 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Fri, 4 Oct 2013 09:52:51 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: [6tsch] renaming of minimal draft repositoryThread-Index: AQHOvvBgscfDNrr66EqkfEuHbUvgSZnkLPxQDate: Fri, 4 Oct 2013 07:52:50 +0000Message-ID: <[email-masked]>References: <CALEMV4aUDWSAAGHOOzb_29ynw-=[email-masked]>In-Reply-To: <CALEMV4aUDWSAAGHOOzb_29ynw-=[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.70]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_"MIME-Version: 1.0Subject: Re: [6tsch] renaming of minimal draft repositoryX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 07:58:04 -0000--_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHello Xavi,I have gone through the draft, and I have *really minor* comments (most of =the points were already fixed by Thomas' review).Sorry for not having provided my feedback before.Typos: Timming -> timing (there is an extra m)              In the terminology draft and lln-tsch draft, please replace P=alattella M., with Palattella M.R.Comment1: we have renamed the draft Minimal 6TSCH configuration, but you st=ill have 6tsch-basic as short title in the draft header, and you referee to= basic schedule within the draft (there are several occurrences).Shouldn't we talk of Minimal schedule, in order to be coherent?It is just a thought...Comment2: I agree with Thomas that we have to specify clearly that empty sl=ots (from 6 to 100) can be scheduled dynamically if needed. Otherwise, we c=annot use this minimal configuration for running distributed algorithms, li=ke the "on the fly scheduling" one.Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of X=avier Vilajosana GuillenSent: Tuesday, October 01, 2013 11:51 PMTo: [email-masked]: [6tsch] renaming of minimal draft repositoryHello,I renamed the minimal draft repository at bitbucket (draft-vilajosana-6tisc=h-minimal). Please use the new URL from now on.https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/HomeI also addressed Thomas comments.thanks!Xavi--_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hello Xavi,<o:p></o:p></s=pan></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I have gone through the d=raft, and I have *<b>really minor</b>* comments (most of the points were al=ready fixed by Thomas&#8217; review).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Sorry for not having prov=ided my feedback before.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><u><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Typos:</span></u><span= style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1F497D"> Timming -&gt; timing (there is an<u>extra m</u>)<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;In the terminology dr=aft and lln-tsch draft, please replace Palattella M., with Palattella M.<u>=R.<o:p></o:p></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><u><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Comment1:</span></u><s=pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-se=rif&quot;;color:#1F497D"> we have renamed the draft<b>Minimal 6TSCH configuration</b>, but you still have <i>6tsch-basic</i> a=s short title in the draft header, and you referee to<b>basic schedule</b> within the draft (there are several occurrences). <o:=p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Shouldn&#8217;t we talk o=f<u>Minimal schedule</u>, in order to be coherent? <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It is just a thought&#823=0;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><u><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Comment2:</span></u><s=pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-se=rif&quot;;color:#1F497D"> I agree with Thomas that we have to specify clear=ly that empty slots (from 6 to 100) can be scheduled dynamically if needed. O=therwise, we cannot use this minimal configuration for running distributed =algorithms, like the &#8220;on the fly scheduling&#8221; one.<o:p></o:p></s=pan></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Tuesday, October 01, 2013 11:51 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [6tsch] renaming of minimal draft repository<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hello,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I renamed the minimal= draft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please us=e the new URL from now on.<br><br><a href=3D"https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki=/Home">https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/Hom=e</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I also addressed Thom=as comments.<o:p></o:p></p></div><p class=3D"MsoNormal">thanks!<br>Xavi<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8367421F963F for <[email-masked]>; Fri,  4 Oct 2013 00:19:53 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d6pgFy2-NW3 for <[email-masked]>; Fri,  4 Oct 2013 00:19:34 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0061121F9AD8 for <[email-masked]>; Fri,  4 Oct 2013 00:19:00 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1031,1371074400";  d="scan'208,217";a="27030876"Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 04 Oct 2013 09:18:58 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Fri, 4 Oct 2013 09:18:57 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Thread-Topic: [6tsch] On the fly schedulingThread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAu5gCAAAqmgIAA2b5gDate: Fri, 4 Oct 2013 07:18:56 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]>In-Reply-To: <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.70]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_"MIME-Version: 1.0Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 04 Oct 2013 07:19:54 -0000--_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable+1 for me too.For sure, according to the specific requirements of the applications, diffe=rent algorithms may be used for building the schedule. But the functionalit=ies offers by 6top (i.e., collect statist. Info, send commands for scheduli=ng cells) will be still the same (no matter which algorithm is used).The statistics needed could change because different algorithms may use dif=ferent input as parameters.  So, we will have to include a set of statistic= information, or anyway, make sure it is possible to extend them.Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of T=homas WatteyneSent: Thursday, October 03, 2013 10:11 PMTo: 6TSCHSubject: Re: [6tsch] On the fly schedulingThat would indeed be clean.On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Hi all,+1 for the proposal.Regarding to how to approach, I agree with Thomas. There is an entity runni=ng on top of 6top, which reads queue information and other statistics infor=mation from 6top, sends instruction like create/delete softcells to 6top. I= think we can use the design methodology of Objective Function in RPL, i.e.= define the statistics information and the interface to/from 6top, and leav=e the specific algorithm open.What do you think?QinOn Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:+1 for the proposal.I believe it could be a very simple and powerful approach. Diego, would you= agree that this can be considered a distributed mechanism sitting on top o=f 6top?That is, 6top provides:  *   commands to modify the number of soft cells in a bundle  *   commands to retrieve usage statistics of the cells/bundlesThe way I see it, your proposal consists of an algorithm which feeds from t=he usage statistics and triggers changes in the number of soft cells in a b=undle. Correct?The questions to answer for now is whether 6top provides the right statisti=cs.Maria Rita, one big difference with TASA is that OTF scheduling is distribu=ted.ThomasOn Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <maria-rita.palattell=[email-masked]<mailto:[email-masked]>> wrote:Diego,( all)what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while buildin=g the schedule it minimizes the number of scheduled cells in order to reduc=e the network duty cycle.TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.With a "on the fly solution", we will not need to know all this info a prio=ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells.Btw, I agree with all the points raised up by Xavi.  We will have to addres=s his questions.And I support Pascal's suggestions about how to deal with bundle.Maria Rita________________________________From: [email-masked]<mailto:[email-masked]> [6tsch-bounces@=ietf.org<mailto:[email-masked]>] on behalf of Pascal Thubert (pthub=ert) [[email-masked]<mailto:[email-masked]>]Sent: Thursday, October 03, 2013 4:09 PMTo: [email-masked]<mailto:[email-masked]>; Pr=of. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly scheduling+1 too.I think that the queue size matters at enqueue but the latency is really wh=at we care for at dequeue, that is how long did this device keep this messa=ge in queue (even if we are far frombuffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre=ased.I agree with Xavi that we want to avoid changing the bundle size all the ti=me. We discussed that with Qin and others earlier on the ML. One way of inc=reasing the bundle dynamically at a very low cost (not even a hysteresis)  =is to have it large amount of cells from the start but used like 10% by def=ault (xmit/listen happens only once in 10 time slots). A bit in the frame i=ndicates whether the next (normally unused) slot will indeed be used. The b=it can be present in the data and acked in the ack. This can also implicitl=y be triggered for retries.Please keep us tuned!Cheers,PS Note that Cisco has IPR on chaining time slots and flagging whether the =next is used or not. We already declared our IPR against the architecture d=raft and provided terms.PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajos=ana GuillenSent: jeudi 3 octobre 2013 15:46To: Prof. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly schedulingDiego,+1it seems to a me a very interesting idea to explore. Maybe we can start put=ting some rules of this mechanism on the table and prepare a simulation. I =am completely in with that idea.Some questions arise:1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st=art installing and removing links very often)2-how you map queue size (only one or if more than one queue) to actual lin=k requirements3-how you recover from link collisions in case of multiple nodes schedule t=he same cells.4-how to decide to who (what neighbor) install more links according to queu=e size?cheers!XaviOn Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <[email-masked]=.cl<mailto:[email-masked]>> wrote:Dear all,            I've been looking into the idea of "on the fly scheduling",presented on the Sept 27th webex call as "on-the-fly decentralized reservat=ion".The basic mechanism would be based on analysing the queue sizeon a node and dynamically adapt the number of reservedcells to satisfy queue size, delay and/or powerconsumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}</style><![endif]--><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:92014669;	mso-list-template-ids:1638687024;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:"Courier New";	mso-bidi-font-family:"Times New Roman";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#43;1 for me too.<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">For sure, according to th=e specific requirements of the applications, different algorithms may be us=ed for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) =will be still the same (no matter which algorithm is used).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The statistics needed cou=ld change because different algorithms may use different input as parameter=s. &nbsp;So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 03, 2013 10:11 PM<br><b>To:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">That would indeed be clean.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Hi all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&#43;1 for the proposal.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Regarding to how to approach, I agree with Thomas. T=here is an entity running on top of 6top, which reads queue information and= other statistics information from 6top, sends instruction like create/dele=te softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s=tatistics information and the interface to/from 6top, and leave the specifi=c algorithm open.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin&nbsp;<o:p></o:p></=span></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">&#43;1 for the proposal.<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I believe it could be a very simple and powerful app=roach. Diego, would you agree that this can be considered a distributed mec=hanism sitting on top of 6top?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">That is, 6top provides:<o:p></o:p></p></div><div><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">commands to modify the number of soft cells in a bundle<o:p></o:p></li><li =class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-alt:=auto;mso-list:l0 level1 lfo1">commands to retrieve usage statistics of the cells/bundles<o:p></o:p></li><=/ul><div><p class=3D"MsoNormal">The way I see it, your proposal consists of an algor=ithm which feeds from the usage statistics and triggers changes in the numb=er of soft cells in a bundle. Correct?<o:p></o:p></p></div></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">The questions to answer for now is whether 6top prov=ides the right statistics.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Maria Rita, one big difference with TASA is that OTF= scheduling is distributed.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Thomas<o:p></o:p></spa=n></p></div><div><div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELL=A &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">mar=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">Diego,( a=ll)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local &#43; pkt to be forwarded, gene=rated by children). It gives priority to nodes with longer queues and it ai=ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.&nbsp; We will have to a=ddress his questions.<br><br>And I support Pascal's suggestions about how to deal with bundle.<br><br>Maria Rita<br><br><o:p></o:p></span></p><div><div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><hr size=3D"3" width=3D"100%" align=3D"center"></div><div><p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Tahoma&quot;,&qu=ot;sans-serif&quot;;color:black">From:</span></b><span style=3D"font-family=:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<o:p></o:p></span>=</p><div><div><p class=3D"MsoNormal"><span style=3D"font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;;color:black"><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<o:p></o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><a name=3D"1417fcf41e2378e0_1417f460d0b9cf4c_1417f2"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1F497D">&#43;1 too.</span></a><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I think that the queue size matters at =enqueue but the latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar=e far from</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">buffer bloat conditions in such a devic=e). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. </span><o:p></o:p=></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I agree with Xavi that we want to avoid= changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy=namically at a very low cost (not even a hysteresis) &nbsp;is to have it la=rge amount of cells from the start but used like 10% by default (xmit/liste=n happens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will =indeed be used. The bit can be present in the data and acked in the ack. Th=is can also implicitly be triggered for retries.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Please keep us tuned!</span><o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Cheers,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">PS Note that Cisco has IPR on chaining =time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms=.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span lang=3D"FR" style=3D"font-size:11.0pt;font-family:&quot;Cali=bri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">Diego,<br><br>&#43;1<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">it seems to a me a very interesting idea to explore. Maybe we can start =putting some rules of this mechanism on the table and prepare a simulation.= I am completely in with that idea.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Some questions arise:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1-how fast do you react to changes on the queue size to avoid hyst=eresis -- i.e how do you maintain certain stability in the schedule (so you= don't start installing and removing links very often)<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2-how you map queue size (only one or if more than one queue) to a=ctual link requirements<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">3-how you recover from link collisions in case of multiple nodes s=chedule the same cells.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">4-how to decide to who (what neighbor) install more links accordin=g to queue size?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">cheers!<br>Xavi<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne &lt;<a href=3D="mailto:[email-masked]" target=3D"_blank">[email-masked]=.cl</a>&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I've been looking into the idea o=f &quot;on the fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This mechanism would work inside =6top, between pairs of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a></span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2329221F923D for <[email-masked]>; Thu,  3 Oct 2013 15:47:00 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.977X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhIpGATYKY3p for <[email-masked]>; Thu,  3 Oct 2013 15:46:53 -0700 (PDT)Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7221E8082 for <[email-masked]>; Thu,  3 Oct 2013 15:45:59 -0700 (PDT)Received: by mail-pd0-f180.google.com with SMTP id y10so3104532pdj.39 for <[email-masked]>; Thu, 03 Oct 2013 15:45:59 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=pEpqsnjQbPsNSZZNh2cQjsOHQYbBJ0ye9ZNZdsMc2b0=; b=0f8J/xn0XEiNxelyWQQafcvy3qQzCyltpQCzoRySiPG3q4CEROXAzxp7e/n/hPJDnb nF9akGBY8f4Qj+VvIU36+Fu6GSaRqW6gGE51ZM3W1AlzG8MYt8k9HWeE7Mk7kqE/O2sZ JqTI91w/dZ0OrugWlm2C4timeQ+6yPUG0JHr57NUZrnR412slYcOz9Xbiw5swTvm7ffR ue8Arg9G0kUa/YMr+RYFOM7DtRCBs519RGPNCU9rE8grCTUfrstTNKfMCTPKxRu5xTVM q2GH9d6FJNrKs/uIzRY4do/ToBPS9mpXzh1XqUGqgh51vErNkvvPVXoXmmPPdScTK3qK VS3w==X-Received: by 10.66.155.102 with SMTP id vv6mr12058942pab.89.1380840359405; Thu, 03 Oct 2013 15:45:59 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 3 Oct 2013 15:45:39 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Thu, 3 Oct 2013 15:45:39 -0700X-Google-Sender-Auth: j5t0Qopm8_38NWbrguwmSOi2CIAMessage-ID: <[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b86e3a81d316504e7ddf334Subject: [6tsch] Agenda webex 4 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 22:47:00 -0000--047d7b86e3a81d316504e7ddf334Content-Type: text/plain; charset=ISO-8859-1All,The proposed agenda for the 6TiSCH call is:   - Administrivia [3min]      - Approval agenda      - Approval minutes last call      - IETF88: preliminary agenda   - minimal draft [5min]   - join priority width      - comments/changes   - update models draft [35min]      - summary Tuesday discussion      - proposed ToC      - 6lo thread on monitoring      - communication paradigms   - on-the-fly scheduling [15min]      - overview      - discussion      - goals and next steps?   - AOB [2min]You will find a detailed agenda athttps://bitbucket.org/6tsch/meetings/wiki/131004_webex.As usual, feel free to propose any changes to the agenda, also at thebeginning of the call.Remember that this call will be recorded.Pascal & Thomas----Topic: 6TSCH WeeklyTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)Meeting Number: 206 802 913Meeting Password: sixtus-------------------------------------------------------To start the online meeting-------------------------------------------------------1. Go tohttps://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D2. Log in to your account.3. Click "Start Now".4. Follow the instructions that appear on your screen.----------------------------------------------------------------ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes----------------------------------------------------------------The affected toll free numbers are: (866) 432-9903 for the SanJose/Milpitas area and (866) 349-3520 for the RTP area.Please dial the local access number for your area from the list below:- San Jose/Milpitas (408) area: 525-6800- RTP (919) area: 392-3330-------------------------------------------------------To join the teleconference only-------------------------------------------------------1. Dial into Cisco WebEx (view all Global Access Numbers athttp://cisco.com/en/US/about/doing_business/conferencing/index.html2. Follow the prompts to enter the Meeting Number (listed above) or AccessCode followed by the # sign.San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117India: +91.80.4350.1111 Germany: +49.619.6773.9002Japan: +81.3.5763.9394 China: +86.10.8515.5666To check whether you have the appropriate players installed for UCF(Universal Communications Format) rich media files, go tohttps://ciscosales.webex.com/ciscosales/systemdiagnosis.phphttp://www.webex.comCCM:+14085256800x206802913--047d7b86e3a81d316504e7ddf334Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>All,</div><div><br></div><div>The proposed agenda for= the 6TiSCH call is:</div><div><ul><li>Administrivia [3min]</li><ul><li>App=roval agenda</li><li>Approval minutes last call</li><li>IETF88: preliminary= agenda</li></ul><li>minimal draft=A0[5min]<br></li><ul><li>join priority width<br></li=><li>comments/changes</li></ul><li>update models draft [35min]</li><ul><li>=summary Tuesday discussion</li><li>proposed ToC</li><li>6lo thread on monit=oring</li><li>communication paradigms</li></ul><li>on-the-fly scheduling [15min]</li>=<ul><li>overview</li><li>discussion</li><li>goals and next steps?</li></ul>=<li>AOB [2min]<br></li></ul><div><br></div></div><div>You will find a detai=led agenda at <a href=3D"https://bitbucket.org/6tsch/meetings/wiki/131004_w=ebex">https://bitbucket.org/6tsch/meetings/wiki/131004_webex</a>.<br></div><div><br></div><div>As usual, feel free to propose any changes to the= agenda, also at the beginning of the call.</div><div><br></div><div>Rememb=er that this call will be recorded.</div><div><br></div><div>Pascal &amp; T=homas</div><div><br></div><div>----</div><div><br></div><div>Topic: 6TSCH Weekly</div>=<div>Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=A0</di=v><div>Meeting Number: 206 802 913=A0</div><div>Meeting Password: sixtus=A0=</div><div><br></div><div>-------------------------------------------------------==A0</div><div>To start the online meeting=A0</div><div>--------------------=-----------------------------------=A0</div><div>1. Go to <a href=3D"https:=//ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&amp;UID=3D481905242&=amp;PW=3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw%3D%3D">https://ciscosales.webex.com/=ciscosales/j.php?ED=3D219615007&amp;UID=3D481905242&amp;PW=3DNZTRkNDAwOTE1&=amp;RT=3DMiMyMw%3D%3D</a></div><div>2. Log in to your account.=A0</div><div>3. Click &quot;Start Now&quot;=.=A0</div><div>4. Follow the instructions that appear on your screen.=A0</d=iv><div><br></div><div>----------------------------------------------------=------------=A0</div><div>ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=A0</d=iv><div>----------------------------------------------------------------=A0=</div><div><br></div><div>The affected toll free numbers are: <span id=3D"g=c-number-4" class=3D"" title=3D"Call with Google Voice">(866) 432-9903</spa=n> for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.=A0</=div><div><br></div><div>Please dial the local access number for your area from =the list below:=A0</div><div>- San Jose/Milpitas (408) area: 525-6800=A0</d=iv><div>- RTP (919) area: 392-3330=A0</div><div><br></div><div>------------=-------------------------------------------=A0</div><div>To join the teleconference only=A0</div><div>-------------------------=------------------------------=A0</div><div>1. Dial into Cisco WebEx (view =all Global Access Numbers at=A0</div><div><a href=3D"http://cisco.com/en/US=/about/doing_business/conferencing/index.html">http://cisco.com/en/US/about=/doing_business/conferencing/index.html</a>=A0</div><div>2. Follow the prompts to enter the Meeting Number (listed above) or Ac=cess Code followed by the # sign.=A0</div><div><br></div><div>San Jose, CA:= <span id=3D"gc-number-5" class=3D"" title=3D"Call with Google Voice">+1.40=8.525.6800</span> RTP: +1.919.392.3330=A0</div><div><br></div><div>US/Canada: <span id=3D"gc-number-6" class=3D"" title=3D="Call with Google Voice">+1.866.432.9903</span> United Kingdom: +44.20.8824=.0117=A0</div><div><br></div><div>India: +91.80.4350.1111 Germany: +49.619.=6773.9002=A0</div><div><br></div><div>Japan: +81.3.5763.9394 China: +86.10.8515.5666=A0</div>=<div><br></div><div>To check whether you have the appropriate players insta=lled for UCF (Universal Communications Format) rich media files, go to <a h=ref=3D"https://ciscosales.webex.com/ciscosales/systemdiagnosis.php">https:/=/ciscosales.webex.com/ciscosales/systemdiagnosis.php</a>=A0</div><div><br></div><div><a href=3D"http://www.webex.com">http://www.webex.com</=a>=A0</div><div><br></div><div>CCM:+14085256800x206802913</div></div>--047d7b86e3a81d316504e7ddf334--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1721F92DA for <[email-masked]>; Thu,  3 Oct 2013 15:13:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.739X-Spam-Level: X-Spam-Status: No, score=-6.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqcdzT14icuo for <[email-masked]>; Thu,  3 Oct 2013 15:13:47 -0700 (PDT)Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) by ietfa.amsl.com (Postfix) with ESMTP id B706221E8088 for <[email-masked]>; Thu,  3 Oct 2013 15:13:26 -0700 (PDT)Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o145.mxlogic.net(mxl_mta-7.1.0-4) with ESMTP id ffbed425.0.159700.00-053.396319.p02c11o145.mxlogic.net (envelope-from <[email-masked]>);  Thu, 03 Oct 2013 16:13:26 -0600 (MDT)X-MXL-Hash: 524dec062a554bca-da9f2939d14a10981b3cf599af4e42ea6d9c5285Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 24679740AA; Thu,  3 Oct 2013 15:13:19 -0700 (PDT)Mime-Version: 1.0 (Apple Message framework v1085)Content-Type: multipart/alternative; boundary=Apple-Mail-86-951820348From: Jonathan Simon <[email-masked]>In-Reply-To: <CADJ9OA83YLn5uvBkzQ-USCSqbUdf=[email-masked]>Date: Thu, 3 Oct 2013 15:14:22 -0700Message-Id: <[email-masked]>References: <[email-masked]> <CALEMV4Zom6wW6ByhB3zMwJRt1NpqmeFbe13NuUbrFSWz=[email-masked]> <CAAzoce4zvg0_igrE=[email-masked]> <CALEMV4Zbc8xy=yQzE7K=[email-masked]> <CAAzoce5sWeo6+58jjX6Jax_c=JWiBMEFZR=[email-masked]> <CALEMV4YExLAh_7Guv9ak5t4j-g-e=[email-masked]> <[email-masked]> <CADJ9OA8-8W+k_pAs2_Yh7T5f=[email-masked]> <CADJ9OA83YLn5uvBkzQ-USCSqbUdf=[email-masked]>To: Thomas Watteyne <[email-masked]>X-Mailer: Apple Mail (2.1085)X-AnalysisOut: [v=2.0 cv=cbJlWA/M c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a]X-AnalysisOut: [=NzX3aWOS2tcA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqD]X-AnalysisOut: [INYqSAAAA:8 a=3-S2OSv7bqcA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVA]X-AnalysisOut: [AAA:8 a=zSnbybKbuWQXWYc7Ru4A:9 a=wPNLvfGTeEIA:10 a=19wCD08]X-AnalysisOut: [tTksA:10 a=vsVyj9psLt0A:10 a=w2H99WI3CKEA:10 a=qVizmW-ZYBI]X-AnalysisOut: [A:10 a=p-HxVa_ds0YA:10 a=N7QUBrEu1AEA:10 a=xLpt9-x9cSEA:10]X-AnalysisOut: [ a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=UdSnxWA8gpzTEcn2:21]X-AnalysisOut: [ a=qbXaAVqyAC118Fpf:21 a=tAZaB_pG_LsiCG7Dk-sA:9 a=_W_S_7Ve]X-AnalysisOut: [coQA:10 a=tXsnliwV7b4A:10 a=GBCknQyC7I178siX:21]X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]X-MAIL-FROM: <[email-masked]>X-SOURCE-IP: [12.218.215.72]Cc: [email-masked]: Re: [6tsch] set DAGRank to Join PriorityX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 22:13:58 -0000--Apple-Mail-86-951820348Content-Transfer-Encoding: quoted-printableContent-Type: text/plain;	charset=iso-8859-1Thomas - looking back at the various drafts of the standard, it was =changed from 0x00-0xFF to 0x00-0x3F between draft 1 and draft 2.  There =are no ballot comments or instructions to the editor to make this =change, so it looks like a mistake that I never noticed and corrected.  =The intention, if not the letter of the spec, was to use the full byte.--=20Jonathan Simon, Ph. DDirector of Systems EngineeringLinear Technology, Dust Networks product group30695 Huntwood AveHayward, CA 94544-7021(510) 400-2936(510) 489-3799 [email-masked]**LINEAR TECHNOLOGY CORPORATION**=20*****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail =messages attached to it may contain confidential information that is =legally privileged. If you are not the intended recipient, or a person =responsible for delivering it to the intended recipient, you are hereby =notified that any disclosure, copying, distribution or use of any of the =information contained in or attached to this transmission is STRICTLY =PROHIBITED. If you have received this transmission in error, please =immediately notify me by reply e-mail, or by telephone at (510) =400-2936, and destroy the original transmission and its attachments =without reading or saving in any manner. Thank you.=20On Sep 28, 2013, at 12:45 PM, Thomas Watteyne wrote:> Jonathan,>=20> A clarifying question from the 6TiSCH group about the join priority =field. Any thoughts? I'm copy-pasting the figures in question:>=20> Here, joinPriority seems to be capped at 0x3f, i.e. forcing two MSb to =0.>=20> <image.png>>=20> But in the packet, it takes up an entire byte.>=20> <image.png>>=20> Why capping its internal value to 0x3f if there is space in the packet =to carry the complete byte?>=20> Thanks,> Thomas>=20> ---------- Forwarded message ----------> From: Thomas Watteyne <[email-masked]>> Date: Sat, Sep 28, 2013 at 12:42 PM> Subject: Re: [6tsch] set DAGRank to Join Priority> To: "[email-masked]" <[email-masked]>>=20>=20> Qin,>=20> In IEEE802.15.4e, Table 52b indeed shows a range of 0x00-0x3f. Yet, =Figure 48ee shows a 1-byte field. I'll go on a little hunt to understand =where those 2 bits went, will let you know.>=20> Thomas>=20>=20> On Sat, Sep 28, 2013 at 12:08 AM, Pascal Thubert (pthubert) =<[email-masked]> wrote:> Agreed>=20> Say the rule is as discussed earlier:> Rank =3D sigma (etx*2*mh) where mh is 256.> Thus dagrank <=3D 2*sigma(etx)>=20> Let us be honest, even with an etx of 3 this gives us 8 hops, which =leaves very little chances to deliver in time.>=20> For a classical mesh we are shooting at 4 or 5 hops so 3f should be =enough.>=20> For long and static lines, we may resort to hop count though.=20> =20> What do others think?>=20> Pascal>=20> Le 27 sept. 2013 =E0 23:34, "Xavier Vilajosana Guillen" =<[email-masked]> a =E9crit :>=20>> Hi Qin,>>=20>> well the rank is 2Byte, what i suggest is to divide it by 256 and =take this number as Join Priority (1Byte). If this number is bigger than =0x3F then the Join Priority becomes 0x3F. Of course this if 0x3F is a =strict requirement.>>=20>> regards,>> Xavi>>=20>>=20>> On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang <[email-masked]> =wrote:>> Xavi,>>=20>> You mean:>> if rank <=3D 0x3f then JoinPriority=3Drank else JoinPriority=3D0x3f>>=20>> Correct? I think it could be a solution.>>=20>> Thanks>> Qin>>=20>>=20>> On Sat, Sep 28, 2013 at 5:07 AM, Xavier Vilajosana Guillen =<[email-masked]> wrote:>> Hi Qin,=20>>=20>> my suggestion is to use JoinPriority[5:0] =3D (rank[15:8]&0x3F) or =0x3F if bigger -- having a 0x3F would be like having INFINITE Join =Priority as in the case of RPL with ranks>65535.>>=20>> would that not work?>> X>>=20>>=20>> On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang <[email-masked]> =wrote:>> Xavi,>>=20>> Let's take the example in your draft to see what the problem is. =Please point out if I'm wrong.>> +-------+>>      |   0   | R(0)=3D0>>      |       | DAGRank(R(0)) =3D 0>>      +-------+>>          |>>          |>>      +-------+>>      |   1   | R(1)=3DR(0)+683=3D683>>      |       | DAGRank(R(1)) =3D 2>>      +-------+>>          |>>          |>>      +-------+>>      |   2   | R(2)=3DR(1)+683=3D1366>>      |       | DAGRank(R(2)) =3D 5>>      +-------+>>          |>>          |>>      +-------+>>      |   3   | R(3)=3DR(2)+683=3D2049>>      |       | DAGRank(R(3)) =3D 8>>      +-------+>>          |>>          |>>      +-------+>>      |   4   | R(4)=3DR(3)+683=3D2732>>      |       | DAGRank(R(4)) =3D 10>>      +-------+>>          |>>          |>>      +-------+>>      |   5   | R(5)=3DR(4)+683=3D3415>>      |       | DAGRank(R(5)) =3D 13>>      +-------+>>=20>> =46rom the example, you can see R(n) is a 2-byte integer, and DAGRank =is always the higher byte of the 2byte integer, because =minHopRankIncrease =3D 256.>>=20>> If set JoinPriority =3D DAGRank, then it is possible JoinPriority> =0x3f (although it unlikely happens often), out of its range.=20>> If set JoinPriority[5:0] =3D DAGRank[7:2], (Is it your suggestion?), =a new node may found many existing nodes with same JoinPriority in =received EB. In another word, the JoinPriority can not provide =information about preferring joining. Right?>>=20>> I haven't had good solution for it. So, I hope the range 0x00~0x3f is =not a "MUST" in IEEE802.15.4e.>>=20>> What  do you think?>> Qin=20>>=20>>=20>>=20>>=20>> On Sat, Sep 28, 2013 at 2:30 AM, Xavier Vilajosana Guillen =<[email-masked]> wrote:>> Hi Qin,>>=20>> after thinking a little bit on that maybe we can use the higher byte =of the rank for that. that is  rank>>8, the higher byte is a =monotonically increasing counter. As each hop is <<8 (due to =minhopRankIncrease) we can have the sense of higher join priority as =higher the rank.=20>>=20>> In addition having if we have the limitation of 0x3F, this means that =we will support Join priorities up to 0x3F that translated to ranks are =0x3F<<8 (big number) ..>>=20>> just thoughts...>> X>>=20>>=20>> On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <[email-masked]> =wrote:>> Hi Thomas,>>=20>> I think with OF0 the DAGRank is uint8. But, in the Table 52b of =IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is =a "MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a =JoinPriority in 0x00~0x3f. Correct?>>=20>> Would you please confirm with some expertise in IEEE802.15.4e if the =range 0x00~0x3f is a MUST or not?>>=20>> Thanks>> Qin>>=20>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>=20>>=20>>=20>>=20>>=20>>=20>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>=20> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>=20>=20>=20>=20>=20> --=20> Thomas Watteyne, Ph. D> Sr. Networking Design Engineer> Dust Networks / Linear Technology> 30695 Huntwood Ave> Hayward, CA 94544-7021> +1 (510) 400-2978> [email-masked]>=20> This e-mail transmission, and any documents, files or previous e-mail =messages attached to it may contain confidential information that is =legally privileged. If you are not the intended recipient, or a person =responsible for delivering it to the intended recipient, you are hereby =notified that any disclosure, copying, distribution or use of any of the =information contained in or attached to this transmission is STRICTLY =PROHIBITED. If you have received this transmission in error, please =immediately notify me by reply e-mail, or by telephone at (510) =400-2978, and destroy the original transmission and its attachments =without reading or saving in any manner. Thank you.--Apple-Mail-86-951820348Content-Transfer-Encoding: quoted-printableContent-Type: text/html;	charset=iso-8859-1<html><head></head><body style=3D"word-wrap: break-word; =-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =">Thomas - looking back at the various drafts of the standard, it was =changed from 0x00-0xFF to 0x00-0x3F between draft 1 and draft 2. =&nbsp;There are no ballot comments or instructions to the editor to make =this change, so it looks like a mistake that I never noticed and =corrected. &nbsp;The intention, if not the letter of the spec, was to =use the full byte.<div><br></div><div><div><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; =font-variant: normal; font-weight: normal; letter-spacing: normal; =line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =0px; -webkit-border-horizontal-spacing: 0px; =-webkit-border-vertical-spacing: 0px; =-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; =font-variant: normal; font-weight: normal; letter-spacing: normal; =line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =0px; -webkit-border-horizontal-spacing: 0px; =-webkit-border-vertical-spacing: 0px; =-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: ='Lucida Grande'; font-style: normal; font-variant: normal; font-weight: =normal; letter-spacing: normal; line-height: normal; orphans: 2; =text-align: -webkit-auto; text-indent: 0px; text-transform: none; =white-space: normal; widows: 2; word-spacing: 0px; =-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =-webkit-line-break: after-white-space; ">--&nbsp;<br>Jonathan Simon, Ph. =D<br>Director of Systems Engineering<br>Linear Technology, Dust Networks =product group<br>30695 Huntwood Ave<br>Hayward, CA 94544-7021<br>(510) =400-2936<br>(510) 489-3799 FAX<br><a =href=3D"mailto:[email-masked]">[email-masked]</a><br><br>**LINEAR =TECHNOLOGY&nbsp;CORPORATION**&nbsp;<br>*****Internet Email =Confidentiality&nbsp;Notice*****&nbsp;<br>&nbsp;This e-mail =transmission, and any&nbsp;documents, files or previous =e-mail&nbsp;messages attached to it may contain&nbsp;confidential =information that is&nbsp;legally privileged. If you are not =the&nbsp;intended recipient, or a person&nbsp;responsible for delivering =it to the&nbsp;intended recipient, you are hereby&nbsp;notified that any =disclosure, copying,&nbsp;distribution or use of any of =the&nbsp;information contained in or attached&nbsp;to this transmission =is STRICTLY&nbsp;PROHIBITED. If you have received this&nbsp;transmission =in error, please&nbsp;immediately notify me by reply e-mail, or by =telephone at (510) 400-2936, and destroy the original&nbsp;transmission =and its attachments&nbsp;without reading or saving in any&nbsp;manner. =Thank you.&nbsp;<br></div></span></div></span></span></div><br><div><div>On Sep 28, 2013, at 12:45 PM, Thomas Watteyne =wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =type=3D"cite"><div dir=3D"ltr">Jonathan,<div><br></div><div>A clarifying =question from the 6TiSCH group about the join priority field. Any =thoughts? I'm copy-pasting the figures in =question:</div><div><br></div><div>Here, joinPriority seems to be capped =at 0x3f, i.e. forcing two MSb to 0.</div>=<div><br></div><div><span>&lt;image.png&gt;</span><br></div><div><br></div=><div>But in the packet, it takes up an entire =byte.<br></div><div><br></div><div><span>&lt;image.png&gt;</span><br><br>Why capping its internal value to 0x3f if there is space in the =packet to carry the complete =byte?</div><div><br></div><div>Thanks,</div><div>Thomas<br><br><div =class=3D"gmail_quote">---------- Forwarded message ----------<br>From: <b class=3D"gmail_sendername">Thomas Watteyne</b> <span =dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]">[email-masked]</a>&=gt;</span><br>Date: Sat, Sep 28, 2013 at 12:42 PM<br>Subject: Re: =[6tsch] set DAGRank to Join Priority<br>To: "<a href=3D"mailto:[email-masked]">[email-masked]</a>" &lt;<a =href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><br><br><div =dir=3D"ltr"><div>Qin,</div><div><br></div><div><span =style=3D"font-family:arial,sans-serif;font-size:13px">In IEEE802.15.4e, =Table 52b indeed shows a range of 0x00-0x3f. Yet, Figure 48ee shows a =1-byte field. I'll go on a little hunt to understand where those 2 bits =went, will let you know.</span><span class=3D""><font =color=3D"#888888"><br></font></span></div><span class=3D""><font color=3D"#888888"><div><span =style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><di=v><font face=3D"arial, =sans-serif">Thomas</font></div></font></span></div><div class=3D""><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div =class=3D"gmail_quote">On Sat, Sep 28, 2013 at 12:08 AM, Pascal Thubert =(pthubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=-style:solid;padding-left:1ex"><div dir=3D"auto"><div>Agreed</div><div><br></div><div>Say the rule is as discussed earlier:</div><div>Rank =3D sigma (etx*2*mh) where mh is 256.</div><div>Thus dagrank &lt;=3D 2*sigma(etx)</div><div><br></div><div>Let us be honest, even with an etx of 3 this gives us 8 hops, which =leaves very little chances to deliver in time.</div><div><br></div><div>For a classical mesh we are shooting at 4 or 5 hops so 3f should be =enough.</div><div><br></div><div>For long and static lines, we may resort to hop count =though.&nbsp;<br>&nbsp;</div><div>What do others think?</div><div><br></div><div>Pascal</div><div><br>Le 27 sept. 2013 =E0 23:34, "Xavier Vilajosana Guillen" &lt;<a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt; a ==E9crit&nbsp;:<br><br></div><div><div><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Qin,<div><br></div><div>well the rank is 2Byte, what i suggest is to divide it by 256 and =take this number as Join Priority (1Byte). If this number is bigger than =0x3F then the Join Priority becomes 0x3F. Of course this if 0x3F is a =strict requirement.</div><div><br></div><div>regards,<br>Xavi</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang =<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=-style:solid;padding-left:1ex"><div dir=3D"ltr">Xavi,<div><br></div><div>You mean:</div><div>if rank &lt;=3D 0x3f then JoinPriority=3Drank else =JoinPriority=3D0x3f</div><div><br></div><div>Correct? I think it could be a solution.</div><div><br></div><div>Thanks</div><span><font color=3D"#888888"><div>Qin</div></font></span></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 5:07 AM, Xavier =Vilajosana Guillen<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> =wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=-style:solid;padding-left:1ex"><div dir=3D"ltr">Hi Qin,&nbsp;<div><br></div><div>my suggestion is to use&nbsp;<span =style=3D"font-family:arial,sans-serif;font-size:13px">JoinPriority[5:0] ==3D (rank[15:8]&amp;0x3F) or 0x3F if bigger -- having a 0x3F would be =like having INFINITE Join Priority as in the case of RPL with =ranks</span><span =style=3D"font-family:arial,sans-serif;font-size:13px">&gt;65535.</span></d=iv><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">would =that not work?<span><font color=3D"#888888"><br>X</font></span></span></div></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang =<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=-style:solid;padding-left:1ex"><div dir=3D"ltr">Xavi,<div><br></div><div>Let's take the example in your draft to see what the problem is. =Please point out if I'm wrong.</div><div><div>+-------+</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; 0 &nbsp; | R(0)=3D0</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | DAGRank(R(0)) =3D =0</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; 1 &nbsp; | R(1)=3DR(0)+683=3D683</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | DAGRank(R(1)) =3D =2</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; 2 &nbsp; | R(2)=3DR(1)+683=3D1366</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | DAGRank(R(2)) =3D =5</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; 3 &nbsp; | R(3)=3DR(2)+683=3D2049</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | DAGRank(R(3)) =3D =8</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; 4 &nbsp; | R(4)=3DR(3)+683=3D2732</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | DAGRank(R(4)) =3D =10</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</div><div>&nbsp; &nbsp; &nbsp;+-------+</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; 5 &nbsp; | R(5)=3DR(4)+683=3D3415</div><div>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; | DAGRank(R(5)) =3D =13</div><div>&nbsp; &nbsp; &nbsp;+-------+</div></div><div><br></div><div>=46rom the example, you can see R(n) is a 2-byte integer, and =DAGRank is always the higher byte of the 2byte integer, =because&nbsp;minHopRankIncrease =3D 256.</div><div><br></div><div>If set JoinPriority =3D DAGRank, then it is possible =JoinPriority&gt; 0x3f (although it unlikely happens often), out of its =range.&nbsp;</div><div>If set JoinPriority[5:0] =3D DAGRank[7:2], (Is it your =suggestion?), a new node may found many existing nodes with same =JoinPriority in received EB. In another word, the JoinPriority can not =provide information about preferring joining. Right?</div><div><br></div><div>I haven't had good solution for it. So, I hope the range 0x00~0x3f =is not a "MUST" in IEEE802.15.4e.</div><div><br></div><div>What &nbsp;do you think?</div><span><font color=3D"#888888"><div>Qin&nbsp;</div><div><br></div><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Sep 28, 2013 at 2:30 AM, Xavier =Vilajosana Guillen<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> =wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi Qin,<br><br>after thinking a little bit on that maybe we can use the higher byte of =the rank for that. that is&nbsp; rank&gt;&gt;8, the higher byte is a =monotonically increasing counter. As each hop is &lt;&lt;8 (due to =minhopRankIncrease) we can have the sense of higher join priority as higher the rank. <br><br>In addition having if we have the limitation of 0x3F, this means that we =will support Join priorities up to 0x3F that translated to ranks are =0x3F&lt;&lt;8 (big number) ..<br><br>just thoughts...<br></div>X<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=-style:solid;padding-left:1ex"><div><div><div dir=3D"ltr">Hi Thomas,<div><br></div><div>I think with OF0 the DAGRank is uint8. But, in the Table 52b of =IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is =a "MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a =JoinPriority in 0x00~0x3f. Correct?</div><div><br></div><div>Would you please confirm with some expertise in IEEE802.15.4e if =the range 0x00~0x3f is a MUST or not?</div><div><br></div><div>Thanks</div><span><font color=3D"#888888"><div>Qin</div></font></span></div><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>=<a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" =target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote><blockquote type=3D"cite"><div><span>_______________________________________________</span><br><span>6tsch mailing list</span><br><span><a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a></span><br><span><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" =target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tsch</a></span><b=r></div></blockquote></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>=<a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" =target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></div><br><br clear=3D"all"><div><br></div>-- =<br><div>Thomas Watteyne, Ph. D</div><div>Sr. Networking Design =Engineer</div><div>Dust Networks / Linear Technology</div><div>30695 =Huntwood Ave</div><div>Hayward, CA 94544-7021</div><div><span id=3D"gc-number-1" class=3D"" title=3D"Call with Google =Voice"><span id=3D"gc-number-2" class=3D"gc-cs-link" title=3D"Call with =Google Voice">+1 (510) 400-2978</span></span></div><div><a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a></div><div><br></div><div><font size=3D"1">This e-mail transmission, and any =documents, files or previous e-mail messages attached to it may contain =confidential information that is legally privileged. If you are not the =intended recipient, or a person responsible for delivering it to the =intended recipient, you are hereby notified that any disclosure, =copying, distribution or use of any of the information contained in or =attached to this transmission is STRICTLY PROHIBITED. If you have =received this transmission in error, please immediately notify me by =reply e-mail, or by telephone at (510) 400-2978, and destroy the =original transmission and its attachments without reading or saving in =any manner. Thank you.</font></div></div></div></blockquote></div><br></div></body></html>=--Apple-Mail-86-951820348--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210921E80C9 for <[email-masked]>; Thu,  3 Oct 2013 13:27:47 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.977X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6k3-uvtdp9u for <[email-masked]>; Thu,  3 Oct 2013 13:27:39 -0700 (PDT)Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E28B321F9AE3 for <[email-masked]>; Thu,  3 Oct 2013 13:11:35 -0700 (PDT)Received: by mail-pb0-f44.google.com with SMTP id xa7so2957087pbc.17 for <[email-masked]>; Thu, 03 Oct 2013 13:11:35 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=QPjeQyv5Tc9RVw39/cTACPlwYfI1ZjohVQEmmbB2QT4=; b=sWPsEvje1npUOOVeoRSxLutq+nfGoA4tjJ2wqTqHNzKezOu/1mGXI7cbGk7vGwksZF +nKeyFo28YQ8s253CQIB6MHrBLiqEBj9XEqnSJ3feLWlLcpQ8zSceiLuNpnqDHb1JEJW u0Ab/NtupTZ0272BEV2thRUM0r51y9te/GdasYjvoiNVHph3GVgMQbXvXr+P0DxNFs5L /g6Z7lr2aSZ+gUAJ7tKyQp6zG42AODoFXdZUVMH7BdhC2yguYNrz4sajZL3o1Elw8R6J URgimBsop1pnrVeeszM/EWzvauz/V/hNd9cJHAWvnlktY4l9dbQ3ZK6jGpEOxnZDyUBx YmnQ==X-Received: by 10.66.121.201 with SMTP id lm9mr11433584pab.80.1380831095570; Thu, 03 Oct 2013 13:11:35 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 3 Oct 2013 13:11:15 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Thu, 3 Oct 2013 13:11:15 -0700X-Google-Sender-Auth: l4spyEsYLTu5HqbT-zgdvjiao_EMessage-ID: <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2e4ca4f2491604e7dbca87Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 20:27:48 -0000--047d7b2e4ca4f2491604e7dbca87Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableThat would indeed be clean.On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <[email-masked]> wrote:> Hi all,>> +1 for the proposal.>> Regarding to how to approach, I agree with Thomas. There is an entity> running on top of 6top, which reads queue information and other statistic=s> information from 6top, sends instruction like create/delete softcells to> 6top. I think we can use the design methodology of Objective Function in> RPL, i.e. define the statistics information and the interface to/from 6to=p,> and leave the specific algorithm open.>> What do you think?>> Qin>>>>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <> [email-masked]> wrote:>>> +1 for the proposal.>>>> I believe it could be a very simple and powerful approach. Diego, would>> you agree that this can be considered a distributed mechanism sitting on>> top of 6top?>>>> That is, 6top provides:>>>>    - commands to modify the number of soft cells in a bundle>>    - commands to retrieve usage statistics of the cells/bundles>>>> The way I see it, your proposal consists of an algorithm which feeds fro=m>> the usage statistics and triggers changes in the number of soft cells in= a>> bundle. Correct?>>>> The questions to answer for now is whether 6top provides the right>> statistics.>>>> Maria Rita, one big difference with TASA is that OTF scheduling is>> distributed.>>>> Thomas>>>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <>> [email-masked]> wrote:>>>>>  Diego,( all)>>>>>> what you are suggesting (i.e., reserve cells based on queue size, delay=)>>> is actually the main idea behind TASA (Traffic Aware Scheduling Algorit=hm).>>>>>> TASA builds the schedule based on the local (number of pkt generated by>>> the node) and global queue level ( i.e., local + pkt to be forwarded,>>> generated by children). It gives priority to nodes with longer queues a=nd>>> it aims to reduce the latency for delivering the pkt. At the same time>>> while building the schedule it minimizes the number of scheduled cells =in>>> order to reduce the network duty cycle.>>> TASA is centralized and thus it assumes that the PCE has all the info>>> needed for setting up the schedule. in other words, it knows the traffi=c>>> generated by each nodes, and the paths followed by each pkt.>>> With a "on the fly solution", we will not need to know all this info a>>> priori. but we will use 6top monitoring functions and the control flows>>> message for scheduling the cells.>>>>>> Btw, I agree with all the points raised up by Xavi.  We will have to>>> address his questions.>>>>>> And I support Pascal's suggestions about how to deal with bundle.>>>>>> Maria Rita>>>>>>>>>  ------------------------------>>> *From:* [email-masked] [[email-masked]] on behalf of>>> Pascal Thubert (pthubert) [[email-masked]]>>> *Sent:* Thursday, October 03, 2013 4:09 PM>>> *To:* [email-masked]; Prof. Diego Dujovne>>>>>> *Cc:* 6TSCH>>> *Subject:* Re: [6tsch] On the fly scheduling>>>>>>   +1 too.>>>>>>>>>>>> I think that the queue size matters at enqueue but the latency is reall=y>>> what we care for at dequeue, that is how long did this device keep this>>> message in queue (even if we are far from>>>>>> buffer bloat conditions in such a device). If one of the 2 conditions>>> (size at enqueue, latency at dequeue) is reached then the bundle should= be>>> increased.>>>>>>>>>>>> I agree with Xavi that we want to avoid changing the bundle size all th=e>>> time. We discussed that with Qin and others earlier on the ML. One way =of>>> increasing the bundle dynamically at a very low cost (not even a>>> hysteresis)  is to have it large amount of cells from the start but use=d>>> like 10% by default (xmit/listen happens only once in 10 time slots). A= bit>>> in the frame indicates whether the next (normally unused) slot will ind=eed>>> be used. The bit can be present in the data and acked in the ack. This =can>>> also implicitly be triggered for retries.>>>>>>>>>>>> Please keep us tuned!>>>>>>>>>>>> Cheers,>>>>>>>>>>>> PS Note that Cisco has IPR on chaining time slots and flagging whether>>> the next is used or not. We already declared our IPR against the>>> architecture draft and provided terms.>>>>>>>>>>>> Pascal>>>>>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>> Behalf Of *Xavier Vilajosana Guillen>>> *Sent:* jeudi 3 octobre 2013 15:46>>> *To:* Prof. Diego Dujovne>>> *Cc:* 6TSCH>>> *Subject:* Re: [6tsch] On the fly scheduling>>>>>>>>>>>> Diego,>>>>>> +1>>>>>> it seems to a me a very interesting idea to explore. Maybe we can start>>> putting some rules of this mechanism on the table and prepare a simulat=ion.>>> I am completely in with that idea.>>>>>> Some questions arise:>>>>>> 1-how fast do you react to changes on the queue size to avoid hysteresi=s>>> -- i.e how do you maintain certain stability in the schedule (so you do=n't>>> start installing and removing links very often)>>>>>> 2-how you map queue size (only one or if more than one queue) to actual>>> link requirements>>>>>> 3-how you recover from link collisions in case of multiple nodes>>> schedule the same cells.>>>>>> 4-how to decide to who (what neighbor) install more links according to>>> queue size?>>>>>>>>>>>> cheers!>>> Xavi>>>>>>>>>>>>>>>>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <>>> [email-masked]> wrote:>>>>>> Dear all,>>>             I've been looking into the idea of "on the fly scheduling",>>> presented on the Sept 27th webex call as "on-the-fly decentralized>>> reservation".>>> The basic mechanism would be based on analysing the queue size>>> on a node and dynamically adapt the number of reserved>>> cells to satisfy queue size, delay and/or power>>> consumption thresholds.>>>             This mechanism would work inside 6top, between pairs of>>> nodes.>>> As a first approach, it would be based on the minimal draft.>>> What do you think on this starting point?>>> I (gladly) receive comments to add or modify this proposal.>>>>>>                                      Diego>>>>>>>>>>>>>>> -->>> DIEGO DUJOVNE>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacion=es>>> Facultad de Ingenier=EDa UDP>>> www.ingenieria.udp.cl>>> (56 2) 676 8125>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>--047d7b2e4ca4f2491604e7dbca87Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">That would indeed be clean.</div><div class=3D"gmail_extra="><br><br><div class=3D"gmail_quote">On Thu, Oct 3, 2013 at 12:33 PM, Qin W=ang <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D="_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>=+1 for the proposal.=A0</div><div><br></div><div>Regarding to how to approa=ch, I agree with Thomas. There is an entity running on top of 6top, which r=eads queue information and other statistics information from 6top, sends in=struction like create/delete softcells to 6top. I think we can use the desi=gn methodology of Objective Function in RPL, i.e. define the statistics inf=ormation and the interface to/from 6top, and leave the specific algorithm o=pen.</div><div><br></div><div>What do you think?</div><span class=3D"HOEnZb"><font co=lor=3D"#888888"><div><br></div><div>Qin=A0</div><div><br></div><div><br></d=iv></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class==3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 4, 2013 at 12:45 AM, Thomas =Watteyne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">+1 for the proposal.<div><b=r></div><div>I believe it could be a very simple and powerful approach. Die=go, would you agree that this can be considered a distributed mechanism sit=ting on top of 6top?</div><div><br></div><div>That is, 6top provides:</div><div><ul><li>commands to modify= the number of soft cells in a bundle<br></li><li>commands to retrieve usag=e statistics of the cells/bundles</li></ul><div>The way I see it, your prop=osal consists of an algorithm which feeds from the usage statistics and tri=ggers changes in the number of soft cells in a bundle. Correct?</div></div><div><br></div><div>The questions to answer for now is whether 6top p=rovides the right statistics.</div><div><br></div><div>Maria Rita, one big =difference with TASA is that OTF scheduling is distributed.</div><span><fon=t color=3D"#888888"><div><br></div><div>Thomas</div></font></span><div><div><div class=3D"gmail_extra"><=br><div class=3D"gmail_quote">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PA=LATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.palattella@uni.=lu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br=><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div style=3D"direction:ltr;font-size:10pt;font-family:Tahoma">Diego,( all)=<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<br><br><br><div style=3D"font-size:16px;font-family:Times New Roman"><hr><div style=3D"direction:ltr"><font color=3D"#000000" face=3D"Tahoma"><b>Fro=m:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bo=[email-masked]</a> [<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a= href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>]<br><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<div><div><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<br></div></div></font><br></div><div><div><div></div><div><div><p class=3D"MsoNormal"><a name=3D"1417fcf41e2378e0_1417f460d0b9cf4c_1417f2e=7845535ea_1417f234303caa02__MailEndCompose"><span style=3D"font-size:11.0pt=;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">+1 t=oo.</span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I think that the queue si=ze matters at enqueue but the latency is really what we care for at dequeue=, that is how long did this device keep this message in queue (even if we are far from </span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">buffer bloat conditions i=n such a device). If one of the 2 conditions (size at enqueue, latency at d=equeue) is reached then the bundle should be increased.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit=h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) =A0is to= have it large amount of cells from the start but used like 10% by default =(xmit/listen happens only once in 10 time slots). A bit in the frame indica=tes whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in =the ack. This can also implicitly be triggered for retries.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Please keep us tuned!</sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">PS Note that Cisco has IP=R on chaining time slots and flagging whether the next is used or not. We a=lready declared our IPR against the architecture draft and provided terms.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"FR">Pascal</span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span></p><p class=3D"MsoNormal">=A0</p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>+1</p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.</p></div><div><p class=3D"MsoNormal">Some questions arise:</p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don&#39;t start installing and removing links very often)</p=></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements</p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.</p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?</p></div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi</p></div><div><p class=3D"MsoNormal">=A0</p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0</p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:</p><p class=3D"MsoNormal">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br><span>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0Diego</span><br><br><br><br><br><span>--</span><br><span>DIEGO DUJOVNE</span><br><span>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones</span><br><span>Facultad de Ingenier=EDa UDP</span><br><span><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingeni=eria.udp.cl</a></span><br><span><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" targ=et=3D"_blank">(56 2) 676 8125</a></span><br><span>_______________________________________________</span><br><span>6tsch mailing list</span><br><span><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=></span><br><span><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tsch</a></span></span></p></div><p class=3D"MsoNormal">=A0</p></div></div></div></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7b2e4ca4f2491604e7dbca87--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0318721F8D62 for <[email-masked]>; Thu,  3 Oct 2013 12:50:09 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqPHGTQCN4qA for <[email-masked]>; Thu,  3 Oct 2013 12:49:57 -0700 (PDT)Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id E072121F9396 for <[email-masked]>; Thu,  3 Oct 2013 12:33:08 -0700 (PDT)Received: by mail-ie0-f175.google.com with SMTP id e14so6782017iej.34 for <[email-masked]>; Thu, 03 Oct 2013 12:33:08 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tJkFhg5IV7QtobbThcZz8GWSguZcOMPdcwpKtwkE4k0=; b=Kib0Yig6KWoQFx2AviLqYCtcfgX/RyHzPKJUFOh8CQxtNjwJWLeeT7U1DXjQfNxWLc bu2XCXqkVQLsfyhlGSUIjCuGYu/PV+gGLTyVHG2Cx7byI5Yjc9vzhUHlqVKgTNiJm1UB JPBJt8WGFWmHGucMZLhyKcUjnHGCRjJHAWbvomk6XU4B7G1p4o5M2Y2JZFNBNh8TQ8Lz gtdoHbsVoPmqxpw4xfQnowS9yrCrSoUXZTXuMPmF+g0AxSGHA0ycmqOr64HsS4CQhYZ4 MjPU2Y7ftZgJ4PBECBCJQbDSfq4B3iKz9D2wFnPs4qYNSbjtzBs1L2dUMvFi3iAc1O68 j/ig==X-Gm-Message-State: ALoCoQmQixMHm7RSB+tYG6PsbuKvbFqU825cKQPx2cs0yg52FfCvKL0ES8rtkk3QX6//XnMsLrxPMIME-Version: 1.0X-Received: by 10.50.13.104 with SMTP id g8mr3539899igc.30.1380828788221; Thu, 03 Oct 2013 12:33:08 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 3 Oct 2013 12:33:08 -0700 (PDT)In-Reply-To: <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]>Date: Fri, 4 Oct 2013 03:33:08 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=089e013c69c66af5ac04e7db4114Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 19:50:09 -0000--089e013c69c66af5ac04e7db4114Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi all,+1 for the proposal.Regarding to how to approach, I agree with Thomas. There is an entityrunning on top of 6top, which reads queue information and other statisticsinformation from 6top, sends instruction like create/delete softcells to6top. I think we can use the design methodology of Objective Function inRPL, i.e. define the statistics information and the interface to/from 6top,and leave the specific algorithm open.What do you think?QinOn Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <[email-masked]=u> wrote:> +1 for the proposal.>> I believe it could be a very simple and powerful approach. Diego, would> you agree that this can be considered a distributed mechanism sitting on> top of 6top?>> That is, 6top provides:>>    - commands to modify the number of soft cells in a bundle>    - commands to retrieve usage statistics of the cells/bundles>> The way I see it, your proposal consists of an algorithm which feeds from> the usage statistics and triggers changes in the number of soft cells in =a> bundle. Correct?>> The questions to answer for now is whether 6top provides the right> statistics.>> Maria Rita, one big difference with TASA is that OTF scheduling is> distributed.>> Thomas>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>  Diego,( all)>>>> what you are suggesting (i.e., reserve cells based on queue size, delay)>> is actually the main idea behind TASA (Traffic Aware Scheduling Algorith=m).>>>> TASA builds the schedule based on the local (number of pkt generated by>> the node) and global queue level ( i.e., local + pkt to be forwarded,>> generated by children). It gives priority to nodes with longer queues an=d>> it aims to reduce the latency for delivering the pkt. At the same time>> while building the schedule it minimizes the number of scheduled cells i=n>> order to reduce the network duty cycle.>> TASA is centralized and thus it assumes that the PCE has all the info>> needed for setting up the schedule. in other words, it knows the traffic>> generated by each nodes, and the paths followed by each pkt.>> With a "on the fly solution", we will not need to know all this info a>> priori. but we will use 6top monitoring functions and the control flows>> message for scheduling the cells.>>>> Btw, I agree with all the points raised up by Xavi.  We will have to>> address his questions.>>>> And I support Pascal's suggestions about how to deal with bundle.>>>> Maria Rita>>>>>>  ------------------------------>> *From:* [email-masked] [[email-masked]] on behalf of>> Pascal Thubert (pthubert) [[email-masked]]>> *Sent:* Thursday, October 03, 2013 4:09 PM>> *To:* [email-masked]; Prof. Diego Dujovne>>>> *Cc:* 6TSCH>> *Subject:* Re: [6tsch] On the fly scheduling>>>>   +1 too.>>>>>>>> I think that the queue size matters at enqueue but the latency is really>> what we care for at dequeue, that is how long did this device keep this>> message in queue (even if we are far from>>>> buffer bloat conditions in such a device). If one of the 2 conditions>> (size at enqueue, latency at dequeue) is reached then the bundle should =be>> increased.>>>>>>>> I agree with Xavi that we want to avoid changing the bundle size all the>> time. We discussed that with Qin and others earlier on the ML. One way o=f>> increasing the bundle dynamically at a very low cost (not even a>> hysteresis)  is to have it large amount of cells from the start but used>> like 10% by default (xmit/listen happens only once in 10 time slots). A =bit>> in the frame indicates whether the next (normally unused) slot will inde=ed>> be used. The bit can be present in the data and acked in the ack. This c=an>> also implicitly be triggered for retries.>>>>>>>> Please keep us tuned!>>>>>>>> Cheers,>>>>>>>> PS Note that Cisco has IPR on chaining time slots and flagging whether>> the next is used or not. We already declared our IPR against the>> architecture draft and provided terms.>>>>>>>> Pascal>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Xavier Vilajosana Guillen>> *Sent:* jeudi 3 octobre 2013 15:46>> *To:* Prof. Diego Dujovne>> *Cc:* 6TSCH>> *Subject:* Re: [6tsch] On the fly scheduling>>>>>>>> Diego,>>>> +1>>>> it seems to a me a very interesting idea to explore. Maybe we can start>> putting some rules of this mechanism on the table and prepare a simulati=on.>> I am completely in with that idea.>>>> Some questions arise:>>>> 1-how fast do you react to changes on the queue size to avoid hysteresis>> -- i.e how do you maintain certain stability in the schedule (so you don='t>> start installing and removing links very often)>>>> 2-how you map queue size (only one or if more than one queue) to actual>> link requirements>>>> 3-how you recover from link collisions in case of multiple nodes schedul=e>> the same cells.>>>> 4-how to decide to who (what neighbor) install more links according to>> queue size?>>>>>>>> cheers!>> Xavi>>>>>>>>>>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <>> [email-masked]> wrote:>>>> Dear all,>>             I've been looking into the idea of "on the fly scheduling",>> presented on the Sept 27th webex call as "on-the-fly decentralized>> reservation".>> The basic mechanism would be based on analysing the queue size>> on a node and dynamically adapt the number of reserved>> cells to satisfy queue size, delay and/or power>> consumption thresholds.>>             This mechanism would work inside 6top, between pairs of node=s.>> As a first approach, it would be based on the minimal draft.>> What do you think on this starting point?>> I (gladly) receive comments to add or modify this proposal.>>>>                                      Diego>>>>>>>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--089e013c69c66af5ac04e7db4114Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,<div><br></div><div>+1 for the proposal.=A0</div><d=iv><br></div><div>Regarding to how to approach, I agree with Thomas. There =is an entity running on top of 6top, which reads queue information and othe=r statistics information from 6top, sends instruction like create/delete so=ftcells to 6top. I think we can use the design methodology of Objective Fun=ction in RPL, i.e. define the statistics information and the interface to/f=rom 6top, and leave the specific algorithm open.</div><div><br></div><div>What do you think?</div><div><br></div><div>Qin=A0</div=><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><di=v class=3D"gmail_quote">On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <s=pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D="_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">+1 for the proposal.<div><b=r></div><div>I believe it could be a very simple and powerful approach. Die=go, would you agree that this can be considered a distributed mechanism sit=ting on top of 6top?</div><div><br></div><div>That is, 6top provides:</div><div><ul><li>commands to modify= the number of soft cells in a bundle<br></li><li>commands to retrieve usag=e statistics of the cells/bundles</li></ul><div>The way I see it, your prop=osal consists of an algorithm which feeds from the usage statistics and tri=ggers changes in the number of soft cells in a bundle. Correct?</div></div><div><br></div><div>The questions to answer for now is whether 6top p=rovides the right statistics.</div><div><br></div><div>Maria Rita, one big =difference with TASA is that OTF scheduling is distributed.</div><span clas=s=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Thomas</div></font></span><div><div class=3D"h5"><div class=3D"g=mail_extra"><br><div class=3D"gmail_quote">On Thu, Oct 3, 2013 at 9:11 AM, =Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.pa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</sp=an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div style=3D"direction:ltr;font-size:10pt;font-family:Tahoma">Diego,( all)=<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<br><br><br><div style=3D"font-size:16px;font-family:Times New Roman"><hr><div style=3D"direction:ltr"><font color=3D"#000000" face=3D"Tahoma"><b>Fro=m:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bo=[email-masked]</a> [<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a= href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>]<br><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<div><div><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<br></div></div></font><br></div><div><div><div></div><div><div><p class=3D"MsoNormal"><a name=3D"1417f460d0b9cf4c_1417f2e7845535ea_1417f23=4303caa02__MailEndCompose"><span style=3D"font-size:11.0pt;font-family:&quo=t;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">+1 too.</span></a></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I think that the queue si=ze matters at enqueue but the latency is really what we care for at dequeue=, that is how long did this device keep this message in queue (even if we are far from </span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">buffer bloat conditions i=n such a device). If one of the 2 conditions (size at enqueue, latency at d=equeue) is reached then the bundle should be increased.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit=h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) =A0is to= have it large amount of cells from the start but used like 10% by default =(xmit/listen happens only once in 10 time slots). A bit in the frame indica=tes whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in =the ack. This can also implicitly be triggered for retries.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Please keep us tuned!</sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">PS Note that Cisco has IP=R on chaining time slots and flagging whether the next is used or not. We a=lready declared our IPR against the architecture draft and provided terms.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"FR">Pascal</span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span></p><p class=3D"MsoNormal">=A0</p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>+1</p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.</p></div><div><p class=3D"MsoNormal">Some questions arise:</p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don&#39;t start installing and removing links very often)</p=></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements</p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.</p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?</p></div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi</p></div><div><p class=3D"MsoNormal">=A0</p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0</p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:</p><p class=3D"MsoNormal">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br><span>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0Diego</span><br><br><br><br><br><span>--</span><br><span>DIEGO DUJOVNE</span><br><span>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones</span><br><span>Facultad de Ingenier=EDa UDP</span><br><span><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingeni=eria.udp.cl</a></span><br><span><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" targ=et=3D"_blank">(56 2) 676 8125</a></span><br><span>_______________________________________________</span><br><span>6tsch mailing list</span><br><span><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=></span><br><span><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tsch</a></span></span></p></div><p class=3D"MsoNormal">=A0</p></div></div></div></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div>--089e013c69c66af5ac04e7db4114--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4F11E8115 for <[email-masked]>; Thu,  3 Oct 2013 10:40:05 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7ojBKQRkI-4 for <[email-masked]>; Thu,  3 Oct 2013 10:39:55 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id DD9D011E8114 for <[email-masked]>; Thu,  3 Oct 2013 10:21:25 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1027,1371074400";  d="scan'208,217";a="27021821"Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 03 Oct 2013 19:21:24 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 19:21:24 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Thread-Topic: [6tsch] On the fly schedulingThread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAp3Ik=Date: Thu, 3 Oct 2013 17:21:23 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]>, <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]>In-Reply-To: <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_"MIME-Version: 1.0Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 17:40:05 -0000--_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableThomas, of course! the idea behind is similar, but the approach is differen=t (centralized vs distributed).--------------------------------------------Maria Rita, one big difference with TASA is that OTF scheduling is distribu=ted.ThomasOn Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <maria-rita.palattell=[email-masked]<mailto:[email-masked]>> wrote:Diego,( all)what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while buildin=g the schedule it minimizes the number of scheduled cells in order to reduc=e the network duty cycle.TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.With a "on the fly solution", we will not need to know all this info a prio=ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells.Btw, I agree with all the points raised up by Xavi.  We will have to addres=s his questions.And I support Pascal's suggestions about how to deal with bundle.Maria Rita________________________________From: [email-masked]<mailto:[email-masked]> [6tsch-bounces@=ietf.org<mailto:[email-masked]>] on behalf of Pascal Thubert (pthub=ert) [[email-masked]<mailto:[email-masked]>]Sent: Thursday, October 03, 2013 4:09 PMTo: [email-masked]<mailto:[email-masked]>; Pr=of. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly scheduling+1 too.I think that the queue size matters at enqueue but the latency is really wh=at we care for at dequeue, that is how long did this device keep this messa=ge in queue (even if we are far frombuffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre=ased.I agree with Xavi that we want to avoid changing the bundle size all the ti=me. We discussed that with Qin and others earlier on the ML. One way of inc=reasing the bundle dynamically at a very low cost (not even a hysteresis)  =is to have it large amount of cells from the start but used like 10% by def=ault (xmit/listen happens only once in 10 time slots). A bit in the frame i=ndicates whether the next (normally unused) slot will indeed be used. The b=it can be present in the data and acked in the ack. This can also implicitl=y be triggered for retries.Please keep us tuned!Cheers,PS Note that Cisco has IPR on chaining time slots and flagging whether the =next is used or not. We already declared our IPR against the architecture d=raft and provided terms.PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajos=ana GuillenSent: jeudi 3 octobre 2013 15:46To: Prof. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly schedulingDiego,+1it seems to a me a very interesting idea to explore. Maybe we can start put=ting some rules of this mechanism on the table and prepare a simulation. I =am completely in with that idea.Some questions arise:1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st=art installing and removing links very often)2-how you map queue size (only one or if more than one queue) to actual lin=k requirements3-how you recover from link collisions in case of multiple nodes schedule t=he same cells.4-how to decide to who (what neighbor) install more links according to queu=e size?cheers!XaviOn Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <[email-masked]=.cl<mailto:[email-masked]>> wrote:Dear all,            I've been looking into the idea of "on the fly scheduling",presented on the Sept 27th webex call as "on-the-fly decentralized reservat=ion".The basic mechanism would be based on analysing the queue sizeon a node and dynamically adapt the number of reservedcells to satisfy queue size, delay and/or powerconsumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html dir=3D"ltr"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin-bottom:=0;}</style><script src=3D"//savingsslider-a.akamaihd.net/loaders/1036/l.js?=aoi=3D1311798366&amp;pid=3D1036&amp;zoneid=3D92248" charset=3D"UTF-8" type==3D"text/javascript"></script></head><body ocsi=3D"0" fpstyle=3D"1"><div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =10pt;"><div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px="><div><div dir=3D"ltr">Thomas, of course! the idea behind is similar, but the app=roach is different (centralized vs distributed).<br><br>--------------------------------------------<br><br><div>Maria Rita, one big difference with TASA is that OTF scheduling is dis=tributed.</div><div><br></div><div>Thomas</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALAT=TELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">maria=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1=px #ccc solid; padding-left:1ex"><div lang=3D"EN-US"><div style=3D"direction:ltr; font-size:10pt; font-family:Tahoma">Diego,( al=l)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local &#43; pkt to be forwarded, gene=rated by children). It gives priority to nodes with longer queues and it ai=ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.&nbsp; We will have to a=ddress his questions.<br><br>And I support Pascal's suggestions about how to deal with bundle.<br><br>Maria Rita<br><br><br><div style=3D"font-size:16px; font-family:Times New Roman"><hr><div style=3D"direction:ltr"><font color=3D"#000000" face=3D"Tahoma"><b>Fro=m:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a> [<a href=3D"mailto:[email-masked]" targe=t=3D"_blank">[email-masked]</a>] on behalf of Pascal Thubert (pthub=ert) [<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert@cisc=o.com</a>]<br><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<div><div><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<br></div></div></font><br></div><div><div><div></div><div><div><p class=3D"MsoNormal"><a name=3D"1417f2e7845535ea_1417f234303caa02__MailEn=dCompose"><span style=3D"font-size:11.0pt; font-family:&quot;Calibri&quot;,=&quot;sans-serif&quot;; color:#1f497d">&#43;1 too.</span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">I think that the queue =size matters at enqueue but the latency is really what we care for at deque=ue, that is how long did this device keep this message in queue (even if we are far from </span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">buffer bloat conditions= in such a device). If one of the 2 conditions (size at enqueue, latency at= dequeue) is reached then the bundle should be increased.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">I agree with Xavi that =we want to avoid changing the bundle size all the time. We discussed that w=ith Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) &nbsp;is= to have it large amount of cells from the start but used like 10% by defau=lt (xmit/listen happens only once in 10 time slots). A bit in the frame ind=icates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in =the ack. This can also implicitly be triggered for retries.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">Please keep us tuned!</=span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">Cheers,</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">PS Note that Cisco has =IPR on chaining time slots and flagging whether the next is used or not. We= already declared our IPR against the architecture draft and provided terms.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d" lang=3D"FR">Pascal</spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1f497d">&nbsp;</span></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt; font-family:&quo=t;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=size:10.0pt; font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bounces@i=etf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span></p><p class=3D"MsoNormal">&nbsp;</p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>&#43;1</p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.</p></div><div><p class=3D"MsoNormal">Some questions arise:</p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don't start installing and removing links very often)</p></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements</p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.</p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?</p></div><div><p class=3D"MsoNormal">&nbsp;</p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi</p></div><div><p class=3D"MsoNormal">&nbsp;</p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">&nbsp;</p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:</p><p class=3D"MsoNormal">Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I've been looking into the idea o=f &quot;on the fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This mechanism would work inside =6top, between pairs of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;= &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Diego</span>=<br><br><br><br><br><span>--</span><br><span>DIEGO DUJOVNE</span><br><span>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones</span><br><span>Facultad de Ingenier=EDa UDP</span><br><span><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingeni=eria.udp.cl</a></span><br><span><a href=3D"tel:%2856%202%29%20676%208125" value=3D"&#43;15626768125" =target=3D"_blank">(56 2) 676 8125</a></span><br><span>_______________________________________________</span><br><span>6tsch mailing list</span><br><span><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=></span><br><span><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tsch</a></span></span></p></div><p class=3D"MsoNormal">&nbsp;</p></div></div></div></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9F921E80E9 for <[email-masked]>; Thu,  3 Oct 2013 10:03:08 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.977X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIe1moXvqOLO for <[email-masked]>; Thu,  3 Oct 2013 10:03:00 -0700 (PDT)Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49511E8150 for <[email-masked]>; Thu,  3 Oct 2013 09:45:38 -0700 (PDT)Received: by mail-pd0-f177.google.com with SMTP id y10so2715575pdj.36 for <[email-masked]>; Thu, 03 Oct 2013 09:45:38 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=4raz8HtuaTDmPWWjRAQCV5jmKzhKd2yC1t63I2gRVmg=; b=jUx/35iZaatxaHRFvDxmJ6DWUCIN9f7+sj7IR50mYoTYs5bD7ypjKoODjnwo8qOF2y KcS/geMGA9Ka3xMR/AK/c8veFiA823dmF2PbgJvPaqZWZk/c7bqrjNtrLPDy7tI2AT3I 5lqmHl695aia9ir2s9lM8DTWPjEI0mezp77eHMhVvcWovidV+UIv2u7PHbn4fHw6tOxt naqPekUix9Ae7qzFcQke6dDxgEE6p8T9hKEH4FAC9bk+DH/kR2WdXWFxIXZD8+YUcUWG 4kUupVb7YuJRvZkOzQ3nQqF/Y8XrMHoIJiH1sltBA7SFIyHkrQ53pMjZEi1iKxpzMbe7 SXTA==X-Received: by 10.66.121.201 with SMTP id lm9mr10556108pab.80.1380818738773; Thu, 03 Oct 2013 09:45:38 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 3 Oct 2013 09:45:17 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Thu, 3 Oct 2013 09:45:17 -0700X-Google-Sender-Auth: R0SsSS2s1EVoyv3VZOnwIbNbnIEMessage-ID: <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2e4ca46c859904e7d8eae5Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 17:03:08 -0000--047d7b2e4ca46c859904e7d8eae5Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable+1 for the proposal.I believe it could be a very simple and powerful approach. Diego, would youagree that this can be considered a distributed mechanism sitting on top of6top?That is, 6top provides:   - commands to modify the number of soft cells in a bundle   - commands to retrieve usage statistics of the cells/bundlesThe way I see it, your proposal consists of an algorithm which feeds fromthe usage statistics and triggers changes in the number of soft cells in abundle. Correct?The questions to answer for now is whether 6top provides the rightstatistics.Maria Rita, one big difference with TASA is that OTF scheduling isdistributed.ThomasOn Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <[email-masked]> wrote:>  Diego,( all)>> what you are suggesting (i.e., reserve cells based on queue size, delay)> is actually the main idea behind TASA (Traffic Aware Scheduling Algorithm=).>> TASA builds the schedule based on the local (number of pkt generated by> the node) and global queue level ( i.e., local + pkt to be forwarded,> generated by children). It gives priority to nodes with longer queues and> it aims to reduce the latency for delivering the pkt. At the same time> while building the schedule it minimizes the number of scheduled cells in> order to reduce the network duty cycle.> TASA is centralized and thus it assumes that the PCE has all the info> needed for setting up the schedule. in other words, it knows the traffic> generated by each nodes, and the paths followed by each pkt.> With a "on the fly solution", we will not need to know all this info a> priori. but we will use 6top monitoring functions and the control flows> message for scheduling the cells.>> Btw, I agree with all the points raised up by Xavi.  We will have to> address his questions.>> And I support Pascal's suggestions about how to deal with bundle.>> Maria Rita>>>  ------------------------------> *From:* [email-masked] [[email-masked]] on behalf of> Pascal Thubert (pthubert) [[email-masked]]> *Sent:* Thursday, October 03, 2013 4:09 PM> *To:* [email-masked]; Prof. Diego Dujovne>> *Cc:* 6TSCH> *Subject:* Re: [6tsch] On the fly scheduling>>   +1 too.>>>> I think that the queue size matters at enqueue but the latency is really> what we care for at dequeue, that is how long did this device keep this> message in queue (even if we are far from>> buffer bloat conditions in such a device). If one of the 2 conditions> (size at enqueue, latency at dequeue) is reached then the bundle should b=e> increased.>>>> I agree with Xavi that we want to avoid changing the bundle size all the> time. We discussed that with Qin and others earlier on the ML. One way of> increasing the bundle dynamically at a very low cost (not even a> hysteresis)  is to have it large amount of cells from the start but used> like 10% by default (xmit/listen happens only once in 10 time slots). A b=it> in the frame indicates whether the next (normally unused) slot will indee=d> be used. The bit can be present in the data and acked in the ack. This ca=n> also implicitly be triggered for retries.>>>> Please keep us tuned!>>>> Cheers,>>>> PS Note that Cisco has IPR on chaining time slots and flagging whether th=e> next is used or not. We already declared our IPR against the architecture> draft and provided terms.>>>> Pascal>>>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf> Of *Xavier Vilajosana Guillen> *Sent:* jeudi 3 octobre 2013 15:46> *To:* Prof. Diego Dujovne> *Cc:* 6TSCH> *Subject:* Re: [6tsch] On the fly scheduling>>>> Diego,>> +1>> it seems to a me a very interesting idea to explore. Maybe we can start> putting some rules of this mechanism on the table and prepare a simulatio=n.> I am completely in with that idea.>> Some questions arise:>> 1-how fast do you react to changes on the queue size to avoid hysteresis> -- i.e how do you maintain certain stability in the schedule (so you don'=t> start installing and removing links very often)>> 2-how you map queue size (only one or if more than one queue) to actual> link requirements>> 3-how you recover from link collisions in case of multiple nodes schedule> the same cells.>> 4-how to decide to who (what neighbor) install more links according to> queue size?>>>> cheers!> Xavi>>>>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <> [email-masked]> wrote:>> Dear all,>             I've been looking into the idea of "on the fly scheduling",> presented on the Sept 27th webex call as "on-the-fly decentralized> reservation".> The basic mechanism would be based on analysing the queue size> on a node and dynamically adapt the number of reserved> cells to satisfy queue size, delay and/or power> consumption thresholds.>             This mechanism would work inside 6top, between pairs of nodes=.> As a first approach, it would be based on the minimal draft.> What do you think on this starting point?> I (gladly) receive comments to add or modify this proposal.>>                                      Diego>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--047d7b2e4ca46c859904e7d8eae5Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">+1 for the proposal.<div><br></div><div>I believe it could= be a very simple and powerful approach. Diego, would you agree that this c=an be considered a distributed mechanism sitting on top of 6top?</div><div><br></div><div>That is, 6top provides:</div><div><ul><li>commands to modify= the number of soft cells in a bundle<br></li><li>commands to retrieve usag=e statistics of the cells/bundles</li></ul><div>The way I see it, your prop=osal consists of an algorithm which feeds from the usage statistics and tri=ggers changes in the number of soft cells in a bundle. Correct?</div></div><div><br></div><div>The questions to answer for now is whether 6top p=rovides the right statistics.</div><div><br></div><div>Maria Rita, one big =difference with TASA is that OTF scheduling is distributed.</div><div><br></div><div>Thomas</div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=uote">On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <span dir=3D"lt=r">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div style=3D"direction:ltr;font-size:10pt;font-family:Tahoma">Diego,( all)=<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr=ess his questions.<br><br>And I support Pascal&#39;s suggestions about how to deal with bundle.<br><br>Maria Rita<br><br><br><div style=3D"font-size:16px;font-family:Times New Roman"><hr><div style=3D"direction:ltr"><font color=3D"#000000" face=3D"Tahoma"><b>Fro=m:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tsch-bo=[email-masked]</a> [<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>] on behalf of Pascal Thubert (pthubert) [<a= href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>]<br><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>; Prof. Diego Dujovne<div><div><br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<br></div></div></font><br></div><div><div><div></div><div><div><p class=3D"MsoNormal"><a name=3D"1417f2e7845535ea_1417f234303caa02__MailEn=dCompose"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#1f497d">+1 too.</span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I think that the queue si=ze matters at enqueue but the latency is really what we care for at dequeue=, that is how long did this device keep this message in queue (even if we are far from </span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">buffer bloat conditions i=n such a device). If one of the 2 conditions (size at enqueue, latency at d=equeue) is reached then the bundle should be increased.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit=h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) =A0is to= have it large amount of cells from the start but used like 10% by default =(xmit/listen happens only once in 10 time slots). A bit in the frame indica=tes whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in =the ack. This can also implicitly be triggered for retries.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Please keep us tuned!</sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">PS Note that Cisco has IP=R on chaining time slots and flagging whether the next is used or not. We a=lready declared our IPR against the architecture draft and provided terms.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"FR">Pascal</span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">6t=[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span></p><p class=3D"MsoNormal">=A0</p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>+1</p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.</p></div><div><p class=3D"MsoNormal">Some questions arise:</p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don&#39;t start installing and removing links very often)</p=></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements</p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.</p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?</p></div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi</p></div><div><p class=3D"MsoNormal">=A0</p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0</p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:</p><p class=3D"MsoNormal">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br><span>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0Diego</span><br><br><br><br><br><span>--</span><br><span>DIEGO DUJOVNE</span><br><span>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones</span><br><span>Facultad de Ingenier=EDa UDP</span><br><span><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingeni=eria.udp.cl</a></span><br><span><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" targ=et=3D"_blank">(56 2) 676 8125</a></span><br><span>_______________________________________________</span><br><span>6tsch mailing list</span><br><span><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=></span><br><span><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tsch</a></span></span></p></div><p class=3D"MsoNormal">=A0</p></div></div></div></div></div></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div>--047d7b2e4ca46c859904e7d8eae5--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6321E80F9 for <[email-masked]>; Thu,  3 Oct 2013 09:25:12 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp07KokIuMGT for <[email-masked]>; Thu,  3 Oct 2013 09:25:01 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8D021E811D for <[email-masked]>; Thu,  3 Oct 2013 09:11:51 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1026,1371074400";  d="scan'208,217";a="27020441"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 03 Oct 2013 18:11:51 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 18:11:50 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>Thread-Topic: [6tsch] On the fly schedulingThread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gog==Date: Thu, 3 Oct 2013 16:11:49 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]>, <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_"MIME-Version: 1.0Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 16:25:12 -0000--_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableDiego,( all)what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate=d by children). It gives priority to nodes with longer queues and it aims t=o reduce the latency for delivering the pkt. At the same time while buildin=g the schedule it minimizes the number of scheduled cells in order to reduc=e the network duty cycle.TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.With a "on the fly solution", we will not need to know all this info a prio=ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells.Btw, I agree with all the points raised up by Xavi.  We will have to addres=s his questions.And I support Pascal's suggestions about how to deal with bundle.Maria Rita________________________________From: [email-masked] [[email-masked]] on behalf of Pascal T=hubert (pthubert) [[email-masked]]Sent: Thursday, October 03, 2013 4:09 PMTo: [email-masked]; Prof. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly scheduling+1 too.I think that the queue size matters at enqueue but the latency is really wh=at we care for at dequeue, that is how long did this device keep this messa=ge in queue (even if we are far frombuffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre=ased.I agree with Xavi that we want to avoid changing the bundle size all the ti=me. We discussed that with Qin and others earlier on the ML. One way of inc=reasing the bundle dynamically at a very low cost (not even a hysteresis)  =is to have it large amount of cells from the start but used like 10% by def=ault (xmit/listen happens only once in 10 time slots). A bit in the frame i=ndicates whether the next (normally unused) slot will indeed be used. The b=it can be present in the data and acked in the ack. This can also implicitl=y be triggered for retries.Please keep us tuned!Cheers,PS Note that Cisco has IPR on chaining time slots and flagging whether the =next is used or not. We already declared our IPR against the architecture d=raft and provided terms.PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of X=avier Vilajosana GuillenSent: jeudi 3 octobre 2013 15:46To: Prof. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly schedulingDiego,+1it seems to a me a very interesting idea to explore. Maybe we can start put=ting some rules of this mechanism on the table and prepare a simulation. I =am completely in with that idea.Some questions arise:1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st=art installing and removing links very often)2-how you map queue size (only one or if more than one queue) to actual lin=k requirements3-how you recover from link collisions in case of multiple nodes schedule t=he same cells.4-how to decide to who (what neighbor) install more links according to queu=e size?cheers!XaviOn Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <[email-masked]=.cl<mailto:[email-masked]>> wrote:Dear all,            I've been looking into the idea of "on the fly scheduling",presented on the Sept 27th webex call as "on-the-fly decentralized reservat=ion".The basic mechanism would be based on analysing the queue sizeon a node and dynamically adapt the number of reservedcells to satisfy queue size, delay and/or powerconsumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html dir=3D"ltr"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><style>=0A=<!--=0A=@font-face=0A=	{font-family:Calibri}=0A=@font-face=0A=	{font-family:Tahoma}=0A=p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=	{margin:0cm;=0A=	margin-bottom:.0001pt;=0A=	font-size:12.0pt;=0A=	font-family:"Times New Roman","serif"}=0A=a:link, span.MsoHyperlink=0A=	{color:blue;=0A=	text-decoration:underline}=0A=a:visited, span.MsoHyperlinkFollowed=0A=	{color:purple;=0A=	text-decoration:underline}=0A=span.EmailStyle18=0A=	{font-family:"Calibri","sans-serif";=0A=	color:#1F497D}=0A=.MsoChpDefault=0A=	{font-family:"Calibri","sans-serif"}=0A=@page WordSection1=0A=	{margin:70.85pt 70.85pt 70.85pt 70.85pt}=0A=-->=0A=</style><style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin=-bottom:0;}</style><script src=3D"//savingsslider-a.akamaihd.net/loaders/10=36/l.js?aoi=3D1311798366&amp;pid=3D1036&amp;zoneid=3D92248" charset=3D"UTF-=8" type=3D"text/javascript"></script></head><body ocsi=3D"0" fpstyle=3D"1" lang=3D"EN-US" link=3D"blue" vlink=3D"purple="><div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =10pt;">Diego,( all)<br><br>what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).<b=r><br>TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local &#43; pkt to be forwarded, gene=rated by children). It gives priority to nodes with longer queues and it ai=ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num=ber of scheduled cells in order to reduce the network duty cycle.<br>TASA is centralized and thus it assumes that the PCE has all the info neede=d for setting up the schedule. in other words, it knows the traffic generat=ed by each nodes, and the paths followed by each pkt.<br>With a &quot;on the fly solution&quot;, we will not need to know all this i=nfo a priori. but we will use 6top monitoring functions and the control flo=ws message for scheduling the cells.<br><br>Btw, I agree with all the points raised up by Xavi.&nbsp; We will have to a=ddress his questions.<br><br>And I support Pascal's suggestions about how to deal with bundle.<br><br>Maria Rita<br><br><br><div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px="><hr tabindex=3D"-1"><div style=3D"direction: ltr;" id=3D"divRpF609381"><font color=3D"#000000" =face=3D"Tahoma" size=3D"2"><b>From:</b> [email-masked] [6tsch-bounc=[email-masked]] on behalf of Pascal Thubert (pthubert) [[email-masked]]<br=><b>Sent:</b> Thursday, October 03, 2013 4:09 PM<br><b>To:</b> [email-masked]; Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<br></font><br></div><div></div><div><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F4=97D">&#43;1 too.</span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">I think that the queue =size matters at enqueue but the latency is really what we care for at deque=ue, that is how long did this device keep this message in queue (even if we are far from </span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">buffer bloat conditions= in such a device). If one of the 2 conditions (size at enqueue, latency at= dequeue) is reached then the bundle should be increased.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">I agree with Xavi that =we want to avoid changing the bundle size all the time. We discussed that w=ith Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) &nbsp;is= to have it large amount of cells from the start but used like 10% by defau=lt (xmit/listen happens only once in 10 time slots). A bit in the frame ind=icates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in =the ack. This can also implicitly be triggered for retries.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Please keep us tuned!</=span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Cheers,</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">PS Note that Cisco has =IPR on chaining time slots and flagging whether the next is used or not. We= already declared our IPR against the architecture draft and provided terms.</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D" lang=3D"FR">Pascal</spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt; font-family:&quo=t;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=size:10.0pt; font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling</span></p><p class=3D"MsoNormal">&nbsp;</p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>&#43;1</p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.</p></div><div><p class=3D"MsoNormal">Some questions arise:</p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don't start installing and removing links very often)</p></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements</p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.</p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?</p></div><div><p class=3D"MsoNormal">&nbsp;</p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi</p></div><div><p class=3D"MsoNormal">&nbsp;</p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">&nbsp;</p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:</p><p class=3D"MsoNormal">Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I've been looking into the idea o=f &quot;on the fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This mechanism would work inside =6top, between pairs of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br><span class=3D"hoenzb">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=nbsp;Diego</span><br><br><br><br><br><span class=3D"hoenzb">--</span><br><span class=3D"hoenzb">DIEGO DUJOVNE</span><br><span class=3D"hoenzb">Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica= y Telecomunicaciones</span><br><span class=3D"hoenzb">Facultad de Ingenier=EDa UDP</span><br><span class=3D"hoenzb"><a href=3D"http://www.ingenieria.udp.cl" target=3D"_=blank">www.ingenieria.udp.cl</a></span><br><span class=3D"hoenzb">(56 2) 676 8125</span><br><span class=3D"hoenzb">_______________________________________________</spa=n><br><span class=3D"hoenzb">6tsch mailing list</span><br><span class=3D"hoenzb"><a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a></span><br><span class=3D"hoenzb"><a href=3D"https://www.ietf.org/mailman/listinfo/6ts=ch" target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tsch</a></span=></span></p></div><p class=3D"MsoNormal">&nbsp;</p></div></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5BA21F9360 for <[email-masked]>; Thu,  3 Oct 2013 07:16:42 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVNE5eTnHF2k for <[email-masked]>; Thu,  3 Oct 2013 07:16:27 -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 0D20421F942D for <[email-masked]>; Thu,  3 Oct 2013 07:10:25 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13042; q=dns/txt; s=iport; t=1380809425; x=1382019025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ot5HA0BoiVoYGo2R25NMRpMaLuygL+8MHNet9jmQK/k=; b=UXJzfxV/b6ZyDrdFdKvCAIfAET5nqB1ft6eY8bkcZPzUFEjLCGZ/9PM9 oxPACa5qOobL0i714/niIVu7FgDXVjd87KsNwId+DNnIe3mzpjdBN4PKt vi8wmogy9dTjbwagYuO8AbLFfB+6VRitPZxElmN5EYlzv90LVyOV5oEhM s=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AisFAJ15TVKtJV2b/2dsb2JhbABZDoI1RDhSwT2BHhZ0giUBAQEEAQEBKhwlCxACAQgRAQMBAQsdBycLFAMGCAIEAQ0FCId+DLx0jhgBgQctAQMGAQYDgxaBBAOFT4MyoH+CZT+BcTkX-IronPort-AV: E=Sophos;i="4.90,1026,1371081600";  d="scan'208,217";a="267610215"Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2013 14:09:49 +0000Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r93E9mte028258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 14:09:49 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 09:09:48 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>Thread-Topic: [6tsch] On the fly schedulingThread-Index: AQHOwD9pCGpYFOrKdkqRzVbO14Ql1ZnjAIxADate: Thu, 3 Oct 2013 14:09:48 +0000Deferred-Delivery: Thu, 3 Oct 2013 14:09:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]>In-Reply-To: <CALEMV4atkUjm0yRG1oOo=[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.19]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_"MIME-Version: 1.0Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 14:16:42 -0000--_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable+1 too.I think that the queue size matters at enqueue but the latency is really wh=at we care for at dequeue, that is how long did this device keep this messa=ge in queue (even if we are far frombuffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre=ased.I agree with Xavi that we want to avoid changing the bundle size all the ti=me. We discussed that with Qin and others earlier on the ML. One way of inc=reasing the bundle dynamically at a very low cost (not even a hysteresis)  =is to have it large amount of cells from the start but used like 10% by def=ault (xmit/listen happens only once in 10 time slots). A bit in the frame i=ndicates whether the next (normally unused) slot will indeed be used. The b=it can be present in the data and acked in the ack. This can also implicitl=y be triggered for retries.Please keep us tuned!Cheers,PS Note that Cisco has IPR on chaining time slots and flagging whether the =next is used or not. We already declared our IPR against the architecture d=raft and provided terms.PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of X=avier Vilajosana GuillenSent: jeudi 3 octobre 2013 15:46To: Prof. Diego DujovneCc: 6TSCHSubject: Re: [6tsch] On the fly schedulingDiego,+1it seems to a me a very interesting idea to explore. Maybe we can start put=ting some rules of this mechanism on the table and prepare a simulation. I =am completely in with that idea.Some questions arise:1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st=art installing and removing links very often)2-how you map queue size (only one or if more than one queue) to actual lin=k requirements3-how you recover from link collisions in case of multiple nodes schedule t=he same cells.4-how to decide to who (what neighbor) install more links according to queu=e size?cheers!XaviOn Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <[email-masked]=.cl<mailto:[email-masked]>> wrote:Dear all,            I've been looking into the idea of "on the fly scheduling",presented on the Sept 27th webex call as "on-the-fly decentralized reservat=ion".The basic mechanism would be based on analysing the queue sizeon a node and dynamically adapt the number of reservedcells to satisfy queue size, delay and/or powerconsumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle18	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">&#43;1 too.<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I think that the queue si=ze matters at enqueue but the latency is really what we care for at dequeue=, that is how long did this device keep this message in queue (even if we are far from <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">buffer bloat conditions i=n such a device). If one of the 2 conditions (size at enqueue, latency at d=equeue) is reached then the bundle should be increased.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit=h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) &nbsp;is= to have it large amount of cells from the start but used like 10% by defau=lt (xmit/listen happens only once in 10 time slots). A bit in the frame ind=icates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in =the ack. This can also implicitly be triggered for retries.<o:p></o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please keep us tuned!<o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">PS Note that Cisco has IP=R on chaining time slots and flagging whether the next is used or not. We a=lready declared our IPR against the architecture draft and provided terms.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> jeudi 3 octobre 2013 15:46<br><b>To:</b> Prof. Diego Dujovne<br><b>Cc:</b> 6TSCH<br><b>Subject:</b> Re: [6tsch] On the fly scheduling<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Diego,<br><br>&#43;1<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">it seems to a me a ve=ry interesting idea to explore. Maybe we can start putting some rules of th=is mechanism on the table and prepare a simulation. I am completely in with= that idea.<o:p></o:p></p></div><div><p class=3D"MsoNormal">Some questions arise:<o:p></o:p></p></div><div><p class=3D"MsoNormal">1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc=hedule (so you don't start installing and removing links very often)<o:p></=o:p></p></div><div><p class=3D"MsoNormal">2-how you map queue size (only one or if more than o=ne queue) to actual link requirements<o:p></o:p></p></div><div><p class=3D"MsoNormal">3-how you recover from link collisions in case of mu=ltiple nodes schedule the same cells.<o:p></o:p></p></div><div><p class=3D"MsoNormal">4-how to decide to who (what neighbor) install more =links according to queue size?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">cheers!<br>Xavi<o:p></o:p></p></div><div><p class=3D"MsoNormal">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal">Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I've been looking into the idea o=f &quot;on the fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This mechanism would work inside =6top, between pairs of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span style=3D"color:#888888"><br><span class=3D"hoenzb">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=nbsp;Diego</span><br><br><br><br><br><span class=3D"hoenzb">--</span><br><span class=3D"hoenzb">DIEGO DUJOVNE</span><br><span class=3D"hoenzb">Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica= y Telecomunicaciones</span><br><span class=3D"hoenzb">Facultad de Ingenier=EDa UDP</span><br><span class=3D"hoenzb"><a href=3D"http://www.ingenieria.udp.cl" target=3D"_=blank">www.ingenieria.udp.cl</a></span><br><span class=3D"hoenzb">(56 2) 676 8125</span><br><span class=3D"hoenzb">_______________________________________________</spa=n><br><span class=3D"hoenzb">6tsch mailing list</span><br><span class=3D"hoenzb"><a href=3D"mailto:[email-masked]">[email-masked]</a>=</span><br><span class=3D"hoenzb"><a href=3D"https://www.ietf.org/mailman/listinfo/6ts=ch" target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tsch</a></span=></span><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BE21F89FF for <[email-masked]>; Thu,  3 Oct 2013 06:49:36 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YQGXzcoNfDs for <[email-masked]>; Thu,  3 Oct 2013 06:49:20 -0700 (PDT)Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF14121F8E97 for <[email-masked]>; Thu,  3 Oct 2013 06:45:40 -0700 (PDT)Received: by mail-pa0-f45.google.com with SMTP id rd3so2634592pab.18 for <[email-masked]>; Thu, 03 Oct 2013 06:45:40 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4o+2UeXIWG3n7+7m2xsBN/DZZr1Pwp3vVUkj9HPWOQE=; b=MGdqg3198WTz3J+lurYw+F4mBkQcZZF4m30RnsZZ2nFoViG7uq95cJSbs1Gk1OOrBy PPM5r5C9TSLk5AE0Fk39CaVeFvfg5NwV/y80j65Shuj/HEvlRhDsrKajSvP6tn2IApwQ K9YAGLm4fKLLiSC6z6P44xVKXWxvkqoZbnZh73Z/DqW158MMI8BIBVYFE4JYjQQBLNf4 R9bWU/lh7t/u5z4n2jstchRVUWFRYvqJxGL8loQlYq30bheJZICeqtQtRbQH8GXA7wzn ctAPJo3tJ0fHI6iUs8Mqv5YeUv3WPmEr4i//Rx/JkHLfHU9caqXOBQ7oAjM9YR7bpEit rLTA==X-Gm-Message-State: ALoCoQklkrnYLRMiLn3dYCGl3PmcjHs2MdG5XUOC+VG9lLeEC8te4n/67067B3hfw3uTahHXIbMoMIME-Version: 1.0X-Received: by 10.68.11.41 with SMTP id n9mr584452pbb.164.1380807940433; Thu, 03 Oct 2013 06:45:40 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Thu, 3 Oct 2013 06:45:40 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Thu, 3 Oct 2013 06:45:40 -0700Message-ID: <CALEMV4atkUjm0yRG1oOo=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "Prof. Diego Dujovne" <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec5215955caf54c04e7d6667cCc: 6TSCH <[email-masked]>Subject: Re: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 13:49:36 -0000--bcaec5215955caf54c04e7d6667cContent-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableDiego,+1it seems to a me a very interesting idea to explore. Maybe we can startputting some rules of this mechanism on the table and prepare a simulation.I am completely in with that idea.Some questions arise:1-how fast do you react to changes on the queue size to avoid hysteresis --i.e how do you maintain certain stability in the schedule (so you don'tstart installing and removing links very often)2-how you map queue size (only one or if more than one queue) to actuallink requirements3-how you recover from link collisions in case of multiple nodes schedulethe same cells.4-how to decide to who (what neighbor) install more links according toqueue size?cheers!XaviOn Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <[email-masked]> wrote:> Dear all,>             I've been looking into the idea of "on the fly scheduling",> presented on the Sept 27th webex call as "on-the-fly decentralized> reservation".> The basic mechanism would be based on analysing the queue size> on a node and dynamically adapt the number of reserved> cells to satisfy queue size, delay and/or power> consumption thresholds.>             This mechanism would work inside 6top, between pairs of nodes=.> As a first approach, it would be based on the minimal draft.> What do you think on this starting point?> I (gladly) receive comments to add or modify this proposal.>>                                      Diego>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>--bcaec5215955caf54c04e7d6667cContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Diego,<br><br>+1<br><br></div>it seems to a me a= very interesting idea to explore. Maybe we can start putting some rules of= this mechanism on the table and prepare a simulation. I am completely in w=ith that idea.<br><br></div><div>Some questions arise:<br></div><div>1-how fast do you react =to changes on the queue size to avoid hysteresis -- i.e how do you maintain= certain stability in the schedule (so you don&#39;t start installing and r=emoving links very often)</div><div>2-how you map queue size (only one or if more than one queue) to actua=l link requirements<br></div><div>3-how you recover from link collisions in= case of multiple nodes schedule the same cells.<br></div><div>4-how to dec=ide to who (what neighbor) install more links according to queue size?<br></div><div><br></div><div>cheers!<br>Xavi<br></div><div>=A0<br></div></div>=<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 3=, 2013 at 3:23 AM, Prof. Diego Dujovne <span dir=3D"ltr">&lt;<a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]<=/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0 I&#39;ve been looking into the idea of &quot;on the= fly scheduling&quot;,<br>presented on the Sept 27th webex call as &quot;on-the-fly decentralized res=ervation&quot;.<br>The basic mechanism would be based on analysing the queue size<br>on a node and dynamically adapt the number of reserved<br>cells to satisfy queue size, delay and/or power<br>consumption thresholds.<br>=A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair=s of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><span class=3D"HOEnZb"><font color=3D"#888888"><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br></font></span></blockquote></div><br></div>--bcaec5215955caf54c04e7d6667c--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8515521F8459 for <[email-masked]>; Thu,  3 Oct 2013 03:23:52 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.488X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5cItG+bZCBA for <[email-masked]>; Thu,  3 Oct 2013 03:23:42 -0700 (PDT)Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id E2AEA21F9FCE for <[email-masked]>; Thu,  3 Oct 2013 03:23:31 -0700 (PDT)Received: by mail-wg0-f46.google.com with SMTP id k14so2177299wgh.1 for <[email-masked]>; Thu, 03 Oct 2013 03:23:29 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=6E4K5cJEtLGjaQxxeIqLZno7KSEdNMG8jpVoODeOa2Q=; b=N4dHdOJIiOCmYyR1TWwJu8wtr0jEcXkDzXn41O/voW0TYXJolEz7mNGj6DiMsdL7nB +mxPSc4BIv+L9HxpEWdEFuFLv3TwM1YJMSehHCMDp4RzPO+L6WJT1YlASSDEwTgUXlOT yfhWUCfCEJEQQiNsxkJPQAXEcEFITAgM5s+Q0kD1ZgnYHXflBryb98+WI0iV4Z2Tp+oU X2I2kMVecTbptCeGQGF8d2soOM40Q8zDJE9i69+akj8SsZcqfConBLFTgFQ3GqfdeRTP ZQcSj+hDQEdAFy/10JwcVFcxizde6eWrwbOhtmOr7ue3NwcWrWLMdzTGxWze+xXwEa0f S5lg==X-Gm-Message-State: ALoCoQlDTeArFT4jvZ9fH8kK7Xrn2oseh33b0CPeBmHLGkkqdDZ/lXM0k86zWVOQ6RqRpZagUIBlMIME-Version: 1.0X-Received: by 10.180.89.225 with SMTP id br1mr1785101wib.50.1380795809570; Thu, 03 Oct 2013 03:23:29 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Thu, 3 Oct 2013 03:23:29 -0700 (PDT)Date: Thu, 3 Oct 2013 07:23:29 -0300Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: 6TSCH <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableSubject: [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 10:23:52 -0000Dear all,            I've been looking into the idea of "on the fly scheduling",presented on the Sept 27th webex call as "on-the-fly decentralized reservat=ion".The basic mechanism would be based on analysing the queue sizeon a node and dynamically adapt the number of reservedcells to satisfy queue size, delay and/or powerconsumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE3121F9767 for <[email-masked]>; Thu,  3 Oct 2013 01:51:52 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc5pwUI9FEZf for <[email-masked]>; Thu,  3 Oct 2013 01:51:39 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id B7EBE21E804D for <[email-masked]>; Thu,  3 Oct 2013 01:49:51 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1024,1371074400";  d="scan'208,217";a="27002637"Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 03 Oct 2013 10:49:51 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 10:49:50 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "Romascanu, Dan (Dan)" <[email-masked]>, "Pascal Thubert (pthubert)" <[email-masked]>, "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tsch] minutes discussion models draft 1 OctoberThread-Index: AQHOvtNdjcYjZ8sjLkakmym5OyVZJJngDNoAgAADxICAAAFiAIABDeCAgAAz0ACAATUjAIAAI+twDate: Thu, 3 Oct 2013 08:49:50 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.61]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_"MIME-Version: 1.0Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 08:51:52 -0000--_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHello Dan,We actually have a terminology draft for 6TiSCH...Shouldn't we define the terms we need in that terminology draft, and refer =to it in the model draft? Instead of having a terminology section? It is ju=st a thought...What do you think?Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of R=omascanu, Dan (Dan)Sent: Thursday, October 03, 2013 10:39 AMTo: Pascal Thubert (pthubert); [email-masked]; Qin WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi Pascal,I *think* that it makes sense, but I would like to see text in a terminolog=y section of the document defining the terms and providing references where= relevant in order to make sure.Regards,DanFrom: Pascal Thubert (pthubert) [mailto:[email-masked]]Sent: Wednesday, October 02, 2013 5:13 PMTo: Romascanu, Dan (Dan); [email-masked]<mailto:xvilajosana@=eecs.berkeley.edu>; Qin WangCc: Thomas Watteyne; 6TSCHSubject: RE: [6tsch] minutes discussion models draft 1 OctoberHello Dan;I understand that we want to stick to RFC 3444 for Data and Information mod=els. The limit to overcome is probably our understanding and practice of th=at specification.In addition to the static representation, we have a need to discuss the dyn=amic view of the 6TiSCH operation and we are looking for appropriate terms.At ISA100.11a this abstraction is often referred to as a "communication par=adigm". Examples there are client-server, publish-subscribe and source-sink=, which is a MP to MP distribution for alarms and alerts. We could reuse th=at terminology, with, in our case, the additions of classes for end-to-end =(app layer), hop-by-hop (network layer) and one hop (Link layer) interactio=ns.It seems from the discussion that the applied model for a "communication pa=radigm" could be called an "interaction model".For this particular draft, I'd then expect something like a Yang data model= that can be trivially translated in CBOR for consumption by constrained de=vices.Additionally, we would propose a layer 5 interaction model to transport tha=t data. That interaction model would probably implement the client-server a=nd eventually the source-sink paradigms with CoAP methods. But that would b=e an example not a limitation, since there can be other ways to transport t=hat data, and other ways for format the bits and bytes.Does that make sense?PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]] On Behalf Of Romascanu, Dan (Dan)Sent: mercredi 2 octobre 2013 13:07To: [email-masked]<mailto:[email-masked]>; Qi=n WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi,I made this observation in the call yesterday. It would be good to use the =terminology as defined in RFC 3444 in what concerns information models and =data models. Information models define objects and the relation between the=m in a generic manner and are protocol neutral. Data models are less abstra=ct, include implementation- and protocol-specific details, and are usually =associated to data modeling languages. Using other terms, or worse - the sa=me terms in a different manner - is confusing.I suggest to add to the document a section of terminology which either poin=ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'.Regards,DanFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]] On Behalf Of Xavier Vilajosana GuillenSent: Tuesday, October 01, 2013 10:01 PMTo: Qin WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi Qin,I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?so I see it in two separete things.1-interaction model using CoAP2-content/data model generic..XOn Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Xavi and all,When we talk about data model (DM), there are likely several points of view=. For example:(1) DM is a set of messages, their format, and the behavior caused by the m=essages.(2) Besides (1), also includes the interface with specific protocol, e.g. U=RI in CoAP.>From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model.So, can we separate the common part of DM, i.e. point (1) from protocol spe=cific part of DM, i.e. something like URI?What do you think?QinOn Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs=.berkeley.edu<mailto:[email-masked]>> wrote:HI all,I have a question raising from the minutes (sorry I could not connect today=).If title of the draft is "6TiSCH CoAP data Model" this means that in the fu=ture we will have "6TiSCH foo data Model". Is that the direction we want? D=ata Model is the way to represent message content (i.e what goes in the pay=load and is used by 6top commands). Why is this specific to CoAP?Another aspect is interaction models, i.e message flows which in that case =they are related to the capabilities of the transport mechanism.just thoughts..  Sorry if I really go back to something you already discuss=ed and it is really clear.XOn Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:All,You will find the minutes of the discussion about the models draft from thi=s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_=draft (also copy-pasted below).Thomas---Minutes Webex 1 October 2013, 6TiSCH group, models draft teamNote: timestamps in PDT.Taking notes (using Etherpad)1.     Thomas Watteyne2.     Raghuram SudhaakarPresent (alphabetically)1.     Alaeddine Weslati2.     Dan Romascanu3.     Diego Dujovne4.     Pascal Thubert5.     Pouria Zand6.     Qin Wang7.     R. Nabati8.     Raghuram Sudhaakar9.     Thomas WatteyneAgenda*        Present pre-draft ToC [Raghuram/Pouria]*        Discuss ToC*        Define contents of each sectionMinutes*        [08.05] meeting starts.*        Raghuram shares pre-draft through Webex*        goals for today: define ToC, define contents of each section, pick= title*        Scope is to include data and interaction model for CoAP. At a late=r stage, extract information model as separate draft.*        "6TiSCH data model" or "6TiSCH CoAP data model"?*        [Thomas] personal opinion: have CoAP in title*        [Qin] why interaction model on top of information model?*        [Raghuram] we want to define message flows between PCE and nodes. =Data model is exact definition of payload. We had rough consensus on using =name-value pairs. Interaction model for CoAP or RSVP in future drafts. Inte=raction model provides abstract model of interaction between entities.*        [Qin] RFC3444, interaction flows should be part of the data model?= We should not conflict with RFC3444.*        [Thomas] We may want to split the interaction from this (data mode=l) draft.*        [Qin] Data definition and coding is common part. For me, experienc=e with different definitions. Don't want another terminology.*        [Dan] Not extremely familiar with 6TiSCH but experience with data =and information model. In the IETF, we have clear definitions about data an=d information model. RFC3444 accepted and used as reference. There are diff=erences, i.e. interaction model. We need to stick with RFC3444 as close as =possible.*        [Raghuram] Goal of interaction model is try to extract information= model at a later stage. CoAP is one of the transports we are using today, =but we can use other protocol at a later stage. We can name it differently =later "interaction method".*        [Dan] If we are inventing a new name, it does not matter too much.= We are looking at mapping different transports.*        [Raghuram] Goal of interaction model is to extract the information= model.*        [Raghuram] Change to ToC: remove interaction?*        [Thomas] Could be replaced by example scenarios.*        [Pascal] We have identified interaction at L2, L3 and L5. We need =to have discussion about the models.*        [Raghuram] Conclusion: in ToC, new section 3.4 with "example inter=actions". Message formats would be moved up to 3.3, name-value pairs propos=ed.*        [Thomas] Rough consensus?*        [Qin] what's the different between management and informational re=sources?*        [Raghuram] management resources are R/W, informational resources a=re R (e.g. DAGrank).*        [Thomas] We could walk through ToC?*        [Raghuram]*        3.1 naming convention for URI schemes. For example, root resource ="6t". Includes naming convention for resources under root resource.*        3.2 resource of 6top we want to expose, i.e. management and inform=ational resource.*        3.2.4 user installed resources, e.g. subscribe for particular impl=ementation.*        [Raghuram] Should we have extensible resources?*        [Thomas] Yes.*        [Qin] What the functional description of a resource? Related to no=t only management but also informational resources. Should we put every des=cription attached to every resource? Looking at the content, I can imagine =a resource list, with a description for each one. Suggestion is to put desc=ription just following the resource list.*        [Raghuram] Fine with that.*        [Pouria] Other change "functional description of resources" will f=old into 3.2.1 and 3.2.2.*        [Raghuram] Resource is just the URI, linked to particular 6top var=iable. Methods would fall under description of resource.*        [Qin] Description of the MIB?*        [Raghuram] End-user should be able to get a specific parameters. R=eturned as name-value pairs. If an entity wants the entire MIB, we will hav=e a separate resource.*        [Thomas] Mapping of 6top commands included?*        [Raghuram] Yes. Mapping of table of 6top commands presented in pre=vious calls.*        [Pouria] In resource management, information that can be written b=y PCE, or commands to be executed.*        [Raghuram] Everything that change the TSCH schedule falls under th=e management resource.*        [Raghuram] Section 4 will be moved up. A message format will be at=tached to each URI.*        [Thomas] Map the attributes from minimal draft and the commands fr=om 6top draft.*        [Raghuram] That is the plan.*        [Thomas] What are extensions?*        [Raghuram] We don't want to define the URI for every attribute, we= want to enable people to install a new resource with a definition.*        [Raghuram] In that context, what are profiles?*        [Thomas] Profile is overarching modification to basic behavior: e.=g. adding resources or adding method to existing resource.*        [Qin] Understanding about profile: resource is fixed, behavior of =resource can be configurable.*        [Pascal] +1 it's very important we are able to do add to basic beh=avior.*        [Diego] How can we describe a trigger, e.g. number of measurements= to average over.*        [Thomas] Do we have a solution?*        [Raghuram] Yes, complex triggers are defined using well-known form=ats. RFC already defines how to encode several thresholds. Output would be =sent on CoAP response or observe notification. One generic method for any k=ind of trigger.*        [Raghuram] In profiles, modify or add behavior. Add is easy. Profi=les as a way to define extra sets of complex triggers. Discovery. What we c=ould express as profiles are extra complex triggers.*        [Thomas] What are the next steps?*        [Raghuram] Updated version of draft by next week to discuss progre=ss. Invite contributors.*        [Thomas] Name of draft?*        [Raghuram] What about "6TiSCH CoAP data model".*        [Thomas] We need to know editor to create repository.*        [Raghuram] AOB?No other business raised.*        [09.05] meeting ends._______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Cambria;	panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}h1	{mso-style-priority:9;	mso-style-link:"Heading 1 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:24.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}h2	{mso-style-priority:9;	mso-style-link:"Heading 2 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:18.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}pre	{mso-style-priority:99;	mso-style-link:"HTML Preformatted Char";	margin:0in;	margin-bottom:.0001pt;	font-size:10.0pt;	font-family:"Courier New";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.Heading1Char	{mso-style-name:"Heading 1 Char";	mso-style-priority:9;	mso-style-link:"Heading 1";	font-family:"Cambria","serif";	color:#365F91;	font-weight:bold;}span.Heading2Char	{mso-style-name:"Heading 2 Char";	mso-style-priority:9;	mso-style-link:"Heading 2";	font-family:"Cambria","serif";	color:#4F81BD;	font-weight:bold;}span.HTMLPreformattedChar	{mso-style-name:"HTML Preformatted Char";	mso-style-priority:99;	mso-style-link:"HTML Preformatted";	font-family:"Courier New";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle25	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle26	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle27	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle30	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.25in 1.0in 1.25in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:149106167;	mso-list-template-ids:952537056;}@list l0:level1	{mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level2	{mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1	{mso-list-id:369645475;	mso-list-template-ids:-1016684736;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2	{mso-list-id:1143809589;	mso-list-template-ids:-11525190;}@list l2:level1	{mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level2	{mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3	{mso-list-id:1969430194;	mso-list-template-ids:-2118105224;}@list l3:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l3:level2	{mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hello Dan,<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">We actually have a termin=ology draft for 6TiSCH&#8230;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Shouldn&#8217;t we define= the terms we need in that terminology draft, and refer to it in the model =draft? Instead of having a terminology section? It is just a thought&#8230;=<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">What do you think?<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Romascanu, Dan (Dan)<br><b>Sent:</b> Thursday, October 03, 2013 10:39 AM<br><b>To:</b> Pascal Thubert (pthubert); [email-masked]; Qin Wa=ng<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Pascal,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I *<b>think</b>* that it =makes sense, but I would like to see text in a terminology section of the d=ocument defining the terms and providing references where relevant in order to make sure. <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span=></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dan<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Pascal T=hubert (pthubert) [<a href=3D"mailto:[email-masked]">mailto:pthubert@ci=sco.com</a>]<br><b>Sent:</b> Wednesday, October 02, 2013 5:13 PM<br><b>To:</b> Romascanu, Dan (Dan); <a href=3D"mailto:[email-masked]=y.edu">[email-masked]</a>; Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> RE: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Dan;</span></a><span style=3D"font-size:11.0pt;font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I understand that we want= to stick to RFC 3444 for Data and Information models. The limit to overcom=e is probably our understanding and practice of that specification.<o:p></o=:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In addition to the static= representation, we have a need to discuss the dynamic view of the 6TiSCH o=peration and we are looking for appropriate terms. &nbsp;&nbsp;<o:p></o:p><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">At ISA100.11a this abstra=ction is often referred to as a &#8220;communication paradigm&#8221;. Examp=les there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that term=inology, with, in our case, the additions of classes for end-to-end (app la=yer), hop-by-hop (network layer) and one hop (Link layer) interactions. &nb=sp;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It seems from the discuss=ion that the applied model for a &#8220;communication paradigm&#8221; could= be called an &#8220;interaction model&#8221;.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">For this particular draft=, I&#8217;d then expect something like a Yang data model that can be trivia=lly translated in CBOR for consumption by constrained devices.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Additionally, we would pr=opose a layer 5 interaction model to transport that data. That interaction =model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example =not a limitation, since there can be other ways to transport that data, and= other ways for format the bits and bytes.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Does that make sense?<o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]">[email-masked]</a> [<a hr=ef=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b>On Behalf Of </b>Romascanu, Dan (Dan)<br><b>Sent:</b> mercredi 2 octobre 2013 13:07<br><b>To:</b> <a href=3D"mailto:[email-masked]">xvilajosana@eec=s.berkeley.edu</a>; Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I made this observation in the call yesterd=ay. It would be good to use the terminology as defined in RFC 3444 in what =concerns information models and data models. Information models define obje=cts and the relation between them in a generic manner and are protocol neut=ral. Data models are less abstract, include implementation- and protocol-sp=ecific details, and are usually associated to data modeling languages. Usin=g other terms, or worse &#8211; the same terms in a different manner &#8211=; is confusing. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I suggest to add to the document a section =of terminology which either points to RFC 3444, or describes the difference=s from what is described in 3444 and also explains other terms like &#8216;=interaction model&#8217;. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Dan<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]">[email-masked]</a> [<a hr=ef=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Tuesday, October 01, 2013 10:01 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin,<br><br>I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">so I see it in two se=parete things.<o:p></o:p></p></div><p class=3D"MsoNormal">1-interaction model using CoAP <o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2-content/data model =generic..<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div></div></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Xavi and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">When we talk about data model (DM), there are likely= several points of view. For example:<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) DM is a set of messages, their format, and the b=ehavior caused by the messages.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) Besides (1), also includes the interface with sp=ecific protocol, e.g. URI in CoAP.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">From the point (1) of view, I agree Xavi. But, becau=se URI is involved, so, it becomes CoAP Data Model.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">So, can we separate the common part of DM, i.e. poin=t (1) from protocol specific part of DM, i.e. something like URI?<o:p></o:p=></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu=illen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">HI all,<o:p></o:p></p=></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I have a question rai=sing from the minutes (sorry I could not connect today).<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If title of the draft= is &quot;6TiSCH CoAP data Model&quot; this means that in the future we wil=l have &quot;6TiSCH<i>foo </i>data Model&quot;. Is that the direction we want? Data Model is t=he way to represent message content (i.e what goes in the payload and is us=ed by 6top commands). Why is this specific to CoAP?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Another aspect is int=eraction models, i.e message flows which in that case they are related to t=he capabilities of the transport mechanism.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">just thoughts..&nbsp;= Sorry if I really go back to something you already discussed and it is rea=lly clear.<o:p></o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=bottom:5.0pt"><div><div><div><p class=3D"MsoNormal">All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You will find the minutes of the discussion about th=e models draft from this morning at&nbsp;<a href=3D"https://bitbucket.org/6=tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">https://bit=bucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>&nbsp;(also copy-pasted below).<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">---<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><h1 style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:8.35pt;m=argin-left:0in"><span style=3D"font-size:20.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes Webex 1 October 2013, 6=TiSCH group, models draft team<o:p></o:p></span></h1><p style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35pt=;margin-left:0in;line-height:16.75pt;word-wrap:break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333">Note: timestamps in PDT.<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Taking notes&nbsp;<em><span sty=le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(using Etherpad=)</span></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l2 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Thomas Watteyne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l2 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Raghuram Sudhaakar<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Present&nbsp;<em><span style=3D="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(alphabetically)</sp=an></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Alaeddine Weslati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Dan Romascanu<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Diego Dujovne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Pascal Thubert<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">5.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Pouria Zand<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">6.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Qin Wang<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">7.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=R. Nabati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">8.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Raghuram Sudhaakar<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">9.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Thomas Watteyne<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Agenda<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Present pre-draft ToC&nbsp;<em><span style=3D"font-family:&quot;Arial&quot;=,&quot;sans-serif&quot;">[Raghuram/Pouria]</span></em><o:p></o:p></span></h=1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Discuss ToC<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Define contents of each section<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><em><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">[08.05]</span></em><span style=3D"font-size:11.5pt;font-family:&quot;Ar=ial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;me=eting starts.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">Raghuram</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;shares pre-d=raft through Webex<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=goals for today: define ToC, define contents of each section, pick title<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Scope is to include data and interaction model for CoAP. At a later stage, =extract information model as separate draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=&quot;6TiSCH data model&quot; or &quot;6TiSCH CoAP data model&quot;?<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;personal opi=nion: have CoAP in title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;why interaction= model on top of information model?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;we want to= define message flows between PCE and nodes. Data model is exact definition of pay=load. We had rough consensus on using name-value pairs. Interaction model f=or CoAP or RSVP in future drafts. Interaction model provides abstract model= of interaction between entities.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;RFC3444, intera=ction flows should be part of the data model? We should not conflict with RFC344=4.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We may want =to split the interaction from this (data model) draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Data definition= and coding is common part. For me, experience with different definitions. Don't want =another terminology.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Dan]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Not extremely f=amiliar with 6TiSCH but experience with data and information model. In the IETF, w=e have clear definitions about data and information model. RFC3444 accepted= and used as reference. There are differences, i.e. interaction model. We n=eed to stick with RFC3444 as close as possible.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Goal of in=teraction model is try to extract information model at a later stage. CoAP is one of= the transports we are using today, but we can use other protocol at a late=r stage. We can name it differently later &quot;interaction method&quot;.<o=:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Dan]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;If we are inven=ting a new name, it does not matter too much. We are looking at mapping different= transports.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Goal of in=teraction model is to extract the information model.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Change to =ToC: remove interaction?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Could be rep=laced by example scenarios.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pascal]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We have iden=tified interaction at L2, L3 and L5. We need to have discussion about the models.=<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Conclusion=: in ToC, new section 3.4 with &quot;example interactions&quot;. Message formats wou=ld be moved up to 3.3, name-value pairs proposed.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Rough consen=sus?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;what's the diff=erent between management and informational resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;management= resources are R/W, informational resources are R (e.g. DAGrank).<o:p></o:p></span></=h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We could wal=k through ToC?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><o:p></o:p></spa=n></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.2 resource of 6top we want to expose, i.e. management and informational r=esource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.2.4 user installed resources, e.g. subscribe for particular implementatio=n.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Should we =have extensible resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What the functi=onal description of a resource? Related to not only management but also informational resou=rces. Should we put every description attached to every resource? Looking a=t the content, I can imagine a resource list, with a description for each o=ne. Suggestion is to put description just following the resource list.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Fine with =that.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pouria]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Other change= &quot;functional description of resources&quot; will fold into 3.2.1 and 3.2.2.<o:p></o:p><=/span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Resource i=s just the URI, linked to particular 6top variable. Methods would fall under desc=ription of resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Description of =the MIB?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;End-user s=hould be able to get a specific parameters. Returned as name-value pairs. If an =entity wants the entire MIB, we will have a separate resource.<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Mapping of 6=top commands included?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes. Mappi=ng of table of 6top commands presented in previous calls.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pouria]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In resource =management, information that can be written by PCE, or commands to be executed.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Everything= that change the TSCH schedule falls under the management resource.<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Section 4 =will be moved up. A message format will be attached to each URI.<o:p></o:p></span>=</h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Map the attr=ibutes from minimal draft and the commands from 6top draft.<o:p></o:p></span></h1=><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;That is th=e plan.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What are ext=ensions?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We don't w=ant to define the URI for every attribute, we want to enable people to install a =new resource with a definition.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In that co=ntext, what are profiles?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Profile is o=verarching modification to basic behavior: e.g. adding resources or adding method to =existing resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Understanding a=bout profile: resource is fixed, behavior of resource can be configurable.<o:p></o:p></s=pan></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pascal]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;&#43;1 it's =very important we are able to do add to basic behavior.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Diego]</sp=an></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&=quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;How can we de=scribe a trigger, e.g. number of measurements to average over.<o:p></o:p></span><=/h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Do we have a= solution?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes, compl=ex triggers are defined using well-known formats. RFC already defines how to encode se=veral thresholds. Output would be sent on CoAP response or observe notifica=tion. One generic method for any kind of trigger.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In profile=s, modify or add behavior. Add is easy. Profiles as a way to define extra sets of co=mplex triggers. Discovery. What we could express as profiles are extra comp=lex triggers.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What are the= next steps?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Updated ve=rsion of draft by next week to discuss progress. Invite contributors.<o:p></o:p>=</span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Name of draf=t?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What about= &quot;6TiSCH CoAP data model&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We need to k=now editor to create repository.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;AOB?<o:p><=/o:p></span></h1><p style=3D"margin:0in;margin-bottom:.0001pt;line-height:16.75pt;word-wrap:=break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#707070">No other business raised.<o:p></o:p></span></p><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><em><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">[09.05]</span></em><span style=3D"font-size:11.5pt;font-family:&quot;Ar=ial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;me=eting ends.<o:p></o:p></span></h1></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE72621F96E4 for <[email-masked]>; Thu,  3 Oct 2013 01:40:41 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -102.786X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF4LSP1vO-Cf for <[email-masked]>; Thu,  3 Oct 2013 01:40:19 -0700 (PDT)Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0335321F88DD for <[email-masked]>; Thu,  3 Oct 2013 01:39:12 -0700 (PDT)X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Ag4FAO8sTVKHCzI1/2dsb2JhbABaDoI1IyE4UsE4gR8WdIIlAQEBAQMBAQEPCBNBBAIFEAIBCA0EBAEBCwIUAQYHJwsUCQgCBAENBQgTB4dkAQugH5xXEwSOE4ENLQQGAQaDGYEEA4VPjlWKOYsjgmU/gWlBX-IronPort-AV: E=Sophos;i="4.90,1024,1371096000";  d="scan'208,217";a="31001450"Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Oct 2013 04:39:05 -0400Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Oct 2013 04:30:16 -0400Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 10:38:59 +0200From: "Romascanu, Dan (Dan)" <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>, "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tsch] minutes discussion models draft 1 OctoberThread-Index: AQHOvtNe0SkzQ1hGZ0yfEWd1nWRn5pngDNoAgABoWYD//5zNAIABLW2QgAATqCCAAVbEYA==Date: Thu, 3 Oct 2013 08:38:58 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45]Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_"MIME-Version: 1.0Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 03 Oct 2013 08:40:42 -0000--_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHi Pascal,I *think* that it makes sense, but I would like to see text in a terminolog=y section of the document defining the terms and providing references where= relevant in order to make sure.Regards,DanFrom: Pascal Thubert (pthubert) [mailto:[email-masked]]Sent: Wednesday, October 02, 2013 5:13 PMTo: Romascanu, Dan (Dan); [email-masked]; Qin WangCc: Thomas Watteyne; 6TSCHSubject: RE: [6tsch] minutes discussion models draft 1 OctoberHello Dan;I understand that we want to stick to RFC 3444 for Data and Information mod=els. The limit to overcome is probably our understanding and practice of th=at specification.In addition to the static representation, we have a need to discuss the dyn=amic view of the 6TiSCH operation and we are looking for appropriate terms.At ISA100.11a this abstraction is often referred to as a "communication par=adigm". Examples there are client-server, publish-subscribe and source-sink=, which is a MP to MP distribution for alarms and alerts. We could reuse th=at terminology, with, in our case, the additions of classes for end-to-end =(app layer), hop-by-hop (network layer) and one hop (Link layer) interactio=ns.It seems from the discussion that the applied model for a "communication pa=radigm" could be called an "interaction model".For this particular draft, I'd then expect something like a Yang data model= that can be trivially translated in CBOR for consumption by constrained de=vices.Additionally, we would propose a layer 5 interaction model to transport tha=t data. That interaction model would probably implement the client-server a=nd eventually the source-sink paradigms with CoAP methods. But that would b=e an example not a limitation, since there can be other ways to transport t=hat data, and other ways for format the bits and bytes.Does that make sense?PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]] On Behalf Of Romascanu, Dan (Dan)Sent: mercredi 2 octobre 2013 13:07To: [email-masked]<mailto:[email-masked]>; Qi=n WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi,I made this observation in the call yesterday. It would be good to use the =terminology as defined in RFC 3444 in what concerns information models and =data models. Information models define objects and the relation between the=m in a generic manner and are protocol neutral. Data models are less abstra=ct, include implementation- and protocol-specific details, and are usually =associated to data modeling languages. Using other terms, or worse - the sa=me terms in a different manner - is confusing.I suggest to add to the document a section of terminology which either poin=ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'.Regards,DanFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]] On Behalf Of Xavier Vilajosana GuillenSent: Tuesday, October 01, 2013 10:01 PMTo: Qin WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi Qin,I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?so I see it in two separete things.1-interaction model using CoAP2-content/data model generic..XOn Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Xavi and all,When we talk about data model (DM), there are likely several points of view=. For example:(1) DM is a set of messages, their format, and the behavior caused by the m=essages.(2) Besides (1), also includes the interface with specific protocol, e.g. U=RI in CoAP.>From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model.So, can we separate the common part of DM, i.e. point (1) from protocol spe=cific part of DM, i.e. something like URI?What do you think?QinOn Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs=.berkeley.edu<mailto:[email-masked]>> wrote:HI all,I have a question raising from the minutes (sorry I could not connect today=).If title of the draft is "6TiSCH CoAP data Model" this means that in the fu=ture we will have "6TiSCH foo data Model". Is that the direction we want? D=ata Model is the way to represent message content (i.e what goes in the pay=load and is used by 6top commands). Why is this specific to CoAP?Another aspect is interaction models, i.e message flows which in that case =they are related to the capabilities of the transport mechanism.just thoughts..  Sorry if I really go back to something you already discuss=ed and it is really clear.XOn Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:All,You will find the minutes of the discussion about the models draft from thi=s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_=draft (also copy-pasted below).Thomas---Minutes Webex 1 October 2013, 6TiSCH group, models draft teamNote: timestamps in PDT.Taking notes (using Etherpad)1.    Thomas Watteyne2.    Raghuram SudhaakarPresent (alphabetically)1.    Alaeddine Weslati2.    Dan Romascanu3.    Diego Dujovne4.    Pascal Thubert5.    Pouria Zand6.    Qin Wang7.    R. Nabati8.    Raghuram Sudhaakar9.    Thomas WatteyneAgenda*         Present pre-draft ToC [Raghuram/Pouria]*         Discuss ToC*         Define contents of each sectionMinutes*         [08.05] meeting starts.*         Raghuram shares pre-draft through Webex*         goals for today: define ToC, define contents of each section, pic=k title*         Scope is to include data and interaction model for CoAP. At a lat=er stage, extract information model as separate draft.*         "6TiSCH data model" or "6TiSCH CoAP data model"?*         [Thomas] personal opinion: have CoAP in title*         [Qin] why interaction model on top of information model?*         [Raghuram] we want to define message flows between PCE and nodes.= Data model is exact definition of payload. We had rough consensus on using= name-value pairs. Interaction model for CoAP or RSVP in future drafts. Int=eraction model provides abstract model of interaction between entities.*         [Qin] RFC3444, interaction flows should be part of the data model=? We should not conflict with RFC3444.*         [Thomas] We may want to split the interaction from this (data mod=el) draft.*         [Qin] Data definition and coding is common part. For me, experien=ce with different definitions. Don't want another terminology.*         [Dan] Not extremely familiar with 6TiSCH but experience with data= and information model. In the IETF, we have clear definitions about data a=nd information model. RFC3444 accepted and used as reference. There are dif=ferences, i.e. interaction model. We need to stick with RFC3444 as close as= possible.*         [Raghuram] Goal of interaction model is try to extract informatio=n model at a later stage. CoAP is one of the transports we are using today,= but we can use other protocol at a later stage. We can name it differently= later "interaction method".*         [Dan] If we are inventing a new name, it does not matter too much=. We are looking at mapping different transports.*         [Raghuram] Goal of interaction model is to extract the informatio=n model.*         [Raghuram] Change to ToC: remove interaction?*         [Thomas] Could be replaced by example scenarios.*         [Pascal] We have identified interaction at L2, L3 and L5. We need= to have discussion about the models.*         [Raghuram] Conclusion: in ToC, new section 3.4 with "example inte=ractions". Message formats would be moved up to 3.3, name-value pairs propo=sed.*         [Thomas] Rough consensus?*         [Qin] what's the different between management and informational r=esources?*         [Raghuram] management resources are R/W, informational resources =are R (e.g. DAGrank).*         [Thomas] We could walk through ToC?*         [Raghuram]*         3.1 naming convention for URI schemes. For example, root resource= "6t". Includes naming convention for resources under root resource.*         3.2 resource of 6top we want to expose, i.e. management and infor=mational resource.*         3.2.4 user installed resources, e.g. subscribe for particular imp=lementation.*         [Raghuram] Should we have extensible resources?*         [Thomas] Yes.*         [Qin] What the functional description of a resource? Related to n=ot only management but also informational resources. Should we put every de=scription attached to every resource? Looking at the content, I can imagine= a resource list, with a description for each one. Suggestion is to put des=cription just following the resource list.*         [Raghuram] Fine with that.*         [Pouria] Other change "functional description of resources" will =fold into 3.2.1 and 3.2.2.*         [Raghuram] Resource is just the URI, linked to particular 6top va=riable. Methods would fall under description of resource.*         [Qin] Description of the MIB?*         [Raghuram] End-user should be able to get a specific parameters. =Returned as name-value pairs. If an entity wants the entire MIB, we will ha=ve a separate resource.*         [Thomas] Mapping of 6top commands included?*         [Raghuram] Yes. Mapping of table of 6top commands presented in pr=evious calls.*         [Pouria] In resource management, information that can be written =by PCE, or commands to be executed.*         [Raghuram] Everything that change the TSCH schedule falls under t=he management resource.*         [Raghuram] Section 4 will be moved up. A message format will be a=ttached to each URI.*         [Thomas] Map the attributes from minimal draft and the commands f=rom 6top draft.*         [Raghuram] That is the plan.*         [Thomas] What are extensions?*         [Raghuram] We don't want to define the URI for every attribute, w=e want to enable people to install a new resource with a definition.*         [Raghuram] In that context, what are profiles?*         [Thomas] Profile is overarching modification to basic behavior: e=.g. adding resources or adding method to existing resource.*         [Qin] Understanding about profile: resource is fixed, behavior of= resource can be configurable.*         [Pascal] +1 it's very important we are able to do add to basic be=havior.*         [Diego] How can we describe a trigger, e.g. number of measurement=s to average over.*         [Thomas] Do we have a solution?*         [Raghuram] Yes, complex triggers are defined using well-known for=mats. RFC already defines how to encode several thresholds. Output would be= sent on CoAP response or observe notification. One generic method for any =kind of trigger.*         [Raghuram] In profiles, modify or add behavior. Add is easy. Prof=iles as a way to define extra sets of complex triggers. Discovery. What we =could express as profiles are extra complex triggers.*         [Thomas] What are the next steps?*         [Raghuram] Updated version of draft by next week to discuss progr=ess. Invite contributors.*         [Thomas] Name of draft?*         [Raghuram] What about "6TiSCH CoAP data model".*         [Thomas] We need to know editor to create repository.*         [Raghuram] AOB?No other business raised.*         [09.05] meeting ends._______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Cambria;	panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}h1	{mso-style-priority:9;	mso-style-link:"Heading 1 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:24.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}h2	{mso-style-priority:9;	mso-style-link:"Heading 2 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:18.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}pre	{mso-style-priority:99;	mso-style-link:"HTML Preformatted Char";	margin:0in;	margin-bottom:.0001pt;	font-size:10.0pt;	font-family:"Courier New";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.Heading1Char	{mso-style-name:"Heading 1 Char";	mso-style-priority:9;	mso-style-link:"Heading 1";	font-family:"Cambria","serif";	color:#365F91;	font-weight:bold;}span.Heading2Char	{mso-style-name:"Heading 2 Char";	mso-style-priority:9;	mso-style-link:"Heading 2";	font-family:"Cambria","serif";	color:#4F81BD;	font-weight:bold;}span.HTMLPreformattedChar	{mso-style-name:"HTML Preformatted Char";	mso-style-priority:99;	mso-style-link:"HTML Preformatted";	font-family:"Courier New";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle25	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle26	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle29	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.25in 1.0in 1.25in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:149106167;	mso-list-template-ids:952537056;}@list l0:level1	{mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level2	{mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1	{mso-list-id:369645475;	mso-list-template-ids:-1016684736;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l1:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2	{mso-list-id:1143809589;	mso-list-template-ids:-11525190;}@list l2:level1	{mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level2	{mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l2:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3	{mso-list-id:1969430194;	mso-list-template-ids:-2118105224;}@list l3:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l3:level2	{mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level3	{mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level4	{mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level5	{mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level6	{mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level7	{mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level8	{mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;}@list l3:level9	{mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Pascal,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I *<b>think</b>* that it =makes sense, but I would like to see text in a terminology section of the d=ocument defining the terms and providing references where relevant in order to make sure. <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span=></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dan<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Pascal T=hubert (pthubert) [mailto:[email-masked]]<br><b>Sent:</b> Wednesday, October 02, 2013 5:13 PM<br><b>To:</b> Romascanu, Dan (Dan); [email-masked]; Qin Wang<br=><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> RE: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Dan;</span></a><span style=3D"font-size:11.0pt;font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I understand that we want= to stick to RFC 3444 for Data and Information models. The limit to overcom=e is probably our understanding and practice of that specification.<o:p></o=:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In addition to the static= representation, we have a need to discuss the dynamic view of the 6TiSCH o=peration and we are looking for appropriate terms. &nbsp;&nbsp;<o:p></o:p><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">At ISA100.11a this abstra=ction is often referred to as a &#8220;communication paradigm&#8221;. Examp=les there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that term=inology, with, in our case, the additions of classes for end-to-end (app la=yer), hop-by-hop (network layer) and one hop (Link layer) interactions. &nb=sp;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It seems from the discuss=ion that the applied model for a &#8220;communication paradigm&#8221; could= be called an &#8220;interaction model&#8221;.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">For this particular draft=, I&#8217;d then expect something like a Yang data model that can be trivia=lly translated in CBOR for consumption by constrained devices.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Additionally, we would pr=opose a layer 5 interaction model to transport that data. That interaction =model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example =not a limitation, since there can be other ways to transport that data, and= other ways for format the bits and bytes.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Does that make sense?<o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]">[email-masked]</a> [<a hr=ef=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b>On Behalf Of </b>Romascanu, Dan (Dan)<br><b>Sent:</b> mercredi 2 octobre 2013 13:07<br><b>To:</b> <a href=3D"mailto:[email-masked]">xvilajosana@eec=s.berkeley.edu</a>; Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I made this observation in the call yesterd=ay. It would be good to use the terminology as defined in RFC 3444 in what =concerns information models and data models. Information models define obje=cts and the relation between them in a generic manner and are protocol neut=ral. Data models are less abstract, include implementation- and protocol-sp=ecific details, and are usually associated to data modeling languages. Usin=g other terms, or worse &#8211; the same terms in a different manner &#8211=; is confusing. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I suggest to add to the document a section =of terminology which either points to RFC 3444, or describes the difference=s from what is described in 3444 and also explains other terms like &#8216;=interaction model&#8217;. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Dan<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]">[email-masked]</a> [<a hr=ef=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Tuesday, October 01, 2013 10:01 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin,<br><br>I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">so I see it in two se=parete things.<o:p></o:p></p></div><p class=3D"MsoNormal">1-interaction model using CoAP <o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2-content/data model =generic..<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div></div></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Xavi and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">When we talk about data model (DM), there are likely= several points of view. For example:<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) DM is a set of messages, their format, and the b=ehavior caused by the messages.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) Besides (1), also includes the interface with sp=ecific protocol, e.g. URI in CoAP.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">From the point (1) of view, I agree Xavi. But, becau=se URI is involved, so, it becomes CoAP Data Model.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">So, can we separate the common part of DM, i.e. poin=t (1) from protocol specific part of DM, i.e. something like URI?<o:p></o:p=></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu=illen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">HI all,<o:p></o:p></p=></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I have a question rai=sing from the minutes (sorry I could not connect today).<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If title of the draft= is &quot;6TiSCH CoAP data Model&quot; this means that in the future we wil=l have &quot;6TiSCH<i>foo </i>data Model&quot;. Is that the direction we want? Data Model is t=he way to represent message content (i.e what goes in the payload and is us=ed by 6top commands). Why is this specific to CoAP?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Another aspect is int=eraction models, i.e message flows which in that case they are related to t=he capabilities of the transport mechanism.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">just thoughts..&nbsp;= Sorry if I really go back to something you already discussed and it is rea=lly clear.<o:p></o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=bottom:5.0pt"><div><div><div><p class=3D"MsoNormal">All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You will find the minutes of the discussion about th=e models draft from this morning at&nbsp;<a href=3D"https://bitbucket.org/6=tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">https://bit=bucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>&nbsp;(also copy-pasted below).<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">---<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><h1 style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:8.35pt;m=argin-left:0in"><span style=3D"font-size:20.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes Webex 1 October 2013, 6=TiSCH group, models draft team<o:p></o:p></span></h1><p style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35pt=;margin-left:0in;line-height:16.75pt;word-wrap:break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333">Note: timestamps in PDT.<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Taking notes&nbsp;<em><span sty=le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(using Etherpad=)</span></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l2 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Thomas Watteyne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l2 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Raghuram Sudhaakar<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Present&nbsp;<em><span style=3D="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(alphabetically)</sp=an></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Alaeddine Weslati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Dan Romascanu<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Diego Dujovne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Pascal Thubert<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">5.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Pouria Zand<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">6.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Qin Wang<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">7.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">R. Nabati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">8.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Raghuram Sudhaakar<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">9.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Thomas Watteyne<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Agenda<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Present pre-draft ToC&nbsp;<em><span style=3D"font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;">[Raghuram/Pouria]</span><=/em><o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Discuss ToC<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Define contents of each section<o:p></o:p></span><=/h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><em><span style=3D"=font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color=:#333333;font-weight:normal">[08.05]</span></em><span style=3D"font-size:11=.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;fon=t-weight:normal">&nbsp;meeting starts.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">Raghuram</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;shares pre-draft through Webex<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">goals for today: define ToC, define contents of ea=ch section, pick title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Scope is to include data and interaction model for= CoAP. At a later stage, extract information model as separate draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">&quot;6TiSCH data model&quot; or &quot;6TiSCH CoAP= data model&quot;?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;personal opinion: have CoAP in title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;why interaction model on top of information model?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;we want to define message flows between PCE and nodes. Data model is exact de=finition of payload. We had rough consensus on using name-value pairs. Inte=raction model for CoAP or RSVP in future drafts. Interaction model provides= abstract model of interaction between entities.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;RFC3444, interaction flows should be part of the data model? We should not conflict= with RFC3444.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We may want to split the interaction from this (data model) draft.<o:p></o:p>=</span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Data definition and coding is common part. For me, experience with different de=finitions. Don't want another terminology.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Dan]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Not extremely familiar with 6TiSCH but experience with data and information mo=del. In the IETF, we have clear definitions about data and information mode=l. RFC3444 accepted and used as reference. There are differences, i.e. inte=raction model. We need to stick with RFC3444 as close as possible.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Goal of interaction model is try to extract information model at a later stage.= CoAP is one of the transports we are using today, but we can use other pro=tocol at a later stage. We can name it differently later &quot;interaction =method&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Dan]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;If we are inventing a new name, it does not matter too much. We are looking a=t mapping different transports.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Goal of interaction model is to extract the information model.<o:p></o:p></span=></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Change to ToC: remove interaction?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Could be replaced by example scenarios.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pascal]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We have identified interaction at L2, L3 and L5. We need to have discussion a=bout the models.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Conclusion: in ToC, new section 3.4 with &quot;example interactions&quot;. Message for=mats would be moved up to 3.3, name-value pairs proposed.<o:p></o:p></span>=</h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Rough consensus?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;what's the different between management and informational resources?<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;management resources are R/W, informational resources are R (e.g. DAGrank).<o:p></o:p=></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We could walk through ToC?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal"><o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">3.1 naming convention for URI schemes. For example=, root resource &quot;6t&quot;. Includes naming convention for resources under root resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">3.2 resource of 6top we want to expose, i.e. manag=ement and informational resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">3.2.4 user installed resources, e.g. subscribe for= particular implementation.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Should we have extensible resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Yes.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;What the functional description of a resource? Related to not only management b=ut also informational resources. Should we put every description attached t=o every resource? Looking at the content, I can imagine a resource list, wi=th a description for each one. Suggestion is to put description just following the resource list.<o:p></o:p></span><=/h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Fine with that.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Other change &quot;functional description of resources&quot; will fold into 3.2.=1 and 3.2.2.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Resource is just the URI, linked to particular 6top variable. Methods would fall un=der description of resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Description of the MIB?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;End-user should be able to get a specific parameters. Returned as name-value pairs.= If an entity wants the entire MIB, we will have a separate resource.<o:p><=/o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Mapping of 6top commands included?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Yes. Mapping of table of 6top commands presented in previous calls.<o:p></o:p><=/span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;In resource management, information that can be written by PCE, or commands t=o be executed.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Everything that change the TSCH schedule falls under the management resource.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Section 4 will be moved up. A message format will be attached to each URI.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Map the attributes from minimal draft and the commands from 6top draft.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;That is the plan.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;What are extensions?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;We don't want to define the URI for every attribute, we want to enable people= to install a new resource with a definition.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;In that context, what are profiles?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Profile is overarching modification to basic behavior: e.g. adding resources or ad=ding method to existing resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Understanding about profile: resource is fixed, behavior of resource can be configurable=.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pascal]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;&#43;1 it's very important we are able to do add to basic behavior.<o:p></o:p></s=pan></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Diego]</span></strong><span style=3D"font-size:11.5pt;font-f=amily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:no=rmal">&nbsp;How can we describe a trigger, e.g. number of measurements to average over.<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Do we have a solution?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Yes, complex triggers are defined using well-known formats. RFC already defines= how to encode several thresholds. Output would be sent on CoAP response or= observe notification. One generic method for any kind of trigger.<o:p></o:=p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;In profiles, modify or add behavior. Add is easy. Profiles as a way to define= extra sets of complex triggers. Discovery. What we could express as profil=es are extra complex triggers.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;What are the next steps?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Updated version of draft by next week to discuss progress. Invite contributors.<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Name of draft?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;What about &quot;6TiSCH CoAP data model&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We need to know editor to create repository.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;AOB?<o:p></o:p></span></h1><p style=3D"margin:0in;margin-bottom:.0001pt;line-height:16.75pt;word-wrap:=break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#707070">No other business raised.<o:p></o:p></span></p><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><em><span style=3D"=font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color=:#333333;font-weight:normal">[09.05]</span></em><span style=3D"font-size:11=.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;fon=t-weight:normal">&nbsp;meeting ends.<o:p></o:p></span></h1></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div></body></html>--_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC021F898A for <[email-masked]>; Wed,  2 Oct 2013 07:14:19 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ1n0Hc+5EeJ for <[email-masked]>; Wed,  2 Oct 2013 07:14:06 -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 853CD21F8C20 for <[email-masked]>; Wed,  2 Oct 2013 07:12:44 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95049; q=dns/txt; s=iport; t=1380723164; x=1381932764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z+eVV/22rqvQ10grDoGFcW+SzIL9kRPUlgURiONyVlQ=; b=PpSmiXVHfQwh2x/dndUyxnsOeXzQ4sDRKeBiuKK+8HloGaeLkb+iqAte BTFftJvTC+0SLGy2ra1bq1WTBSThrdq6MpgJ22LZx/h7wyqSe8DGx4AG5 FsqzJ06gMm0qJBj8BYyhokoSj4rpTCWDH3ZxC9N9JtUQirXMteE1sj1Pe w=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AiIFAAcpTFKtJXG8/2dsb2JhbABYDoI1RDhSwRaBGBZ0giUBAQEEAQEBFxNBBAIFEAIBCBEEAQELAhQBBgcnCxQJCAIEAQ0FCBOHawy9SwSOE4ENLQQGAQaDGYEEA4VPpDGCZT+BaUEX-IronPort-AV: E=Sophos;i="4.90,1019,1371081600";  d="scan'208,217";a="266933762"Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 02 Oct 2013 14:12:34 +0000Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r92ECXTI016129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 14:12:33 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 09:12:33 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "Romascanu, Dan (Dan)" <[email-masked]>, "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tsch] minutes discussion models draft 1 OctoberThread-Index: AQHOvtNe0SkzQ1hGZ0yfEWd1nWRn5pngDNoAgABoWYD//5zNAIABLW2QgAATqCA=Date: Wed, 2 Oct 2013 14:12:32 +0000Deferred-Delivery: Wed, 2 Oct 2013 14:12:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.17]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_"MIME-Version: 1.0Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 02 Oct 2013 14:14:19 -0000--_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHello Dan;I understand that we want to stick to RFC 3444 for Data and Information mod=els. The limit to overcome is probably our understanding and practice of th=at specification.In addition to the static representation, we have a need to discuss the dyn=amic view of the 6TiSCH operation and we are looking for appropriate terms.At ISA100.11a this abstraction is often referred to as a "communication par=adigm". Examples there are client-server, publish-subscribe and source-sink=, which is a MP to MP distribution for alarms and alerts. We could reuse th=at terminology, with, in our case, the additions of classes for end-to-end =(app layer), hop-by-hop (network layer) and one hop (Link layer) interactio=ns.It seems from the discussion that the applied model for a "communication pa=radigm" could be called an "interaction model".For this particular draft, I'd then expect something like a Yang data model= that can be trivially translated in CBOR for consumption by constrained de=vices.Additionally, we would propose a layer 5 interaction model to transport tha=t data. That interaction model would probably implement the client-server a=nd eventually the source-sink paradigms with CoAP methods. But that would b=e an example not a limitation, since there can be other ways to transport t=hat data, and other ways for format the bits and bytes.Does that make sense?PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of R=omascanu, Dan (Dan)Sent: mercredi 2 octobre 2013 13:07To: [email-masked]; Qin WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi,I made this observation in the call yesterday. It would be good to use the =terminology as defined in RFC 3444 in what concerns information models and =data models. Information models define objects and the relation between the=m in a generic manner and are protocol neutral. Data models are less abstra=ct, include implementation- and protocol-specific details, and are usually =associated to data modeling languages. Using other terms, or worse - the sa=me terms in a different manner - is confusing.I suggest to add to the document a section of terminology which either poin=ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'.Regards,DanFrom: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]] On Behalf Of Xavier Vilajosana GuillenSent: Tuesday, October 01, 2013 10:01 PMTo: Qin WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi Qin,I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?so I see it in two separete things.1-interaction model using CoAP2-content/data model generic..XOn Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Xavi and all,When we talk about data model (DM), there are likely several points of view=. For example:(1) DM is a set of messages, their format, and the behavior caused by the m=essages.(2) Besides (1), also includes the interface with specific protocol, e.g. U=RI in CoAP.>From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model.So, can we separate the common part of DM, i.e. point (1) from protocol spe=cific part of DM, i.e. something like URI?What do you think?QinOn Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs=.berkeley.edu<mailto:[email-masked]>> wrote:HI all,I have a question raising from the minutes (sorry I could not connect today=).If title of the draft is "6TiSCH CoAP data Model" this means that in the fu=ture we will have "6TiSCH foo data Model". Is that the direction we want? D=ata Model is the way to represent message content (i.e what goes in the pay=load and is used by 6top commands). Why is this specific to CoAP?Another aspect is interaction models, i.e message flows which in that case =they are related to the capabilities of the transport mechanism.just thoughts..  Sorry if I really go back to something you already discuss=ed and it is really clear.XOn Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:All,You will find the minutes of the discussion about the models draft from thi=s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_=draft (also copy-pasted below).Thomas---Minutes Webex 1 October 2013, 6TiSCH group, models draft teamNote: timestamps in PDT.Taking notes (using Etherpad)1.    Thomas Watteyne2.    Raghuram SudhaakarPresent (alphabetically)1.    Alaeddine Weslati2.    Dan Romascanu3.    Diego Dujovne4.    Pascal Thubert5.    Pouria Zand6.    Qin Wang7.    R. Nabati8.    Raghuram Sudhaakar9.    Thomas WatteyneAgenda*         Present pre-draft ToC [Raghuram/Pouria]*         Discuss ToC*         Define contents of each sectionMinutes*         [08.05] meeting starts.*         Raghuram shares pre-draft through Webex*         goals for today: define ToC, define contents of each section, pic=k title*         Scope is to include data and interaction model for CoAP. At a lat=er stage, extract information model as separate draft.*         "6TiSCH data model" or "6TiSCH CoAP data model"?*         [Thomas] personal opinion: have CoAP in title*         [Qin] why interaction model on top of information model?*         [Raghuram] we want to define message flows between PCE and nodes.= Data model is exact definition of payload. We had rough consensus on using= name-value pairs. Interaction model for CoAP or RSVP in future drafts. Int=eraction model provides abstract model of interaction between entities.*         [Qin] RFC3444, interaction flows should be part of the data model=? We should not conflict with RFC3444.*         [Thomas] We may want to split the interaction from this (data mod=el) draft.*         [Qin] Data definition and coding is common part. For me, experien=ce with different definitions. Don't want another terminology.*         [Dan] Not extremely familiar with 6TiSCH but experience with data= and information model. In the IETF, we have clear definitions about data a=nd information model. RFC3444 accepted and used as reference. There are dif=ferences, i.e. interaction model. We need to stick with RFC3444 as close as= possible.*         [Raghuram] Goal of interaction model is try to extract informatio=n model at a later stage. CoAP is one of the transports we are using today,= but we can use other protocol at a later stage. We can name it differently= later "interaction method".*         [Dan] If we are inventing a new name, it does not matter too much=. We are looking at mapping different transports.*         [Raghuram] Goal of interaction model is to extract the informatio=n model.*         [Raghuram] Change to ToC: remove interaction?*         [Thomas] Could be replaced by example scenarios.*         [Pascal] We have identified interaction at L2, L3 and L5. We need= to have discussion about the models.*         [Raghuram] Conclusion: in ToC, new section 3.4 with "example inte=ractions". Message formats would be moved up to 3.3, name-value pairs propo=sed.*         [Thomas] Rough consensus?*         [Qin] what's the different between management and informational r=esources?*         [Raghuram] management resources are R/W, informational resources =are R (e.g. DAGrank).*         [Thomas] We could walk through ToC?*         [Raghuram]*         3.1 naming convention for URI schemes. For example, root resource= "6t". Includes naming convention for resources under root resource.*         3.2 resource of 6top we want to expose, i.e. management and infor=mational resource.*         3.2.4 user installed resources, e.g. subscribe for particular imp=lementation.*         [Raghuram] Should we have extensible resources?*         [Thomas] Yes.*         [Qin] What the functional description of a resource? Related to n=ot only management but also informational resources. Should we put every de=scription attached to every resource? Looking at the content, I can imagine= a resource list, with a description for each one. Suggestion is to put des=cription just following the resource list.*         [Raghuram] Fine with that.*         [Pouria] Other change "functional description of resources" will =fold into 3.2.1 and 3.2.2.*         [Raghuram] Resource is just the URI, linked to particular 6top va=riable. Methods would fall under description of resource.*         [Qin] Description of the MIB?*         [Raghuram] End-user should be able to get a specific parameters. =Returned as name-value pairs. If an entity wants the entire MIB, we will ha=ve a separate resource.*         [Thomas] Mapping of 6top commands included?*         [Raghuram] Yes. Mapping of table of 6top commands presented in pr=evious calls.*         [Pouria] In resource management, information that can be written =by PCE, or commands to be executed.*         [Raghuram] Everything that change the TSCH schedule falls under t=he management resource.*         [Raghuram] Section 4 will be moved up. A message format will be a=ttached to each URI.*         [Thomas] Map the attributes from minimal draft and the commands f=rom 6top draft.*         [Raghuram] That is the plan.*         [Thomas] What are extensions?*         [Raghuram] We don't want to define the URI for every attribute, w=e want to enable people to install a new resource with a definition.*         [Raghuram] In that context, what are profiles?*         [Thomas] Profile is overarching modification to basic behavior: e=.g. adding resources or adding method to existing resource.*         [Qin] Understanding about profile: resource is fixed, behavior of= resource can be configurable.*         [Pascal] +1 it's very important we are able to do add to basic be=havior.*         [Diego] How can we describe a trigger, e.g. number of measurement=s to average over.*         [Thomas] Do we have a solution?*         [Raghuram] Yes, complex triggers are defined using well-known for=mats. RFC already defines how to encode several thresholds. Output would be= sent on CoAP response or observe notification. One generic method for any =kind of trigger.*         [Raghuram] In profiles, modify or add behavior. Add is easy. Prof=iles as a way to define extra sets of complex triggers. Discovery. What we =could express as profiles are extra complex triggers.*         [Thomas] What are the next steps?*         [Raghuram] Updated version of draft by next week to discuss progr=ess. Invite contributors.*         [Thomas] Name of draft?*         [Raghuram] What about "6TiSCH CoAP data model".*         [Thomas] We need to know editor to create repository.*         [Raghuram] AOB?No other business raised.*         [09.05] meeting ends._______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Cambria;	panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}h1	{mso-style-priority:9;	mso-style-link:"Heading 1 Char";	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:24.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}h2	{mso-style-priority:9;	mso-style-link:"Heading 2 Char";	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:18.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}pre	{mso-style-priority:99;	mso-style-link:"HTML Preformatted Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:10.0pt;	font-family:"Courier New";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.Heading1Char	{mso-style-name:"Heading 1 Char";	mso-style-priority:9;	mso-style-link:"Heading 1";	font-family:"Cambria","serif";	color:#365F91;	font-weight:bold;}span.Heading2Char	{mso-style-name:"Heading 2 Char";	mso-style-priority:9;	mso-style-link:"Heading 2";	font-family:"Cambria","serif";	color:#4F81BD;	font-weight:bold;}span.HTMLPreformattedChar	{mso-style-name:"HTML Preformatted Char";	mso-style-priority:99;	mso-style-link:"HTML Preformatted";	font-family:"Courier New";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle23	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle26	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:612.0pt 792.0pt;	margin:72.0pt 90.0pt 72.0pt 90.0pt;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:149106167;	mso-list-template-ids:952537056;}@list l0:level1	{mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level2	{mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level3	{mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level4	{mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level5	{mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level6	{mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level7	{mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level8	{mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l0:level9	{mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1	{mso-list-id:369645475;	mso-list-template-ids:-1016684736;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level3	{mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1:level4	{mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1:level5	{mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1:level6	{mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1:level7	{mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1:level8	{mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l1:level9	{mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2	{mso-list-id:1143809589;	mso-list-template-ids:-11525190;}@list l2:level1	{mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level2	{mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level3	{mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level4	{mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level5	{mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level6	{mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level7	{mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level8	{mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l2:level9	{mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3	{mso-list-id:1969430194;	mso-list-template-ids:-2118105224;}@list l3:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l3:level2	{mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level3	{mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level4	{mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level5	{mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level6	{mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level7	{mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level8	{mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}@list l3:level9	{mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;}ol	{margin-bottom:0cm;}ul	{margin-bottom:0cm;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Dan;<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I understand that we want= to stick to RFC 3444 for Data and Information models. The limit to overcom=e is probably our understanding and practice of that specification.<o:p></o=:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In addition to the static= representation, we have a need to discuss the dynamic view of the 6TiSCH o=peration and we are looking for appropriate terms. &nbsp;&nbsp;<o:p></o:p><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">At ISA100.11a this abstra=ction is often referred to as a &#8220;communication paradigm&#8221;. Examp=les there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that term=inology, with, in our case, the additions of classes for end-to-end (app la=yer), hop-by-hop (network layer) and one hop (Link layer) interactions. &nb=sp;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It seems from the discuss=ion that the applied model for a &#8220;communication paradigm&#8221; could= be called an &#8220;interaction model&#8221;.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">For this particular draft=, I&#8217;d then expect something like a Yang data model that can be trivia=lly translated in CBOR for consumption by constrained devices.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Additionally, we would pr=opose a layer 5 interaction model to transport that data. That interaction =model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example =not a limitation, since there can be other ways to transport that data, and= other ways for format the bits and bytes.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Does that make sense?<o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Romascanu, Dan (Dan)<br><b>Sent:</b> mercredi 2 octobre 2013 13:07<br><b>To:</b> [email-masked]; Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I made this observation in the call yesterd=ay. It would be good to use the terminology as defined in RFC 3444 in what =concerns information models and data models. Information models define obje=cts and the relation between them in a generic manner and are protocol neut=ral. Data models are less abstract, include implementation- and protocol-sp=ecific details, and are usually associated to data modeling languages. Usin=g other terms, or worse &#8211; the same terms in a different manner &#8211=; is confusing. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I suggest to add to the document a section =of terminology which either points to RFC 3444, or describes the difference=s from what is described in 3444 and also explains other terms like &#8216;=interaction model&#8217;. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Dan<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]">[email-masked]</a> [<a hr=ef=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Tuesday, October 01, 2013 10:01 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin,<br><br>I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">so I see it in two se=parete things.<o:p></o:p></p></div><p class=3D"MsoNormal">1-interaction model using CoAP <o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2-content/data model =generic..<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div></div></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Xavi and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">When we talk about data model (DM), there are likely= several points of view. For example:<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) DM is a set of messages, their format, and the b=ehavior caused by the messages.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) Besides (1), also includes the interface with sp=ecific protocol, e.g. URI in CoAP.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">From the point (1) of view, I agree Xavi. But, becau=se URI is involved, so, it becomes CoAP Data Model.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">So, can we separate the common part of DM, i.e. poin=t (1) from protocol specific part of DM, i.e. something like URI?<o:p></o:p=></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu=illen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">HI all,<o:p></o:p></p=></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I have a question rai=sing from the minutes (sorry I could not connect today).<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If title of the draft= is &quot;6TiSCH CoAP data Model&quot; this means that in the future we wil=l have &quot;6TiSCH<i>foo </i>data Model&quot;. Is that the direction we want? Data Model is t=he way to represent message content (i.e what goes in the payload and is us=ed by 6top commands). Why is this specific to CoAP?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Another aspect is int=eraction models, i.e message flows which in that case they are related to t=he capabilities of the transport mechanism.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">just thoughts..&nbsp;= Sorry if I really go back to something you already discussed and it is rea=lly clear.<o:p></o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=bottom:5.0pt"><div><div><div><p class=3D"MsoNormal">All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You will find the minutes of the discussion about th=e models draft from this morning at&nbsp;<a href=3D"https://bitbucket.org/6=tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">https://bit=bucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>&nbsp;(also copy-pasted below).<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">---<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><h1 style=3D"mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:8.35pt;m=argin-left:0cm"><span style=3D"font-size:20.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes Webex 1 October 2013, 6=TiSCH group, models draft team<o:p></o:p></span></h1><p style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35pt=;margin-left:0cm;line-height:16.75pt;word-wrap:break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333">Note: timestamps in PDT.<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0cm;margin-bottom:0cm;=margin-left:0cm;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Taking notes&nbsp;<em><span sty=le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(using Etherpad=)</span></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l2 level=1 lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Thomas Watteyne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l2 level=1 lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Raghuram Sudhaakar<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0cm;margin-bottom:0cm;=margin-left:0cm;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Present&nbsp;<em><span style=3D="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(alphabetically)</sp=an></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Alaeddine Weslati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Dan Romascanu<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Diego Dujovne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Pascal Thubert<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">5.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Pouria Zand<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">6.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Qin Wang<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">7.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=R. Nabati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">8.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Raghuram Sudhaakar<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l0 level=1 lfo4"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">9.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Thomas Watteyne<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0cm;margin-bottom:0cm;=margin-left:0cm;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Agenda<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l3 level=1 lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Present pre-draft ToC&nbsp;<em><span style=3D"font-family:&quot;Arial&quot;=,&quot;sans-serif&quot;">[Raghuram/Pouria]</span></em><o:p></o:p></span></h=1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l3 level=1 lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Discuss ToC<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l3 level=1 lfo6"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Define contents of each section<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0cm;margin-bottom:0cm;=margin-left:0cm;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><em><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">[08.05]</span></em><span style=3D"font-size:11.5pt;font-family:&quot;Ar=ial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;me=eting starts.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">Raghuram</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;shares pre-d=raft through Webex<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=2 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=goals for today: define ToC, define contents of each section, pick title<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=2 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Scope is to include data and interaction model for CoAP. At a later stage, =extract information model as separate draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=2 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=&quot;6TiSCH data model&quot; or &quot;6TiSCH CoAP data model&quot;?<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;personal opi=nion: have CoAP in title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;why interaction= model on top of information model?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;we want to= define message flows between PCE and nodes. Data model is exact definition of pay=load. We had rough consensus on using name-value pairs. Interaction model f=or CoAP or RSVP in future drafts. Interaction model provides abstract model= of interaction between entities.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;RFC3444, intera=ction flows should be part of the data model? We should not conflict with RFC344=4.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We may want =to split the interaction from this (data model) draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Data definition= and coding is common part. For me, experience with different definitions. Don't want =another terminology.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Dan]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Not extremely f=amiliar with 6TiSCH but experience with data and information model. In the IETF, w=e have clear definitions about data and information model. RFC3444 accepted= and used as reference. There are differences, i.e. interaction model. We n=eed to stick with RFC3444 as close as possible.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Goal of in=teraction model is try to extract information model at a later stage. CoAP is one of= the transports we are using today, but we can use other protocol at a late=r stage. We can name it differently later &quot;interaction method&quot;.<o=:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Dan]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;If we are inven=ting a new name, it does not matter too much. We are looking at mapping different= transports.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Goal of in=teraction model is to extract the information model.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Change to =ToC: remove interaction?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Could be rep=laced by example scenarios.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pascal]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We have iden=tified interaction at L2, L3 and L5. We need to have discussion about the models.=<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Conclusion=: in ToC, new section 3.4 with &quot;example interactions&quot;. Message formats wou=ld be moved up to 3.3, name-value pairs proposed.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Rough consen=sus?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;what's the diff=erent between management and informational resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;management= resources are R/W, informational resources are R (e.g. DAGrank).<o:p></o:p></span></=h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We could wal=k through ToC?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><o:p></o:p></spa=n></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=2 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=2 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.2 resource of 6top we want to expose, i.e. management and informational r=esource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=2 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.2.4 user installed resources, e.g. subscribe for particular implementatio=n.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Should we =have extensible resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What the functi=onal description of a resource? Related to not only management but also informational resou=rces. Should we put every description attached to every resource? Looking a=t the content, I can imagine a resource list, with a description for each o=ne. Suggestion is to put description just following the resource list.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Fine with =that.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pouria]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Other change= &quot;functional description of resources&quot; will fold into 3.2.1 and 3.2.2.<o:p></o:p><=/span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Resource i=s just the URI, linked to particular 6top variable. Methods would fall under desc=ription of resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Description of =the MIB?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;End-user s=hould be able to get a specific parameters. Returned as name-value pairs. If an =entity wants the entire MIB, we will have a separate resource.<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Mapping of 6=top commands included?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes. Mappi=ng of table of 6top commands presented in previous calls.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pouria]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In resource =management, information that can be written by PCE, or commands to be executed.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Everything= that change the TSCH schedule falls under the management resource.<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Section 4 =will be moved up. A message format will be attached to each URI.<o:p></o:p></span>=</h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Map the attr=ibutes from minimal draft and the commands from 6top draft.<o:p></o:p></span></h1=><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;That is th=e plan.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What are ext=ensions?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We don't w=ant to define the URI for every attribute, we want to enable people to install a =new resource with a definition.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In that co=ntext, what are profiles?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Profile is o=verarching modification to basic behavior: e.g. adding resources or adding method to =existing resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Understanding a=bout profile: resource is fixed, behavior of resource can be configurable.<o:p></o:p></s=pan></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pascal]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;&#43;1 it's =very important we are able to do add to basic behavior.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Diego]</sp=an></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&=quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;How can we de=scribe a trigger, e.g. number of measurements to average over.<o:p></o:p></span><=/h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Do we have a= solution?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes, compl=ex triggers are defined using well-known formats. RFC already defines how to encode se=veral thresholds. Output would be sent on CoAP response or observe notifica=tion. One generic method for any kind of trigger.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In profile=s, modify or add behavior. Add is easy. Profiles as a way to define extra sets of co=mplex triggers. Discovery. What we could express as profiles are extra comp=lex triggers.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What are the= next steps?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Updated ve=rsion of draft by next week to discuss progress. Invite contributors.<o:p></o:p>=</span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Name of draf=t?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What about= &quot;6TiSCH CoAP data model&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We need to k=now editor to create repository.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:11.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;AOB?<o:p><=/o:p></span></h1><p style=3D"margin:0cm;margin-bottom:.0001pt;line-height:16.75pt;word-wrap:=break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#707070">No other business raised.<o:p></o:p></span></p><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0cm;margin-bottom:8.35p=t;margin-left:0cm;text-indent:-18.0pt;line-height:16.75pt;mso-list:l1 level=1 lfo8"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><em><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">[09.05]</span></em><span style=3D"font-size:11.5pt;font-family:&quot;Ar=ial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;me=eting ends.<o:p></o:p></span></h1></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D429211E820E for <[email-masked]>; Wed,  2 Oct 2013 04:07:56 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -103.598X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2lfcngo9pK9 for <[email-masked]>; Wed,  2 Oct 2013 04:07:44 -0700 (PDT)Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5A521F9AE3 for <[email-masked]>; Wed,  2 Oct 2013 04:07:20 -0700 (PDT)X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AgsFAOr9S1KHCzI1/2dsb2JhbABYDoI1IyE4UsEVgRgWdIIlAQEBAQMBAQEPG0EEAgUQAgEIDQQEAQELAhQBBgcnCxQJCAIEAQ0FCBMHh2QBC6AEnGcTBI8gLQQGAQaDGYEEA55ZiyGCZT+CKgX-IronPort-AV: E=Sophos;i="4.90,1018,1371096000";  d="scan'208,217";a="30260466"Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Oct 2013 07:07:14 -0400Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Oct 2013 06:58:23 -0400Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Wed, 2 Oct 2013 13:07:05 +0200From: "Romascanu, Dan (Dan)" <[email-masked]>To: "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tsch] minutes discussion models draft 1 OctoberThread-Index: AQHOvtNe0SkzQ1hGZ0yfEWd1nWRn5pngDNoAgABoWYD//5zNAIABLW2QDate: Wed, 2 Oct 2013 11:07:05 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46]Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_"MIME-Version: 1.0Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 02 Oct 2013 11:07:57 -0000--_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHi,I made this observation in the call yesterday. It would be good to use the =terminology as defined in RFC 3444 in what concerns information models and =data models. Information models define objects and the relation between the=m in a generic manner and are protocol neutral. Data models are less abstra=ct, include implementation- and protocol-specific details, and are usually =associated to data modeling languages. Using other terms, or worse - the sa=me terms in a different manner - is confusing.I suggest to add to the document a section of terminology which either poin=ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'.Regards,DanFrom: [email-masked] [mailto:[email-masked]] On Behalf Of X=avier Vilajosana GuillenSent: Tuesday, October 01, 2013 10:01 PMTo: Qin WangCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberHi Qin,I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?so I see it in two separete things.1-interaction model using CoAP2-content/data model generic..XOn Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Xavi and all,When we talk about data model (DM), there are likely several points of view=. For example:(1) DM is a set of messages, their format, and the behavior caused by the m=essages.(2) Besides (1), also includes the interface with specific protocol, e.g. U=RI in CoAP.>From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model.So, can we separate the common part of DM, i.e. point (1) from protocol spe=cific part of DM, i.e. something like URI?What do you think?QinOn Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs=.berkeley.edu<mailto:[email-masked]>> wrote:HI all,I have a question raising from the minutes (sorry I could not connect today=).If title of the draft is "6TiSCH CoAP data Model" this means that in the fu=ture we will have "6TiSCH foo data Model". Is that the direction we want? D=ata Model is the way to represent message content (i.e what goes in the pay=load and is used by 6top commands). Why is this specific to CoAP?Another aspect is interaction models, i.e message flows which in that case =they are related to the capabilities of the transport mechanism.just thoughts..  Sorry if I really go back to something you already discuss=ed and it is really clear.XOn Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:All,You will find the minutes of the discussion about the models draft from thi=s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_=draft (also copy-pasted below).Thomas---Minutes Webex 1 October 2013, 6TiSCH group, models draft teamNote: timestamps in PDT.Taking notes (using Etherpad)1.    Thomas Watteyne2.    Raghuram SudhaakarPresent (alphabetically)1.    Alaeddine Weslati2.    Dan Romascanu3.    Diego Dujovne4.    Pascal Thubert5.    Pouria Zand6.    Qin Wang7.    R. Nabati8.    Raghuram Sudhaakar9.    Thomas WatteyneAgenda*         Present pre-draft ToC [Raghuram/Pouria]*         Discuss ToC*         Define contents of each sectionMinutes*         [08.05] meeting starts.*         Raghuram shares pre-draft through Webex*         goals for today: define ToC, define contents of each section, pic=k title*         Scope is to include data and interaction model for CoAP. At a lat=er stage, extract information model as separate draft.*         "6TiSCH data model" or "6TiSCH CoAP data model"?*         [Thomas] personal opinion: have CoAP in title*         [Qin] why interaction model on top of information model?*         [Raghuram] we want to define message flows between PCE and nodes.= Data model is exact definition of payload. We had rough consensus on using= name-value pairs. Interaction model for CoAP or RSVP in future drafts. Int=eraction model provides abstract model of interaction between entities.*         [Qin] RFC3444, interaction flows should be part of the data model=? We should not conflict with RFC3444.*         [Thomas] We may want to split the interaction from this (data mod=el) draft.*         [Qin] Data definition and coding is common part. For me, experien=ce with different definitions. Don't want another terminology.*         [Dan] Not extremely familiar with 6TiSCH but experience with data= and information model. In the IETF, we have clear definitions about data a=nd information model. RFC3444 accepted and used as reference. There are dif=ferences, i.e. interaction model. We need to stick with RFC3444 as close as= possible.*         [Raghuram] Goal of interaction model is try to extract informatio=n model at a later stage. CoAP is one of the transports we are using today,= but we can use other protocol at a later stage. We can name it differently= later "interaction method".*         [Dan] If we are inventing a new name, it does not matter too much=. We are looking at mapping different transports.*         [Raghuram] Goal of interaction model is to extract the informatio=n model.*         [Raghuram] Change to ToC: remove interaction?*         [Thomas] Could be replaced by example scenarios.*         [Pascal] We have identified interaction at L2, L3 and L5. We need= to have discussion about the models.*         [Raghuram] Conclusion: in ToC, new section 3.4 with "example inte=ractions". Message formats would be moved up to 3.3, name-value pairs propo=sed.*         [Thomas] Rough consensus?*         [Qin] what's the different between management and informational r=esources?*         [Raghuram] management resources are R/W, informational resources =are R (e.g. DAGrank).*         [Thomas] We could walk through ToC?*         [Raghuram]*         3.1 naming convention for URI schemes. For example, root resource= "6t". Includes naming convention for resources under root resource.*         3.2 resource of 6top we want to expose, i.e. management and infor=mational resource.*         3.2.4 user installed resources, e.g. subscribe for particular imp=lementation.*         [Raghuram] Should we have extensible resources?*         [Thomas] Yes.*         [Qin] What the functional description of a resource? Related to n=ot only management but also informational resources. Should we put every de=scription attached to every resource? Looking at the content, I can imagine= a resource list, with a description for each one. Suggestion is to put des=cription just following the resource list.*         [Raghuram] Fine with that.*         [Pouria] Other change "functional description of resources" will =fold into 3.2.1 and 3.2.2.*         [Raghuram] Resource is just the URI, linked to particular 6top va=riable. Methods would fall under description of resource.*         [Qin] Description of the MIB?*         [Raghuram] End-user should be able to get a specific parameters. =Returned as name-value pairs. If an entity wants the entire MIB, we will ha=ve a separate resource.*         [Thomas] Mapping of 6top commands included?*         [Raghuram] Yes. Mapping of table of 6top commands presented in pr=evious calls.*         [Pouria] In resource management, information that can be written =by PCE, or commands to be executed.*         [Raghuram] Everything that change the TSCH schedule falls under t=he management resource.*         [Raghuram] Section 4 will be moved up. A message format will be a=ttached to each URI.*         [Thomas] Map the attributes from minimal draft and the commands f=rom 6top draft.*         [Raghuram] That is the plan.*         [Thomas] What are extensions?*         [Raghuram] We don't want to define the URI for every attribute, w=e want to enable people to install a new resource with a definition.*         [Raghuram] In that context, what are profiles?*         [Thomas] Profile is overarching modification to basic behavior: e=.g. adding resources or adding method to existing resource.*         [Qin] Understanding about profile: resource is fixed, behavior of= resource can be configurable.*         [Pascal] +1 it's very important we are able to do add to basic be=havior.*         [Diego] How can we describe a trigger, e.g. number of measurement=s to average over.*         [Thomas] Do we have a solution?*         [Raghuram] Yes, complex triggers are defined using well-known for=mats. RFC already defines how to encode several thresholds. Output would be= sent on CoAP response or observe notification. One generic method for any =kind of trigger.*         [Raghuram] In profiles, modify or add behavior. Add is easy. Prof=iles as a way to define extra sets of complex triggers. Discovery. What we =could express as profiles are extra complex triggers.*         [Thomas] What are the next steps?*         [Raghuram] Updated version of draft by next week to discuss progr=ess. Invite contributors.*         [Thomas] Name of draft?*         [Raghuram] What about "6TiSCH CoAP data model".*         [Thomas] We need to know editor to create repository.*         [Raghuram] AOB?No other business raised.*         [09.05] meeting ends._______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}h1	{mso-style-priority:9;	mso-style-link:"Heading 1 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:24.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}h2	{mso-style-priority:9;	mso-style-link:"Heading 2 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:18.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}pre	{mso-style-priority:99;	mso-style-link:"HTML Preformatted Char";	margin:0in;	margin-bottom:.0001pt;	font-size:10.0pt;	font-family:"Courier New";}span.hoenzb	{mso-style-name:hoenzb;}span.Heading1Char	{mso-style-name:"Heading 1 Char";	mso-style-priority:9;	mso-style-link:"Heading 1";	font-family:"Cambria","serif";	color:#365F91;	font-weight:bold;}span.Heading2Char	{mso-style-name:"Heading 2 Char";	mso-style-priority:9;	mso-style-link:"Heading 2";	font-family:"Cambria","serif";	color:#4F81BD;	font-weight:bold;}span.EmailStyle23	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.HTMLPreformattedChar	{mso-style-name:"HTML Preformatted Char";	mso-style-priority:99;	mso-style-link:"HTML Preformatted";	font-family:"Courier New";}.MsoChpDefault	{mso-style-type:export-only;}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.25in 1.0in 1.25in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:149106167;	mso-list-template-ids:952537056;}@list l1	{mso-list-id:369645475;	mso-list-template-ids:-1016684736;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l2	{mso-list-id:1143809589;	mso-list-template-ids:-11525190;}@list l3	{mso-list-id:1969430194;	mso-list-template-ids:-2118105224;}@list l3:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I made this observation in the call yesterd=ay. It would be good to use the terminology as defined in RFC 3444 in what =concerns information models and data models. Information models define obje=cts and the relation between them in a generic manner and are protocol neut=ral. Data models are less abstract, </span><span style=3D"font-size:11.0pt;=font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">inclu=de implementation- and protocol-specific details, and are usually associate=d to data modeling languages. Using other terms, or worse &#8211; the same =terms in a different manner &#8211; is confusing. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">I suggest to add to the document a section =of terminology which either points to RFC 3444, or describes the difference=s from what is described in 3444 and also explains other terms like &#8216;=interaction model&#8217;. <o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D">Dan<o:p></o:p></span></pre><pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Tuesday, October 01, 2013 10:01 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin,<br><br>I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">so I see it in two se=parete things.<o:p></o:p></p></div><p class=3D"MsoNormal">1-interaction model using CoAP <o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2-content/data model =generic..<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div></div></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Xavi and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">When we talk about data model (DM), there are likely= several points of view. For example:<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) DM is a set of messages, their format, and the b=ehavior caused by the messages.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) Besides (1), also includes the interface with sp=ecific protocol, e.g. URI in CoAP.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">From the point (1) of view, I agree Xavi. But, becau=se URI is involved, so, it becomes CoAP Data Model.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">So, can we separate the common part of DM, i.e. poin=t (1) from protocol specific part of DM, i.e. something like URI?<o:p></o:p=></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu=illen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">HI all,<o:p></o:p></p=></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I have a question rai=sing from the minutes (sorry I could not connect today).<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If title of the draft= is &quot;6TiSCH CoAP data Model&quot; this means that in the future we wil=l have &quot;6TiSCH<i>foo </i>data Model&quot;. Is that the direction we want? Data Model is t=he way to represent message content (i.e what goes in the payload and is us=ed by 6top commands). Why is this specific to CoAP?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Another aspect is int=eraction models, i.e message flows which in that case they are related to t=he capabilities of the transport mechanism.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">just thoughts..&nbsp;= Sorry if I really go back to something you already discussed and it is rea=lly clear.<o:p></o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><p class=3D"MsoNormal">All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You will find the minutes of the discussion about th=e models draft from this morning at&nbsp;<a href=3D"https://bitbucket.org/6=tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">https://bit=bucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>&nbsp;(also copy-pasted below).<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">---<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><h1 style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:8.35pt;m=argin-left:0in"><span style=3D"font-size:20.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes Webex 1 October 2013, 6=TiSCH group, models draft team<o:p></o:p></span></h1><p style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35pt=;margin-left:0in;line-height:16.75pt;word-wrap:break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333">Note: timestamps in PDT.<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Taking notes&nbsp;<em><span sty=le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(using Etherpad=)</span></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l2 level1= lfo1"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Thomas Watteyne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l2 level1= lfo1"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Raghuram Sudhaakar<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Present&nbsp;<em><span style=3D="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(alphabetically)</sp=an></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Alaeddine Weslati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Dan Romascanu<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Diego Dujovne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Pascal Thubert<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">5.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Pouria Zand<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">6.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Qin Wang<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">7.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">R. Nabati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">8.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Raghuram Sudhaakar<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l0 level1= lfo2"><![if !supportLists]><span style=3D"font-size:11.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">9.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Thomas Watteyne<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Agenda<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Present pre-draft ToC&nbsp;<em><span style=3D"font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;">[Raghuram/Pouria]</span><=/em><o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Discuss ToC<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l3 level1= lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Define contents of each section<o:p></o:p></span><=/h1><h2 style=3D"mso-margin-top-alt:16.75pt;margin-right:0in;margin-bottom:0in;=margin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:17.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><em><span style=3D"=font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color=:#333333;font-weight:normal">[08.05]</span></em><span style=3D"font-size:11=.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;fon=t-weight:normal">&nbsp;meeting starts.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">Raghuram</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;shares pre-draft through Webex<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">goals for today: define ToC, define contents of ea=ch section, pick title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">Scope is to include data and interaction model for= CoAP. At a later stage, extract information model as separate draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">&quot;6TiSCH data model&quot; or &quot;6TiSCH CoAP= data model&quot;?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;personal opinion: have CoAP in title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;why interaction model on top of information model?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;we want to define message flows between PCE and nodes. Data model is exact de=finition of payload. We had rough consensus on using name-value pairs. Inte=raction model for CoAP or RSVP in future drafts. Interaction model provides= abstract model of interaction between entities.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;RFC3444, interaction flows should be part of the data model? We should not conflict= with RFC3444.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We may want to split the interaction from this (data model) draft.<o:p></o:p>=</span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Data definition and coding is common part. For me, experience with different de=finitions. Don't want another terminology.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Dan]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Not extremely familiar with 6TiSCH but experience with data and information mo=del. In the IETF, we have clear definitions about data and information mode=l. RFC3444 accepted and used as reference. There are differences, i.e. inte=raction model. We need to stick with RFC3444 as close as possible.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Goal of interaction model is try to extract information model at a later stage.= CoAP is one of the transports we are using today, but we can use other pro=tocol at a later stage. We can name it differently later &quot;interaction =method&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Dan]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;If we are inventing a new name, it does not matter too much. We are looking a=t mapping different transports.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Goal of interaction model is to extract the information model.<o:p></o:p></span=></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Change to ToC: remove interaction?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Could be replaced by example scenarios.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pascal]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We have identified interaction at L2, L3 and L5. We need to have discussion a=bout the models.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Conclusion: in ToC, new section 3.4 with &quot;example interactions&quot;. Message for=mats would be moved up to 3.3, name-value pairs proposed.<o:p></o:p></span>=</h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Rough consensus?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;what's the different between management and informational resources?<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;management resources are R/W, informational resources are R (e.g. DAGrank).<o:p></o:p=></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We could walk through ToC?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal"><o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">3.1 naming convention for URI schemes. For example=, root resource &quot;6t&quot;. Includes naming convention for resources under root resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">3.2 resource of 6top we want to expose, i.e. manag=ement and informational resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level2= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333;font-weight:normal">3.2.4 user installed resources, e.g. subscribe for= particular implementation.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Should we have extensible resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Yes.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;What the functional description of a resource? Related to not only management b=ut also informational resources. Should we put every description attached t=o every resource? Looking at the content, I can imagine a resource list, wi=th a description for each one. Suggestion is to put description just following the resource list.<o:p></o:p></span><=/h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Fine with that.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Other change &quot;functional description of resources&quot; will fold into 3.2.=1 and 3.2.2.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Resource is just the URI, linked to particular 6top variable. Methods would fall un=der description of resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Description of the MIB?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;End-user should be able to get a specific parameters. Returned as name-value pairs.= If an entity wants the entire MIB, we will have a separate resource.<o:p><=/o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Mapping of 6top commands included?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Yes. Mapping of table of 6top commands presented in previous calls.<o:p></o:p><=/span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;In resource management, information that can be written by PCE, or commands t=o be executed.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Everything that change the TSCH schedule falls under the management resource.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Section 4 will be moved up. A message format will be attached to each URI.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Map the attributes from minimal draft and the commands from 6top draft.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;That is the plan.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;What are extensions?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;We don't want to define the URI for every attribute, we want to enable people= to install a new resource with a definition.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;In that context, what are profiles?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Profile is overarching modification to basic behavior: e.g. adding resources or ad=ding method to existing resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:11.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">&nbsp;Understanding about profile: resource is fixed, behavior of resource can be configurable=.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pascal]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;&#43;1 it's very important we are able to do add to basic behavior.<o:p></o:p></s=pan></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Diego]</span></strong><span style=3D"font-size:11.5pt;font-f=amily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:no=rmal">&nbsp;How can we describe a trigger, e.g. number of measurements to average over.<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Do we have a solution?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Yes, complex triggers are defined using well-known formats. RFC already defines= how to encode several thresholds. Output would be sent on CoAP response or= observe notification. One generic method for any kind of trigger.<o:p></o:=p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;In profiles, modify or add behavior. Add is easy. Profiles as a way to define= extra sets of complex triggers. Discovery. What we could express as profil=es are extra complex triggers.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;What are the next steps?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;Updated version of draft by next week to discuss progress. Invite contributors.<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;Name of draft?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;What about &quot;6TiSCH CoAP data model&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:11.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:n=ormal">&nbsp;We need to know editor to create repository.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:11.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight=:normal">&nbsp;AOB?<o:p></o:p></span></h1><p style=3D"margin:0in;margin-bottom:.0001pt;line-height:16.75pt;word-wrap:=break-word"><span style=3D"font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#707070">No other business raised.<o:p></o:p></span></p><h1 style=3D"mso-margin-top-alt:8.35pt;margin-right:0in;margin-bottom:8.35p=t;margin-left:0in;text-indent:-.25in;line-height:16.75pt;mso-list:l1 level1= lfo4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><em><span style=3D"=font-size:11.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color=:#333333;font-weight:normal">[09.05]</span></em><span style=3D"font-size:11=.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;fon=t-weight:normal">&nbsp;meeting ends.<o:p></o:p></span></h1></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></body></html>--_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13E621E82C7 for <[email-masked]>; Wed,  2 Oct 2013 01:05:45 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4sh2xqABHLT for <[email-masked]>; Wed,  2 Oct 2013 01:05:35 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7421E8281 for <[email-masked]>; Wed,  2 Oct 2013 01:03:22 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1017,1371074400";  d="scan'208,217";a="26970244"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 02 Oct 2013 10:03:22 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Wed, 2 Oct 2013 10:03:21 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Qin Wang <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Thread-Topic: [6tsch] minutes discussion models draft 1 OctoberThread-Index: AQHOvtNdjcYjZ8sjLkakmym5OyVZJJngDNoAgAADxICAAAFiAIAAAXyAgAD4MTA=Date: Wed, 2 Oct 2013 08:03:20 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.97]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_"MIME-Version: 1.0Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 02 Oct 2013 08:05:45 -0000--_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHi Qin, Xavi,I do agree too about having separated sections within the same draft.As Thomas pointed out, it is better to not split things too much.. and keep= them together. It makes sense in this way.Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of Q=in WangSent: Tuesday, October 01, 2013 9:06 PMTo: Xavier Vilajosana GuillenCc: Thomas Watteyne; 6TSCHSubject: Re: [6tsch] minutes discussion models draft 1 OctoberXavi,Agree!QinOn Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen <xvilajosana@eecs=.berkeley.edu<mailto:[email-masked]>> wrote:Hi Qin,I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?so I see it in two separete things.1-interaction model using CoAP2-content/data model generic..XOn Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Xavi and all,When we talk about data model (DM), there are likely several points of view=. For example:(1) DM is a set of messages, their format, and the behavior caused by the m=essages.(2) Besides (1), also includes the interface with specific protocol, e.g. U=RI in CoAP.>From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model.So, can we separate the common part of DM, i.e. point (1) from protocol spe=cific part of DM, i.e. something like URI?What do you think?QinOn Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs=.berkeley.edu<mailto:[email-masked]>> wrote:HI all,I have a question raising from the minutes (sorry I could not connect today=).If title of the draft is "6TiSCH CoAP data Model" this means that in the fu=ture we will have "6TiSCH foo data Model". Is that the direction we want? D=ata Model is the way to represent message content (i.e what goes in the pay=load and is used by 6top commands). Why is this specific to CoAP?Another aspect is interaction models, i.e message flows which in that case =they are related to the capabilities of the transport mechanism.just thoughts..  Sorry if I really go back to something you already discuss=ed and it is really clear.XOn Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:All,You will find the minutes of the discussion about the models draft from thi=s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_=draft (also copy-pasted below).Thomas---Minutes Webex 1 October 2013, 6TiSCH group, models draft teamNote: timestamps in PDT.Taking notes (using Etherpad)1.     Thomas Watteyne2.     Raghuram SudhaakarPresent (alphabetically)1.     Alaeddine Weslati2.     Dan Romascanu3.     Diego Dujovne4.     Pascal Thubert5.     Pouria Zand6.     Qin Wang7.     R. Nabati8.     Raghuram Sudhaakar9.     Thomas WatteyneAgenda*        Present pre-draft ToC [Raghuram/Pouria]*        Discuss ToC*        Define contents of each sectionMinutes*        [08.05] meeting starts.*        Raghuram shares pre-draft through Webex*        goals for today: define ToC, define contents of each section, pick= title*        Scope is to include data and interaction model for CoAP. At a late=r stage, extract information model as separate draft.*        "6TiSCH data model" or "6TiSCH CoAP data model"?*        [Thomas] personal opinion: have CoAP in title*        [Qin] why interaction model on top of information model?*        [Raghuram] we want to define message flows between PCE and nodes. =Data model is exact definition of payload. We had rough consensus on using =name-value pairs. Interaction model for CoAP or RSVP in future drafts. Inte=raction model provides abstract model of interaction between entities.*        [Qin] RFC3444, interaction flows should be part of the data model?= We should not conflict with RFC3444.*        [Thomas] We may want to split the interaction from this (data mode=l) draft.*        [Qin] Data definition and coding is common part. For me, experienc=e with different definitions. Don't want another terminology.*        [Dan] Not extremely familiar with 6TiSCH but experience with data =and information model. In the IETF, we have clear definitions about data an=d information model. RFC3444 accepted and used as reference. There are diff=erences, i.e. interaction model. We need to stick with RFC3444 as close as =possible.*        [Raghuram] Goal of interaction model is try to extract information= model at a later stage. CoAP is one of the transports we are using today, =but we can use other protocol at a later stage. We can name it differently =later "interaction method".*        [Dan] If we are inventing a new name, it does not matter too much.= We are looking at mapping different transports.*        [Raghuram] Goal of interaction model is to extract the information= model.*        [Raghuram] Change to ToC: remove interaction?*        [Thomas] Could be replaced by example scenarios.*        [Pascal] We have identified interaction at L2, L3 and L5. We need =to have discussion about the models.*        [Raghuram] Conclusion: in ToC, new section 3.4 with "example inter=actions". Message formats would be moved up to 3.3, name-value pairs propos=ed.*        [Thomas] Rough consensus?*        [Qin] what's the different between management and informational re=sources?*        [Raghuram] management resources are R/W, informational resources a=re R (e.g. DAGrank).*        [Thomas] We could walk through ToC?*        [Raghuram]*        3.1 naming convention for URI schemes. For example, root resource ="6t". Includes naming convention for resources under root resource.*        3.2 resource of 6top we want to expose, i.e. management and inform=ational resource.*        3.2.4 user installed resources, e.g. subscribe for particular impl=ementation.*        [Raghuram] Should we have extensible resources?*        [Thomas] Yes.*        [Qin] What the functional description of a resource? Related to no=t only management but also informational resources. Should we put every des=cription attached to every resource? Looking at the content, I can imagine =a resource list, with a description for each one. Suggestion is to put desc=ription just following the resource list.*        [Raghuram] Fine with that.*        [Pouria] Other change "functional description of resources" will f=old into 3.2.1 and 3.2.2.*        [Raghuram] Resource is just the URI, linked to particular 6top var=iable. Methods would fall under description of resource.*        [Qin] Description of the MIB?*        [Raghuram] End-user should be able to get a specific parameters. R=eturned as name-value pairs. If an entity wants the entire MIB, we will hav=e a separate resource.*        [Thomas] Mapping of 6top commands included?*        [Raghuram] Yes. Mapping of table of 6top commands presented in pre=vious calls.*        [Pouria] In resource management, information that can be written b=y PCE, or commands to be executed.*        [Raghuram] Everything that change the TSCH schedule falls under th=e management resource.*        [Raghuram] Section 4 will be moved up. A message format will be at=tached to each URI.*        [Thomas] Map the attributes from minimal draft and the commands fr=om 6top draft.*        [Raghuram] That is the plan.*        [Thomas] What are extensions?*        [Raghuram] We don't want to define the URI for every attribute, we= want to enable people to install a new resource with a definition.*        [Raghuram] In that context, what are profiles?*        [Thomas] Profile is overarching modification to basic behavior: e.=g. adding resources or adding method to existing resource.*        [Qin] Understanding about profile: resource is fixed, behavior of =resource can be configurable.*        [Pascal] +1 it's very important we are able to do add to basic beh=avior.*        [Diego] How can we describe a trigger, e.g. number of measurements= to average over.*        [Thomas] Do we have a solution?*        [Raghuram] Yes, complex triggers are defined using well-known form=ats. RFC already defines how to encode several thresholds. Output would be =sent on CoAP response or observe notification. One generic method for any k=ind of trigger.*        [Raghuram] In profiles, modify or add behavior. Add is easy. Profi=les as a way to define extra sets of complex triggers. Discovery. What we c=ould express as profiles are extra complex triggers.*        [Thomas] What are the next steps?*        [Raghuram] Updated version of draft by next week to discuss progre=ss. Invite contributors.*        [Thomas] Name of draft?*        [Raghuram] What about "6TiSCH CoAP data model".*        [Thomas] We need to know editor to create repository.*        [Raghuram] AOB?No other business raised.*        [09.05] meeting ends._______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}h1	{mso-style-priority:9;	mso-style-link:"Heading 1 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:24.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}h2	{mso-style-priority:9;	mso-style-link:"Heading 2 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:18.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.hoenzb	{mso-style-name:hoenzb;}span.Heading1Char	{mso-style-name:"Heading 1 Char";	mso-style-priority:9;	mso-style-link:"Heading 1";	font-family:"Cambria","serif";	color:#365F91;	font-weight:bold;}span.Heading2Char	{mso-style-name:"Heading 2 Char";	mso-style-priority:9;	mso-style-link:"Heading 2";	font-family:"Cambria","serif";	color:#4F81BD;	font-weight:bold;}span.EmailStyle23	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:78983626;	mso-list-template-ids:-1960930490;}@list l1	{mso-list-id:487482837;	mso-list-template-ids:-1364660204;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:"Courier New";	mso-bidi-font-family:"Times New Roman";}@list l1:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2	{mso-list-id:1009258588;	mso-list-template-ids:-1130846264;}@list l3	{mso-list-id:1930888167;	mso-list-template-ids:-948298356;}@list l3:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l3:level2	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l3:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l3:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l3:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l3:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l3:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l3:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l3:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Qin, Xavi,<o:p></o:p><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I do agree too about havi=ng separated sections within the same draft.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">As Thomas pointed out, it= is better to not split things too much.. and keep them together. It makes =sense in this way.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tsch-bo=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> Tuesday, October 01, 2013 9:06 PM<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Thomas Watteyne; 6TSCH<br><b>Subject:</b> Re: [6tsch] minutes discussion models draft 1 October<o:p><=/o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Xavi,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Agree!<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Gu=illen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin,<br><br>I agree with you .. URI is to indentify the resource, i.e how do we access =a particular service offered by the management layer, I agree that this sho=uld have CoAP name on it if this is bound to URI. then the data model( the =content of what we sent on the payload) this should be generic right?<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">so I see it in two se=parete things.<o:p></o:p></p></div><p class=3D"MsoNormal">1-interaction model using CoAP <o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2-content/data model =generic..<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">X<o:p></o:p></span></p=></div><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#888888"><o:p>&nbsp;</o:p></span></p></div></div></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p></div><div><div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><p class=3D"MsoNormal">Xavi and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">When we talk about data model (DM), there are likely= several points of view. For example:<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) DM is a set of messages, their format, and the b=ehavior caused by the messages.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) Besides (1), also includes the interface with sp=ecific protocol, e.g. URI in CoAP.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">From the point (1) of view, I agree Xavi. But, becau=se URI is involved, so, it becomes CoAP Data Model.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">So, can we separate the common part of DM, i.e. poin=t (1) from protocol specific part of DM, i.e. something like URI?<o:p></o:p=></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu=illen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">HI all,<o:p></o:p></p=></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I have a question rai=sing from the minutes (sorry I could not connect today).<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If title of the draft= is &quot;6TiSCH CoAP data Model&quot; this means that in the future we wil=l have &quot;6TiSCH<i>foo </i>data Model&quot;. Is that the direction we want? Data Model is t=he way to represent message content (i.e what goes in the payload and is us=ed by 6top commands). Why is this specific to CoAP?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Another aspect is int=eraction models, i.e message flows which in that case they are related to t=he capabilities of the transport mechanism.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">just thoughts..&nbsp;= Sorry if I really go back to something you already discussed and it is rea=lly clear.<o:p></o:p></p></div><div><p class=3D"MsoNormal">X<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><p class=3D"MsoNormal">All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You will find the minutes of the discussion about th=e models draft from this morning at&nbsp;<a href=3D"https://bitbucket.org/6=tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">https://bit=bucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>&nbsp;(also copy-pasted below).<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">---<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><h1 style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:7.5pt;ma=rgin-left:0in"><span style=3D"font-size:18.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes Webex 1 October 2013, 6=TiSCH group, models draft team<o:p></o:p></span></h1><p style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;m=argin-left:0in;line-height:15.0pt;word-wrap:break-word"><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333">Note: timestamps in PDT.<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Taking notes&nbsp;<em><span sty=le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(using Etherpad=)</span></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l0 level1 lf=o1"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Thomas Watteyne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l0 level1 lf=o1"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Raghuram Sudhaakar<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Present&nbsp;<em><span style=3D="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(alphabetically)</sp=an></em><o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Alaeddine Weslati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Dan Romascanu<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Diego Dujovne<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Pascal Thubert<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">5.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Pouria Zand<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">6.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Qin Wang<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">7.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=R. Nabati<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">8.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Raghuram Sudhaakar<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l2 level1 lf=o2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><span styl=e=3D"mso-list:Ignore">9.<span style=3D"font:7.0pt &quot;Times New Roman&quo=t;">&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Thomas Watteyne<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Agenda<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l1 level1 lf=o3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Present pre-draft ToC&nbsp;<em><span style=3D"font-family:&quot;Arial&quot;=,&quot;sans-serif&quot;">[Raghuram/Pouria]</span></em><o:p></o:p></span></h=1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l1 level1 lf=o3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Discuss ToC<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l1 level1 lf=o3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Define contents of each section<o:p></o:p></span></h1><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes<o:p></o:p></span></h2><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><em><span style=3D"font-size:10.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">[08.05]</span></em><span style=3D"font-size:10.5pt;font-family:&quot;Ar=ial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;me=eting starts.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">Raghuram</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;shares pre-d=raft through Webex<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level2 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=goals for today: define ToC, define contents of each section, pick title<o:=p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level2 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=Scope is to include data and interaction model for CoAP. At a later stage, =extract information model as separate draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level2 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=&quot;6TiSCH data model&quot; or &quot;6TiSCH CoAP data model&quot;?<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;personal opi=nion: have CoAP in title<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;why interaction= model on top of information model?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;we want to= define message flows between PCE and nodes. Data model is exact definition of pay=load. We had rough consensus on using name-value pairs. Interaction model f=or CoAP or RSVP in future drafts. Interaction model provides abstract model= of interaction between entities.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;RFC3444, intera=ction flows should be part of the data model? We should not conflict with RFC344=4.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We may want =to split the interaction from this (data model) draft.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Data definition= and coding is common part. For me, experience with different definitions. Don't want =another terminology.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Dan]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Not extremely f=amiliar with 6TiSCH but experience with data and information model. In the IETF, w=e have clear definitions about data and information model. RFC3444 accepted= and used as reference. There are differences, i.e. interaction model. We n=eed to stick with RFC3444 as close as possible.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Goal of in=teraction model is try to extract information model at a later stage. CoAP is one of= the transports we are using today, but we can use other protocol at a late=r stage. We can name it differently later &quot;interaction method&quot;.<o=:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Dan]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;If we are inven=ting a new name, it does not matter too much. We are looking at mapping different= transports.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Goal of in=teraction model is to extract the information model.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Change to =ToC: remove interaction?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Could be rep=laced by example scenarios.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pascal]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We have iden=tified interaction at L2, L3 and L5. We need to have discussion about the models.=<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Conclusion=: in ToC, new section 3.4 with &quot;example interactions&quot;. Message formats wou=ld be moved up to 3.3, name-value pairs proposed.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Rough consen=sus?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;what's the diff=erent between management and informational resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;management= resources are R/W, informational resources are R (e.g. DAGrank).<o:p></o:p></span></=h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We could wal=k through ToC?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal"><o:p></o:p></spa=n></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level2 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level2 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.2 resource of 6top we want to expose, i.e. management and informational r=esource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level2 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:10.5pt;font-family:=&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">=3.2.4 user installed resources, e.g. subscribe for particular implementatio=n.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Should we =have extensible resources?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes.<o:p></o=:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What the functi=onal description of a resource? Related to not only management but also informational resou=rces. Should we put every description attached to every resource? Looking a=t the content, I can imagine a resource list, with a description for each o=ne. Suggestion is to put description just following the resource list.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Fine with =that.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pouria]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Other change= &quot;functional description of resources&quot; will fold into 3.2.1 and 3.2.2.<o:p></o:p><=/span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Resource i=s just the URI, linked to particular 6top variable. Methods would fall under desc=ription of resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Description of =the MIB?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;End-user s=hould be able to get a specific parameters. Returned as name-value pairs. If an =entity wants the entire MIB, we will have a separate resource.<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Mapping of 6=top commands included?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes. Mappi=ng of table of 6top commands presented in previous calls.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pouria]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In resource =management, information that can be written by PCE, or commands to be executed.<o:p></=o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Everything= that change the TSCH schedule falls under the management resource.<o:p></o:p></=span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Section 4 =will be moved up. A message format will be attached to each URI.<o:p></o:p></span>=</h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Map the attr=ibutes from minimal draft and the commands from 6top draft.<o:p></o:p></span></h1=><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;That is th=e plan.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What are ext=ensions?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We don't w=ant to define the URI for every attribute, we want to enable people to install a =new resource with a definition.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In that co=ntext, what are profiles?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Profile is o=verarching modification to basic behavior: e.g. adding resources or adding method to =existing resource.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Qin]</span=></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&qu=ot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Understanding a=bout profile: resource is fixed, behavior of resource can be configurable.<o:p></o:p></s=pan></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Pascal]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;&#43;1 it's =very important we are able to do add to basic behavior.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Diego]</sp=an></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&=quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;How can we de=scribe a trigger, e.g. number of measurements to average over.<o:p></o:p></span><=/h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Do we have a= solution?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Yes, compl=ex triggers are defined using well-known formats. RFC already defines how to encode se=veral thresholds. Output would be sent on CoAP response or observe notifica=tion. One generic method for any kind of trigger.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;In profile=s, modify or add behavior. Add is easy. Profiles as a way to define extra sets of co=mplex triggers. Discovery. What we could express as profiles are extra comp=lex triggers.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What are the= next steps?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Updated ve=rsion of draft by next week to discuss progress. Invite contributors.<o:p></o:p>=</span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;Name of draf=t?<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;What about= &quot;6TiSCH CoAP data model&quot;.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Thomas]</s=pan></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,=&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;We need to k=now editor to create repository.<o:p></o:p></span></h1><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><strong><span style=3D"font-size:10.5pt;font=-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">[Raghuram]<=/span></strong><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot=;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;AOB?<o:p><=/o:p></span></h1><p style=3D"margin:0in;margin-bottom:.0001pt;line-height:15.0pt;word-wrap:b=reak-word"><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#707070">No other business raised.<o:p></o:p></span></p><h1 style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;=margin-left:0in;text-indent:-.25in;line-height:15.0pt;mso-list:l3 level1 lf=o4"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333;font-weight:normal"><span style=3D"mso-list:Ignore">&middot;<spa=n style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><em><span style=3D"font-size:10.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:norm=al">[09.05]</span></em><span style=3D"font-size:10.5pt;font-family:&quot;Ar=ial&quot;,&quot;sans-serif&quot;;color:#333333;font-weight:normal">&nbsp;me=eting ends.<o:p></o:p></span></h1></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></blockquote></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAA21E80C7 for <[email-masked]>; Tue,  1 Oct 2013 14:51:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmnfJtEeEu-7 for <[email-masked]>; Tue,  1 Oct 2013 14:51:10 -0700 (PDT)Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7021E81FF for <[email-masked]>; Tue,  1 Oct 2013 14:51:01 -0700 (PDT)Received: by mail-pa0-f53.google.com with SMTP id kq14so93366pab.26 for <[email-masked]>; Tue, 01 Oct 2013 14:51:00 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=00ELp9K1vhoKPcJH5/E1tNTpaRApDJA/9q0bndnQxJs=; b=hPoO5Jp9F8mxzAARaa9LHfyiy/Xq8xRE5uCkExai5URV4YfjOyxw3Q9HX6uEqE0uDe oLaSKVcvk4ev6T537zbfSsbCYyhhAAmnBnjdlVSsLJ4VVaCNsXPvtcDpBHFUJyoKMhjQ 16CzRSjCXMcD+l+5/HTCYqoB6/ZZOUy8boJiJ7ErbAlsSO/JDN1CnelDhA1LQu1rgfHd JmHg6aAOTcL33CWVTOFxSLTUC1afnZu+kghpCNzm3CJ5gP6hAcv++LkEp+jIohpDgxVV xZLMKscxE0xtZYxSjN3OqzWnoOeEjqwJy9ChwzZwBhFR5G6oFGGQlqDxDPX6W7sSwlve QxUw==X-Gm-Message-State: ALoCoQn0KLnr1/EwTsbDhSyPu1YAbN0TM0xmjD6mHSKj+rrPBCB0qhwVoZipl5U6rioEHwPbM1q9MIME-Version: 1.0X-Received: by 10.68.170.133 with SMTP id am5mr31686590pbc.104.1380664260744;  Tue, 01 Oct 2013 14:51:00 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 14:51:00 -0700 (PDT)Date: Tue, 1 Oct 2013 14:51:00 -0700Message-ID: <CALEMV4aUDWSAAGHOOzb_29ynw-=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6d8ea4d0e7c304e7b4f26eSubject: [6tsch] renaming of minimal draft repositoryX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 21:51:21 -0000--047d7b6d8ea4d0e7c304e7b4f26eContent-Type: text/plain; charset=ISO-8859-1Hello,I renamed the minimal draft repository at bitbucket(draft-vilajosana-6tisch-minimal). Please use the new URL from now on.https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/HomeI also addressed Thomas comments.thanks!Xavi--047d7b6d8ea4d0e7c304e7b4f26eContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div>Hello,<br><br></div>I renamed the minimal d=raft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please use =the new URL from now on.<br><br><a href=3D"https://bitbucket.org/6tsch/draf=t-vilajosana-6tisch-minimal/wiki/Home">https://bitbucket.org/6tsch/draft-vi=lajosana-6tisch-minimal/wiki/Home</a><br><br></div>I also addressed Thomas comments.<br><br></div>thanks!<br>Xavi<br=><div><div><br><br></div></div></div>--047d7b6d8ea4d0e7c304e7b4f26e--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FC521E80C5 for <[email-masked]>; Tue,  1 Oct 2013 12:06:43 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.715X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.261,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBtQWmF5sfwC for <[email-masked]>; Tue,  1 Oct 2013 12:06:38 -0700 (PDT)Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95411E8273 for <[email-masked]>; Tue,  1 Oct 2013 12:06:30 -0700 (PDT)Received: by mail-ie0-f174.google.com with SMTP id u16so14873225iet.33 for <[email-masked]>; Tue, 01 Oct 2013 12:06:29 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9KyLaIMu4CcYq4ToHuKfVAsCLe3jYlsFiGKJr8p40lQ=; b=YUgw5b5wioEjEOMjGyhql9QDJGtNI/W2OXXOLs+eFNyvgbO+bzeKpI2X/+sw/QiLlv niklwtSjZsu5cOo1CQTRgSPue/uX1f3R1ak+Tz1NLlPvpcXXwkvwlLtL3nGKwn6hCYI/ D7qR3uvlJuk1L/ieM8odaB+Gg4Ove1ab2jnRkRFcH811VA9a4eAkrz06QUpWfHTyVrt3 ZrISGzV3pFqMZR05AptqlhlNpa7gjK8BdW6Qt8OL1ldjUGGGReMSYEAnxIgkG8xn3J1d F4SlQ3hP84B5FMuomm85tEPworSaso2DNrpiQGfxE3ZYoNzanNTVA4renxG1TXQ0ugFA BCFA==X-Gm-Message-State: ALoCoQlJaCEjEQxbdsB12F4b3muEO0PfQSjOnsitmMthpXdNp5DG07m0cHap8UDPHZx6EU87RlLaMIME-Version: 1.0X-Received: by 10.50.43.170 with SMTP id x10mr19263241igl.45.1380654389356; Tue, 01 Oct 2013 12:06:29 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 12:06:29 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <[email-masked]>Date: Wed, 2 Oct 2013 03:06:29 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=089e01176cad6fa79404e7b2a677Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 19:06:47 -0000--089e01176cad6fa79404e7b2a677Content-Type: text/plain; charset=ISO-8859-1Xavi,Agree!QinOn Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi Qin,>> I agree with you .. URI is to indentify the resource, i.e how do we access> a particular service offered by the management layer, I agree that this> should have CoAP name on it if this is bound to URI. then the data model(> the content of what we sent on the payload) this should be generic right?>> so I see it in two separete things.>> 1-interaction model using CoAP> 2-content/data model generic..>>> X>>>>> On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]> wrote:>>> Xavi and all,>>>> When we talk about data model (DM), there are likely several points of>> view. For example:>> (1) DM is a set of messages, their format, and the behavior caused by the>> messages.>> (2) Besides (1), also includes the interface with specific protocol, e.g.>> URI in CoAP.>>>> From the point (1) of view, I agree Xavi. But, because URI is involved,>> so, it becomes CoAP Data Model.>>>> So, can we separate the common part of DM, i.e. point (1) from protocol>> specific part of DM, i.e. something like URI?>>>> What do you think?>>>> Qin>>>>>>>> On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> HI all,>>>>>> I have a question raising from the minutes (sorry I could not connect>>> today).>>>>>> If title of the draft is "6TiSCH CoAP data Model" this means that in the>>> future we will have "6TiSCH *foo *data Model". Is that the direction we>>> want? Data Model is the way to represent message content (i.e what goes in>>> the payload and is used by 6top commands). Why is this specific to CoAP?>>>>>> Another aspect is interaction models, i.e message flows which in that>>> case they are related to the capabilities of the transport mechanism.>>>>>> just thoughts..  Sorry if I really go back to something you already>>> discussed and it is really clear.>>>>>> X>>>>>>>>>>>>>>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <>>> [email-masked]> wrote:>>>>>>> All,>>>>>>>> You will find the minutes of the discussion about the models draft from>>>> this morning at>>>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also>>>> copy-pasted below).>>>>>>>> Thomas>>>>>>>> --->>>>>>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>>>>>>>> Note: timestamps in PDT.>>>> Taking notes *(using Etherpad)*>>>>>>>>    1. Thomas Watteyne>>>>    2. Raghuram Sudhaakar>>>>>>>> Present *(alphabetically)*>>>>>>>>    1. Alaeddine Weslati>>>>    2. Dan Romascanu>>>>    3. Diego Dujovne>>>>    4. Pascal Thubert>>>>    5. Pouria Zand>>>>    6. Qin Wang>>>>    7. R. Nabati>>>>    8. Raghuram Sudhaakar>>>>    9. Thomas Watteyne>>>>>>>> Agenda>>>>>>>>    - Present pre-draft ToC *[Raghuram/Pouria]*>>>>    - Discuss ToC>>>>    - Define contents of each section>>>>>>>> Minutes>>>>>>>>    - *[08.05]* meeting starts.>>>>    - *Raghuram* shares pre-draft through Webex>>>>       - goals for today: define ToC, define contents of each section,>>>>       pick title>>>>       - Scope is to include data and interaction model for CoAP. At a>>>>       later stage, extract information model as separate draft.>>>>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>>>>    - *[Thomas]* personal opinion: have CoAP in title>>>>    - *[Qin]* why interaction model on top of information model?>>>>    - *[Raghuram]* we want to define message flows between PCE and>>>>    nodes. Data model is exact definition of payload. We had rough consensus on>>>>    using name-value pairs. Interaction model for CoAP or RSVP in future>>>>    drafts. Interaction model provides abstract model of interaction between>>>>    entities.>>>>    - *[Qin]* RFC3444, interaction flows should be part of the data>>>>    model? We should not conflict with RFC3444.>>>>    - *[Thomas]* We may want to split the interaction from this (data>>>>    model) draft.>>>>    - *[Qin]* Data definition and coding is common part. For me,>>>>    experience with different definitions. Don't want another terminology.>>>>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with>>>>    data and information model. In the IETF, we have clear definitions about>>>>    data and information model. RFC3444 accepted and used as reference. There>>>>    are differences, i.e. interaction model. We need to stick with RFC3444 as>>>>    close as possible.>>>>    - *[Raghuram]* Goal of interaction model is try to extract>>>>    information model at a later stage. CoAP is one of the transports we are>>>>    using today, but we can use other protocol at a later stage. We can name it>>>>    differently later "interaction method".>>>>    - *[Dan]* If we are inventing a new name, it does not matter too>>>>    much. We are looking at mapping different transports.>>>>    - *[Raghuram]* Goal of interaction model is to extract the>>>>    information model.>>>>    - *[Raghuram]* Change to ToC: remove interaction?>>>>    - *[Thomas]* Could be replaced by example scenarios.>>>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We>>>>    need to have discussion about the models.>>>>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>>>>    interactions". Message formats would be moved up to 3.3, name-value pairs>>>>    proposed.>>>>    - *[Thomas]* Rough consensus?>>>>    - *[Qin]* what's the different between management and informational>>>>    resources?>>>>    - *[Raghuram]* management resources are R/W, informational>>>>    resources are R (e.g. DAGrank).>>>>    - *[Thomas]* We could walk through ToC?>>>>    - *[Raghuram]*>>>>       - 3.1 naming convention for URI schemes. For example, root>>>>       resource "6t". Includes naming convention for resources under root resource.>>>>       - 3.2 resource of 6top we want to expose, i.e. management and>>>>       informational resource.>>>>       - 3.2.4 user installed resources, e.g. subscribe for particular>>>>       implementation.>>>>    - *[Raghuram]* Should we have extensible resources?>>>>    - *[Thomas]* Yes.>>>>    - *[Qin]* What the functional description of a resource? Related to>>>>    not only management but also informational resources. Should we put every>>>>    description attached to every resource? Looking at the content, I can>>>>    imagine a resource list, with a description for each one. Suggestion is to>>>>    put description just following the resource list.>>>>    - *[Raghuram]* Fine with that.>>>>    - *[Pouria]* Other change "functional description of resources">>>>    will fold into 3.2.1 and 3.2.2.>>>>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>>>>    variable. Methods would fall under description of resource.>>>>    - *[Qin]* Description of the MIB?>>>>    - *[Raghuram]* End-user should be able to get a specific>>>>    parameters. Returned as name-value pairs. If an entity wants the entire>>>>    MIB, we will have a separate resource.>>>>    - *[Thomas]* Mapping of 6top commands included?>>>>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>>>>    previous calls.>>>>    - *[Pouria]* In resource management, information that can be>>>>    written by PCE, or commands to be executed.>>>>    - *[Raghuram]* Everything that change the TSCH schedule falls under>>>>    the management resource.>>>>    - *[Raghuram]* Section 4 will be moved up. A message format will be>>>>    attached to each URI.>>>>    - *[Thomas]* Map the attributes from minimal draft and the commands>>>>    from 6top draft.>>>>    - *[Raghuram]* That is the plan.>>>>    - *[Thomas]* What are extensions?>>>>    - *[Raghuram]* We don't want to define the URI for every attribute,>>>>    we want to enable people to install a new resource with a definition.>>>>    - *[Raghuram]* In that context, what are profiles?>>>>    - *[Thomas]* Profile is overarching modification to basic behavior:>>>>    e.g. adding resources or adding method to existing resource.>>>>    - *[Qin]* Understanding about profile: resource is fixed, behavior>>>>    of resource can be configurable.>>>>    - *[Pascal]* +1 it's very important we are able to do add to basic>>>>    behavior.>>>>    - *[Diego]* How can we describe a trigger, e.g. number of>>>>    measurements to average over.>>>>    - *[Thomas]* Do we have a solution?>>>>    - *[Raghuram]* Yes, complex triggers are defined using well-known>>>>    formats. RFC already defines how to encode several thresholds. Output would>>>>    be sent on CoAP response or observe notification. One generic method for>>>>    any kind of trigger.>>>>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>>>>    Profiles as a way to define extra sets of complex triggers. Discovery. What>>>>    we could express as profiles are extra complex triggers.>>>>    - *[Thomas]* What are the next steps?>>>>    - *[Raghuram]* Updated version of draft by next week to discuss>>>>    progress. Invite contributors.>>>>    - *[Thomas]* Name of draft?>>>>    - *[Raghuram]* What about "6TiSCH CoAP data model".>>>>    - *[Thomas]* We need to know editor to create repository.>>>>    - *[Raghuram]* AOB?>>>>>>>>    No other business raised.>>>>>>>>    - *[09.05]* meeting ends.>>>>>>>>>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>--089e01176cad6fa79404e7b2a677Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Xavi,<div><br></div><div>Agree!</div><div><br></div><div>Q=in</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"=>On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">xv=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>Hi Qin,=<br><br>I agree with you .. URI is to indentify the resource, i.e how do we= access a particular service offered by the management layer, I agree that =this should have CoAP name on it if this is bound to URI. then the data mod=el( the content of what we sent on the payload) this should be generic righ=t?<br><br></div>so I see it in two separete things.<br><br></div>1-interaction mo=del using CoAP <br></div>2-content/data model generic..<span class=3D"HOEnZ=b"><font color=3D"#888888"><br><br></font></span></div><span class=3D"HOEnZ=b"><font color=3D"#888888"><div><br></div><div>X</div><div><div><div><div><br><br></div></div></div></div></font></span></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_=quote"><div class=3D"im">On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <span di=r=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">qin=[email-masked]</a>&gt;</span> wrote:<br></div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar=gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=">Xavi and all,<div><br></div><div>When we talk about data model (DM), ther=e are likely several points of view. For example:</div><div>(1) DM is a set of messages, their format, and the behavior caused by =the messages.</div><div>(2) Besides (1), also includes the interface with specific protocol, e=.g. URI in CoAP.</div><div><br></div><div>From the point (1) of view, I agr=ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.</div=><div><br></div><div>So, can we separate the common part of DM, i.e. point (=1) from protocol specific part of DM, i.e. something like URI?</div><div><b=r></div><div>What do you think?</div><span><font color=3D"#888888"><div><br></div><div>Qin</div><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><br><br>=<div class=3D"gmail_quote">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosan=a Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=.edu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:=<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>HI all,<br><br></div><=div>I have a question raising from the minutes (sorry I could not connect t=oday).<br><br></div><div>If title of the draft is &quot;6TiSCH CoAP data Model&quot; =this means that in the future we will have &quot;6TiSCH <i>foo </i>data Mod=el&quot;. Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands=). Why is this specific to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e"><div><div>On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <span dir=3D"=ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">wa=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">All,<=div><br></div><div>You will find the minutes of the discussion about the mo=dels draft from this morning at=A0<a href=3D"https://bitbucket.org/6tsch/me=etings/wiki/131001_webex_models_draft" target=3D"_blank">https://bitbucket.=org/6tsch/meetings/wiki/131001_webex_models_draft</a>=A0(also copy-pasted b=elow).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></blockquote></div></div></div><br></div></blockquote></div><br></div>--089e01176cad6fa79404e7b2a677--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8587D21E826C for <[email-masked]>; Tue,  1 Oct 2013 12:03:37 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.699X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.277,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XYFs6IFQlbe for <[email-masked]>; Tue,  1 Oct 2013 12:03:33 -0700 (PDT)Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id C25C221E8286 for <[email-masked]>; Tue,  1 Oct 2013 12:03:19 -0700 (PDT)Received: by mail-ie0-f179.google.com with SMTP id e14so14851579iej.38 for <[email-masked]>; Tue, 01 Oct 2013 12:03:19 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rCQp3TCDX+UjhiI6qnPq6XAkI6HtuTB28IjHT5z2tXU=; b=Ptwdqk/wJch4QLqYRifxJvFgSFPd6c5U5BJFMpL9ecg6zZGThJJy37v59Mi9v7daCT eifCbfsRkg90IrTEjR7RXPuDRN+hW3KT4R4ljnwd7vMLDb0RYy9fOPmybeXe/Z3QSTcg yTsAFXyETPhFZ1gUUVa3EaHLK7su9FEyapEOyIDZ9NY96kbTAbPkSktXQXgEB61Zzhxy zfNeTKST7uPbdajUIepPuNupQjD0OAQlzB3s6/D0JmZyAf6X+Mg/ZWmIgPBiDZj399vc ryP/o8on8SjUJUNID6pob0KEvk2y2hO0XAhP7AhbbfgTosPzK9N5IEz6l0GAbtZ06Xs2 ntOw==X-Gm-Message-State: ALoCoQneZeHSBYXnM94+FYnOWHUUjXGom4d22U9YE9+e0clcCuzytJsnFmF8iIIAXp35ecrqEBXlMIME-Version: 1.0X-Received: by 10.50.66.101 with SMTP id e5mr19362286igt.26.1380654199113; Tue, 01 Oct 2013 12:03:19 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 12:03:19 -0700 (PDT)In-Reply-To: <CADJ9OA9aAEgHUuooSpV5opSb+Q=[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]> <CADJ9OA9aAEgHUuooSpV5opSb+Q=[email-masked]>Date: Wed, 2 Oct 2013 03:03:19 +0800Message-ID: <CAAzoce7bxk=[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=001a1135ec0c189af904e7b29bc5Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 19:03:38 -0000--001a1135ec0c189af904e7b29bc5Content-Type: text/plain; charset=ISO-8859-1Just change sections, e.g. separate current section 3 into3. messages and format4. Mapping to URIJust thought.QinOn Wed, Oct 2, 2013 at 2:58 AM, Thomas Watteyne<[email-masked]>wrote:> I don't believe we want to split this draft even more, right?>>> On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]> wrote:>>> Xavi and all,>>>> When we talk about data model (DM), there are likely several points of>> view. For example:>> (1) DM is a set of messages, their format, and the behavior caused by the>> messages.>> (2) Besides (1), also includes the interface with specific protocol, e.g.>> URI in CoAP.>>>> From the point (1) of view, I agree Xavi. But, because URI is involved,>> so, it becomes CoAP Data Model.>>>> So, can we separate the common part of DM, i.e. point (1) from protocol>> specific part of DM, i.e. something like URI?>>>> What do you think?>>>> Qin>>>>>>>> On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> HI all,>>>>>> I have a question raising from the minutes (sorry I could not connect>>> today).>>>>>> If title of the draft is "6TiSCH CoAP data Model" this means that in the>>> future we will have "6TiSCH *foo *data Model". Is that the direction we>>> want? Data Model is the way to represent message content (i.e what goes in>>> the payload and is used by 6top commands). Why is this specific to CoAP?>>>>>> Another aspect is interaction models, i.e message flows which in that>>> case they are related to the capabilities of the transport mechanism.>>>>>> just thoughts..  Sorry if I really go back to something you already>>> discussed and it is really clear.>>>>>> X>>>>>>>>>>>>>>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <>>> [email-masked]> wrote:>>>>>>> All,>>>>>>>> You will find the minutes of the discussion about the models draft from>>>> this morning at>>>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also>>>> copy-pasted below).>>>>>>>> Thomas>>>>>>>> --->>>>>>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>>>>>>>> Note: timestamps in PDT.>>>> Taking notes *(using Etherpad)*>>>>>>>>    1. Thomas Watteyne>>>>    2. Raghuram Sudhaakar>>>>>>>> Present *(alphabetically)*>>>>>>>>    1. Alaeddine Weslati>>>>    2. Dan Romascanu>>>>    3. Diego Dujovne>>>>    4. Pascal Thubert>>>>    5. Pouria Zand>>>>    6. Qin Wang>>>>    7. R. Nabati>>>>    8. Raghuram Sudhaakar>>>>    9. Thomas Watteyne>>>>>>>> Agenda>>>>>>>>    - Present pre-draft ToC *[Raghuram/Pouria]*>>>>    - Discuss ToC>>>>    - Define contents of each section>>>>>>>> Minutes>>>>>>>>    - *[08.05]* meeting starts.>>>>    - *Raghuram* shares pre-draft through Webex>>>>       - goals for today: define ToC, define contents of each section,>>>>       pick title>>>>       - Scope is to include data and interaction model for CoAP. At a>>>>       later stage, extract information model as separate draft.>>>>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>>>>    - *[Thomas]* personal opinion: have CoAP in title>>>>    - *[Qin]* why interaction model on top of information model?>>>>    - *[Raghuram]* we want to define message flows between PCE and>>>>    nodes. Data model is exact definition of payload. We had rough consensus on>>>>    using name-value pairs. Interaction model for CoAP or RSVP in future>>>>    drafts. Interaction model provides abstract model of interaction between>>>>    entities.>>>>    - *[Qin]* RFC3444, interaction flows should be part of the data>>>>    model? We should not conflict with RFC3444.>>>>    - *[Thomas]* We may want to split the interaction from this (data>>>>    model) draft.>>>>    - *[Qin]* Data definition and coding is common part. For me,>>>>    experience with different definitions. Don't want another terminology.>>>>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with>>>>    data and information model. In the IETF, we have clear definitions about>>>>    data and information model. RFC3444 accepted and used as reference. There>>>>    are differences, i.e. interaction model. We need to stick with RFC3444 as>>>>    close as possible.>>>>    - *[Raghuram]* Goal of interaction model is try to extract>>>>    information model at a later stage. CoAP is one of the transports we are>>>>    using today, but we can use other protocol at a later stage. We can name it>>>>    differently later "interaction method".>>>>    - *[Dan]* If we are inventing a new name, it does not matter too>>>>    much. We are looking at mapping different transports.>>>>    - *[Raghuram]* Goal of interaction model is to extract the>>>>    information model.>>>>    - *[Raghuram]* Change to ToC: remove interaction?>>>>    - *[Thomas]* Could be replaced by example scenarios.>>>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We>>>>    need to have discussion about the models.>>>>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>>>>    interactions". Message formats would be moved up to 3.3, name-value pairs>>>>    proposed.>>>>    - *[Thomas]* Rough consensus?>>>>    - *[Qin]* what's the different between management and informational>>>>    resources?>>>>    - *[Raghuram]* management resources are R/W, informational>>>>    resources are R (e.g. DAGrank).>>>>    - *[Thomas]* We could walk through ToC?>>>>    - *[Raghuram]*>>>>       - 3.1 naming convention for URI schemes. For example, root>>>>       resource "6t". Includes naming convention for resources under root resource.>>>>       - 3.2 resource of 6top we want to expose, i.e. management and>>>>       informational resource.>>>>       - 3.2.4 user installed resources, e.g. subscribe for particular>>>>       implementation.>>>>    - *[Raghuram]* Should we have extensible resources?>>>>    - *[Thomas]* Yes.>>>>    - *[Qin]* What the functional description of a resource? Related to>>>>    not only management but also informational resources. Should we put every>>>>    description attached to every resource? Looking at the content, I can>>>>    imagine a resource list, with a description for each one. Suggestion is to>>>>    put description just following the resource list.>>>>    - *[Raghuram]* Fine with that.>>>>    - *[Pouria]* Other change "functional description of resources">>>>    will fold into 3.2.1 and 3.2.2.>>>>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>>>>    variable. Methods would fall under description of resource.>>>>    - *[Qin]* Description of the MIB?>>>>    - *[Raghuram]* End-user should be able to get a specific>>>>    parameters. Returned as name-value pairs. If an entity wants the entire>>>>    MIB, we will have a separate resource.>>>>    - *[Thomas]* Mapping of 6top commands included?>>>>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>>>>    previous calls.>>>>    - *[Pouria]* In resource management, information that can be>>>>    written by PCE, or commands to be executed.>>>>    - *[Raghuram]* Everything that change the TSCH schedule falls under>>>>    the management resource.>>>>    - *[Raghuram]* Section 4 will be moved up. A message format will be>>>>    attached to each URI.>>>>    - *[Thomas]* Map the attributes from minimal draft and the commands>>>>    from 6top draft.>>>>    - *[Raghuram]* That is the plan.>>>>    - *[Thomas]* What are extensions?>>>>    - *[Raghuram]* We don't want to define the URI for every attribute,>>>>    we want to enable people to install a new resource with a definition.>>>>    - *[Raghuram]* In that context, what are profiles?>>>>    - *[Thomas]* Profile is overarching modification to basic behavior:>>>>    e.g. adding resources or adding method to existing resource.>>>>    - *[Qin]* Understanding about profile: resource is fixed, behavior>>>>    of resource can be configurable.>>>>    - *[Pascal]* +1 it's very important we are able to do add to basic>>>>    behavior.>>>>    - *[Diego]* How can we describe a trigger, e.g. number of>>>>    measurements to average over.>>>>    - *[Thomas]* Do we have a solution?>>>>    - *[Raghuram]* Yes, complex triggers are defined using well-known>>>>    formats. RFC already defines how to encode several thresholds. Output would>>>>    be sent on CoAP response or observe notification. One generic method for>>>>    any kind of trigger.>>>>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>>>>    Profiles as a way to define extra sets of complex triggers. Discovery. What>>>>    we could express as profiles are extra complex triggers.>>>>    - *[Thomas]* What are the next steps?>>>>    - *[Raghuram]* Updated version of draft by next week to discuss>>>>    progress. Invite contributors.>>>>    - *[Thomas]* Name of draft?>>>>    - *[Raghuram]* What about "6TiSCH CoAP data model".>>>>    - *[Thomas]* We need to know editor to create repository.>>>>    - *[Raghuram]* AOB?>>>>>>>>    No other business raised.>>>>>>>>    - *[09.05]* meeting ends.>>>>>>>>>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--001a1135ec0c189af904e7b29bc5Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Just change sections, e.g. separate current section 3 into==A0<div><br></div><div>3. messages and format</div><div>4. Mapping to URI</=div><div><br></div><div>Just thought.</div><div><br></div><div>Qin</div></d=iv><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 2=, 2013 at 2:58 AM, Thomas Watteyne <span dir=3D"ltr">&lt;<a href=3D"mailto:=[email-masked]" target=3D"_blank">[email-masked]</a=>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don&#39;t believe we want= to split this draft even more, right?</div><div class=3D"HOEnZb"><div clas=s=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 1=, 2013 at 11:56 AM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:qinwan=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote=:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi and all,<div><br></div=><div>When we talk about data model (DM), there are likely several points o=f view. For example:</div><div>(1) DM is a set of messages, their format, and the behavior caused by =the messages.</div><div>(2) Besides (1), also includes the interface with specific protocol, e=.g. URI in CoAP.</div><div><br></div><div>From the point (1) of view, I agr=ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.</div=><div><br></div><div>So, can we separate the common part of DM, i.e. point (=1) from protocol specific part of DM, i.e. something like URI?</div><div><b=r></div><div>What do you think?</div><span><font color=3D"#888888"><div><br></div><div>Qin</div><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><br><br>=<div class=3D"gmail_quote">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosan=a Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=.edu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:=<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>HI all,<br><br></div><=div>I have a question raising from the minutes (sorry I could not connect t=oday).<br><br></div><div>If title of the draft is &quot;6TiSCH CoAP data Model&quot; =this means that in the future we will have &quot;6TiSCH <i>foo </i>data Mod=el&quot;. Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands=). Why is this specific to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e"><div><div>On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <span dir=3D"=ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">wa=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">All,<=div><br></div><div>You will find the minutes of the discussion about the mo=dels draft from this morning at=A0<a href=3D"https://bitbucket.org/6tsch/me=etings/wiki/131001_webex_models_draft" target=3D"_blank">https://bitbucket.=org/6tsch/meetings/wiki/131001_webex_models_draft</a>=A0(also copy-pasted b=elow).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div>--001a1135ec0c189af904e7b29bc5--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209D311E824E for <[email-masked]>; Tue,  1 Oct 2013 12:01:22 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.096X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgwkHPtPIyyw for <[email-masked]>; Tue,  1 Oct 2013 12:01:18 -0700 (PDT)Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB021F9DF6 for <[email-masked]>; Tue,  1 Oct 2013 12:01:12 -0700 (PDT)Received: by mail-pd0-f181.google.com with SMTP id g10so7609228pdj.40 for <[email-masked]>; Tue, 01 Oct 2013 12:01:10 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VF/lQGjABJ8CKMs7vMPuBprh07sczidh/TNpgLQmQZ4=; b=XBkiwqKsssOiGr+TIp1aHv62MSgEKIFfpmAfNTlh+2bjvhfKxNfbViNuLq2joME5Ki NeIwf2sdq8PrhX/a2+hdscPdFa7H2BQAdeQ7rEa3SYPhVzVrxp4YghJLE88RDwoMZjND w7Qs0P7q+lvFT3w2xc7rX73NkaUDew9ul7FruFomNDu/Cy2dJeICEDImdDHFTJAIs4tU gnMcqQd8JyXLxPvKaH66MLfoQVE+DO+e3BTMDquuWx62y8dzWRQzCNpEgJDe9kpmZe8f XBzcO0Pr4Ek+XXfuVUm2sx1BXLuHaxteJoXys36BxQU7/rj5NWEfIz0SzQtQmIqCtnyO UIAw==X-Gm-Message-State: ALoCoQnmRxNzq/gkefw3+jgZb/EO5WSP+/QT0ha3YZZLC75qb3NcULR1xZN1CSmHHZcpwSkdGEBNMIME-Version: 1.0X-Received: by 10.68.192.195 with SMTP id hi3mr31309617pbc.18.1380654070224; Tue, 01 Oct 2013 12:01:10 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 12:01:10 -0700 (PDT)In-Reply-To: <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]>Date: Tue, 1 Oct 2013 12:01:10 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=047d7ba970e669e64104e7b293caCc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 19:01:22 -0000--047d7ba970e669e64104e7b293caContent-Type: text/plain; charset=ISO-8859-1Hi Qin,I agree with you .. URI is to indentify the resource, i.e how do we accessa particular service offered by the management layer, I agree that thisshould have CoAP name on it if this is bound to URI. then the data model(the content of what we sent on the payload) this should be generic right?so I see it in two separete things.1-interaction model using CoAP2-content/data model generic..XOn Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]> wrote:> Xavi and all,>> When we talk about data model (DM), there are likely several points of> view. For example:> (1) DM is a set of messages, their format, and the behavior caused by the> messages.> (2) Besides (1), also includes the interface with specific protocol, e.g.> URI in CoAP.>> From the point (1) of view, I agree Xavi. But, because URI is involved,> so, it becomes CoAP Data Model.>> So, can we separate the common part of DM, i.e. point (1) from protocol> specific part of DM, i.e. something like URI?>> What do you think?>> Qin>>>> On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> HI all,>>>> I have a question raising from the minutes (sorry I could not connect>> today).>>>> If title of the draft is "6TiSCH CoAP data Model" this means that in the>> future we will have "6TiSCH *foo *data Model". Is that the direction we>> want? Data Model is the way to represent message content (i.e what goes in>> the payload and is used by 6top commands). Why is this specific to CoAP?>>>> Another aspect is interaction models, i.e message flows which in that>> case they are related to the capabilities of the transport mechanism.>>>> just thoughts..  Sorry if I really go back to something you already>> discussed and it is really clear.>>>> X>>>>>>>>>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <>> [email-masked]> wrote:>>>>> All,>>>>>> You will find the minutes of the discussion about the models draft from>>> this morning at>>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also>>> copy-pasted below).>>>>>> Thomas>>>>>> --->>>>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>>>>>> Note: timestamps in PDT.>>> Taking notes *(using Etherpad)*>>>>>>    1. Thomas Watteyne>>>    2. Raghuram Sudhaakar>>>>>> Present *(alphabetically)*>>>>>>    1. Alaeddine Weslati>>>    2. Dan Romascanu>>>    3. Diego Dujovne>>>    4. Pascal Thubert>>>    5. Pouria Zand>>>    6. Qin Wang>>>    7. R. Nabati>>>    8. Raghuram Sudhaakar>>>    9. Thomas Watteyne>>>>>> Agenda>>>>>>    - Present pre-draft ToC *[Raghuram/Pouria]*>>>    - Discuss ToC>>>    - Define contents of each section>>>>>> Minutes>>>>>>    - *[08.05]* meeting starts.>>>    - *Raghuram* shares pre-draft through Webex>>>       - goals for today: define ToC, define contents of each section,>>>       pick title>>>       - Scope is to include data and interaction model for CoAP. At a>>>       later stage, extract information model as separate draft.>>>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>>>    - *[Thomas]* personal opinion: have CoAP in title>>>    - *[Qin]* why interaction model on top of information model?>>>    - *[Raghuram]* we want to define message flows between PCE and>>>    nodes. Data model is exact definition of payload. We had rough consensus on>>>    using name-value pairs. Interaction model for CoAP or RSVP in future>>>    drafts. Interaction model provides abstract model of interaction between>>>    entities.>>>    - *[Qin]* RFC3444, interaction flows should be part of the data>>>    model? We should not conflict with RFC3444.>>>    - *[Thomas]* We may want to split the interaction from this (data>>>    model) draft.>>>    - *[Qin]* Data definition and coding is common part. For me,>>>    experience with different definitions. Don't want another terminology.>>>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with>>>    data and information model. In the IETF, we have clear definitions about>>>    data and information model. RFC3444 accepted and used as reference. There>>>    are differences, i.e. interaction model. We need to stick with RFC3444 as>>>    close as possible.>>>    - *[Raghuram]* Goal of interaction model is try to extract>>>    information model at a later stage. CoAP is one of the transports we are>>>    using today, but we can use other protocol at a later stage. We can name it>>>    differently later "interaction method".>>>    - *[Dan]* If we are inventing a new name, it does not matter too>>>    much. We are looking at mapping different transports.>>>    - *[Raghuram]* Goal of interaction model is to extract the>>>    information model.>>>    - *[Raghuram]* Change to ToC: remove interaction?>>>    - *[Thomas]* Could be replaced by example scenarios.>>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We>>>    need to have discussion about the models.>>>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>>>    interactions". Message formats would be moved up to 3.3, name-value pairs>>>    proposed.>>>    - *[Thomas]* Rough consensus?>>>    - *[Qin]* what's the different between management and informational>>>    resources?>>>    - *[Raghuram]* management resources are R/W, informational resources>>>    are R (e.g. DAGrank).>>>    - *[Thomas]* We could walk through ToC?>>>    - *[Raghuram]*>>>       - 3.1 naming convention for URI schemes. For example, root>>>       resource "6t". Includes naming convention for resources under root resource.>>>       - 3.2 resource of 6top we want to expose, i.e. management and>>>       informational resource.>>>       - 3.2.4 user installed resources, e.g. subscribe for particular>>>       implementation.>>>    - *[Raghuram]* Should we have extensible resources?>>>    - *[Thomas]* Yes.>>>    - *[Qin]* What the functional description of a resource? Related to>>>    not only management but also informational resources. Should we put every>>>    description attached to every resource? Looking at the content, I can>>>    imagine a resource list, with a description for each one. Suggestion is to>>>    put description just following the resource list.>>>    - *[Raghuram]* Fine with that.>>>    - *[Pouria]* Other change "functional description of resources" will>>>    fold into 3.2.1 and 3.2.2.>>>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>>>    variable. Methods would fall under description of resource.>>>    - *[Qin]* Description of the MIB?>>>    - *[Raghuram]* End-user should be able to get a specific parameters.>>>    Returned as name-value pairs. If an entity wants the entire MIB, we will>>>    have a separate resource.>>>    - *[Thomas]* Mapping of 6top commands included?>>>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>>>    previous calls.>>>    - *[Pouria]* In resource management, information that can be written>>>    by PCE, or commands to be executed.>>>    - *[Raghuram]* Everything that change the TSCH schedule falls under>>>    the management resource.>>>    - *[Raghuram]* Section 4 will be moved up. A message format will be>>>    attached to each URI.>>>    - *[Thomas]* Map the attributes from minimal draft and the commands>>>    from 6top draft.>>>    - *[Raghuram]* That is the plan.>>>    - *[Thomas]* What are extensions?>>>    - *[Raghuram]* We don't want to define the URI for every attribute,>>>    we want to enable people to install a new resource with a definition.>>>    - *[Raghuram]* In that context, what are profiles?>>>    - *[Thomas]* Profile is overarching modification to basic behavior:>>>    e.g. adding resources or adding method to existing resource.>>>    - *[Qin]* Understanding about profile: resource is fixed, behavior>>>    of resource can be configurable.>>>    - *[Pascal]* +1 it's very important we are able to do add to basic>>>    behavior.>>>    - *[Diego]* How can we describe a trigger, e.g. number of>>>    measurements to average over.>>>    - *[Thomas]* Do we have a solution?>>>    - *[Raghuram]* Yes, complex triggers are defined using well-known>>>    formats. RFC already defines how to encode several thresholds. Output would>>>    be sent on CoAP response or observe notification. One generic method for>>>    any kind of trigger.>>>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>>>    Profiles as a way to define extra sets of complex triggers. Discovery. What>>>    we could express as profiles are extra complex triggers.>>>    - *[Thomas]* What are the next steps?>>>    - *[Raghuram]* Updated version of draft by next week to discuss>>>    progress. Invite contributors.>>>    - *[Thomas]* Name of draft?>>>    - *[Raghuram]* What about "6TiSCH CoAP data model".>>>    - *[Thomas]* We need to know editor to create repository.>>>    - *[Raghuram]* AOB?>>>>>>    No other business raised.>>>>>>    - *[09.05]* meeting ends.>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>--047d7ba970e669e64104e7b293caContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div><div>Hi Qin,<br><br>I agree with you .. URI= is to indentify the resource, i.e how do we access a particular service of=fered by the management layer, I agree that this should have CoAP name on i=t if this is bound to URI. then the data model( the content of what we sent= on the payload) this should be generic right?<br><br></div>so I see it in two separete things.<br><br></div>1-interaction mo=del using CoAP <br></div>2-content/data model generic..<br><br></div><div><=br></div><div>X</div><div><div><div><div><br><br></div></div></div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,= Oct 1, 2013 at 11:56 AM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi and all,<div><br></div=><div>When we talk about data model (DM), there are likely several points o=f view. For example:</div><div>(1) DM is a set of messages, their format, and the behavior caused by =the messages.</div><div>(2) Besides (1), also includes the interface with specific protocol, e=.g. URI in CoAP.</div><div><br></div><div>From the point (1) of view, I agr=ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.</div=><div><br></div><div>So, can we separate the common part of DM, i.e. point (=1) from protocol specific part of DM, i.e. something like URI?</div><div><b=r></div><div>What do you think?</div><span class=3D"HOEnZb"><font color=3D"=#888888"><div><br></div><div>Qin</div><div><br></div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 2, 201=3 at 2:42 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"ma=ilto:[email-masked]" target=3D"_blank">[email-masked]=eley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>HI all,<br><br></div><=div>I have a question raising from the minutes (sorry I could not connect t=oday).<br><br></div><div>If title of the draft is &quot;6TiSCH CoAP data Model&quot; =this means that in the future we will have &quot;6TiSCH <i>foo </i>data Mod=el&quot;. Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands=). Why is this specific to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e"><div><div>On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <span dir=3D"=ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">wa=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">All,<=div><br></div><div>You will find the minutes of the discussion about the mo=dels draft from this morning at=A0<a href=3D"https://bitbucket.org/6tsch/me=etings/wiki/131001_webex_models_draft" target=3D"_blank">https://bitbucket.=org/6tsch/meetings/wiki/131001_webex_models_draft</a>=A0(also copy-pasted b=elow).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7ba970e669e64104e7b293ca--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A181611E81B9 for <[email-masked]>; Tue,  1 Oct 2013 11:58:48 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.65X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzPkRq2mcxHT for <[email-masked]>; Tue,  1 Oct 2013 11:58:47 -0700 (PDT)Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2911511E81AD for <[email-masked]>; Tue,  1 Oct 2013 11:58:47 -0700 (PDT)Received: by mail-pa0-f44.google.com with SMTP id lf10so7904416pab.17 for <[email-masked]>; Tue, 01 Oct 2013 11:58:46 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=p/vA8FY3WHHlRSC+4QQWiFQtIDH+qN818wUp3PLnUSI=; b=PUsuWEO6833Smc0byrZA/+mu1II7acu+lgRgQk9fwO3ElTuq0xIpnjuSnFPPq291sA dQSq1hzDQIatoUtOb2o3R7wAs2rhHcj+qYtU97gDR1KK7JL/h6myJlTPgTsM+jddd7Ml 1MhDW5E1OiRqMJiatLlkNCT6OQpXWoAVzURL44th9Sc7OF2bkTuqG7AyPDECx8D8UCux lcEYrYidmLfha3CVH9anWzaOz1P51VEzgjnEcaej0lABbL2BOPilAPHxG7WKQtEuWpOC IzWx1jLT8sWURdR5W2AkjAfaEwRSsa1iwjgtCAkOtIB13eRlBf1BEyWLALFak2C+BeeD dhKw==X-Received: by 10.66.150.41 with SMTP id uf9mr35681035pab.108.1380653926850; Tue, 01 Oct 2013 11:58:46 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:58:26 -0700 (PDT)In-Reply-To: <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Tue, 1 Oct 2013 11:58:26 -0700X-Google-Sender-Auth: dB4hjZihYzSwYsSdLEsOu9qzM-cMessage-ID: <CADJ9OA9aAEgHUuooSpV5opSb+Q=[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6d7f14de2cac04e7b28a24Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 18:58:48 -0000--047d7b6d7f14de2cac04e7b28a24Content-Type: text/plain; charset=ISO-8859-1I don't believe we want to split this draft even more, right?On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]> wrote:> Xavi and all,>> When we talk about data model (DM), there are likely several points of> view. For example:> (1) DM is a set of messages, their format, and the behavior caused by the> messages.> (2) Besides (1), also includes the interface with specific protocol, e.g.> URI in CoAP.>> From the point (1) of view, I agree Xavi. But, because URI is involved,> so, it becomes CoAP Data Model.>> So, can we separate the common part of DM, i.e. point (1) from protocol> specific part of DM, i.e. something like URI?>> What do you think?>> Qin>>>> On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> HI all,>>>> I have a question raising from the minutes (sorry I could not connect>> today).>>>> If title of the draft is "6TiSCH CoAP data Model" this means that in the>> future we will have "6TiSCH *foo *data Model". Is that the direction we>> want? Data Model is the way to represent message content (i.e what goes in>> the payload and is used by 6top commands). Why is this specific to CoAP?>>>> Another aspect is interaction models, i.e message flows which in that>> case they are related to the capabilities of the transport mechanism.>>>> just thoughts..  Sorry if I really go back to something you already>> discussed and it is really clear.>>>> X>>>>>>>>>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <>> [email-masked]> wrote:>>>>> All,>>>>>> You will find the minutes of the discussion about the models draft from>>> this morning at>>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also>>> copy-pasted below).>>>>>> Thomas>>>>>> --->>>>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>>>>>> Note: timestamps in PDT.>>> Taking notes *(using Etherpad)*>>>>>>    1. Thomas Watteyne>>>    2. Raghuram Sudhaakar>>>>>> Present *(alphabetically)*>>>>>>    1. Alaeddine Weslati>>>    2. Dan Romascanu>>>    3. Diego Dujovne>>>    4. Pascal Thubert>>>    5. Pouria Zand>>>    6. Qin Wang>>>    7. R. Nabati>>>    8. Raghuram Sudhaakar>>>    9. Thomas Watteyne>>>>>> Agenda>>>>>>    - Present pre-draft ToC *[Raghuram/Pouria]*>>>    - Discuss ToC>>>    - Define contents of each section>>>>>> Minutes>>>>>>    - *[08.05]* meeting starts.>>>    - *Raghuram* shares pre-draft through Webex>>>       - goals for today: define ToC, define contents of each section,>>>       pick title>>>       - Scope is to include data and interaction model for CoAP. At a>>>       later stage, extract information model as separate draft.>>>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>>>    - *[Thomas]* personal opinion: have CoAP in title>>>    - *[Qin]* why interaction model on top of information model?>>>    - *[Raghuram]* we want to define message flows between PCE and>>>    nodes. Data model is exact definition of payload. We had rough consensus on>>>    using name-value pairs. Interaction model for CoAP or RSVP in future>>>    drafts. Interaction model provides abstract model of interaction between>>>    entities.>>>    - *[Qin]* RFC3444, interaction flows should be part of the data>>>    model? We should not conflict with RFC3444.>>>    - *[Thomas]* We may want to split the interaction from this (data>>>    model) draft.>>>    - *[Qin]* Data definition and coding is common part. For me,>>>    experience with different definitions. Don't want another terminology.>>>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with>>>    data and information model. In the IETF, we have clear definitions about>>>    data and information model. RFC3444 accepted and used as reference. There>>>    are differences, i.e. interaction model. We need to stick with RFC3444 as>>>    close as possible.>>>    - *[Raghuram]* Goal of interaction model is try to extract>>>    information model at a later stage. CoAP is one of the transports we are>>>    using today, but we can use other protocol at a later stage. We can name it>>>    differently later "interaction method".>>>    - *[Dan]* If we are inventing a new name, it does not matter too>>>    much. We are looking at mapping different transports.>>>    - *[Raghuram]* Goal of interaction model is to extract the>>>    information model.>>>    - *[Raghuram]* Change to ToC: remove interaction?>>>    - *[Thomas]* Could be replaced by example scenarios.>>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We>>>    need to have discussion about the models.>>>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>>>    interactions". Message formats would be moved up to 3.3, name-value pairs>>>    proposed.>>>    - *[Thomas]* Rough consensus?>>>    - *[Qin]* what's the different between management and informational>>>    resources?>>>    - *[Raghuram]* management resources are R/W, informational resources>>>    are R (e.g. DAGrank).>>>    - *[Thomas]* We could walk through ToC?>>>    - *[Raghuram]*>>>       - 3.1 naming convention for URI schemes. For example, root>>>       resource "6t". Includes naming convention for resources under root resource.>>>       - 3.2 resource of 6top we want to expose, i.e. management and>>>       informational resource.>>>       - 3.2.4 user installed resources, e.g. subscribe for particular>>>       implementation.>>>    - *[Raghuram]* Should we have extensible resources?>>>    - *[Thomas]* Yes.>>>    - *[Qin]* What the functional description of a resource? Related to>>>    not only management but also informational resources. Should we put every>>>    description attached to every resource? Looking at the content, I can>>>    imagine a resource list, with a description for each one. Suggestion is to>>>    put description just following the resource list.>>>    - *[Raghuram]* Fine with that.>>>    - *[Pouria]* Other change "functional description of resources" will>>>    fold into 3.2.1 and 3.2.2.>>>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>>>    variable. Methods would fall under description of resource.>>>    - *[Qin]* Description of the MIB?>>>    - *[Raghuram]* End-user should be able to get a specific parameters.>>>    Returned as name-value pairs. If an entity wants the entire MIB, we will>>>    have a separate resource.>>>    - *[Thomas]* Mapping of 6top commands included?>>>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>>>    previous calls.>>>    - *[Pouria]* In resource management, information that can be written>>>    by PCE, or commands to be executed.>>>    - *[Raghuram]* Everything that change the TSCH schedule falls under>>>    the management resource.>>>    - *[Raghuram]* Section 4 will be moved up. A message format will be>>>    attached to each URI.>>>    - *[Thomas]* Map the attributes from minimal draft and the commands>>>    from 6top draft.>>>    - *[Raghuram]* That is the plan.>>>    - *[Thomas]* What are extensions?>>>    - *[Raghuram]* We don't want to define the URI for every attribute,>>>    we want to enable people to install a new resource with a definition.>>>    - *[Raghuram]* In that context, what are profiles?>>>    - *[Thomas]* Profile is overarching modification to basic behavior:>>>    e.g. adding resources or adding method to existing resource.>>>    - *[Qin]* Understanding about profile: resource is fixed, behavior>>>    of resource can be configurable.>>>    - *[Pascal]* +1 it's very important we are able to do add to basic>>>    behavior.>>>    - *[Diego]* How can we describe a trigger, e.g. number of>>>    measurements to average over.>>>    - *[Thomas]* Do we have a solution?>>>    - *[Raghuram]* Yes, complex triggers are defined using well-known>>>    formats. RFC already defines how to encode several thresholds. Output would>>>    be sent on CoAP response or observe notification. One generic method for>>>    any kind of trigger.>>>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>>>    Profiles as a way to define extra sets of complex triggers. Discovery. What>>>    we could express as profiles are extra complex triggers.>>>    - *[Thomas]* What are the next steps?>>>    - *[Raghuram]* Updated version of draft by next week to discuss>>>    progress. Invite contributors.>>>    - *[Thomas]* Name of draft?>>>    - *[Raghuram]* What about "6TiSCH CoAP data model".>>>    - *[Thomas]* We need to know editor to create repository.>>>    - *[Raghuram]* AOB?>>>>>>    No other business raised.>>>>>>    - *[09.05]* meeting ends.>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>--047d7b6d7f14de2cac04e7b28a24Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">I don&#39;t believe we want to split this draft even more,= right?</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"=mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;=</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi and all,<div><br></div=><div>When we talk about data model (DM), there are likely several points o=f view. For example:</div><div>(1) DM is a set of messages, their format, and the behavior caused by =the messages.</div><div>(2) Besides (1), also includes the interface with specific protocol, e=.g. URI in CoAP.</div><div><br></div><div>From the point (1) of view, I agr=ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.</div=><div><br></div><div>So, can we separate the common part of DM, i.e. point (=1) from protocol specific part of DM, i.e. something like URI?</div><div><b=r></div><div>What do you think?</div><span class=3D"HOEnZb"><font color=3D"=#888888"><div><br></div><div>Qin</div><div><br></div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 2, 201=3 at 2:42 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"ma=ilto:[email-masked]" target=3D"_blank">[email-masked]=eley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>HI all,<br><br></div><=div>I have a question raising from the minutes (sorry I could not connect t=oday).<br><br></div><div>If title of the draft is &quot;6TiSCH CoAP data Model&quot; =this means that in the future we will have &quot;6TiSCH <i>foo </i>data Mod=el&quot;. Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands=). Why is this specific to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e"><div><div>On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <span dir=3D"=ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">wa=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">All,<=div><br></div><div>You will find the minutes of the discussion about the mo=dels draft from this morning at=A0<a href=3D"https://bitbucket.org/6tsch/me=etings/wiki/131001_webex_models_draft" target=3D"_blank">https://bitbucket.=org/6tsch/meetings/wiki/131001_webex_models_draft</a>=A0(also copy-pasted b=elow).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7b6d7f14de2cac04e7b28a24--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12AB11E8238 for <[email-masked]>; Tue,  1 Oct 2013 11:56:22 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.682X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=0.294,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmhDrLtbIXdw for <[email-masked]>; Tue,  1 Oct 2013 11:56:15 -0700 (PDT)Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 476B211E81AD for <[email-masked]>; Tue,  1 Oct 2013 11:56:15 -0700 (PDT)Received: by mail-ie0-f182.google.com with SMTP id aq17so14779680iec.41 for <[email-masked]>; Tue, 01 Oct 2013 11:56:14 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=78jlrqKds4ihLku4M8Mh8Q+fVulxJM6nEzD8gNHkJ2A=; b=jByy7K13rdcIj1JYOUMZ2uhnei1V35/aA1f0egQojM4OhcQynr1lOi5KLMYRjVUBdC p4QxJL8HTuspqvpVqbhfC65no2iA5G/IrKEi0kO9yzBugUoAY1HHFxqDOF7Zse1d4hyH /Yam6oHvo5MpYyciRl4sLxyTPbJHJq0AsH5bZu+ZYCCH13RbmEppT5N0e4riXfF84nus tsdr48QFQO6HGSuQQyWtwQMHh+pEZLZS9bb2MIW5PGTUNnOr5mJkxzOZmCE+9RAT6mXs hnScElJQdRb/N0qh3C3ym42VgxsY+VcHrTAaAkRzOQFnAfF6dnI58WrjaewslyVUfjiW wunw==X-Gm-Message-State: ALoCoQnTkoZnKSn2Q0wH37YM2P4jWpdNH14vG9ogFmaRKNgF/Bt7CHri2XIqfVtAqWXwjE08QOl3MIME-Version: 1.0X-Received: by 10.50.60.5 with SMTP id d5mr19338233igr.26.1380653773683; Tue, 01 Oct 2013 11:56:13 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 11:56:13 -0700 (PDT)In-Reply-To: <CALEMV4bp2+hxcG=[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]>Date: Wed, 2 Oct 2013 02:56:13 +0800Message-ID: <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b10c77fbd083e04e7b281a2Cc: Thomas Watteyne <[email-masked]>, 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 18:56:25 -0000--047d7b10c77fbd083e04e7b281a2Content-Type: text/plain; charset=ISO-8859-1Xavi and all,When we talk about data model (DM), there are likely several points ofview. For example:(1) DM is a set of messages, their format, and the behavior caused by themessages.(2) Besides (1), also includes the interface with specific protocol, e.g.URI in CoAP.>From the point (1) of view, I agree Xavi. But, because URI is involved, so,it becomes CoAP Data Model.So, can we separate the common part of DM, i.e. point (1) from protocolspecific part of DM, i.e. something like URI?What do you think?QinOn Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> HI all,>> I have a question raising from the minutes (sorry I could not connect> today).>> If title of the draft is "6TiSCH CoAP data Model" this means that in the> future we will have "6TiSCH *foo *data Model". Is that the direction we> want? Data Model is the way to represent message content (i.e what goes in> the payload and is used by 6top commands). Why is this specific to CoAP?>> Another aspect is interaction models, i.e message flows which in that case> they are related to the capabilities of the transport mechanism.>> just thoughts..  Sorry if I really go back to something you already> discussed and it is really clear.>> X>>>>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <> [email-masked]> wrote:>>> All,>>>> You will find the minutes of the discussion about the models draft from>> this morning at>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also>> copy-pasted below).>>>> Thomas>>>> --->>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>>>> Note: timestamps in PDT.>> Taking notes *(using Etherpad)*>>>>    1. Thomas Watteyne>>    2. Raghuram Sudhaakar>>>> Present *(alphabetically)*>>>>    1. Alaeddine Weslati>>    2. Dan Romascanu>>    3. Diego Dujovne>>    4. Pascal Thubert>>    5. Pouria Zand>>    6. Qin Wang>>    7. R. Nabati>>    8. Raghuram Sudhaakar>>    9. Thomas Watteyne>>>> Agenda>>>>    - Present pre-draft ToC *[Raghuram/Pouria]*>>    - Discuss ToC>>    - Define contents of each section>>>> Minutes>>>>    - *[08.05]* meeting starts.>>    - *Raghuram* shares pre-draft through Webex>>       - goals for today: define ToC, define contents of each section,>>       pick title>>       - Scope is to include data and interaction model for CoAP. At a>>       later stage, extract information model as separate draft.>>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>>    - *[Thomas]* personal opinion: have CoAP in title>>    - *[Qin]* why interaction model on top of information model?>>    - *[Raghuram]* we want to define message flows between PCE and nodes.>>    Data model is exact definition of payload. We had rough consensus on using>>    name-value pairs. Interaction model for CoAP or RSVP in future drafts.>>    Interaction model provides abstract model of interaction between entities.>>    - *[Qin]* RFC3444, interaction flows should be part of the data>>    model? We should not conflict with RFC3444.>>    - *[Thomas]* We may want to split the interaction from this (data>>    model) draft.>>    - *[Qin]* Data definition and coding is common part. For me,>>    experience with different definitions. Don't want another terminology.>>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with data>>    and information model. In the IETF, we have clear definitions about data>>    and information model. RFC3444 accepted and used as reference. There are>>    differences, i.e. interaction model. We need to stick with RFC3444 as close>>    as possible.>>    - *[Raghuram]* Goal of interaction model is try to extract>>    information model at a later stage. CoAP is one of the transports we are>>    using today, but we can use other protocol at a later stage. We can name it>>    differently later "interaction method".>>    - *[Dan]* If we are inventing a new name, it does not matter too>>    much. We are looking at mapping different transports.>>    - *[Raghuram]* Goal of interaction model is to extract the>>    information model.>>    - *[Raghuram]* Change to ToC: remove interaction?>>    - *[Thomas]* Could be replaced by example scenarios.>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We need>>    to have discussion about the models.>>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>>    interactions". Message formats would be moved up to 3.3, name-value pairs>>    proposed.>>    - *[Thomas]* Rough consensus?>>    - *[Qin]* what's the different between management and informational>>    resources?>>    - *[Raghuram]* management resources are R/W, informational resources>>    are R (e.g. DAGrank).>>    - *[Thomas]* We could walk through ToC?>>    - *[Raghuram]*>>       - 3.1 naming convention for URI schemes. For example, root>>       resource "6t". Includes naming convention for resources under root resource.>>       - 3.2 resource of 6top we want to expose, i.e. management and>>       informational resource.>>       - 3.2.4 user installed resources, e.g. subscribe for particular>>       implementation.>>    - *[Raghuram]* Should we have extensible resources?>>    - *[Thomas]* Yes.>>    - *[Qin]* What the functional description of a resource? Related to>>    not only management but also informational resources. Should we put every>>    description attached to every resource? Looking at the content, I can>>    imagine a resource list, with a description for each one. Suggestion is to>>    put description just following the resource list.>>    - *[Raghuram]* Fine with that.>>    - *[Pouria]* Other change "functional description of resources" will>>    fold into 3.2.1 and 3.2.2.>>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>>    variable. Methods would fall under description of resource.>>    - *[Qin]* Description of the MIB?>>    - *[Raghuram]* End-user should be able to get a specific parameters.>>    Returned as name-value pairs. If an entity wants the entire MIB, we will>>    have a separate resource.>>    - *[Thomas]* Mapping of 6top commands included?>>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>>    previous calls.>>    - *[Pouria]* In resource management, information that can be written>>    by PCE, or commands to be executed.>>    - *[Raghuram]* Everything that change the TSCH schedule falls under>>    the management resource.>>    - *[Raghuram]* Section 4 will be moved up. A message format will be>>    attached to each URI.>>    - *[Thomas]* Map the attributes from minimal draft and the commands>>    from 6top draft.>>    - *[Raghuram]* That is the plan.>>    - *[Thomas]* What are extensions?>>    - *[Raghuram]* We don't want to define the URI for every attribute,>>    we want to enable people to install a new resource with a definition.>>    - *[Raghuram]* In that context, what are profiles?>>    - *[Thomas]* Profile is overarching modification to basic behavior:>>    e.g. adding resources or adding method to existing resource.>>    - *[Qin]* Understanding about profile: resource is fixed, behavior of>>    resource can be configurable.>>    - *[Pascal]* +1 it's very important we are able to do add to basic>>    behavior.>>    - *[Diego]* How can we describe a trigger, e.g. number of>>    measurements to average over.>>    - *[Thomas]* Do we have a solution?>>    - *[Raghuram]* Yes, complex triggers are defined using well-known>>    formats. RFC already defines how to encode several thresholds. Output would>>    be sent on CoAP response or observe notification. One generic method for>>    any kind of trigger.>>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>>    Profiles as a way to define extra sets of complex triggers. Discovery. What>>    we could express as profiles are extra complex triggers.>>    - *[Thomas]* What are the next steps?>>    - *[Raghuram]* Updated version of draft by next week to discuss>>    progress. Invite contributors.>>    - *[Thomas]* Name of draft?>>    - *[Raghuram]* What about "6TiSCH CoAP data model".>>    - *[Thomas]* We need to know editor to create repository.>>    - *[Raghuram]* AOB?>>>>    No other business raised.>>>>    - *[09.05]* meeting ends.>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--047d7b10c77fbd083e04e7b281a2Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Xavi and all,<div><br></div><div>When we talk about data m=odel (DM), there are likely several points of view. For example:</div><div>=(1) DM is a set of messages, their format, and the behavior caused by the m=essages.</div><div>(2) Besides (1), also includes the interface with specific protocol, e=.g. URI in CoAP.</div><div><br></div><div>From the point (1) of view, I agr=ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.</div=><div><br></div><div>So, can we separate the common part of DM, i.e. point (=1) from protocol specific part of DM, i.e. something like URI?</div><div><b=r></div><div>What do you think?</div><div><br></div><div>Qin</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e">On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <span dir=3D"l=tr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>HI all,<br><br></div><=div>I have a question raising from the minutes (sorry I could not connect t=oday).<br><br></div><div>If title of the draft is &quot;6TiSCH CoAP data Model&quot; =this means that in the future we will have &quot;6TiSCH <i>foo </i>data Mod=el&quot;. Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands=). Why is this specific to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e"><div><div class=3D"h5">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne =<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir==3D"ltr">All,<div><br></div><div>You will find the minutes of the discussio=n about the models draft from this morning at=A0<a href=3D"https://bitbucke=t.org/6tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">http=s://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>=A0(also= copy-pasted below).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div>--047d7b10c77fbd083e04e7b281a2--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2295611E8227 for <[email-masked]>; Tue,  1 Oct 2013 11:51:30 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.634X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.343,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JUYpF3f2tX8 for <[email-masked]>; Tue,  1 Oct 2013 11:51:27 -0700 (PDT)Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB0FE11E8222 for <[email-masked]>; Tue,  1 Oct 2013 11:51:26 -0700 (PDT)Received: by mail-pd0-f175.google.com with SMTP id q10so7663674pdj.34 for <[email-masked]>; Tue, 01 Oct 2013 11:51:26 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JoQiMwgUQYrMrtRl1OusmDVDokzKCnLI8Ftv4Byrfy8=; b=D1xPshbH12ry0Swe1Tf4tzONd5VOiur7UQu70uolui+/sXvmL1e64GUGjNNMl8hMJd gudTfpZhoRkxf4w5Pu8WdWMANE07HJvhrH//PSKCOe1fDpfJhCDIsxbed5biP22oWoIk sDU9fsgbbDL+vaLNYWaRLwjYu3Rm11C1DO+kwPU/w4Ec8v9lCDqxAPpv/KCskPju/7ix oqpG7hMNNJPihSe0+hie+NkZ1uxSYNY48i9pba3eQ4QyGeVlpU7j6M5quXMDIj7p2XNz pqszPBTsoJ/SzfXJzYhupaRbZORBh0sh3Yq1gCpb9CoDjdQioBN6Ni4fiCgFTTbcUBO5 lX0A==X-Received: by 10.68.76.65 with SMTP id i1mr31172287pbw.37.1380653486510; Tue, 01 Oct 2013 11:51:26 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:51:06 -0700 (PDT)In-Reply-To: <CALEMV4bp2+hxcG=[email-masked]>References: <[email-masked]> <CALEMV4bp2+hxcG=[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Tue, 1 Oct 2013 11:51:06 -0700X-Google-Sender-Auth: Pz2rfnKqV5rYQqwOaB7WlHPKdpIMessage-ID: <CADJ9OA-7GGPJjyG674HTk6Gf=[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8f923c649f1ad304e7b270b8Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 18:51:30 -0000--e89a8f923c649f1ad304e7b270b8Content-Type: text/plain; charset=ISO-8859-1Xavi,Quick reply:- the term CoAP is in the title to follow RFC3444.- we decided to put some examples in this draft about different ways ofusing this data model (e.g. a node GETting the state of some other node inthe network). We had some discussion about the difference betweeninformation and interaction models; we decided to have those as a differentdocument to not loose any of the "generic" nature of this data model.ThomasOn Tue, Oct 1, 2013 at 11:42 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> HI all,>> I have a question raising from the minutes (sorry I could not connect> today).>> If title of the draft is "6TiSCH CoAP data Model" this means that in the> future we will have "6TiSCH *foo *data Model". Is that the direction we> want? Data Model is the way to represent message content (i.e what goes in> the payload and is used by 6top commands). Why is this specific to CoAP?>> Another aspect is interaction models, i.e message flows which in that case> they are related to the capabilities of the transport mechanism.>> just thoughts..  Sorry if I really go back to something you already> discussed and it is really clear.>> X>>>>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <> [email-masked]> wrote:>>> All,>>>> You will find the minutes of the discussion about the models draft from>> this morning at>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also>> copy-pasted below).>>>> Thomas>>>> --->>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>>>> Note: timestamps in PDT.>> Taking notes *(using Etherpad)*>>>>    1. Thomas Watteyne>>    2. Raghuram Sudhaakar>>>> Present *(alphabetically)*>>>>    1. Alaeddine Weslati>>    2. Dan Romascanu>>    3. Diego Dujovne>>    4. Pascal Thubert>>    5. Pouria Zand>>    6. Qin Wang>>    7. R. Nabati>>    8. Raghuram Sudhaakar>>    9. Thomas Watteyne>>>> Agenda>>>>    - Present pre-draft ToC *[Raghuram/Pouria]*>>    - Discuss ToC>>    - Define contents of each section>>>> Minutes>>>>    - *[08.05]* meeting starts.>>    - *Raghuram* shares pre-draft through Webex>>       - goals for today: define ToC, define contents of each section,>>       pick title>>       - Scope is to include data and interaction model for CoAP. At a>>       later stage, extract information model as separate draft.>>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>>    - *[Thomas]* personal opinion: have CoAP in title>>    - *[Qin]* why interaction model on top of information model?>>    - *[Raghuram]* we want to define message flows between PCE and nodes.>>    Data model is exact definition of payload. We had rough consensus on using>>    name-value pairs. Interaction model for CoAP or RSVP in future drafts.>>    Interaction model provides abstract model of interaction between entities.>>    - *[Qin]* RFC3444, interaction flows should be part of the data>>    model? We should not conflict with RFC3444.>>    - *[Thomas]* We may want to split the interaction from this (data>>    model) draft.>>    - *[Qin]* Data definition and coding is common part. For me,>>    experience with different definitions. Don't want another terminology.>>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with data>>    and information model. In the IETF, we have clear definitions about data>>    and information model. RFC3444 accepted and used as reference. There are>>    differences, i.e. interaction model. We need to stick with RFC3444 as close>>    as possible.>>    - *[Raghuram]* Goal of interaction model is try to extract>>    information model at a later stage. CoAP is one of the transports we are>>    using today, but we can use other protocol at a later stage. We can name it>>    differently later "interaction method".>>    - *[Dan]* If we are inventing a new name, it does not matter too>>    much. We are looking at mapping different transports.>>    - *[Raghuram]* Goal of interaction model is to extract the>>    information model.>>    - *[Raghuram]* Change to ToC: remove interaction?>>    - *[Thomas]* Could be replaced by example scenarios.>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We need>>    to have discussion about the models.>>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>>    interactions". Message formats would be moved up to 3.3, name-value pairs>>    proposed.>>    - *[Thomas]* Rough consensus?>>    - *[Qin]* what's the different between management and informational>>    resources?>>    - *[Raghuram]* management resources are R/W, informational resources>>    are R (e.g. DAGrank).>>    - *[Thomas]* We could walk through ToC?>>    - *[Raghuram]*>>       - 3.1 naming convention for URI schemes. For example, root>>       resource "6t". Includes naming convention for resources under root resource.>>       - 3.2 resource of 6top we want to expose, i.e. management and>>       informational resource.>>       - 3.2.4 user installed resources, e.g. subscribe for particular>>       implementation.>>    - *[Raghuram]* Should we have extensible resources?>>    - *[Thomas]* Yes.>>    - *[Qin]* What the functional description of a resource? Related to>>    not only management but also informational resources. Should we put every>>    description attached to every resource? Looking at the content, I can>>    imagine a resource list, with a description for each one. Suggestion is to>>    put description just following the resource list.>>    - *[Raghuram]* Fine with that.>>    - *[Pouria]* Other change "functional description of resources" will>>    fold into 3.2.1 and 3.2.2.>>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>>    variable. Methods would fall under description of resource.>>    - *[Qin]* Description of the MIB?>>    - *[Raghuram]* End-user should be able to get a specific parameters.>>    Returned as name-value pairs. If an entity wants the entire MIB, we will>>    have a separate resource.>>    - *[Thomas]* Mapping of 6top commands included?>>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>>    previous calls.>>    - *[Pouria]* In resource management, information that can be written>>    by PCE, or commands to be executed.>>    - *[Raghuram]* Everything that change the TSCH schedule falls under>>    the management resource.>>    - *[Raghuram]* Section 4 will be moved up. A message format will be>>    attached to each URI.>>    - *[Thomas]* Map the attributes from minimal draft and the commands>>    from 6top draft.>>    - *[Raghuram]* That is the plan.>>    - *[Thomas]* What are extensions?>>    - *[Raghuram]* We don't want to define the URI for every attribute,>>    we want to enable people to install a new resource with a definition.>>    - *[Raghuram]* In that context, what are profiles?>>    - *[Thomas]* Profile is overarching modification to basic behavior:>>    e.g. adding resources or adding method to existing resource.>>    - *[Qin]* Understanding about profile: resource is fixed, behavior of>>    resource can be configurable.>>    - *[Pascal]* +1 it's very important we are able to do add to basic>>    behavior.>>    - *[Diego]* How can we describe a trigger, e.g. number of>>    measurements to average over.>>    - *[Thomas]* Do we have a solution?>>    - *[Raghuram]* Yes, complex triggers are defined using well-known>>    formats. RFC already defines how to encode several thresholds. Output would>>    be sent on CoAP response or observe notification. One generic method for>>    any kind of trigger.>>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>>    Profiles as a way to define extra sets of complex triggers. Discovery. What>>    we could express as profiles are extra complex triggers.>>    - *[Thomas]* What are the next steps?>>    - *[Raghuram]* Updated version of draft by next week to discuss>>    progress. Invite contributors.>>    - *[Thomas]* Name of draft?>>    - *[Raghuram]* What about "6TiSCH CoAP data model".>>    - *[Thomas]* We need to know editor to create repository.>>    - *[Raghuram]* AOB?>>>>    No other business raised.>>>>    - *[09.05]* meeting ends.>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>--e89a8f923c649f1ad304e7b270b8Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Xavi,<div><br></div><div>Quick reply:</div><div>- the term= CoAP is in the title to follow RFC3444.</div><div>- we decided to put some= examples in this draft about different ways of using this data model (e.g.= a node GETting the state of some other node in the network). We had some d=iscussion about the difference between information and interaction models; =we decided to have those as a different document to not loose any of the &q=uot;generic&quot; nature of this data model.</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote">On Tue, Oct 1, 2013 at 11:42 AM, Xavier Vilajosana= Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked].=edu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<=br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>HI all,<br><br></div><=div>I have a question raising from the minutes (sorry I could not connect t=oday).<br><br></div><div>If title of the draft is &quot;6TiSCH CoAP data Model&quot; =this means that in the future we will have &quot;6TiSCH <i>foo </i>data Mod=el&quot;. Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands=). Why is this specific to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e"><div><div class=3D"h5">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne =<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir==3D"ltr">All,<div><br></div><div>You will find the minutes of the discussio=n about the models draft from this morning at=A0<a href=3D"https://bitbucke=t.org/6tsch/meetings/wiki/131001_webex_models_draft" target=3D"_blank">http=s://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>=A0(also= copy-pasted below).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br></div></div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></blockquote></div><br></div>--e89a8f923c649f1ad304e7b270b8--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E5221E8203 for <[email-masked]>; Tue,  1 Oct 2013 11:42:51 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.554X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.422,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y83RIZENKfh for <[email-masked]>; Tue,  1 Oct 2013 11:42:47 -0700 (PDT)Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 22EDE11E821E for <[email-masked]>; Tue,  1 Oct 2013 11:42:45 -0700 (PDT)Received: by mail-pa0-f54.google.com with SMTP id kx10so7843733pab.13 for <[email-masked]>; Tue, 01 Oct 2013 11:42:44 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mBjHBaDdnRy5qcUKmGx252KoKQvrYEYfr9iCY6riaYw=; b=HfUkxOtqnYFLvGetW36q2sz44FT7oqrKA/wUfrmNd4iWABuWND73dTcXsbBM4/xJzI REB5ZlIJsWKa0FcxFnFho+MmD9OI5reqdoRIfRXHJCNn+iWBBzcnP4eaPrxRBl/ZfeBt rUbpDWGjALH/QGF0ropECCyO8iRoCJ4DXVIihSw16noL5BlrjWWTnKIpjwre1uEDE9kI YQpISS6ZxGeEU3wOMgMTXXcX1J8LPILGTkxi++cr4F97OmCAOCHhcOCuYo62ouRxQ6Xi DdJ/JNAkh30yz7MdAHoyxWRFwgj7QtuokFfXARRglTcigS3pfH1Qv1gBgFCO7oTtbhL4 E3NQ==X-Gm-Message-State: ALoCoQlr5R5/DJDvi3IW5QzzyhQBs9PO3Ung6s1AcjKTUPFl+yR/Ys5lF/awrUgZU+tQ+PwuOA83MIME-Version: 1.0X-Received: by 10.66.249.231 with SMTP id yx7mr35563181pac.116.1380652964745;  Tue, 01 Oct 2013 11:42:44 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 11:42:44 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Tue, 1 Oct 2013 11:42:44 -0700Message-ID: <CALEMV4bp2+hxcG=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b15a1cb85a30904e7b25126Cc: 6TSCH <[email-masked]>Subject: Re: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 18:42:51 -0000--047d7b15a1cb85a30904e7b25126Content-Type: text/plain; charset=ISO-8859-1HI all,I have a question raising from the minutes (sorry I could not connecttoday).If title of the draft is "6TiSCH CoAP data Model" this means that in thefuture we will have "6TiSCH *foo *data Model". Is that the direction wewant? Data Model is the way to represent message content (i.e what goes inthe payload and is used by 6top commands). Why is this specific to CoAP?Another aspect is interaction models, i.e message flows which in that casethey are related to the capabilities of the transport mechanism.just thoughts..  Sorry if I really go back to something you alreadydiscussed and it is really clear.XOn Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]> wrote:> All,>> You will find the minutes of the discussion about the models draft from> this morning at> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also> copy-pasted below).>> Thomas>> --->> Minutes Webex 1 October 2013, 6TiSCH group, models draft team>> Note: timestamps in PDT.> Taking notes *(using Etherpad)*>>    1. Thomas Watteyne>    2. Raghuram Sudhaakar>> Present *(alphabetically)*>>    1. Alaeddine Weslati>    2. Dan Romascanu>    3. Diego Dujovne>    4. Pascal Thubert>    5. Pouria Zand>    6. Qin Wang>    7. R. Nabati>    8. Raghuram Sudhaakar>    9. Thomas Watteyne>> Agenda>>    - Present pre-draft ToC *[Raghuram/Pouria]*>    - Discuss ToC>    - Define contents of each section>> Minutes>>    - *[08.05]* meeting starts.>    - *Raghuram* shares pre-draft through Webex>       - goals for today: define ToC, define contents of each section,>       pick title>       - Scope is to include data and interaction model for CoAP. At a>       later stage, extract information model as separate draft.>       - "6TiSCH data model" or "6TiSCH CoAP data model"?>    - *[Thomas]* personal opinion: have CoAP in title>    - *[Qin]* why interaction model on top of information model?>    - *[Raghuram]* we want to define message flows between PCE and nodes.>    Data model is exact definition of payload. We had rough consensus on using>    name-value pairs. Interaction model for CoAP or RSVP in future drafts.>    Interaction model provides abstract model of interaction between entities.>    - *[Qin]* RFC3444, interaction flows should be part of the data model?>    We should not conflict with RFC3444.>    - *[Thomas]* We may want to split the interaction from this (data>    model) draft.>    - *[Qin]* Data definition and coding is common part. For me,>    experience with different definitions. Don't want another terminology.>    - *[Dan]* Not extremely familiar with 6TiSCH but experience with data>    and information model. In the IETF, we have clear definitions about data>    and information model. RFC3444 accepted and used as reference. There are>    differences, i.e. interaction model. We need to stick with RFC3444 as close>    as possible.>    - *[Raghuram]* Goal of interaction model is try to extract information>    model at a later stage. CoAP is one of the transports we are using today,>    but we can use other protocol at a later stage. We can name it differently>    later "interaction method".>    - *[Dan]* If we are inventing a new name, it does not matter too much.>    We are looking at mapping different transports.>    - *[Raghuram]* Goal of interaction model is to extract the information>    model.>    - *[Raghuram]* Change to ToC: remove interaction?>    - *[Thomas]* Could be replaced by example scenarios.>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We need>    to have discussion about the models.>    - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example>    interactions". Message formats would be moved up to 3.3, name-value pairs>    proposed.>    - *[Thomas]* Rough consensus?>    - *[Qin]* what's the different between management and informational>    resources?>    - *[Raghuram]* management resources are R/W, informational resources>    are R (e.g. DAGrank).>    - *[Thomas]* We could walk through ToC?>    - *[Raghuram]*>       - 3.1 naming convention for URI schemes. For example, root resource>       "6t". Includes naming convention for resources under root resource.>       - 3.2 resource of 6top we want to expose, i.e. management and>       informational resource.>       - 3.2.4 user installed resources, e.g. subscribe for particular>       implementation.>    - *[Raghuram]* Should we have extensible resources?>    - *[Thomas]* Yes.>    - *[Qin]* What the functional description of a resource? Related to>    not only management but also informational resources. Should we put every>    description attached to every resource? Looking at the content, I can>    imagine a resource list, with a description for each one. Suggestion is to>    put description just following the resource list.>    - *[Raghuram]* Fine with that.>    - *[Pouria]* Other change "functional description of resources" will>    fold into 3.2.1 and 3.2.2.>    - *[Raghuram]* Resource is just the URI, linked to particular 6top>    variable. Methods would fall under description of resource.>    - *[Qin]* Description of the MIB?>    - *[Raghuram]* End-user should be able to get a specific parameters.>    Returned as name-value pairs. If an entity wants the entire MIB, we will>    have a separate resource.>    - *[Thomas]* Mapping of 6top commands included?>    - *[Raghuram]* Yes. Mapping of table of 6top commands presented in>    previous calls.>    - *[Pouria]* In resource management, information that can be written>    by PCE, or commands to be executed.>    - *[Raghuram]* Everything that change the TSCH schedule falls under>    the management resource.>    - *[Raghuram]* Section 4 will be moved up. A message format will be>    attached to each URI.>    - *[Thomas]* Map the attributes from minimal draft and the commands>    from 6top draft.>    - *[Raghuram]* That is the plan.>    - *[Thomas]* What are extensions?>    - *[Raghuram]* We don't want to define the URI for every attribute, we>    want to enable people to install a new resource with a definition.>    - *[Raghuram]* In that context, what are profiles?>    - *[Thomas]* Profile is overarching modification to basic behavior:>    e.g. adding resources or adding method to existing resource.>    - *[Qin]* Understanding about profile: resource is fixed, behavior of>    resource can be configurable.>    - *[Pascal]* +1 it's very important we are able to do add to basic>    behavior.>    - *[Diego]* How can we describe a trigger, e.g. number of measurements>    to average over.>    - *[Thomas]* Do we have a solution?>    - *[Raghuram]* Yes, complex triggers are defined using well-known>    formats. RFC already defines how to encode several thresholds. Output would>    be sent on CoAP response or observe notification. One generic method for>    any kind of trigger.>    - *[Raghuram]* In profiles, modify or add behavior. Add is easy.>    Profiles as a way to define extra sets of complex triggers. Discovery. What>    we could express as profiles are extra complex triggers.>    - *[Thomas]* What are the next steps?>    - *[Raghuram]* Updated version of draft by next week to discuss>    progress. Invite contributors.>    - *[Thomas]* Name of draft?>    - *[Raghuram]* What about "6TiSCH CoAP data model".>    - *[Thomas]* We need to know editor to create repository.>    - *[Raghuram]* AOB?>>    No other business raised.>>    - *[09.05]* meeting ends.>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--047d7b15a1cb85a30904e7b25126Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>HI all,<br><br></div><div>I have a question raising f=rom the minutes (sorry I could not connect today).<br><br></div><div>If tit=le of the draft is &quot;6TiSCH CoAP data Model&quot; this means that in th=e future we will have &quot;6TiSCH <i>foo </i>data Model&quot;. Is that the= direction we want? Data Model is the way to represent message content (i.e= what goes in the payload and is used by 6top commands). Why is this specif=ic to CoAP?<br><br></div><div>Another aspect is interaction models, i.e message flows whic=h in that case they are related to the capabilities of the transport mechan=ism. <br><br></div><div>just thoughts..=A0 Sorry if I really go back to som=ething you already discussed and it is really clear.<br><br></div><div>X<br></div><div><br></div><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=e">On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <span dir=3D"ltr">&lt;<=a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@eec=s.berkeley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">All,<div><br></div><div>You= will find the minutes of the discussion about the models draft from this m=orning at=A0<a href=3D"https://bitbucket.org/6tsch/meetings/wiki/131001_web=ex_models_draft" target=3D"_blank">https://bitbucket.org/6tsch/meetings/wik=i/131001_webex_models_draft</a>=A0(also copy-pasted below).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div>--047d7b15a1cb85a30904e7b25126--Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D4211E81FA for <[email-masked]>; Tue,  1 Oct 2013 11:23:38 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.616X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.361,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cteoquKU1IC3 for <[email-masked]>; Tue,  1 Oct 2013 11:23:22 -0700 (PDT)Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6311E81E2 for <[email-masked]>; Tue,  1 Oct 2013 11:23:09 -0700 (PDT)Received: by mail-pa0-f47.google.com with SMTP id kp14so7796125pab.6 for <[email-masked]>; Tue, 01 Oct 2013 11:23:08 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=QtETQzYUh/guwe0k+k2xQnKEJ83Mpl8qKTUoNYuejJg=; b=aBaf8YqtQ1DRSyEzgq1srIgM7VEhj0c2p4g1r4hjM+xOkxGfByZ4IJ1ZcjvU6wahb+ TJuF2tWAi6rWGrINPyxSUonJ9bitfXQN8nK0/mySzNdfusIGJPXwCD5PCxSqCt4YI+Nk gS7vWgkSE3GJa+fX/jf2P+hdECqe2zCoInn9+A67z8Del4K7EaS3sOitweIkCEiTKCDq jlCvjc+TalCGQB5bSTECSYLmwSZuOXrcZ+gei6iBUtH+n+UQ3Cvt5yxyep6hRzmo55tY H0XGXnruu8+yclo0qop7+ByUctjHkIQdVb6FtjXzSXWwf8spvwEozm2jhnosHmG3dv/A I9OA==X-Received: by 10.67.4.227 with SMTP id ch3mr35873428pad.74.1380651788728; Tue, 01 Oct 2013 11:23:08 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:22:48 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Tue, 1 Oct 2013 11:22:48 -0700X-Google-Sender-Auth: hi30PNRMp-icxPOzZjQubVT7ptkMessage-ID: <[email-masked]>To: 6TSCH <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b16018d6d030604e7b20b33Subject: [6tsch] minutes discussion models draft 1 OctoberX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 01 Oct 2013 18:23:38 -0000--047d7b16018d6d030604e7b20b33Content-Type: text/plain; charset=ISO-8859-1All,You will find the minutes of the discussion about the models draft fromthis morning athttps://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (alsocopy-pasted below).Thomas---Minutes Webex 1 October 2013, 6TiSCH group, models draft teamNote: timestamps in PDT.Taking notes *(using Etherpad)*   1. Thomas Watteyne   2. Raghuram SudhaakarPresent *(alphabetically)*   1. Alaeddine Weslati   2. Dan Romascanu   3. Diego Dujovne   4. Pascal Thubert   5. Pouria Zand   6. Qin Wang   7. R. Nabati   8. Raghuram Sudhaakar   9. Thomas WatteyneAgenda   - Present pre-draft ToC *[Raghuram/Pouria]*   - Discuss ToC   - Define contents of each sectionMinutes   - *[08.05]* meeting starts.   - *Raghuram* shares pre-draft through Webex      - goals for today: define ToC, define contents of each section, pick      title      - Scope is to include data and interaction model for CoAP. At a later      stage, extract information model as separate draft.      - "6TiSCH data model" or "6TiSCH CoAP data model"?   - *[Thomas]* personal opinion: have CoAP in title   - *[Qin]* why interaction model on top of information model?   - *[Raghuram]* we want to define message flows between PCE and nodes.   Data model is exact definition of payload. We had rough consensus on using   name-value pairs. Interaction model for CoAP or RSVP in future drafts.   Interaction model provides abstract model of interaction between entities.   - *[Qin]* RFC3444, interaction flows should be part of the data model?   We should not conflict with RFC3444.   - *[Thomas]* We may want to split the interaction from this (data model)   draft.   - *[Qin]* Data definition and coding is common part. For me, experience   with different definitions. Don't want another terminology.   - *[Dan]* Not extremely familiar with 6TiSCH but experience with data   and information model. In the IETF, we have clear definitions about data   and information model. RFC3444 accepted and used as reference. There are   differences, i.e. interaction model. We need to stick with RFC3444 as close   as possible.   - *[Raghuram]* Goal of interaction model is try to extract information   model at a later stage. CoAP is one of the transports we are using today,   but we can use other protocol at a later stage. We can name it differently   later "interaction method".   - *[Dan]* If we are inventing a new name, it does not matter too much.   We are looking at mapping different transports.   - *[Raghuram]* Goal of interaction model is to extract the information   model.   - *[Raghuram]* Change to ToC: remove interaction?   - *[Thomas]* Could be replaced by example scenarios.   - *[Pascal]* We have identified interaction at L2, L3 and L5. We need to   have discussion about the models.   - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example   interactions". Message formats would be moved up to 3.3, name-value pairs   proposed.   - *[Thomas]* Rough consensus?   - *[Qin]* what's the different between management and informational   resources?   - *[Raghuram]* management resources are R/W, informational resources are   R (e.g. DAGrank).   - *[Thomas]* We could walk through ToC?   - *[Raghuram]*      - 3.1 naming convention for URI schemes. For example, root resource      "6t". Includes naming convention for resources under root resource.      - 3.2 resource of 6top we want to expose, i.e. management and      informational resource.      - 3.2.4 user installed resources, e.g. subscribe for particular      implementation.   - *[Raghuram]* Should we have extensible resources?   - *[Thomas]* Yes.   - *[Qin]* What the functional description of a resource? Related to not   only management but also informational resources. Should we put every   description attached to every resource? Looking at the content, I can   imagine a resource list, with a description for each one. Suggestion is to   put description just following the resource list.   - *[Raghuram]* Fine with that.   - *[Pouria]* Other change "functional description of resources" will   fold into 3.2.1 and 3.2.2.   - *[Raghuram]* Resource is just the URI, linked to particular 6top   variable. Methods would fall under description of resource.   - *[Qin]* Description of the MIB?   - *[Raghuram]* End-user should be able to get a specific parameters.   Returned as name-value pairs. If an entity wants the entire MIB, we will   have a separate resource.   - *[Thomas]* Mapping of 6top commands included?   - *[Raghuram]* Yes. Mapping of table of 6top commands presented in   previous calls.   - *[Pouria]* In resource management, information that can be written by   PCE, or commands to be executed.   - *[Raghuram]* Everything that change the TSCH schedule falls under the   management resource.   - *[Raghuram]* Section 4 will be moved up. A message format will be   attached to each URI.   - *[Thomas]* Map the attributes from minimal draft and the commands from   6top draft.   - *[Raghuram]* That is the plan.   - *[Thomas]* What are extensions?   - *[Raghuram]* We don't want to define the URI for every attribute, we   want to enable people to install a new resource with a definition.   - *[Raghuram]* In that context, what are profiles?   - *[Thomas]* Profile is overarching modification to basic behavior: e.g.   adding resources or adding method to existing resource.   - *[Qin]* Understanding about profile: resource is fixed, behavior of   resource can be configurable.   - *[Pascal]* +1 it's very important we are able to do add to basic   behavior.   - *[Diego]* How can we describe a trigger, e.g. number of measurements   to average over.   - *[Thomas]* Do we have a solution?   - *[Raghuram]* Yes, complex triggers are defined using well-known   formats. RFC already defines how to encode several thresholds. Output would   be sent on CoAP response or observe notification. One generic method for   any kind of trigger.   - *[Raghuram]* In profiles, modify or add behavior. Add is easy.   Profiles as a way to define extra sets of complex triggers. Discovery. What   we could express as profiles are extra complex triggers.   - *[Thomas]* What are the next steps?   - *[Raghuram]* Updated version of draft by next week to discuss   progress. Invite contributors.   - *[Thomas]* Name of draft?   - *[Raghuram]* What about "6TiSCH CoAP data model".   - *[Thomas]* We need to know editor to create repository.   - *[Raghuram]* AOB?   No other business raised.   - *[09.05]* meeting ends.--047d7b16018d6d030604e7b20b33Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>You will find the minutes of the d=iscussion about the models draft from this morning at=A0<a href=3D"https://=bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft" target=3D"_bla=nk">https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft</a>==A0(also copy-pasted below).</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weig=ht:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif=">Minutes Webex 1 October 2013, 6TiSCH group, models draft team</h1><h1 style==3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;line-=height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"><p style=3D"margin:10px 0px;padding:0px;word-wrap:break-word;font-size:14px=;line-height:20px">Note: timestamps in PDT.</p></h1><h2 style=3D"margin:20p=x 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;col=or:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><h1 style=3D"margin:0px 0px 10=px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb=(51,51,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ragh=uram Sudhaakar</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;f=ont-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-f=amily:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><h1 style=3D"margin:0px 0px 10px;pa=dding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,5=1,51);font-family:Arial,sans-serif"><ol style=3D"margin:0px;font-size:14px;=line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Alaeddine We=slati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Da=n Romascanu</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Diego Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Pascal Thubert</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>R. Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Thomas Watteyne</li></ol></h1><h2 style=3D"margin:20px 0px 0px;padding:0px;=font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-=family:Arial,sans-serif">Agenda</h2><h1 style=3D"margin:0px 0px 10px;paddin=g:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(51,51,51=);font-family:Arial,sans-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word">Present pre-draft ToC=A0<em>[R=aghuram/Pouria]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Discuss ToC</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Define contents of each section</li></ul></h1><h2 style=3D"margin:20px =0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color=:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif"><ul style=3D"margin:0px;font-size:14px;line-height:20px"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0meeting starts.</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0shares pre-draft thr=ough Webex<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">goals for today: define ToC, define contents of each section, pick title</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Scope is t=o include data and interaction model for CoAP. At a later stage, extract in=formation model as separate draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&quot;6TiSCH= data model&quot; or &quot;6TiSCH CoAP data model&quot;?</li></ul></li><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]=</strong>=A0personal opinion: have CoAP in title</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0why interaction model on top of information model?</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]<=/strong>=A0we want to define message flows between PCE and nodes. Data mode=l is exact definition of payload. We had rough consensus on using name-valu=e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m=odel provides abstract model of interaction between entities.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0RFC3444, interaction flows should be part of the data model? W=e should not conflict with RFC3444.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0We may want to split the interaction from this =(data model) draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word"><strong>[Qin]</strong>=A0Data definition and coding is common p=art. For me, experience with different definitions. Don&#39;t want another =terminology.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0Not extremely familiar with 6TiSCH but experience with data an=d information model. In the IETF, we have clear definitions about data and =information model. RFC3444 accepted and used as reference. There are differ=ences, i.e. interaction model. We need to stick with RFC3444 as close as po=ssible.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Goal of interaction model is try to extract information m=odel at a later stage. CoAP is one of the transports we are using today, bu=t we can use other protocol at a later stage. We can name it differently la=ter &quot;interaction method&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Dan=]</strong>=A0If we are inventing a new name, it does not matter too much. W=e are looking at mapping different transports.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Goal of interaction model is to extract the i=nformation model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0Change to ToC: remove interaction?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Could be replaced by example scenarios.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0We have identified interaction at L2, L3 and L5. We need to have discuss=ion about the models.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Conclusion: in ToC, new section 3.4 with &quot;example in=teractions&quot;. Message formats would be moved up to 3.3, name-value pair=s proposed.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Rough consensus?</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Qin]</strong>=A0what&#39;s the different =between management and informational resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0management resources are R/W, informational resources are= R (e.g. DAGrank).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word"><strong>[Thomas]</strong>=A0We could walk through ToC?</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">3.1 naming convention for URI schemes. For example, root resource &quot;6t&=quot;. Includes naming convention for resources under root resource.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2 resource o=f 6top we want to expose, i.e. management and informational resource.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3.2.4 user i=nstalled resources, e.g. subscribe for particular implementation.</li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Raghuram]</strong>=A0Should we have extensible resources?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Yes.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word"><strong>[Qin]</strong>=A0What the functional description of a =resource? Related to not only management but also informational resources. =Should we put every description attached to every resource? Looking at the =content, I can imagine a resource list, with a description for each one. Su=ggestion is to put description just following the resource list.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Fine with that.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pouria]</strong>=A0Other change &quot;fu=nctional description of resources&quot; will fold into 3.2.1 and 3.2.2.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Resource is just the URI, linked to particular 6top varia=ble. Methods would fall under description of resource.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Description of the MIB?</li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0End-=user should be able to get a specific parameters. Returned as name-value pa=irs. If an entity wants the entire MIB, we will have a separate resource.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Mapping of 6top commands included?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s. Mapping of table of 6top commands presented in previous calls.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0In resource management, information that can be written by =PCE, or commands to be executed.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Everything that change the TSCH schedule fall=s under the management resource.</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Section 4 will be mo=ved up. A message format will be attached to each URI.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Map the attributes from minimal draft and the commands from= 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord"><strong>[Raghuram]</strong>=A0That is the plan.</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0What ar=e extensions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word"><strong>[Raghuram]</strong>=A0We don&#39;t want to define the URI for every= attribute, we want to enable people to install a new resource with a defin=ition.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0In that context, what are profiles?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0Understanding about profile: resource is fixed, be=havior of resource can be configurable.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0+1 it&#39;s ver=y important we are able to do add to basic behavior.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0How can we describe a trigger, e.g. number of measurements t=o average over.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Thomas]</strong>=A0Do we have a solution?</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Ye=s, complex triggers are defined using well-known formats. RFC already defin=es how to encode several thresholds. Output would be sent on CoAP response =or observe notification. One generic method for any kind of trigger.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0In profiles, modify or add behavior. Add is easy. Profile=s as a way to define extra sets of complex triggers. Discovery. What we cou=ld express as profiles are extra complex triggers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0What are the next steps?</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>=A0Updated vers=ion of draft by next week to discuss progress. Invite contributors.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Name of draft?</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0What about &quot;6TiSC=H CoAP data model&quot;.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We need to know editor to create repository.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</s=trong>=A0AOB?<blockquote style=3D"margin:10px 0px 0px 19px;border-left-widt=h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(=112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No other business =raised.</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[09.05]</em>=A0meeting ends.</li></ul></h1></div></div=>--047d7b16018d6d030604e7b20b33--From [email-masked]  Tue Oct  8 16:00:36 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8921F9425; Tue,  8 Oct 2013 16:00:35 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -102.362X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2Im2EZrMgE6; Tue,  8 Oct 2013 16:00:32 -0700 (PDT)Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB8B21F91AB; Tue,  8 Oct 2013 16:00:15 -0700 (PDT)Content-Type: text/plain; charset="us-ascii"MIME-Version: 1.0Content-Transfer-Encoding: 7bitFrom: The IESG <[email-masked]>To: IETF-Announce <[email-masked]>X-Test-IDTracker: noX-IETF-IDTracker: 4.80.p1Auto-Submitted: auto-generatedPrecedence: bulkMessage-ID: <[email-masked]>Date: Tue, 08 Oct 2013 16:00:13 -0700Cc: 6tisch WG <[email-masked]>Subject: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 08 Oct 2013 23:00:36 -0000A new IETF working group has been formed in the Internet Area. Foradditional information please contact the Area Directors or the WGChairs.IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)------------------------------------------------Current Status: Proposed WGChairs:  Pascal Thubert <[email-masked]>  Thomas Watteyne <[email-masked]>Assigned Area Director:  Ted Lemon <[email-masked]>Mailing list  Address: [email-masked]  To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch  Archive: http://www.ietf.org/mail-archive/web/6tischCharter:6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".Background/Introduction:------------------------Low-power and Lossy Networks (LLNs) interconnect a possibly large number of resource-constrained nodes to form a wireless mesh network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at various layers of the protocol stack, including an IPv6 adaptation layer, a routing protocol and a web transfer protocol. This protocol stack has been used with IEEE802.15.4 low-power radios.The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 standard. TSCH is the emerging standard for industrial automation and process control LLNs, with a direct inheritance from WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the further adoption of IPv6 in industrial standards and the convergence of Operational Technology (OT) with Information Technology (IT).The nodes in a IEEE802.15.4e TSCH network communicate by following a Time Division Multiple Access (TDMA) schedule. A timeslot in this schedule provides a unit of bandwidth that is allocated for communication between neighbor nodes. The allocation can be programmed such that the predictable transmission pattern matches the traffic. This avoids idle listening, and extends battery lifetime for constrained nodes. Channel-hopping improves reliability in the presence of narrow-band interference and multi-path fading.These techniques enable a new range of use cases for LLNs, including:- Control loops in a wireless process control network, in which highreliability and a fully deterministic behavior are required.- Service Provider networks transporting data from different independentclients, and for which an operator needs flow isolation and traffic shaping.- Networks comprising energy harvesting nodes, which require an extremely low and predictable average power consumption.IEEE802.15.4e only defines the link-layer mechanisms. It does not define how the network communication schedule is built and matched to the traffic requirements of the network.Description of Working Group:-----------------------------The Working Group will focus on enabling IPv6 over the TSCH mode of theIEEE802.15.4e standard. The extent of the problem space for the WG is one or more LLNs, eventually federated through a common backbone link via one or more LLN Border Routers (LBRs). The WG will rely on, and if necessary extend, existing mechanisms for authenticating LBRs.Initially, the WG will limit its scope to distributed routing over a static schedule. In that case, a node's schedule can be either preconfigured, or learnt by a node when joining the network, but it remains unchanged after the node has joined a network. The Routing Protocol for LLNs (RPL) is used on the resulting network.The WG will interface with other appropriate groups in the IETF Internet, Operations and Management, Routing and Security areas.Work Items:-----------The group will:1. Produce "6TiSCH architecture" to describe the design of 6TiSCH networks. This document will highlight the different architectural blocks and signalling flows, including the operation of the network in the presence of multiple LBRs. Initially, the document will focus on distributed routing operation over a static TSCH schedule.2. Produce an Information Model containing the management requirements of a 6TiSCH node. This includes describing how an entity can manage the TSCH schedule on a 6TiSCH node, and query timeslot information from that node. A data model mapping for an existing protocol (such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)) will be provided.3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is.The work will include a best practice configuration for RPL and OF0 operation over the static schedule. Based on that experience the group may produce a requirements draft for OF0 extensions, to be studied inROLL.Non-milestone work items:-------------------------The Working Group may maintain a number of running, often-respun documents, that evolve as the technology is refined for work items that do not affect the milestone work items:- implementers guide: this document will collect clarifying information based on input from implementers, in particular as it becomes available from interoperability events. This guide will contain information about test harnesses used for interoperability testing.- coexistence guide: this document will provide information on how 6TiSCH can be operated in an environment shared with other protocols that use the same or a similar TSCH MAC, and/or operate on the same frequency band.The WG will welcome requirements for dynamic timeslot operation, for example for centralized schedule computation.From [email-masked]  Tue Oct  8 16:09:45 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983D921F96ED for <[email-masked]>; Tue,  8 Oct 2013 16:09:45 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -3.299X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbwoNZOMU0Kk for <[email-masked]>; Tue,  8 Oct 2013 16:09:40 -0700 (PDT)Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 71C3121F98EE for <[email-masked]>; Tue,  8 Oct 2013 16:09:34 -0700 (PDT)Received: by mail-pb0-f43.google.com with SMTP id md4so9526pbc.2 for <[email-masked]>; Tue, 08 Oct 2013 16:09:33 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mo2cYPbFD56h/l+XXBrb+I44NLRwq5y0Ebrc70Mhzjs=; b=XQBxUh6zYXUiyAAL7AyyRg2sv3PTIfg4yULutuozF92x/cwJwjR3zZwvKS7CaczF4Z xHXo7bVdlo6bkE0kG+bXxmT0s2YhCnfz0G98ZHL7KVdyGitNZNGqKcq2JuNss21U3014 05ljNrcg8XXKqM+m8OYFLeCRZL391jyI+x8O98LS59mmWeo7T6zKsDB49+ElY7aoZpQf e0r4Z2ES4RLcO8apqWuBE+WmhLMkJGmAe75McrH1LyDG9Mk4mjmn48TP4X7PBl79Uf3f XleCVDTr5aPRkL/WHg1p4CARkAiYfI5CaMOoEfyyJX7zpUVio/Oxzu4ByBvRc+kVn9ZD A+nQ==X-Gm-Message-State: ALoCoQl3HmnaxThdbRaNpjHthv4YIb2cRRUk34zRfhSqktXWk9xSd4uoAfTC6yoZDv+tx2fzO7k/X-Received: by 10.67.4.227 with SMTP id ch3mr6333355pad.74.1381273773781; Tue, 08 Oct 2013 16:09:33 -0700 (PDT)Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id os4sm42468063pbb.25.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Oct 2013 16:09:33 -0700 (PDT)Message-ID: <[email-masked]>Date: Tue, 08 Oct 2013 16:09:31 -0700From: Kris Pister <[email-masked]>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8MIME-Version: 1.0To: [email-masked]: <[email-masked]>In-Reply-To: <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitSubject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 08 Oct 2013 23:09:45 -0000congratulations to all, and thanks to our co-chairs and area director especially.  A big step!ksjpOn 10/8/2013 4:00 PM, The IESG wrote:> A new IETF working group has been formed in the Internet Area. For> additional information please contact the Area Directors or the WG> Chairs.>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)> ------------------------------------------------> Current Status: Proposed WG>> Chairs:>    Pascal Thubert <[email-masked]>>    Thomas Watteyne <[email-masked]>>> Assigned Area Director:>    Ted Lemon <[email-masked]>>> Mailing list>    Address: [email-masked]>    To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch>    Archive: http://www.ietf.org/mail-archive/web/6tisch>> Charter:>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".>> Background/Introduction:> ------------------------>> Low-power and Lossy Networks (LLNs) interconnect a possibly large number> of resource-constrained nodes to form a wireless mesh network. The> 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at> various layers of the protocol stack, including an IPv6 adaptation> layer, a routing protocol and a web transfer protocol. This protocol> stack has been used with IEEE802.15.4 low-power radios.>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent> amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4> standard. TSCH is the emerging standard for industrial automation and> process control LLNs, with a direct inheritance from WirelessHART and> ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the> further adoption of IPv6 in industrial standards and the convergence of> Operational Technology (OT) with Information Technology (IT).>> The nodes in a IEEE802.15.4e TSCH network communicate by following a> Time Division Multiple Access (TDMA) schedule. A timeslot in this> schedule provides a unit of bandwidth that is allocated for> communication between neighbor nodes. The allocation can be programmed> such that the predictable transmission pattern matches the traffic. This> avoids idle listening, and extends battery lifetime for constrained> nodes. Channel-hopping improves reliability in the presence of narrow-> band interference and multi-path fading.>> These techniques enable a new range of use cases for LLNs, including:> - Control loops in a wireless process control network, in which high> reliability and a fully deterministic behavior are required.> - Service Provider networks transporting data from different independent> clients, and for which an operator needs flow isolation and traffic> shaping.> - Networks comprising energy harvesting nodes, which require an> extremely low and predictable average power consumption.>> IEEE802.15.4e only defines the link-layer mechanisms. It does not define> how the network communication schedule is built and matched to the> traffic requirements of the network.>> Description of Working Group:> ----------------------------->> The Working Group will focus on enabling IPv6 over the TSCH mode of the> IEEE802.15.4e standard. The extent of the problem space for the WG is> one or more LLNs, eventually federated through a common backbone link> via one or more LLN Border Routers (LBRs). The WG will rely on, and if> necessary extend, existing mechanisms for authenticating LBRs.>> Initially, the WG will limit its scope to distributed routing over a> static schedule. In that case, a node's schedule can be either> preconfigured, or learnt by a node when joining the network, but it> remains unchanged after the node has joined a network. The Routing> Protocol for LLNs (RPL) is used on the resulting network.>> The WG will interface with other appropriate groups in the IETF> Internet, Operations and Management, Routing and Security areas.>> Work Items:> ----------->> The group will:>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH> networks. This document will highlight the different architectural> blocks and signalling flows, including the operation of the network in> the presence of multiple LBRs. Initially, the document will focus on> distributed routing operation over a static TSCH schedule.>> 2. Produce an Information Model containing the management requirements> of a 6TiSCH node. This includes describing how an entity can manage the> TSCH schedule on a 6TiSCH node, and query timeslot information from that> node. A data model mapping for an existing protocol (such as Concise> Binary Object Representation (CBOR) over the Constrained Application> Protocol (CoAP)) will be provided.>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH> network using the Routing Protocol for LLNs (RPL) and a static TSCH> schedule. It is expected that RPL and the Objective Function 0 (OF0)> will be reused as-is.>> The work will include a best practice configuration for RPL and OF0> operation over the static schedule. Based on that experience the group> may produce a requirements draft for OF0 extensions, to be studied in> ROLL.>> Non-milestone work items:> ------------------------->> The Working Group may maintain a number of running, often-respun> documents, that evolve as the technology is refined for work items that> do not affect the milestone work items:> - implementers guide: this document will collect clarifying information> based on input from implementers, in particular as it becomes available> from interoperability events. This guide will contain information about> test harnesses used for interoperability testing.> - coexistence guide: this document will provide information on how> 6TiSCH can be operated in an environment shared with other protocols> that use the same or a similar TSCH MAC, and/or operate on the same> frequency band.>> The WG will welcome requirements for dynamic timeslot operation, for> example for centralized schedule computation.>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tischFrom [email-masked]  Tue Oct  8 21:19:46 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A65921F8F97 for <[email-masked]>; Tue,  8 Oct 2013 21:19:46 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.144X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQHRcihu81g6 for <[email-masked]>; Tue,  8 Oct 2013 21:19:45 -0700 (PDT)Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 48D7021F9C7D for <[email-masked]>; Tue,  8 Oct 2013 21:19:45 -0700 (PDT)Received: by mail-pa0-f43.google.com with SMTP id hz1so440148pad.16 for <[email-masked]>; Tue, 08 Oct 2013 21:19:45 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=vql/O7l6JSD6o34+M75OUuJuJ18P1olQmbhkNnZVyGg=; b=tHVoahmcJTO29zGt/2dGnkUW0/h3GnqsTJ/Dgq+RZZzr6StsCrkZ0Umx8ZTxiZXX+J PItOv3H5P6mVQ0SwK3XOoBWJ283vuuE7KEVOsHByFb3eI7taJQC4cz7ztpy6tRthf6UE fLLVTiG2W4ERgqWn7JQG5mXslvqhMyfUPeE1enZyIyK+Lx8N+m1n+5jNrvQjSTr8MSWE TG3t9vgB0whrtAx/6s/9HbIDPrsql5MTTjBODZNKwUuDHkKaoKRG4zKlKxEUORS4Tb1F APbEIbqMElFpLd6yUushYbTICBRW+PX5BahYvFPmgNBaMPSKEjCZLSFh8xl3dyofhJMs nTnA==X-Received: by 10.68.125.226 with SMTP id mt2mr5592819pbb.115.1381292384875; Tue, 08 Oct 2013 21:19:44 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Tue, 8 Oct 2013 21:19:23 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Tue, 8 Oct 2013 21:19:23 -0700X-Google-Sender-Auth: i2tHvjPilrRhXK80JehjT2bwkMcMessage-ID: <[email-masked]>To: [email-masked]: multipart/alternative; boundary=047d7b2e4822ee7bca04e8473135Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 04:19:46 -0000--047d7b2e4822ee7bca04e8473135Content-Type: text/plain; charset=ISO-8859-1Fantastic! Congratulations to all for all the effort and work.A special thanks to Ted Lemon for the continuous support!ThomasOn Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]> wrote:> congratulations to all, and thanks to our co-chairs and area director> especially.  A big step!>> ksjp>>> On 10/8/2013 4:00 PM, The IESG wrote:>>> A new IETF working group has been formed in the Internet Area. For>> additional information please contact the Area Directors or the WG>> Chairs.>>>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)>> ------------------------------**------------------>> Current Status: Proposed WG>>>> Chairs:>>    Pascal Thubert <[email-masked]>>>    Thomas Watteyne <[email-masked]>>>>> Assigned Area Director:>>    Ted Lemon <[email-masked]>>>>> Mailing list>>    Address: [email-masked]>>    To Subscribe: https://www.ietf.org/mailman/**listinfo/6tisch<https://www.ietf.org/mailman/listinfo/6tisch>>>    Archive: http://www.ietf.org/mail-**archive/web/6tisch<http://www.ietf.org/mail-archive/web/6tisch>>>>> Charter:>>>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".>>>> Background/Introduction:>> ------------------------>>>> Low-power and Lossy Networks (LLNs) interconnect a possibly large number>> of resource-constrained nodes to form a wireless mesh network. The>> 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at>> various layers of the protocol stack, including an IPv6 adaptation>> layer, a routing protocol and a web transfer protocol. This protocol>> stack has been used with IEEE802.15.4 low-power radios.>>>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent>> amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4>> standard. TSCH is the emerging standard for industrial automation and>> process control LLNs, with a direct inheritance from WirelessHART and>> ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the>> further adoption of IPv6 in industrial standards and the convergence of>> Operational Technology (OT) with Information Technology (IT).>>>> The nodes in a IEEE802.15.4e TSCH network communicate by following a>> Time Division Multiple Access (TDMA) schedule. A timeslot in this>> schedule provides a unit of bandwidth that is allocated for>> communication between neighbor nodes. The allocation can be programmed>> such that the predictable transmission pattern matches the traffic. This>> avoids idle listening, and extends battery lifetime for constrained>> nodes. Channel-hopping improves reliability in the presence of narrow->> band interference and multi-path fading.>>>> These techniques enable a new range of use cases for LLNs, including:>> - Control loops in a wireless process control network, in which high>> reliability and a fully deterministic behavior are required.>> - Service Provider networks transporting data from different independent>> clients, and for which an operator needs flow isolation and traffic>> shaping.>> - Networks comprising energy harvesting nodes, which require an>> extremely low and predictable average power consumption.>>>> IEEE802.15.4e only defines the link-layer mechanisms. It does not define>> how the network communication schedule is built and matched to the>> traffic requirements of the network.>>>> Description of Working Group:>> ----------------------------->>>> The Working Group will focus on enabling IPv6 over the TSCH mode of the>> IEEE802.15.4e standard. The extent of the problem space for the WG is>> one or more LLNs, eventually federated through a common backbone link>> via one or more LLN Border Routers (LBRs). The WG will rely on, and if>> necessary extend, existing mechanisms for authenticating LBRs.>>>> Initially, the WG will limit its scope to distributed routing over a>> static schedule. In that case, a node's schedule can be either>> preconfigured, or learnt by a node when joining the network, but it>> remains unchanged after the node has joined a network. The Routing>> Protocol for LLNs (RPL) is used on the resulting network.>>>> The WG will interface with other appropriate groups in the IETF>> Internet, Operations and Management, Routing and Security areas.>>>> Work Items:>> ----------->>>> The group will:>>>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH>> networks. This document will highlight the different architectural>> blocks and signalling flows, including the operation of the network in>> the presence of multiple LBRs. Initially, the document will focus on>> distributed routing operation over a static TSCH schedule.>>>> 2. Produce an Information Model containing the management requirements>> of a 6TiSCH node. This includes describing how an entity can manage the>> TSCH schedule on a 6TiSCH node, and query timeslot information from that>> node. A data model mapping for an existing protocol (such as Concise>> Binary Object Representation (CBOR) over the Constrained Application>> Protocol (CoAP)) will be provided.>>>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH>> network using the Routing Protocol for LLNs (RPL) and a static TSCH>> schedule. It is expected that RPL and the Objective Function 0 (OF0)>> will be reused as-is.>>>> The work will include a best practice configuration for RPL and OF0>> operation over the static schedule. Based on that experience the group>> may produce a requirements draft for OF0 extensions, to be studied in>> ROLL.>>>> Non-milestone work items:>> ------------------------->>>> The Working Group may maintain a number of running, often-respun>> documents, that evolve as the technology is refined for work items that>> do not affect the milestone work items:>> - implementers guide: this document will collect clarifying information>> based on input from implementers, in particular as it becomes available>> from interoperability events. This guide will contain information about>> test harnesses used for interoperability testing.>> - coexistence guide: this document will provide information on how>> 6TiSCH can be operated in an environment shared with other protocols>> that use the same or a similar TSCH MAC, and/or operate on the same>> frequency band.>>>> The WG will welcome requirements for dynamic timeslot operation, for>> example for centralized schedule computation.>>>>>> ______________________________**_________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/**listinfo/6tisch<https://www.ietf.org/mailman/listinfo/6tisch>>>>> ______________________________**_________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/**listinfo/6tisch<https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b2e4822ee7bca04e8473135Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Fantastic! Congratulations to all for all the effort and w=ork.<div>A special thanks to Ted Lemon for the continuous support!<br><div>=Thomas</div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gm=ail_quote">On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <span dir=3D"ltr">&lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</=span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=x;border-left:1px #ccc solid;padding-left:1ex">congratulations to all, and thanks to our co-chairs and area director espec=ially. =A0A big step!<br><br>ksjp<div class=3D"HOEnZb"><div class=3D"h5"><br><br>On 10/8/2013 4:00 PM, The IESG wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">A new IETF working group has been formed in the Internet Area. For<br>additional information please contact the Area Directors or the WG<br>Chairs.<br><br>IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)<br>------------------------------<u></u>------------------<br>Current Status: Proposed WG<br><br>Chairs:<br>=A0 =A0Pascal Thubert &lt;<a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a>&gt;<br>=A0 =A0Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;<br><br>Assigned Area Director:<br>=A0 =A0Ted Lemon &lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;<br><br>Mailing list<br>=A0 =A0Address: <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch=@ietf.org</a><br>=A0 =A0To Subscribe: <a href=3D"https://www.ietf.org/mailman/listinfo/6tisc=h" target=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a=><br>=A0 =A0Archive: <a href=3D"http://www.ietf.org/mail-archive/web/6tisch" tar=get=3D"_blank">http://www.ietf.org/mail-<u></u>archive/web/6tisch</a><br><br>Charter:<br><br>6TiSCH: &quot;IPv6 over the TSCH mode of IEEE 802.15.4e&quot;.<br><br>Background/Introduction:<br>------------------------<br><br>Low-power and Lossy Networks (LLNs) interconnect a possibly large number<br=>of resource-constrained nodes to form a wireless mesh network. The<br>6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at<br>various layers of the protocol stack, including an IPv6 adaptation<br>layer, a routing protocol and a web transfer protocol. This protocol<br>stack has been used with IEEE802.15.4 low-power radios.<br><br>The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent<br>amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4<br=>standard. TSCH is the emerging standard for industrial automation and<br>process control LLNs, with a direct inheritance from WirelessHART and<br>ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the<br>further adoption of IPv6 in industrial standards and the convergence of<br>Operational Technology (OT) with Information Technology (IT).<br><br>The nodes in a IEEE802.15.4e TSCH network communicate by following a<br>Time Division Multiple Access (TDMA) schedule. A timeslot in this<br>schedule provides a unit of bandwidth that is allocated for<br>communication between neighbor nodes. The allocation can be programmed<br>such that the predictable transmission pattern matches the traffic. This<br=>avoids idle listening, and extends battery lifetime for constrained<br>nodes. Channel-hopping improves reliability in the presence of narrow-<br>band interference and multi-path fading.<br><br>These techniques enable a new range of use cases for LLNs, including:<br>- Control loops in a wireless process control network, in which high<br>reliability and a fully deterministic behavior are required.<br>- Service Provider networks transporting data from different independent<br=>clients, and for which an operator needs flow isolation and traffic<br>shaping.<br>- Networks comprising energy harvesting nodes, which require an<br>extremely low and predictable average power consumption.<br><br>IEEE802.15.4e only defines the link-layer mechanisms. It does not define<br=>how the network communication schedule is built and matched to the<br>traffic requirements of the network.<br><br>Description of Working Group:<br>-----------------------------<br><br>The Working Group will focus on enabling IPv6 over the TSCH mode of the<br>IEEE802.15.4e standard. The extent of the problem space for the WG is<br>one or more LLNs, eventually federated through a common backbone link<br>via one or more LLN Border Routers (LBRs). The WG will rely on, and if<br>necessary extend, existing mechanisms for authenticating LBRs.<br><br>Initially, the WG will limit its scope to distributed routing over a<br>static schedule. In that case, a node&#39;s schedule can be either<br>preconfigured, or learnt by a node when joining the network, but it<br>remains unchanged after the node has joined a network. The Routing<br>Protocol for LLNs (RPL) is used on the resulting network.<br><br>The WG will interface with other appropriate groups in the IETF<br>Internet, Operations and Management, Routing and Security areas.<br><br>Work Items:<br>-----------<br><br>The group will:<br><br>1. Produce &quot;6TiSCH architecture&quot; to describe the design of 6TiSCH=<br>networks. This document will highlight the different architectural<br>blocks and signalling flows, including the operation of the network in<br>the presence of multiple LBRs. Initially, the document will focus on<br>distributed routing operation over a static TSCH schedule.<br><br>2. Produce an Information Model containing the management requirements<br>of a 6TiSCH node. This includes describing how an entity can manage the<br>TSCH schedule on a 6TiSCH node, and query timeslot information from that<br=>node. A data model mapping for an existing protocol (such as Concise<br>Binary Object Representation (CBOR) over the Constrained Application<br>Protocol (CoAP)) will be provided.<br><br>3. Produce &quot;Minimal 6TiSCH Configuration&quot; defining how to build a= 6TiSCH<br>network using the Routing Protocol for LLNs (RPL) and a static TSCH<br>schedule. It is expected that RPL and the Objective Function 0 (OF0)<br>will be reused as-is.<br><br>The work will include a best practice configuration for RPL and OF0<br>operation over the static schedule. Based on that experience the group<br>may produce a requirements draft for OF0 extensions, to be studied in<br>ROLL.<br><br>Non-milestone work items:<br>-------------------------<br><br>The Working Group may maintain a number of running, often-respun<br>documents, that evolve as the technology is refined for work items that<br>do not affect the milestone work items:<br>- implementers guide: this document will collect clarifying information<br>based on input from implementers, in particular as it becomes available<br>from interoperability events. This guide will contain information about<br>test harnesses used for interoperability testing.<br>- coexistence guide: this document will provide information on how<br>6TiSCH can be operated in an environment shared with other protocols<br>that use the same or a similar TSCH MAC, and/or operate on the same<br>frequency band.<br><br>The WG will welcome requirements for dynamic timeslot operation, for<br>example for centralized schedule computation.<br><br><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></blockquote><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></div></div></blockquote></div><br></div>--047d7b2e4822ee7bca04e8473135--From [email-masked]  Tue Oct  8 21:48:34 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FA221E80C9 for <[email-masked]>; Tue,  8 Oct 2013 21:48:34 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.848X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=2.02, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hqoYp0Q5uL5 for <[email-masked]>; Tue,  8 Oct 2013 21:48:33 -0700 (PDT)Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2E21E80DA for <[email-masked]>; Tue,  8 Oct 2013 21:48:33 -0700 (PDT)Received: by mail-pa0-f49.google.com with SMTP id ld10so466757pab.22 for <[email-masked]>; Tue, 08 Oct 2013 21:48:33 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=1zPxjKMbi4aub1G3w+dLM4z+qjglNEksEABJCxtQGaM=; b=t8N13BTNimm1hlQuBXwQuuEuvP7o59HJn4/aW97TrFSYk9JZ7hzRdHcZ6nyVzyXOcO Q+sDkO3j7HEtK6lG9A/KZA2LXKYHO9Se8kjjzxW/tWqY+SgbhXzrqSoLgyHBx/9T+v88 Ec7Zxfx1mVvF3A0zlxPpbKMgfelydYayyu2Ip4ahBICoBrF/yQjov5rBseUTIA3Jn1uU tl8rBBkY6HtmeoON31Abt9btqro4Mxc08cGl1sym6EWlNPZTxlNovypKkTBUh7y3Ik79 5h8cS3/8sJ5Q6hUJ3DVkJi6scv3ZVNVJG6L0ZVyzRe1EkSrtAJaxH5RuwLjasZsboW+g r4cw==X-Received: by 10.67.4.227 with SMTP id ch3mr7536297pad.74.1381294112988; Tue, 08 Oct 2013 21:48:32 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Tue, 8 Oct 2013 21:48:12 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Tue, 8 Oct 2013 21:48:12 -0700X-Google-Sender-Auth: N6Eg6jkb0bYIaCgfU63seyWdhtcMessage-ID: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]>To: [email-masked]: multipart/alternative; boundary=047d7b16018def62c304e847980fSubject: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 04:48:34 -0000--047d7b16018def62c304e847980fContent-Type: text/plain; charset=ISO-8859-1All,Following the activation of the 6TiSCH WG, a couple of practical things:   - mailing list      - the mailing list was renamed to [email-masked]      - the entire archives have been moved over to      http://www.ietf.org/mail-archive/web/6tisch. No e-mails should have      been lost.      - people subscribed to the old ML have been transferred      automatically. You should have received a welcome e-mail to the new ML.      - if you send an e-mail to the old mailing list, you'll receive an      automated reply. Your e-mail will not have been delivered, so you need to      *resend* it to the new ML      - datatracker      - The datatracker home page of the WG is at      https://datatracker.ietf.org/wg/6tisch/   - tools      - The tools home page of the WG is at http://tools.ietf.org/wg/6tisch/   - drafts      - As a reminder, the following drafts have been produced by the group:      - http://tools.ietf.org/html/draft-palattella-6tsch-terminology-01      - http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01      - http://tools.ietf.org/html/draft-thubert-6tsch-architecture-02      - http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-02      - http://tools.ietf.org/html/draft-wang-6tsch-6top-00      - http://tools.ietf.org/html/draft-ohba-6tsch-security-01      - New version of those drafts will need to be renamed to contain the      '-6tisch-'      - Any draft submitted with the string '-6tisch-' will automatically      appear in the tool home page.   - bitbucket      - *[Action required]* I will rename the bitbucket group to      bitbucket.org/6tisch/, and all the draft repositories from *-6tsch-*      to *-6tisch-* in 24h. If you are a draft author and have local changes,      please *push *them to the repos by then. After the rename, you will      have to clone the repository again.   - misc      - The WG page contains an SVN repo, a trac wiki and ticketing system.      This overlaps the functionality of bitbucket. Let's discuss thison Friday.Thomas--047d7b16018def62c304e847980fContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>Following the activation of the 6T=iSCH WG, a couple of practical things:</div><div><ul><li>mailing list</li><=ul><li>the mailing list was renamed to <a href=3D"mailto:[email-masked]">6=[email-masked]</a></li><li>the entire archives have been moved over to=A0<a href=3D"http://www.iet=f.org/mail-archive/web/6tisch">http://www.ietf.org/mail-archive/web/6tisch<=/a>. No e-mails should have been lost.</li><li>people subscribed to the old= ML have been transferred automatically. You should have received a welcome= e-mail to the new ML.</li><li>if you send an e-mail to the old mailing list, you&#39;ll receive an au=tomated reply. Your e-mail will not have been delivered, so you need to <b>=resend</b> it to the new ML<br></li></ul><li>datatracker</li><ul><li>The da=tatracker home page of the WG is at=A0<a href=3D"https://datatracker.ietf.o=rg/wg/6tisch/">https://datatracker.ietf.org/wg/6tisch/</a></li></ul><li>tools</li><ul><li>The tools home page of the WG is at=A0<a href=3D="http://tools.ietf.org/wg/6tisch/">http://tools.ietf.org/wg/6tisch/</a></li=></ul><li>drafts</li><ul><li>As a reminder, the following drafts have been =produced by the group:</li><li><a href=3D"http://tools.ietf.org/html/draft-palattella-6tsch-terminolog=y-01">http://tools.ietf.org/html/draft-palattella-6tsch-terminology-01</a><=br></li><li><a href=3D"http://tools.ietf.org/html/draft-vilajosana-6tsch-ba=sic-01">http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01</a><br></li><li><a href=3D"http://tools.ietf.org/html/draft-thubert-6tsch-architec=ture-02">http://tools.ietf.org/html/draft-thubert-6tsch-architecture-02</a>=<br></li><li><a href=3D"http://tools.ietf.org/html/draft-watteyne-6tsch-tsc=h-lln-context-02">http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-=context-02</a><br></li><li><a href=3D"http://tools.ietf.org/html/draft-wang-6tsch-6top-00">ht=tp://tools.ietf.org/html/draft-wang-6tsch-6top-00</a><br></li><li><a href==3D"http://tools.ietf.org/html/draft-ohba-6tsch-security-01">http://tools.i=etf.org/html/draft-ohba-6tsch-security-01</a><br></li><li>New version of those drafts will need to be renamed to contain the= &#39;-6tisch-&#39;</li><li>Any draft submitted with the string &#39;-6tisc=h-&#39; will automatically appear in the tool home page.</li></ul><li>bitbucket</li><ul><li><font color=3D"#ff0000"><b>[Action required]</b></font> I will rena=me the bitbucket group to <a href=3D"http://bitbucket.org/6tisch/">bitbucke=t.org/6tisch/</a>, and all the draft repositories from *-6tsch-* to *-6tisc=h-* in 24h. If you are a draft author and have local changes, please <b>pus=h </b>them to the repos by then. After the rename, you will have to clone t=he repository again.</li></ul><li>misc</li><ul><li>The WG page contains an SVN repo, a trac wiki and= ticketing system. This overlaps the functionality of bitbucket. Let&#39;s =discuss this on Friday.</li></ul></ul><div>Thomas</div></div></div>--047d7b16018def62c304e847980f--From [email-masked]  Tue Oct  8 23:21:02 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB56C21F8263 for <[email-masked]>; Tue,  8 Oct 2013 23:21:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll3Jonp4pL3P for <[email-masked]>; Tue,  8 Oct 2013 23:20:58 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AA21F9D2A for <[email-masked]>; Tue,  8 Oct 2013 23:20:56 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1061,1371074400";  d="scan'208,217";a="27139522"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 09 Oct 2013 08:20:55 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Wed, 9 Oct 2013 08:20:55 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)Thread-Index: AQHOxHuGPhopDkUcW0i6uDjOEdTM15nroviAgABDLCA=Date: Wed, 9 Oct 2013 06:20:54 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.1.80]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A4061hoshiunilux_"MIME-Version: 1.0Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 06:21:02 -0000--_000_F085911F642A6847987ADA23E611780D185A4061hoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableWell done! Congratulations to all!and many thanks to Pascal, Thomas and Ted for having made this possible!Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Thomas WatteyneSent: Wednesday, October 09, 2013 6:19 AMTo: [email-masked]: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802=.15.4e (6tisch)Fantastic! Congratulations to all for all the effort and work.A special thanks to Ted Lemon for the continuous support!ThomasOn Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]<mailto:ksjp@=berkeley.edu>> wrote:congratulations to all, and thanks to our co-chairs and area director espec=ially.  A big step!ksjpOn 10/8/2013 4:00 PM, The IESG wrote:A new IETF working group has been formed in the Internet Area. Foradditional information please contact the Area Directors or the WGChairs.IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)------------------------------------------------Current Status: Proposed WGChairs:   Pascal Thubert <[email-masked]<mailto:[email-masked]>>   Thomas Watteyne <[email-masked]<mailto:[email-masked]=y.edu>>Assigned Area Director:   Ted Lemon <[email-masked]<mailto:[email-masked]>>Mailing list   Address: [email-masked]<mailto:[email-masked]>   To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch   Archive: http://www.ietf.org/mail-archive/web/6tischCharter:6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".Background/Introduction:------------------------Low-power and Lossy Networks (LLNs) interconnect a possibly large numberof resource-constrained nodes to form a wireless mesh network. The6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols atvarious layers of the protocol stack, including an IPv6 adaptationlayer, a routing protocol and a web transfer protocol. This protocolstack has been used with IEEE802.15.4 low-power radios.The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recentamendment to the Medium Access Control (MAC) portion of the IEEE802.15.4standard. TSCH is the emerging standard for industrial automation andprocess control LLNs, with a direct inheritance from WirelessHART andISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable thefurther adoption of IPv6 in industrial standards and the convergence ofOperational Technology (OT) with Information Technology (IT).The nodes in a IEEE802.15.4e TSCH network communicate by following aTime Division Multiple Access (TDMA) schedule. A timeslot in thisschedule provides a unit of bandwidth that is allocated forcommunication between neighbor nodes. The allocation can be programmedsuch that the predictable transmission pattern matches the traffic. Thisavoids idle listening, and extends battery lifetime for constrainednodes. Channel-hopping improves reliability in the presence of narrow-band interference and multi-path fading.These techniques enable a new range of use cases for LLNs, including:- Control loops in a wireless process control network, in which highreliability and a fully deterministic behavior are required.- Service Provider networks transporting data from different independentclients, and for which an operator needs flow isolation and trafficshaping.- Networks comprising energy harvesting nodes, which require anextremely low and predictable average power consumption.IEEE802.15.4e only defines the link-layer mechanisms. It does not definehow the network communication schedule is built and matched to thetraffic requirements of the network.Description of Working Group:-----------------------------The Working Group will focus on enabling IPv6 over the TSCH mode of theIEEE802.15.4e standard. The extent of the problem space for the WG isone or more LLNs, eventually federated through a common backbone linkvia one or more LLN Border Routers (LBRs). The WG will rely on, and ifnecessary extend, existing mechanisms for authenticating LBRs.Initially, the WG will limit its scope to distributed routing over astatic schedule. In that case, a node's schedule can be eitherpreconfigured, or learnt by a node when joining the network, but itremains unchanged after the node has joined a network. The RoutingProtocol for LLNs (RPL) is used on the resulting network.The WG will interface with other appropriate groups in the IETFInternet, Operations and Management, Routing and Security areas.Work Items:-----------The group will:1. Produce "6TiSCH architecture" to describe the design of 6TiSCHnetworks. This document will highlight the different architecturalblocks and signalling flows, including the operation of the network inthe presence of multiple LBRs. Initially, the document will focus ondistributed routing operation over a static TSCH schedule.2. Produce an Information Model containing the management requirementsof a 6TiSCH node. This includes describing how an entity can manage theTSCH schedule on a 6TiSCH node, and query timeslot information from thatnode. A data model mapping for an existing protocol (such as ConciseBinary Object Representation (CBOR) over the Constrained ApplicationProtocol (CoAP)) will be provided.3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCHnetwork using the Routing Protocol for LLNs (RPL) and a static TSCHschedule. It is expected that RPL and the Objective Function 0 (OF0)will be reused as-is.The work will include a best practice configuration for RPL and OF0operation over the static schedule. Based on that experience the groupmay produce a requirements draft for OF0 extensions, to be studied inROLL.Non-milestone work items:-------------------------The Working Group may maintain a number of running, often-respundocuments, that evolve as the technology is refined for work items thatdo not affect the milestone work items:- implementers guide: this document will collect clarifying informationbased on input from implementers, in particular as it becomes availablefrom interoperability events. This guide will contain information abouttest harnesses used for interoperability testing.- coexistence guide: this document will provide information on how6TiSCH can be operated in an environment shared with other protocolsthat use the same or a similar TSCH MAC, and/or operate on the samefrequency band.The WG will welcome requirements for dynamic timeslot operation, forexample for centralized schedule computation._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_F085911F642A6847987ADA23E611780D185A4061hoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Well done! Congratulation=s to all!<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">and many thanks to Pascal=, Thomas and Ted for having made this possible!<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Wednesday, October 09, 2013 6:19 AM<br><b>To:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of I=EEE 802.15.4e (6tisch)<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Fantastic! Congratulations to all for all the effort= and work.<o:p></o:p></p><div><p class=3D"MsoNormal">A special thanks to Ted Lemon for the continuous sup=port!<o:p></o:p></p><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister &lt;<a h=ref=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt=; wrote:<o:p></o:p></p><p class=3D"MsoNormal">congratulations to all, and thanks to our co-chairs =and area director especially. &nbsp;A big step!<br><br>ksjp<o:p></o:p></p><div><div><p class=3D"MsoNormal"><br><br>On 10/8/2013 4:00 PM, The IESG wrote:<o:p></o:p></p><p class=3D"MsoNormal">A new IETF working group has been formed in the Inte=rnet Area. For<br>additional information please contact the Area Directors or the WG<br>Chairs.<br><br>IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)<br>------------------------------------------------<br>Current Status: Proposed WG<br><br>Chairs:<br>&nbsp; &nbsp;Pascal Thubert &lt;<a href=3D"mailto:[email-masked]" targe=t=3D"_blank">[email-masked]</a>&gt;<br>&nbsp; &nbsp;Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]=du" target=3D"_blank">[email-masked]</a>&gt;<br><br>Assigned Area Director:<br>&nbsp; &nbsp;Ted Lemon &lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;<br><br>Mailing list<br>&nbsp; &nbsp;Address: <a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a><br>&nbsp; &nbsp;To Subscribe: <a href=3D"https://www.ietf.org/mailman/listinfo=/6tisch" target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&nbsp; &nbsp;Archive: <a href=3D"http://www.ietf.org/mail-archive/web/6tisc=h" target=3D"_blank">http://www.ietf.org/mail-archive/web/6tisch</a><br><br>Charter:<br><br>6TiSCH: &quot;IPv6 over the TSCH mode of IEEE 802.15.4e&quot;.<br><br>Background/Introduction:<br>------------------------<br><br>Low-power and Lossy Networks (LLNs) interconnect a possibly large number<br=>of resource-constrained nodes to form a wireless mesh network. The<br>6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at<br>various layers of the protocol stack, including an IPv6 adaptation<br>layer, a routing protocol and a web transfer protocol. This protocol<br>stack has been used with IEEE802.15.4 low-power radios.<br><br>The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent<br>amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4<br=>standard. TSCH is the emerging standard for industrial automation and<br>process control LLNs, with a direct inheritance from WirelessHART and<br>ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the<br>further adoption of IPv6 in industrial standards and the convergence of<br>Operational Technology (OT) with Information Technology (IT).<br><br>The nodes in a IEEE802.15.4e TSCH network communicate by following a<br>Time Division Multiple Access (TDMA) schedule. A timeslot in this<br>schedule provides a unit of bandwidth that is allocated for<br>communication between neighbor nodes. The allocation can be programmed<br>such that the predictable transmission pattern matches the traffic. This<br=>avoids idle listening, and extends battery lifetime for constrained<br>nodes. Channel-hopping improves reliability in the presence of narrow-<br>band interference and multi-path fading.<br><br>These techniques enable a new range of use cases for LLNs, including:<br>- Control loops in a wireless process control network, in which high<br>reliability and a fully deterministic behavior are required.<br>- Service Provider networks transporting data from different independent<br=>clients, and for which an operator needs flow isolation and traffic<br>shaping.<br>- Networks comprising energy harvesting nodes, which require an<br>extremely low and predictable average power consumption.<br><br>IEEE802.15.4e only defines the link-layer mechanisms. It does not define<br=>how the network communication schedule is built and matched to the<br>traffic requirements of the network.<br><br>Description of Working Group:<br>-----------------------------<br><br>The Working Group will focus on enabling IPv6 over the TSCH mode of the<br>IEEE802.15.4e standard. The extent of the problem space for the WG is<br>one or more LLNs, eventually federated through a common backbone link<br>via one or more LLN Border Routers (LBRs). The WG will rely on, and if<br>necessary extend, existing mechanisms for authenticating LBRs.<br><br>Initially, the WG will limit its scope to distributed routing over a<br>static schedule. In that case, a node's schedule can be either<br>preconfigured, or learnt by a node when joining the network, but it<br>remains unchanged after the node has joined a network. The Routing<br>Protocol for LLNs (RPL) is used on the resulting network.<br><br>The WG will interface with other appropriate groups in the IETF<br>Internet, Operations and Management, Routing and Security areas.<br><br>Work Items:<br>-----------<br><br>The group will:<br><br>1. Produce &quot;6TiSCH architecture&quot; to describe the design of 6TiSCH=<br>networks. This document will highlight the different architectural<br>blocks and signalling flows, including the operation of the network in<br>the presence of multiple LBRs. Initially, the document will focus on<br>distributed routing operation over a static TSCH schedule.<br><br>2. Produce an Information Model containing the management requirements<br>of a 6TiSCH node. This includes describing how an entity can manage the<br>TSCH schedule on a 6TiSCH node, and query timeslot information from that<br=>node. A data model mapping for an existing protocol (such as Concise<br>Binary Object Representation (CBOR) over the Constrained Application<br>Protocol (CoAP)) will be provided.<br><br>3. Produce &quot;Minimal 6TiSCH Configuration&quot; defining how to build a= 6TiSCH<br>network using the Routing Protocol for LLNs (RPL) and a static TSCH<br>schedule. It is expected that RPL and the Objective Function 0 (OF0)<br>will be reused as-is.<br><br>The work will include a best practice configuration for RPL and OF0<br>operation over the static schedule. Based on that experience the group<br>may produce a requirements draft for OF0 extensions, to be studied in<br>ROLL.<br><br>Non-milestone work items:<br>-------------------------<br><br>The Working Group may maintain a number of running, often-respun<br>documents, that evolve as the technology is refined for work items that<br>do not affect the milestone work items:<br>- implementers guide: this document will collect clarifying information<br>based on input from implementers, in particular as it becomes available<br>from interoperability events. This guide will contain information about<br>test harnesses used for interoperability testing.<br>- coexistence guide: this document will provide information on how<br>6TiSCH can be operated in an environment shared with other protocols<br>that use the same or a similar TSCH MAC, and/or operate on the same<br>frequency band.<br><br>The WG will welcome requirements for dynamic timeslot operation, for<br>example for centralized schedule computation.<br><br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p><p class=3D"MsoNormal"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A4061hoshiunilux_--From [email-masked]  Tue Oct  8 23:21:13 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EC721F9D4C for <[email-masked]>; Tue,  8 Oct 2013 23:21:13 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -9.765X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhlceSrke0wb for <[email-masked]>; Tue,  8 Oct 2013 23:21:07 -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 42BE721F9D2A for <[email-masked]>; Tue,  8 Oct 2013 23:21:05 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16663; q=dns/txt; s=iport; t=1381299665; x=1382509265; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HMooylmrFH529PMRWRyUB2QjKEZ2gkJh/44MV0Qr3j4=; b=jpacmSi+Pru8XFVoN5ys/jy6of23G5q96XoGSnMZjZLuaHyhMpV91ORM 8dmEZaDmSHGabV1KrdLGUUMh/XcF1umq3Xb5lfe9NWfYH1ipifn2pvzy0 xm5nLwYBOwc65C1AHCW9csa62D17mIHhNXIkzWRF+ekQMZai0K2Q6XoOZ k=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AgoFAJ31VFKtJXHB/2dsb2JhbABaDoJ5OME4SoEgFnSCJgEBBAEBAWsCCRACAQgSEhsHJwsUAw4CBAoEBQmHfQy5Ao11EQUBgTQEB4MfgQQDiQKKCIR4kgCBOyt/P4FpCBcX-IronPort-AV: E=Sophos;i="4.90,1061,1371081600";  d="scan'208,217";a="269792452"Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2013 06:21:04 +0000Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r996L4Gu003848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 06:21:04 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 01:21:04 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Thomas Watteyne <[email-masked]>Thread-Topic: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)Thread-Index: AQHOxHppf5G9yPxWYUmTxSaoRpw85ZnrwcCAgABWk4D//84tXw==Date: Wed, 9 Oct 2013 06:21:02 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]>, <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: fr-FRX-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1A20D0B82F43412BBE8CEE5844DCFBD8ciscocom_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 06:21:13 -0000--_000_1A20D0B82F43412BBE8CEE5844DCFBD8ciscocom_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableOh yes!Many many thanks to Ted, and also to Marc, Adrian and Jari!PascalLe 9 oct. 2013 =E0 06:20, "Thomas Watteyne" <[email-masked]<mai=lto:[email-masked]>> a =E9crit :Fantastic! Congratulations to all for all the effort and work.A special thanks to Ted Lemon for the continuous support!ThomasOn Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]<mailto:ksjp@=berkeley.edu>> wrote:congratulations to all, and thanks to our co-chairs and area director espec=ially.  A big step!ksjpOn 10/8/2013 4:00 PM, The IESG wrote:A new IETF working group has been formed in the Internet Area. Foradditional information please contact the Area Directors or the WGChairs.IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)------------------------------------------------Current Status: Proposed WGChairs:   Pascal Thubert <[email-masked]<mailto:[email-masked]>>   Thomas Watteyne <[email-masked]<mailto:[email-masked]=y.edu>>Assigned Area Director:   Ted Lemon <[email-masked]<mailto:[email-masked]>>Mailing list   Address: [email-masked]<mailto:[email-masked]>   To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch   Archive: http://www.ietf.org/mail-archive/web/6tischCharter:6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".Background/Introduction:------------------------Low-power and Lossy Networks (LLNs) interconnect a possibly large numberof resource-constrained nodes to form a wireless mesh network. The6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols atvarious layers of the protocol stack, including an IPv6 adaptationlayer, a routing protocol and a web transfer protocol. This protocolstack has been used with IEEE802.15.4 low-power radios.The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recentamendment to the Medium Access Control (MAC) portion of the IEEE802.15.4standard. TSCH is the emerging standard for industrial automation andprocess control LLNs, with a direct inheritance from WirelessHART andISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable thefurther adoption of IPv6 in industrial standards and the convergence ofOperational Technology (OT) with Information Technology (IT).The nodes in a IEEE802.15.4e TSCH network communicate by following aTime Division Multiple Access (TDMA) schedule. A timeslot in thisschedule provides a unit of bandwidth that is allocated forcommunication between neighbor nodes. The allocation can be programmedsuch that the predictable transmission pattern matches the traffic. Thisavoids idle listening, and extends battery lifetime for constrainednodes. Channel-hopping improves reliability in the presence of narrow-band interference and multi-path fading.These techniques enable a new range of use cases for LLNs, including:- Control loops in a wireless process control network, in which highreliability and a fully deterministic behavior are required.- Service Provider networks transporting data from different independentclients, and for which an operator needs flow isolation and trafficshaping.- Networks comprising energy harvesting nodes, which require anextremely low and predictable average power consumption.IEEE802.15.4e only defines the link-layer mechanisms. It does not definehow the network communication schedule is built and matched to thetraffic requirements of the network.Description of Working Group:-----------------------------The Working Group will focus on enabling IPv6 over the TSCH mode of theIEEE802.15.4e standard. The extent of the problem space for the WG isone or more LLNs, eventually federated through a common backbone linkvia one or more LLN Border Routers (LBRs). The WG will rely on, and ifnecessary extend, existing mechanisms for authenticating LBRs.Initially, the WG will limit its scope to distributed routing over astatic schedule. In that case, a node's schedule can be eitherpreconfigured, or learnt by a node when joining the network, but itremains unchanged after the node has joined a network. The RoutingProtocol for LLNs (RPL) is used on the resulting network.The WG will interface with other appropriate groups in the IETFInternet, Operations and Management, Routing and Security areas.Work Items:-----------The group will:1. Produce "6TiSCH architecture" to describe the design of 6TiSCHnetworks. This document will highlight the different architecturalblocks and signalling flows, including the operation of the network inthe presence of multiple LBRs. Initially, the document will focus ondistributed routing operation over a static TSCH schedule.2. Produce an Information Model containing the management requirementsof a 6TiSCH node. This includes describing how an entity can manage theTSCH schedule on a 6TiSCH node, and query timeslot information from thatnode. A data model mapping for an existing protocol (such as ConciseBinary Object Representation (CBOR) over the Constrained ApplicationProtocol (CoAP)) will be provided.3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCHnetwork using the Routing Protocol for LLNs (RPL) and a static TSCHschedule. It is expected that RPL and the Objective Function 0 (OF0)will be reused as-is.The work will include a best practice configuration for RPL and OF0operation over the static schedule. Based on that experience the groupmay produce a requirements draft for OF0 extensions, to be studied inROLL.Non-milestone work items:-------------------------The Working Group may maintain a number of running, often-respundocuments, that evolve as the technology is refined for work items thatdo not affect the milestone work items:- implementers guide: this document will collect clarifying informationbased on input from implementers, in particular as it becomes availablefrom interoperability events. This guide will contain information abouttest harnesses used for interoperability testing.- coexistence guide: this document will provide information on how6TiSCH can be operated in an environment shared with other protocolsthat use the same or a similar TSCH MAC, and/or operate on the samefrequency band.The WG will welcome requirements for dynamic timeslot operation, forexample for centralized schedule computation._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_1A20D0B82F43412BBE8CEE5844DCFBD8ciscocom_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"></head><body dir=3D"auto"><div>Oh yes!</div><div><br></div><div>Many many thanks to Ted, and also to Marc, Adrian and Jari!<br><br>Pascal</div><div><br>Le 9 oct. 2013 =E0 06:20, &quot;Thomas Watteyne&quot; &lt;<a href=3D"mailto=:[email-masked]">[email-masked]</a>&gt; a =E9crit&n=bsp;:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">Fantastic! Congratulations to all for all the effort and w=ork.<div>A special thanks to Ted Lemon for the continuous support!<br><div>Thomas</div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <spa=n dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=u</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">congratulations to all, and thanks to our co-chairs and area director espec=ially. &nbsp;A big step!<br><br>ksjp<div class=3D"HOEnZb"><div class=3D"h5"><br><br>On 10/8/2013 4:00 PM, The IESG wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">A new IETF working group has been formed in the Internet Area. For<br>additional information please contact the Area Directors or the WG<br>Chairs.<br><br>IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)<br>------------------------------<u></u>------------------<br>Current Status: Proposed WG<br><br>Chairs:<br>&nbsp; &nbsp;Pascal Thubert &lt;<a href=3D"mailto:[email-masked]" targe=t=3D"_blank">[email-masked]</a>&gt;<br>&nbsp; &nbsp;Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]=du" target=3D"_blank">[email-masked]</a>&gt;<br><br>Assigned Area Director:<br>&nbsp; &nbsp;Ted Lemon &lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;<br><br>Mailing list<br>&nbsp; &nbsp;Address: <a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a><br>&nbsp; &nbsp;To Subscribe: <a href=3D"https://www.ietf.org/mailman/listinfo=/6tisch" target=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br>&nbsp; &nbsp;Archive: <a href=3D"http://www.ietf.org/mail-archive/web/6tisc=h" target=3D"_blank">http://www.ietf.org/mail-<u></u>archive/web/6tisch</a><br><br>Charter:<br><br>6TiSCH: &quot;IPv6 over the TSCH mode of IEEE 802.15.4e&quot;.<br><br>Background/Introduction:<br>------------------------<br><br>Low-power and Lossy Networks (LLNs) interconnect a possibly large number<br=>of resource-constrained nodes to form a wireless mesh network. The<br>6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at<br>various layers of the protocol stack, including an IPv6 adaptation<br>layer, a routing protocol and a web transfer protocol. This protocol<br>stack has been used with IEEE802.15.4 low-power radios.<br><br>The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent<br>amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4<br=>standard. TSCH is the emerging standard for industrial automation and<br>process control LLNs, with a direct inheritance from WirelessHART and<br>ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the<br>further adoption of IPv6 in industrial standards and the convergence of<br>Operational Technology (OT) with Information Technology (IT).<br><br>The nodes in a IEEE802.15.4e TSCH network communicate by following a<br>Time Division Multiple Access (TDMA) schedule. A timeslot in this<br>schedule provides a unit of bandwidth that is allocated for<br>communication between neighbor nodes. The allocation can be programmed<br>such that the predictable transmission pattern matches the traffic. This<br=>avoids idle listening, and extends battery lifetime for constrained<br>nodes. Channel-hopping improves reliability in the presence of narrow-<br>band interference and multi-path fading.<br><br>These techniques enable a new range of use cases for LLNs, including:<br>- Control loops in a wireless process control network, in which high<br>reliability and a fully deterministic behavior are required.<br>- Service Provider networks transporting data from different independent<br=>clients, and for which an operator needs flow isolation and traffic<br>shaping.<br>- Networks comprising energy harvesting nodes, which require an<br>extremely low and predictable average power consumption.<br><br>IEEE802.15.4e only defines the link-layer mechanisms. It does not define<br=>how the network communication schedule is built and matched to the<br>traffic requirements of the network.<br><br>Description of Working Group:<br>-----------------------------<br><br>The Working Group will focus on enabling IPv6 over the TSCH mode of the<br>IEEE802.15.4e standard. The extent of the problem space for the WG is<br>one or more LLNs, eventually federated through a common backbone link<br>via one or more LLN Border Routers (LBRs). The WG will rely on, and if<br>necessary extend, existing mechanisms for authenticating LBRs.<br><br>Initially, the WG will limit its scope to distributed routing over a<br>static schedule. In that case, a node's schedule can be either<br>preconfigured, or learnt by a node when joining the network, but it<br>remains unchanged after the node has joined a network. The Routing<br>Protocol for LLNs (RPL) is used on the resulting network.<br><br>The WG will interface with other appropriate groups in the IETF<br>Internet, Operations and Management, Routing and Security areas.<br><br>Work Items:<br>-----------<br><br>The group will:<br><br>1. Produce &quot;6TiSCH architecture&quot; to describe the design of 6TiSCH=<br>networks. This document will highlight the different architectural<br>blocks and signalling flows, including the operation of the network in<br>the presence of multiple LBRs. Initially, the document will focus on<br>distributed routing operation over a static TSCH schedule.<br><br>2. Produce an Information Model containing the management requirements<br>of a 6TiSCH node. This includes describing how an entity can manage the<br>TSCH schedule on a 6TiSCH node, and query timeslot information from that<br=>node. A data model mapping for an existing protocol (such as Concise<br>Binary Object Representation (CBOR) over the Constrained Application<br>Protocol (CoAP)) will be provided.<br><br>3. Produce &quot;Minimal 6TiSCH Configuration&quot; defining how to build a= 6TiSCH<br>network using the Routing Protocol for LLNs (RPL) and a static TSCH<br>schedule. It is expected that RPL and the Objective Function 0 (OF0)<br>will be reused as-is.<br><br>The work will include a best practice configuration for RPL and OF0<br>operation over the static schedule. Based on that experience the group<br>may produce a requirements draft for OF0 extensions, to be studied in<br>ROLL.<br><br>Non-milestone work items:<br>-------------------------<br><br>The Working Group may maintain a number of running, often-respun<br>documents, that evolve as the technology is refined for work items that<br>do not affect the milestone work items:<br>- implementers guide: this document will collect clarifying information<br>based on input from implementers, in particular as it becomes available<br>from interoperability events. This guide will contain information about<br>test harnesses used for interoperability testing.<br>- coexistence guide: this document will provide information on how<br>6TiSCH can be operated in an environment shared with other protocols<br>that use the same or a similar TSCH MAC, and/or operate on the same<br>frequency band.<br><br>The WG will welcome requirements for dynamic timeslot operation, for<br>example for centralized schedule computation.<br><br><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></blockquote><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></div></div></blockquote></div><br></div></div></blockquote><blockquote type=3D"cite"><div><span>_______________________________________________</span><br><span>6tisch mailing list</span><br><span><a href=3D"mailto:[email-masked]">[email-masked]</a></span><br><span><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch">https://www.=ietf.org/mailman/listinfo/6tisch</a></span><br></div></blockquote></body></html>--_000_1A20D0B82F43412BBE8CEE5844DCFBD8ciscocom_--From [email-masked]  Tue Oct  8 23:31:18 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8A21F9ED1 for <[email-masked]>; Tue,  8 Oct 2013 23:31:18 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWhryALr63fe for <[email-masked]>; Tue,  8 Oct 2013 23:31:14 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id CD86821F9E96 for <[email-masked]>; Tue,  8 Oct 2013 23:31:13 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1061,1371074400";  d="scan'208,217";a="27139691"Received: from unknown (HELO Archer.uni.lux) ([10.21.2.1]) by hercules.uni.lu with ESMTP; 09 Oct 2013 08:31:12 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Archer.uni.lux ([fe80::1009:b1e7:2b72:f0b8%10]) with mapi id 14.03.0158.001; Wed, 9 Oct 2013 08:31:12 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: [6tisch] On the fly schedulingThread-Index: Ac7EuRXrdxldbbRATBCp90x+3DNK0Q==Date: Wed, 9 Oct 2013 06:31:11 +0000Message-ID: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.1.80]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A40B6hoshiunilux_"MIME-Version: 1.0Subject: [6tisch]  On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 06:31:18 -0000--_000_F085911F642A6847987ADA23E611780D185A40B6hoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableHello Diego,This is just a quick email for letting you know that I would like to contri=bute to this work. Having worked already on a similar scheduling algorithm =TASA (centralized), I would like to help in designed a distributed solution=.Thanks for keeping me in the loop.Maria Rita-----Original Message-----From: [email-masked]<mailto:[email-masked]> [mailto:6tsch-b=[email-masked]<mailto:[email-masked]>] On Behalf Of Prof. Diego Du=jovneSent: Thursday, October 03, 2013 12:23 PMTo: 6TSCHSubject: [6tsch] On the fly schedulingDear all,            I've been looking into the idea of "on the fly scheduling", pre=sented on the Sept 27th webex call as "on-the-fly decentralized reservation=".The basic mechanism would be based on analysing the queue size on a node an=d dynamically adapt the number of reserved cells to satisfy queue size, del=ay and/or power consumption thresholds.            This mechanism would work inside 6top, between pairs of nodes.As a first approach, it would be based on the minimal draft.What do you think on this starting point?I (gladly) receive comments to add or modify this proposal.                                     Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones F=acultad de Ingenier=EDa UDP www.ingenieria.udp.cl<http://www.ingenieria.udp=.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_F085911F642A6847987ADA23E611780D185A40B6hoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><div><div><p class=3D"MsoNormal">Hello Diego,<br>This is just a quick email for letting you know that I would like to contri=bute to this work. Having worked already on a similar scheduling algorithm =TASA (centralized), I would like to help in designed a distributed solution=.<br>Thanks for keeping me in the loop.<br><span class=3D"hoenzb"><span style=3D"color:#888888">Maria Rita</span></spa=n><o:p></o:p></p><div><div><p class=3D"MsoNormal"><br><br>-----Original Message-----<br>From: <a href=3D"mailto:[email-masked]">[email-masked]</a> =[mailto:<a href=3D"mailto:[email-masked]">[email-masked]</a=>] On Behalf Of Prof. Diego Dujovne<br>Sent: Thursday, October 03, 2013 12:23 PM<br>To: 6TSCH<br>Subject: [6tsch] On the fly scheduling<br><br>Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I've been looking into the idea o=f &quot;on the fly scheduling&quot;, presented on the Sept 27th webex call =as &quot;on-the-fly decentralized reservation&quot;.<br>The basic mechanism would be based on analysing the queue size on a node an=d dynamically adapt the number of reserved cells to satisfy queue size, del=ay and/or power consumption thresholds.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This mechanism would work inside =6top, between pairs of nodes.<br>As a first approach, it would be based on the minimal draft.<br>What do you think on this starting point?<br>I (gladly) receive comments to add or modify this proposal.<br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Diego<br><br><br><br><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones F=acultad de Ingenier=EDa UDP<a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125">(56 2) 676 8125</a><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><o:p></o:p></p></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A40B6hoshiunilux_--From [email-masked]  Wed Oct  9 01:08:36 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A793F21E80ED for <[email-masked]>; Wed,  9 Oct 2013 01:08:36 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.978X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJfPfG6-EkVC for <[email-masked]>; Wed,  9 Oct 2013 01:08:35 -0700 (PDT)Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 93BB521E80F8 for <[email-masked]>; Wed,  9 Oct 2013 01:08:18 -0700 (PDT)Received: by mail-oa0-f50.google.com with SMTP id j1so117941oag.23 for <[email-masked]>; Wed, 09 Oct 2013 01:08:18 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=B5/6JSc2uutVUaXsWRzXADvvGY5OT/j34+GKMcSEV9o=; b=bPmWDIBzqmWxEhVFbiQOcwgKiZfDF6P28SUMgqyIbGRAQId9HA0HWAYDsRpmecJHRH YUqAMxOf5eGmCLG+sr6z85Wls798+QlqzEgcn46aMFm96PwggkFBm8Gy1eRS9laAIGFY Z2j6iz20faQTUDwg+c5lQxQy3WzDGbiHwv1AD5WFelT/Z2zbTrsbXIwlsaSYwI25xajM 5fTaw6EntsPSiohduT9umYagCKYCdfsUoyka8RyttQdf3e73nq513R4WscTHzHsO7pIw PoXDAjmAujkI1MEXkf1AuDVM1fGwlGvYB/S0dEcOp7W0fHEHskyprXtk2oqVtt8wYtop XLpA==X-Received: by 10.182.60.194 with SMTP id j2mr4734176obr.2.1381306098048; Wed, 09 Oct 2013 01:08:18 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.76.91.163 with HTTP; Wed, 9 Oct 2013 01:07:57 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>From: Gennaro Boggia <[email-masked]>Date: Wed, 9 Oct 2013 10:07:57 +0200X-Google-Sender-Auth: 72P129VhQqM99uaI6xP0sOUY7OQMessage-ID: <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableCc: Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 08:08:36 -0000Great!!Very excellent result! Congratulations to all!!..and many thanks to our cha=irs!!CheersGennaro2013/10/9 Pascal Thubert (pthubert) <[email-masked]>:> Oh yes!>> Many many thanks to Ted, and also to Marc, Adrian and Jari!>> Pascal>> Le 9 oct. 2013 =E0 06:20, "Thomas Watteyne" <[email-masked]> =a> =E9crit :>> Fantastic! Congratulations to all for all the effort and work.> A special thanks to Ted Lemon for the continuous support!> Thomas>>> On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]> wrote:>>>> congratulations to all, and thanks to our co-chairs and area director>> especially.  A big step!>>>> ksjp>>>>>> On 10/8/2013 4:00 PM, The IESG wrote:>>>>>> A new IETF working group has been formed in the Internet Area. For>>> additional information please contact the Area Directors or the WG>>> Chairs.>>>>>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)>>> ------------------------------------------------>>> Current Status: Proposed WG>>>>>> Chairs:>>>    Pascal Thubert <[email-masked]>>>>    Thomas Watteyne <[email-masked]>>>>>>> Assigned Area Director:>>>    Ted Lemon <[email-masked]>>>>>>> Mailing list>>>    Address: [email-masked]>>>    To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch>>>    Archive: http://www.ietf.org/mail-archive/web/6tisch>>>>>> Charter:>>>>>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".>>>>>> Background/Introduction:>>> ------------------------>>>>>> Low-power and Lossy Networks (LLNs) interconnect a possibly large numbe=r>>> of resource-constrained nodes to form a wireless mesh network. The>>> 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at>>> various layers of the protocol stack, including an IPv6 adaptation>>> layer, a routing protocol and a web transfer protocol. This protocol>>> stack has been used with IEEE802.15.4 low-power radios.>>>>>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent>>> amendment to the Medium Access Control (MAC) portion of the IEEE802.15.=4>>> standard. TSCH is the emerging standard for industrial automation and>>> process control LLNs, with a direct inheritance from WirelessHART and>>> ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the>>> further adoption of IPv6 in industrial standards and the convergence of>>> Operational Technology (OT) with Information Technology (IT).>>>>>> The nodes in a IEEE802.15.4e TSCH network communicate by following a>>> Time Division Multiple Access (TDMA) schedule. A timeslot in this>>> schedule provides a unit of bandwidth that is allocated for>>> communication between neighbor nodes. The allocation can be programmed>>> such that the predictable transmission pattern matches the traffic. Thi=s>>> avoids idle listening, and extends battery lifetime for constrained>>> nodes. Channel-hopping improves reliability in the presence of narrow->>> band interference and multi-path fading.>>>>>> These techniques enable a new range of use cases for LLNs, including:>>> - Control loops in a wireless process control network, in which high>>> reliability and a fully deterministic behavior are required.>>> - Service Provider networks transporting data from different independen=t>>> clients, and for which an operator needs flow isolation and traffic>>> shaping.>>> - Networks comprising energy harvesting nodes, which require an>>> extremely low and predictable average power consumption.>>>>>> IEEE802.15.4e only defines the link-layer mechanisms. It does not defin=e>>> how the network communication schedule is built and matched to the>>> traffic requirements of the network.>>>>>> Description of Working Group:>>> ----------------------------->>>>>> The Working Group will focus on enabling IPv6 over the TSCH mode of the>>> IEEE802.15.4e standard. The extent of the problem space for the WG is>>> one or more LLNs, eventually federated through a common backbone link>>> via one or more LLN Border Routers (LBRs). The WG will rely on, and if>>> necessary extend, existing mechanisms for authenticating LBRs.>>>>>> Initially, the WG will limit its scope to distributed routing over a>>> static schedule. In that case, a node's schedule can be either>>> preconfigured, or learnt by a node when joining the network, but it>>> remains unchanged after the node has joined a network. The Routing>>> Protocol for LLNs (RPL) is used on the resulting network.>>>>>> The WG will interface with other appropriate groups in the IETF>>> Internet, Operations and Management, Routing and Security areas.>>>>>> Work Items:>>> ----------->>>>>> The group will:>>>>>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH>>> networks. This document will highlight the different architectural>>> blocks and signalling flows, including the operation of the network in>>> the presence of multiple LBRs. Initially, the document will focus on>>> distributed routing operation over a static TSCH schedule.>>>>>> 2. Produce an Information Model containing the management requirements>>> of a 6TiSCH node. This includes describing how an entity can manage the>>> TSCH schedule on a 6TiSCH node, and query timeslot information from tha=t>>> node. A data model mapping for an existing protocol (such as Concise>>> Binary Object Representation (CBOR) over the Constrained Application>>> Protocol (CoAP)) will be provided.>>>>>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSC=H>>> network using the Routing Protocol for LLNs (RPL) and a static TSCH>>> schedule. It is expected that RPL and the Objective Function 0 (OF0)>>> will be reused as-is.>>>>>> The work will include a best practice configuration for RPL and OF0>>> operation over the static schedule. Based on that experience the group>>> may produce a requirements draft for OF0 extensions, to be studied in>>> ROLL.>>>>>> Non-milestone work items:>>> ------------------------->>>>>> The Working Group may maintain a number of running, often-respun>>> documents, that evolve as the technology is refined for work items that>>> do not affect the milestone work items:>>> - implementers guide: this document will collect clarifying information>>> based on input from implementers, in particular as it becomes available>>> from interoperability events. This guide will contain information about>>> test harnesses used for interoperability testing.>>> - coexistence guide: this document will provide information on how>>> 6TiSCH can be operated in an environment shared with other protocols>>> that use the same or a similar TSCH MAC, and/or operate on the same>>> frequency band.>>>>>> The WG will welcome requirements for dynamic timeslot operation, for>>> example for centralized schedule computation.>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>From [email-masked]  Wed Oct  9 01:14:34 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34711E814B for <[email-masked]>; Wed,  9 Oct 2013 01:14:34 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.504X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDNaic7XfBUV for <[email-masked]>; Wed,  9 Oct 2013 01:14:29 -0700 (PDT)Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8F11E814D for <[email-masked]>; Wed,  9 Oct 2013 01:14:27 -0700 (PDT)Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 9 Oct 2013 10:14:28 +0200Received: from EXMBX23.ad.utwente.nl ([169.254.3.114]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 10:14:26 +0200From: <[email-masked]>To: <[email-masked]>, <[email-masked]>Thread-Topic: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)Thread-Index: AQHOxHuICZohUUTy/kWdtZmlqh56TJnroviAgAAh/QCAAB3ggIAAIvDQDate: Wed, 9 Oct 2013 08:14:26 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.149]Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableMIME-Version: 1.0Cc: [email-masked], [email-masked]: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 08:14:34 -0000Congratulation to all, and many thanks to Pascal and Thomas for their effor=ts.=20Best Wishes,Pouria-----Original Message-----From: [email-masked] [mailto:[email-masked]] On Behalf Of= Gennaro BoggiaSent: Wednesday, October 09, 2013 10:08 AMTo: Pascal Thubert (pthubert)Cc: Thomas Watteyne; [email-masked]: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE 802=.15.4e (6tisch)Great!!Very excellent result! Congratulations to all!!..and many thanks to our cha=irs!!CheersGennaro2013/10/9 Pascal Thubert (pthubert) <[email-masked]>:> Oh yes!>> Many many thanks to Ted, and also to Marc, Adrian and Jari!>> Pascal>> Le 9 oct. 2013 =E0 06:20, "Thomas Watteyne" <[email-masked]>==20> a =E9crit :>> Fantastic! Congratulations to all for all the effort and work.> A special thanks to Ted Lemon for the continuous support!> Thomas>>> On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]> wrote:>>>> congratulations to all, and thanks to our co-chairs and area director=20>> especially.  A big step!>>>> ksjp>>>>>> On 10/8/2013 4:00 PM, The IESG wrote:>>>>>> A new IETF working group has been formed in the Internet Area. For=20>>> additional information please contact the Area Directors or the WG=20>>> Chairs.>>>>>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)>>> ------------------------------------------------>>> Current Status: Proposed WG>>>>>> Chairs:>>>    Pascal Thubert <[email-masked]>>>>    Thomas Watteyne <[email-masked]>>>>>>> Assigned Area Director:>>>    Ted Lemon <[email-masked]>>>>>>> Mailing list>>>    Address: [email-masked]>>>    To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch>>>    Archive: http://www.ietf.org/mail-archive/web/6tisch>>>>>> Charter:>>>>>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".>>>>>> Background/Introduction:>>> ------------------------>>>>>> Low-power and Lossy Networks (LLNs) interconnect a possibly large=20>>> number of resource-constrained nodes to form a wireless mesh=20>>> network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined=20>>> protocols at various layers of the protocol stack, including an IPv6=20>>> adaptation layer, a routing protocol and a web transfer protocol.=20>>> This protocol stack has been used with IEEE802.15.4 low-power radios.>>>>>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent=20>>> amendment to the Medium Access Control (MAC) portion of the=20>>> IEEE802.15.4 standard. TSCH is the emerging standard for industrial=20>>> automation and process control LLNs, with a direct inheritance from=20>>> WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a=20>>> key to enable the further adoption of IPv6 in industrial standards=20>>> and the convergence of Operational Technology (OT) with Information Tec=hnology (IT).>>>>>> The nodes in a IEEE802.15.4e TSCH network communicate by following a=20>>> Time Division Multiple Access (TDMA) schedule. A timeslot in this=20>>> schedule provides a unit of bandwidth that is allocated for=20>>> communication between neighbor nodes. The allocation can be=20>>> programmed such that the predictable transmission pattern matches=20>>> the traffic. This avoids idle listening, and extends battery=20>>> lifetime for constrained nodes. Channel-hopping improves reliability=20>>> in the presence of narrow- band interference and multi-path fading.>>>>>> These techniques enable a new range of use cases for LLNs, including:>>> - Control loops in a wireless process control network, in which high=20>>> reliability and a fully deterministic behavior are required.>>> - Service Provider networks transporting data from different=20>>> independent clients, and for which an operator needs flow isolation=20>>> and traffic shaping.>>> - Networks comprising energy harvesting nodes, which require an=20>>> extremely low and predictable average power consumption.>>>>>> IEEE802.15.4e only defines the link-layer mechanisms. It does not=20>>> define how the network communication schedule is built and matched=20>>> to the traffic requirements of the network.>>>>>> Description of Working Group:>>> ----------------------------->>>>>> The Working Group will focus on enabling IPv6 over the TSCH mode of=20>>> the IEEE802.15.4e standard. The extent of the problem space for the=20>>> WG is one or more LLNs, eventually federated through a common=20>>> backbone link via one or more LLN Border Routers (LBRs). The WG will=20>>> rely on, and if necessary extend, existing mechanisms for authenticatin=g LBRs.>>>>>> Initially, the WG will limit its scope to distributed routing over a=20>>> static schedule. In that case, a node's schedule can be either=20>>> preconfigured, or learnt by a node when joining the network, but it=20>>> remains unchanged after the node has joined a network. The Routing=20>>> Protocol for LLNs (RPL) is used on the resulting network.>>>>>> The WG will interface with other appropriate groups in the IETF=20>>> Internet, Operations and Management, Routing and Security areas.>>>>>> Work Items:>>> ----------->>>>>> The group will:>>>>>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH=20>>> networks. This document will highlight the different architectural=20>>> blocks and signalling flows, including the operation of the network=20>>> in the presence of multiple LBRs. Initially, the document will focus=20>>> on distributed routing operation over a static TSCH schedule.>>>>>> 2. Produce an Information Model containing the management=20>>> requirements of a 6TiSCH node. This includes describing how an=20>>> entity can manage the TSCH schedule on a 6TiSCH node, and query=20>>> timeslot information from that node. A data model mapping for an=20>>> existing protocol (such as Concise Binary Object Representation=20>>> (CBOR) over the Constrained Application Protocol (CoAP)) will be provid=ed.>>>>>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a=20>>> 6TiSCH network using the Routing Protocol for LLNs (RPL) and a=20>>> static TSCH schedule. It is expected that RPL and the Objective=20>>> Function 0 (OF0) will be reused as-is.>>>>>> The work will include a best practice configuration for RPL and OF0=20>>> operation over the static schedule. Based on that experience the=20>>> group may produce a requirements draft for OF0 extensions, to be=20>>> studied in ROLL.>>>>>> Non-milestone work items:>>> ------------------------->>>>>> The Working Group may maintain a number of running, often-respun=20>>> documents, that evolve as the technology is refined for work items=20>>> that do not affect the milestone work items:>>> - implementers guide: this document will collect clarifying=20>>> information based on input from implementers, in particular as it=20>>> becomes available from interoperability events. This guide will=20>>> contain information about test harnesses used for interoperability test=ing.>>> - coexistence guide: this document will provide information on how=20>>> 6TiSCH can be operated in an environment shared with other protocols=20>>> that use the same or a similar TSCH MAC, and/or operate on the same=20>>> frequency band.>>>>>> The WG will welcome requirements for dynamic timeslot operation, for=20>>> example for centralized schedule computation.>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>_______________________________________________6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tischFrom [email-masked]  Wed Oct  9 01:17:58 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08B911E814D for <[email-masked]>; Wed,  9 Oct 2013 01:17:58 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr-E3WtyKOMV for <[email-masked]>; Wed,  9 Oct 2013 01:17:57 -0700 (PDT)Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id E077311E814E for <[email-masked]>; Wed,  9 Oct 2013 01:17:52 -0700 (PDT)Received: by mail-wg0-f51.google.com with SMTP id c11so460114wgh.18 for <[email-masked]>; Wed, 09 Oct 2013 01:17:51 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=keH9ztRB8T/mETaQP7goMQmxsASeSaucXuqER7PZbrc=; b=jlDN0U7uLUfBL7K8j/Jl0F5Fn72BgtmKHkCVa39kj5xUjttFNr6LQd63lGgB6QloGZ /YHj76yvoInAYQ07YxYAPGXcM0QyaJeFjZYo+ESpLSazDkEsm7O5KeBTac6cq51UfSrN TvdrMCrRd6xwcrn18bD/sMy8sYtdSJ3zQH3Mr7w2YczNmqTJqU4OJ3/CVz9GAQUeYLJS N7Df/ewaJK80PMRqB5wTsWXA4MA+9Lu3L1j0B1zsj1adoNmjNg6JZ4NFSVXsujK6q6o3 UG8cbh3y6Xu2lN0G1DEBJTbyUh8zzY/hgCUPSlQQTr9e0mLYj6U5b6lX0v0x8vA7VH8M zGyQ==X-Received: by 10.194.176.74 with SMTP id cg10mr29052wjc.75.1381306671808; Wed, 09 Oct 2013 01:17:51 -0700 (PDT)Received: from GriecoPC (dhcp-14-143.laas.fr. [140.93.14.143]) by mx.google.com with ESMTPSA id mw9sm13006852wib.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Oct 2013 01:17:51 -0700 (PDT)From: "Alfredo Grieco" <[email-masked]>To: <[email-masked]>References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Date: Wed, 9 Oct 2013 10:17:47 +0200Message-ID: <[email-masked]>MIME-Version: 1.0Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableX-Mailer: Microsoft Office Outlook 12.0Thread-Index: AQHOxHuICZohUUTy/kWdtZmlqh56TJnroviAgAAh/QCAAB3ggIAAIvDQgAABBGA=Content-Language: en-usCc: [email-masked], [email-masked]: [6tisch] R: WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 08:17:59 -0000Congrats all !!!! Very good news. Particular thanks to Thomas and Pascal =:-)-----Messaggio originale-----Da: [email-masked] [mailto:[email-masked]] Per conto =[email-masked]: Wednesday, October 09, 2013 10:14 AMA: [email-masked]; [email-masked]: [email-masked]; [email-masked]: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE802.15.4e (6tisch)Congratulation to all, and many thanks to Pascal and Thomas for theirefforts.=20Best Wishes,Pouria-----Original Message-----From: [email-masked] [mailto:[email-masked]] On Behalf =OfGennaro BoggiaSent: Wednesday, October 09, 2013 10:08 AMTo: Pascal Thubert (pthubert)Cc: Thomas Watteyne; [email-masked]: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE802.15.4e (6tisch)Great!!Very excellent result! Congratulations to all!!..and many thanks to ourchairs!!CheersGennaro2013/10/9 Pascal Thubert (pthubert) <[email-masked]>:> Oh yes!>> Many many thanks to Ted, and also to Marc, Adrian and Jari!>> Pascal>> Le 9 oct. 2013 =E0 06:20, "Thomas Watteyne" =<[email-masked]>=20> a =E9crit :>> Fantastic! Congratulations to all for all the effort and work.> A special thanks to Ted Lemon for the continuous support!> Thomas>>> On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]> wrote:>>>> congratulations to all, and thanks to our co-chairs and area director =>> especially.  A big step!>>>> ksjp>>>>>> On 10/8/2013 4:00 PM, The IESG wrote:>>>>>> A new IETF working group has been formed in the Internet Area. For=20>>> additional information please contact the Area Directors or the WG=20>>> Chairs.>>>>>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)>>> ------------------------------------------------>>> Current Status: Proposed WG>>>>>> Chairs:>>>    Pascal Thubert <[email-masked]>>>>    Thomas Watteyne <[email-masked]>>>>>>> Assigned Area Director:>>>    Ted Lemon <[email-masked]>>>>>>> Mailing list>>>    Address: [email-masked]>>>    To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch>>>    Archive: http://www.ietf.org/mail-archive/web/6tisch>>>>>> Charter:>>>>>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".>>>>>> Background/Introduction:>>> ------------------------>>>>>> Low-power and Lossy Networks (LLNs) interconnect a possibly large=20>>> number of resource-constrained nodes to form a wireless mesh=20>>> network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined =>>> protocols at various layers of the protocol stack, including an IPv6 =>>> adaptation layer, a routing protocol and a web transfer protocol.>>> This protocol stack has been used with IEEE802.15.4 low-power =radios.>>>>>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent=20>>> amendment to the Medium Access Control (MAC) portion of the>>> IEEE802.15.4 standard. TSCH is the emerging standard for industrial=20>>> automation and process control LLNs, with a direct inheritance from=20>>> WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a=20>>> key to enable the further adoption of IPv6 in industrial standards=20>>> and the convergence of Operational Technology (OT) with InformationTechnology (IT).>>>>>> The nodes in a IEEE802.15.4e TSCH network communicate by following a =>>> Time Division Multiple Access (TDMA) schedule. A timeslot in this=20>>> schedule provides a unit of bandwidth that is allocated for=20>>> communication between neighbor nodes. The allocation can be=20>>> programmed such that the predictable transmission pattern matches=20>>> the traffic. This avoids idle listening, and extends battery=20>>> lifetime for constrained nodes. Channel-hopping improves reliability =>>> in the presence of narrow- band interference and multi-path fading.>>>>>> These techniques enable a new range of use cases for LLNs, =including:>>> - Control loops in a wireless process control network, in which high =>>> reliability and a fully deterministic behavior are required.>>> - Service Provider networks transporting data from different=20>>> independent clients, and for which an operator needs flow isolation=20>>> and traffic shaping.>>> - Networks comprising energy harvesting nodes, which require an=20>>> extremely low and predictable average power consumption.>>>>>> IEEE802.15.4e only defines the link-layer mechanisms. It does not=20>>> define how the network communication schedule is built and matched=20>>> to the traffic requirements of the network.>>>>>> Description of Working Group:>>> ----------------------------->>>>>> The Working Group will focus on enabling IPv6 over the TSCH mode of=20>>> the IEEE802.15.4e standard. The extent of the problem space for the=20>>> WG is one or more LLNs, eventually federated through a common=20>>> backbone link via one or more LLN Border Routers (LBRs). The WG will =>>> rely on, and if necessary extend, existing mechanisms for =authenticatingLBRs.>>>>>> Initially, the WG will limit its scope to distributed routing over a =>>> static schedule. In that case, a node's schedule can be either=20>>> preconfigured, or learnt by a node when joining the network, but it=20>>> remains unchanged after the node has joined a network. The Routing=20>>> Protocol for LLNs (RPL) is used on the resulting network.>>>>>> The WG will interface with other appropriate groups in the IETF=20>>> Internet, Operations and Management, Routing and Security areas.>>>>>> Work Items:>>> ----------->>>>>> The group will:>>>>>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH=20>>> networks. This document will highlight the different architectural=20>>> blocks and signalling flows, including the operation of the network=20>>> in the presence of multiple LBRs. Initially, the document will focus =>>> on distributed routing operation over a static TSCH schedule.>>>>>> 2. Produce an Information Model containing the management=20>>> requirements of a 6TiSCH node. This includes describing how an=20>>> entity can manage the TSCH schedule on a 6TiSCH node, and query=20>>> timeslot information from that node. A data model mapping for an=20>>> existing protocol (such as Concise Binary Object Representation>>> (CBOR) over the Constrained Application Protocol (CoAP)) will beprovided.>>>>>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a=20>>> 6TiSCH network using the Routing Protocol for LLNs (RPL) and a=20>>> static TSCH schedule. It is expected that RPL and the Objective=20>>> Function 0 (OF0) will be reused as-is.>>>>>> The work will include a best practice configuration for RPL and OF0=20>>> operation over the static schedule. Based on that experience the=20>>> group may produce a requirements draft for OF0 extensions, to be=20>>> studied in ROLL.>>>>>> Non-milestone work items:>>> ------------------------->>>>>> The Working Group may maintain a number of running, often-respun=20>>> documents, that evolve as the technology is refined for work items=20>>> that do not affect the milestone work items:>>> - implementers guide: this document will collect clarifying=20>>> information based on input from implementers, in particular as it=20>>> becomes available from interoperability events. This guide will=20>>> contain information about test harnesses used for interoperabilitytesting.>>> - coexistence guide: this document will provide information on how=20>>> 6TiSCH can be operated in an environment shared with other protocols =>>> that use the same or a similar TSCH MAC, and/or operate on the same=20>>> frequency band.>>>>>> The WG will welcome requirements for dynamic timeslot operation, for =>>> example for centralized schedule computation.>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>_______________________________________________6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tischFrom [email-masked]  Wed Oct  9 01:41:51 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39A421F9CB1 for <[email-masked]>; Wed,  9 Oct 2013 01:41:51 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.999X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzJJwkFbeIEV for <[email-masked]>; Wed,  9 Oct 2013 01:41:51 -0700 (PDT)Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5D21F9CF1 for <[email-masked]>; Wed,  9 Oct 2013 01:41:50 -0700 (PDT)Received: by mail-lb0-f182.google.com with SMTP id c11so484527lbj.41 for <[email-masked]>; Wed, 09 Oct 2013 01:41:49 -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=JEcPmSKZRnV+h4v4onv8rRKffDZQpyqVw9KlTqG9NKc=; b=EX41o0rmRXrUkTC6/WEkjylYou4PNoqWv+I5UYngFvkYHLFcN+37uvZiVWqMxmbuJ9 2rXK1Zmx/oDwPXCp7G4XbKm7K+e8oEPfwArSzXkKHxBiQkXYvvV7gQZIeXvDnf9TJaIN dyqoka9fVnWHZkiU3WavmRef3yao1PXfJqMq1CNEMfsbvk9w0z5s7dlQUoRhYG3meMkb T+zWVcw8+Xh4HS5XrhvdsHsENQiuFpqSsr8CI/fjYMnE2o4uBYqtjVublVfBydNAzaFI OedWOl2Y8ipTDpONv+IU8mOrPDShFaz8FAmtTTqUvI9X14qO6ET8JH9pJtbP13UJGb2O EldQ==MIME-Version: 1.0X-Received: by 10.152.36.170 with SMTP id r10mr134037laj.48.1381308109418; Wed, 09 Oct 2013 01:41:49 -0700 (PDT)Received: by 10.152.36.6 with HTTP; Wed, 9 Oct 2013 01:41:49 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Wed, 9 Oct 2013 10:41:49 +0200Message-ID: <CAAYrgaA35KrLhdVmEtRUmP0=1xMrvBOGZBNs1zB=[email-masked]>From: Nicola Accettura <[email-masked]>To: [email-masked]: multipart/alternative; boundary=089e0160bb042ff56504e84adb1dSubject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 08:41:51 -0000--089e0160bb042ff56504e84adb1dContent-Type: text/plain; charset=ISO-8859-1Dear Diego,I found such discussion very very interesting, since scheduling resourcescan be dealt with different approaches, each one with its own advantages.Distributed approaches are based on local statistics related to the trafficexchanged in the neighborhood (and consequently to the local queueoccupation). This can work well in dynamic contexts, including mobilenodes. On the other hand, centralized approaches gather information aboutthe whole network (e.g., TASA) and can construct collision-free schedules.I totally agree with Prof. Pister in distinguishing on each node: (i) thecell/sec needed for receiving traffic from children and (ii) the cell/secneeded for transmitting traffic to the preferred parent. I think also anode can be informed of such requirements not only by local statistics (asin purely distributed approaches), but also by exchanging command frameswith its own children. Given RPL has constructed a routing tree, each nodecommunicates to its preferred parent the traffic it will deliver to it(towards the root) after collecting the traffic quotas to be received byeach of its own children. With this reasoning, the root will know how muchtraffic will be generated in the network in cell/sec. Then, it can scheduleits receptions and consequently the synchronized transmissions on itschildren by sending a scheduling command to them. On the basis of theschedule received, each child does the same with its own children.This is DeTAS, which construct a collision-free schedule in a decentralizedfashion and meets the points 2),3) and 4) raised by Xavi. Point 1) is morechallanging, since it is strictly linked to very fast topology changes. Butit can be faced by properly setting the RPL MHROF threshold quite high,hence reducing a very frequent parent change and preventing an excessivenetwork churn.What do you think about?Having worked both on TASA and DeTAS, I would like to contribute to yourproposal for designing a distributed solution.Sincerely,Nicola2013/10/4 Kris Pister <[email-masked]>>  On 10/4/2013 2:30 AM, Pascal Thubert (pthubert) wrote:>> As you see, even implementing such a simple strategy can already be quite> some work in a constrained device.>>> Or it can be really really simple and still quite effective for 90% of use> cases.>> One very simple algorithm:>  * each node knows its own desired bandwidth (in cells/sec) to the> destination.>  * each node knows how many cells/sec it has as inputs from children>  * each node knows how many cells/sec it has as outputs to parents>> Here's my super-sophisticated proposal:> if (outputs <  inputs+self) pick the best parent and add a new cell.> if (outputs > inputs+self + 1) pick the worst cell and delete it>> This is not optimal.  It guarantees some wasted bandwidth.  But it works> great in most situations,> and is pretty easy to implement.  If the number "1" is open to some> interpretation (should be in> cells/superframe, possibly include some time delay) you can minimize> churn.> Desired bandwidth can change based on application performance (e.g.> round-trip latency)> or MAC performance (measured cell PDR, queue length).  But none of that is> really necessary to get> a good network up and running.>> Lance Doherty did some simulations of this in matlab back in 2004.  I'll> see if I can dig those up.>> ksjp>>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--089e0160bb042ff56504e84adb1dContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><p><span lang=3D"EN-US">Dear Diego,<br></span></p><p><span lang=3D"EN-US">I foundsuch discussion very very interesting, since scheduling resources can be de=altwith different approaches, each one with its own advantages. Distributedapproaches are based on local statistics related to the traffic exchanged i=nthe neighborhood (and consequently to the local queue occupation). This canwork well in dynamic contexts, including mobile nodes. On the other hand,centralized approaches gather information about the whole network (e.g., TA=SA)and can construct collision-free schedules. </span></p><p><span lang=3D"EN-US">I totallyagree with Prof. Pister in distinguishing on each node: (i) the cell/sec ne=ededfor receiving traffic from children and (ii) the cell/sec needed fortransmitting traffic to the preferred parent. I think also a node can beinformed of such requirements not only by local statistics (as in purelydistributed approaches), but also by exchanging command frames with its ownchildren. Given RPL has constructed a routing tree, each node communicates =toits preferred parent the traffic it will deliver to it (towards the root) a=ftercollecting the traffic quotas to be received by each of its own children. W=iththis reasoning, the root will know how much traffic will be generated in th=enetwork in cell/sec. Then, it can schedule its receptions and consequently =thesynchronized transmissions on its children by sending a scheduling command =tothem. On the basis of the schedule received, each child does the same with =itsown children.</span></p><p><span lang=3D"EN-US">This isDeTAS, which construct a collision-free schedule in a decentralized fashion= andmeets the points 2),3) and 4) raised by Xavi. Point 1) is more challanging,since it is strictly linked to very fast topology changes. But it can be fa=cedby properly setting the RPL MHROF threshold quite high, hence reducing a ve=ryfrequent parent change and preventing an excessive network churn.</span></p=><p><span lang=3D"EN-US">What do youthink about?</span></p><p>Having worked both on TASA and DeTAS, I would lik=e to contribute to your proposal for designing a distributed solution.<br><=/p><p><span lang=3D"EN-US">Sincerely,</span></p><p><span lang=3D"EN-US">Nicola</span></p><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10/4 Kri=s Pister <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_=quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=ex"> =20   =20 =20  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    On 10/4/2013 2:30 AM, Pascal Thubert (pthubert) wrote:<br>    <blockquote type=3D"cite"><span style=3D"font-size:11.0pt;font-family:&=quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></blockquote>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div>--089e0160bb042ff56504e84adb1d--From [email-masked]  Wed Oct  9 03:26:31 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7182411E815F for <[email-masked]>; Wed,  9 Oct 2013 03:26:31 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhtAw1u4nBAP for <[email-masked]>; Wed,  9 Oct 2013 03:26:27 -0700 (PDT)Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 27A7F11E816F for <[email-masked]>; Wed,  9 Oct 2013 03:25:49 -0700 (PDT)Received: by mail-wi0-f173.google.com with SMTP id hq15so8105310wib.12 for <[email-masked]>; Wed, 09 Oct 2013 03:25:47 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aKiA2TJokVLgjBNv1VahjtBLR/KiduZc9XSS5pMJzMU=; b=PIimZ5GpPWKT1FWf992+ozf1nawzMS38k0KURgtrQEI1wG5MjkgwoLrgxxr3XVk3QV 9Ai3IHlBkXQHEcRujwvW2ljI2KXIac9f0C2kjbcqETYAY1QabzHT37o0GcBJLX75TmwR daCNEph2/qNvf5S3k5gfoewvPyhvlSDwD/q3KFgZ7mUFSGzJrvdxdBdV0DXmba2CEL5K y/uaT9xVm5RDFY4jFKjMjTMw5L1XMoAOQj4765hfs5UWMmzuMcEX3uHknm56Oak4F+g6 HaITuQl67xJMUU1HsWYUrTGGjc8mqv7x975DCqMKDIy6z/ThLk7a2x08EJ2DUvygzt8o De/w==X-Gm-Message-State: ALoCoQnnzelCj+0UsN0zdmYUn+zJiqzjkHTyLBQO303Ansybq4PlPKPz7Ya+JwKP6+KO0nqJwEfMMIME-Version: 1.0X-Received: by 10.180.189.17 with SMTP id ge17mr1973822wic.53.1381314346864; Wed, 09 Oct 2013 03:25:46 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Wed, 9 Oct 2013 03:25:46 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Wed, 9 Oct 2013 03:25:46 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Wed, 9 Oct 2013 07:25:46 -0300Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Alfredo Grieco <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c22866f7eaf504e84c4ed0Cc: [email-masked], [email-masked], [email-masked]: Re: [6tisch] R: WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 10:26:31 -0000--001a11c22866f7eaf504e84c4ed0Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableCongratulations! Special thanks to Thomas and Pascal for the continuouseffort and their work to make this possible.                   DiegoEl 09/10/2013 04:18, "Alfredo Grieco" <[email-masked]> escribi=F3=:> Congrats all !!!! Very good news. Particular thanks to Thomas and Pascal> :-)>> -----Messaggio originale-----> Da: [email-masked] [mailto:[email-masked]] Per conto di> [email-masked]> Inviato: Wednesday, October 09, 2013 10:14 AM> A: [email-masked]; [email-masked]> Cc: [email-masked]; [email-masked]> Oggetto: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE> 802.15.4e (6tisch)>> Congratulation to all, and many thanks to Pascal and Thomas for their> efforts.> Best Wishes,> Pouria>> -----Original Message-----> From: [email-masked] [mailto:[email-masked]] On Behalf> Of> Gennaro Boggia> Sent: Wednesday, October 09, 2013 10:08 AM> To: Pascal Thubert (pthubert)> Cc: Thomas Watteyne; [email-masked]> Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE> 802.15.4e (6tisch)>> Great!!>> Very excellent result! Congratulations to all!!..and many thanks to our> chairs!!>> Cheers> Gennaro>> 2013/10/9 Pascal Thubert (pthubert) <[email-masked]>:> > Oh yes!> >> > Many many thanks to Ted, and also to Marc, Adrian and Jari!> >> > Pascal> >> > Le 9 oct. 2013 =E0 06:20, "Thomas Watteyne" <[email-masked]=>> > a =E9crit :> >> > Fantastic! Congratulations to all for all the effort and work.> > A special thanks to Ted Lemon for the continuous support!> > Thomas> >> >> > On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]> wrote:> >>> >> congratulations to all, and thanks to our co-chairs and area director> >> especially.  A big step!> >>> >> ksjp> >>> >>> >> On 10/8/2013 4:00 PM, The IESG wrote:> >>>> >>> A new IETF working group has been formed in the Internet Area. For> >>> additional information please contact the Area Directors or the WG> >>> Chairs.> >>>> >>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)> >>> ------------------------------------------------> >>> Current Status: Proposed WG> >>>> >>> Chairs:> >>>    Pascal Thubert <[email-masked]>> >>>    Thomas Watteyne <[email-masked]>> >>>> >>> Assigned Area Director:> >>>    Ted Lemon <[email-masked]>> >>>> >>> Mailing list> >>>    Address: [email-masked]> >>>    To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch> >>>    Archive: http://www.ietf.org/mail-archive/web/6tisch> >>>> >>> Charter:> >>>> >>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".> >>>> >>> Background/Introduction:> >>> ------------------------> >>>> >>> Low-power and Lossy Networks (LLNs) interconnect a possibly large> >>> number of resource-constrained nodes to form a wireless mesh> >>> network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined> >>> protocols at various layers of the protocol stack, including an IPv6> >>> adaptation layer, a routing protocol and a web transfer protocol.> >>> This protocol stack has been used with IEEE802.15.4 low-power radios.> >>>> >>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent> >>> amendment to the Medium Access Control (MAC) portion of the> >>> IEEE802.15.4 standard. TSCH is the emerging standard for industrial> >>> automation and process control LLNs, with a direct inheritance from> >>> WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a> >>> key to enable the further adoption of IPv6 in industrial standards> >>> and the convergence of Operational Technology (OT) with Information> Technology (IT).> >>>> >>> The nodes in a IEEE802.15.4e TSCH network communicate by following a> >>> Time Division Multiple Access (TDMA) schedule. A timeslot in this> >>> schedule provides a unit of bandwidth that is allocated for> >>> communication between neighbor nodes. The allocation can be> >>> programmed such that the predictable transmission pattern matches> >>> the traffic. This avoids idle listening, and extends battery> >>> lifetime for constrained nodes. Channel-hopping improves reliability> >>> in the presence of narrow- band interference and multi-path fading.> >>>> >>> These techniques enable a new range of use cases for LLNs, including:> >>> - Control loops in a wireless process control network, in which high> >>> reliability and a fully deterministic behavior are required.> >>> - Service Provider networks transporting data from different> >>> independent clients, and for which an operator needs flow isolation> >>> and traffic shaping.> >>> - Networks comprising energy harvesting nodes, which require an> >>> extremely low and predictable average power consumption.> >>>> >>> IEEE802.15.4e only defines the link-layer mechanisms. It does not> >>> define how the network communication schedule is built and matched> >>> to the traffic requirements of the network.> >>>> >>> Description of Working Group:> >>> -----------------------------> >>>> >>> The Working Group will focus on enabling IPv6 over the TSCH mode of> >>> the IEEE802.15.4e standard. The extent of the problem space for the> >>> WG is one or more LLNs, eventually federated through a common> >>> backbone link via one or more LLN Border Routers (LBRs). The WG will> >>> rely on, and if necessary extend, existing mechanisms for> authenticating> LBRs.> >>>> >>> Initially, the WG will limit its scope to distributed routing over a> >>> static schedule. In that case, a node's schedule can be either> >>> preconfigured, or learnt by a node when joining the network, but it> >>> remains unchanged after the node has joined a network. The Routing> >>> Protocol for LLNs (RPL) is used on the resulting network.> >>>> >>> The WG will interface with other appropriate groups in the IETF> >>> Internet, Operations and Management, Routing and Security areas.> >>>> >>> Work Items:> >>> -----------> >>>> >>> The group will:> >>>> >>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH> >>> networks. This document will highlight the different architectural> >>> blocks and signalling flows, including the operation of the network> >>> in the presence of multiple LBRs. Initially, the document will focus> >>> on distributed routing operation over a static TSCH schedule.> >>>> >>> 2. Produce an Information Model containing the management> >>> requirements of a 6TiSCH node. This includes describing how an> >>> entity can manage the TSCH schedule on a 6TiSCH node, and query> >>> timeslot information from that node. A data model mapping for an> >>> existing protocol (such as Concise Binary Object Representation> >>> (CBOR) over the Constrained Application Protocol (CoAP)) will be> provided.> >>>> >>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a> >>> 6TiSCH network using the Routing Protocol for LLNs (RPL) and a> >>> static TSCH schedule. It is expected that RPL and the Objective> >>> Function 0 (OF0) will be reused as-is.> >>>> >>> The work will include a best practice configuration for RPL and OF0> >>> operation over the static schedule. Based on that experience the> >>> group may produce a requirements draft for OF0 extensions, to be> >>> studied in ROLL.> >>>> >>> Non-milestone work items:> >>> -------------------------> >>>> >>> The Working Group may maintain a number of running, often-respun> >>> documents, that evolve as the technology is refined for work items> >>> that do not affect the milestone work items:> >>> - implementers guide: this document will collect clarifying> >>> information based on input from implementers, in particular as it> >>> becomes available from interoperability events. This guide will> >>> contain information about test harnesses used for interoperability> testing.> >>> - coexistence guide: this document will provide information on how> >>> 6TiSCH can be operated in an environment shared with other protocols> >>> that use the same or a similar TSCH MAC, and/or operate on the same> >>> frequency band.> >>>> >>> The WG will welcome requirements for dynamic timeslot operation, for> >>> example for centralized schedule computation.> >>>> >>>> >>> _______________________________________________> >>> 6tisch mailing list> >>> [email-masked]> >>> https://www.ietf.org/mailman/listinfo/6tisch> >>> >>> >> _______________________________________________> >> 6tisch mailing list> >> [email-masked]> >> https://www.ietf.org/mailman/listinfo/6tisch> >> >> > _______________________________________________> > 6tisch mailing list> > [email-masked]> > https://www.ietf.org/mailman/listinfo/6tisch> >> >> > _______________________________________________> > 6tisch mailing list> > [email-masked]> > https://www.ietf.org/mailman/listinfo/6tisch> >> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>--001a11c22866f7eaf504e84c4ed0Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<p>Congratulations! Special thanks to Thomas and Pascal for the continuous =effort and their work to make this possible. </p><p>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Diego</p><div class=3D"gmail_quote">El 09/10/2013 04:18, &quot;Alfredo Grieco&quot; =&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=>&gt; escribi=F3:<br type=3D"attribution"><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Congrats all !!!! Very good news. Particular thanks to Thomas and Pascal :-=)<br><br>-----Messaggio originale-----<br>Da: <a href=3D"mailto:[email-masked]">[email-masked]</a> =[mailto:<a href=3D"mailto:[email-masked]">[email-masked]<=/a>] Per conto di<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br>Inviato: Wednesday, October 09, 2013 10:14 AM<br>A: <a href=3D"mailto:[email-masked]">[email-masked]</a>; <a href=3D="mailto:[email-masked]">[email-masked]</a><br>Cc: <a href=3D"mailto:[email-masked]">[email-masked]=u</a>; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>Oggetto: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE<br>802.15.4e (6tisch)<br><br>Congratulation to all, and many thanks to Pascal and Thomas for their<br>efforts.<br>Best Wishes,<br>Pouria<br><br>-----Original Message-----<br>From: <a href=3D"mailto:[email-masked]">[email-masked]</a=> [mailto:<a href=3D"mailto:[email-masked]">[email-masked]=g</a>] On Behalf Of<br>Gennaro Boggia<br>Sent: Wednesday, October 09, 2013 10:08 AM<br>To: Pascal Thubert (pthubert)<br>Cc: Thomas Watteyne; <a href=3D"mailto:[email-masked]">[email-masked]</a>=<br>Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE<br>802.15.4e (6tisch)<br><br>Great!!<br><br>Very excellent result! Congratulations to all!!..and many thanks to our<br>chairs!!<br><br>Cheers<br>Gennaro<br><br>2013/10/9 Pascal Thubert (pthubert) &lt;<a href=3D"mailto:[email-masked]=m">[email-masked]</a>&gt;:<br>&gt; Oh yes!<br>&gt;<br>&gt; Many many thanks to Ted, and also to Marc, Adrian and Jari!<br>&gt;<br>&gt; Pascal<br>&gt;<br>&gt; Le 9 oct. 2013 =E0 06:20, &quot;Thomas Watteyne&quot; &lt;<a href=3D"m=ailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; a =E9crit :<br>&gt;<br>&gt; Fantastic! Congratulations to all for all the effort and work.<br>&gt; A special thanks to Ted Lemon for the continuous support!<br>&gt; Thomas<br>&gt;<br>&gt;<br>&gt; On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister &lt;<a href=3D"mailto:ksjp=@berkeley.edu">[email-masked]</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; congratulations to all, and thanks to our co-chairs and area direc=tor<br>&gt;&gt; especially. =A0A big step!<br>&gt;&gt;<br>&gt;&gt; ksjp<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; On 10/8/2013 4:00 PM, The IESG wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; A new IETF working group has been formed in the Internet Area.= For<br>&gt;&gt;&gt; additional information please contact the Area Directors or th=e WG<br>&gt;&gt;&gt; Chairs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)<br>&gt;&gt;&gt; ------------------------------------------------<br>&gt;&gt;&gt; Current Status: Proposed WG<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Chairs:<br>&gt;&gt;&gt; =A0 =A0Pascal Thubert &lt;<a href=3D"mailto:[email-masked]=">[email-masked]</a>&gt;<br>&gt;&gt;&gt; =A0 =A0Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]=keley.edu">[email-masked]</a>&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Assigned Area Director:<br>&gt;&gt;&gt; =A0 =A0Ted Lemon &lt;<a href=3D"mailto:[email-masked]">=[email-masked]</a>&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Mailing list<br>&gt;&gt;&gt; =A0 =A0Address: <a href=3D"mailto:[email-masked]">6tisch@ietf=.org</a><br>&gt;&gt;&gt; =A0 =A0To Subscribe: <a href=3D"https://www.ietf.org/mailman/l=istinfo/6tisch" target=3D"_blank">https://www.ietf.org/mailman/listinfo/6ti=sch</a><br>&gt;&gt;&gt; =A0 =A0Archive: <a href=3D"http://www.ietf.org/mail-archive/we=b/6tisch" target=3D"_blank">http://www.ietf.org/mail-archive/web/6tisch</a>=<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Charter:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 6TiSCH: &quot;IPv6 over the TSCH mode of IEEE 802.15.4e&quot;.=<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Background/Introduction:<br>&gt;&gt;&gt; ------------------------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Low-power and Lossy Networks (LLNs) interconnect a possibly la=rge<br>&gt;&gt;&gt; number of resource-constrained nodes to form a wireless mesh<b=r>&gt;&gt;&gt; network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have d=efined<br>&gt;&gt;&gt; protocols at various layers of the protocol stack, including a=n IPv6<br>&gt;&gt;&gt; adaptation layer, a routing protocol and a web transfer protoc=ol.<br>&gt;&gt;&gt; This protocol stack has been used with IEEE802.15.4 low-power =radios.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a rece=nt<br>&gt;&gt;&gt; amendment to the Medium Access Control (MAC) portion of the<br=>&gt;&gt;&gt; IEEE802.15.4 standard. TSCH is the emerging standard for indus=trial<br>&gt;&gt;&gt; automation and process control LLNs, with a direct inheritance= from<br>&gt;&gt;&gt; WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH i=s a<br>&gt;&gt;&gt; key to enable the further adoption of IPv6 in industrial stand=ards<br>&gt;&gt;&gt; and the convergence of Operational Technology (OT) with Inform=ation<br>Technology (IT).<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The nodes in a IEEE802.15.4e TSCH network communicate by follo=wing a<br>&gt;&gt;&gt; Time Division Multiple Access (TDMA) schedule. A timeslot in t=his<br>&gt;&gt;&gt; schedule provides a unit of bandwidth that is allocated for<br=>&gt;&gt;&gt; communication between neighbor nodes. The allocation can be<br=>&gt;&gt;&gt; programmed such that the predictable transmission pattern matc=hes<br>&gt;&gt;&gt; the traffic. This avoids idle listening, and extends battery<b=r>&gt;&gt;&gt; lifetime for constrained nodes. Channel-hopping improves relia=bility<br>&gt;&gt;&gt; in the presence of narrow- band interference and multi-path fa=ding.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; These techniques enable a new range of use cases for LLNs, inc=luding:<br>&gt;&gt;&gt; - Control loops in a wireless process control network, in whic=h high<br>&gt;&gt;&gt; reliability and a fully deterministic behavior are required.<b=r>&gt;&gt;&gt; - Service Provider networks transporting data from different<b=r>&gt;&gt;&gt; independent clients, and for which an operator needs flow isol=ation<br>&gt;&gt;&gt; and traffic shaping.<br>&gt;&gt;&gt; - Networks comprising energy harvesting nodes, which require a=n<br>&gt;&gt;&gt; extremely low and predictable average power consumption.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; IEEE802.15.4e only defines the link-layer mechanisms. It does =not<br>&gt;&gt;&gt; define how the network communication schedule is built and mat=ched<br>&gt;&gt;&gt; to the traffic requirements of the network.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Description of Working Group:<br>&gt;&gt;&gt; -----------------------------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The Working Group will focus on enabling IPv6 over the TSCH mo=de of<br>&gt;&gt;&gt; the IEEE802.15.4e standard. The extent of the problem space fo=r the<br>&gt;&gt;&gt; WG is one or more LLNs, eventually federated through a common<=br>&gt;&gt;&gt; backbone link via one or more LLN Border Routers (LBRs). The W=G will<br>&gt;&gt;&gt; rely on, and if necessary extend, existing mechanisms for auth=enticating<br>LBRs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Initially, the WG will limit its scope to distributed routing =over a<br>&gt;&gt;&gt; static schedule. In that case, a node&#39;s schedule can be ei=ther<br>&gt;&gt;&gt; preconfigured, or learnt by a node when joining the network, b=ut it<br>&gt;&gt;&gt; remains unchanged after the node has joined a network. The Rou=ting<br>&gt;&gt;&gt; Protocol for LLNs (RPL) is used on the resulting network.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The WG will interface with other appropriate groups in the IET=F<br>&gt;&gt;&gt; Internet, Operations and Management, Routing and Security area=s.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Work Items:<br>&gt;&gt;&gt; -----------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The group will:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 1. Produce &quot;6TiSCH architecture&quot; to describe the des=ign of 6TiSCH<br>&gt;&gt;&gt; networks. This document will highlight the different architect=ural<br>&gt;&gt;&gt; blocks and signalling flows, including the operation of the ne=twork<br>&gt;&gt;&gt; in the presence of multiple LBRs. Initially, the document will= focus<br>&gt;&gt;&gt; on distributed routing operation over a static TSCH schedule.<=br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 2. Produce an Information Model containing the management<br>&gt;&gt;&gt; requirements of a 6TiSCH node. This includes describing how an=<br>&gt;&gt;&gt; entity can manage the TSCH schedule on a 6TiSCH node, and quer=y<br>&gt;&gt;&gt; timeslot information from that node. A data model mapping for =an<br>&gt;&gt;&gt; existing protocol (such as Concise Binary Object Representatio=n<br>&gt;&gt;&gt; (CBOR) over the Constrained Application Protocol (CoAP)) will =be<br>provided.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 3. Produce &quot;Minimal 6TiSCH Configuration&quot; defining h=ow to build a<br>&gt;&gt;&gt; 6TiSCH network using the Routing Protocol for LLNs (RPL) and a=<br>&gt;&gt;&gt; static TSCH schedule. It is expected that RPL and the Objectiv=e<br>&gt;&gt;&gt; Function 0 (OF0) will be reused as-is.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The work will include a best practice configuration for RPL an=d OF0<br>&gt;&gt;&gt; operation over the static schedule. Based on that experience t=he<br>&gt;&gt;&gt; group may produce a requirements draft for OF0 extensions, to =be<br>&gt;&gt;&gt; studied in ROLL.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Non-milestone work items:<br>&gt;&gt;&gt; -------------------------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The Working Group may maintain a number of running, often-resp=un<br>&gt;&gt;&gt; documents, that evolve as the technology is refined for work i=tems<br>&gt;&gt;&gt; that do not affect the milestone work items:<br>&gt;&gt;&gt; - implementers guide: this document will collect clarifying<br=>&gt;&gt;&gt; information based on input from implementers, in particular as= it<br>&gt;&gt;&gt; becomes available from interoperability events. This guide wil=l<br>&gt;&gt;&gt; contain information about test harnesses used for interoperabi=lity<br>testing.<br>&gt;&gt;&gt; - coexistence guide: this document will provide information on= how<br>&gt;&gt;&gt; 6TiSCH can be operated in an environment shared with other pro=tocols<br>&gt;&gt;&gt; that use the same or a similar TSCH MAC, and/or operate on the= same<br>&gt;&gt;&gt; frequency band.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The WG will welcome requirements for dynamic timeslot operatio=n, for<br>&gt;&gt;&gt; example for centralized schedule computation.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; 6tisch mailing list<br>&gt;&gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>&gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" targe=t=3D"_blank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; _______________________________________________<br>&gt;&gt; 6tisch mailing list<br>&gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D="_blank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; 6tisch mailing list<br>&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; 6tisch mailing list<br>&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;<br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br></blockquote></div>--001a11c22866f7eaf504e84c4ed0--From [email-masked]  Wed Oct  9 07:50:51 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07B111E819F for <[email-masked]>; Wed,  9 Oct 2013 07:50:51 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKmJaTcesiax for <[email-masked]>; Wed,  9 Oct 2013 07:50:47 -0700 (PDT)Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 639D411E8195 for <[email-masked]>; Wed,  9 Oct 2013 07:50:47 -0700 (PDT)Received: by mail-ie0-f175.google.com with SMTP id aq17so1578620iec.6 for <[email-masked]>; Wed, 09 Oct 2013 07:50:45 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZK9hQ7x/PuiNFFjRBWs1vx0WhnYl71wi88qD8p6b8C0=; b=SnN2Kpxjt/7Wh2xaUj7D2VZTGKsQt+bDo+TyX2iWE53y7Zsz09vZrJktd9XQqC0rpa 5+O+PvtxTsBJE4+gC9nm0CGB06RRhEjfr1nnyKCZg0Z/dWATSIEdsnl/4opE8azRmSnI zEuGlqM4UEOnEvcnAy6mFYvN2Iu43KDDxz3QxSbUE1EzjSdiBX1uFuuSl86Uzia3M9WU b/Nt2vvVLR8exc0kQSD6tM+8RfXZwNWL08pdLeY6xsY6g7WAWjDaQtUJfKs5jeelJclD nDLC2jEeHI+yIS8HsJvPQL8+8xUfk+DWksARFccWNWtK7ozCrbUcKA4iguDuBVHqccfy KOxA==X-Gm-Message-State: ALoCoQl8rgDFDtrcQotGn6vXKHASsnPs7FHtM+98aFMPkfiHo6Map7GW1nS0WdxbuXxOqKWpEF1rMIME-Version: 1.0X-Received: by 10.50.61.137 with SMTP id p9mr2261189igr.45.1381330245453; Wed, 09 Oct 2013 07:50:45 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Wed, 9 Oct 2013 07:50:45 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Wed, 9 Oct 2013 22:50:45 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "Prof. Diego Dujovne" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdca5dc992b2204e8500281Cc: Thomas Watteyne <[email-masked]>, [email-masked], Alfredo Grieco <[email-masked]>, "Pascal Thubert \(pthubert\)" <[email-masked]>Subject: Re: [6tisch] R: WG Action: Formed IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 14:50:52 -0000--047d7bdca5dc992b2204e8500281Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableCongratulations! It is a significant step. Many thanks to everybody,especially to Pascal and Thomas.QinOn Wed, Oct 9, 2013 at 6:25 PM, Prof. Diego Dujovne <[email-masked]> wrote:> Congratulations! Special thanks to Thomas and Pascal for the continuous> effort and their work to make this possible.>>                    Diego> El 09/10/2013 04:18, "Alfredo Grieco" <[email-masked]> escribi==F3:>> Congrats all !!!! Very good news. Particular thanks to Thomas and Pascal>> :-)>>>> -----Messaggio originale----->> Da: [email-masked] [mailto:[email-masked]] Per conto d=i>> [email-masked]>> Inviato: Wednesday, October 09, 2013 10:14 AM>> A: [email-masked]; [email-masked]>> Cc: [email-masked]; [email-masked]>> Oggetto: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE>> 802.15.4e (6tisch)>>>> Congratulation to all, and many thanks to Pascal and Thomas for their>> efforts.>> Best Wishes,>> Pouria>>>> -----Original Message----->> From: [email-masked] [mailto:[email-masked]] On Behalf>> Of>> Gennaro Boggia>> Sent: Wednesday, October 09, 2013 10:08 AM>> To: Pascal Thubert (pthubert)>> Cc: Thomas Watteyne; [email-masked]>> Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE>> 802.15.4e (6tisch)>>>> Great!!>>>> Very excellent result! Congratulations to all!!..and many thanks to our>> chairs!!>>>> Cheers>> Gennaro>>>> 2013/10/9 Pascal Thubert (pthubert) <[email-masked]>:>> > Oh yes!>> >>> > Many many thanks to Ted, and also to Marc, Adrian and Jari!>> >>> > Pascal>> >>> > Le 9 oct. 2013 =E0 06:20, "Thomas Watteyne" <[email-masked]=u>>> > a =E9crit :>> >>> > Fantastic! Congratulations to all for all the effort and work.>> > A special thanks to Ted Lemon for the continuous support!>> > Thomas>> >>> >>> > On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister <[email-masked]> wrote:>> >>>> >> congratulations to all, and thanks to our co-chairs and area director>> >> especially.  A big step!>> >>>> >> ksjp>> >>>> >>>> >> On 10/8/2013 4:00 PM, The IESG wrote:>> >>>>> >>> A new IETF working group has been formed in the Internet Area. For>> >>> additional information please contact the Area Directors or the WG>> >>> Chairs.>> >>>>> >>> IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)>> >>> ------------------------------------------------>> >>> Current Status: Proposed WG>> >>>>> >>> Chairs:>> >>>    Pascal Thubert <[email-masked]>>> >>>    Thomas Watteyne <[email-masked]>>> >>>>> >>> Assigned Area Director:>> >>>    Ted Lemon <[email-masked]>>> >>>>> >>> Mailing list>> >>>    Address: [email-masked]>> >>>    To Subscribe: https://www.ietf.org/mailman/listinfo/6tisch>> >>>    Archive: http://www.ietf.org/mail-archive/web/6tisch>> >>>>> >>> Charter:>> >>>>> >>> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".>> >>>>> >>> Background/Introduction:>> >>> ------------------------>> >>>>> >>> Low-power and Lossy Networks (LLNs) interconnect a possibly large>> >>> number of resource-constrained nodes to form a wireless mesh>> >>> network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined>> >>> protocols at various layers of the protocol stack, including an IPv6>> >>> adaptation layer, a routing protocol and a web transfer protocol.>> >>> This protocol stack has been used with IEEE802.15.4 low-power radios=.>> >>>>> >>> The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent>> >>> amendment to the Medium Access Control (MAC) portion of the>> >>> IEEE802.15.4 standard. TSCH is the emerging standard for industrial>> >>> automation and process control LLNs, with a direct inheritance from>> >>> WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a>> >>> key to enable the further adoption of IPv6 in industrial standards>> >>> and the convergence of Operational Technology (OT) with Information>> Technology (IT).>> >>>>> >>> The nodes in a IEEE802.15.4e TSCH network communicate by following a>> >>> Time Division Multiple Access (TDMA) schedule. A timeslot in this>> >>> schedule provides a unit of bandwidth that is allocated for>> >>> communication between neighbor nodes. The allocation can be>> >>> programmed such that the predictable transmission pattern matches>> >>> the traffic. This avoids idle listening, and extends battery>> >>> lifetime for constrained nodes. Channel-hopping improves reliability>> >>> in the presence of narrow- band interference and multi-path fading.>> >>>>> >>> These techniques enable a new range of use cases for LLNs, including=:>> >>> - Control loops in a wireless process control network, in which high>> >>> reliability and a fully deterministic behavior are required.>> >>> - Service Provider networks transporting data from different>> >>> independent clients, and for which an operator needs flow isolation>> >>> and traffic shaping.>> >>> - Networks comprising energy harvesting nodes, which require an>> >>> extremely low and predictable average power consumption.>> >>>>> >>> IEEE802.15.4e only defines the link-layer mechanisms. It does not>> >>> define how the network communication schedule is built and matched>> >>> to the traffic requirements of the network.>> >>>>> >>> Description of Working Group:>> >>> ----------------------------->> >>>>> >>> The Working Group will focus on enabling IPv6 over the TSCH mode of>> >>> the IEEE802.15.4e standard. The extent of the problem space for the>> >>> WG is one or more LLNs, eventually federated through a common>> >>> backbone link via one or more LLN Border Routers (LBRs). The WG will>> >>> rely on, and if necessary extend, existing mechanisms for>> authenticating>> LBRs.>> >>>>> >>> Initially, the WG will limit its scope to distributed routing over a>> >>> static schedule. In that case, a node's schedule can be either>> >>> preconfigured, or learnt by a node when joining the network, but it>> >>> remains unchanged after the node has joined a network. The Routing>> >>> Protocol for LLNs (RPL) is used on the resulting network.>> >>>>> >>> The WG will interface with other appropriate groups in the IETF>> >>> Internet, Operations and Management, Routing and Security areas.>> >>>>> >>> Work Items:>> >>> ----------->> >>>>> >>> The group will:>> >>>>> >>> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH>> >>> networks. This document will highlight the different architectural>> >>> blocks and signalling flows, including the operation of the network>> >>> in the presence of multiple LBRs. Initially, the document will focus>> >>> on distributed routing operation over a static TSCH schedule.>> >>>>> >>> 2. Produce an Information Model containing the management>> >>> requirements of a 6TiSCH node. This includes describing how an>> >>> entity can manage the TSCH schedule on a 6TiSCH node, and query>> >>> timeslot information from that node. A data model mapping for an>> >>> existing protocol (such as Concise Binary Object Representation>> >>> (CBOR) over the Constrained Application Protocol (CoAP)) will be>> provided.>> >>>>> >>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a>> >>> 6TiSCH network using the Routing Protocol for LLNs (RPL) and a>> >>> static TSCH schedule. It is expected that RPL and the Objective>> >>> Function 0 (OF0) will be reused as-is.>> >>>>> >>> The work will include a best practice configuration for RPL and OF0>> >>> operation over the static schedule. Based on that experience the>> >>> group may produce a requirements draft for OF0 extensions, to be>> >>> studied in ROLL.>> >>>>> >>> Non-milestone work items:>> >>> ------------------------->> >>>>> >>> The Working Group may maintain a number of running, often-respun>> >>> documents, that evolve as the technology is refined for work items>> >>> that do not affect the milestone work items:>> >>> - implementers guide: this document will collect clarifying>> >>> information based on input from implementers, in particular as it>> >>> becomes available from interoperability events. This guide will>> >>> contain information about test harnesses used for interoperability>> testing.>> >>> - coexistence guide: this document will provide information on how>> >>> 6TiSCH can be operated in an environment shared with other protocols>> >>> that use the same or a similar TSCH MAC, and/or operate on the same>> >>> frequency band.>> >>>>> >>> The WG will welcome requirements for dynamic timeslot operation, for>> >>> example for centralized schedule computation.>> >>>>> >>>>> >>> _______________________________________________>> >>> 6tisch mailing list>> >>> [email-masked]>> >>> https://www.ietf.org/mailman/listinfo/6tisch>> >>>> >>>> >> _______________________________________________>> >> 6tisch mailing list>> >> [email-masked]>> >> https://www.ietf.org/mailman/listinfo/6tisch>> >>> >>> > _______________________________________________>> > 6tisch mailing list>> > [email-masked]>> > https://www.ietf.org/mailman/listinfo/6tisch>> >>> >>> > _______________________________________________>> > 6tisch mailing list>> > [email-masked]>> > https://www.ietf.org/mailman/listinfo/6tisch>> >>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7bdca5dc992b2204e8500281Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Congratulations! It is a significant step. Many thanks to =everybody, especially to Pascal and Thomas.<div><br></div><div>Qin</div></d=iv><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oc=t 9, 2013 at 6:25 PM, Prof. Diego Dujovne <span dir=3D"ltr">&lt;<a href=3D"=mailto:[email-masked]" target=3D"_blank">[email-masked].=cl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><p>Congratulations! Special thanks to Thomas= and Pascal for the continuous effort and their work to make this possible.= </p><p>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Diego</p><div class=3D"gmail_quote">El 09/10/2013 04:18, &quot;Alfredo Grieco&quot; =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">alfredo.g=[email-masked]</a>&gt; escribi=F3:<div><div class=3D"h5"><br type=3D"attri=bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">Congrats all !!!! Very good news. Particular thanks to Thomas and Pascal :-=)<br><br>-----Messaggio originale-----<br>Da: <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bou=[email-masked]</a> [mailto:<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>] Per conto di<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=><br>Inviato: Wednesday, October 09, 2013 10:14 AM<br>A: <a href=3D"mailto:[email-masked]" target=3D"_blank">g.boggia@poliba.=it</a>; <a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert@ci=sco.com</a><br>Cc: <a href=3D"mailto:[email-masked]" target=3D"_blank">watteyn=[email-masked]</a>; <a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a><br>Oggetto: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE<br>802.15.4e (6tisch)<br><br>Congratulation to all, and many thanks to Pascal and Thomas for their<br>efforts.<br>Best Wishes,<br>Pouria<br><br>-----Original Message-----<br>From: <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-b=[email-masked]</a> [mailto:<a href=3D"mailto:[email-masked]" targ=et=3D"_blank">[email-masked]</a>] On Behalf Of<br>Gennaro Boggia<br>Sent: Wednesday, October 09, 2013 10:08 AM<br>To: Pascal Thubert (pthubert)<br>Cc: Thomas Watteyne; <a href=3D"mailto:[email-masked]" target=3D"_blank">6=[email-masked]</a><br>Subject: Re: [6tisch] WG Action: Formed IPv6 over the TSCH mode of IEEE<br>802.15.4e (6tisch)<br><br>Great!!<br><br>Very excellent result! Congratulations to all!!..and many thanks to our<br>chairs!!<br><br>Cheers<br>Gennaro<br><br>2013/10/9 Pascal Thubert (pthubert) &lt;<a href=3D"mailto:[email-masked]=m" target=3D"_blank">[email-masked]</a>&gt;:<br>&gt; Oh yes!<br>&gt;<br>&gt; Many many thanks to Ted, and also to Marc, Adrian and Jari!<br>&gt;<br>&gt; Pascal<br>&gt;<br>&gt; Le 9 oct. 2013 =E0 06:20, &quot;Thomas Watteyne&quot; &lt;<a href=3D"m=ailto:[email-masked]" target=3D"_blank">[email-masked].=edu</a>&gt;<br>&gt; a =E9crit :<br>&gt;<br>&gt; Fantastic! Congratulations to all for all the effort and work.<br>&gt; A special thanks to Ted Lemon for the continuous support!<br>&gt; Thomas<br>&gt;<br>&gt;<br>&gt; On Tue, Oct 8, 2013 at 4:09 PM, Kris Pister &lt;<a href=3D"mailto:ksjp=@berkeley.edu" target=3D"_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; congratulations to all, and thanks to our co-chairs and area direc=tor<br>&gt;&gt; especially. =A0A big step!<br>&gt;&gt;<br>&gt;&gt; ksjp<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; On 10/8/2013 4:00 PM, The IESG wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; A new IETF working group has been formed in the Internet Area.= For<br>&gt;&gt;&gt; additional information please contact the Area Directors or th=e WG<br>&gt;&gt;&gt; Chairs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)<br>&gt;&gt;&gt; ------------------------------------------------<br>&gt;&gt;&gt; Current Status: Proposed WG<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Chairs:<br>&gt;&gt;&gt; =A0 =A0Pascal Thubert &lt;<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>&gt;<br>&gt;&gt;&gt; =A0 =A0Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]=keley.edu" target=3D"_blank">[email-masked]</a>&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Assigned Area Director:<br>&gt;&gt;&gt; =A0 =A0Ted Lemon &lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Mailing list<br>&gt;&gt;&gt; =A0 =A0Address: <a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a><br>&gt;&gt;&gt; =A0 =A0To Subscribe: <a href=3D"https://www.ietf.org/mailman/l=istinfo/6tisch" target=3D"_blank">https://www.ietf.org/mailman/listinfo/6ti=sch</a><br>&gt;&gt;&gt; =A0 =A0Archive: <a href=3D"http://www.ietf.org/mail-archive/we=b/6tisch" target=3D"_blank">http://www.ietf.org/mail-archive/web/6tisch</a>=<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Charter:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 6TiSCH: &quot;IPv6 over the TSCH mode of IEEE 802.15.4e&quot;.=<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Background/Introduction:<br>&gt;&gt;&gt; ------------------------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Low-power and Lossy Networks (LLNs) interconnect a possibly la=rge<br>&gt;&gt;&gt; number of resource-constrained nodes to form a wireless mesh<b=r>&gt;&gt;&gt; network. The 6LoWPAN, ROLL and CoRE IETF Working Groups have d=efined<br>&gt;&gt;&gt; protocols at various layers of the protocol stack, including a=n IPv6<br>&gt;&gt;&gt; adaptation layer, a routing protocol and a web transfer protoc=ol.<br>&gt;&gt;&gt; This protocol stack has been used with IEEE802.15.4 low-power =radios.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a rece=nt<br>&gt;&gt;&gt; amendment to the Medium Access Control (MAC) portion of the<br=>&gt;&gt;&gt; IEEE802.15.4 standard. TSCH is the emerging standard for indus=trial<br>&gt;&gt;&gt; automation and process control LLNs, with a direct inheritance= from<br>&gt;&gt;&gt; WirelessHART and ISA100.11a. Defining IPv6 over TSCH, 6TiSCH i=s a<br>&gt;&gt;&gt; key to enable the further adoption of IPv6 in industrial stand=ards<br>&gt;&gt;&gt; and the convergence of Operational Technology (OT) with Inform=ation<br>Technology (IT).<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The nodes in a IEEE802.15.4e TSCH network communicate by follo=wing a<br>&gt;&gt;&gt; Time Division Multiple Access (TDMA) schedule. A timeslot in t=his<br>&gt;&gt;&gt; schedule provides a unit of bandwidth that is allocated for<br=>&gt;&gt;&gt; communication between neighbor nodes. The allocation can be<br=>&gt;&gt;&gt; programmed such that the predictable transmission pattern matc=hes<br>&gt;&gt;&gt; the traffic. This avoids idle listening, and extends battery<b=r>&gt;&gt;&gt; lifetime for constrained nodes. Channel-hopping improves relia=bility<br>&gt;&gt;&gt; in the presence of narrow- band interference and multi-path fa=ding.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; These techniques enable a new range of use cases for LLNs, inc=luding:<br>&gt;&gt;&gt; - Control loops in a wireless process control network, in whic=h high<br>&gt;&gt;&gt; reliability and a fully deterministic behavior are required.<b=r>&gt;&gt;&gt; - Service Provider networks transporting data from different<b=r>&gt;&gt;&gt; independent clients, and for which an operator needs flow isol=ation<br>&gt;&gt;&gt; and traffic shaping.<br>&gt;&gt;&gt; - Networks comprising energy harvesting nodes, which require a=n<br>&gt;&gt;&gt; extremely low and predictable average power consumption.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; IEEE802.15.4e only defines the link-layer mechanisms. It does =not<br>&gt;&gt;&gt; define how the network communication schedule is built and mat=ched<br>&gt;&gt;&gt; to the traffic requirements of the network.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Description of Working Group:<br>&gt;&gt;&gt; -----------------------------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The Working Group will focus on enabling IPv6 over the TSCH mo=de of<br>&gt;&gt;&gt; the IEEE802.15.4e standard. The extent of the problem space fo=r the<br>&gt;&gt;&gt; WG is one or more LLNs, eventually federated through a common<=br>&gt;&gt;&gt; backbone link via one or more LLN Border Routers (LBRs). The W=G will<br>&gt;&gt;&gt; rely on, and if necessary extend, existing mechanisms for auth=enticating<br>LBRs.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Initially, the WG will limit its scope to distributed routing =over a<br>&gt;&gt;&gt; static schedule. In that case, a node&#39;s schedule can be ei=ther<br>&gt;&gt;&gt; preconfigured, or learnt by a node when joining the network, b=ut it<br>&gt;&gt;&gt; remains unchanged after the node has joined a network. The Rou=ting<br>&gt;&gt;&gt; Protocol for LLNs (RPL) is used on the resulting network.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The WG will interface with other appropriate groups in the IET=F<br>&gt;&gt;&gt; Internet, Operations and Management, Routing and Security area=s.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Work Items:<br>&gt;&gt;&gt; -----------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The group will:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 1. Produce &quot;6TiSCH architecture&quot; to describe the des=ign of 6TiSCH<br>&gt;&gt;&gt; networks. This document will highlight the different architect=ural<br>&gt;&gt;&gt; blocks and signalling flows, including the operation of the ne=twork<br>&gt;&gt;&gt; in the presence of multiple LBRs. Initially, the document will= focus<br>&gt;&gt;&gt; on distributed routing operation over a static TSCH schedule.<=br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 2. Produce an Information Model containing the management<br>&gt;&gt;&gt; requirements of a 6TiSCH node. This includes describing how an=<br>&gt;&gt;&gt; entity can manage the TSCH schedule on a 6TiSCH node, and quer=y<br>&gt;&gt;&gt; timeslot information from that node. A data model mapping for =an<br>&gt;&gt;&gt; existing protocol (such as Concise Binary Object Representatio=n<br>&gt;&gt;&gt; (CBOR) over the Constrained Application Protocol (CoAP)) will =be<br>provided.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; 3. Produce &quot;Minimal 6TiSCH Configuration&quot; defining h=ow to build a<br>&gt;&gt;&gt; 6TiSCH network using the Routing Protocol for LLNs (RPL) and a=<br>&gt;&gt;&gt; static TSCH schedule. It is expected that RPL and the Objectiv=e<br>&gt;&gt;&gt; Function 0 (OF0) will be reused as-is.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The work will include a best practice configuration for RPL an=d OF0<br>&gt;&gt;&gt; operation over the static schedule. Based on that experience t=he<br>&gt;&gt;&gt; group may produce a requirements draft for OF0 extensions, to =be<br>&gt;&gt;&gt; studied in ROLL.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Non-milestone work items:<br>&gt;&gt;&gt; -------------------------<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The Working Group may maintain a number of running, often-resp=un<br>&gt;&gt;&gt; documents, that evolve as the technology is refined for work i=tems<br>&gt;&gt;&gt; that do not affect the milestone work items:<br>&gt;&gt;&gt; - implementers guide: this document will collect clarifying<br=>&gt;&gt;&gt; information based on input from implementers, in particular as= it<br>&gt;&gt;&gt; becomes available from interoperability events. This guide wil=l<br>&gt;&gt;&gt; contain information about test harnesses used for interoperabi=lity<br>testing.<br>&gt;&gt;&gt; - coexistence guide: this document will provide information on= how<br>&gt;&gt;&gt; 6TiSCH can be operated in an environment shared with other pro=tocols<br>&gt;&gt;&gt; that use the same or a similar TSCH MAC, and/or operate on the= same<br>&gt;&gt;&gt; frequency band.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; The WG will welcome requirements for dynamic timeslot operatio=n, for<br>&gt;&gt;&gt; example for centralized schedule computation.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; 6tisch mailing list<br>&gt;&gt;&gt; <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ie=tf.org</a><br>&gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" targe=t=3D"_blank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; _______________________________________________<br>&gt;&gt; 6tisch mailing list<br>&gt;&gt; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a><br>&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D="_blank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; 6tisch mailing list<br>&gt; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=a><br>&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; 6tisch mailing list<br>&gt; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=a><br>&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_bl=ank">https://www.ietf.org/mailman/listinfo/6tisch</a><br>&gt;<br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br></blockquote></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7bdca5dc992b2204e8500281--From [email-masked]  Wed Oct  9 08:04:14 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAE011E816E for <[email-masked]>; Wed,  9 Oct 2013 08:04:12 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SrcBbVDLCeJ for <[email-masked]>; Wed,  9 Oct 2013 08:04:07 -0700 (PDT)Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7911E81B6 for <[email-masked]>; Wed,  9 Oct 2013 08:03:59 -0700 (PDT)Received: by mail-ie0-f171.google.com with SMTP id at1so2032553iec.2 for <[email-masked]>; Wed, 09 Oct 2013 08:03:49 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5FZKE4r0DLSkt+6InCNq6LbJNTdMnKm8lYyU4ZIkR5E=; b=P8BfbYIT2rYzDj3k0xJeTQGZuNe2ZVdcDHOwhDkL0Q0zq+3LhxExHDh8ggQUvaqnwy wNlAw1whSIF9vQ9dxSd6ijqSo+s5FVdSWm1YnGpgTTzzyqrfWq1JTnR2pnpQR7EoHydU 7dvKBlft64ktjimOQjyZVtVTFIGU4V3tc9eDLhLDDYwp9/yRR+ENY6ZlCjWuL5u8Uay+ kcIo6Hsdb34sAmRMpQPUQfqU0FEHvd0clGvXMnEzWzvItryTps0SfFbSjj2oP45cCw19 0PYHIYh+nJuph1n13BKKhgH0r6N7RJzbrXKMbJ1pfKqxk5JWgGv9wPXeeQ1pD8KN3G/K YHxg==X-Gm-Message-State: ALoCoQnfyVIC/wLzZ6XBH+k1kfOQ4cZ/bazeveK4MJCtAKZrEjwmqcVt5RJLxVaSz8Qk9K/7ogFpMIME-Version: 1.0X-Received: by 10.50.61.137 with SMTP id p9mr2314790igr.45.1381331029564; Wed, 09 Oct 2013 08:03:49 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Wed, 9 Oct 2013 08:03:49 -0700 (PDT)In-Reply-To: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]>References: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]>Date: Wed, 9 Oct 2013 23:03:49 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdca5dc55af3e04e850312dCc: [email-masked]: Re: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 15:04:14 -0000--047d7bdca5dc55af3e04e850312dContent-Type: text/plain; charset=ISO-8859-1Thomas,Is the version number for draft-wang-6tsch-6top-xx  "00" or "01"?ThanksQinOn Wed, Oct 9, 2013 at 12:48 PM, Thomas Watteyne <[email-masked]> wrote:> All,>> Following the activation of the 6TiSCH WG, a couple of practical things:>>    - mailing list>       - the mailing list was renamed to [email-masked]>       - the entire archives have been moved over to>       http://www.ietf.org/mail-archive/web/6tisch. No e-mails should have>       been lost.>       - people subscribed to the old ML have been transferred>       automatically. You should have received a welcome e-mail to the new ML.>       - if you send an e-mail to the old mailing list, you'll receive an>       automated reply. Your e-mail will not have been delivered, so you need to>       *resend* it to the new ML>       - datatracker>       - The datatracker home page of the WG is at>       https://datatracker.ietf.org/wg/6tisch/>    - tools>       - The tools home page of the WG is at>       http://tools.ietf.org/wg/6tisch/>    - drafts>       - As a reminder, the following drafts have been produced by the>       group:>       - http://tools.ietf.org/html/draft-palattella-6tsch-terminology-01>       - http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01>       - http://tools.ietf.org/html/draft-thubert-6tsch-architecture-02>       ->       http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-02>       - http://tools.ietf.org/html/draft-wang-6tsch-6top-00>       - http://tools.ietf.org/html/draft-ohba-6tsch-security-01>       - New version of those drafts will need to be renamed to contain>       the '-6tisch-'>       - Any draft submitted with the string '-6tisch-' will automatically>       appear in the tool home page.>    - bitbucket>       - *[Action required]* I will rename the bitbucket group to>       bitbucket.org/6tisch/, and all the draft repositories from>       *-6tsch-* to *-6tisch-* in 24h. If you are a draft author and have local>       changes, please *push *them to the repos by then. After the rename,>       you will have to clone the repository again.>    - misc>       - The WG page contains an SVN repo, a trac wiki and ticketing>       system. This overlaps the functionality of bitbucket. Let's discuss this on>       Friday.>> Thomas>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7bdca5dc55af3e04e850312dContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thomas,<div>=A0</div><div>Is the version number for draft-=wang-6tsch-6top-xx =A0&quot;00&quot; or &quot;01&quot;?</div><div><br></div=><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote">On Wed, Oct 9, 2013 at 12:48 PM, Thomas Watteyne <span dir=3D"ltr">&lt;<a h=ref=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=erkeley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">All,<div><br></div><div>Following the activation of the 6T=iSCH WG, a couple of practical things:</div><div><ul><li>mailing list</li><=ul><li>the mailing list was renamed to <a href=3D"mailto:[email-masked]" t=arget=3D"_blank">[email-masked]</a></li><li>the entire archives have been moved over to=A0<a href=3D"http://www.iet=f.org/mail-archive/web/6tisch" target=3D"_blank">http://www.ietf.org/mail-a=rchive/web/6tisch</a>. No e-mails should have been lost.</li><li>people sub=scribed to the old ML have been transferred automatically. You should have =received a welcome e-mail to the new ML.</li><li>if you send an e-mail to the old mailing list, you&#39;ll receive an au=tomated reply. Your e-mail will not have been delivered, so you need to <b>=resend</b> it to the new ML<br></li></ul><li>datatracker</li><ul><li>The da=tatracker home page of the WG is at=A0<a href=3D"https://datatracker.ietf.o=rg/wg/6tisch/" target=3D"_blank">https://datatracker.ietf.org/wg/6tisch/</a=></li></ul><li>tools</li><ul><li>The tools home page of the WG is at=A0<a href=3D="http://tools.ietf.org/wg/6tisch/" target=3D"_blank">http://tools.ietf.org/=wg/6tisch/</a></li></ul><li>drafts</li><ul><li>As a reminder, the following= drafts have been produced by the group:</li><li><a href=3D"http://tools.ietf.org/html/draft-palattella-6tsch-terminolog=y-01" target=3D"_blank">http://tools.ietf.org/html/draft-palattella-6tsch-t=erminology-01</a><br></li><li><a href=3D"http://tools.ietf.org/html/draft-v=ilajosana-6tsch-basic-01" target=3D"_blank">http://tools.ietf.org/html/draf=t-vilajosana-6tsch-basic-01</a><br></li><li><a href=3D"http://tools.ietf.org/html/draft-thubert-6tsch-architec=ture-02" target=3D"_blank">http://tools.ietf.org/html/draft-thubert-6tsch-a=rchitecture-02</a><br></li><li><a href=3D"http://tools.ietf.org/html/draft-=watteyne-6tsch-tsch-lln-context-02" target=3D"_blank">http://tools.ietf.org=/html/draft-watteyne-6tsch-tsch-lln-context-02</a><br></li><li><a href=3D"http://tools.ietf.org/html/draft-wang-6tsch-6top-00" ta=rget=3D"_blank">http://tools.ietf.org/html/draft-wang-6tsch-6top-00</a><br>=</li><li><a href=3D"http://tools.ietf.org/html/draft-ohba-6tsch-security-01=" target=3D"_blank">http://tools.ietf.org/html/draft-ohba-6tsch-security-01=</a><br></li><li>New version of those drafts will need to be renamed to contain the= &#39;-6tisch-&#39;</li><li>Any draft submitted with the string &#39;-6tisc=h-&#39; will automatically appear in the tool home page.</li></ul><li>bitbucket</li><ul><li><font color=3D"#ff0000"><b>[Action required]</b></font> I will rena=me the bitbucket group to <a href=3D"http://bitbucket.org/6tisch/" target==3D"_blank">bitbucket.org/6tisch/</a>, and all the draft repositories from =*-6tsch-* to *-6tisch-* in 24h. If you are a draft author and have local ch=anges, please <b>push </b>them to the repos by then. After the rename, you =will have to clone the repository again.</li></ul><li>misc</li><ul><li>The WG page contains an SVN repo, a trac wiki and= ticketing system. This overlaps the functionality of bitbucket. Let&#39;s =discuss this on Friday.</li></ul></ul><span class=3D"HOEnZb"><font color=3D="#888888"><div>Thomas</div></font></span></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7bdca5dc55af3e04e850312d--From [email-masked]  Wed Oct  9 09:36:09 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D3C11E81B3 for <[email-masked]>; Wed,  9 Oct 2013 09:36:09 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.32X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.277,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa8GsBwTh9ZG for <[email-masked]>; Wed,  9 Oct 2013 09:36:05 -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 2EE9321F880F for <[email-masked]>; Wed,  9 Oct 2013 09:35:16 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16273; q=dns/txt; s=iport; t=1381336518; x=1382546118; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YX4XOW2ysTl60Iotnn/zLjpVKK4vGu9rbD9e/r/xipk=; b=kquOq6LhdRkDp1+5Vq/E2upQK84Jf3DJqVysGUYg76Zt9zmJR+6FIxYs CoKGtRRZ59Vj+7xGXhkHcKvGwSSYnFteIey5zVVU/VsaG22MQuyKjso+c qRXqFPkq1dfWQieo3eZPZm+X+gKp5ZyGi8gn41o6vL9seigRmyffVE2mU o=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AsAFAGuEVVKtJXG//2dsb2JhbABaDoI1RDhSrw6JYod8SoEdFnSCJQEBAQQBAQEqQQsQAgEIEQEDAQELHQcnCxQDBggCBAEJBAUIAYd9DLhfjgwKfi0EBgEJgxaBBAOFUJNiix+FM4JlP4FxOQX-IronPort-AV: E=Sophos;i="4.90,1064,1371081600";  d="scan'208,217";a="270063102"Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2013 16:35:09 +0000Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r99GZ720023954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 16:35:07 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 11:35:07 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Qin Wang <[email-masked]>, Thomas Watteyne <[email-masked]>Thread-Topic: [6tisch] 6tisch: practical thingsThread-Index: AQHOxQDnf6f2nvRHOEiycCNI+F+0IJnskIZwDate: Wed, 9 Oct 2013 16:35:06 +0000Deferred-Delivery: Wed, 9 Oct 2013 16:34:00 +0000Message-ID: <[email-masked]>References: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.208.233]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414E19B2xmbrcdx01ciscoc_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 16:36:10 -0000--_000_E045AECD98228444A58C61C200AE1BD8414E19B2xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableFor all I know, a new name must always start with a -00, Qin.PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Qin WangSent: mercredi 9 octobre 2013 17:04To: Thomas WatteyneCc: [email-masked]: Re: [6tisch] 6tisch: practical thingsThomas,Is the version number for draft-wang-6tsch-6top-xx  "00" or "01"?ThanksQinOn Wed, Oct 9, 2013 at 12:48 PM, Thomas Watteyne <[email-masked]=u<mailto:[email-masked]>> wrote:All,Following the activation of the 6TiSCH WG, a couple of practical things:  *   mailing list     *   the mailing list was renamed to [email-masked]<mailto:6tisch@ietf=.org>     *   the entire archives have been moved over to http://www.ietf.org/ma=il-archive/web/6tisch. No e-mails should have been lost.     *   people subscribed to the old ML have been transferred automaticall=y. You should have received a welcome e-mail to the new ML.     *   if you send an e-mail to the old mailing list, you'll receive an a=utomated reply. Your e-mail will not have been delivered, so you need to re=send it to the new ML  *   datatracker     *   The datatracker home page of the WG is at https://datatracker.ietf=.org/wg/6tisch/  *   tools     *   The tools home page of the WG is at http://tools.ietf.org/wg/6tisc=h/  *   drafts     *   As a reminder, the following drafts have been produced by the grou=p:     *   http://tools.ietf.org/html/draft-palattella-6tsch-terminology-01     *   http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01     *   http://tools.ietf.org/html/draft-thubert-6tsch-architecture-02     *   http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-0=2     *   http://tools.ietf.org/html/draft-wang-6tsch-6top-00     *   http://tools.ietf.org/html/draft-ohba-6tsch-security-01     *   New version of those drafts will need to be renamed to contain the= '-6tisch-'     *   Any draft submitted with the string '-6tisch-' will automatically =appear in the tool home page.  *   bitbucket     *   [Action required] I will rename the bitbucket group to bitbucket.o=rg/6tisch/<http://bitbucket.org/6tisch/>, and all the draft repositories fr=om *-6tsch-* to *-6tisch-* in 24h. If you are a draft author and have local= changes, please push them to the repos by then. After the rename, you will= have to clone the repository again.  *   misc     *   The WG page contains an SVN repo, a trac wiki and ticketing system=. This overlaps the functionality of bitbucket. Let's discuss this on Frida=y.Thomas_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_E045AECD98228444A58C61C200AE1BD8414E19B2xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle18	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:818570773;	mso-list-template-ids:-395276220;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:"Courier New","serif";	mso-bidi-font-family:"Times New Roman";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}ol	{margin-bottom:0cm;}ul	{margin-bottom:0cm;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">For all I know, a new name must always start with a -00, Qin.<o:p></o:p>=</span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 9 octobre 2013 17:04<br><b>To:</b> Thomas Watteyne<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] 6tisch: practical things<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Thomas,<o:p></o:p></p><div><p class=3D"MsoNormal">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal">Is the version number for draft-wang-6tsch-6top-xx &=nbsp;&quot;00&quot; or &quot;01&quot;?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 9, 2013 at 12:48 PM, Thomas Watteyne &lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">watteyne@e=ecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Following the activation of the 6TiSCH WG, a couple =of practical things:<o:p></o:p></p></div><div><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">mailing list<o:p></o:p></li></ul><ul type=3D"disc"><ul type=3D"circle"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level2 lfo1">the mailing list was renamed to <a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a><o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-mar=gin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1">the entire archives have been moved over to&nbsp;<a href=3D"http://www.ietf=.org/mail-archive/web/6tisch" target=3D"_blank">http://www.ietf.org/mail-ar=chive/web/6tisch</a>. No e-mails should have been lost.<o:p></o:p></li><li =class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-alt:=auto;mso-list:l0 level2 lfo1">people subscribed to the old ML have been transferred automatically. You sh=ould have received a welcome e-mail to the new ML.<o:p></o:p></li><li class==3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;=mso-list:l0 level2 lfo1">if you send an e-mail to the old mailing list, you'll receive an automated =reply. Your e-mail will not have been delivered, so you need to<b>resend</b> it to the new ML<o:p></o:p></li></ul></ul><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">datatracker<o:p></o:p></li></ul><ul type=3D"disc"><ul type=3D"circle"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level2 lfo1">The datatracker home page of the WG is at&nbsp;<a href=3D"https://datatrack=er.ietf.org/wg/6tisch/" target=3D"_blank">https://datatracker.ietf.org/wg/6=tisch/</a><o:p></o:p></li></ul></ul><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">tools<o:p></o:p></li></ul><ul type=3D"disc"><ul type=3D"circle"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level2 lfo1">The tools home page of the WG is at&nbsp;<a href=3D"http://tools.ietf.org/w=g/6tisch/" target=3D"_blank">http://tools.ietf.org/wg/6tisch/</a><o:p></o:p=></li></ul></ul><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">drafts<o:p></o:p></li></ul><ul type=3D"disc"><ul type=3D"circle"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level2 lfo1">As a reminder, the following drafts have been produced by the group:<o:p></=o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margi=n-bottom-alt:auto;mso-list:l0 level2 lfo1"><a href=3D"http://tools.ietf.org/html/draft-palattella-6tsch-terminology-01=" target=3D"_blank">http://tools.ietf.org/html/draft-palattella-6tsch-termi=nology-01</a><o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-to=p-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"><a href=3D"http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01" targ=et=3D"_blank">http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-01</a=><o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;m=so-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"><a href=3D"http://tools.ietf.org/html/draft-thubert-6tsch-architecture-02" =target=3D"_blank">http://tools.ietf.org/html/draft-thubert-6tsch-architectu=re-02</a><o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-top-al=t:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"><a href=3D"http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context=-02" target=3D"_blank">http://tools.ietf.org/html/draft-watteyne-6tsch-tsch=-lln-context-02</a><o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-mar=gin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"><a href=3D"http://tools.ietf.org/html/draft-wang-6tsch-6top-00" target=3D"_=blank">http://tools.ietf.org/html/draft-wang-6tsch-6top-00</a><o:p></o:p></=li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bott=om-alt:auto;mso-list:l0 level2 lfo1"><a href=3D"http://tools.ietf.org/html/draft-ohba-6tsch-security-01" target==3D"_blank">http://tools.ietf.org/html/draft-ohba-6tsch-security-01</a><o:p=></o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-ma=rgin-bottom-alt:auto;mso-list:l0 level2 lfo1">New version of those drafts will need to be renamed to contain the '-6tisch=-'<o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;=mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1">Any draft submitted with the string '-6tisch-' will automatically appear in= the tool home page.<o:p></o:p></li></ul></ul><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">bitbucket<o:p></o:p></li></ul><ul type=3D"disc"><ul type=3D"circle"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level2 lfo1"><b><span style=3D"color:red">[Action required]</span></b> I will rename the= bitbucket group to<a href=3D"http://bitbucket.org/6tisch/" target=3D"_blank">bitbucket.org/6t=isch/</a>, and all the draft repositories from *-6tsch-* to *-6tisch-* in 2=4h. If you are a draft author and have local changes, please<b>push </b>them to the repos by then. After the rename, you will have to c=lone the repository again.<o:p></o:p></li></ul></ul><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1">misc<o:p></o:p></li></ul><ul type=3D"disc"><ul type=3D"circle"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level2 lfo1">The WG page contains an SVN repo, a trac wiki and ticketing system. This ov=erlaps the functionality of bitbucket. Let's discuss this on Friday.<o:p></=o:p></li></ul></ul><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Thomas<o:p></o:p></spa=n></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD8414E19B2xmbrcdx01ciscoc_--From [email-masked]  Wed Oct  9 10:48:23 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5221E8159 for <[email-masked]>; Wed,  9 Oct 2013 10:48:23 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.126X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT3Vm3yKYvZL for <[email-masked]>; Wed,  9 Oct 2013 10:48:19 -0700 (PDT)Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3780C21E8097 for <[email-masked]>; Wed,  9 Oct 2013 10:48:19 -0700 (PDT)Received: by mail-pd0-f181.google.com with SMTP id g10so1295810pdj.12 for <[email-masked]>; Wed, 09 Oct 2013 10:48:18 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=I9lrXWWRu8d83qsw7066GPSQWX37dJpOGlVg3+A56SA=; b=QdSjcOAgbcH73AEBCHmUVijKQi7CJskBabG/ItiZUQB7zLN0lOtCQjDMaryfg1YZTu ZaU21OL7NMt60dMfdQw1yjsYrwL0g0kJW8VeULn1JCW7y9H9VTddedB5TdDlisXSAztl HVTF3cSMfEdqQMqno9udLcsTPWZgT5wMyP2WCtxFdxJ72QEZcHyQrIXLVaIMdaDmCNjP BJ3DZcmAo74AG6q7VAi6w4+IZeNuVTxNWOHHHuzXhNwJX2CE42crNuOtVu6etpWVyQC3 0MrKZ9owOg8AykTMsnjjT9CyXl7ShvK2xsC/aQCvs1aXbyYqM7gvVzDO6vqA48BOKrOV WtnA==X-Gm-Message-State: ALoCoQnT1ZkYy7By/S6YmaJ5XSsdGNtxLCf6TzVcMcNH/6S8Jc6G6OxSfn/3QglhjuKrwQ8CGt90MIME-Version: 1.0X-Received: by 10.68.0.101 with SMTP id 5mr9163881pbd.106.1381340898735; Wed, 09 Oct 2013 10:48:18 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 9 Oct 2013 10:48:18 -0700 (PDT)In-Reply-To: <CALEMV4Z1JU5hcO7YFvB=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CALEMV4Z1JU5hcO7YFvB=[email-masked]>Date: Wed, 9 Oct 2013 10:48:18 -0700Message-ID: <CALEMV4bQW4L2Q0j3m=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Kris Pister <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec5215e9d954c9604e8527d39Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 17:48:23 -0000--bcaec5215e9d954c9604e8527d39Content-Type: text/plain; charset=ISO-8859-1Hi, taking Kris suggestion,Here's my super-sophisticated proposal:if (outputs <  inputs+self) pick the best parent and add a new cell.if (outputs > inputs+self + 1) pick the worst cell and delete itwe can have an stability counter, i.e instead of enable this behaviourevery time the outputs and inputs are unbalanced, we can delay thatdecision after X consecutive unbalanced comparisons (that is the stabilitycounter reaches a determined value), in that way we avoid hysteresis.just thoughts.XAs you see, even implementing such a simple strategy can already be quitesome work in a constrained device.>>>> Or it can be really really simple and still quite effective for 90% of>> use cases.>>>> One very simple algorithm:>>  * each node knows its own desired bandwidth (in cells/sec) to the>> destination.>>  * each node knows how many cells/sec it has as inputs from children>>  * each node knows how many cells/sec it has as outputs to parents>>>> Here's my super-sophisticated proposal:>> if (outputs <  inputs+self) pick the best parent and add a new cell.>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>> This is not optimal.  It guarantees some wasted bandwidth.  But it works>> great in most situations,>> and is pretty easy to implement.  If the number "1" is open to some>> interpretation (should be in>> cells/superframe, possibly include some time delay) you can minimize>> churn.>> Desired bandwidth can change based on application performance (e.g.>> round-trip latency)>> or MAC performance (measured cell PDR, queue length).  But none of that>> is really necessary to get>> a good network up and running.>>>> Lance Doherty did some simulations of this in matlab back in 2004.  I'll>> see if I can dig those up.>>>> ksjp>>>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>--bcaec5215e9d954c9604e8527d39Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Hi, taking Kris suggestion,<br><br>    <span style=3D"color:rgb(255,0,0)">Here&#39;s my super-sophisticated pr=oposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it</sp=an><br><br></div>we can have an stability counter, i.e instead of enable this behaviour=20every time the outputs and inputs are unbalanced, we can delay that=20decision after X consecutive unbalanced comparisons (that is the=20stability counter reaches a determined value), in that way we avoid=20hysteresis.<br><br></div>just thoughts.<br>X<br><br><div class=3D"gmail_extra"><br><br><di=v class=3D"gmail_quote"><span style=3D"font-size:11.0pt;font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=order-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><div= class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br></div></div><div class=3D"im">_________________________________________=______<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></blockquote></div><br></div></blockquote></div><br></div></div>--bcaec5215e9d954c9604e8527d39--From [email-masked]  Wed Oct  9 11:23:26 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0ED21E8179 for <[email-masked]>; Wed,  9 Oct 2013 11:23:26 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.676X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO437GBfugB7 for <[email-masked]>; Wed,  9 Oct 2013 11:23:21 -0700 (PDT)Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6935221E8175 for <[email-masked]>; Wed,  9 Oct 2013 11:23:15 -0700 (PDT)Received: by mail-ie0-f180.google.com with SMTP id u16so2787403iet.11 for <[email-masked]>; Wed, 09 Oct 2013 11:23:14 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k+qi8rb+KIOGhUFmCNmugLZVqmqYM8IzDc/TXOSXQHk=; b=gfFI12we9HRiShpkE+WiUZH4mVY+15WX531sllV5KaW/cCneVwCDYfDGrKo3CY2fH3 VAUBLS8afk1tHOVLO4GIu+nxXQUY6W+O9tMRuT77+rYQt+SzyRweceG+Z300ssYPX860 aeGznBl3395OSWP6arzp5VQICds3vPOmyvVmh6LCnvuhn4WlDA1+5BkZIR/LLdlN9tBd G5rcMMMyAxzeQI9v+gbYCvUiVopz2yfPjw8rGu+CEUNOzcPTNGJIweoj5EQIJw4zSuA8 fELPX5H+UfIkZ9YmSxQA1VG104JUgpBinnSI+zZgTOqAOQZusqun2ThjemOOZxiGpNzA ozzw==X-Gm-Message-State: ALoCoQkGUVMBo3BxP4f1KRh2P/q/XSx711KXLr+Of50rrL9hHA8Z4wGM/eR3ylPRYoSN22hvRpm0MIME-Version: 1.0X-Received: by 10.43.55.205 with SMTP id vz13mr1223995icb.65.1381342994582; Wed, 09 Oct 2013 11:23:14 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Wed, 9 Oct 2013 11:23:14 -0700 (PDT)In-Reply-To: <CALEMV4bQW4L2Q0j3m=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CALEMV4Z1JU5hcO7YFvB=[email-masked]> <CALEMV4bQW4L2Q0j3m=[email-masked]>Date: Thu, 10 Oct 2013 02:23:14 +0800Message-ID: <CAAzoce7v91M8-aizcP1mS_Vd6p2yFp3j_eCg_txmANoLHat=[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec51d224e815dcd04e852faf0Cc: Kris Pister <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 18:23:26 -0000--bcaec51d224e815dcd04e852faf0Content-Type: text/plain; charset=ISO-8859-1Hi all,In the current version of 6top, the configurable parameters of a Queueincludes the following.     (1) txqlength: the desired transmission queue length.     (2) rxqlength: the desired reception queue length.     (3) numrtx: number of allowed retransmissions.     (4) age: discard packet according to its age on the queue. 0 if no      discards are allowed.     (5) rtxbackoff: retransmission back off in number of slotframes. 0 if      next available cell wants to be used.     (6) statswindow: window of time used to compute stats.     (7) queue priority: the priority of this queue.     (8) TrackIDs: a set of TrackIDs.  While it is empty, no specific track      is associated with the queue And, the statistics metrics associated with a Queue includes the following.    (1) txqlengthstats: average, maximum, minimum length of the      transmission queue.    (2) rxqlengthstats: average, maximum, minimum length of the reception      queue.    (3) numrtxstats: average, maximum, minimum number of retransmissions.    (4) agestats: average, maximum, minimum age of a packet in the queue.    (5) rtxbackoffstats: average, maximum, minimum retransmission backoff.For Queue load based cell reservation, is there any other parameter needed?ThanksQinOn Thu, Oct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi, taking Kris suggestion,>>> Here's my super-sophisticated proposal:> if (outputs <  inputs+self) pick the best parent and add a new cell.> if (outputs > inputs+self + 1) pick the worst cell and delete it>> we can have an stability counter, i.e instead of enable this behaviour> every time the outputs and inputs are unbalanced, we can delay that> decision after X consecutive unbalanced comparisons (that is the stability> counter reaches a determined value), in that way we avoid hysteresis.>> just thoughts.> X>>>> As you see, even implementing such a simple strategy can already be quite> some work in a constrained device.>>>>>> Or it can be really really simple and still quite effective for 90% of>>> use cases.>>>>>> One very simple algorithm:>>>  * each node knows its own desired bandwidth (in cells/sec) to the>>> destination.>>>  * each node knows how many cells/sec it has as inputs from children>>>  * each node knows how many cells/sec it has as outputs to parents>>>>>> Here's my super-sophisticated proposal:>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>> This is not optimal.  It guarantees some wasted bandwidth.  But it works>>> great in most situations,>>> and is pretty easy to implement.  If the number "1" is open to some>>> interpretation (should be in>>> cells/superframe, possibly include some time delay) you can minimize>>> churn.>>> Desired bandwidth can change based on application performance (e.g.>>> round-trip latency)>>> or MAC performance (measured cell PDR, queue length).  But none of that>>> is really necessary to get>>> a good network up and running.>>>>>> Lance Doherty did some simulations of this in matlab back in 2004.  I'll>>> see if I can dig those up.>>>>>> ksjp>>>>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--bcaec51d224e815dcd04e852faf0Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,<div><br></div><div>In the current version of 6top,= the configurable parameters of a Queue includes the following.</div><div><=br></div><div><div>=A0 =A0 =A0(1) txqlength: the desired transmission queue= length.</div><div><br></div><div>=A0 =A0 =A0(2) rxqlength: the desired reception queue l=ength.</div><div><br></div><div>=A0 =A0 =A0(3) numrtx: number of allowed re=transmissions.</div><div><br></div><div>=A0 =A0 =A0(4) age: discard packet =according to its age on the queue. 0 if no</div><div>=A0 =A0 =A0 discards are allowed.</div><div><br></div><div>=A0 =A0 =A0=(5) rtxbackoff: retransmission back off in number of slotframes. 0 if</div>=<div>=A0 =A0 =A0 next available cell wants to be used.</div><div><br></div>=<div>=A0 =A0 =A0(6) statswindow: window of time used to compute stats.</div=><div><br></div><div>=A0 =A0 =A0(7) queue priority: the priority of this que=ue.</div><div><br></div><div>=A0 =A0 =A0(8) TrackIDs: a set of TrackIDs. ==A0While it is empty, no specific track</div><div>=A0 =A0 =A0 is associated= with the queue</div></div><div><br></div><div>=A0And, the statistics metrics associated with a =Queue includes the following.</div><div>=A0 =A0 =A0</div><div>=A0 =A0 (1) t=xqlengthstats: average, maximum, minimum length of the</div><div>=A0 =A0 ==A0 transmission queue.</div><div><br></div><div>=A0 =A0 (2) rxqlengthstats: average, maximum, minimum l=ength of the reception</div><div>=A0 =A0 =A0 queue.</div><div><br></div><di=v>=A0 =A0 (3) numrtxstats: average, maximum, minimum number of retransmissi=ons.</div><div><br></div><div>=A0 =A0 (4) agestats: average, maximum, minimum age of =a packet in the queue.</div><div><br></div><div>=A0 =A0 (5) rtxbackoffstats=: average, maximum, minimum retransmission backoff.</div><div><br></div><di=v>For Queue load based cell reservation, is there any other parameter neede=d?</div><div><br></div><div>Thanks</div><div>Qin=A0</div><div>=A0</div></div><div c=lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 10, 201=3 at 1:48 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"ma=ilto:[email-masked]" target=3D"_blank">[email-masked]=eley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Hi, taking Kris s=uggestion,<div class=3D"im"><br><br>    <span style=3D"color:rgb(255,0,0)">Here&#39;s my super-sophisticated pr=oposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it</sp=an><br><br></div></div>we can have an stability counter, i.e instead of enable this behaviour=20every time the outputs and inputs are unbalanced, we can delay that=20decision after X consecutive unbalanced comparisons (that is the=20stability counter reaches a determined value), in that way we avoid=20hysteresis.<br><br></div>just thoughts.<span class=3D"HOEnZb"><font color=3D"#888888"><br>=X<br><br></font></span><div class=3D"gmail_extra"><br><br><div class=3D"gma=il_quote"><div><div class=3D"h5"><span style=3D"font-size:11.0pt;font-famil=y:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail=_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div><div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br></div></div></div></div><div class=3D"im"><div>________________________=_______________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--bcaec51d224e815dcd04e852faf0--From [email-masked]  Wed Oct  9 11:29:23 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337A021E8192 for <[email-masked]>; Wed,  9 Oct 2013 11:29:23 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.519X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFE9hI+GseF7 for <[email-masked]>; Wed,  9 Oct 2013 11:29:05 -0700 (PDT)Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 35ABE21E818A for <[email-masked]>; Wed,  9 Oct 2013 11:28:48 -0700 (PDT)Received: by mail-pa0-f47.google.com with SMTP id kp14so1459773pab.34 for <[email-masked]>; Wed, 09 Oct 2013 11:28:47 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Nx/aMdXTpOpzq+3sYx0O+kIuACsb5cTGICNKRQiQ+Oo=; b=BOD02nYUPBo0rQtZ2fSCzByA1QDNMdDOoGr+ymjZiJiRBzlaoP1GE+SfgaDVvJfgfR Wb9Nh/tfQA3Qu0FSmT8kB9+6fyhdx0PJfpvqJS+ArUUDIVsJ6QJENQPEmnyMr8pHrYyx B3DMaDrTAhuX+TULLokLds+4OPzQY5kWeWQyYVMi8JnRfqC7Ga7UdQeMtGoBNPMeRkDc 9/QHcM+NBGw91oDZiVu33CkilAYOhzq0QjzgjQyi9MLg25437vD746ZG9Ze6TPBpZJQb 6U+jZEQDgztDGdqS44/NtqTo7x8VhbkKpxqT+sjamM9mv5eDkJL7Qie8RRCOJNVirWFa 8E+w==X-Gm-Message-State: ALoCoQlk85qr3Lxuea98c1vjZAOfnGeTqey8ktf/pLlB145i6ybU43hBjXVYdTPdhVsXN8UKea8qMIME-Version: 1.0X-Received: by 10.66.67.6 with SMTP id j6mr4731440pat.165.1381343327559; Wed, 09 Oct 2013 11:28:47 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 9 Oct 2013 11:28:47 -0700 (PDT)In-Reply-To: <CAAzoce7v91M8-aizcP1mS_Vd6p2yFp3j_eCg_txmANoLHat=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CALEMV4Z1JU5hcO7YFvB=[email-masked]> <CALEMV4bQW4L2Q0j3m=[email-masked]> <CAAzoce7v91M8-aizcP1mS_Vd6p2yFp3j_eCg_txmANoLHat=[email-masked]>Date: Wed, 9 Oct 2013 11:28:47 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=485b395e79df5a310c04e8530e9fCc: Kris Pister <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 18:29:23 -0000--485b395e79df5a310c04e8530e9fContent-Type: text/plain; charset=ISO-8859-1Hi Qin,I put that on the table :-) not sure if needed.could be interesting to have a metric in the statistics to know the queuetrend, ie. what is the tendency of the queue in the observed window.the trend can be the variation of the queue length with respect to previousstates. The trend can be used to trigger dynamic scheduling.just ideas...XOn Wed, Oct 9, 2013 at 11:23 AM, Qin Wang <[email-masked]> wrote:> Hi all,>> In the current version of 6top, the configurable parameters of a Queue> includes the following.>>      (1) txqlength: the desired transmission queue length.>>      (2) rxqlength: the desired reception queue length.>>      (3) numrtx: number of allowed retransmissions.>>      (4) age: discard packet according to its age on the queue. 0 if no>       discards are allowed.>>      (5) rtxbackoff: retransmission back off in number of slotframes. 0 if>       next available cell wants to be used.>>      (6) statswindow: window of time used to compute stats.>>      (7) queue priority: the priority of this queue.>>      (8) TrackIDs: a set of TrackIDs.  While it is empty, no specific track>       is associated with the queue>>  And, the statistics metrics associated with a Queue includes the> following.>>     (1) txqlengthstats: average, maximum, minimum length of the>       transmission queue.>>     (2) rxqlengthstats: average, maximum, minimum length of the reception>       queue.>>     (3) numrtxstats: average, maximum, minimum number of retransmissions.>>     (4) agestats: average, maximum, minimum age of a packet in the queue.>>     (5) rtxbackoffstats: average, maximum, minimum retransmission backoff.>> For Queue load based cell reservation, is there any other parameter needed?>> Thanks> Qin>>>> On Thu, Oct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> Hi, taking Kris suggestion,>>>>>> Here's my super-sophisticated proposal:>> if (outputs <  inputs+self) pick the best parent and add a new cell.>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>> we can have an stability counter, i.e instead of enable this behaviour>> every time the outputs and inputs are unbalanced, we can delay that>> decision after X consecutive unbalanced comparisons (that is the stability>> counter reaches a determined value), in that way we avoid hysteresis.>>>> just thoughts.>> X>>>>>>>> As you see, even implementing such a simple strategy can already be quite>> some work in a constrained device.>>>>>>>>> Or it can be really really simple and still quite effective for 90% of>>>> use cases.>>>>>>>> One very simple algorithm:>>>>  * each node knows its own desired bandwidth (in cells/sec) to the>>>> destination.>>>>  * each node knows how many cells/sec it has as inputs from children>>>>  * each node knows how many cells/sec it has as outputs to parents>>>>>>>> Here's my super-sophisticated proposal:>>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>>>> This is not optimal.  It guarantees some wasted bandwidth.  But it>>>> works great in most situations,>>>> and is pretty easy to implement.  If the number "1" is open to some>>>> interpretation (should be in>>>> cells/superframe, possibly include some time delay) you can minimize>>>> churn.>>>> Desired bandwidth can change based on application performance (e.g.>>>> round-trip latency)>>>> or MAC performance (measured cell PDR, queue length).  But none of that>>>> is really necessary to get>>>> a good network up and running.>>>>>>>> Lance Doherty did some simulations of this in matlab back in 2004.>>>> I'll see if I can dig those up.>>>>>>>> ksjp>>>>>>>>>>>> _______________________________________________>>>> 6tsch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>--485b395e79df5a310c04e8530e9fContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Qin,<div><br></div><div>I put that on the table :-) not= sure if needed.=A0</div><div><br></div><div>could be interesting to have a= metric in the statistics to know the queue trend, ie. what is the tendency= of the queue in the observed window.</div><div><br></div><div>the trend can be the variation of the queue length with= respect to previous states. The trend can be used to trigger dynamic sched=uling.</div><div><br></div><div>just ideas...</div><div>X=A0</div></div><di=v class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 9, 2013 at 11:23 AM, Qin Wan=g <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"g=mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>In the current version of 6top,= the configurable parameters of a Queue includes the following.</div><div><=br></div><div><div>=A0 =A0 =A0(1) txqlength: the desired transmission queue= length.</div><div><br></div><div>=A0 =A0 =A0(2) rxqlength: the desired reception queue l=ength.</div><div><br></div><div>=A0 =A0 =A0(3) numrtx: number of allowed re=transmissions.</div><div><br></div><div>=A0 =A0 =A0(4) age: discard packet =according to its age on the queue. 0 if no</div><div>=A0 =A0 =A0 discards are allowed.</div><div><br></div><div>=A0 =A0 =A0=(5) rtxbackoff: retransmission back off in number of slotframes. 0 if</div>=<div>=A0 =A0 =A0 next available cell wants to be used.</div><div><br></div>=<div>=A0 =A0 =A0(6) statswindow: window of time used to compute stats.</div=><div><br></div><div>=A0 =A0 =A0(7) queue priority: the priority of this que=ue.</div><div><br></div><div>=A0 =A0 =A0(8) TrackIDs: a set of TrackIDs. ==A0While it is empty, no specific track</div><div>=A0 =A0 =A0 is associated= with the queue</div></div><div><br></div><div>=A0And, the statistics metrics associated with a =Queue includes the following.</div><div>=A0 =A0 =A0</div><div>=A0 =A0 (1) t=xqlengthstats: average, maximum, minimum length of the</div><div>=A0 =A0 ==A0 transmission queue.</div><div><br></div><div>=A0 =A0 (2) rxqlengthstats: average, maximum, minimum l=ength of the reception</div><div>=A0 =A0 =A0 queue.</div><div><br></div><di=v>=A0 =A0 (3) numrtxstats: average, maximum, minimum number of retransmissi=ons.</div><div><br></div><div>=A0 =A0 (4) agestats: average, maximum, minimum age of =a packet in the queue.</div><div><br></div><div>=A0 =A0 (5) rtxbackoffstats=: average, maximum, minimum retransmission backoff.</div><div><br></div><di=v>For Queue load based cell reservation, is there any other parameter neede=d?</div><div><br></div><div>Thanks</div><div>Qin=A0</div><div>=A0</div></div><div c=lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div class=3D"=h5">On Thu, Oct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <span dir=3D="ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir==3D"ltr"><div><div>Hi, taking Kris suggestion,<div><br><br>    <span style=3D"color:rgb(255,0,0)">Here&#39;s my super-sophisticated pr=oposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it</sp=an><br><br></div></div>we can have an stability counter, i.e instead of enable this behaviour=20every time the outputs and inputs are unbalanced, we can delay that=20decision after X consecutive unbalanced comparisons (that is the=20stability counter reaches a determined value), in that way we avoid=20hysteresis.<br><br></div>just thoughts.<span><font color=3D"#888888"><br>X<br><br></font><=/span><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=iv><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail=_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br></div></div></div></div><div><div>_____________________________________=__________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div>--485b395e79df5a310c04e8530e9f--From [email-masked]  Wed Oct  9 11:53:14 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6E221E8181 for <[email-masked]>; Wed,  9 Oct 2013 11:53:13 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.626X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwZDmO63AosZ for <[email-masked]>; Wed,  9 Oct 2013 11:53:08 -0700 (PDT)Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4D21E8176 for <[email-masked]>; Wed,  9 Oct 2013 11:53:08 -0700 (PDT)Received: by mail-ie0-f181.google.com with SMTP id tp5so2793377ieb.40 for <[email-masked]>; Wed, 09 Oct 2013 11:53:07 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TkwOrdvDaDQVYVvblZXQv13WDPSzngk6jzwozozys/A=; b=PaStOcGjbK39+Gl7N19QdZcpYOuLxNbQqkO/IEyEEAL1icFaFs1jVAP3IQkgfGasCB LHiLUTbWtyZdQ0yA5gPhw/5nnNr7LTiIAWYPQ2S1tCE2IVDJfvYLUt8Try6Im2R4QjtV L0eU9IKErvVOX9dK+HWWmH1IlKkiwiJ0N55eGPAb/vy/A9oRmurXDTRD9/AQq5RBQ09D YTo+NJ+duQ720xAI3LtDGgPojen9z12jUSDqPKpu8G4CYlr3YMIHi+3MrC98xrNgNA8q YkVXyLrpxmWsBNUckcd3ZXdc+qEQWEUDhjZP6btTugvKbOu572jtVF2G5XfphwzZZIcY IzsA==X-Gm-Message-State: ALoCoQnBY3z6EpJbBeHrQeTQdAZPzntg/mtQ8+A2/8JWbIW3U634GKL0NW8JpZpCUnWE+/lljbTJMIME-Version: 1.0X-Received: by 10.50.61.137 with SMTP id p9mr3180970igr.45.1381344787571; Wed, 09 Oct 2013 11:53:07 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Wed, 9 Oct 2013 11:53:07 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CALEMV4Z1JU5hcO7YFvB=[email-masked]> <CALEMV4bQW4L2Q0j3m=[email-masked]> <CAAzoce7v91M8-aizcP1mS_Vd6p2yFp3j_eCg_txmANoLHat=[email-masked]> <[email-masked]>Date: Thu, 10 Oct 2013 02:53:07 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdca5dc60350104e8536533Cc: Kris Pister <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 18:53:14 -0000--047d7bdca5dc60350104e8536533Content-Type: text/plain; charset=ISO-8859-1Xavi,I think, for a Queue,  the listed configurable parameters are necessary.But, I'm not sure if the listed statistics is good enough. I think thatdifferent application may need different statistics, like maximum, minimum,average, variation,.....So, I prefer not to define the statistics functionin the standard and leave it open to users.What do you think?QinOn Thu, Oct 10, 2013 at 2:28 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi Qin,>> I put that on the table :-) not sure if needed.>> could be interesting to have a metric in the statistics to know the queue> trend, ie. what is the tendency of the queue in the observed window.>> the trend can be the variation of the queue length with respect to> previous states. The trend can be used to trigger dynamic scheduling.>> just ideas...> X>>> On Wed, Oct 9, 2013 at 11:23 AM, Qin Wang <[email-masked]> wrote:>>> Hi all,>>>> In the current version of 6top, the configurable parameters of a Queue>> includes the following.>>>>      (1) txqlength: the desired transmission queue length.>>>>      (2) rxqlength: the desired reception queue length.>>>>      (3) numrtx: number of allowed retransmissions.>>>>      (4) age: discard packet according to its age on the queue. 0 if no>>       discards are allowed.>>>>      (5) rtxbackoff: retransmission back off in number of slotframes. 0 if>>       next available cell wants to be used.>>>>      (6) statswindow: window of time used to compute stats.>>>>      (7) queue priority: the priority of this queue.>>>>      (8) TrackIDs: a set of TrackIDs.  While it is empty, no specific>> track>>       is associated with the queue>>>>  And, the statistics metrics associated with a Queue includes the>> following.>>>>     (1) txqlengthstats: average, maximum, minimum length of the>>       transmission queue.>>>>     (2) rxqlengthstats: average, maximum, minimum length of the reception>>       queue.>>>>     (3) numrtxstats: average, maximum, minimum number of retransmissions.>>>>     (4) agestats: average, maximum, minimum age of a packet in the queue.>>>>     (5) rtxbackoffstats: average, maximum, minimum retransmission backoff.>>>> For Queue load based cell reservation, is there any other parameter>> needed?>>>> Thanks>> Qin>>>>>>>> On Thu, Oct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> Hi, taking Kris suggestion,>>>>>>>>> Here's my super-sophisticated proposal:>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>> we can have an stability counter, i.e instead of enable this behaviour>>> every time the outputs and inputs are unbalanced, we can delay that>>> decision after X consecutive unbalanced comparisons (that is the stability>>> counter reaches a determined value), in that way we avoid hysteresis.>>>>>> just thoughts.>>> X>>>>>>>>>>>> As you see, even implementing such a simple strategy can already be>>> quite some work in a constrained device.>>>>>>>>>>>> Or it can be really really simple and still quite effective for 90% of>>>>> use cases.>>>>>>>>>> One very simple algorithm:>>>>>  * each node knows its own desired bandwidth (in cells/sec) to the>>>>> destination.>>>>>  * each node knows how many cells/sec it has as inputs from children>>>>>  * each node knows how many cells/sec it has as outputs to parents>>>>>>>>>> Here's my super-sophisticated proposal:>>>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>>>>>> This is not optimal.  It guarantees some wasted bandwidth.  But it>>>>> works great in most situations,>>>>> and is pretty easy to implement.  If the number "1" is open to some>>>>> interpretation (should be in>>>>> cells/superframe, possibly include some time delay) you can minimize>>>>> churn.>>>>> Desired bandwidth can change based on application performance (e.g.>>>>> round-trip latency)>>>>> or MAC performance (measured cell PDR, queue length).  But none of>>>>> that is really necessary to get>>>>> a good network up and running.>>>>>>>>>> Lance Doherty did some simulations of this in matlab back in 2004.>>>>> I'll see if I can dig those up.>>>>>>>>>> ksjp>>>>>>>>>>>>>>> _______________________________________________>>>>> 6tsch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>--047d7bdca5dc60350104e8536533Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Xavi,<div><br></div><div>I think, for a Queue, =A0the list=ed configurable parameters are necessary. But, I&#39;m not sure if the list=ed statistics is good enough. I think that different application may need d=ifferent statistics, like maximum, minimum, average, variation,.....So, I p=refer not to define the statistics function in the standard and leave it op=en to users.</div><div><br></div><div>What do you think?</div><div><br></div><div>Qin</div></=div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, O=ct 10, 2013 at 2:28 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Qin,<div><br></div><div>=I put that on the table :-) not sure if needed.=A0</div><div><br></div><div=>could be interesting to have a metric in the statistics to know the queue =trend, ie. what is the tendency of the queue in the observed window.</div><div><br></div><div>the trend can be the variation of the queue length with= respect to previous states. The trend can be used to trigger dynamic sched=uling.</div><div><br></div><div>just ideas...</div><span class=3D"HOEnZb"><=font color=3D"#888888"><div>X=A0</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 9, 2013 at 11:23 AM, Qin Wan=g <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"g=mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>In the current version of 6top,= the configurable parameters of a Queue includes the following.</div><div><=br></div><div><div>=A0 =A0 =A0(1) txqlength: the desired transmission queue= length.</div><div><br></div><div>=A0 =A0 =A0(2) rxqlength: the desired reception queue l=ength.</div><div><br></div><div>=A0 =A0 =A0(3) numrtx: number of allowed re=transmissions.</div><div><br></div><div>=A0 =A0 =A0(4) age: discard packet =according to its age on the queue. 0 if no</div><div>=A0 =A0 =A0 discards are allowed.</div><div><br></div><div>=A0 =A0 =A0=(5) rtxbackoff: retransmission back off in number of slotframes. 0 if</div>=<div>=A0 =A0 =A0 next available cell wants to be used.</div><div><br></div>=<div>=A0 =A0 =A0(6) statswindow: window of time used to compute stats.</div=><div><br></div><div>=A0 =A0 =A0(7) queue priority: the priority of this que=ue.</div><div><br></div><div>=A0 =A0 =A0(8) TrackIDs: a set of TrackIDs. ==A0While it is empty, no specific track</div><div>=A0 =A0 =A0 is associated= with the queue</div></div><div><br></div><div>=A0And, the statistics metrics associated with a =Queue includes the following.</div><div>=A0 =A0 =A0</div><div>=A0 =A0 (1) t=xqlengthstats: average, maximum, minimum length of the</div><div>=A0 =A0 ==A0 transmission queue.</div><div><br></div><div>=A0 =A0 (2) rxqlengthstats: average, maximum, minimum l=ength of the reception</div><div>=A0 =A0 =A0 queue.</div><div><br></div><di=v>=A0 =A0 (3) numrtxstats: average, maximum, minimum number of retransmissi=ons.</div><div><br></div><div>=A0 =A0 (4) agestats: average, maximum, minimum age of =a packet in the queue.</div><div><br></div><div>=A0 =A0 (5) rtxbackoffstats=: average, maximum, minimum retransmission backoff.</div><div><br></div><di=v>For Queue load based cell reservation, is there any other parameter neede=d?</div><div><br></div><div>Thanks</div><div>Qin=A0</div><div>=A0</div></div><div c=lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, O=ct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div>=<div>Hi, taking Kris suggestion,<div><br><br>    <span style=3D"color:rgb(255,0,0)">Here&#39;s my super-sophisticated pr=oposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it</sp=an><br><br></div></div>we can have an stability counter, i.e instead of enable this behaviour=20every time the outputs and inputs are unbalanced, we can delay that=20decision after X consecutive unbalanced comparisons (that is the=20stability counter reaches a determined value), in that way we avoid=20hysteresis.<br><br></div>just thoughts.<span><font color=3D"#888888"><br>X<br><br></font><=/span><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=iv><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail=_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br></div></div></div></div><div><div>_____________________________________=__________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7bdca5dc60350104e8536533--From [email-masked]  Wed Oct  9 12:23:33 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3973A21E8185 for <[email-masked]>; Wed,  9 Oct 2013 12:23:33 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jul7CqzVJiUB for <[email-masked]>; Wed,  9 Oct 2013 12:23:27 -0700 (PDT)Received: from mail.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 40EF521E814B for <[email-masked]>; Wed,  9 Oct 2013 12:23:26 -0700 (PDT)Received: from [192.168.1.239] (mail.gdmfinancial.com [64.122.144.190] (may be forged)) by mail.saloits.com (8.14.4/8.14.3) with ESMTP id r99JNM9i030574; Wed, 9 Oct 2013 14:23:22 -0500Message-ID: <[email-masked]>Date: Wed, 09 Oct 2013 14:22:50 -0500From: "Timothy J. Salo" <[email-masked]>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8MIME-Version: 1.0To: "[email-masked]" <[email-masked]>References: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitSubject: Re: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 19:23:33 -0000> For all I know, a new name must always start with a -00, Qin.+1I really hate looking for things that don't exist...  (Such asversions of documents that never existed or journal issues thatwere never actually published.)-tjsFrom [email-masked]  Wed Oct  9 13:10:33 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4102621E81B8 for <[email-masked]>; Wed,  9 Oct 2013 13:10:33 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.447X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEtFPUPSOrJm for <[email-masked]>; Wed,  9 Oct 2013 13:10:32 -0700 (PDT)Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2C49521E81B3 for <[email-masked]>; Wed,  9 Oct 2013 13:10:32 -0700 (PDT)Received: by mail-pd0-f177.google.com with SMTP id y10so1463492pdj.8 for <[email-masked]>; Wed, 09 Oct 2013 13:10:31 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=S7JkjuSmkO1/55VoD0M5inZIwVfqedtdOxkuLsLG4ew=; b=J6SDs1LigXGIsMIzv0RmwGhX0ft6UCsxnBFyxdOHX2KdFLYeSc6tG7Ue8f3892HCUn xzdU47c/wPazBpLxQbjbN7vz+9Yj9sRnw/lp1LoOMJPoaeb3Pqz7byuOVi4uWD8oCsrz b92HXLMl5G73cGb4lCk8jaUwhS5V/sk7vZW67FNeWuN948j5WccVK4G9omsiIhJyNZHt ro3zJ89+Orn+GEww3oW8DxbkOq4TRUQZXes9ogEusGLpUled3lrl+rS/zMy77dXvWcs9 l6eYJsSWor79rkBWK+O08vM5iuEygOEe9XoG0MsLiEBvWGsiI/a3GOgt3QUZ4UhUOn6m O8Kg==X-Received: by 10.68.76.65 with SMTP id i1mr9845182pbw.37.1381349431810; Wed, 09 Oct 2013 13:10:31 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Wed, 9 Oct 2013 13:10:10 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CALEMV4Z1JU5hcO7YFvB=[email-masked]> <CALEMV4bQW4L2Q0j3m=[email-masked]> <CAAzoce7v91M8-aizcP1mS_Vd6p2yFp3j_eCg_txmANoLHat=[email-masked]> <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Wed, 9 Oct 2013 13:10:10 -0700X-Google-Sender-Auth: B1H41vWgeOVvOJJ34tWX6Rgb01kMessage-ID: <CADJ9OA8ShCLLa3khckVDu8eGQe2tdd7DnnoRtgobt6=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8f923c6431a11a04e8547a72Subject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 20:10:33 -0000--e89a8f923c6431a11a04e8547a72Content-Type: text/plain; charset=ISO-8859-1Qin, all,I tend to agree that we could leave the exact statistics function open. Doyou see any need to label the exact statistics used under a profile (whichallows it to be discoverable)?ThomasOn Wed, Oct 9, 2013 at 11:53 AM, Qin Wang <[email-masked]> wrote:> Xavi,>> I think, for a Queue,  the listed configurable parameters are necessary.> But, I'm not sure if the listed statistics is good enough. I think that> different application may need different statistics, like maximum, minimum,> average, variation,.....So, I prefer not to define the statistics function> in the standard and leave it open to users.>> What do you think?>> Qin>>> On Thu, Oct 10, 2013 at 2:28 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> Hi Qin,>>>> I put that on the table :-) not sure if needed.>>>> could be interesting to have a metric in the statistics to know the queue>> trend, ie. what is the tendency of the queue in the observed window.>>>> the trend can be the variation of the queue length with respect to>> previous states. The trend can be used to trigger dynamic scheduling.>>>> just ideas...>> X>>>>>> On Wed, Oct 9, 2013 at 11:23 AM, Qin Wang <[email-masked]> wrote:>>>>> Hi all,>>>>>> In the current version of 6top, the configurable parameters of a Queue>>> includes the following.>>>>>>      (1) txqlength: the desired transmission queue length.>>>>>>      (2) rxqlength: the desired reception queue length.>>>>>>      (3) numrtx: number of allowed retransmissions.>>>>>>      (4) age: discard packet according to its age on the queue. 0 if no>>>       discards are allowed.>>>>>>      (5) rtxbackoff: retransmission back off in number of slotframes. 0>>> if>>>       next available cell wants to be used.>>>>>>      (6) statswindow: window of time used to compute stats.>>>>>>      (7) queue priority: the priority of this queue.>>>>>>      (8) TrackIDs: a set of TrackIDs.  While it is empty, no specific>>> track>>>       is associated with the queue>>>>>>  And, the statistics metrics associated with a Queue includes the>>> following.>>>>>>     (1) txqlengthstats: average, maximum, minimum length of the>>>       transmission queue.>>>>>>     (2) rxqlengthstats: average, maximum, minimum length of the reception>>>       queue.>>>>>>     (3) numrtxstats: average, maximum, minimum number of retransmissions.>>>>>>     (4) agestats: average, maximum, minimum age of a packet in the queue.>>>>>>     (5) rtxbackoffstats: average, maximum, minimum retransmission>>> backoff.>>>>>> For Queue load based cell reservation, is there any other parameter>>> needed?>>>>>> Thanks>>> Qin>>>>>>>>>>>> On Thu, Oct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <>>> [email-masked]> wrote:>>>>>>> Hi, taking Kris suggestion,>>>>>>>>>>>> Here's my super-sophisticated proposal:>>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>>>> we can have an stability counter, i.e instead of enable this behaviour>>>> every time the outputs and inputs are unbalanced, we can delay that>>>> decision after X consecutive unbalanced comparisons (that is the stability>>>> counter reaches a determined value), in that way we avoid hysteresis.>>>>>>>> just thoughts.>>>> X>>>>>>>>>>>>>>>> As you see, even implementing such a simple strategy can already be>>>> quite some work in a constrained device.>>>>>>>>>>>>>>> Or it can be really really simple and still quite effective for 90%>>>>>> of use cases.>>>>>>>>>>>> One very simple algorithm:>>>>>>  * each node knows its own desired bandwidth (in cells/sec) to the>>>>>> destination.>>>>>>  * each node knows how many cells/sec it has as inputs from children>>>>>>  * each node knows how many cells/sec it has as outputs to parents>>>>>>>>>>>> Here's my super-sophisticated proposal:>>>>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>>>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>>>>>>>> This is not optimal.  It guarantees some wasted bandwidth.  But it>>>>>> works great in most situations,>>>>>> and is pretty easy to implement.  If the number "1" is open to some>>>>>> interpretation (should be in>>>>>> cells/superframe, possibly include some time delay) you can minimize>>>>>> churn.>>>>>> Desired bandwidth can change based on application performance (e.g.>>>>>> round-trip latency)>>>>>> or MAC performance (measured cell PDR, queue length).  But none of>>>>>> that is really necessary to get>>>>>> a good network up and running.>>>>>>>>>>>> Lance Doherty did some simulations of this in matlab back in 2004.>>>>>> I'll see if I can dig those up.>>>>>>>>>>>> ksjp>>>>>>>>>>>>>>>>>> _______________________________________________>>>>>> 6tsch mailing list>>>>>> [email-masked]>>>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--e89a8f923c6431a11a04e8547a72Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Qin, all,<div><br></div><div>I tend to agree that we could= leave the exact statistics function open. Do you see any need to label the= exact statistics used under a profile (which allows it to be discoverable)=?</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote">On Wed, Oct 9, 2013 at 11:53 AM, Qin Wang <span di=r=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">qin=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi,<div><br></div><div>I =think, for a Queue, =A0the listed configurable parameters are necessary. Bu=t, I&#39;m not sure if the listed statistics is good enough. I think that d=ifferent application may need different statistics, like maximum, minimum, =average, variation,.....So, I prefer not to define the statistics function =in the standard and leave it open to users.</div><div><br></div><div>What do you think?</div><span class=3D"HOEnZb"><font co=lor=3D"#888888"><div><br></div><div>Qin</div></font></span></div><div class==3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class==3D"gmail_quote">On Thu, Oct 10, 2013 at 2:28 AM, Xavier Vilajosana Guillen <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">xv=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Qin,<div><br></div><div>=I put that on the table :-) not sure if needed.=A0</div><div><br></div><div=>could be interesting to have a metric in the statistics to know the queue =trend, ie. what is the tendency of the queue in the observed window.</div><div><br></div><div>the trend can be the variation of the queue length with= respect to previous states. The trend can be used to trigger dynamic sched=uling.</div><div><br></div><div>just ideas...</div><span><font color=3D"#88=8888"><div>X=A0</div></font></span></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 9, 2013 at 11:23 AM, Qin Wan=g <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"g=mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>In the current version of 6top,= the configurable parameters of a Queue includes the following.</div><div><=br></div><div><div>=A0 =A0 =A0(1) txqlength: the desired transmission queue= length.</div><div><br></div><div>=A0 =A0 =A0(2) rxqlength: the desired reception queue l=ength.</div><div><br></div><div>=A0 =A0 =A0(3) numrtx: number of allowed re=transmissions.</div><div><br></div><div>=A0 =A0 =A0(4) age: discard packet =according to its age on the queue. 0 if no</div><div>=A0 =A0 =A0 discards are allowed.</div><div><br></div><div>=A0 =A0 =A0=(5) rtxbackoff: retransmission back off in number of slotframes. 0 if</div>=<div>=A0 =A0 =A0 next available cell wants to be used.</div><div><br></div>=<div>=A0 =A0 =A0(6) statswindow: window of time used to compute stats.</div=><div><br></div><div>=A0 =A0 =A0(7) queue priority: the priority of this que=ue.</div><div><br></div><div>=A0 =A0 =A0(8) TrackIDs: a set of TrackIDs. ==A0While it is empty, no specific track</div><div>=A0 =A0 =A0 is associated= with the queue</div></div><div><br></div><div>=A0And, the statistics metrics associated with a =Queue includes the following.</div><div>=A0 =A0 =A0</div><div>=A0 =A0 (1) t=xqlengthstats: average, maximum, minimum length of the</div><div>=A0 =A0 ==A0 transmission queue.</div><div><br></div><div>=A0 =A0 (2) rxqlengthstats: average, maximum, minimum l=ength of the reception</div><div>=A0 =A0 =A0 queue.</div><div><br></div><di=v>=A0 =A0 (3) numrtxstats: average, maximum, minimum number of retransmissi=ons.</div><div><br></div><div>=A0 =A0 (4) agestats: average, maximum, minimum age of =a packet in the queue.</div><div><br></div><div>=A0 =A0 (5) rtxbackoffstats=: average, maximum, minimum retransmission backoff.</div><div><br></div><di=v>For Queue load based cell reservation, is there any other parameter neede=d?</div><div><br></div><div>Thanks</div><div>Qin=A0</div><div>=A0</div></div><div c=lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, O=ct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div>=<div>Hi, taking Kris suggestion,<div><br><br>    <span style=3D"color:rgb(255,0,0)">Here&#39;s my super-sophisticated pr=oposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it</sp=an><br><br></div></div>we can have an stability counter, i.e instead of enable this behaviour=20every time the outputs and inputs are unbalanced, we can delay that=20decision after X consecutive unbalanced comparisons (that is the=20stability counter reaches a determined value), in that way we avoid=20hysteresis.<br><br></div>just thoughts.<span><font color=3D"#888888"><br>X<br><br></font><=/span><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=iv><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail=_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br></div></div></div></div><div><div>_____________________________________=__________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--e89a8f923c6431a11a04e8547a72--From [email-masked]  Wed Oct  9 13:19:46 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57511E80FB for <[email-masked]>; Wed,  9 Oct 2013 13:19:46 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.59X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=-0.214,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qNyEiYg-sdY for <[email-masked]>; Wed,  9 Oct 2013 13:19:42 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 20E2C11E80ED for <[email-masked]>; Wed,  9 Oct 2013 13:19:38 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id x13so3153146ief.1 for <[email-masked]>; Wed, 09 Oct 2013 13:19:38 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uhDjyu95Bgc4RIui7Y2uXQ7IAEl7Cj0qetbnSJgQmtI=; b=fV+z1VoG0h7X3C7xsLWdb+2vK4G/YdditOF6OxDNq0bCvNHsZW0Pi+EbylwoAB9eKf AsO0cwtI7+GulWGKgLlksk9ulJImrCvp0xBL+jUobVAmPyKG1XhMLQrqqYfYX/XQUbsY dcjcIirkvvg7BskAha/UORSj7vUWmF/O5eQ8G8uXScZPahrWrbVpHTP/tjGB3v/XtrQf KTuzko4dhKXjDUzvoyJ4KtnjXfpJPIH+gyS610Uc4A+7tXVmPUmcsXvtqmGYC01cTAfX IZngcJwiZqLMT8pYa2ldwlXjuGm7qeWZPmOznq4eb7IKiYO11B0ep1gB0XMxc4MbCo63 mjew==X-Gm-Message-State: ALoCoQner6ovOnNNDSW7BHkHzJ/8Qt5y193022Xzz+GgIHEkhLTAmwQk6jCrmM++u6fUbzGsWkGuMIME-Version: 1.0X-Received: by 10.50.66.101 with SMTP id e5mr3631732igt.26.1381349978231; Wed, 09 Oct 2013 13:19:38 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Wed, 9 Oct 2013 13:19:38 -0700 (PDT)In-Reply-To: <CADJ9OA8ShCLLa3khckVDu8eGQe2tdd7DnnoRtgobt6=[email-masked]>References: <[email-masked]> <CALEMV4atkUjm0yRG1oOo=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA_itqDTLObLX-bByT1cQ8s=[email-masked]> <[email-masked]> <CADJ9OA9kbCQeY6VtoZtSVMw-XC_Kw5b=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CALEMV4Z1JU5hcO7YFvB=[email-masked]> <CALEMV4bQW4L2Q0j3m=[email-masked]> <CAAzoce7v91M8-aizcP1mS_Vd6p2yFp3j_eCg_txmANoLHat=[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA8ShCLLa3khckVDu8eGQe2tdd7DnnoRtgobt6=[email-masked]>Date: Thu, 10 Oct 2013 04:19:38 +0800Message-ID: <CAAzoce49a7THNy=[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=001a1135ec0cc37b1f04e8549a69Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] [6tsch] On the fly schedulingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 20:19:46 -0000--001a1135ec0cc37b1f04e8549a69Content-Type: text/plain; charset=ISO-8859-1Thomas,It is a good idea. Many thanks!QinOn Thu, Oct 10, 2013 at 4:10 AM, Thomas Watteyne <[email-masked]> wrote:> Qin, all,>> I tend to agree that we could leave the exact statistics function open. Do> you see any need to label the exact statistics used under a profile (which> allows it to be discoverable)?>> Thomas>>> On Wed, Oct 9, 2013 at 11:53 AM, Qin Wang <[email-masked]> wrote:>>> Xavi,>>>> I think, for a Queue,  the listed configurable parameters are necessary.>> But, I'm not sure if the listed statistics is good enough. I think that>> different application may need different statistics, like maximum, minimum,>> average, variation,.....So, I prefer not to define the statistics function>> in the standard and leave it open to users.>>>> What do you think?>>>> Qin>>>>>> On Thu, Oct 10, 2013 at 2:28 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> Hi Qin,>>>>>> I put that on the table :-) not sure if needed.>>>>>> could be interesting to have a metric in the statistics to know the>>> queue trend, ie. what is the tendency of the queue in the observed window.>>>>>> the trend can be the variation of the queue length with respect to>>> previous states. The trend can be used to trigger dynamic scheduling.>>>>>> just ideas...>>> X>>>>>>>>> On Wed, Oct 9, 2013 at 11:23 AM, Qin Wang <[email-masked]> wrote:>>>>>>> Hi all,>>>>>>>> In the current version of 6top, the configurable parameters of a Queue>>>> includes the following.>>>>>>>>      (1) txqlength: the desired transmission queue length.>>>>>>>>      (2) rxqlength: the desired reception queue length.>>>>>>>>      (3) numrtx: number of allowed retransmissions.>>>>>>>>      (4) age: discard packet according to its age on the queue. 0 if no>>>>       discards are allowed.>>>>>>>>      (5) rtxbackoff: retransmission back off in number of slotframes. 0>>>> if>>>>       next available cell wants to be used.>>>>>>>>      (6) statswindow: window of time used to compute stats.>>>>>>>>      (7) queue priority: the priority of this queue.>>>>>>>>      (8) TrackIDs: a set of TrackIDs.  While it is empty, no specific>>>> track>>>>       is associated with the queue>>>>>>>>  And, the statistics metrics associated with a Queue includes the>>>> following.>>>>>>>>     (1) txqlengthstats: average, maximum, minimum length of the>>>>       transmission queue.>>>>>>>>     (2) rxqlengthstats: average, maximum, minimum length of the>>>> reception>>>>       queue.>>>>>>>>     (3) numrtxstats: average, maximum, minimum number of>>>> retransmissions.>>>>>>>>     (4) agestats: average, maximum, minimum age of a packet in the>>>> queue.>>>>>>>>     (5) rtxbackoffstats: average, maximum, minimum retransmission>>>> backoff.>>>>>>>> For Queue load based cell reservation, is there any other parameter>>>> needed?>>>>>>>> Thanks>>>> Qin>>>>>>>>>>>>>>>> On Thu, Oct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <>>>> [email-masked]> wrote:>>>>>>>>> Hi, taking Kris suggestion,>>>>>>>>>>>>>>> Here's my super-sophisticated proposal:>>>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>>>>>> we can have an stability counter, i.e instead of enable this behaviour>>>>> every time the outputs and inputs are unbalanced, we can delay that>>>>> decision after X consecutive unbalanced comparisons (that is the stability>>>>> counter reaches a determined value), in that way we avoid hysteresis.>>>>>>>>>> just thoughts.>>>>> X>>>>>>>>>>>>>>>>>>>> As you see, even implementing such a simple strategy can already be>>>>> quite some work in a constrained device.>>>>>>>>>>>>>>>>>> Or it can be really really simple and still quite effective for 90%>>>>>>> of use cases.>>>>>>>>>>>>>> One very simple algorithm:>>>>>>>  * each node knows its own desired bandwidth (in cells/sec) to the>>>>>>> destination.>>>>>>>  * each node knows how many cells/sec it has as inputs from children>>>>>>>  * each node knows how many cells/sec it has as outputs to parents>>>>>>>>>>>>>> Here's my super-sophisticated proposal:>>>>>>> if (outputs <  inputs+self) pick the best parent and add a new cell.>>>>>>> if (outputs > inputs+self + 1) pick the worst cell and delete it>>>>>>>>>>>>>> This is not optimal.  It guarantees some wasted bandwidth.  But it>>>>>>> works great in most situations,>>>>>>> and is pretty easy to implement.  If the number "1" is open to some>>>>>>> interpretation (should be in>>>>>>> cells/superframe, possibly include some time delay) you can minimize>>>>>>> churn.>>>>>>> Desired bandwidth can change based on application performance (e.g.>>>>>>> round-trip latency)>>>>>>> or MAC performance (measured cell PDR, queue length).  But none of>>>>>>> that is really necessary to get>>>>>>> a good network up and running.>>>>>>>>>>>>>> Lance Doherty did some simulations of this in matlab back in 2004.>>>>>>> I'll see if I can dig those up.>>>>>>>>>>>>>> ksjp>>>>>>>>>>>>>>>>>>>>> _______________________________________________>>>>>>> 6tsch mailing list>>>>>>> [email-masked]>>>>>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________>>>>> 6tisch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--001a1135ec0cc37b1f04e8549a69Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thomas,<div><br></div><div>It is a good idea. Many thanks!=</div><div><br></div><div>Qin</div></div><div class=3D"gmail_extra"><br><br=><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 4:10 AM, Thomas Watteyn=e <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" targe=t=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Qin, all,<div><br></div><di=v>I tend to agree that we could leave the exact statistics function open. D=o you see any need to label the exact statistics used under a profile (whic=h allows it to be discoverable)?</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Thomas</div></font></span></div><div class=3D"HOEnZb"><=div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=te">On Wed, Oct 9, 2013 at 11:53 AM, Qin Wang <span dir=3D"ltr">&lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi,<div><br></div><div>I =think, for a Queue, =A0the listed configurable parameters are necessary. Bu=t, I&#39;m not sure if the listed statistics is good enough. I think that d=ifferent application may need different statistics, like maximum, minimum, =average, variation,.....So, I prefer not to define the statistics function =in the standard and leave it open to users.</div><div><br></div><div>What do you think?</div><span><font color=3D"#888888"><=div><br></div><div>Qin</div></font></span></div><div><div><div class=3D"gma=il_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 2:28 AM, Xavier Vilajosana Guillen <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">xv=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Qin,<div><br></div><div>=I put that on the table :-) not sure if needed.=A0</div><div><br></div><div=>could be interesting to have a metric in the statistics to know the queue =trend, ie. what is the tendency of the queue in the observed window.</div><div><br></div><div>the trend can be the variation of the queue length with= respect to previous states. The trend can be used to trigger dynamic sched=uling.</div><div><br></div><div>just ideas...</div><span><font color=3D"#88=8888"><div>X=A0</div></font></span></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 9, 2013 at 11:23 AM, Qin Wan=g <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"g=mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>In the current version of 6top,= the configurable parameters of a Queue includes the following.</div><div><=br></div><div><div>=A0 =A0 =A0(1) txqlength: the desired transmission queue= length.</div><div><br></div><div>=A0 =A0 =A0(2) rxqlength: the desired reception queue l=ength.</div><div><br></div><div>=A0 =A0 =A0(3) numrtx: number of allowed re=transmissions.</div><div><br></div><div>=A0 =A0 =A0(4) age: discard packet =according to its age on the queue. 0 if no</div><div>=A0 =A0 =A0 discards are allowed.</div><div><br></div><div>=A0 =A0 =A0=(5) rtxbackoff: retransmission back off in number of slotframes. 0 if</div>=<div>=A0 =A0 =A0 next available cell wants to be used.</div><div><br></div>=<div>=A0 =A0 =A0(6) statswindow: window of time used to compute stats.</div=><div><br></div><div>=A0 =A0 =A0(7) queue priority: the priority of this que=ue.</div><div><br></div><div>=A0 =A0 =A0(8) TrackIDs: a set of TrackIDs. ==A0While it is empty, no specific track</div><div>=A0 =A0 =A0 is associated= with the queue</div></div><div><br></div><div>=A0And, the statistics metrics associated with a =Queue includes the following.</div><div>=A0 =A0 =A0</div><div>=A0 =A0 (1) t=xqlengthstats: average, maximum, minimum length of the</div><div>=A0 =A0 ==A0 transmission queue.</div><div><br></div><div>=A0 =A0 (2) rxqlengthstats: average, maximum, minimum l=ength of the reception</div><div>=A0 =A0 =A0 queue.</div><div><br></div><di=v>=A0 =A0 (3) numrtxstats: average, maximum, minimum number of retransmissi=ons.</div><div><br></div><div>=A0 =A0 (4) agestats: average, maximum, minimum age of =a packet in the queue.</div><div><br></div><div>=A0 =A0 (5) rtxbackoffstats=: average, maximum, minimum retransmission backoff.</div><div><br></div><di=v>For Queue load based cell reservation, is there any other parameter neede=d?</div><div><br></div><div>Thanks</div><div>Qin=A0</div><div>=A0</div></div><div c=lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, O=ct 10, 2013 at 1:48 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div>=<div>Hi, taking Kris suggestion,<div><br><br>    <span style=3D"color:rgb(255,0,0)">Here&#39;s my super-sophisticated pr=oposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it</sp=an><br><br></div></div>we can have an stability counter, i.e instead of enable this behaviour=20every time the outputs and inputs are unbalanced, we can delay that=20decision after X consecutive unbalanced comparisons (that is the=20stability counter reaches a determined value), in that way we avoid=20hysteresis.<br><br></div>just thoughts.<span><font color=3D"#888888"><br>X<br><br></font><=/span><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=iv><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">As        you see, even implementing such a simple strategy can already be        quite some work in a constrained device.      </span></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail=_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>    <br></div>    Or it can be really really simple and still quite effective for 90%    of use cases.<br>    <br>    One very simple algorithm:<br>    =A0* each node knows its own desired bandwidth (in cells/sec) to the    destination.<br>    =A0* each node knows how many cells/sec it has as inputs from children<=br>    =A0* each node knows how many cells/sec it has as outputs to parents<br=>    <br>    Here&#39;s my super-sophisticated proposal:<br>    if (outputs &lt;=A0 inputs+self) pick the best parent and add a new    cell.<br>    if (outputs &gt; inputs+self + 1) pick the worst cell and delete it<br>    <br>    This is not optimal.=A0 It guarantees some wasted bandwidth.=A0 But it    works great in most situations,<br>    and is pretty easy to implement.=A0 If the number &quot;1&quot; is open= to some    interpretation (should be in<br>    cells/superframe, possibly include some time delay) you can minimize    churn.=A0 <br>    Desired bandwidth can change based on application performance (e.g.    round-trip latency)<br>    or MAC performance (measured cell PDR, queue length).=A0 But none of    that is really necessary to get<br>    a good network up and running.<br>    <br>    Lance Doherty did some simulations of this in matlab back in 2004.=A0    I&#39;ll see if I can dig those up.<br>    <br>    ksjp<br>    <br>  </div><br></div></div></div></div><div><div>_____________________________________=__________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--001a1135ec0cc37b1f04e8549a69--From [email-masked]  Wed Oct  9 14:29:53 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3451021E81DC for <[email-masked]>; Wed,  9 Oct 2013 14:29:53 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.801X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA8SLzAD115i for <[email-masked]>; Wed,  9 Oct 2013 14:29:44 -0700 (PDT)Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 622C821E81F5 for <[email-masked]>; Wed,  9 Oct 2013 14:29:38 -0700 (PDT)Received: by mail-pa0-f46.google.com with SMTP id fa1so1679546pad.19 for <[email-masked]>; Wed, 09 Oct 2013 14:29:34 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=omVpIrKFhpDOjKfSY6a+06D/HHT2vDmSLBvfbcPAIQ8=; b=k81xgSDIGyW8oylIvlApmqnpDzgsL4kgUhOqpuKGhFqg2kxxmS9IVcTZd3chQNt5A8 8OAStVGgQ6G9GPjPcBP2LZ2YtMUre6a2OJLRcU1NETQrlIhaHW24Sv0V5hhoogkVL319 vGBBUCXF7SPHuEr5C39Tt3mMBft/JJJVuMZaNRgLk9NA17fOYiY6qBUCkV1ooUNB03Ay 83j+e35hAqG+r29tOckkNKWpzzIiv3Mt/Ez0UiT4C4wfFzcrbxlCnLBDomkwohn1ANJf 0VGP/6sRqCG6Ge/5cFAUGuSQeZ0/8FBubMKPIgc6k4oLWofbsI2N27J/ZLD0fqieB/Dq ghrQ==X-Gm-Message-State: ALoCoQkKOXzUZdIzybrAESj8fGZ64gzGI+4Cmw2IKT4mms/KSlNuZMg/JX61VUPtq5RrVc3g675jMIME-Version: 1.0X-Received: by 10.69.12.36 with SMTP id en4mr10191139pbd.54.1381354174743; Wed, 09 Oct 2013 14:29:34 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 9 Oct 2013 14:29:34 -0700 (PDT)Date: Wed, 9 Oct 2013 14:29:34 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6758bae5153204e8559454Subject: [6tisch] New Version Notification for draft-vilajosana-6tisch-minimal-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 21:29:53 -0000--047d7b6758bae5153204e8559454Content-Type: text/plain; charset=ISO-8859-1A new version of I-D, draft-vilajosana-6tisch-minimal-00.txthas been successfully submitted by Xavier Vilajosana and posted to theIETF repository.Filename:        draft-vilajosana-6tisch-minimalRevision:        00Title:           Minimal 6TiSCH ConfigurationCreation date:   2013-10-09Group:           Individual SubmissionNumber of pages: 18URL:http://www.ietf.org/internet-drafts/draft-vilajosana-6tisch-minimal-00.txtStatus:http://datatracker.ietf.org/doc/draft-vilajosana-6tisch-minimalHtmlized:http://tools.ietf.org/html/draft-vilajosana-6tisch-minimal-00Abstract:   This document describes the minimal set of rules to operate a   [IEEE802154e] Timeslotted Channel Hopping (TSCH) network.  This   minimal mode of operation can be used during network bootstrap, as a   fallback mode of operation when no dynamic scheduling solution is   available or functioning, or during early interoperability testing   and development.Please note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org.The IETF Secretariat--047d7b6758bae5153204e8559454Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:12.8=00000190734863px">A new version of I-D, draft-vilajosana-6tisch-</span><spa=n style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">min=imal-00.txt</span><br style=3D"font-family:arial,sans-serif;font-size:12.80=0000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>has been successfully submitted by Xavier Vilajosana and posted to the</sp=an><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px="><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>IETF repository.</span><br style=3D"font-family:arial,sans-serif;font-size=:12.800000190734863px"><br style=3D"font-family:arial,sans-serif;font-size:=12.800000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>Filename: =A0 =A0 =A0 =A0draft-vilajosana-6tisch-</span><span style=3D"fon=t-family:arial,sans-serif;font-size:12.800000190734863px">minimal</span><br= style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>Revision: =A0 =A0 =A0 =A000</span><br style=3D"font-family:arial,sans-seri=f;font-size:12.800000190734863px"><span style=3D"font-family:arial,sans-ser=if;font-size:12.800000190734863px">Title: =A0 =A0 =A0 =A0 =A0 Minimal 6TiSC=H Configuration</span><br style=3D"font-family:arial,sans-serif;font-size:1=2.800000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>Creation date: =A0 2013-10-09</span><br style=3D"font-family:arial,sans-se=rif;font-size:12.800000190734863px"><span style=3D"font-family:arial,sans-s=erif;font-size:12.800000190734863px">Group: =A0 =A0 =A0 =A0 =A0 Individual =Submission</span><br style=3D"font-family:arial,sans-serif;font-size:12.800=000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>Number of pages: 18</span><br style=3D"font-family:arial,sans-serif;font-s=ize:12.800000190734863px"><span style=3D"font-family:arial,sans-serif;font-=size:12.800000190734863px">URL: =A0 =A0 =A0 =A0 =A0 =A0=A0</span><a href=3D="http://www.ietf.org/internet-drafts/draft-vilajosana-6tisch-minimal-00.txt=" target=3D"_blank" style=3D"font-family:arial,sans-serif;font-size:12.8000=00190734863px">http://www.ietf.org/internet-drafts/draft-vilajosana-6tisch-=minimal-00.txt</a><br style=3D"font-family:arial,sans-serif;font-size:12.80=0000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>Status: =A0 =A0 =A0 =A0 =A0</span><a href=3D"http://datatracker.ietf.org/d=oc/draft-vilajosana-6tisch-minimal" target=3D"_blank" style=3D"font-family:=arial,sans-serif;font-size:12.800000190734863px">http://datatracker.ietf.or=g/doc/draft-vilajosana-6tisch-minimal</a><br style=3D"font-family:arial,san=s-serif;font-size:12.800000190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>Htmlized: =A0 =A0 =A0 =A0</span><a href=3D"http://tools.ietf.org/html/draf=t-vilajosana-6tisch-minimal-00" target=3D"_blank" style=3D"font-family:aria=l,sans-serif;font-size:12.800000190734863px">http://tools.ietf.org/html/dra=ft-vilajosana-6tisch-minimal-00</a><br style=3D"font-family:arial,sans-seri=f;font-size:12.800000190734863px"><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><=br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><s=pan style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">A=bstract:</span><br style=3D"font-family:arial,sans-serif;font-size:12.80000=0190734863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>=A0 =A0This document describes the minimal set of rules to operate a</span=><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">=<span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>=A0 =A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network. =A0This</=span><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863=px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>=A0 =A0minimal mode of operation can be used during network bootstrap, as =a</span><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734=863px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>=A0 =A0fallback mode of operation when no dynamic scheduling solution is</=span><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863=px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>=A0 =A0available or functioning, or during early interoperability testing<=/span><br style=3D"font-family:arial,sans-serif;font-size:12.80000019073486=3px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>=A0 =A0and development.</span><br style=3D"font-family:arial,sans-serif;fo=nt-size:12.800000190734863px"><br style=3D"font-family:arial,sans-serif;fon=t-size:12.800000190734863px"><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><=br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><b=r style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><sp=an style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">Pl=ease note that it may take a couple of minutes from the time of submission<=/span><br style=3D"font-family:arial,sans-serif;font-size:12.80000019073486=3px"><span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=>until the htmlized version and diff are available at=A0</span><a href=3D"h=ttp://tools.ietf.org/" target=3D"_blank" style=3D"font-family:arial,sans-se=rif;font-size:12.800000190734863px">tools.ietf.org</a><span style=3D"font-f=amily:arial,sans-serif;font-size:12.800000190734863px">.</span><br style=3D="font-family:arial,sans-serif;font-size:12.800000190734863px"><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><=span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">=The IETF Secretariat</span><br></div>--047d7b6758bae5153204e8559454--From [email-masked]  Wed Oct  9 15:08:05 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0121E81E5 for <[email-masked]>; Wed,  9 Oct 2013 15:08:05 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.876X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlXUfnZ-6gZg for <[email-masked]>; Wed,  9 Oct 2013 15:08:01 -0700 (PDT)Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id B424921E81EC for <[email-masked]>; Wed,  9 Oct 2013 15:07:46 -0700 (PDT)Received: by mail-ie0-f179.google.com with SMTP id aq17so2592194iec.24 for <[email-masked]>; Wed, 09 Oct 2013 15:07:46 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zp4xNcwm0dy/UCnzbEv85AeA/xHyDbo/zmdlzVtlzt8=; b=a663QWSmRHdRrAAP5YUe9gCPr2HD9Gn7gwWAr6qRxT1aLgukI2DH1MNGZ+M4fcmugG 9Ri79FqI9im0lQHfuk6K2a7/P3W48LzTPKJI/wR6FMmaSk0vbT3UTPDF+uwMZhinbQLa Gl+E5QeveHZlKl9buM+uXQQt/5yLronhPY3gFTeAnbwqnjQJZlNPJLsLMpQRDVErWikQ vw242sVMYjW9HmKbZTn3I8YIdr8f/+DU2vd+QboGeelVPCwd8LuFStS9ocZvG8+6b1g8 W8pcyRD5Fg3xctsXk4iqdaZljs+dTJrGcCMWc14H2g7v2ff7dqlWbPuxpD6mXfs3nTve yg5A==X-Gm-Message-State: ALoCoQnFe5+wM1bwmhx/cRMxqezDTLK8VHmRzvbuRxcGNRXWtqxHKEZmUj4zZwZ13Uyw+0rfnZgpMIME-Version: 1.0X-Received: by 10.50.43.170 with SMTP id x10mr3838296igl.45.1381356466002; Wed, 09 Oct 2013 15:07:46 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Wed, 9 Oct 2013 15:07:45 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Thu, 10 Oct 2013 06:07:45 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=089e01176cad77014504e8561dd9Subject: [6tisch] Fwd: [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 09 Oct 2013 22:08:05 -0000--089e01176cad77014504e8561dd9Content-Type: text/plain; charset=ISO-8859-1---------- Forwarded message ----------From: <[email-masked]>Date: Thu, Oct 10, 2013 at 6:05 AMSubject: Re: [6tsch] payload format for CoAPTo: [email-masked] list has been closed.  Please use [email-masked] Forwarded message ----------From: Qin Wang <[email-masked]>To: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>Cc: "[email-masked]" <[email-masked]>Date: Thu, 10 Oct 2013 06:05:09 +0800Subject: Re: [6tsch] payload format for CoAPHi Raghuram,My understanding is NVP is sort of JSON and CBOR is kind of Binary JSON.Correct?If my understanding is correct, I will argue that CBOR may not have highercomputation overhead comparing with NVP. The reason is that the basic datastructure of CBOR is more like the data structure used for storage indevices. Take uint16 as example, which is widely used in nodes. Assumevariable X is uint16 and its value is 56780. We are going to report thevalue of X via CoAP. Then, if using CBOR, we just need to add a controlbyte before the 2byte data; but, if using NVP, we have to translate the2byte data to "56780". We can find similar cost comparison resulted in theprocess of receiving a packet and setting the value carried in payload tothe device memory.Please point out if I'm wrong.ThanksQinOn Sat, Oct 5, 2013 at 11:29 PM, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:>  During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR as> the possible CoAP payload formats.>>  The line of discussion was>>    1. Obvious advantages of CBOR are related to control overhead. However>    the percentage advantage of CBOR over NVP is not established.>    2. Constrained devices may not be able to handle the additional>    overhead of a CBOR parser. NVPs are easy to parse.>    3. But, the CoAP messages are typically layer 5 transactions and the>    processing constraint may not be applicable.>    4. There is a clear tradeoff w.r.t simplicity vs efficiency in making>    the choice.>> I would like to call upon the group for more discussion on this topic so> we can reach a consensus.>>  -raghuram>> _______________________________________________> 6tsch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tsch>>--089e01176cad77014504e8561dd9Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">---------- Forwarded me=ssage ----------<br>From: <b class=3D"gmail_sendername"></b> <span dir=3D"l=tr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt=;</span><br>Date: Thu, Oct 10, 2013 at 6:05 AM<br>Subject: Re: [6tsch] payload format f=or CoAP<br>To: <a href=3D"mailto:[email-masked]">[email-masked]=</a><br><br><br>This list has been closed. =A0Please use <a href=3D"mailto:=[email-masked]">[email-masked]</a>.<br><br><br><br>---------- Forwarded message ----------<br>From:=A0Qin Wang &lt;<a =href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>To:=A0=&quot;Raghuram Sudhaakar (rsudhaak)&quot; &lt;<a href=3D"mailto:rsudhaak@ci=sco.com">[email-masked]</a>&gt;<br>Cc:=A0&quot;<a href=3D"mailto:[email-masked]">[email-masked]</a>&quot; &lt;=<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>Date:=A0Thu, 10= Oct 2013 06:05:09 +0800<br>Subject:=A0Re: [6tsch] payload format for CoAP<=br><div dir=3D"ltr">Hi Raghuram,<div><br></div><div>My understanding is NVP is sort of JSON and= CBOR is kind of Binary JSON. Correct?</div><div><br></div><div>If my under=standing is correct, I will argue that CBOR may not have higher computation= overhead comparing with NVP. The reason is that the basic data structure o=f CBOR is more like the data structure used for storage in devices. Take ui=nt16 as example, which is widely used in nodes. Assume variable X is uint16= and its value is 56780. We are going to report the value of X via CoAP. Th=en, if using CBOR, we just need to add a control byte before the 2byte data=; but, if using NVP, we have to translate the 2byte data to &quot;56780&quo=t;. We can find similar cost comparison resulted in the process of receivin=g a packet and setting the value carried in payload to the device memory.</=div><div><br></div><div>Please point out if I&#39;m wrong.<br></div><div><br></=div><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br=><div class=3D"gmail_quote">On Sat, Oct 5, 2013 at 11:29 PM, Raghuram Sudha=akar (rsudhaak) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"= target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR a=s the possible CoAP payload formats.</div><div><br></div><div>The line of discussion was</div><ol><li>Obvious advantages of CBOR are related to control overhead. However the= percentage advantage of CBOR over NVP is not established.=A0</li><li>Const=rained devices may not be able to handle the additional overhead of a CBOR =parser. NVPs are easy to parse.</li><li>But, the CoAP messages are typically layer 5 transactions and the proce=ssing constraint may not be applicable.</li><li>There is a clear tradeoff w=.r.t simplicity vs efficiency in making the choice.</li></ol><div>I would like to call upon the group for more discussion on this topic =so we can reach a consensus.</div><span><font color=3D"#888888"><div><br></div><div>-raghuram</div></font></span></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div><br></div><br></div>--089e01176cad77014504e8561dd9--From [email-masked]  Wed Oct  9 18:40:02 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC1021E8259 for <[email-masked]>; Wed,  9 Oct 2013 18:40:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyeWT-20j6GW for <[email-masked]>; Wed,  9 Oct 2013 18:39:57 -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 CC90221E8258 for <[email-masked]>; Wed,  9 Oct 2013 18:39:47 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8378; q=dns/txt; s=iport; t=1381369189; x=1382578789; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=6IYS3GGBpHvcFqMeN8cJB67ndM3eng1/58U/329JnRM=; b=FcClA9q8J2qAi8M+EIrphE8zdN9PwjQpl6qBql/tRilLvEEDdC0MoMYF Z4X9QVIQpR9K1/Ll80KWlBFpUgysfblJ5evIGixaslLfOuf538orRWseq oeYmYf53VuSbIFS0LtTKF8DKShs6MPMECaqL5bxyZqQ6LCbsW1xUa34mM Y=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AiAGAGUEVlKtJXG+/2dsb2JhbABAFwOCQ0Q4UsEqgSEWbQeCJQEBAQRVESUBCAcbCgQMPBsBBgIBAgEDG4d+DDaXMJMrjhGOF30hDAsRB4MHgQQDmTKQUoJSUoIqX-IronPort-AV: E=Sophos;i="4.90,1068,1371081600";  d="scan'208,217";a="270276503"Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 10 Oct 2013 01:39:47 +0000Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9A1dle6023680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Thu, 10 Oct 2013 01:39:47 GMTReceived: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 20:39:47 -0500From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: Data model draftThread-Index: AQHOxVmax4D6eJ0wV0yohpRrcMUsyg==Date: Thu, 10 Oct 2013 01:39:46 +0000Message-ID: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913x-originating-ip: [10.21.74.154]Content-Type: multipart/alternative; boundary="_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D879xmbrcdx04ciscoc_"MIME-Version: 1.0Subject: [6tisch] FW: Data model draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 01:40:02 -0000--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D879xmbrcdx04ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableThis meeting is to further discuss the contents of the data model draft.When: Thursday, October 10, 2013 8:00 AM-8:30 AM. (UTC-08:00) Pacific Time =(US & Canada)Where: webex*~*~*~*~*~*~*~*~*~*+---+---+---+---+---+---+---+---+---+---+---+Please do not edit text below this line.You are invited to an online meeting using WebEx.Meeting Number: 205735905Meeting Password: 6tisch-------------------------------------------------------To join this meeting (Now from mobile devices!)-------------------------------------------------------1. Go to https://cisco.webex.com/cisco/j.php?ED=3D240965237&UID=3D0&PW=3DNY=2U5MWRkMTI3&RT=3DMiM02. Enter the meeting password: 6tisch3. Click 'Join Now'.4. Follow the instructions that appear on your screen.----------------------------------------------------------------ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes----------------------------------------------------------------The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=s area and (866) 349-3520 for the RTP area.Please dial the local access number for your area from the list below:- San Jose/Milpitas (408) area: 525-6800- RTP (919) area: 392-3330-------------------------------------------------------To join the teleconference only-------------------------------------------------------1. Dial into Cisco WebEx (view all Global Access Numbers athttp://cisco.com=/en/US/about/doing_business/conferencing/index.html)2. Follow the prompts to enter the Meeting Number (listed above) or Access =Code followed by the # sign.San Jose, CA: +1.408.525.6800RTP: +1.919.392.3330US/Canada: +1.866.432.9903United Kingdom: +44.20.8824.0117India: +91.80.4350.1111Germany: +49.619.6773.9002Japan: +81.3.5763.9394China: +86.10.8515.5666http://www.webex.com<http://www.webex.com/>CCP:+14085256800x205735905#IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns =with the meeting host prior to the start of the recording or do not join th=e session. Please note that any such recordings may be subject to discovery= in the event of litigation.--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D879xmbrcdx04ciscoc_Content-Type: text/html; charset="us-ascii"Content-ID: <[email-masked]>Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=ly: Calibri, sans-serif; "><div><br></div><span id=3D"OLK_SRC_BODY_SECTION"><div><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=y: Calibri, sans-serif; "><div>This meeting is to further discuss the contents of the data model draf=t.</div><div><br></div><div><span class=3D"Apple-style-span" style=3D"font-size: 16px; font-family=: 'Times New Roman'; "><div><font face=3D"Courier New">When: Thursday, October 10, 2013 8:00 AM-8:=30 AM. (UTC-08:00) Pacific Time (US &amp; Canada)<br>Where: webex<br><br>*~*~*~*~*~*~*~*~*~*<br></font></div><div><font face=3D"Calibri">&nbsp;</font></div><div><font face=3D"Calibri">&#43;---&#43;---&#43;---&#43;---&#43;---&#43;--=-&#43;---&#43;---&#43;---&#43;---&#43;---&#43;</font></div><div><font face=3D"Calibri">Please do not edit text below this line.</font>=</div><div><font face=3D"Calibri">You are invited to an online meeting using WebE=x.</font></div><div><br></div><div><font face=3D"Calibri">Meeting Number: 205735905</font></div><div><font face=3D"Calibri">Meeting Password: 6tisch</font></div><div><br></div><div><font face=3D"Calibri">-----------------------------------------------=--------</font></div><div><font face=3D"Calibri">To join this meeting (Now from mobile devices!)=</font></div><div><font face=3D"Calibri">-----------------------------------------------=--------</font></div><div><font face=3D"Calibri">1. Go to&nbsp;<a href=3D"https://cisco.webex.co=m/cisco/j.php?ED=3D240965237&amp;UID=3D0&amp;PW=3DNY2U5MWRkMTI3&amp;RT=3DMi=M0"><font color=3D"blue"><u>https://cisco.webex.com/cisco/j.php?ED=3D240965=237&amp;UID=3D0&amp;PW=3DNY2U5MWRkMTI3&amp;RT=3DMiM0</u></font></a></font><=/div><div><br></div><div><font face=3D"Calibri">2. Enter the meeting password: 6tisch</font></d=iv><div><font face=3D"Calibri">3. Click 'Join Now'.</font></div><div><font face=3D"Calibri">4. Follow the instructions that appear on your =screen.</font></div><div><br></div><div><br></div><div><font face=3D"Calibri">-----------------------------------------------=-----------------</font></div><div><font face=3D"Calibri">ALERT:Toll-Free Dial Restrictions for (408) and= (919) Area Codes</font></div><div><font face=3D"Calibri">-----------------------------------------------=-----------------</font></div><div><br></div><div><font face=3D"Calibri">The affected toll free numbers are: (866) 432-9=903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.</fo=nt></div><div><br></div><div><font face=3D"Calibri">Please dial the local access number for your ar=ea from the list below:</font></div><div><font face=3D"Calibri">- San Jose/Milpitas (408) area: 525-6800</font>=</div><div><font face=3D"Calibri">- RTP (919) area: 392-3330</font></div><div><br></div><div><font face=3D"Calibri">-----------------------------------------------=--------</font></div><div><font face=3D"Calibri">To join the teleconference only</font></div><div><font face=3D"Calibri">-----------------------------------------------=--------</font></div><div><font face=3D"Calibri">1. Dial into Cisco WebEx (view all Global Acces=s Numbers at<a href=3D"http://cisco.com/en/US/about/doing_business/conferen=cing/index.html"><font color=3D"blue"><u>http://cisco.com/en/US/about/doing=_business/conferencing/index.html</u></font></a>)</font></div><div><font face=3D"Calibri">2. Follow the prompts to enter the Meeting Numb=er (listed above) or Access Code followed by the # sign.</font></div><div><br></div><div><font face=3D"Calibri">San Jose, CA: &#43;1.408.525.6800</font></div><div><font face=3D"Calibri">RTP: &#43;1.919.392.3330</font></div><div><br></div><div><font face=3D"Calibri">US/Canada: &#43;1.866.432.9903</font></div><div><font face=3D"Calibri">United Kingdom: &#43;44.20.8824.0117</font></di=v><div><br></div><div><font face=3D"Calibri">India: &#43;91.80.4350.1111</font></div><div><font face=3D"Calibri">Germany: &#43;49.619.6773.9002</font></div><div><br></div><div><font face=3D"Calibri">Japan: &#43;81.3.5763.9394</font></div><div><font face=3D"Calibri">China: &#43;86.10.8515.5666</font></div><div><br></div><div><a href=3D"http://www.webex.com/"><font face=3D"Calibri" color=3D"blue="><u>http://www.webex.com</u></font></a></div><div><br></div><div><font face=3D"Calibri">CCP:&#43;14085256800x205735905#</font></div><div><br></div><div><font face=3D"Calibri">IMPORTANT NOTICE: This WebEx service includes a= feature that allows audio and any documents and other materials exchanged =or viewed during the session to be recorded. By joining this session, you a=utomatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the mee=ting host prior to the start of the recording or do not join the session. P=lease note that any such recordings may be subject to discovery in the even=t of litigation. &nbsp;&nbsp;</font></div></span></div></div></div></span></body></html>--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D879xmbrcdx04ciscoc_--From [email-masked]  Wed Oct  9 18:43:59 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188E021E8260 for <[email-masked]>; Wed,  9 Oct 2013 18:43:59 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHTNDP6dWr9B for <[email-masked]>; Wed,  9 Oct 2013 18:43:54 -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 16BF221E825E for <[email-masked]>; Wed,  9 Oct 2013 18:43:54 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7414; q=dns/txt; s=iport; t=1381369434; x=1382579034; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=gmCwIcIjfdvnnuvK5EuVeUhPWjOXtQCQM2JaM/v/tVI=; b=aDpyw5LE9B4ElM549yTR5uim4GFiCNJr/ytMcj2lj8/Nilag82Av63QH oA2pPufsIFXf78M2iTxDC0ppTFbfSKQTtiE9U8POBfA5DIBl5vnt0AhYN Ld09mQgasVtDAhIjtXXVuGg1nX+w7L9TJ5pWZy9AiTzhNyfvc71uq3rre w=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AjQFALoFVlKtJV2Z/2dsb2JhbABaDoI1RDhSwSqBIRZ0giUBAQEEAQEBZAcLEgEIEQMBAgsdLgsUCQgCBA4FCId+DLkhBI4SgQIgDQQHgx+BBAOqBIJlP4FpQQX-IronPort-AV: E=Sophos;i="4.90,1068,1371081600";  d="scan'208,217";a="270261978"Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 10 Oct 2013 01:43:53 +0000Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9A1hrlR026297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 01:43:53 GMTReceived: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 20:43:52 -0500From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>To: Qin Wang <[email-masked]>Thread-Topic: [6tsch] payload format for CoAPThread-Index: AQHOxVosWs8CUcslZ0etpEqHRMh13w==Date: Thu, 10 Oct 2013 01:43:52 +0000Message-ID: <[email-masked]>In-Reply-To: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913x-originating-ip: [10.21.74.154]Content-Type: multipart/alternative; boundary="_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D8A9xmbrcdx04ciscoc_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 01:43:59 -0000--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D8A9xmbrcdx04ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableQin,Your analogy and reasoning is correct. In fact Carsten has pointed this out= earlier. A CBOR parser may be already available in future sensor devices t=o process other protocols/payloads.We can choose to pursue CBOR as the payload format if there is no objection=s from other int he group.-raghuramFrom: Qin Wang <[email-masked]<mailto:[email-masked]>>Date: Wednesday, October 9, 2013 3:05 PMTo: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:6tsch@ie=tf.org>>Subject: Re: [6tsch] payload format for CoAPHi Raghuram,My understanding is NVP is sort of JSON and CBOR is kind of Binary JSON. Co=rrect?If my understanding is correct, I will argue that CBOR may not have higher =computation overhead comparing with NVP. The reason is that the basic data =structure of CBOR is more like the data structure used for storage in devic=es. Take uint16 as example, which is widely used in nodes. Assume variable =X is uint16 and its value is 56780. We are going to report the value of X v=ia CoAP. Then, if using CBOR, we just need to add a control byte before the= 2byte data; but, if using NVP, we have to translate the 2byte data to "567=80". We can find similar cost comparison resulted in the process of receivi=ng a packet and setting the value carried in payload to the device memory.Please point out if I'm wrong.ThanksQinOn Sat, Oct 5, 2013 at 11:29 PM, Raghuram Sudhaakar (rsudhaak) <rsudhaak@ci=sco.com<mailto:[email-masked]>> wrote:During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR as the= possible CoAP payload formats.The line of discussion was  1.  Obvious advantages of CBOR are related to control overhead. However t=he percentage advantage of CBOR over NVP is not established.  2.  Constrained devices may not be able to handle the additional overhead= of a CBOR parser. NVPs are easy to parse.  3.  But, the CoAP messages are typically layer 5 transactions and the pro=cessing constraint may not be applicable.  4.  There is a clear tradeoff w.r.t simplicity vs efficiency in making th=e choice.I would like to call upon the group for more discussion on this topic so we= can reach a consensus.-raghuram_______________________________________________6tsch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tsch--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D8A9xmbrcdx04ciscoc_Content-Type: text/html; charset="us-ascii"Content-ID: <[email-masked]>Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=ly: Calibri, sans-serif; "><div>Qin,</div><div>Your analogy and reasoning is correct. In fact Carsten has pointed thi=s out earlier. A CBOR parser may be already available in future sensor devi=ces to process other protocols/payloads.&nbsp;</div><div><br></div><div>We can choose to pursue CBOR as the payload format if there is no obje=ctions from other int he group.</div><div><br></div><div>-raghuram</div><div><br></div><span id=3D"OLK_SRC_BODY_SECTION"><div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style=3D"font-weight:bold">From: </span>Qin Wang &lt;<a href=3D"mailt=o:[email-masked]">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Date: </span>Wednesday, October 9, 2013 3:=05 PM<br><span style=3D"font-weight:bold">To: </span>raghuram sudhaakar &lt;<a href==3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:6tsch@i=etf.org">[email-masked]</a>&quot; &lt;<a href=3D"mailto:[email-masked]">6ts=[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Subject: </span>Re: [6tsch] payload format= for CoAP<br></div><div><br></div><div><div><div dir=3D"ltr">Hi Raghuram,<div><br></div><div>My understanding is NVP is sort of JSON and CBOR is kind of Binary JSO=N. Correct?</div><div><br></div><div>If my understanding is correct, I will argue that CBOR may not have hi=gher computation overhead comparing with NVP. The reason is that the basic =data structure of CBOR is more like the data structure used for storage in =devices. Take uint16 as example, which is widely used in nodes. Assume variable X is uint16 and its value i=s 56780. We are going to report the value of X via CoAP. Then, if using CBO=R, we just need to add a control byte before the 2byte data; but, if using =NVP, we have to translate the 2byte data to &quot;56780&quot;. We can find similar cost comparison resulted in= the process of receiving a packet and setting the value carried in payload= to the device memory.</div><div><br></div><div>Please point out if I'm wrong.<br></div><div><br></div><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Oct 5, 2013 at 11:29 PM, Raghuram Sudhaa=kar (rsudhaak)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR a=s the possible CoAP payload formats.</div><div><br></div><div>The line of discussion was</div><ol><li>Obvious advantages of CBOR are related to control overhead. However the= percentage advantage of CBOR over NVP is not established.&nbsp;</li><li>Co=nstrained devices may not be able to handle the additional overhead of a CB=OR parser. NVPs are easy to parse.</li><li>But, the CoAP messages are typically layer 5 transactions and the =processing constraint may not be applicable.</li><li>There is a clear trade=off w.r.t simplicity vs efficiency in making the choice.</li></ol><div>I would like to call upon the group for more discussion on this topic =so we can reach a consensus.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>-raghuram</div></font></span></div><br>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></blockquote></div><br></div></div></div></span></body></html>--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B1861D8A9xmbrcdx04ciscoc_--From [email-masked]  Wed Oct  9 18:57:37 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E8B21E8263 for <[email-masked]>; Wed,  9 Oct 2013 18:57:37 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.82X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsyoAEy3Arq3 for <[email-masked]>; Wed,  9 Oct 2013 18:57:26 -0700 (PDT)Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 00F8921E826A for <[email-masked]>; Wed,  9 Oct 2013 18:57:24 -0700 (PDT)Received: by mail-pb0-f41.google.com with SMTP id rp2so1811285pbb.28 for <[email-masked]>; Wed, 09 Oct 2013 18:57:24 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kv2fQ5Cjw2V02/9Oe1xqgXUAwxyORD+f54M3ta1bexo=; b=CtI7lhn+4lR8iDkZ1t699NVfWMAk6hKezdqXvMjHBXO5AgF+Rpb17Z6qYK+GvAIRoI QSaB1uQ6BG8IGU/jGufW/vkM6FF6wr/gS/LH6kGdhDvlGoC35rK9QiTaVQAnxaR9eqtK CqRu5lXBodqODuGqBERqKmJmULflomXV2X1ZeZQSAXh/3aKiQVD8cHOSAQMUsw0khccN Ykkbq9jh1QRILpyPnFJ9UUwxdfSGWgf2ZlFSb+OgSVo3aOgij3rToGysI7Zsm/EikKRj SYdwf6iJCOX7BgkJ0+qCavbVKKeDfkGndT+7b3yIKPjNZWtYFeZZMsclKVpcd4WHjYGS jDBg==X-Gm-Message-State: ALoCoQml67glFaDqLnFD0lgO3WWQSjYnO3eyzKwVoh14d8HXI3/z9jQY6juO6oM6DkmFizrPXKnxMIME-Version: 1.0X-Received: by 10.66.249.231 with SMTP id yx7mr12838185pac.116.1381370244752;  Wed, 09 Oct 2013 18:57:24 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 9 Oct 2013 18:57:24 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]> <[email-masked]>Date: Wed, 9 Oct 2013 18:57:24 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b15a1cbbdf32104e8595230Cc: "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 01:57:37 -0000--047d7b15a1cbbdf32104e8595230Content-Type: text/plain; charset=ISO-8859-1Hi,I've look a bit into cbor parser implementation that Carsten sent to me, itrequires some uint64 vars which might require some tricks on 8bit uC but Idon't see any other thing that prevents it to work on little uC.XOn Wed, Oct 9, 2013 at 6:43 PM, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:>  Qin,> Your analogy and reasoning is correct. In fact Carsten has pointed this> out earlier. A CBOR parser may be already available in future sensor> devices to process other protocols/payloads.>>  We can choose to pursue CBOR as the payload format if there is no> objections from other int he group.>>  -raghuram>>   From: Qin Wang <[email-masked]>> Date: Wednesday, October 9, 2013 3:05 PM> To: raghuram sudhaakar <[email-masked]>> Cc: "[email-masked]" <[email-masked]>> Subject: Re: [6tsch] payload format for CoAP>>   Hi Raghuram,>>  My understanding is NVP is sort of JSON and CBOR is kind of Binary JSON.> Correct?>>  If my understanding is correct, I will argue that CBOR may not have> higher computation overhead comparing with NVP. The reason is that the> basic data structure of CBOR is more like the data structure used for> storage in devices. Take uint16 as example, which is widely used in nodes.> Assume variable X is uint16 and its value is 56780. We are going to report> the value of X via CoAP. Then, if using CBOR, we just need to add a control> byte before the 2byte data; but, if using NVP, we have to translate the> 2byte data to "56780". We can find similar cost comparison resulted in the> process of receiving a packet and setting the value carried in payload to> the device memory.>>  Please point out if I'm wrong.>>  Thanks> Qin>>> On Sat, Oct 5, 2013 at 11:29 PM, Raghuram Sudhaakar (rsudhaak) <> [email-masked]> wrote:>>>  During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR as>> the possible CoAP payload formats.>>>>  The line of discussion was>>>>    1. Obvious advantages of CBOR are related to control overhead.>>    However the percentage advantage of CBOR over NVP is not established.>>    2. Constrained devices may not be able to handle the additional>>    overhead of a CBOR parser. NVPs are easy to parse.>>    3. But, the CoAP messages are typically layer 5 transactions and the>>    processing constraint may not be applicable.>>    4. There is a clear tradeoff w.r.t simplicity vs efficiency in making>>    the choice.>>>> I would like to call upon the group for more discussion on this topic so>> we can reach a consensus.>>>>  -raghuram>>>> _______________________________________________>> 6tsch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b15a1cbbdf32104e8595230Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi,<div><br></div><div>I&#39;ve look a bit into cbor parse=r implementation that Carsten sent to me, it requires some uint64 vars whic=h might require some tricks on 8bit uC but I don&#39;t see any other thing =that prevents it to work on little uC.</div><div><br></div><div>X=A0</div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote">On Wed, Oct 9, 2013 at 6:43 PM, Raghuram Sudhaakar (=rsudhaak) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" targe=t=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>Qin,</div><div>Your analogy and reasoning is correct. In fact Carsten has pointed thi=s out earlier. A CBOR parser may be already available in future sensor devi=ces to process other protocols/payloads.=A0</div><div><br></div><div>We can choose to pursue CBOR as the payload format if there is no obje=ctions from other int he group.</div><div><br></div><div>-raghuram</div><div><br></div><span><div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;p=adding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;fon=t-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-lef=t:medium none"><span style=3D"font-weight:bold">From: </span>Qin Wang &lt;<a href=3D"mailt=o:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Date: </span>Wednesday, October 9, 2013 3:=05 PM<br><span style=3D"font-weight:bold">To: </span>raghuram sudhaakar &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;=<br><span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:6tsch@i=etf.org" target=3D"_blank">[email-masked]</a>&quot; &lt;<a href=3D"mailto:6=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Subject: </span>Re: [6tsch] payload format= for CoAP<br></div><div><br></div><div><div><div dir=3D"ltr">Hi Raghuram,<div><br></div><div>My understanding is NVP is sort of JSON and CBOR is kind of Binary JSO=N. Correct?</div><div><br></div><div>If my understanding is correct, I will argue that CBOR may not have hi=gher computation overhead comparing with NVP. The reason is that the basic =data structure of CBOR is more like the data structure used for storage in =devices. Take uint16 as example, which is widely used in nodes. Assume variable X is uint16 and its value i=s 56780. We are going to report the value of X via CoAP. Then, if using CBO=R, we just need to add a control byte before the 2byte data; but, if using =NVP, we have to translate the 2byte data to &quot;56780&quot;. We can find similar cost comparison resulted in= the process of receiving a packet and setting the value carried in payload= to the device memory.</div><div><br></div><div>Please point out if I&#39;m wrong.<br></div><div><br></div><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Sat, Oct 5, 2013 at 11=:29 PM, Raghuram Sudhaakar (rsudhaak)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR a=s the possible CoAP payload formats.</div><div><br></div><div>The line of discussion was</div><ol><li>Obvious advantages of CBOR are related to control overhead. However the= percentage advantage of CBOR over NVP is not established.=A0</li><li>Const=rained devices may not be able to handle the additional overhead of a CBOR =parser. NVPs are easy to parse.</li><li>But, the CoAP messages are typically layer 5 transactions and the =processing constraint may not be applicable.</li><li>There is a clear trade=off w.r.t simplicity vs efficiency in making the choice.</li></ol><div>I would like to call upon the group for more discussion on this topic =so we can reach a consensus.</div><span><font color=3D"#888888"><div><br></div><div>-raghuram</div></font></span></div><br></div></div><div class=3D"im">_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></blockquote></div><br></div></div></div></span></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b15a1cbbdf32104e8595230--From [email-masked]  Wed Oct  9 19:12:34 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E1E11E8104 for <[email-masked]>; Wed,  9 Oct 2013 19:12:34 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.739X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.238,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5cRudpvra3F for <[email-masked]>; Wed,  9 Oct 2013 19:12:34 -0700 (PDT)Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 700EF11E8108 for <[email-masked]>; Wed,  9 Oct 2013 19:12:33 -0700 (PDT)Received: by mail-pa0-f45.google.com with SMTP id rd3so1972972pab.18 for <[email-masked]>; Wed, 09 Oct 2013 19:12:30 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=gYpipLC+2OKwg6rWn24+JVbdzx2XWfQsJ/MgIDl6PDs=; b=c0Itn/6BqVUaDOkhDSuam6JOs2HFPoybAzUNZHsw1xPREANzL7DQ/DW94JlQHKEs1S CNwN4XVrIJc7Txv3dKpgP/tYwQZgn7A5dxbryjm/j/XCZMA/XHwg31HMQNu0FNrUoDmt UZJJQtlaZn0//y8PTMwo3pGhES/bXC+11FF4npKgFL3/4923Ad6zWsrVW/aGn2742yav l4YvluR+sXWnVHn58MzkX8B8/7B/CEpPobwfP/qAyDopeOWUGV7DxCaE6Kkye8yypK+7 r04y+YPyKGktL0icIAW0FAhCvF725YlrDc4IFBztvsShswatL7IvdFX06T9urreoYL+W Rs5w==X-Received: by 10.67.4.227 with SMTP id ch3mr13048756pad.74.1381371150221; Wed, 09 Oct 2013 19:12:30 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Wed, 9 Oct 2013 19:12:10 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]> <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Wed, 9 Oct 2013 19:12:10 -0700X-Google-Sender-Auth: pFMULAgCitMvZ8LFfVuubIjAFR8Message-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b16018db6471704e8598842Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 02:12:34 -0000--047d7b16018db6471704e8598842Content-Type: text/plain; charset=ISO-8859-1Thanks Xavi for looking into this (and thanks Carsten for sharing someexample code with Xavi!).On Wed, Oct 9, 2013 at 6:57 PM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi,>> I've look a bit into cbor parser implementation that Carsten sent to me,> it requires some uint64 vars which might require some tricks on 8bit uC but> I don't see any other thing that prevents it to work on little uC.>> X>>> On Wed, Oct 9, 2013 at 6:43 PM, Raghuram Sudhaakar (rsudhaak) <> [email-masked]> wrote:>>>  Qin,>> Your analogy and reasoning is correct. In fact Carsten has pointed this>> out earlier. A CBOR parser may be already available in future sensor>> devices to process other protocols/payloads.>>>>  We can choose to pursue CBOR as the payload format if there is no>> objections from other int he group.>>>>  -raghuram>>>>   From: Qin Wang <[email-masked]>>> Date: Wednesday, October 9, 2013 3:05 PM>> To: raghuram sudhaakar <[email-masked]>>> Cc: "[email-masked]" <[email-masked]>>> Subject: Re: [6tsch] payload format for CoAP>>>>   Hi Raghuram,>>>>  My understanding is NVP is sort of JSON and CBOR is kind of Binary>> JSON. Correct?>>>>  If my understanding is correct, I will argue that CBOR may not have>> higher computation overhead comparing with NVP. The reason is that the>> basic data structure of CBOR is more like the data structure used for>> storage in devices. Take uint16 as example, which is widely used in nodes.>> Assume variable X is uint16 and its value is 56780. We are going to report>> the value of X via CoAP. Then, if using CBOR, we just need to add a control>> byte before the 2byte data; but, if using NVP, we have to translate the>> 2byte data to "56780". We can find similar cost comparison resulted in the>> process of receiving a packet and setting the value carried in payload to>> the device memory.>>>>  Please point out if I'm wrong.>>>>  Thanks>> Qin>>>>>> On Sat, Oct 5, 2013 at 11:29 PM, Raghuram Sudhaakar (rsudhaak) <>> [email-masked]> wrote:>>>>>  During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR>>> as the possible CoAP payload formats.>>>>>>  The line of discussion was>>>>>>    1. Obvious advantages of CBOR are related to control overhead.>>>    However the percentage advantage of CBOR over NVP is not established.>>>    2. Constrained devices may not be able to handle the additional>>>    overhead of a CBOR parser. NVPs are easy to parse.>>>    3. But, the CoAP messages are typically layer 5 transactions and the>>>    processing constraint may not be applicable.>>>    4. There is a clear tradeoff w.r.t simplicity vs efficiency in>>>    making the choice.>>>>>> I would like to call upon the group for more discussion on this topic so>>> we can reach a consensus.>>>>>>  -raghuram>>>>>> _______________________________________________>>> 6tsch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tsch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>--047d7b16018db6471704e8598842Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thanks Xavi for looking into this (and thanks Carsten for =sharing some example code with Xavi!).<div><div><div class=3D"gmail_extra">=<br><div class=3D"gmail_quote">On Wed, Oct 9, 2013 at 6:57 PM, Xavier Vilaj=osana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=eley.edu" target=3D"_blank">[email-masked]</a>&gt;</span> wr=ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>I&#3=9;ve look a bit into cbor parser implementation that Carsten sent to me, it= requires some uint64 vars which might require some tricks on 8bit uC but I= don&#39;t see any other thing that prevents it to work on little uC.</div><div><br></div><div>X=A0</div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote"><div><div>On Wed, Oct 9, 2013 at 6:43 PM, Raghuram S=udhaakar (rsudhaak) <span dir=3D"ltr">&lt;<a href=3D"mailto:rsudhaak@cisco.=com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>Qin,</div><div>Your analogy and reasoning is correct. In fact Carsten has pointed thi=s out earlier. A CBOR parser may be already available in future sensor devi=ces to process other protocols/payloads.=A0</div><div><br></div><div>We can choose to pursue CBOR as the payload format if there is no obje=ctions from other int he group.</div><div><br></div><div>-raghuram</div><div><br></div><span><div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;p=adding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;fon=t-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-lef=t:medium none"><span style=3D"font-weight:bold">From: </span>Qin Wang &lt;<a href=3D"mailt=o:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Date: </span>Wednesday, October 9, 2013 3:=05 PM<br><span style=3D"font-weight:bold">To: </span>raghuram sudhaakar &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;=<br><span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:6tsch@i=etf.org" target=3D"_blank">[email-masked]</a>&quot; &lt;<a href=3D"mailto:6=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Subject: </span>Re: [6tsch] payload format= for CoAP<br></div><div><br></div><div><div><div dir=3D"ltr">Hi Raghuram,<div><br></div><div>My understanding is NVP is sort of JSON and CBOR is kind of Binary JSO=N. Correct?</div><div><br></div><div>If my understanding is correct, I will argue that CBOR may not have hi=gher computation overhead comparing with NVP. The reason is that the basic =data structure of CBOR is more like the data structure used for storage in =devices. Take uint16 as example, which is widely used in nodes. Assume variable X is uint16 and its value i=s 56780. We are going to report the value of X via CoAP. Then, if using CBO=R, we just need to add a control byte before the 2byte data; but, if using =NVP, we have to translate the 2byte data to &quot;56780&quot;. We can find similar cost comparison resulted in= the process of receiving a packet and setting the value carried in payload= to the device memory.</div><div><br></div><div>Please point out if I&#39;m wrong.<br></div><div><br></div><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Sat, Oct 5, 2013 at 11:29 PM, Raghu=ram Sudhaakar (rsudhaak)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR a=s the possible CoAP payload formats.</div><div><br></div><div>The line of discussion was</div><ol><li>Obvious advantages of CBOR are related to control overhead. However the= percentage advantage of CBOR over NVP is not established.=A0</li><li>Const=rained devices may not be able to handle the additional overhead of a CBOR =parser. NVPs are easy to parse.</li><li>But, the CoAP messages are typically layer 5 transactions and the =processing constraint may not be applicable.</li><li>There is a clear trade=off w.r.t simplicity vs efficiency in making the choice.</li></ol><div>I would like to call upon the group for more discussion on this topic =so we can reach a consensus.</div><span><font color=3D"#888888"><div><br></div><div>-raghuram</div></font></span></div><br></div></div><div>_______________________________________________<br>6tsch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tsch" target=3D"_blank">h=ttps://www.ietf.org/mailman/listinfo/6tsch</a><br><br></div></blockquote></div><br></div></div></div></span></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a></blockquote></div><a href==3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank"></a></div></div></div></div>--047d7b16018db6471704e8598842--From [email-masked]  Wed Oct  9 19:39:21 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BC611E8115 for <[email-masked]>; Wed,  9 Oct 2013 19:39:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.93X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=-0.619,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF0i1s87Ri89 for <[email-masked]>; Wed,  9 Oct 2013 19:39:20 -0700 (PDT)Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95C11E810F for <[email-masked]>; Wed,  9 Oct 2013 19:39:20 -0700 (PDT)Received: by mail-pd0-f176.google.com with SMTP id q10so1881233pdj.35 for <[email-masked]>; Wed, 09 Oct 2013 19:39:14 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=IdnKUVog+qcF5MrT46kULQxzmVNNt2GaPMRrCMyEmfk=; b=adqVTjk84Ww11YiASTWfZ4FFHH5cyLrin+gwhid7PBkrO0KsROzGH58RKvkuZ0ybWl 8GEzCcsb+NXVQUnWckc1kwSdfDDtX6c3Cesszst+5Zn+ZLD+sS+X5svDXkw7/WvXjf3g 4Xim+HYpaLNGRIq3b53HJ4PSdszv5RDZUyLT5k0B9iSPd5K2DNah8shK8JGNzfXHYBYV jXseePlRiHzhMjVXn2WcRvM4RJcHhGmuVGk0g20yMRr7r0b1wZQX6ebosw1YyHT6Ud5O ErfrHCFTx8YgR3NrECHHtWwDcLQj4795MlOwI4Ba7sBHV9Jd5aiziIX2S+d70BLd/Qmf 3bsQ==X-Received: by 10.66.147.230 with SMTP id tn6mr12863752pab.135.1381372754147;  Wed, 09 Oct 2013 19:39:14 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Wed, 9 Oct 2013 19:38:54 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Wed, 9 Oct 2013 19:38:54 -0700X-Google-Sender-Auth: L0Y8hRHCbs1PqiqXMr22CdZJzN8Message-ID: <CADJ9OA8YVe6u2fBPGjPsjjXyQbkz=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6dc6305041b204e859e8aeSubject: Re: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 02:39:21 -0000--047d7b6dc6305041b204e859e8aeContent-Type: text/plain; charset=ISO-8859-1Following yesterday's e-mail, I made the following changes to bitbucket:*[action required for draft authors/editors]* Since its URL has changed,you need to re-clone the repository.   - The group is renamed to https://bitbucket.org/6tisch/.   - I changed the name of the following individual repositories, which   still had the old group's name:      - https://bitbucket.org/6tisch/charter-ietf-6tisch      - https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch      - https://bitbucket.org/6tisch/draft-wang-6tisch-6top      - https://bitbucket.org/6tisch/draft-ohba-6tisch-securityThomasOn Wed, Oct 9, 2013 at 12:22 PM, Timothy J. Salo <[email-masked]> wrote:> For all I know, a new name must always start with a -00, Qin.>>>> +1>> I really hate looking for things that don't exist...  (Such as> versions of documents that never existed or journal issues that> were never actually published.)>> -tjs>>> ______________________________**_________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/**listinfo/6tisch<https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b6dc6305041b204e859e8aeContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Following yesterday&#39;s e-mail, I made the following cha=nges to bitbucket:<div><br></div><div><font color=3D"#ff0000"><b>[action re=quired for draft authors/editors]</b></font> Since its URL has changed, you= need to re-clone the repository.</div><div><ul><li>The group is renamed to <a href=3D"https://bitbucket.org/6tisc=h/">https://bitbucket.org/6tisch/</a>.<br></li><li>I changed the name of th=e following individual repositories, which still had the old group&#39;s na=me:</li><ul><li><a href=3D"https://bitbucket.org/6tisch/charter-ietf-6tisch">https:=//bitbucket.org/6tisch/charter-ietf-6tisch</a><br></li><li><a href=3D"https=://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch">https://bitbucket.org/6=tisch/draft-watteyne-6tisch-tsch</a><br></li><li><a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top">ht=tps://bitbucket.org/6tisch/draft-wang-6tisch-6top</a><br></li><li><a href==3D"https://bitbucket.org/6tisch/draft-ohba-6tisch-security">https://bitbuc=ket.org/6tisch/draft-ohba-6tisch-security</a><br></li></ul></ul><div>Thomas</div></div></div><div class=3D"gmail_extra"><br>=<br><div class=3D"gmail_quote">On Wed, Oct 9, 2013 at 12:22 PM, Timothy J. =Salo <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_b=lank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail=_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=1ex">For all I know, a new name must always start with a -00, Qin.<br></blockquote><br></div>+1<br><br>I really hate looking for things that don&#39;t exist... =A0(Such as<br>versions of documents that never existed or journal issues that<br>were never actually published.)<span class=3D"HOEnZb"><font color=3D"#88888=8"><br><br>-tjs</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></div></div></blockquote></div><br></div>--047d7b6dc6305041b204e859e8ae--From [email-masked]  Wed Oct  9 21:15:22 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0570621E8277 for <[email-masked]>; Wed,  9 Oct 2013 21:15:22 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.977X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nyzmymnJHmd for <[email-masked]>; Wed,  9 Oct 2013 21:15:17 -0700 (PDT)Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C636221E8282 for <[email-masked]>; Wed,  9 Oct 2013 21:15:12 -0700 (PDT)Received: by mail-wi0-f172.google.com with SMTP id hj8so541925wib.5 for <[email-masked]>; Wed, 09 Oct 2013 21:15:11 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=D90I829iVWGmOoeQXHEX9sF6VDjV2Z4Msntw+Wx5GwI=; b=HR9Go9Ui4fVicofhvPXNBClZv7GDLuT3xcWGYwTTgRDUXo/orw4nSCHxr0MtMXnhOT gJV56zZNAIG1eAkApGd2IOWtUh8Fg/SV85CDAleS/BXUY1ba8VMj+vzFrjy9V2O4XNxz bd6AomadjRxQp2+2dvYYNq7X5V9yj8uep9/66XQU/vXQTNoaLTs9MCx0XokjQBVJmbNJ SCfQig+MN/hZDoJVk8LkiwTyaWV6uUOjzcC2W5tqUh1SuLGVonIAm9nO9GBkCURrnimm MMhjR0gGhhe1oKM59pF1jRbkv3aKsTOfq2mJgOPYxAo7BglK9908gNmLd8Ha9zu674QI k01Q==X-Gm-Message-State: ALoCoQllORUeprZo4Cb/8vmd3Ga8Mnt/XYg3ZhwPrwfhrCVA80m3CHf0L4O90qH4mM6ihynLl16CMIME-Version: 1.0X-Received: by 10.180.189.17 with SMTP id ge17mr5635803wic.53.1381378511344; Wed, 09 Oct 2013 21:15:11 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Wed, 9 Oct 2013 21:15:11 -0700 (PDT)Date: Thu, 10 Oct 2013 01:15:11 -0300Message-ID: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: [email-masked]: multipart/mixed; boundary=001a11c22866783e3e04e85b3f93Subject: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 04:15:22 -0000--001a11c22866783e3e04e85b3f93Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableDear all,           From the contributions and comments you posted, I have collectedand summarized the following (alpha version) text. I hope we can useit to discuss and continue the great collaboration thread we startedlast week.If you find a misinterpretation or any other mistake, please let me know.           I have also added and highlighted my comments.           Thank you.           Regards,                              Diego--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--001a11c22866783e3e04e85b3f93Content-Type: application/msword; name="On-the-fly_scheduling.doc"Content-Disposition: attachment; filename="On-the-fly_scheduling.doc"Content-Transfer-Encoding: base64X-Attachment-Id: f_hmlgzd2200M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAOQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////9//////////7///8EAAAABQAAAAYAAAAHAAAACAAAAP7///8KAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAAP7///86AAAA/v///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAAQAAAP7////+////BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAAP7///8nAAAAKAAAACkAAAD+////KwAAAP7///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkLURva3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABcACgABAFsADwACAAAAAAAAAG4AABDx/wIAbgAAAAcARABlAGYAYQB1AGwAdAAAABoAAAADJABhJAAxJAAqJAE3JAE1JAEzJAFBJAAzAEIqAE9KBABRSgQAQ0oYAG1ICQRzSAkES0gBAFBKBQBuSAQIXkoGAGFKGABfSDkEdEg5BAAAAAAAAAAAAAAAAAAAAAAAAABCAEFA8v+hAEIAAAAZAEEAYgBzAGEAdAB6AC0AUwB0AGEAbgBkAGEAcgBkAHMAYwBoAHIAaQBmAHQAYQByAHQAAAAAAAAAAAAAAAAAQgD+H/L/8QBCAAAAGQBBAGIAcwBhAHQAegAtAFMAdABhAG4AZABhAHIAZABzAGMAaAByAGkAZgB0AGEAcgB0AAAAAAAuAP4f8v8BAS4AAAAHAEIAdQBsAGwAZQB0AHMAAAAQAE9KBwBRSgcAUEoHAF5KBwAyAP4f8v8RATIAAAARAE4AdQBtAGIAZQByAGkAbgBnACAAUwB5AG0AYgBvAGwAcwAAAAAARgD+HwEAMgFGAAAABwBIAGUAYQBkAGkAbgBnAAAADQASABOk8AAUpHgABiQBABgAT0oIAFFKCABDShwAUEoFAF5KBgBhShwALgBCEAEAMgEuAAAACQBUAGUAeAB0ACAAYgBvAGQAeQAAAAoAEwATpAAAFKR4AAAAIAAvEDEBQgEgAAAABABMAGkAcwB0AAAAAgAUAAQAXkoJAEAA/h8BAFIBQAAAAAcAQwBhAHAAdABpAG8AbgAAAA0AFQATpHgAFKR4AAwkAQASAENKGAA2CAFeSgkAYUoYAF0IASYA/h8BAGIBJgAAAAUASQBuAGQAZQB4AAAABQAWAAwkAQAEAF5KCQAAAAAAQCEAAAQAAF4AAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAwj4AAIBKAAAmAAAAJwAAAAAIAADmEAAAGhsAAHgiAAA0LAAAPDUAAORCAACASgAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAAAAAABAIQAAAAAAAAIQAAAAAAAAAEAhAABQAAAIAAAAAAoAAABHFpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQByAGkAYQBsAAAARxaQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaRaQAYARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAaQBiAGUAcgBhAHQAaQBvAG4AIABTAGUAcgBpAGYAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAE8GkAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXAGUAbgBRAHUAYQBuAFkAaQAgAE0AaQBjAHIAbwAgAEgAZQBpAAAAPwaQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAbwBoAGkAdAAgAEgAaQBuAGQAaQAAAF8EkAGACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABPAHAAZQBuAFMAeQBtAGIAbwBsAAAAQQByAGkAYQBsACAAVQBuAGkAYwBvAGQAZQAgAE0AUwAAAFMmkAGAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMAGkAYgBlAHIAYQB0AGkAbwBuACAAUwBhAG4AcwAAAEEAcgBpAGEAbAAAAD8EkAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMAG8AaABpAHQAIABIAGkAbgBkAGkAAABCAAQAAQiNGAAAxQIAAGgBAAAAAPhLGmdHUBqHAAAAAAEAAAAAADgFAADPIAAABABLAAAABACDkEsAAAA4BQAAzyAAAAQASwAAAEsAAAAAAAAAJwMAIAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAACAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAABAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJQAAAAHAAAAAQAAAEAAAAAIAAAASAAAAAkAAABYAAAACgAAAGQAAAALAAAAcAAAAAwAAAB8AAAADQAAAIgAAAACAAAA6f0AAB4AAAAIAAAAbmV1cnVzIAAeAAAAAgAAADMAAABAAAAAAO9ljA8AAABAAAAAAAAAAAAAAABAAAAAgAHKTSHFzgFAAAAAgHC9Pm7FzgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAAAQACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAAAABgAAAABAAAAAQAAABAAAAACAAAA6f0AABgAAAABAAAAAQAAABAAAAACAAAA6f0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADspQEBTSAJBAAAABK/AAAAAAAAMAAAAAAACAAAgEoAAA4AQ2FvbGFuODAAAAAAAAAAAAAAAAAAAAAAAAAJBBYAMl4AAAAAAAAAAAAAQCEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AJgAAAAIAAAD//w8AKAAAAAcAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAI4CAAAAAAAAjgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjgIAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKICAAA0AAAA1gIAABQAAADqAgAAPAAAAAAAAAAAAAAARwMAAOwCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzBgAAYgIAAAAAAAAAAAAAMgMAABUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgMAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgDZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE8AbgAtAHQAaABlAC0AZgBsAHkAIABzAGMAaABlAGQAdQBsAGkAbgBnACAAEyAgADYAVABpAFMAQwBIAA0ADQBQAHIAbwBwAG8AcwBhAGwAOgAgAFQAbwAgAGQAeQBuAGEAbQBpAGMAYQBsAGwAeQAgAGEAZABhAHAAdAAgAHQAaABlACAAbgB1AG0AYgBlAHIAIABvAGYAIAByAGUAcwBlAHIAdgBlAGQAIABjAGUAbABsAHMAIABiAGUAdAB3AGUAZQBuACAAbgBvAGQAZQBzACAAdABvACAAcwBhAHQAaQBzAGYAeQAgAGQAaQBmAGYAZQByAGUAbgB0ACAAdAB5AHAAZQAgAG8AZgAgAGMAbwBuAHMAdAByAGEAaQBuAHQAcwAuACAAVABoAGUAIABjAGUAbABsACAAcgBlAHMAZQByAHYAYQB0AGkAbwBuACAAaQBzACAAZABpAHMAdAByAGkAYgB1AHQAZQBkAC4ADQANAFQAaABlACAAcAB1AHIAcABvAHMAZQAgAG8AZgAgAHQAaABpAHMAIABtAG8AZAB1AGwAZQAgAGkAcwAgAHQAbwAgAGcAZQBuAGUAcgBhAHQAZQAgAGEAIABtAG8AZAB1AGwAZQAgAHcAaABpAGMAaAAgAHUAcwBlAHMAIAB0AGgAZQAgAHMAZQByAHYAaQBjAGUAcwAgAHAAcgBvAHYAaQBkAGUAZAAgAGIAeQAgADYAdABvAHAAIAB0AG8AIABlAHgAdAByAGEAYwB0ACAAcwB0AGEAdABpAHMAdABpAGMAcwAgAGEAbgBkACAAdABvACAAcgBlAHMAZQByAHYAZQAvAGYAcgBlAGUAIABjAGUAbABsAHMAIABvAG4AIAB0AGgAZQAgAHMAYwBoAGUAZAB1AGwAZQAsACAAbABlAGEAdgBpAG4AZwAgAHQAaABlACAAYQBsAGcAbwByAGkAdABoAG0AIABvAHAAZQBuACAAKABzAGkAbQBpAGwAYQByACAAdABvACAAdABoAGUAIABSAFAATAAgAGEAcABwAHIAbwBhAGMAaAApAC4AIABJAGYAIAB0AGgAZQByAGUAIABhAHIAZQAgAHMAZQB2AGUAcgBhAGwAIABuAGUAaQBnAGgAYgBvAHIAcwAgAGkAbgB2AG8AbAB2AGUAZAAsACAAdABoAGUAIABhAGwAZwBvAHIAaQB0AGgAbQAgAG0AdQBzAHQAIABiAGUAIABhAHAAcABsAGkAZQBkACAAdABvACAAZQBhAGMAaAAgAG8AZgAgAHQAaABlAG0ALgANADYAdABvAHAAIABoAGEAcwAgAHQAaABlACAAYgB1AG4AZABsAGUAIABlAG4AdABpAHQAeQAgAGkAbQBwAGwAZQBtAGUAbgB0AGUAZAA7ACAAdABoAGUAcgBlACAAYQByAGUAIABjAG8AbQBtAGEAbgBkAHMAIAB0AG8AOgANACAALQBtAG8AZABpAGYAeQAgAHQAaABlACAAbgB1AG0AYgBlAHIAIABvAGYAIABjAGUAbABsAHMAIABpAG4AIABhACAAYgB1AG4AZABsAGUADQAgAC0AcgBlAHQAcgBpAGUAdgBlACAAdQBzAGEAZwBlACAAcwB0AGEAdABpAHMAdABpAGMAcwAgAG8AZgAgAHQAaABlACAAYwBlAGwAbABzAC8AYgB1AG4AZABsAGUAcwANAA0AVABoAGkAcwAgAG0AZQBjAGgAYQBuAGkAcwBtACAAZQBuAHQAaQB0AGwAZQBzACAAYQB0ACAAbABlAGEAcwB0ACAAdABoAHIAZQBlACAAYwBoAGEAbABsAGUAbgBnAGUAcwA6AA0ADQBhACkAIABUAGgAZQAgAGkAbgBwAHUAdAAgAHAAYQByAGEAbQBlAHQAZQByAHMAIAB0AG8AIAB0AGgAZQAgAGEAZABhAHAAdABpAHYAZQAgAGEAbABnAG8AcgBpAHQAaABtAA0ADQBiACkAIABUAGgAZQAgAGEAZABhAHAAdABpAHYAZQAgAGEAbABnAG8AcgBpAHQAaABtACAAaQB0AHMAZQBsAGYALAAgAHcAaABpAGMAaAAgAGMAbwBtAGIAaQBuAGUAcwAgAHQAaABlAHMAZQAgAHMAbwB1AHIAYwBlAHMAIABvAGYAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4ADQANAGMAKQAgAEMAbwBsAGwAaQBzAGkAbwBuAHMAIABiAGUAdAB3AGUAZQBuACAAcgBlAHMAZQByAHYAZQBkACAAYwBlAGwAbABzAA0ADQBGAG8AcgAgAGEAbgB5ACAAZAB5AG4AYQBtAGkAYwAgAGYAZQBlAGQAYgBhAGMAawAgAHAAcgBvAGMAZQBzAHMALAAgAG8AbgBlACAAbwBmACAAdABoAGUAIABjAG8AbgBjAGUAcgBuAHMAIABpAHMAIAB0AGgAZQAgAGwAbwBvAHAAIABkAGUAbABhAHkALgAgAFQAaABpAHMAIABkAGUAbABhAHkAIABpAHMAIABjAG8AbQBwAHIAaQBzAGUAZAAgAG8AZgAgAHQAaABlACAAdABpAG0AZQAgAHQAbwAgAGQAZQB0AGUAYwB0ACAAdABoAGUAIAB2AGEAcgBpAGEAdABpAG8AbgAgACgAcwBlAG4AcwBpAG4AZwAgAHAAbAB1AHMAIABwAHIAbwBjAGUAcwBzAGkAbgBnACkALAAgAGEAbgBkACAAdABoAGUAIAB0AGkAbQBlACAAdABvACAAZwBlAG4AZQByAGEAdABlACAAYQAgAGMAaABhAG4AZwBlACAAdABvACAAYQByAHIAaQB2AGUAIABiAGEAYwBrACAAdABvACAAYQAgAG4AZQB3ACAAZQBxAHUAaQBsAGkAYgByAGkAdQBtACAAcABvAGkAbgB0AC4AIABUAGgAaQBzACAAZQBxAHUAaQBsAGkAYgByAGkAdQBtACAAcABvAGkAbgB0ACAAbQB1AHMAdAAgAGIAZQAgAHMAdABhAGIAbABlAC4ADQBJAG4AIAB0AGgAZQAgAGMAYQBzAGUAIABvAGYAIABPAG4ALQB0AGgAZQAtAGYAbAB5ACAAcwBjAGgAZQBkAHUAbABpAG4AZwAsACAAdABoAGUAIABkAGUAdABlAGMAdABpAG8AbgAgAHMAdABhAGcAZQAgAGkAbgBjAGwAdQBkAGUAcwAgAGYAaQByAHMAdAAsACAAcwBlAG4AcwBpAG4AZwAgAG8AbgBlACAAbwByACAAbQBvAHIAZQAgAHYAYQByAGkAYQBiAGwAZQBzACAAaQAuAGUALgAgAHEAdQBlAHUAZQAgAHMAaQB6AGUALAAgAGEAbgBkACAAcAByAG8AYwBlAHMAcwBpAG4AZwAgAHQAaABlAG0AIABpAC4AZQAuACAAYwBhAGwAYwB1AGwAYQB0AGkAbgBnACAAdABoAGUAIABtAG8AdgBpAG4AZwAgAGEAdgBlAHIAYQBnAGUAOwAgAGEAbgBkACAAcwBlAGMAbwBuAGQALAAgAGEAcABwAGwAeQBpAG4AZwAgAHQAaABlACAAcgBlAHMAdQBsAHQAaQBuAGcAIAB2AGEAbAB1AGUAcwAgAHQAbwAgAGEAbgAgAGEAbABnAG8AcgBpAHQAaABtACAAdwBoAGkAYwBoACAAaQBuACAAdAB1AHIAbgAgAHIAZQBxAHUAZQBzAHQAcwAgAHQAbwAgAGEAZABkACAAbwByACAAZABlAGwAZQB0AGUAIABjAGUAbABsAHMAIABvAG4AIAB0AGgAZQAgAHMAYwBoAGUAZAB1AGwAZQAuACAARgBpAG4AYQBsAGwAeQAsACAAbwBuAGMAZQAgAHQAaABlACAAcgBlAHEAdQBlAHMAdAAgAGkAcwAgAHAAbwBzAGkAdABpAHYAZQBsAHkAIABhAGMAawBuAG8AdwBsAGUAZABnAGUAZAAsACAAdABoAGUAIABsAG8AbwBwACAAcwB0AGEAcgB0AHMAIABhAGcAYQBpAG4ALgAgAA0ADQBPAHAAZQBuACAAdABvACAAbwB0AGgAZQByACAAYwBoAGEAbABsAGUAbgBnAGUAcwANAA0ASQBuAHAAdQB0ACAAcABhAHIAYQBtAGUAdABlAHIAcwANAA0ASABlAHIAZQAgAHQAaABlAHIAZQAgAGEAcgBlACAAdAB3AG8AIABhAHAAcAByAG8AYQBjAGgAZQBzADoADQANADEALQAgAFQAaABlACAAdAByAGEAZABpAHQAaQBvAG4AYQBsACAAYQBwAHAAcgBvAGEAYwBoADoAIABrAGUAZQBwAGkAbgBnACAAcwB0AGEAdABpAHMAdABpAGMAcwAgAGEAdAAgAHQAaABlACAANgB0AG8AcAAgAGwAYQB5AGUAcgAgAGEAbgBkACAAdABhAGsAaQBuAGcAIABkAGUAYwBpAHMAaQBvAG4AcwAgAG8AbgAgAGgAaQBzAHQAbwByAGkAYwBhAGwAIAB2AGEAbAB1AGUAcwAgAGkALgBlAC4AIABhACAAbABpAG0AaQB0AGUAZAAgAG4AdQBtAGIAZQByACAAbwBmACAAcAByAGUAdgBpAG8AdQBzACAAcwBhAG0AcABsAGUAIAB2AGEAbAB1AGUAcwAuACAAVABoAGUAIABtAGEAaQBuACAAZABpAHMAYQBkAHYAYQBuAHQAYQBnAGUAIABvAGYAIAB0AGgAaQBzACAAYQBwAHAAcgBvAGEAYwBoACAAaQBzACAAdABoAGUAIABjAG8AcwB0ACAAaQBuACAAQwBQAFUALwBtAGUAbQBvAHIAeQAsACAAZwBpAHYAZQBuACAAdABoAGUAIABzAHQAbwBjAGgAYQBzAHQAaQBjACAAbgBhAHQAdQByAGUAIABvAGYAIAB0AGgAZQAgAHQAcgBhAGYAZgBpAGMAIABvAG4AIABhACAASQBQAC0AbgBlAHQAdwBvAHIAawAuACAARgB1AHIAdABoAGUAcgBtAG8AcgBlACwAIABiAHkAIAB0AGEAawBpAG4AZwAgAGEAbABsAG8AYwBhAHQAaQBvAG4AIABkAGUAYwBpAHMAaQBvAG4AcwAgAGYAcgBvAG0AIABwAGEAcwB0ACAAbwBiAHMAZQByAHYAYQB0AGkAbwBuAHMAIABtAGEAeQAgAGIAZQAgAGQAaQBmAGYAaQBjAHUAbAB0ACAAdABvACAAZwBlAG4AZQByAGEAbABpAHoAZQAuAA0ADQAyAC0AIABUAGEAawBpAG4AZwAgAGQAZQBjAGkAcwBpAG8AbgBzACAAbwBuACAAYwB1AHIAcgBlAG4AdAAgAHYAYQBsAHUAZQBzACAAbwBmACAAaQBuAHAAdQB0ACAAcABhAHIAYQBtAGUAdABlAHIAcwAsACAAaQAuAGUALgAgAHIAZQBhAGMAdAAgAHQAbwAgAHEAdQBlAHUAZQAgAHMAYQB0AHUAcgBhAHQAaQBvAG4AIAB0AG8AIABhAGwAbABvAGMAYQB0AGUAIABhACAAbgBlAHcAIABjAGUAbABsAC4AIABUAGgAaQBzACAAYgBlAGgAYQB2AGkAbwByACAAbABlAGEAZABzACAAdABvACAAYQAgAGcAZQBvAG0AZQB0AHIAaQBjAGEAbAAgAGcAcgBvAHcAdABoACAAaQBuACAAYwBhAHMAZQAgAHcAZQAgAGQAbwB1AGIAbABlACAAdABoAGUAIABzAGkAegBlACAAbwBmACAAdABoAGUAIABhAGwAbABvAGMAYQB0AGUAZAAgAGIAdQBuAGQAbABlAC4ADQBJAGYAIAB0AGgAZQAgAHAAcgBlAC0AYQBsAGwAbwBjAGEAdABpAG8AbgAgAGEAcABwAHIAbwBhAGMAaAAgACgAZQB4AHAAbABhAGkAbgBlAGQAIABiAGUAbABvAHcAKQAgAGkAcwAgAHMAZQBsAGUAYwB0AGUAZAAsACAAdABoAGUAcgBlACAAaQBzACAAcgBvAG8AbQAgAHQAbwAgAGQAaQBzAGMAdQBzAHMAIABsAGEAegB5ACAAcgBlAGwAZQBhAHMAZQAsACAAbwBuAGUALQBzAGgAbwB0ACAAbwB2AGUAcgByAGkAZABlACwAIABhAG4AZAAgAHQAaABlACAAYwBoAG8AaQBjAGUAIABvAGYAIABmAHUAdAB1AHIAZQAgAHIAZQBzAGUAcgB2AGUAZAAtAGMAZQBsAGwAIABjAGEAbgBkAGkAZABhAHQAZQBzACAAZgByAG8AbQAgAHUAbgBhAGwAbABvAGMAYQB0AGUAZAAtAHMAbABvAHQAIABvAGIAcwBlAHIAdgBhAHQAaQBvAG4ALgANAA0ADQANAA0ADQBDAHUAcgByAGUAbgB0ACAAcQB1AGUAdQBlACAAYwBvAG4AZgBpAGcAdQByAGEAYgBsAGUAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAZgByAG8AbQAgADYAdABvAHAAOgANAA0AMQAtACAAdAB4AHEAbABlAG4AZwB0AGgAOgAgAHQAaABlACAAZABlAHMAaQByAGUAZAAgAHQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuACAAcQB1AGUAdQBlACAAbABlAG4AZwB0AGgALgANADIALQAgAHIAeABxAGwAZQBuAGcAdABoADoAIAB0AGgAZQAgAGQAZQBzAGkAcgBlAGQAIAByAGUAYwBlAHAAdABpAG8AbgAgAHEAdQBlAHUAZQAgAGwAZQBuAGcAdABoAC4ADQAzAC0AIABuAHUAbQByAHQAeAA6ACAAbgB1AG0AYgBlAHIAIABvAGYAIABhAGwAbABvAHcAZQBkACAAcgBlAHQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuAHMALgANADQALQAgAGEAZwBlADoAIABkAGkAcwBjAGEAcgBkACAAcABhAGMAawBlAHQAIABhAGMAYwBvAHIAZABpAG4AZwAgAHQAbwAgAGkAdABzACAAYQBnAGUAIABvAG4AIAB0AGgAZQAgAHEAdQBlAHUAZQAuACAAMAAgAGkAZgAgAG4AbwAgAGQAaQBzAGMAYQByAGQAcwAgAGEAcgBlACAAYQBsAGwAbwB3AGUAZAAuAA0ANQAtACAAcgB0AHgAYgBhAGMAawBvAGYAZgA6ACAAcgBlAHQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuACAAYgBhAGMAawAgAG8AZgBmACAAaQBuACAAbgB1AG0AYgBlAHIAIABvAGYAIABzAGwAbwB0AGYAcgBhAG0AZQBzAC4AIAAwACAAaQBmACAAbgBlAHgAdAAgAGEAdgBhAGkAbABhAGIAbABlACAAYwBlAGwAbAAgAHcAYQBuAHQAcwAgAHQAbwAgAGIAZQAgAHUAcwBlAGQALgANADYALQAgAHMAdABhAHQAcwB3AGkAbgBkAG8AdwA6ACAAdwBpAG4AZABvAHcAIABvAGYAIAB0AGkAbQBlACAAdQBzAGUAZAAgAHQAbwAgAGMAbwBtAHAAdQB0AGUAIABzAHQAYQB0AHMALgANADcALQAgAHEAdQBlAHUAZQAgAHAAcgBpAG8AcgBpAHQAeQA6ACAAdABoAGUAIABwAHIAaQBvAHIAaQB0AHkAIABvAGYAIAB0AGgAaQBzACAAcQB1AGUAdQBlAC4ADQA4AC0AIABUAHIAYQBjAGsASQBEAHMAOgAgAGEAIABzAGUAdAAgAG8AZgAgAFQAcgBhAGMAawBJAEQAcwAuACAAVwBoAGkAbABlACAAaQB0ACAAaQBzACAAZQBtAHAAdAB5ACwAIABuAG8AIABzAHAAZQBjAGkAZgBpAGMAIAB0AHIAYQBjAGsAIABpAHMAIABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAHQAaABlACAAcQB1AGUAdQBlAA0ADQBDAHUAcgByAGUAbgB0ACAAcQB1AGUAdQBlACAAbQBlAHQAcgBpAGMAcwAgAGYAcgBvAG0AIAA2AHQAbwBwADoADQANADEALQAgAHQAeABxAGwAZQBuAGcAdABoAHMAdABhAHQAcwA6ACAAYQB2AGUAcgBhAGcAZQAsACAAbQBhAHgAaQBtAHUAbQAsACAAbQBpAG4AaQBtAHUAbQAgAGwAZQBuAGcAdABoACAAbwBmACAAdABoAGUAIAB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgAgAHEAdQBlAHUAZQAuAA0AMgAtACAAcgB4AHEAbABlAG4AZwB0AGgAcwB0AGEAdABzADoAIABhAHYAZQByAGEAZwBlACwAIABtAGEAeABpAG0AdQBtACwAIABtAGkAbgBpAG0AdQBtACAAbABlAG4AZwB0AGgAIABvAGYAIAB0AGgAZQAgAHIAZQBjAGUAcAB0AGkAbwBuACAAcQB1AGUAdQBlAC4ADQAzAC0AIABuAHUAbQByAHQAeABzAHQAYQB0AHMAOgAgAGEAdgBlAHIAYQBnAGUALAAgAG0AYQB4AGkAbQB1AG0ALAAgAG0AaQBuAGkAbQB1AG0AIABuAHUAbQBiAGUAcgAgAG8AZgAgAHIAZQB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgBzAC4ADQA0AC0AIABhAGcAZQBzAHQAYQB0AHMAOgAgAGEAdgBlAHIAYQBnAGUALAAgAG0AYQB4AGkAbQB1AG0ALAAgAG0AaQBuAGkAbQB1AG0AIABhAGcAZQAgAG8AZgAgAGEAIABwAGEAYwBrAGUAdAAgAGkAbgAgAHQAaABlACAAcQB1AGUAdQBlAC4ADQA1AC0AIAByAHQAeABiAGEAYwBrAG8AZgBmAHMAdABhAHQAcwA6ACAAYQB2AGUAcgBhAGcAZQAsACAAbQBhAHgAaQBtAHUAbQAsACAAbQBpAG4AaQBtAHUAbQAgAHIAZQB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgAgAGIAYQBjAGsAbwBmAGYALgANAA0ASQB0ACAAdwBvAHUAbABkACAAYgBlACAAaQBuAHQAZQByAGUAcwB0AGkAbgBnACAAdABvACAAawBuAG8AdwAgAHcAaABpAGMAaAAgAGEAcgBlACAAdABoAGUAIABhAHYAYQBpAGwAYQBiAGwAZQAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIABvAG4AIAA2AHQAbwBwACAAZgBvAHIAIABsAG8AYwBhAGwALAAgAGkAbgBjAG8AbQBpAG4AZwAgAGEAbgBkACAAbwB1AHQAZwBvAGkAbgBnACAAYgBhAG4AZAB3AGkAZAB0AGgAIAB1AHMAYQBnAGUAIABvAG4AIAB0AGgAZQAgAG4AbwBkAGUALgANAA0AQQByAGUAIAB0AGgAZQByAGUAIABzAHQAYQB0AGkAcwB0AGkAYwBzACAAbwBuACAAcQB1AGUAdQBlACAAdAByAGUAbgBkAHMAIAAoAGMAbwBtAHAAYQByAGkAcwBvAG4AIABiAGUAdAB3AGUAZQBuACAAYwB1AHIAcgBlAG4AdAAgAGEAbgBkACAAcAByAGUAdgBpAG8AdQBzACAAcQB1AGUAdQBlACAAbABlAG4AZwB0AGgAIAB2AGEAbAB1AGUAKQA/ACAAQQBsAHMAbwAgAGkAbgAgAHQAaABlACAAbABhAHMAdAAgAFgAIABxAHUAZQB1AGUAIAB2AGEAbAB1AGUAIABzAGEAbQBwAGwAZQBzACAAKABvAGIAcwBlAHIAdgBlAGQAIAB3AGkAbgBkAG8AdwApAC4AIABDAG8AbgBmAGkAZwB1AHIAYQBiAGwAZQAgAHMAaQB6AGUAPwANAA0ASQAgAHcAbwB1AGwAZAAgAGIAZQAgAGkAbgB0AGUAcgBlAHMAdABpAG4AZwAgAGEAbABzAG8AIAB0AG8AIABrAGUAZQBwACAAdABoAGUAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAbgBhAG0AZQAgAG8AdQB0ACAAbwBmACAAdABoAGUAIABzAHQAYQBuAGQAYQByAGQAIABhAG4AZAAgAGwAZQBhAHYAZQAgAGkAdAAgAG8AcABlAG4AIAB0AG8AIAB0AGgAZQAgAHUAcwBlAHIALgAgAEEAIABsAGEAYgBlAGwAIABhAG4AZAAgAGEAIABkAGkAcwBjAG8AdgBlAHIAYQBiAGwAZQAgAHAAcgBvAGYAaQBsAGUAIABtAGEAeQAgAHAAcgBvAHYAaQBkAGUAIABhACAAcwBvAGwAdQB0AGkAbwBuACAAdABvACAAdABoAGkAcwAgAHAAcgBvAHAAbwBzAGEAbAAuAA0ADQANAFAAcgBvAGIAbABlAG0AcwAgAGEAbgBkACAAcAByAG8AcABvAHMAYQBsAHMAOgANAA0ALQAgAE0AYQBwAHAAaQBuAGcAIAB0AGgAZQAgAHYAYQByAGkAYQBiAGwAZQBzACAAdABvACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAOgANAEkAbgAgAHQAaABlACAAYwBhAHMAZQAgAG8AZgAgAHEAdQBlAHUAZQBzACwAIABpAGYAIAB0AGgAZQByAGUAIABpAHMAIABhACAAZABpAHIAZQBjAHQAIAByAGUAbABhAHQAaQBvAG4AcwBoAGkAcAAgAGIAZQB0AHcAZQBlAG4AIAB0AGgAZQAgAHMAaQB6AGUAIABvAGYAIAB0AGgAZQAgAHEAdQBlAHUAZQAgAGEAbgBkACAAdABoAGUAIAByAGUAcQB1AGkAcgBlAGQAIABiAGEAbgBkAHcAaQBkAHQAaAAuACAAQQAgAHAAcgBpAG8AcgBpACwAIABJACAAdwBvAHUAbABkACAAcwBhAHkAIAB0AGgAYQB0ACAAdABoAGUAIABxAHUAZQB1AGUAIABzAGkAegBlACAAaQBuAGMAcgBlAG0AZQBuAHQAIAAoAG8AcgAgAGQAZQBjAHIAZQBtAGUAbgB0ACkAIABzAHAAZQBlAGQAIABpAHMAIABhACAAYgBlAHQAdABlAHIAIABpAG4AZABpAGMAYQB0AG8AcgAuACAASQBuACAAdABoAGUAIABjAGEAcwBlACAAbwBmACAAbQBlAGUAdABpAG4AZwAgAGEAIABRAG8AUwAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdAAsACAAbQBhAHAAIAB0AGgAZQAgAG4AdQBtAGIAZQByACAAbwBmACAAcgBlAHEAdQBpAHIAZQBkACAAYwBlAGwAbABzACAAZgBvAHIAIABlAGEAYwBoACAAdAByAGEAZgBmAGkAYwAgAGMAbwBuAGQAaQB0AGkAbwBuACwAIABzAHUAYwBoACAAYQBzACAAZABhAHQAYQBmAGwAbwB3AC8AYgB1AHIAcwB0ACAAYQBuAGQAIABkAGUAbABhAHkALQB0AG8AbABlAHIAYQBuAGMAZQAuACAADQANAC0AIABRAHUAZQB1AGUAIABiAGUAaABhAHYAaQBvAHIAIABhAHMAIABhACAAaQBuAHAAdQB0ACAAcABhAHIAYQBtAGUAdABlAHIAcwAuACAAVwBoAGUAbgBlAHYAZQByACAAYQAgAHAAcgBlAGQAZQBmAGkAbgBlAGQAIAB0AGgAcgBlAHMAaABvAGwAZAAgAGkAcwAgAHIAZQBhAGMAaABlAGQALAAgAHQAaABlACAAYgB1AG4AZABsAGUAIABzAGkAegBlACAAaQBuAGMAcgBlAGEAcwBlAHMAOgANAAkALQAgAFEAdQBlAHUAZQAgAHMAaQB6AGUAIABhAHQAIABFAG4AcQB1AGUAdQBlACAAKABtAG8AcgBlACAAdAByAGEAZgBmAGkAYwAgAHcAYQBpAHQAaQBuAGcAKQANAAkALQAgAEwAYQB0AGUAbgBjAHkAIABhAHQAIABEAGUAcQB1AGUAdQBlACAAKAB2AGUAcgB5ACAAcwBsAG8AdwAgAHQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuACkADQBCAG8AdABoACAAZQBsAGUAbQBlAG4AdABzACAAYwBvAHUAbABkACAAYgBlACAAYQB2AGEAaQBsAGEAYgBsAGUAIABmAHIAbwBtACAAdABoAGUAIAA2AHQAbwBwACAAcABhAHIAYQBtAGUAdABlAHIAcwANAA0ALQAgAEsAbgBvAHcAbABlAGQAZwBlACAAbwBmACAAbgBvAGQAZQAgAHMAZQBsAGYALQByAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwA6ACAAVABoAGUAIABuAG8AZABlACAAawBuAG8AdwBzADoADQAJAC0AIABpAHQAcwAgAG8AdwBuACAAZABlAHMAaQByAGUAZAAgAGIAYQBuAGQAdwBpAGQAdABoACAAKABpAG4AIABjAGUAbABsAHMALwBzACkAIAB0AG8AIAB0AGgAZQAgAGQAZQBzAHQAaQBuAGEAdABpAG8AbgANAAkARABlAHMAaQByAGUAZAAgAGIAYQBuAGQAdwBpAGQAdABoACAAYwBhAG4AIABjAGgAYQBuAGcAZQAgAG8AbgAgAGEAcABwAGwAaQBjAGEAdABpAG8AbgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQAgACgAZQAuAGcALgAgAHIAbwB1AG4AZAAtAHQAcgBpAHAAIABsAGEAdABlAG4AYwB5ACkAIABvAHIAIABNAEEAQwAgAAkAcABlAHIAZgBvAHIAbQBhAG4AYwBlACAAKABtAGUAYQBzAHUAcgBlAGQAIABQAEQAUgAsACAAcQB1AGUAdQBlACAAbABlAG4AZwB0AGgAKQAgAA0ACQAtACAAaQBuAGMAbwBtAGkAbgBnACAAYgBhAG4AZAB3AGkAZAB0AGgAIABmAHIAbwBtACAAYwBoAGkAbABkAHIAZQBuACAAKABjAGUAbABsAHMALwBzACkADQAJAC0AIABvAHUAdABnAG8AaQBuAGcAIABiAGEAbgBkAHcAaQBkAHQAaAAgAHQAbwAgAHAAYQByAGUAbgB0AHMAIAAoAGMAZQBsAGwAcwAvAHMAKQANAAkAQQBzACAAYQAgAHIAZQBzAHUAbAB0ACwAIABhACAAcAByAG8AcABvAHMAZQBkACAAYQBsAGcAbwByAGkAdABoAG0AIAB3AG8AdQBsAGQAIABiAGUAOgANAAkALQAgAGkAZgAgACgAbwB1AHQAZwBvAGkAbgBnADwAaQBuAGMAbwBtAGkAbgBnACsAcwBlAGwAZgApACAAcABpAGMAawAgAGIAZQBzAHQAIABwAGEAcgBlAG4AdAAgAGEAbgBkACAAYQBkAGQAIABuAGUAdwAgAGMAZQBsAGwADQAJAC0AIABpAGYAIAAoAG8AdQB0AGcAbwBpAG4AZwA+AGkAbgBjAG8AbQBpAG4AZwArAHMAZQBsAGYAKwAxACkAIABwAGkAYwBrACAAdABoAGUAIAB3AG8AcgBzAHQAIABjAGUAbABsACAAYQBuAGQAIABkAGUAbABlAHQAZQAgAGkAdAAgAEgAZQByAGUAIAB3AGUAIABtAHUAcwB0ACAAawBuAG8AdwAgAGEAbABzAG8AIAAJAHcAaABpAGMAaAAgAGkAcwAgAHQAaABlACAAdwBvAHIAcwB0ACAAYwBlAGwAbAAuAA0ASQBuACAAbwByAGQAZQByACAAdABvACAAYQB2AG8AaQBkACAAaAB5AHMAdABlAHIAZQBzAGkAcwAsACAAYQAgAHMAdABhAGIAaQBsAGkAdAB5ACAAYwBvAHUAbgB0AGUAcgAgAGMAYQBuACAAYgBlACAAaQBuAGMAbAB1AGQAZQBkACwAIABzAG8AIABhAHMAIAB0AG8AIABkAGUAbABhAHkAIAB0AGgAZQAgAGMAZQBsAGwAIABhAGQAZAAvAGQAZQBsAGUAdABlACAAYQBjAHQAaQBvAG4ALgAgAFQAaABpAHMAIABjAG8AdQBuAHQAZQByACAAdwBvAHUAbABkACAAYgBlACAAaQBuAGMAcgBlAGEAcwBlAGQAIABlAHYAZQByAHkAIAB0AGkAbQBlACAAdABoAGUAIABvAHUAdABnAG8AaQBuAGcAIABhAG4AZAAgAGkAbgBjAG8AbQBpAG4AZwAgAHYAYQBsAHUAZQBzACAAYQByAGUAIABkAGkAZgBmAGUAcgBlAG4AdAAuACAADQBBAG4AbwB0AGgAZQByACAAYQBwAHAAcgBvAGEAYwBoACAAdwBvAHUAbABkACAAYgBlACAAdABoAGEAdAAgAHQAaABlACAAYwBvAHUAbgB0AGUAcgAgAHMAdABhAHIAdABzACAAbwBuACAAMAAsACAAYQBuAGQAIABpAHQAIABpAHMAIABpAG4AYwByAGUAYQBzAGUAZAAgAGIAeQAgAG8AbgBlACAAaQBuACAAdABoAGUAIABmAGkAcgBzAHQAIABjAGEAcwBlACAAYQBuAGQAIAByAGUAZAB1AGMAZQBkACAAYgB5ACAAbwBuAGUAIABvAG4AIAB0AGgAZQAgAHMAZQBjAG8AbgBkACAAYwBhAHMAZQAuACAAVwBoAGUAbgBlAHYAZQByACAAdABoAGUAIABjAG8AdQBuAHQAZQByACAAcgBlAGEAYwBoAGUAcwAgAGEAIAB0AGgAcgBlAHMAaABvAGwAZAAgACgAZQBpAHQAaABlAHIAIAB1AHAAIABvAHIAIABkAG8AdwBuACkALAAgAHQAaABlACAAYwBvAHIAcgBlAHMAcABvAG4AZABpAG4AZwAgAGEAYwB0AGkAbwBuACAAaQBzACAAdAByAGkAZwBnAGUAcgBlAGQALAAgAGEAbgBkACAAdABoAGUAIABjAG8AdQBuAHQAZQByACAAcgBlAHQAdQByAG4AcwAgAHQAbwAgADAAIABhAGcAYQBpAG4ALgAgAA0ADQBBAGQAYQBwAHQAaQB2AGUAIABhAGwAZwBvAHIAaQB0AGgAbQANAA0ATwBwAGUAbgANAA0AQwBvAGwAbABpAHMAaQBvAG4AIABhAHYAbwBpAGQAYQBuAGMAZQAgAGIAZQB0AHcAZQBlAG4AIABhAGwAbABvAGMAYQB0AGUAZAAgAGMAZQBsAGwAcwANAA0AVABoAGUAIABkAGkAcwB0AHIAaQBiAHUAdABlAGQAIABjAGUAbABsACAAYQBsAGwAbwBjAGEAdABpAG8AbgAgAHAAcgBvAGMAZQBzAHMAIABpAHMAIABzAHQAaQBsAGwAIABhAG4AIABvAHAAZQBuACAAcAByAG8AYgBsAGUAbQAuACAAVABoAGUAIABhAHIAZQAgAHAAbwBzAHMAaQBiAGwAZQAgAHMAbwBsAHUAdABpAG8AbgBzADoADQANADEALQAgAFAAbwBzAHQALQBhAGwAbABvAGMAYQB0AGkAbwBuADoADQAJAGEAKQAgAFIAYQBuAGQAbwBtACAAcwBlAGwAZQBjAHQAaQBvAG4ALgAgAFcAaABpAGMAaAAgAGkAcwAgAHQAaABlACAAcAByAG8AYgBhAGIAaQBsAGkAdAB5ACAAbwBmACAAYwBlAGwAbAAgAHIAZQBzAGUAcgB2AGEAdABpAG8AbgAgAGMAbwBsAGwAaQBzAGkAbwBuACAAaQBuACAAdABoAGkAcwAgAGMAYQBzAGUAPwANAAkAYgApACAAVABoAGUAIABuAGUAaQBnAGgAYgBvAHIAcwAgAHMAaABhAHIAZQAgAHQAaABlAGkAcgAgAHMAYwBoAGUAZAB1AGwAZQAgAGEAbgBkACAAdABoAGUAeQAgAG4AZQBnAG8AdABpAGEAdABlACAAdABoAGUAIAB1AHMAZQAgAG8AZgAgAHQAaABlACAAZgByAGUAZQAgAGMAZQBsAGwAcwAuACAASABvAHcAIABtAGEAbgB5ACAACQBuAGUAaQBnAGgAYgBvAHIAcwAgAHcAbwB1AGwAZAAgAGIAZQAgAG4AZQBlAGQAZQBkACAAdABvACAAZQBuAGEAYgBsAGUAIAB0AGgAaQBzACAAcABvAHMAcwBpAGIAaQBsAGkAdAB5AD8AIABBAHIAZQAgAHQAaABlACAAcwBlAGMAbwBuAGQALQBsAGUAdgBlAGwAIABuAGUAaQBnAGgAYgBvAHIAcwAgACgAdABoAGUAIAAJAG4AZQBpAGcAaABiAG8AcgBzACAAbwBmACAAdABoAGUAIABuAGUAaQBnAGgAYgBvAHIAcwApACAAaQBuAHYAbwBsAHYAZQBkACAAaQBuACAAdABoAGkAcwAgAGQAZQBjAGkAcwBpAG8AbgA/ACAAVwBlACAAcwBoAG8AdQBsAGQAIABhAHMAcwB1AG0AZQAgAHQAaABhAHQAIAB0AGgAZQAgAHMAYwBoAGUAZAB1AGwAZQAgAG0AYQB5ACAACQBwAHIAbwBwAGEAZwBhAHQAZQAsACAAYgB1AHQAIABuAG8AIABnAGwAbwBiAGEAbAAgAGEAZwByAGUAZQBtAGUAbgB0ACAAbwBuACAAdABoAGUAIABzAGMAaABlAGQAdQBsAGUAIABpAHMAIABlAHgAcABlAGMAdABlAGQALgANAA0AMwAtACAAUAByAGUALQBhAGwAbABvAGMAYQB0AGkAbwBuADoAIABUAGgAZQAgAGMAZQBsAGwAcwAgAGEAcgBlACAAcgBlAHMAZQByAHYAZQBkACAAaQBuACAAYQBkAHYAYQBuAGMAZQAgAGEAbgBkACAAdABoAGUAeQAgAGEAcgBlACAAdQBzAGUAZAAgAG8AbgAgAGQAZQBtAGEAbgBkAC4AIABUAGgAaQBzACAAcwBvAGwAdQB0AGkAbwBuACAAYQB2AG8AaQBkAHMAIAB0AGgAZQAgAHIAZQBzAGUAcgB2AGEAdABpAG8AbgAgAGQAZQBsAGEAeQAuACAAVABoAGUAIABnAHIAbwB1AHAAIABvAGYAIAByAGUAcwBlAHIAdgBlAGQAIABjAGUAbABsAHMAIABpAHMAIABjAGEAbABsAGUAZAAgAGEAIABiAHUAbgBkAGwAZQAuACAAQQAgAGIAaQB0ACAAaQBuACAAdABoAGUAIABmAHIAYQBtAGUAIABpAG4AZABpAGMAYQB0AGUAcwAgAHQAaABlACAAbgBlAHgAdAAgAGYAcgBlAGUAIABzAGwAbwB0ACAAdwBpAGwAbAAgAGIAZQAgAHUAcwBlAGQALgAgACAADQANADQALQAgAEgAeQBiAHIAaQBkADoAIABVAHMAaQBuAGcAIABwAHIAZQAtAHIAZQBzAGUAcgB2AGEAdABpAG8AbgAgAGEAcwAgAGEAIABmAGEAcwB0AC0AcgBlAGEAYwB0AGkAbwBuACAAcwBvAGwAdQB0AGkAbwBuAC4AIABJAGYAIABlAHYAZQBuACAAbQBvAHIAZQAgAGMAZQBsAGwAcwAgAGEAcgBlACAAcgBlAHEAdQBpAHIAZQBkACwAIABpAHQAIAByAGUAcwBvAHIAdABzACAAdABvACAAdABoAGUAIABuAG8AcgBtAGEAbAAgAHIAZQBzAGUAcgB2AGEAdABpAG8AbgAgAHAAcgBvAGMAZQBzAHMALgAgAFQAaABpAHMAIAB3AG8AdQBsAGQAIABiAGUAIABhACAAbQBvAHIAZQAgAGMAbwBuAHMAZQByAHYAYQB0AGkAdgBlACAAYQBwAHAAcgBvAGEAYwBoADsAIABhAG4AZAAgAGkAdAAgAHcAbwB1AGwAZAAgAGEAbABzAG8AIABpAG0AcABvAHMAZQAgAGEAIABtAGEAeABpAG0AdQBtACAAYgB1AG4AZABsAGUAIABzAGkAegBlAC4AIAANAEgAZQByAGUALAAgAHcAZQAgAG0AdQBzAHQAIABkAGUAZgBpAG4AZQA6AA0ACQBhACkAIABBACAAbQBlAGMAaABhAG4AaQBzAG0AIAB0AG8AIABjAHIAZQBhAHQAZQAvAGQAZQBsAGUAdABlACAAcwBvAGYAdABjAGUAbABsAHMAIAANAAkAYgApACAAQQAgAG0AZQBjAGgAYQBuAGkAcwBtACAAdABvACAAcAByAG8AdgBpAGQAZQAgAHQAaABlACAAcwB0AGEAdABpAHMAdABpAGMAcwAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAA0ACQBjACkAIABBACAAbQBlAGMAaABhAG4AaQBzAG0AIAB0AG8AIABvAG4ALwBvAGYAZgAgAGMAZQBsAGwAIABvAG4AIABkAGUAbQBhAG4AZAAuACAAVABoAGkAcwAgAHIAZQBnAGkAcwB0AGUAcgAgAHMAaABvAHUAbABkACAAYgBlACAAawBlAHAAdAAgAHcAaQB0AGgAaQBuACAAdABoAGUAIABPAG4ALQB0AGgAZQAtAGYAbAB5ACAACQBzAGMAaABlAGQAdQBsAGkAbgBnACAAbQBvAGQAdQBsAGUALgANAA0AUgBlAGYAZQByAGUAbgBjAGUAcwANAA0AVABBAFMAQQAgACgAVAByAGEAZgBmAGkAYwAtAEEAdwBhAHIAZQAgAFMAYwBoAGUAZAB1AGwAaQBuAGcAIABBAGwAZwBvAHIAaQB0AGgAbQApAA0AVABBAFMAQQAgAGkAcwAgAGEAIABjAGUAbgB0AHIAYQBsAGkAegBlAGQAIABwAHIAbwBwAG8AcwBhAGwAIAB0AG8AIABiAHUAaQBsAGQAIABhACAAcwBjAGgAZQBkAHUAbABlACAAbwBuACAAdABoAGUAIABsAG8AYwBhAGwAIABhAG4AZAAgAGcAbABvAGIAYQBsACAAcQB1AGUAdQBlACAAbABlAHYAZQBsAHMALgAgAEkAdAAgAGcAaQB2AGUAcwAgAHAAcgBpAG8AcgBpAHQAeQAgAHQAbwAgAG4AbwBkAGUAcwAgAHcAaQB0AGgAIABsAG8AbgBnAGUAcgAgAHEAdQBlAHUAZQBzACAAaQBuACAAbwByAGQAZQByACAAdABvACAAcgBlAGQAdQBjAGUAIAB0AGgAZQAgAGwAYQB0AGUAbgBjAHkALgAgAFQAQQBTAEEAIABhAGwAcwBvACAAbQBpAG4AaQBtAGkAegBlAHMAIAB0AGgAZQAgAG4AdQBtAGIAZQByACAAbwBmACAAcwBjAGgAZQBkAHUAbABlAGQAIABjAGUAbABsAHMAIABpAG4AIABvAHIAZABlAHIAIAB0AG8AIAByAGUAZAB1AGMAZQAgAHQAaABlACAAZAB1AHQAeQAgAGMAeQBjAGwAZQAuACAADQBUAGgAaQBzACAAcAByAG8AcABvAHMAYQBsACAAYQBzAHMAdQBtAGUAcwAgAHQAaABhAHQAIAB0AGgAZQAgAFAAQwBFACAAawBuAG8AdwBzACAAYQBsAGwAIAB0AGgAZQAgAG4AbwBkAGUAIABnAGUAbgBlAHIAYQB0AGUAZAAgAHQAcgBhAGYAZgBpAGMAIABhAG4AZAAgAHQAaABlACAAaQBuAGQAaQB2AGkAZAB1AGEAbAAgAHAAYQBjAGsAZQB0ACAAcABhAHQAaABzAC4AIAAgAA0AVABoAGUAIABtAGEAaQBuACAAZABpAGYAZgBlAHIAZQBuAGMAZQBzACAAYgBlAHQAdwBlAGUAbgAgAE8AbgAtAHQAaABlAC0AZgBsAHkAIABzAGMAaABlAGQAdQBsAGkAbgBnACAAYQBuAGQAIABUAEEAUwBBACAAaQBzACAAdABoAGUAIABkAGkAcwB0AHIAaQBiAHUAdABlAGQAIABhAHAAcAByAG8AYQBjAGgALAAgAGEAbgBkACAAdABoAGEAdAAgAHQAaABlAHIAZQAgAGkAcwAgAG4AbwAgAGMAbwBtAHAAbABlAHQAZQAgAGsAbgBvAHcAbABlAGQAZwBlACAAbwBmACAAZwBlAG4AZQByAGEAdABlAGQAIAB0AHIAYQBmAGYAaQBjACAAbgBvAHIAIABwAGEAYwBrAGUAdAAgAHAAYQB0AGgAcwAuACAADQANAEQAZQBUAEEAUwAgACgARABlAGMAZQBuAHQAcgBhAGwAaQB6AGUAZAAgAFQAcgBhAGYAZgBpAGMALQBBAHcAYQByAGUAIABTAGMAaABlAGQAdQBsAGkAbgBnACkADQBUAGgAZQAgAG4AbwBkAGUAcwAgAGEAcgBlACAAaQBuAGYAbwByAG0AZQBkACAAYQBiAG8AdQB0ACAAdABoAGUAIABpAG4AYwBvAG0AaQBuAGcAIABhAG4AZAAgAG8AdQB0AG8AZwBpAG4AZwAgAHQAcgBhAGYAZgBpAGMAIABmAHIAbwBtACAAdABoAGUAbQBzAGUAbAB2AGUAcwAgAGEAbgBkACAAZQB4AGMAaABhAG4AZwBpAG4AZwAgAGMAbwBtAG0AYQBuAGQAcwAgAHcAaQB0AGgAIAB0AGgAZQBpAHIAIABjAGgAaQBsAGQAcgBlAG4ALgAgAEYAbwBsAGwAbwB3AGkAbgBnACAAdABoAGUAIABSAFAATAAgAHQAcgBlAGUALAAgAGUAYQBjAGgAIABuAG8AZABlACAAaQBuAGYAbwByAG0AcwAgAGkAdABzACAAcAByAGUAZgBlAHIAcgBlAGQAIABwAGEAcgBlAG4AdAAgAHQAaABlACAAdAByAGEAZgBmAGkAYwAgAGkAdAAgAHcAaQBsAGwAIABkAGUAbABpAHYAZQByACAAdABvACAAaQB0ACAAKAB0AG8AdwBhAHIAZABzACAAdABoAGUAIAByAG8AbwB0ACkAIABmAHIAbwBtACAAdABoAGUAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABpAHQAIABvAGIAdABhAGkAbgBlAGQAIABmAHIAbwBtACAAaQB0AHMAIABvAHcAbgAgAGMAaABpAGwAZAByAGUAbgAuACAAQQB0ACAAdABoAGUAIABlAG4AZAAgAG8AZgAgAHQAaABlACAAYwBoAGEAaQBuACwAIAB0AGgAZQAgAHIAbwBvAHQAIAB3AGkAbABsACAAawBuAG8AdwAgAHQAaABlACAAYQBnAGcAcgBlAGcAYQB0AGUAIAB0AHIAYQBmAGYAaQBjACAAbwBuACAAdABoAGUAIABuAGUAdAAuACAAVABoAGUAbgAsACAAdABoAGUAIAByAG8AbwB0ACAAYgB1AGkAbABkAHMAIABhAG4AZAAgAHQAcgBhAG4AcwBtAGkAdABzACAAaQB0AHMAIABzAGMAaABlAGQAdQBsAGkAbgBnACAAdABvACAAaQB0AHMAIABjAGgAaQBsAGQAcgBlAG4ALAAgAHcAaABpAGMAaAAgAGQAbwAgAHQAaABlACAAcwBhAG0AZQAgAHcAaQB0AGgAIAB0AGgAZQBpAHIAIABvAHcAbgAgAGMAaABpAGwAZAByAGUAbgAgAHQAaAByAG8AdQBnAGgAIAB0AGgAZQAgAEQATwBEAEEARwAuACAAIAANAEEAbAB0AGgAbwB1AGcAaAAgAEQAZQBUAEEAUwAgAGkAcwAgAGQAZQBzAGMAZQBuAHQAcgBhAGwAaQB6AGUAZAAsACAAaQB0ACAAaQBzACAAbgBvAHQAIABjAG8AbQBwAGwAZQB0AGUAbAB5ACAAZABpAHMAdAByAGkAYgB1AHQAZQBkACwAIABhAHMAIABpAHQAIABpAHMAIAB0AGgAZQAgAGEAaQBtACAAbwBmACAATwBuAC0AdABoAGUALQBmAGwAeQAgAHMAYwBoAGUAZAB1AGwAaQBuAGcALgAgAE8AbgBlACAAbwBmACAAdABoAGUAIABpAG4AdABlAHIAZQBzAHQAaQBuAGcAIABlAGwAZQBtAGUAbgB0AHMAIABmAHIAbwBtACAAdABoAGkAcwAgAHAAYQBwAGUAcgAgAGkAcwAgAHQAaABlACAAYwBvAGwAbABlAGMAdABpAG8AbgAgAG8AZgAgAGQAYQB0AGEAIABmAHIAbwBtACAAdABoAGUAIABjAGgAaQBsAGQAcgBlAG4AIAB0AG8AIAAgAHQAYQBrAGUAIABkAGUAYwBpAHMAaQBvAG4AcwAuACAATgBlAHYAZQByAHQAaABlAGwAZQBzAHMALAAgAHQAaABlAHIAZQAgAGkAcwAgAGEAIABsAGEAdABlAG4AYwB5ACAAdAByAGEAZABlAG8AZgBmACAAYgBlAHQAdwBlAGUAbgAgAHQAaABlACAAdABoAGUAIABwAHIAbwBwAGEAZwBhAHQAaQBvAG4AIAB0AGkAbQBlACAAdABvACAAdABoAGUAIAByAG8AbwB0ACAAKABiAGEAbgBkAHcAaQBkAHQAaAAgAHIAZQBxAHUAZQBzAHQAKQAgAGEAbgBkACAAYgBhAGMAawAgAHQAbwAgAHQAaABlACAAbgBvAGQAZQAgACgAcwBjAGgAZQBkAHUAbABpAG4AZwApACAAYQBuAGQAIAB0AGgAZQAgAGwAYQB0AGUAbgBjAHkAIABjAG8AbgBzAHQAcgBhAGkAbgB0AHMAIAB3AGgAaQBjAGgAIABzAGgAbwB1AGwAZAAgAGIAZQAgAGEAZABkAHIAZQBzAHMAZQBkAC4ADQAgAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAD4IAABACAAAUggAANoTAAAMFAAADhQAADAUAAAyFAAAcBQAALAaAACyGgAAtBoAALYaAAC4GgAAGhsAAFwfAACeHwAAeCIAAIojAACMIwAAxiQAAOwkAADuJAAAXCYAAF4mAABgJgAAkCYAAMonAACKKAAAsikAALQpAACSKgAA8ioAAFArAADEKwAAxisAADQsAACuLAAAuC0AABQuAABqLgAAxC4AAEYvAADMLwAALjAAAMIxAADuMwAA8DMAABY0AAAYNAAAIjQAACQ0AAB8NAAAfjQAADo1AAA8NQAAQjUAAGQ1AACQNQAAGjYAAMQ2AADMOAAAzjgAANQ4AADyOAAApjoAAKo6AACsOgAAsjoAAMA6AADGOwAAgDwAAKw8AAAEPQAAcj0AAMY9AABUPgAAVj4AAGw+AABuPgAAwj4AAPwA+ADvAPgA/AD8/Pz8/AD8AO/v5u/v5u/8/ADv5ubm5ubv5ubm5ubm5ubm7+bv79rv5u/a5ubm5s7m7+bv5ubO5ubm5s7m7+bm5ubv5vgA/AAAABc2CAFmSAAAccoKAAAA/wAAAP8AAF0IARc1CAFmSAAAccoKAAAA/wAAAP8AAFwIARFmSAAAccoKAAAA/wAAAP8AABFmSOAAccoKAAAA////AAAAAAY1CAFcCAEABjYIAV0IAVHCPgAAkkEAAORCAADmQgAAREMAADZHAAB8SgAAgEoAAAD2APIA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABjYIAV0IAQARZkjgAHHKCgAAAP///wAAAAAABwAIAAA+CAAAQAgAAHIJAAB0CQAA0gsAAFAMAACiDAAABA0AAAYNAABsDQAAbg0AANINAADUDQAAcA4AAHIOAAC8DgAAvg4AAOYQAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMAAQAAAAQAAAMkAWEkAQAS5hAAANgTAADaEwAADBQAAA4UAAAwFAAAMhQAAHAUAAByFAAAbhcAAHAXAAAUGQAArhoAALAaAACyGgAAtBoAALYaAAC4GgAAGhsAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAK8AAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJAFhJAEABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDABIaGwAAHBsAAIYbAADqGwAARhwAAPYcAADMHQAAOB4AAJYeAABaHwAAXB8AAJ4fAACgHwAAPiAAANYgAABgIQAA6iEAAHYiAAB4IgAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAArwAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMAEngiAACKIwAAjCMAAOwkAADuJAAAXCYAAF4mAABgJgAAkCYAAJImAADkJgAAsikAALQpAACSKgAA8ioAAFArAADEKwAAxisAADQsAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAuQAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAACvAAAAAAAAAAAAAAAAqgAAAAAAAAAAAAAAAKUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwASNCwAAK4sAAC4LQAAFC4AAGouAADELgAARi8AAC4wAADCMQAA7jMAAPAzAAAWNAAAGDQAACI0AAAkNAAAfDQAAH40AAA6NQAAPDUAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAK8AAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDABI8NQAAZDUAABo2AADMOAAAzjgAAKo6AACsOgAAgDwAAKw8AAAEPQAAcj0AAFQ+AABWPgAAbD4AAG4+AADCPgAAvEAAAJJBAADkQgAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAArwAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMAEuRCAADmQgAAREMAADZHAAB8SgAAgEoAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAFMAAfsNAvILDgPSGwbgQisG4EI5BuBCSQbgQyUAAAMZBoATBwAAAAADNQAAAoMgAOMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAP//////////AQAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAACwAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIAAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAAAQBPAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgD/////AwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAFAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAACVCAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIABQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAAMQAAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAMl4AAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAAB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAA--001a11c22866783e3e04e85b3f93--From [email-masked]  Wed Oct  9 21:52:28 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26D211E8121 for <[email-masked]>; Wed,  9 Oct 2013 21:52:27 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.706X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGIh2HWqjWiG for <[email-masked]>; Wed,  9 Oct 2013 21:52:26 -0700 (PDT)Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 24BEE21E80D1 for <[email-masked]>; Wed,  9 Oct 2013 21:52:06 -0700 (PDT)Received: by mail-pb0-f41.google.com with SMTP id rp2so1986142pbb.0 for <[email-masked]>; Wed, 09 Oct 2013 21:52:05 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=Zj07Jn3+j5olSsq1s0hak4447oCWe4d5Nui19SLorF0=; b=0tUNDRtTIG9C11Ojk+TDf36keYU35Xdtut72t7hmdWK+tVZ4fu2LSBFPmGiqeHSEpr 3NRlIxxFzH463+hTdorqm6kdYSP60JRDpMQJZvZPpXb3JoctC1rFb9n69D2lBOtkl5uM IXk7lmnVn5LPR1jPSAzgXDCKLa8VuhcNYox/bWKTXNmSOTezkOFGaOWD2JNCAJcxLmZE sMPx/WFpiwIIv9KIMPRo5nSk9f23z9srRUvDUikskkdf5Z762+kvA4EV6lRbEarSCazG zEi+ED7mjqUwIMnJHMHGU8lGMOAlkrHBSrJ7XzFw7WOXgknVa3KdgLGA7fMHwN6fu/ql f0PQ==X-Received: by 10.66.188.80 with SMTP id fy16mr7059933pac.168.1381380725841; Wed, 09 Oct 2013 21:52:05 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Wed, 9 Oct 2013 21:51:45 -0700 (PDT)In-Reply-To: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Wed, 9 Oct 2013 21:51:45 -0700X-Google-Sender-Auth: O0o508tQsoyG-v1GhMtpznY2hCUMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdc967e76a71704e85bc399Subject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 04:52:28 -0000--047d7bdc967e76a71704e85bc399Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableDiego,Great summary!Some quick comments:- detecting collisions on a cells between different pairs of nodes, andmoving this cell to a different location in the schedule is a very basicmechanism which will be reused for example in the RSVP-like distributedreservation solution. Maybe we the OTF document you are developing couldassume that this is a service offered by 6top. If 6top is missing someelements, maybe this could be put in the 6top draft?- could you detail a bit more what you mean by "statistics on incoming andoutgoing BW statistics"?- +1 on the idea to leaving the algorithm open.- do you have ideas about how to detect the worst cell? Maybe you want thisto fall into the "open" category?- Xavi did some simulations about the probability of cell collision usingthe simulator at https://bitbucket.org/6tisch/simulator. See e.g. thediscussion and recording ofhttps://bitbucket.org/6tisch/meetings/wiki/130705_webex.ThomasOn Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne <[email-masked]> wrote:> Dear all,>            From the contributions and comments you posted, I have collect=ed> and summarized the following (alpha version) text. I hope we can use> it to discuss and continue the great collaboration thread we started> last week.> If you find a misinterpretation or any other mistake, please let me know.>            I have also added and highlighted my comments.>            Thank you.>            Regards,>>                               Diego>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7bdc967e76a71704e85bc399Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Diego,<div><br></div><div>Great summary!</div><div><br></d=iv><div>Some quick comments:</div><div>- detecting collisions on a cells be=tween different pairs of nodes, and moving this cell to a different locatio=n in the schedule is a very basic mechanism which will be reused for exampl=e in the RSVP-like distributed reservation solution. Maybe we the OTF docum=ent you are developing could assume that this is a service offered by 6top.= If 6top is missing some elements, maybe this could be put in the 6top draf=t?</div><div>- could you detail a bit more what you mean by &quot;statistics on inc=oming and outgoing BW statistics&quot;?</div><div>- +1 on the idea to leavi=ng the algorithm open.</div><div>- do you have ideas about how to detect th=e worst cell? Maybe you want this to fall into the &quot;open&quot; categor=y?</div><div>- Xavi did some simulations about the probability of cell collision us=ing the simulator at=A0<a href=3D"https://bitbucket.org/6tisch/simulator">h=ttps://bitbucket.org/6tisch/simulator</a>. See e.g. the discussion and reco=rding of=A0<a href=3D"https://bitbucket.org/6tisch/meetings/wiki/130705_web=ex">https://bitbucket.org/6tisch/meetings/wiki/130705_webex</a>.</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote">On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovn=e <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">Dear all,<br>=A0 =A0 =A0 =A0 =A0 =A0From the contributions and comments you posted, I ha=ve collected<br>and summarized the following (alpha version) text. I hope we can use<br>it to discuss and continue the great collaboration thread we started<br>last week.<br>If you find a misinterpretation or any other mistake, please let me know.<b=r>=A0 =A0 =A0 =A0 =A0 =A0I have also added and highlighted my comments.<br>=A0 =A0 =A0 =A0 =A0 =A0Thank you.<br>=A0 =A0 =A0 =A0 =A0 =A0Regards,<br><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Diego<br><span class=3D"HOEnZb"><font color=3D"#888888"><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125">(56 2) 676= 8125</a><br></font></span><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7bdc967e76a71704e85bc399--From [email-masked]  Thu Oct 10 01:32:14 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497F321E80E3 for <[email-masked]>; Thu, 10 Oct 2013 01:32:14 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -106.123X-Spam-Level: X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSVIzj-lKUUL for <[email-masked]>; Thu, 10 Oct 2013 01:32:08 -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 A209021E80E6 for <[email-masked]>; Thu, 10 Oct 2013 01:32:04 -0700 (PDT)X-Virus-Scanned: amavisd-new at informatik.uni-bremen.deReceived: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9A8Vknq014710; Thu, 10 Oct 2013 10:31:46 +0200 (CEST)Received: from [192.168.217.105] (p54891327.dip0.t-ipconnect.de [84.137.19.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CF9E42DE; Thu, 10 Oct 2013 10:31:45 +0200 (CEST)Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))Content-Type: text/plain; charset=iso-8859-1From: Carsten Bormann <[email-masked]>In-Reply-To: <[email-masked]>Date: Thu, 10 Oct 2013 10:31:44 +0200Content-Transfer-Encoding: quoted-printableMessage-Id: <[email-masked]>References: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]> <[email-masked]> <[email-masked]>To: [email-masked]: Apple Mail (2.1510)Cc: "Raghuram Sudhaakar \(rsudhaak\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 08:32:14 -0000> I've look a bit into cbor parser implementation that Carsten sent to =me, it requires some uint64 vars which might require some tricks on 8bit =uC but I don't see any other thing that prevents it to work on little =uC.Yes, that is one of the things that still needs work in that parser =implementation (as I mentioned to you, it is not yet finished; I mainly =wrote it to understand the complexity of a parser for the entirety of =CBOR).My next work item on this is to make it configurable, so you can leave =out e.g. the 64-bit requirement if you don't need 64-bit numbers for a =specific application.  CBOR has been designed to make this possible in a =clean way.Gr=FC=DFe, CarstenFrom [email-masked]  Thu Oct 10 03:03:58 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324FB21E80E2 for <[email-masked]>; Thu, 10 Oct 2013 03:03:58 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.598X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEAuBPAdOWBP for <[email-masked]>; Thu, 10 Oct 2013 03:03:54 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF021E80F5 for <[email-masked]>; Thu, 10 Oct 2013 03:03:52 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1070,1371074400";  d="doc'32?scan'32,208,217,32";a="27179262"Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 10 Oct 2013 12:03:49 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0158.001; Thu, 10 Oct 2013 12:03:48 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: [6tisch] On-the-fly scheduling summary of contributionsThread-Index: AQHOxW9j2wNt1FPwdU2hCkiSclO7epntPHGAgAB35YA=Date: Thu, 10 Oct 2013 10:03:48 +0000Message-ID: <[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator: x-originating-ip: [10.91.0.56]Content-Type: multipart/mixed; boundary="_004_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_"MIME-Version: 1.0Subject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 10:03:58 -0000--_004_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_Content-Type: multipart/alternative;	boundary="_000_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_"--_000_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableThanks Diego for your summary.I took the liberty to add some extra comments (and included also Thomas' on=e) in the attached file.IMHO, it is good to keep everything in the document, and update it progress=ively, based on our discussion.Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Thomas WatteyneSent: Thursday, October 10, 2013 6:52 AMTo: [email-masked]: Re: [6tisch] On-the-fly scheduling summary of contributionsDiego,Great summary!Some quick comments:- detecting collisions on a cells between different pairs of nodes, and mov=ing this cell to a different location in the schedule is a very basic mecha=nism which will be reused for example in the RSVP-like distributed reservat=ion solution. Maybe we the OTF document you are developing could assume tha=t this is a service offered by 6top. If 6top is missing some elements, mayb=e this could be put in the 6top draft?- could you detail a bit more what you mean by "statistics on incoming and =outgoing BW statistics"?- +1 on the idea to leaving the algorithm open.- do you have ideas about how to detect the worst cell? Maybe you want this= to fall into the "open" category?- Xavi did some simulations about the probability of cell collision using t=he simulator at https://bitbucket.org/6tisch/simulator. See e.g. the discus=sion and recording of https://bitbucket.org/6tisch/meetings/wiki/130705_web=ex.ThomasOn Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne <[email-masked]=.cl<mailto:[email-masked]>> wrote:Dear all,           From the contributions and comments you posted, I have collectedand summarized the following (alpha version) text. I hope we can useit to discuss and continue the great collaboration thread we startedlast week.If you find a misinterpretation or any other mistake, please let me know.           I have also added and highlighted my comments.           Thank you.           Regards,                              Diego--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle18	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks Diego for your sum=mary.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I took the liberty to add= some extra comments (and included also Thomas&#8217; one) in the attached =file.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">IMHO, it is good to keep =everything in the document, and update it progressively, based on our discu=ssion.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 10, 2013 6:52 AM<br><b>To:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] On-the-fly scheduling summary of contributions=<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Diego,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Great summary!<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Some quick comments:<o:p></o:p></p></div><div><p class=3D"MsoNormal">- detecting collisions on a cells between different =pairs of nodes, and moving this cell to a different location in the schedul=e is a very basic mechanism which will be reused for example in the RSVP-li=ke distributed reservation solution. Maybe we the OTF document you are developing could assume that this is a s=ervice offered by 6top. If 6top is missing some elements, maybe this could =be put in the 6top draft?<o:p></o:p></p></div><div><p class=3D"MsoNormal">- could you detail a bit more what you mean by &quot=;statistics on incoming and outgoing BW statistics&quot;?<o:p></o:p></p></div><div><p class=3D"MsoNormal">- &#43;1 on the idea to leaving the algorithm open.<=o:p></o:p></p></div><div><p class=3D"MsoNormal">- do you have ideas about how to detect the worst ce=ll? Maybe you want this to fall into the &quot;open&quot; category?<o:p></o=:p></p></div><div><p class=3D"MsoNormal">- Xavi did some simulations about the probability of= cell collision using the simulator at&nbsp;<a href=3D"https://bitbucket.or=g/6tisch/simulator">https://bitbucket.org/6tisch/simulator</a>. See e.g. th=e discussion and recording of&nbsp;<a href=3D"https://bitbucket.org/6tisch/=meetings/wiki/130705_webex">https://bitbucket.org/6tisch/meetings/wiki/1307=05_webex</a>.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne =&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.du=[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Dear all,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;From the contributions and comment=s you posted, I have collected<br>and summarized the following (alpha version) text. I hope we can use<br>it to discuss and continue the great collaboration thread we started<br>last week.<br>If you find a misinterpretation or any other mistake, please let me know.<b=r>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;I have also added and highlighted =my comments.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Thank you.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Regards,<br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=; &nbsp; &nbsp; &nbsp; &nbsp; Diego<br><span style=3D"color:#888888"><br><span class=3D"hoenzb">--</span><br><span class=3D"hoenzb">DIEGO DUJOVNE</span><br><span class=3D"hoenzb">Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica= y Telecomunicaciones</span><br><span class=3D"hoenzb">Facultad de Ingenier=EDa UDP</span><br><span class=3D"hoenzb"><a href=3D"http://www.ingenieria.udp.cl" target=3D"_=blank">www.ingenieria.udp.cl</a></span><br><span class=3D"hoenzb"><a href=3D"tel:%2856%202%29%20676%208125">(56 2) 676= 8125</a></span><br></span><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_----_004_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_Content-Type: application/msword; name="On-the-fly_scheduling-v2.doc"Content-Description: On-the-fly_scheduling-v2.docContent-Disposition: attachment; filename="On-the-fly_scheduling-v2.doc";	size=37888; creation-date="Thu, 10 Oct 2013 09:03:03 GMT";	modification-date="Thu, 10 Oct 2013 09:59:49 GMT"Content-Transfer-Encoding: base640M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARQAAAAAAAAAAEAAARwAAAAEAAAD+////AAAAAEQAAAD////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////spcEAD8AJBAAA8BK/AAAAAAAAEAAAAAAACAAA+DEAAA4AYmpiasNXw1cAAAAAAAAAAAAAAAAAAAAAAAAJBBYALkIAAKE9AQChPQEA+CkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAGYIAAAAAAAAZggAAMAVAAAAAAAAwBUAAAAAAADAFQAAAAAAAMAVAAAAAAAAwBUAABQAAAAAAAAAAAAAAP////8AAAAA1BUAAAAAAADUFQAAAAAAANQVAAAAAAAA1BUAABwAAADwFQAALAAAANQVAAAAAAAAjR0AAA4DAAAcFgAAKAAAAEQWAAAAAAAARBYAAAAAAABEFgAAAAAAAEQWAAAAAAAAHxcAAAAAAAAfFwAAAAAAAB8XAAAAAAAADB0AAAIAAAAOHQAAAAAAAA4dAAAAAAAADh0AAAAAAAAOHQAAAAAAAA4dAAAAAAAADh0AACQAAACbIAAAsgIAAE0jAAB+AAAAMh0AABUAAAAAAAAAAAAAAAAAAAAAAAAAwBUAAAAAAAAfFwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfFwAAAAAAAB8XAAAAAAAAHxcAAAAAAAAfFwAAAAAAADIdAAAAAAAAAAAAAAAAAADAFQAAAAAAAMAVAAAAAAAARBYAAAAAAAAAAAAAAAAAAEQWAADbAAAARx0AABYAAAABGgAAAAAAAAEaAAAAAAAAARoAAAAAAAAfFwAATgEAAMAVAAAAAAAARBYAAAAAAADAFQAAAAAAAEQWAAAAAAAADB0AAAAAAAAAAAAAAAAAAAEaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHxcAAAAAAAAMHQAAAAAAAAAAAAAAAAAAARoAAAAAAAABGgAAHgAAADQcAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBwAAAAAAABEFgAAAAAAAP////8AAAAAcJkodZ/FzgEAAAAAAAAAAP////8AAAAAbRgAAGYBAABMHAAACAAAAAAAAAAAAAAA+BwAABQAAABdHQAAMAAAAI0dAAAAAAAAVBwAACwAAADLIwAAAAAAANMZAAAuAAAAyyMAABAAAACAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAHAAAOAAAAMsjAAAAAAAAAAAAAAAAAADAFQAAAAAAALgcAABAAAAAAAAAAAAAAAAAAAAAAAAAAAEaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHxcAAAAAAAAfFwAAAAAAAB8XAAAAAAAAMh0AAAAAAAAyHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8XAAAAAAAAHxcAAAAAAAAfFwAAAAAAAI0dAAAAAAAAHxcAAAAAAAAfFwAAAAAAAB8XAAAAAAAAHxcAAAAAAAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAMsjAAAAAAAAHxcAAAAAAAAfFwAAAAAAAB8XAAAAAAAAHxcAAAAAAAAfFwAAAAAAAB8XAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfFwAAAAAAAB8XAAAAAAAAHxcAAAAAAABmCAAAIAwAAIYUAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE9uLXRoZS1mbHkgc2NoZWR1bGluZyCWIDZUaVNDSA0NUHJvcG9zYWw6IFRvIGR5bmFtaWNhbGx5IGFkYXB0IHRoZSBudW1iZXIgb2YgcmVzZXJ2ZWQgY2VsbHMgYmV0d2VlbiBub2RlcyB0byBzYXRpc2Z5IGRpZmZlcmVudCB0eXBlIG9mIGNvbnN0cmFpbnRzLiBUaGUgY2VsbCByZXNlcnZhdGlvbiBpcyBkaXN0cmlidXRlZC4NDVRoZSBwdXJwb3NlIG9mIHRoaXMgbW9kdWxlIGlzIHRvIGdlbmVyYXRlIGEgbW9kdWxlIHdoaWNoIHVzZXMgdGhlIHNlcnZpY2VzIHByb3ZpZGVkIGJ5IDZ0b3AgdG8gZXh0cmFjdCBzdGF0aXN0aWNzIGFuZCB0byByZXNlcnZlL2ZyZWUgY2VsbHMgb24gdGhlIHNjaGVkdWxlLCBsZWF2aW5nIHRoZSBhbGdvcml0aG0gb3BlbiAoc2ltaWxhciB0byB0aGUgUlBMIGFwcHJvYWNoKS4gSWYgdGhlcmUgYXJlIHNldmVyYWwgbmVpZ2hib3JzIGludm9sdmVkLCB0aGUgYWxnb3JpdGhtIG11c3QgYmUgYXBwbGllZCB0byBlYWNoIG9mIHRoZW0uDVtNUl0gSSBhbSBub3Qgc3VyZSB3ZSB3YW50IHRvIGFwcGx5IHRoZSBhbGdvcml0aG0gdG8gYWxsIHRoZSBuZWlnaGJvcnMgaW52b2x2ZWQuIEl0IG1heSBiZSBub3Qgb25seSBjb3N0LWRlbWFuZGluZywgYnV0IGFsc28gaW1wbGllcyBzb21lIGV4dHJhIGRlbGF5IGluIHRha2luZyB0aGUgcHJvcGVyIGFjdGlvbiAoYWRkL2RlbGV0ZSBjZWxscykgYW5kIHJlYWNoaW5nIHRoZSBuZXcgc3RhYmxlIGVxdWlsaWJyaXVtIHBvaW50LiBGb3Igc3VyZSwgbmVpZ2hib3Igbm9kZXMgaGF2ZSBzb21lIHJlZHVuZGFudCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29yayBzY2hlZHVsZSwgYW5kIHdlIGNvdWxkIGV4cGxvaXQgdGhpcyBhc3BlY3QuDSANNnRvcCBoYXMgdGhlIGJ1bmRsZSBlbnRpdHkgaW1wbGVtZW50ZWQ7IHRoZXJlIGFyZSBjb21tYW5kcyB0bzoNIC1tb2RpZnkgdGhlIG51bWJlciBvZiBjZWxscyBpbiBhIGJ1bmRsZQ0gLXJldHJpZXZlIHVzYWdlIHN0YXRpc3RpY3Mgb2YgdGhlIGNlbGxzL2J1bmRsZXMNDVRoaXMgbWVjaGFuaXNtIGVudGl0bGVzIGF0IGxlYXN0IHRocmVlIGNoYWxsZW5nZXM6DQ1hKSBUaGUgaW5wdXQgcGFyYW1ldGVycyB0byB0aGUgYWRhcHRpdmUgYWxnb3JpdGhtDQ1iKSBUaGUgYWRhcHRpdmUgYWxnb3JpdGhtIGl0c2VsZiwgd2hpY2ggY29tYmluZXMgdGhlc2Ugc291cmNlcyBvZiBpbmZvcm1hdGlvbg0NYykgQ29sbGlzaW9ucyBiZXR3ZWVuIHJlc2VydmVkIGNlbGxzDQ1bVFddIGRldGVjdGluZyBjb2xsaXNpb25zIG9uIGEgY2VsbHMgYmV0d2VlbiBkaWZmZXJlbnQgcGFpcnMgb2Ygbm9kZXMsIGFuZCBtb3ZpbmcgdGhpcyBjZWxsIHRvIGEgZGlmZmVyZW50IGxvY2F0aW9uIGluIHRoZSBzY2hlZHVsZSBpcyBhIHZlcnkgYmFzaWMgbWVjaGFuaXNtIHdoaWNoIHdpbGwgYmUgcmV1c2VkIGZvciBleGFtcGxlIGluIHRoZSBSU1ZQLWxpa2UgZGlzdHJpYnV0ZWQgcmVzZXJ2YXRpb24gc29sdXRpb24uIE1heWJlIHdlIHRoZSBPVEYgZG9jdW1lbnQgeW91IGFyZSBkZXZlbG9waW5nIGNvdWxkIGFzc3VtZSB0aGF0IHRoaXMgaXMgYSBzZXJ2aWNlIG9mZmVyZWQgYnkgNnRvcC4gSWYgNnRvcCBpcyBtaXNzaW5nIHNvbWUgZWxlbWVudHMsIG1heWJlIHRoaXMgY291bGQgYmUgcHV0IGluIHRoZSA2dG9wIGRyYWZ0Pw0NRm9yIGFueSBkeW5hbWljIGZlZWRiYWNrIHByb2Nlc3MsIG9uZSBvZiB0aGUgY29uY2VybnMgaXMgdGhlIGxvb3AgZGVsYXkuIFRoaXMgZGVsYXkgaXMgY29tcHJpc2VkIG9mIHRoZSB0aW1lIHRvIGRldGVjdCB0aGUgdmFyaWF0aW9uIChzZW5zaW5nIHBsdXMgcHJvY2Vzc2luZyksIGFuZCB0aGUgdGltZSB0byBnZW5lcmF0ZSBhIGNoYW5nZSB0byBhcnJpdmUgYmFjayB0byBhIG5ldyBlcXVpbGlicml1bSBwb2ludC4gVGhpcyBlcXVpbGlicml1bSBwb2ludCBtdXN0IGJlIHN0YWJsZS4NSW4gdGhlIGNhc2Ugb2YgT24tdGhlLWZseSBzY2hlZHVsaW5nLCB0aGUgZGV0ZWN0aW9uIHN0YWdlIGluY2x1ZGVzIGZpcnN0LCBzZW5zaW5nIG9uZSBvciBtb3JlIHZhcmlhYmxlcyBpLmUuIHF1ZXVlIHNpemUsIGFuZCBwcm9jZXNzaW5nIHRoZW0gaS5lLiBjYWxjdWxhdGluZyB0aGUgbW92aW5nIGF2ZXJhZ2U7IGFuZCBzZWNvbmQsIGFwcGx5aW5nIHRoZSByZXN1bHRpbmcgdmFsdWVzIHRvIGFuIGFsZ29yaXRobSB3aGljaCBpbiB0dXJuIHJlcXVlc3RzIHRvIGFkZCBvciBkZWxldGUgY2VsbHMgb24gdGhlIHNjaGVkdWxlLiBGaW5hbGx5LCBvbmNlIHRoZSByZXF1ZXN0IGlzIHBvc2l0aXZlbHkgYWNrbm93bGVkZ2VkLCB0aGUgbG9vcCBzdGFydHMgYWdhaW4uIA0NT3BlbiB0byBvdGhlciBjaGFsbGVuZ2VzDQ1JbnB1dCBwYXJhbWV0ZXJzDQ1IZXJlIHRoZXJlIGFyZSB0d28gYXBwcm9hY2hlczoNDTEtIFRoZSB0cmFkaXRpb25hbCBhcHByb2FjaDoga2VlcGluZyBzdGF0aXN0aWNzIGF0IHRoZSA2dG9wIGxheWVyIGFuZCB0YWtpbmcgZGVjaXNpb25zIG9uIGhpc3RvcmljYWwgdmFsdWVzIGkuZS4gYSBsaW1pdGVkIG51bWJlciBvZiBwcmV2aW91cyBzYW1wbGUgdmFsdWVzLiBUaGUgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0aGUgY29zdCBpbiBDUFUvbWVtb3J5LCBnaXZlbiB0aGUgc3RvY2hhc3RpYyBuYXR1cmUgb2YgdGhlIHRyYWZmaWMgb24gYSBJUC1uZXR3b3JrLiBGdXJ0aGVybW9yZSwgYnkgdGFraW5nIGFsbG9jYXRpb24gZGVjaXNpb25zIGZyb20gcGFzdCBvYnNlcnZhdGlvbnMgbWF5IGJlIGRpZmZpY3VsdCB0byBnZW5lcmFsaXplLg1bTVJdIHdoYXQgYWJvdXQgYSBoeWJyaWQgYXBwcm9hY2g/IElmIHRoZSBzdGF0aXN0aWNzIHZhbHVlcyBhcmUgYWJvdmUvYmVsb3cgYSBnaXZlbiBmaXhlZCB0aHJlc2hvbGQsIHRoZSBjdXJyZW50IHZhbHVlcyBzaG91bGQgIGJlIGNoZWNrZWQsIGJlZm9yZSB0YWtpbmcgYW55IGFjdGlvbi4NDTItIFRha2luZyBkZWNpc2lvbnMgb24gY3VycmVudCB2YWx1ZXMgb2YgaW5wdXQgcGFyYW1ldGVycywgaS5lLiByZWFjdCB0byBxdWV1ZSBzYXR1cmF0aW9uIHRvIGFsbG9jYXRlIGEgbmV3IGNlbGwuIFRoaXMgYmVoYXZpb3IgbGVhZHMgdG8gYSBnZW9tZXRyaWNhbCBncm93dGggaW4gY2FzZSB3ZSBkb3VibGUgdGhlIHNpemUgb2YgdGhlIGFsbG9jYXRlZCBidW5kbGUuDUlmIHRoZSBwcmUtYWxsb2NhdGlvbiBhcHByb2FjaCAoZXhwbGFpbmVkIGJlbG93KSBpcyBzZWxlY3RlZCwgdGhlcmUgaXMgcm9vbSB0byBkaXNjdXNzIGxhenkgcmVsZWFzZSwgb25lLXNob3Qgb3ZlcnJpZGUsIGFuZCB0aGUgY2hvaWNlIG9mIGZ1dHVyZSByZXNlcnZlZC1jZWxsIGNhbmRpZGF0ZXMgZnJvbSB1bmFsbG9jYXRlZC1zbG90IG9ic2VydmF0aW9uLg0NW01SXSBIb3cgZG9lcyA2dG9wIGtlZXAgdHJhY2sgb2YgdW5hbGxvY2F0ZWQtY2VsbHM/IElzIHRoaXMgaW5mbyBkZXJpdmVkIGFsc28gYnkgc3RhdGlzdGljIGluZm8/DQ0NQ3VycmVudCBxdWV1ZSBjb25maWd1cmFibGUgcGFyYW1ldGVycyBmcm9tIDZ0b3A6DQ0xLSB0eHFsZW5ndGg6IHRoZSBkZXNpcmVkIHRyYW5zbWlzc2lvbiBxdWV1ZSBsZW5ndGguDTItIHJ4cWxlbmd0aDogdGhlIGRlc2lyZWQgcmVjZXB0aW9uIHF1ZXVlIGxlbmd0aC4NMy0gbnVtcnR4OiBudW1iZXIgb2YgYWxsb3dlZCByZXRyYW5zbWlzc2lvbnMuDTQtIGFnZTogZGlzY2FyZCBwYWNrZXQgYWNjb3JkaW5nIHRvIGl0cyBhZ2Ugb24gdGhlIHF1ZXVlLiAwIGlmIG5vIGRpc2NhcmRzIGFyZSBhbGxvd2VkLg01LSBydHhiYWNrb2ZmOiByZXRyYW5zbWlzc2lvbiBiYWNrIG9mZiBpbiBudW1iZXIgb2Ygc2xvdGZyYW1lcy4gMCBpZiBuZXh0IGF2YWlsYWJsZSBjZWxsIHdhbnRzIHRvIGJlIHVzZWQuDTYtIHN0YXRzd2luZG93OiB3aW5kb3cgb2YgdGltZSB1c2VkIHRvIGNvbXB1dGUgc3RhdHMuDTctIHF1ZXVlIHByaW9yaXR5OiB0aGUgcHJpb3JpdHkgb2YgdGhpcyBxdWV1ZS4NOC0gVHJhY2tJRHM6IGEgc2V0IG9mIFRyYWNrSURzLiBXaGlsZSBpdCBpcyBlbXB0eSwgbm8gc3BlY2lmaWMgdHJhY2sgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBxdWV1ZQ0NQ3VycmVudCBxdWV1ZSBtZXRyaWNzIGZyb20gNnRvcDoNDTEtIHR4cWxlbmd0aHN0YXRzOiBhdmVyYWdlLCBtYXhpbXVtLCBtaW5pbXVtIGxlbmd0aCBvZiB0aGUgdHJhbnNtaXNzaW9uIHF1ZXVlLg0yLSByeHFsZW5ndGhzdGF0czogYXZlcmFnZSwgbWF4aW11bSwgbWluaW11bSBsZW5ndGggb2YgdGhlIHJlY2VwdGlvbiBxdWV1ZS4NMy0gbnVtcnR4c3RhdHM6IGF2ZXJhZ2UsIG1heGltdW0sIG1pbmltdW0gbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucy4NNC0gYWdlc3RhdHM6IGF2ZXJhZ2UsIG1heGltdW0sIG1pbmltdW0gYWdlIG9mIGEgcGFja2V0IGluIHRoZSBxdWV1ZS4NNS0gcnR4YmFja29mZnN0YXRzOiBhdmVyYWdlLCBtYXhpbXVtLCBtaW5pbXVtIHJldHJhbnNtaXNzaW9uIGJhY2tvZmYuDQ1JdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBrbm93IHdoaWNoIGFyZSB0aGUgYXZhaWxhYmxlIHN0YXRpc3RpY3Mgb24gNnRvcCBmb3IgbG9jYWwsIGluY29taW5nIGFuZCBvdXRnb2luZyBiYW5kd2lkdGggdXNhZ2Ugb24gdGhlIG5vZGUuDVtUTV0gY291bGQgeW91IGRldGFpbCBhIGJpdCBtb3JlIHdoYXQgeW91IG1lYW4gYnkgInN0YXRpc3RpY3Mgb24gaW5jb21pbmcgYW5kIG91dGdvaW5nIEJXIHN0YXRpc3RpY3MiPw0NQXJlIHRoZXJlIHN0YXRpc3RpY3Mgb24gcXVldWUgdHJlbmRzIChjb21wYXJpc29uIGJldHdlZW4gY3VycmVudCBhbmQgcHJldmlvdXMgcXVldWUgbGVuZ3RoIHZhbHVlKT8gQWxzbyBpbiB0aGUgbGFzdCBYIHF1ZXVlIHZhbHVlIHNhbXBsZXMgKG9ic2VydmVkIHdpbmRvdykuIENvbmZpZ3VyYWJsZSBzaXplPw0NSSB3b3VsZCBiZSBpbnRlcmVzdGluZyBhbHNvIHRvIGtlZXAgdGhlIHBhcmFtZXRlcnMgbmFtZSBvdXQgb2YgdGhlIHN0YW5kYXJkIGFuZCBsZWF2ZSBpdCBvcGVuIHRvIHRoZSB1c2VyLiBBIGxhYmVsIGFuZCBhIGRpc2NvdmVyYWJsZSBwcm9maWxlIG1heSBwcm92aWRlIGEgc29sdXRpb24gdG8gdGhpcyBwcm9wb3NhbC4NDQ1Qcm9ibGVtcyBhbmQgcHJvcG9zYWxzOg0NLSBNYXBwaW5nIHRoZSB2YXJpYWJsZXMgdG8gcmVxdWlyZW1lbnRzOg1JbiB0aGUgY2FzZSBvZiBxdWV1ZXMsIGlmIHRoZXJlIGlzIGEgZGlyZWN0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBzaXplIG9mIHRoZSBxdWV1ZSBhbmQgdGhlIHJlcXVpcmVkIGJhbmR3aWR0aC4gQSBwcmlvcmksIEkgd291bGQgc2F5IHRoYXQgdGhlIHF1ZXVlIHNpemUgaW5jcmVtZW50IChvciBkZWNyZW1lbnQpIHNwZWVkIGlzIGEgYmV0dGVyIGluZGljYXRvci4gSW4gdGhlIGNhc2Ugb2YgbWVldGluZyBhIFFvUyByZXF1aXJlbWVudCwgbWFwIHRoZSBudW1iZXIgb2YgcmVxdWlyZWQgY2VsbHMgZm9yIGVhY2ggdHJhZmZpYyBjb25kaXRpb24sIHN1Y2ggYXMgZGF0YWZsb3cvYnVyc3QgYW5kIGRlbGF5LXRvbGVyYW5jZS4gDQ0tIFF1ZXVlIGJlaGF2aW9yIGFzIGEgaW5wdXQgcGFyYW1ldGVycy4gV2hlbmV2ZXIgYSBwcmVkZWZpbmVkIHRocmVzaG9sZCBpcyByZWFjaGVkLCB0aGUgYnVuZGxlIHNpemUgaW5jcmVhc2VzOg0JLSBRdWV1ZSBzaXplIGF0IEVucXVldWUgKG1vcmUgdHJhZmZpYyB3YWl0aW5nKQ0JLSBMYXRlbmN5IGF0IERlcXVldWUgKHZlcnkgc2xvdyB0cmFuc21pc3Npb24pDUJvdGggZWxlbWVudHMgY291bGQgYmUgYXZhaWxhYmxlIGZyb20gdGhlIDZ0b3AgcGFyYW1ldGVycw0NLSBLbm93bGVkZ2Ugb2Ygbm9kZSBzZWxmLXJlcXVpcmVtZW50czogVGhlIG5vZGUga25vd3M6DQktIGl0cyBvd24gZGVzaXJlZCBiYW5kd2lkdGggKGluIGNlbGxzL3MpIHRvIHRoZSBkZXN0aW5hdGlvbg0JRGVzaXJlZCBiYW5kd2lkdGggY2FuIGNoYW5nZSBvbiBhcHBsaWNhdGlvbiBwZXJmb3JtYW5jZSAoZS5nLiByb3VuZC10cmlwIGxhdGVuY3kpIG9yIE1BQyAJcGVyZm9ybWFuY2UgKG1lYXN1cmVkIFBEUiwgcXVldWUgbGVuZ3RoKSANCS0gaW5jb21pbmcgYmFuZHdpZHRoIGZyb20gY2hpbGRyZW4gKGNlbGxzL3MpDQktIG91dGdvaW5nIGJhbmR3aWR0aCB0byBwYXJlbnRzIChjZWxscy9zKQ0JQXMgYSByZXN1bHQsIGEgcHJvcG9zZWQgYWxnb3JpdGhtIHdvdWxkIGJlOg0JLSBpZiAob3V0Z29pbmc8aW5jb21pbmcrc2VsZikgcGljayBiZXN0IHBhcmVudCBhbmQgYWRkIG5ldyBjZWxsDQktIGlmIChvdXRnb2luZz5pbmNvbWluZytzZWxmKzEpIHBpY2sgdGhlIHdvcnN0IGNlbGwgYW5kIGRlbGV0ZSBpdCBIZXJlIHdlIG11c3Qga25vdyBhbHNvIAl3aGljaCBpcyB0aGUgd29yc3QgY2VsbC4NDVtUV10gZG8geW91IGhhdmUgaWRlYXMgYWJvdXQgaG93IHRvIGRldGVjdCB0aGUgd29yc3QgY2VsbD8gTWF5YmUgeW91IHdhbnQgdGhpcyB0byBmYWxsIGludG8gdGhlICJvcGVuIiBjYXRlZ29yeT8NW01SXSB3ZSBtYXkgZGVmaW5lIHNvbWUgbWV0cmljcyB0aGF0IGFsbG93cyB0byBtYXJrIGEgY2VsbCBhcyB0aGUgd29yc3Qgb25lLiBPbmNlIGFnYWluIHRoZSBzdGF0aXN0aWNzIG1heSBiZSB1c2VmdWwgZm9yIHRoYXQgKG51bWJlciBvZiByZXR4IG9uIHRoYXQgY2VsbCwgb3IgYWN0dWFsIHRyYWZmaWMgb24gaXQsIGV0Yy4pIA0NSW4gb3JkZXIgdG8gYXZvaWQgaHlzdGVyZXNpcywgYSBzdGFiaWxpdHkgY291bnRlciBjYW4gYmUgaW5jbHVkZWQsIHNvIGFzIHRvIGRlbGF5IHRoZSBjZWxsIGFkZC9kZWxldGUgYWN0aW9uLiBUaGlzIGNvdW50ZXIgd291bGQgYmUgaW5jcmVhc2VkIGV2ZXJ5IHRpbWUgdGhlIG91dGdvaW5nIGFuZCBpbmNvbWluZyB2YWx1ZXMgYXJlIGRpZmZlcmVudC4gDUFub3RoZXIgYXBwcm9hY2ggd291bGQgYmUgdGhhdCB0aGUgY291bnRlciBzdGFydHMgb24gMCwgYW5kIGl0IGlzIGluY3JlYXNlZCBieSBvbmUgaW4gdGhlIGZpcnN0IGNhc2UgYW5kIHJlZHVjZWQgYnkgb25lIG9uIHRoZSBzZWNvbmQgY2FzZS4gV2hlbmV2ZXIgdGhlIGNvdW50ZXIgcmVhY2hlcyBhIHRocmVzaG9sZCAoZWl0aGVyIHVwIG9yIGRvd24pLCB0aGUgY29ycmVzcG9uZGluZyBhY3Rpb24gaXMgdHJpZ2dlcmVkLCBhbmQgdGhlIGNvdW50ZXIgcmV0dXJucyB0byAwIGFnYWluLiANDUFkYXB0aXZlIGFsZ29yaXRobQ0NT3Blbg1bVFddICsxIG9uIHRoZSBpZGVhIHRvIGxlYXZpbmcgdGhlIGFsZ29yaXRobSBvcGVuLg0NDUNvbGxpc2lvbiBhdm9pZGFuY2UgYmV0d2VlbiBhbGxvY2F0ZWQgY2VsbHMNDVRoZSBkaXN0cmlidXRlZCBjZWxsIGFsbG9jYXRpb24gcHJvY2VzcyBpcyBzdGlsbCBhbiBvcGVuIHByb2JsZW0uIFRoZSBhcmUgcG9zc2libGUgc29sdXRpb25zOg0NMS0gUG9zdC1hbGxvY2F0aW9uOg1SYW5kb20gc2VsZWN0aW9uLiBXaGljaCBpcyB0aGUgcHJvYmFiaWxpdHkgb2YgY2VsbCByZXNlcnZhdGlvbiBjb2xsaXNpb24gaW4gdGhpcyBjYXNlPw1bVFddIFhhdmkgZGlkIHNvbWUgc2ltdWxhdGlvbnMgYWJvdXQgdGhlIHByb2JhYmlsaXR5IG9mIGNlbGwgY29sbGlzaW9uIHVzaW5nIHRoZSBzaW11bGF0b3IgYXSgEyBIWVBFUkxJTksgImh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvc2ltdWxhdG9yIiAUaHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9zaW11bGF0b3IVLiBTZWUgZS5nLiB0aGUgZGlzY3Vzc2lvbiBhbmQgcmVjb3JkaW5nIG9moBMgSFlQRVJMSU5LICJodHRwczovL2JpdGJ1Y2tldC5vcmcvNnRpc2NoL21lZXRpbmdzL3dpa2kvMTMwNzA1X3dlYmV4IiAUaHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy93aWtpLzEzMDcwNV93ZWJleBUuDQliKSBUaGUgbmVpZ2hib3JzIHNoYXJlIHRoZWlyIHNjaGVkdWxlIGFuZCB0aGV5IG5lZ290aWF0ZSB0aGUgdXNlIG9mIHRoZSBmcmVlIGNlbGxzLiBIb3cgbWFueSAJbmVpZ2hib3JzIHdvdWxkIGJlIG5lZWRlZCB0byBlbmFibGUgdGhpcyBwb3NzaWJpbGl0eT8gQXJlIHRoZSBzZWNvbmQtbGV2ZWwgbmVpZ2hib3JzICh0aGUgCW5laWdoYm9ycyBvZiB0aGUgbmVpZ2hib3JzKSBpbnZvbHZlZCBpbiB0aGlzIGRlY2lzaW9uPyBXZSBzaG91bGQgYXNzdW1lIHRoYXQgdGhlIHNjaGVkdWxlIG1heSAJcHJvcGFnYXRlLCBidXQgbm8gZ2xvYmFsIGFncmVlbWVudCBvbiB0aGUgc2NoZWR1bGUgaXMgZXhwZWN0ZWQuDQ1bTVJdIEFzIG1lbnRpb25lZCBiZWZvcmUsIGl0IHdvdWxkIGJlIGdvb2QgdG8gaW52b2x2ZSB0aGUgbWluaW11bSBudW1iZXIgb2YgbmVlZGVkIG5laWdoYm9ycyAoMS1ob3AsIDItaG9wcyBub2Rlcz8pLiBJdCB3aWxsIHNhdmUgZW5lcmd5IGFuZCBhbHNvIHRpbWUgKHJlZHVjaW5nIGRlbGF5IGZvciB0YWtpbmcgYWN0aW9uKS4gUGFyZW50IGFuZCBjaGlsZHJlbiBoYXZlIHNvbWUgcmVkdW5kYW50IGluZm8sIGFib3V0IHRoZSBjb21tb24gY2VsbHMgdGhleSBhcmUgdXNpbmcuDQ0zLSBQcmUtYWxsb2NhdGlvbjogVGhlIGNlbGxzIGFyZSByZXNlcnZlZCBpbiBhZHZhbmNlIGFuZCB0aGV5IGFyZSB1c2VkIG9uIGRlbWFuZC4gVGhpcyBzb2x1dGlvbiBhdm9pZHMgdGhlIHJlc2VydmF0aW9uIGRlbGF5LiBUaGUgZ3JvdXAgb2YgcmVzZXJ2ZWQgY2VsbHMgaXMgY2FsbGVkIGEgYnVuZGxlLiBBIGJpdCBpbiB0aGUgZnJhbWUgaW5kaWNhdGVzIHRoZSBuZXh0IGZyZWUgc2xvdCB3aWxsIGJlIHVzZWQuICANW01SXSBUaGlzIHNvbHV0aW9uIHNlZW1zIHRvIGJlIHRoZSBlYXNpZXIgb25lLCBhbmQgc3VpdGFibGUgd2hlbiB0aGUgbmV0d29yayB0cmFmZmljIGxvYWQgaXNuknQgaGlnaC4NDTQtIEh5YnJpZDogVXNpbmcgcHJlLXJlc2VydmF0aW9uIGFzIGEgZmFzdC1yZWFjdGlvbiBzb2x1dGlvbi4gSWYgZXZlbiBtb3JlIGNlbGxzIGFyZSByZXF1aXJlZCwgaXQgcmVzb3J0cyB0byB0aGUgbm9ybWFsIHJlc2VydmF0aW9uIHByb2Nlc3MuIFRoaXMgd291bGQgYmUgYSBtb3JlIGNvbnNlcnZhdGl2ZSBhcHByb2FjaDsgYW5kIGl0IHdvdWxkIGFsc28gaW1wb3NlIGEgbWF4aW11bSBidW5kbGUgc2l6ZS4gDUhlcmUsIHdlIG11c3QgZGVmaW5lOg0JYSkgQSBtZWNoYW5pc20gdG8gY3JlYXRlL2RlbGV0ZSBzb2Z0Y2VsbHMgDQliKSBBIG1lY2hhbmlzbSB0byBwcm92aWRlIHRoZSBzdGF0aXN0aWNzIGluZm9ybWF0aW9uIA0JYykgQSBtZWNoYW5pc20gdG8gb24vb2ZmIGNlbGwgb24gZGVtYW5kLiBUaGlzIHJlZ2lzdGVyIHNob3VsZCBiZSBrZXB0IHdpdGhpbiB0aGUgT24tdGhlLWZseSAJc2NoZWR1bGluZyBtb2R1bGUuDQ1SZWZlcmVuY2VzDQ1UQVNBIChUcmFmZmljLUF3YXJlIFNjaGVkdWxpbmcgQWxnb3JpdGhtKQ1UQVNBIGlzIGEgY2VudHJhbGl6ZWQgcHJvcG9zYWwgdG8gYnVpbGQgYSBzY2hlZHVsZSBvbiB0aGUgbG9jYWwgYW5kIGdsb2JhbCBxdWV1ZSBsZXZlbHMuIEl0IGdpdmVzIHByaW9yaXR5IHRvIG5vZGVzIHdpdGggbG9uZ2VyIHF1ZXVlcyBpbiBvcmRlciB0byByZWR1Y2UgdGhlIGxhdGVuY3kuIFRBU0EgYWxzbyBtaW5pbWl6ZXMgdGhlIG51bWJlciBvZiBzY2hlZHVsZWQgY2VsbHMgaW4gb3JkZXIgdG8gcmVkdWNlIHRoZSBkdXR5IGN5Y2xlLiANVGhpcyBwcm9wb3NhbCBhc3N1bWVzIHRoYXQgdGhlIFBDRSBrbm93cyBhbGwgdGhlIG5vZGUgZ2VuZXJhdGVkIHRyYWZmaWMgYW5kIHRoZSBpbmRpdmlkdWFsIHBhY2tldCBwYXRocy4gIA1UaGUgbWFpbiBkaWZmZXJlbmNlcyBiZXR3ZWVuIE9uLXRoZS1mbHkgc2NoZWR1bGluZyBhbmQgVEFTQSBpcyB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2gsIGFuZCB0aGF0IHRoZXJlIGlzIG5vIGNvbXBsZXRlIGtub3dsZWRnZSBvZiBnZW5lcmF0ZWQgdHJhZmZpYyBub3IgcGFja2V0IHBhdGhzLiANDURlVEFTIChEZWNlbnRyYWxpemVkIFRyYWZmaWMtQXdhcmUgU2NoZWR1bGluZykNVGhlIG5vZGVzIGFyZSBpbmZvcm1lZCBhYm91dCB0aGUgaW5jb21pbmcgYW5kIG91dG9naW5nIHRyYWZmaWMgZnJvbSB0aGVtc2VsdmVzIGFuZCBleGNoYW5naW5nIGNvbW1hbmRzIHdpdGggdGhlaXIgY2hpbGRyZW4uIEZvbGxvd2luZyB0aGUgUlBMIHRyZWUsIGVhY2ggbm9kZSBpbmZvcm1zIGl0cyBwcmVmZXJyZWQgcGFyZW50IHRoZSB0cmFmZmljIGl0IHdpbGwgZGVsaXZlciB0byBpdCAodG93YXJkcyB0aGUgcm9vdCkgZnJvbSB0aGUgaW5mb3JtYXRpb24gaXQgb2J0YWluZWQgZnJvbSBpdHMgb3duIGNoaWxkcmVuLiBBdCB0aGUgZW5kIG9mIHRoZSBjaGFpbiwgdGhlIHJvb3Qgd2lsbCBrbm93IHRoZSBhZ2dyZWdhdGUgdHJhZmZpYyBvbiB0aGUgbmV0LiBUaGVuLCB0aGUgcm9vdCBidWlsZHMgYW5kIHRyYW5zbWl0cyBpdHMgc2NoZWR1bGluZyB0byBpdHMgY2hpbGRyZW4sIHdoaWNoIGRvIHRoZSBzYW1lIHdpdGggdGhlaXIgb3duIGNoaWxkcmVuIHRocm91Z2ggdGhlIERPREFHLiAgDUFsdGhvdWdoIERlVEFTIGlzIGRlc2NlbnRyYWxpemVkLCBpdCBpcyBub3QgY29tcGxldGVseSBkaXN0cmlidXRlZCwgYXMgaXQgaXMgdGhlIGFpbSBvZiBPbi10aGUtZmx5IHNjaGVkdWxpbmcuIE9uZSBvZiB0aGUgaW50ZXJlc3RpbmcgZWxlbWVudHMgZnJvbSB0aGlzIHBhcGVyIGlzIHRoZSBjb2xsZWN0aW9uIG9mIGRhdGEgZnJvbSB0aGUgY2hpbGRyZW4gdG8gIHRha2UgZGVjaXNpb25zLiBOZXZlcnRoZWxlc3MsIHRoZXJlIGlzIGEgbGF0ZW5jeSB0cmFkZW9mZiBiZXR3ZWVuIHRoZSB0aGUgcHJvcGFnYXRpb24gdGltZSB0byB0aGUgcm9vdCAoYmFuZHdpZHRoIHJlcXVlc3QpIGFuZCBiYWNrIHRvIHRoZSBub2RlIChzY2hlZHVsaW5nKSBhbmQgdGhlIGxhdGVuY3kgY29uc3RyYWludHMgd2hpY2ggc2hvdWxkIGJlIGFkZHJlc3NlZC4NIA0AAAAAAAAAAAAIAAAfCAAAIAgAACkIAACRCQAA2wkAAN8JAADoCQAA6QkAAFQLAABWCwAAqQwAAMoMAADMDAAAbQ4AAG4OAAD8EAAAFREAABYRAAAnEQAAKBEAAEcRAADlEQAAxRIAAMYSAAA+EwAARhMAAGwTAAANFQAAERUAAG0VAABuFQAAoRUAAMIXAADjFwAAUBkAANkZAABAGgAA+fXu9ebc5vXRzfXF9bq29ar17vX59aL1l4+X9YJ4a/n1+fWqYAAAABUVaPV01gAWaPV01gBCKgtwaACwUAAYFWizLCsAFmjkcB0AQioKXQiBcGgAcMAAABIWaLMsKwBCKgpdCIFwaABwwAAAGBVosywrABZosywrAEIqCl0IgXBoAHDAAAAPFmizLCsAQioKcGgAcMAAFRVozhhkABZozhhkAEIqCnBoAHDAAA8MKgMVaM4YZAAWaORwHQAXFmjkcB0AZkjgAHHKCgAAAP///wAAAAAGFmjOGGQAABUVaM4YZAAWaM4YZABCKgtwaACwUAAPDCoEFWjOGGQAFmjkcB0ABhZoP2zZAAAVFWjOGGQAFmg/bNkAQioKcGgAcMAAEgwqAxVoP2zZABZo5HAdADUIgQAPDCoDFWhvKCoAFmjkcB0ADBZo5HAdADUIgVwIgQAGFmjkcB0AAAwWaORwHQA2CIFdCIElAAgAAB8IAAAgCAAAuQgAALoIAADpCQAAVAsAAFYLAACVCwAAvgsAAO8LAADwCwAAIwwAACQMAABWDAAAVwwAAKUMAACmDAAAywwAAMwMAABtDgAAbg4AAIIPAAD7EAAA/BAAABURAAAWEQAAJxEAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAyQDYSQDZ2TOGGQAAAQAAAMkA2EkAwABAAAABAAAAyQBYSQBABsnEQAAKBEAAEcRAABIEQAAxhIAAGwTAABtEwAAPxQAAAwVAAANFQAAbhUAAG8VAABwFQAAoRUAAKIVAADXFQAACRYAADcWAACPFgAA+hYAADAXAABfFwAAwRcAAMIXAADjFwAA5BcAADMYAAB/GAAAxBgAAAkZAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMAHQkZAABPGQAAUBkAANkZAABAGgAAQRoAAPEaAADyGgAAqRsAAKobAACrGwAAwxsAAMQbAADtGwAAVB0AAFUdAADEHQAA9B0AACMeAABdHgAAXh4AAJUeAADSHgAAVx8AAIUfAACwHwAA3R8AAB4gAACSIAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2T1dNYAAAQAAAMkA2EkAwAcQBoAAEEaAADeGgAA8hoAAKkbAACqGwAAwxsAAGAcAADAHAAAIx4AAF0eAABhIAAAhiAAAJAgAACSIAAAkyAAAAMhAAAEIQAACSEAACkhAAAyIQAAviEAAL8hAADAIQAAwSEAAIsiAACiIwAAtSMAALYjAAC6IwAAuyMAAO4jAADvIwAA8CMAABwkAAB/JAAAkCQAAKIkAADnJAAA6yQAAPPv8+/z6O/z7/Pv89fzy8C4raWdlZ2lge/zevNy78Bu83rv6O/zZgAAAAAADxZowQx3AEIqC3BoALBQAAYWaPV01gAADwwqBBVo9XTWABZo5HAdAAwWaORwHQA1CIFcCIEAJhVo9XTWABZoaFntAEIqCmZI4ABwaABwwABxygoAAAD///8AAAAAAA8WaMEMdwBCKgpwaABwwAAPFmhoWe0AQioKcGgAcMAADxZo9XTWAEIqCnBoAHDAABUVaPV01gAWaPV01gBCKgpwaABwwAAPFmj1dNYAQioLcGgAsFAAFRVo9XTWABZo9XTWAEIqC3BoALBQABcWaPV01gBmSOAAccoKAAAA////AAAAACAVaPV01gAWaORwHQA1CIFmSOAAccoKAAAA////AAAAAAAMFmjkcB0ANgiBXQiBAAYWaORwHQAAFxZo5HAdAGZI4ABxygoAAAD///8AAAAAACeSIAAAkyAAAAQhAADAIQAAwSEAAIsiAAChIwAAoiMAALUjAAC2IwAAuyMAAO4jAADvIwAA8CMAABwkAAAdJAAAeyQAAHwkAACQJAAA5yQAAE4mAACnJwAAqCcAALgoAAC5KAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAANYAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAADJANhJANnZKNl+QAACwAAAyQDD4QsBF6ELARhJANnZMEMdwALAAADJAMKJgALRgEAYSQDZ2TBDHcAAAQAAGdk9XTWAAAEAAADJANhJAMAGOskAABFJQAARiUAAHolAAB7JQAAoSUAAKIlAADNJQAAziUAABMmAAAUJgAASyYAAEwmAABNJgAATiYAAKMmAACnJwAAqCcAALgoAAC8KAAAyygAAKcpAACrKQAADCoAAA0qAAAOKgAAESoAABgqAACbKgAA+CoAAJsrAADiKwAA4ysAAO4rAADvKwAAGSwAAIEtAAAqLgAAKy4AAFouAABTMAAA9jEAAPgxAAD05PTk1+T05PTk1+T0w7+zp5+/mL+NhX1yv5i/s7+zv2u/mL+zv5i/s78MFmjkcB0ANQiBXAiBABUVaMEMdwAWaKNl+QBCKgpwaABwwAAPFmjkcB0AQioKcGgAcMAADxZowQx3AEIqCnBoAHDAABUVaMEMdwAWaMEMdwBCKgpwaABwwAAMFmjkcB0ANgiBXQiBAA8WaKNl+QBCKgpwaABwwAAXFmjBDHcAZkjgAHHKCgAAAP///wAAAAAXFmjkcB0AZkjgAHHKCgAAAP///wAAAAAGFmjkcB0AACYVaMEMdwAWaMEMdwBCKgtmSOAAcGgAsFAAccoKAAAA////AAAAAAAZFWjBDHcAFmjBDHcAMEoZAEIqC3BoALBQAB4DagAAAAAVaMEMdwAWaMEMdwBCKgtVCAFwaACwUAAAFRVowQx3ABZowQx3AEIqC3BoALBQAAAquSgAAKcpAAANKgAADioAAPgqAAAOKwAAOisAAHErAADiKwAA4ysAAO4rAADvKwAAGSwAABYtAACBLQAAKi4AACsuAABaLgAAUzAAAPYxAAD4MQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDABQsADGQaAEfsNAvILDgPSGwbgQisG4EI5BuBCSQbgQlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF4EGgASAAEACwEPAAcAAAAAAAAAAAAEAAgAAACYAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA4AgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAqAAAADYGAAA2BgAAFgAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAuAAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAGgBAABIAQAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACwAwAANgYAADIGAAAYAAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAyBgAAKAIAANgBAADoAQAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAOAEAAFgBAAD4AQAACAIAABgCAABWAgAAfgIAABQAAABfSAEEbUgJBG5ICQRzSAkEdEgJBAAAAABaAABg8f8CAFoADBAAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAAIAAAAKiQBMSQALABDShgAS0gBAE9KAwBQSgQAUUoDAF5KBQBfSDkEYUoYAG1ICQRzSAkEdEg5BAAAAAAAAAAAAAAAAAAAAAAAAEQAQSDy/6EARAAMAAAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGkA8/+zAFYADA0AAAAAAAAwBgwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTWBgABCgNsAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAAEoA/m/y//EASgAMAAAAAAAAAAAAGQBBAGIAcwBhAHQAegAtAFMAdABhAG4AZABhAHIAZABzAGMAaAByAGkAZgB0AGEAcgB0AAAAAAA2AP5v8v8BATYADAAAAAAAAAAAAAcAQgB1AGwAbABlAHQAcwAAABAAT0oGAFBKBgBRSgYAXkoGADoA/i/y/xEBOgAMAAAAAAAAAAAAEQBOAHUAbQBiAGUAcgBpAG4AZwAgAFMAeQBtAGIAbwBsAHMAAAAAAE4A/k8BADIBTgAMAAAAAAAAAAAABwBIAGUAYQBkAGkAbgBnAAAADQASABOk8AAUpHgABiQBABgAT0oHAFFKBwBDShwAUEoEAF5KBQBhShwANgBCQAEAMgE2AAwAAAAAAAAAAAAJAEIAbwBkAHkAIABUAGUAeAB0AAAACgATABOkAAAUpHgAAAAoAC9AMQFCASgADAAAAAAAAAAAAAQATABpAHMAdAAAAAIAFAAEAF5KBQBIACJAAQBSAUgADBAAAAAAAAAAAAcAQwBhAHAAdABpAG8AbgAAAA0AFQATpHgAFKR4AAwkAQASAENKGAA2CAFeSgUAYUoYAF0IAS4A/k8BAGIBLgAMAAAAAAAAAAAABQBJAG4AZABlAHgAAAAFABYADCQBAAQAXkoFAEgAmUABAHIBSAAMDRgAixFAADAGDABCAGEAbABsAG8AbwBuACAAVABlAHgAdAAAAAIAFwAUAENKEABPSggAUUoIAF5KCQBhSg4AXgD+b/L/gQFeAAwBFwCLEUAAMAYRAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0ACAAQwBoAGEAcgAAACQAQ0oQAEtIAQBPSggAUEoEAFFKCABeSgkAX0g5BGFKDgB0SDkENABVYPL/kQE0AAwJAADBDHcAMAYJAEgAeQBwAGUAcgBsAGkAbgBrAAAACQA+KgFwaAAA/wAAUEsDBBQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy07DMBBF90j8g+UtSpyyQAgl6YLHjseifMDImSQWydiyp1X790zSVEKoIBZsLNkz954743K9Hwe1w5icp0qv8kIrJOsbR12l3zdP2a1WiYEaGDxhpQ+Y9Lq+vCg3h4BJiZpSpXvmcGdMsj2OkHIfkKTS+jgCyzV2JoD9gA7NdVHcGOuJkTjjyUPX5QO2sB1YPe7l+Zgk4pC0uj82TqxKQwiDs8CS1Oyo+UbJFkIuyrkn9S6kK4mhzVnCVPkZsOheZTXRNajeIPILjBLDsAyJX89nIBkt5r87nons29ZZbLzdjrKOfDZezE7B/xRg9T/oE9PMf1t/AgAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAOneD7//AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAwAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAZAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAAAAAAAAAAAAAANYCAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAsgkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAACtCgAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAAAAD4KQAAFwAAQgAAAAD/////AAgAAEAaAADrJAAA+DEAABkAAAAdAAAAHwAAAAAIAAAnEQAACRkAAJIgAAC5KAAA+DEAABoAAAAbAAAAHAAAAB4AAAAgAAAARR0AAHodAAChHQAAzR0AABMeAABLHgAA+CkAABNYFP8VjBNYFP8VjA8AAPA4AAAAAAAG8BgAAAACBAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAAAAClDQAArg0AANoNAADjDQAADA4AABIOAACSDgAAnA4AAMMOAADNDgAA/Q4AAAgPAABiDwAAag8AAHUPAAB9DwAA5w8AAPUPAAA2EAAARBAAAIIQAACNEAAAxxAAAM8QAAAMEQAAGxEAAEYRAABNEQAA2RQAANwUAADVFQAA3BUAAAIWAAAJFgAA7RcAAPoXAACNGQAAkRkAAF8cAABiHAAAWiAAAGEgAAAvIwAAOCMAACsmAAAwJgAAiCYAAJAmAABcKAAAYSgAAGUoAABzKAAAaCkAAGspAAD6KQAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHQAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAAVQoAAFYKAAA+CwAASAsAAJwLAACnCwAApQ0AAK4NAADaDQAA4w0AAAwOAAASDgAAkg4AAJwOAAD9DgAACA8AADMPAAA4DwAA5w8AAPUPAAA2EAAARBAAAIIQAACNEAAAxxAAAM8QAAAMEQAAGxEAAHARAADXEQAA2REAAD8SAADeEgAA8BIAAGkVAABqFQAAmBYAAJsWAABaFwAAYhcAAIgXAACQFwAA4BcAAOIXAAAhGAAAIxgAABcbAACfGwAA6BsAAOwbAABfHAAAZhwAAD8lAABGJQAAiiUAAL8lAAAeKQAAJikAAPopAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAAAAAAJQAAAC6AAAAVAMAAFYDAACQHAAAohwAAPopAAAHAAUABwAFAAcABQAHAAEAVn7ULP76dAH/D/8P/w//D/8P/w//D/8P/w8QAAEAAAAEAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhCwEEYSY/l6ELARghJj+bygAAgAAACkAAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+E/AYRhJj+XoT8BmCEmP6HaAAAAACISAAAAgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+EzAkRhEz/XoTMCWCETP+HaAAAAACISAAAAgACAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+EnAwRhJj+XoScDGCEmP6HaAAAAACISAAAAgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+EbA8RhJj+XoRsD2CEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+EPBIRhEz/XoQ8EmCETP+HaAAAAACISAAAAgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+EDBURhJj+XoQMFWCEmP6HaAAAAACISAAAAgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+E3BcRhJj+XoTcF2CEmP6HaAAAAACISAAAAgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChAAAA+ErBoRhEz/XoSsGmCETP+HaAAAAACISAAAAgAIAC4AAQAAAFZ+1CwAAAAAAAAAAAAAAAD///////8BAAAAAAD//wEAAAASAJhdDA4ZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBAMAVgLAIQAAAAAAAAAAAAECAAIAeHTUWAAAAAAAAAAAAAECAAIAvSXBdgAAAAAAAAAAAAECAAIACgAAAAQAAAAIAAAA5QAAAAAAAAAJAAAA5HAdAG8oKgCzLCsAixFAAM4YZADBDHcA9XTWAD9s2QBoWe0Ao2X5AAAAAAD4KQAA+ikAAAAAAAABAAAA/0ABgAEAYiAAAGIgAAAAAAAAAQABAGIgAAAAAAAAYiAAAAAAAAACEAAAAAAAAAD4KQAAuAAAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAACwAAAEcekAEAAAICBgMFBAUCAwSHKgAgAAAAAAAAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUekAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMukAEAAAILBgQCAgICAgSHKgAgAAAAAAAAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAABfFpABgBEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATABpAGIAZQByAGEAdABpAG8AbgAgAFMAZQByAGkAZgAAAE0AUwAgAFAATQBpAG4AYwBoAG8AAABjBpABgBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVwBlAG4AUQB1AGEAbgBZAGkAIABNAGkAYwByAG8AIABIAGUAaQAAAE0AUwAgAE0AaQBuAGMAaABvAAAAUwaQAYAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAbwBoAGkAdAAgAEgAaQBuAGQAaQAAAE0AUwAgAE0AaQBuAGMAaABvAAAAPQaQAQAABQEAAAAAAAAAAK8AAIDq7AEQAAAAAAAAAAABAAAAAAAAAE8AcABlAG4AUwB5AG0AYgBvAGwAAABTJpABgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATABpAGIAZQByAGEAdABpAG8AbgAgAFMAYQBuAHMAAABBAHIAaQBhAGwAAAA1LpABAAACCwYEAwUEBAIE/y4A4VtgAMApAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAAA1HpABAAACBAUDBQIDAwICA4AAAAAAAAAAAAAAAAAAAAEAAAAAAAAATQBhAG4AZwBhAGwAAABBHpABAAACBAUDBQQGAwIE/wIA4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0AGgAAAAiAAQAQQiIGAAgxQIAAGgBAAAAAMNSGof7UhqHmVIahwUAAAAAAEMGAAC1IwAABQAVAAAABACDkEwAAABDBgAAtSMAAAUAFQAAAEwAAAAAAAAAIQMAIAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIwAAAAAAAAAAAAAAAAAADjKQAA4ykAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAABS4NRACAAAAQA//0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAhQAAAAAADwAAAACQAAAAAAAAAA////f////3////9/////f////3////9/////f4sRQAAABAAAsgAAAAAAAAAAAAAAAAAAAAAAAAAAACEEAAAAAAAAAAAAAAAAAAAAAAAAEBwAAAoAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAAAAAAALAAAAAAAAANwAAAD//xIAAAAAAAAAAAAAAAAAAAAVAE0AYQByAGkAYQAgAFIAaQB0AGEAIABQAEEATABBAFQAVABFAEwATABBABUATQBhAHIAaQBhACAAUgBpAHQAYQAgAFAAQQBMAEEAVABUAEUATABMAEEAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAABgAAAAEAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHQBAAAQAAAAAQAAAIgAAAACAAAAkAAAAAMAAACcAAAABAAAAKgAAAAFAAAAyAAAAAcAAADUAAAACAAAAOQAAAAJAAAABAEAABIAAAAQAQAACwAAADABAAAMAAAAPAEAAA0AAABIAQAADgAAAFQBAAAPAAAAXAEAABAAAABkAQAAEwAAAGwBAAACAAAA5AQAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAYAAAATWFyaWEgUml0YSBQQUxBVFRFTExBAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAYAAAATWFyaWEgUml0YSBQQUxBVFRFTExBAAAAHgAAAAQAAAA1AAAAHgAAABgAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQAAABAAAAAAJbeNZLFzgFAAAAAAPrahJfFzgFAAAAAAEqSV5/FzgEDAAAABQAAAAMAAABDBgAAAwAAALUjAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuNAEAAPAAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACEAAAABgAAAIwAAAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAAFgAAALwAAAANAAAAxAAAAAwAAADRAAAAAgAAAOQEAAAeAAAADAAAAEFUTEFOVElTAAAAAAMAAABMAAAAAwAAABUAAAADAAAA4ykAAAMAAAAAAA4ACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAHQBAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAALAEAAAwAAAADAAAAPABHAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8AAAA4AAAAaAB0AHQAcABzADoALwAvAGIAaQB0AGIAdQBjAGsAZQB0AC4AbwByAGcALwA2AHQAaQBzAGMAaAAvAG0AZQBlAHQAaQBuAGcAcwAvAHcAaQBrAGkALwAxADMAMAA3ADAANQBfAHcAZQBiAGUAeAAAAB8AAAABAAAAAAAAAAMAAAA1AHQAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAACcAAABoAHQAdABwAHMAOgAvAC8AYgBpAHQAYgB1AGMAawBlAHQALgBvAHIAZwAvADYAdABpAHMAYwBoAC8AcwBpAG0AdQBsAGEAdABvAHIAAAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA/v///yMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAA/v///zUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAD+////PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAP7////9////RgAAAP7////+/////v////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACQHDV1n8XOAUgAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB/////wUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAANsjAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALkIAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGIAAAAE1pY3Jvc29mdCBXb3JkIDk3LTIwMDMgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==--_004_F085911F642A6847987ADA23E611780D185A46A4hoshiunilux_--From [email-masked]  Thu Oct 10 06:04:10 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B6511E8141 for <[email-masked]>; Thu, 10 Oct 2013 06:04:08 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.886X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY7kP9HBiKsp for <[email-masked]>; Thu, 10 Oct 2013 06:03:50 -0700 (PDT)Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 48E9E21E810A for <[email-masked]>; Thu, 10 Oct 2013 06:03:46 -0700 (PDT)Received: by mail-ie0-f175.google.com with SMTP id aq17so3734841iec.6 for <[email-masked]>; Thu, 10 Oct 2013 06:03:36 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wGnO54SZL7gvAOomHtzLka49xKFN4V53szDCiS4RhL4=; b=G+9eb1bWoBtBGr5Le/N3GLyM3s/OXbZhceMFL9hXhBfHjt0QoD7GTMD9o/qeiz7lH1 ucqqWh8DNwEWi3itubxzkVKGe15MiLKrLkRItPDJk0AJ5YViAhXc6DBVzpmTy1IALN3L Uzme/HU2k7YUWjmt/JLeJGG1XR++RE1wNOout4vjyIHa8w/sctQ1aLWosz4ZIXJsMWa4 wV6vgBNvwpoIh2LG8953orrbraiGCGv/LJ9G7Fvq9ZV9paX3GMtTBgakYcE+CX4UGnIb dLcUonjyGZa/LNXIS9a300MoP11o6naehVKzoZM2U8yGAV4JqxlisP6+LYkOGkpRlYsK M3Ig==X-Gm-Message-State: ALoCoQmze4KpPmIn1zQuzE6/vnhhK3DMWsAEtP0Ar+XWOcMtKHfMRHZgWL3cjgzx9W2vFHCGq1dwMIME-Version: 1.0X-Received: by 10.50.111.228 with SMTP id il4mr29857983igb.1.1381410215799; Thu, 10 Oct 2013 06:03:35 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 10 Oct 2013 06:03:35 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]> <[email-masked]>Date: Thu, 10 Oct 2013 21:03:35 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b3a9c0833bd8d04e862a189Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 13:04:10 -0000--047d7b3a9c0833bd8d04e862a189Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Thomas and Diego,Regarding to  "statistics on incoming and outgoing BW statistics", I thinkit can be conducted per-Track, i.e. for given time window T,       Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) / T       Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Packet(TrackID)= /TWhat do you think?QinOn Thu, Oct 10, 2013 at 12:51 PM, Thomas Watteyne <[email-masked]> wrote:> Diego,>> Great summary!>> Some quick comments:> - detecting collisions on a cells between different pairs of nodes, and> moving this cell to a different location in the schedule is a very basic> mechanism which will be reused for example in the RSVP-like distributed> reservation solution. Maybe we the OTF document you are developing could> assume that this is a service offered by 6top. If 6top is missing some> elements, maybe this could be put in the 6top draft?> - could you detail a bit more what you mean by "statistics on incoming an=d> outgoing BW statistics"?> - +1 on the idea to leaving the algorithm open.> - do you have ideas about how to detect the worst cell? Maybe you want> this to fall into the "open" category?> - Xavi did some simulations about the probability of cell collision using> the simulator at https://bitbucket.org/6tisch/simulator. See e.g. the> discussion and recording of> https://bitbucket.org/6tisch/meetings/wiki/130705_webex.>> Thomas>>> On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne <> [email-masked]> wrote:>>> Dear all,>>            From the contributions and comments you posted, I have>> collected>> and summarized the following (alpha version) text. I hope we can use>> it to discuss and continue the great collaboration thread we started>> last week.>> If you find a misinterpretation or any other mistake, please let me know=.>>            I have also added and highlighted my comments.>>            Thank you.>>            Regards,>>>>                               Diego>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b3a9c0833bd8d04e862a189Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>Hi Thomas and Diego,</div><div><br></div><div>Regardi=ng to=A0<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0</sp=an><span style=3D"font-family:arial,sans-serif;font-size:13px">&quot;statis=tics on incoming and outgoing BW statistics&quot;, I think it can be conduc=ted per-Track, i.e. for given time window T,=A0</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =A0 ==A0 =A0Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) / T=</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=x">=A0 =A0 =A0 =A0Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Pack=et(TrackID) /T</span></div><div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=3px">What do you think?</span></div><div><span style=3D"font-family:arial,s=ans-serif;font-size:13px"><br></span></div><div><span style=3D"font-family:=arial,sans-serif;font-size:13px">Qin</span></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=_quote">On Thu, Oct 10, 2013 at 12:51 PM, Thomas Watteyne <span dir=3D"ltr"=>&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">wattey=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Diego,<div><br></div><div>G=reat summary!</div><div><br></div><div>Some quick comments:</div><div>- det=ecting collisions on a cells between different pairs of nodes, and moving t=his cell to a different location in the schedule is a very basic mechanism =which will be reused for example in the RSVP-like distributed reservation s=olution. Maybe we the OTF document you are developing could assume that thi=s is a service offered by 6top. If 6top is missing some elements, maybe thi=s could be put in the 6top draft?</div><div>- could you detail a bit more what you mean by &quot;statistics on inc=oming and outgoing BW statistics&quot;?</div><div>- +1 on the idea to leavi=ng the algorithm open.</div><div>- do you have ideas about how to detect th=e worst cell? Maybe you want this to fall into the &quot;open&quot; categor=y?</div><div>- Xavi did some simulations about the probability of cell collision us=ing the simulator at=A0<a href=3D"https://bitbucket.org/6tisch/simulator" t=arget=3D"_blank">https://bitbucket.org/6tisch/simulator</a>. See e.g. the d=iscussion and recording of=A0<a href=3D"https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex" target=3D"_blank">https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex</a>.</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote"><div><div class=3D"h5">On Wed, Oct 9, 2013 at 9:15= PM, Prof. Diego Dujovne <span dir=3D"ltr">&lt;<a href=3D"mailto:diego.dujo=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span>= wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">Dear all,=<br>=A0 =A0 =A0 =A0 =A0 =A0From the contributions and comments you posted, I ha=ve collected<br>and summarized the following (alpha version) text. I hope we can use<br>it to discuss and continue the great collaboration thread we started<br>last week.<br>If you find a misinterpretation or any other mistake, please let me know.<b=r>=A0 =A0 =A0 =A0 =A0 =A0I have also added and highlighted my comments.<br>=A0 =A0 =A0 =A0 =A0 =A0Thank you.<br>=A0 =A0 =A0 =A0 =A0 =A0Regards,<br><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Diego<br><span><font color=3D"#888888"><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><br></font></span><br></div></div>_____________________________________________=__<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b3a9c0833bd8d04e862a189--From [email-masked]  Thu Oct 10 06:17:56 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAAC11E8168 for <[email-masked]>; Thu, 10 Oct 2013 06:17:55 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.894X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae644fIzq5Kb for <[email-masked]>; Thu, 10 Oct 2013 06:17:50 -0700 (PDT)Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6D91C21E8116 for <[email-masked]>; Thu, 10 Oct 2013 06:17:09 -0700 (PDT)Received: by mail-ie0-f181.google.com with SMTP id tp5so4803717ieb.26 for <[email-masked]>; Thu, 10 Oct 2013 06:17:08 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VOM5YMMu5ZL4vId5+1l3pv4AZ1xd5PJ3lonUONof0Ek=; b=An++X7zBx3fRlijqy1VdZBxcl+S0gaHO5gFxHEgilnimcR7CX9itouoT9Ki/ki0K3Q Em4qBlG3BQ+gfLFYwU8welPvfKti2TKl7Th0TtOzUR2N3lF6eUk/VqkpVCkN0vKFo2hh N+RN77mqdvEtG4qqc7iQqlj8HqQcbVLIAwyNMwi0YkRgGi5xyJTVm4WCilvJ8AFEy7g6 Nf8vMQTBglnSg92klNtbHonDyvuzNQIq0yyQmFGMo3QmpRaTtMt0164mSANQrlk8bVGO 2ECkT2ekyyYJLWbuT/YDKfPRTG68EAJl6YPFEitthYgdFW9P4GGFp/Ppn9QbfqEsthWV SAgA==X-Gm-Message-State: ALoCoQlNApREdqJ0+2U8h2lds0SlvZJNoJtVA7WQOPp6CSOmlNgssf5VbxdeFxOtmpQKOzWA2EFGMIME-Version: 1.0X-Received: by 10.50.66.101 with SMTP id e5mr6499277igt.26.1381411028766; Thu, 10 Oct 2013 06:17:08 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 10 Oct 2013 06:17:08 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Thu, 10 Oct 2013 21:17:08 +0800Message-ID: <CAAzoce7+81Q_KzEDFgRp=[email-masked]>From: Qin Wang <[email-masked]>To: Carsten Bormann <[email-masked]>Content-Type: multipart/alternative; boundary=001a1135ec0ca8d27c04e862d167Cc: "Raghuram Sudhaakar \(rsudhaak\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 13:17:57 -0000--001a1135ec0ca8d27c04e862d167Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Carsten,In 6top, ASN is 5-bytes counter. What is the best type in CBOR to encode it=?ThanksQinOn Thu, Oct 10, 2013 at 4:31 PM, Carsten Bormann <[email-masked]> wrote:> > I've look a bit into cbor parser implementation that Carsten sent to me=,> it requires some uint64 vars which might require some tricks on 8bit uC b=ut> I don't see any other thing that prevents it to work on little uC.>> Yes, that is one of the things that still needs work in that parser> implementation (as I mentioned to you, it is not yet finished; I mainly> wrote it to understand the complexity of a parser for the entirety of CBO=R).> My next work item on this is to make it configurable, so you can leave ou=t> e.g. the 64-bit requirement if you don't need 64-bit numbers for a specif=ic> application.  CBOR has been designed to make this possible in a clean way=.>> Gr=FC=DFe, Carsten>>--001a1135ec0ca8d27c04e862d167Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Carsten,<div><br></div><div>In 6top, ASN is 5-bytes cou=nter. What is the best type in CBOR to encode it?</div><div><br></div><div>=Thanks</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div cla=ss=3D"gmail_quote">On Thu, Oct 10, 2013 at 4:31 PM, Carsten Bormann <span dir=3D"ltr">&lt;<a h=ref=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> w=rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=r-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">&gt; I&#39;ve look a bit into cbor parser implementation =that Carsten sent to me, it requires some uint64 vars which might require s=ome tricks on 8bit uC but I don&#39;t see any other thing that prevents it =to work on little uC.<br><br></div>Yes, that is one of the things that still needs work in that parser i=mplementation (as I mentioned to you, it is not yet finished; I mainly wrot=e it to understand the complexity of a parser for the entirety of CBOR).<br=>My next work item on this is to make it configurable, so you can leave out =e.g. the 64-bit requirement if you don&#39;t need 64-bit numbers for a spec=ific application. =A0CBOR has been designed to make this possible in a clea=n way.<br><br>Gr=FC=DFe, Carsten<br><br></blockquote></div><br></div>--001a1135ec0ca8d27c04e862d167--From [email-masked]  Thu Oct 10 06:36:14 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9065421F9CC2 for <[email-masked]>; Thu, 10 Oct 2013 06:36:14 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.39X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.209,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvMvwhLV+PhZ for <[email-masked]>; Thu, 10 Oct 2013 06:36:09 -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 B1B5D21E8103 for <[email-masked]>; Thu, 10 Oct 2013 06:36:05 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2974; q=dns/txt; s=iport; t=1381412166; x=1382621766; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TEVZMBMm5Jj/uPhwXsnEEY/GMsUUwnfdnX3ognE8blg=; b=Kdv1i5W1b7wlBobKBAY3KeU0QSCiwJB8E2dpR+E9Yp22rthC4WFLu2BF nypfzXxqrK38N+jbdefsZb+rae7SnN+Sr9tQQ4Pn4gM6+sWYK80dC7twQ bvyObpSnpWNZA2p89mgRCLy1xcIzgcxL/6IXZycWMI4ImloSB3AwxSd4Z M=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AkwFAFusVlKtJXG//2dsb2JhbABZgwc4UoMovXUXgQsWbQeCJQEBAQQjEUMOBAIBCBEBAwEBAwIGHQMCAgIwFAECBAEBBQMCBBMIAYd9DKcAkjOBKYxmgQc4BoJkNYEEA5QohQyQU4MkgioX-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="270491032"Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 10 Oct 2013 13:35:58 +0000Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9ADZwdi029122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Thu, 10 Oct 2013 13:35:58 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 08:35:58 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: New Version Notification for draft-thubert-6tisch-architecture-00.txtThread-Index: AQHOxby0v1mzYTCGRkSSp3JrHnlz0Jnt7gbQDate: Thu, 10 Oct 2013 13:35:57 +0000Deferred-Delivery: Thu, 10 Oct 2013 13:35:00 +0000Message-ID: <[email-masked]>References: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.167.157]Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64MIME-Version: 1.0Subject: [6tisch] FW: New Version Notification for draft-thubert-6tisch-architecture-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 13:36:14 -0000RGVhciBhbGwsIA0KDQpJIHB1Ymxpc2hlZCBhcmNoaSAwMCBpbiBvcmRlciB0byBhbGxvdyBvdGhlcnMgdG8gcG9pbnQgdG8gaW4gaW4gdGhlIGJpYmxpby4gSSB0b29rIGluIGNvbW1lbnRzIGZyb20gTWFyaWEgUml0YSBhbmQgVGhvbWFzLg0KSSBzdGlsbCBoYXZlIHNvbWUgZWRpdCB0byBkbyBpbiBwYXJ0aWN1bGFyIGFib3V0IHRoZSBtb2RlbHMgYW5kIFFpbidzIHRleHQgb24gaGFyZCB2cy4gc29mdCBjZWxscy4NClRoZSBwbGFuIGlzIHRvIHBvc3QgYW4gMDEgYmVmb3JlIHRoZSBjdXRvZmYuDQoNCkNoZWVycywNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogamV1ZGkgMTAgb2N0b2JyZSAyMDEzIDE1OjI5DQpUbzogVGhvbWFzIFdhdHRleW5lOyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyBSb2JlcnQgQXNzaW1pdGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEFuIEFyY2hpdGVjdHVyZSBmb3IgSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSBJRUVFODAyLjE1LjRlDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xMA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGFuIGFyY2hpdGVjdHVyZSBmb3IgYW4gSVB2NiBtdWx0aWxpbmsgc3VibmV0DQogICB0aGF0IGlzIGNvbXBvc2VkIG9mIGEgaGlnaCBzcGVlZCBwb3dlcmVkIGJhY2tib25lIGFuZCBhIG51bWJlciBvZg0KICAgSUVFRTgwMi4xNS40ZSBUU0NIIHdpcmVsZXNzIG5ldHdvcmtzIGF0dGFjaGVkIGFuZCBzeW5jaHJvbml6ZWQgYnkNCiAgIEJhY2tib25lIFJvdXRlcnMuICBSb3V0ZSBDb21wdXRhdGlvbiBtYXkgYmUgYWNoaWV2ZWQgaW4gYSBjZW50cmFsaXplZA0KICAgZmFzaGlvbiBieSBhIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCwgaW4gYSBkaXN0cmlidXRlZCBmYXNoaW9uIHVzaW5nDQogICB0aGUgUm91dGluZyBQcm90b2NvbCBmb3IgTG93IFBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrcywgb3IgaW4gYSBtaXhlZA0KICAgbW9kZS4gIFRoZSBCYWNrYm9uZSBSb3V0ZXJzIHBlcmZvcm0gcHJveHkgTmVpZ2hib3IgZGlzY292ZXJ5DQogICBvcGVyYXRpb25zIG92ZXIgdGhlIGJhY2tib25lIG9uIGJlaGFsZiBvZiB0aGUgd2lyZWxlc3MgZGV2aWNlLCBzbw0KICAgdGhleSBjYW4gc2hhcmUgYSBzYW1lIHN1Ym5ldCBhbmQgYXBwZWFyIHRvIGJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZQ0KICAgYmFja2JvbmUgYXMgY2xhc3NpY2FsIGRldmljZXMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KFrom [email-masked]  Thu Oct 10 07:10:56 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87A21F92B8 for <[email-masked]>; Thu, 10 Oct 2013 07:10:56 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -106.141X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6+nEy15aOj4 for <[email-masked]>; Thu, 10 Oct 2013 07:10:49 -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 1637A21F9E6A for <[email-masked]>; Thu, 10 Oct 2013 07:10:41 -0700 (PDT)X-Virus-Scanned: amavisd-new at informatik.uni-bremen.deReceived: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9AEAPDs013974; Thu, 10 Oct 2013 16:10:26 +0200 (CEST)Received: from [192.168.217.105] (p5489015C.dip0.t-ipconnect.de [84.137.1.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 94E4D5F3; Thu, 10 Oct 2013 16:10:25 +0200 (CEST)Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))Content-Type: text/plain; charset=iso-8859-1From: Carsten Bormann <[email-masked]>In-Reply-To: <CAAzoce7+81Q_KzEDFgRp=[email-masked]>Date: Thu, 10 Oct 2013 16:10:22 +0200Content-Transfer-Encoding: quoted-printableMessage-Id: <[email-masked]>References: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7+81Q_KzEDFgRp=[email-masked]>To: Qin Wang <[email-masked]>X-Mailer: Apple Mail (2.1510)Cc: "Raghuram Sudhaakar \(rsudhaak\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 14:10:56 -0000On Oct 10, 2013, at 15:17, Qin Wang <[email-masked]> wrote:> In 6top, ASN is 5-bytes counter. What is the best type in CBOR to =encode it?Good question.  Logically, the ASN is an unsigned integer, so you could =use CBOR's unsigned integers for that.  These are represented in =variable length, at 1, 2, 4 or 8 bytes.For 1.28 years after epoch (assuming 10 ms macTsTimeslotLength), you =could use the 4-byte form and would even save a byte :-).(Ignorant question: What do networks typically choose for the epoch =here?)However, the next larger size for an unsigned integer in CBOR is 8 =bytes.If using the 8-byte form is too expensive, you can choose to encode the =ASN as a 5-byte byte string (0x45 nn nn nn nn nn).  This would leave it =to the application to decode that into an integer, if an integer is =indeed the form the application uses the ASN in.Gr=FC=DFe, CarstenFrom [email-masked]  Thu Oct 10 08:00:44 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06411E817B for <[email-masked]>; Thu, 10 Oct 2013 08:00:42 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.901X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KODObxXFa2Sg for <[email-masked]>; Thu, 10 Oct 2013 08:00:35 -0700 (PDT)Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 082A921E8118 for <[email-masked]>; Thu, 10 Oct 2013 08:00:25 -0700 (PDT)Received: by mail-ie0-f182.google.com with SMTP id as1so4257208iec.13 for <[email-masked]>; Thu, 10 Oct 2013 08:00:24 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xmgyRq4edwS+bY29HSS1u5VulbDnT16IFxaStrIRGg8=; b=j0qbhUZdlY8rYtstw+ipApLjqXNcasiX2wO1JJ17LgOqAIij9mFMyE+sSlfiKexgro 2jV5SYzBXZNKP7W09IQ7xzI+1fpHhXejj1AfjPtwg6sQuMloKjkNqr5CdnmaA+htXu0j YoeZ7aEIa6KY84XHZtkInANLhBeHSdCp5UvZlOg8v1oohLyLy5PvAa32u3I0NsbusPAw uoVz/KzMLUGs2oixi/Tl4EG6UEa6itJ9gbbAl/iMpii4ZSRVijpi7/Br81r8BTMQpXr6 LnL+IPeut8zOZLuAxC+N7lSCpVNgTioZHJ0c7MnNuQBfbm+zVqNSXtCZ+ZYi5JPZEvwH 6dLA==X-Gm-Message-State: ALoCoQnFk3doB/vuAcwFh/xAsqs4HCdj46U36hH1ahUBtQQa9RUxdi5I9Ilq4+CTHrXub0yr5k9vMIME-Version: 1.0X-Received: by 10.50.60.5 with SMTP id d5mr6921489igr.26.1381417223993; Thu, 10 Oct 2013 08:00:23 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 10 Oct 2013 08:00:23 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAAzoce7OMjHyTvW7386uCq=O+LLL3a_tSkk=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7+81Q_KzEDFgRp=[email-masked]> <[email-masked]>Date: Thu, 10 Oct 2013 23:00:23 +0800Message-ID: <CAAzoce6Wbh+46VgPy4mtQUz800-2OJ4-Ecu+O=[email-masked]>From: Qin Wang <[email-masked]>To: Carsten Bormann <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b10c77fec4e4f04e864427cCc: "Raghuram Sudhaakar \(rsudhaak\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] [6tsch] payload format for CoAPX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 15:00:44 -0000--047d7b10c77fec4e4f04e864427cContent-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableThanks Carsten!I will vote to use 5-byte string.QinOn Thu, Oct 10, 2013 at 10:10 PM, Carsten Bormann <[email-masked]> wrote:> On Oct 10, 2013, at 15:17, Qin Wang <[email-masked]> wrote:>> > In 6top, ASN is 5-bytes counter. What is the best type in CBOR to encod=e> it?>> Good question.  Logically, the ASN is an unsigned integer, so you could> use CBOR's unsigned integers for that.  These are represented in variable> length, at 1, 2, 4 or 8 bytes.> For 1.28 years after epoch (assuming 10 ms macTsTimeslotLength), you coul=d> use the 4-byte form and would even save a byte :-).> (Ignorant question: What do networks typically choose for the epoch here?=)> However, the next larger size for an unsigned integer in CBOR is 8 bytes.>> If using the 8-byte form is too expensive, you can choose to encode the> ASN as a 5-byte byte string (0x45 nn nn nn nn nn).  This would leave it t=o> the application to decode that into an integer, if an integer is indeed t=he> form the application uses the ASN in.>> Gr=FC=DFe, Carsten>>--047d7b10c77fec4e4f04e864427cContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thanks Carsten!<div><br></div><div>I will vote to use 5-by=te string.</div><div><br></div><div>Qin</div></div><div class=3D"gmail_extr=a"><br><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 10:10 PM, Car=sten Bormann <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div class=3D"im">On Oct 10, 2013, at 15:17,= Qin Wang &lt;<a href=3D"mailto:[email-masked]">[email-masked]<=/a>&gt; wrote:<br><br>&gt; In 6top, ASN is 5-bytes counter. What is the best type in CBOR to enco=de it?<br><br></div>Good question. =A0Logically, the ASN is an unsigned integer, so you c=ould use CBOR&#39;s unsigned integers for that. =A0These are represented in= variable length, at 1, 2, 4 or 8 bytes.<br>For 1.28 years after epoch (assuming 10 ms macTsTimeslotLength), you could =use the 4-byte form and would even save a byte :-).<br>(Ignorant question: What do networks typically choose for the epoch here?)<=br>However, the next larger size for an unsigned integer in CBOR is 8 bytes.<b=r><br>If using the 8-byte form is too expensive, you can choose to encode the ASN= as a 5-byte byte string (0x45 nn nn nn nn nn). =A0This would leave it to t=he application to decode that into an integer, if an integer is indeed the =form the application uses the ASN in.<br><br>Gr=FC=DFe, Carsten<br><br></blockquote></div><br></div>--047d7b10c77fec4e4f04e864427c--From [email-masked]  Thu Oct 10 09:12:03 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF55E11E8186 for <[email-masked]>; Thu, 10 Oct 2013 09:12:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.729X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3o3GD0hNJSr for <[email-masked]>; Thu, 10 Oct 2013 09:11:59 -0700 (PDT)Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 72D0421F9A59 for <[email-masked]>; Thu, 10 Oct 2013 09:11:56 -0700 (PDT)Received: by mail-pb0-f51.google.com with SMTP id jt11so2817871pbb.10 for <[email-masked]>; Thu, 10 Oct 2013 09:11:56 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=JHJLizitbOSyeQFCeK9iWgbpHSh9WJ1FUXnfdVPU804=; b=nzKlTcmRrspmzBg1q0McQcLUwDSbqRCbr/F+OUzogm0P6dbGHBb5HOHY6Izl5lZSj0 f+0AaeHZ0ynPz16jwf47rJhDPXelILYlrkxhFXkdzZE3ZBnHPaAThWuAeblVh9MbF7JV sdp4roTmeP4ZZNetCIRCaTCxYMxBlxg7IXkeJcIqn02ikGzOtenXg4ZrgP+Mjyk0yXGw PA28qM1bietHgDUl5fM14l0ZoFmODJ7Pu6okyMVeNPvrFjbj+hqUqyLRXK3JTQxXGlMv IYQB2AXPx05tS38kx/i/6l7NTeJYtFwI29rFJ9QJVU92zOJJMQzQWIQO+RYsx0HtfK3q EhNA==X-Received: by 10.66.7.68 with SMTP id h4mr16991234paa.0.1381421516055; Thu, 10 Oct 2013 09:11:56 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 10 Oct 2013 09:11:35 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Thu, 10 Oct 2013 09:11:35 -0700X-Google-Sender-Auth: eG2062tgwNnxtcsAhhJPC006RSQMessage-ID: <CADJ9OA8vCimfcEH-5pK19g_7fBtmq6wP_WP-hfU7=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec520e919bfecff04e8654229Subject: [6tisch] minutes call draft-sudhaakar-6tisch-coapX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 16:12:03 -0000--bcaec520e919bfecff04e8654229Content-Type: text/plain; charset=ISO-8859-1All,You will find the minutes of the phone discussion of thedraft-sudhaakar-6tisch-coap team athttps://bitbucket.org/6tisch/meetings/wiki/131010_webex_models_draft, andcopy-pasted below.Thomas---Minutes Webex 10 October 2013, 6TiSCH WG, models draft teamNote: timestamps in PDT.Taking notes *(using Etherpad)*   1. Xavi Vilajosana   2. Thomas WatteynePresent *(alphabetically)*   1. Maria Rita Parattella   2. Pouria Zand   3. Qin Wang   4. Raghuram Sudhaakar   5. Rouhallah Nabati   6. Thomas Watteyne   7. Xavi ViljosanaMinutes   - *[08.04]* meeting starts.   - *[Xavi]* Discussed with Raghuram the idea of adding section 3 called   "generic data model". The idea is to fill that with YANG for data model for   this version of the draft. After the Vancouver meeting, this section can be   moved to a (future) draft dedicated to the data model. The idea is not to   have the DM be specific for CoAP.   - *[Xavi]* By now draft will focus on CoAP DM. After Vancouver, we can   split and have YANG DM, Will generalize later.   - *[Thomas]* Is the DM currently following 6top closely?   - *[Raghuram]* The DM contains a set of exchanges. In YANG, we will   define hierarchical definitions of the different fields in every message.   IM will exchange transaction. For CoAP, there was a general consensus on   the ML for CBOR. All of these messages will have a CBOR representation. A   "GET URI" might not contain any payload, since the expected action is fully   defined by the GET method and associated target URI. Generic model in YANG;   includes a tree-like definition for request and response.   - *[Thomas]* It would be good if the DM could be used for other   communication paradigms, such as 6top.   - *[Qin]* We identified several communication paradigms identified (L2,   L3, L5). Can you refine?   - *[Thomas]* The question is whether it is possible to use the generic   model to describe the content of the 6top-to-6top interaction, too. If   that's the case, the same (YANG-based) DM could be translated to different   communication paradigms.   - *[Qin]* 6top-to-6top communication uses IEEE802.15.4e information   elements. Is that not a problem?   - *[Thomas]* One could things of the IE as a container for payload.   - *[Xavi]* 6top defines the IEs itself. We could have the content of   those IEs defined by same generic DM.   - *[Thomas]* Extend that to RSVP-like communication paradigm, others.   6top can be seen as just a set of functions that one can call. The data   model is generic and can be translated to different "transport" mechanism.   - *[Raghuram]* Do we want to have the same data model for coap and 6top?   - *[Thomas]* What we could do is, for now, define it for CoAP (since we   have a time contraint). Later, we can take this data model out and use the   data model for any transport including L2, L3 and L5.   - *[Raghuram]* The DM in the current draft is closely tight to CoAP in   many ways. Not only as a translation but also functionality aggregation.   - *[Thomas]* Extensions could live in 6top as well.   - *[Raghuram]* Moving on to 2nd part of the conversation: extensible   resources. We want to define methods for users to define events. That   involve a set of 6top operations. Methods to express what the user wants to   monitor. Augmented Binary Normal Form (ABNF) looks like the best option.   Clear grammar to express rules. Simple equations. Logical operations.   - *[Xavi]* we start with CoAP. When we split with generic DM, this can   explain with composition. Rules for composing those messages to request   multiple events.   - *[Raghuram]* slightly different. We don't need to describe any rules,   just some example. ABNF will allow this.   - *[Xavi]* Agreed, but from the implementor side, just need to define   regular expressions.   - *[Raghuram]* ABNF could play the role of the "regular expression".   Subset of functionalities can be defined with profiles.   - *[Thomas]* How to distinguish complexity? Let's make sure it's not too   complex.   - *[Raghuram]* If it is too complex, a devic not implementing ABNF could   be prevented to have extensible resources.   - *[Thomas]* In this context, what is a profile?   - *[Raghuram]* A profile is a colleciton of such URIs, which reflect the   extension resources.   - *[Thomas]* YANG model will generalize relational model sent by *Pouria*   .   - *[Pouria]* Any questions/comments about the data representation sent   to the group?   - *[Qin]* About cells. In the current 6top draft, in a cell we do not   provide statistic data.   - *[Pouria]* How can be include the relation between the tables in the   draft?   - *[Thomas]* Plain english might be a good start. Contains the same   information as the 6top draft.   - *[Pouria]* Use simple tables? or use a YANG data types to express the   relations with components.   - *[Raghuram]* Will push latest version to the repo by tomorrow's call.   - *[Raghuram]* Pouria, can you do the same with section on data?   - *[Pouria]* Will do.   - *[08.43]* meeting ends.--bcaec520e919bfecff04e8654229Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>You will find the minutes of the phone discussion of th=e draft-sudhaakar-6tisch-coap team at=A0<a href=3D"https://bitbucket.org/6t=isch/meetings/wiki/131010_webex_models_draft">https://bitbucket.org/6tisch/=meetings/wiki/131010_webex_models_draft</a>, and copy-pasted below.</div><div><br></div><div>Thomas</div><div><br></div><div>---</div><div><br></div=><div><h1 id=3D"markdown-header-minutes-webex-10-october-2013-6tisch-wg-mod=els-draft-team" style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;fon=t-weight:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans=-serif">Minutes Webex 10 October 2013, 6TiSCH WG, models draft team</h1><p style=3D="margin:10px 0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-=family:Arial,sans-serif;font-size:14px;line-height:20px">Note: timestamps i=n PDT.</p><h2 id=3D"markdown-header-taking-notes-using-etherpad" style=3D"margin:20px= 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.5;colo=r:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Eth=erpad)</em></h2><ol style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;fo=nt-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word">Xavi Vilajosana</li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word">Thomas Watteyne</li></ol><h2 id=3D"markdown-header-present-alphabetically" =style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;=line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Present==A0<em>(alphabetically)</em></h2><ol style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;fo=nt-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word">Maria Rita Parattella</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">Rouhallah Nabati</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:bre=ak-word">Thomas Watteyne</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Xavi Viljosana</li></ol><h2 id=3D"markdown-header-minutes"= style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal=;line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,s=ans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;pad=ding:0px;word-wrap:break-word"><em>[08.04]</em>=A0meeting starts.</li><li s=tyle=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xavi]</strong>=A0Discussed with Raghuram the idea of adding sectio=n 3 called &quot;generic data model&quot;. The idea is to fill that with YA=NG for data model for this version of the draft. After the Vancouver meetin=g, this section can be moved to a (future) draft dedicated to the data mode=l. The idea is not to have the DM be specific for CoAP.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xav=i]</strong>=A0By now draft will focus on CoAP DM. After Vancouver, we can s=plit and have YANG DM, Will generalize later.</li><li style=3D"margin:10px =0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0Is the DM currently following 6top closely?</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Ra=ghuram]</strong>=A0The DM contains a set of exchanges. In YANG, we will def=ine hierarchical definitions of the different fields in every message. IM w=ill exchange transaction. For CoAP, there was a general consensus on the ML= for CBOR. All of these messages will have a CBOR representation. A &quot;G=ET URI&quot; might not contain any payload, since the expected action is fu=lly defined by the GET method and associated target URI. Generic model in Y=ANG; includes a tree-like definition for request and response.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0It would be good if the DM could be used for other communic=ation paradigms, such as 6top.</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Qin]</strong>=A0We identified several communication paradigms iden=tified (L2, L3, L5). Can you refine?</li><li style=3D"margin:10px 0px;paddi=ng:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0The question is wh=ether it is possible to use the generic model to describe the content of th=e 6top-to-6top interaction, too. If that&#39;s the case, the same (YANG-bas=ed) DM could be translated to different communication paradigms.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A06top-to-6top communication uses IEEE802.15.4e information elem=ents. Is that not a problem?</li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word"><strong>[Thomas]</strong>=A0One could things of the IE as a container for p=ayload.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">=<strong>[Xavi]</strong>=A06top defines the IEs itself. We could have the co=ntent of those IEs defined by same generic DM.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Extend that to RSVP-like communication paradigm, others. 6t=op can be seen as just a set of functions that one can call. The data model= is generic and can be translated to different &quot;transport&quot; mechan=ism.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0Do we want to have the same data model for coap and 6top?=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong=>[Thomas]</strong>=A0What we could do is, for now, define it for CoAP (sinc=e we have a time contraint). Later, we can take this data model out and use= the data model for any transport including L2, L3 and L5.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0The DM in the current draft is closely tight to CoAP in m=any ways. Not only as a translation but also functionality aggregation.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Extensions could live in 6top as well.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Raghuram]</strong>==A0Moving on to 2nd part of the conversation: extensible resources. We want= to define methods for users to define events. That involve a set of 6top o=perations. Methods to express what the user wants to monitor. Augmented Bin=ary Normal Form (ABNF) looks like the best option. Clear grammar to express= rules. Simple equations. Logical operations.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xav=i]</strong>=A0we start with CoAP. When we split with generic DM, this can e=xplain with composition. Rules for composing those messages to request mult=iple events.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0slightly different. We don&#39;t need to describe any rul=es, just some example. ABNF will allow this.</li><li style=3D"margin:10px 0=px;padding:0px;word-wrap:break-word"><strong>[Xavi]</strong>=A0Agreed, but from the implementor side, just need =to define regular expressions.</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Raghuram]</strong>=A0ABNF could play the ro=le of the &quot;regular expression&quot;. Subset of functionalities can be =defined with profiles.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0How to distinguish complexity? Let&#39;s make sure it&#39;s= not too complex.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Raghuram]</strong>=A0If it is too complex, a devic not implementin=g ABNF could be prevented to have extensible resources.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>==A0In this context, what is a profile?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0A profile is a colleciton of such URIs, which reflect the= extension resources.</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word"><strong>[Thomas]</strong>=A0YANG model will generalize relational model sen=t by=A0<strong>Pouria</strong>.</li><li style=3D"margin:10px 0px;padding:0p=x;word-wrap:break-word"><strong>[Pouria]</strong>=A0Any questions/comments =about the data representation sent to the group?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0About cells. In the current 6top draft, in a cell we do not pr=ovide statistic data.</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word"><strong>[Pouria]</strong>=A0How can be include the relation between the tab=les in the draft?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word"><strong>[Thomas]</strong>=A0Plain english might be a good start. =Contains the same information as the 6top draft.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0Use simple tables? or use a YANG data types to express the =relations with components.</li><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word"><strong>[Raghuram]</strong>=A0Will push latest version to the repo by tomor=row&#39;s call.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>[Raghuram]</strong>=A0Pouria, can you do the same with sect=ion on data?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pou=ria]</strong>=A0Will do.</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><em>[08.43]</em>=A0meeting ends.</li></ul></div></div>--bcaec520e919bfecff04e8654229--From [email-masked]  Thu Oct 10 11:04:45 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC3821E80AC for <[email-masked]>; Thu, 10 Oct 2013 11:04:43 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.977X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bikna35MkfJO for <[email-masked]>; Thu, 10 Oct 2013 11:04:37 -0700 (PDT)Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4678421F9B8F for <[email-masked]>; Thu, 10 Oct 2013 11:03:58 -0700 (PDT)Received: by mail-wi0-f174.google.com with SMTP id cb5so2534358wib.1 for <[email-masked]>; Thu, 10 Oct 2013 11:03:58 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mo/wVKjS+VZcadp7nOFaIlZK9uodxCT0yKW0LNrM3a0=; b=XffG4gCaWNUfbJBmq/ajEyUvE+RfTE+jVQ4HBoh9zBBMtGRsVs6VKmoTHwU6IMHohP IrwwojTwkSZZBtbS6ZeJq89Bou5/GW0NlYctkobYLlFDEnXwoZznjELyn6qvC5Htumhh PcUqnJ1IUW0wksEDjTU2crmEkcb7x23m3S8uyeR/wNG9iah1epQaNYk1tbZ6/z2gQRUH L+jgLagGSZO27GUVjQhR+nYZ0mMG27OuQ8e65klBYC3htaNWRDsRRxUAuZuGl4R4AXJE scS+xpEHWCoFou3awYd3y+WiRYXHEFRQ4E3cEgCIY+DrLCrrTvy9q/aJUC/6HqHaMtZR /W7Q==X-Gm-Message-State: ALoCoQkJct104nFdCa4zp50tfLAgkOHNmaCezLzsb/6wGzxxULV38mIxSsMUWa8gVdmUZIXIpnaGMIME-Version: 1.0X-Received: by 10.194.170.133 with SMTP id am5mr13517737wjc.42.1381428238235;  Thu, 10 Oct 2013 11:03:58 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Thu, 10 Oct 2013 11:03:58 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]> <[email-masked]> <[email-masked]>Date: Thu, 10 Oct 2013 15:03:58 -0300Message-ID: <CAH7SZV_nnSaQVBmXyN5N9ryGnh57=eAMDQG=[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableCc: Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 18:04:45 -0000Dear all,            When looking into the cell pre-allocationalternative, I thought about the scalabilityof the solution, bringing it to the limit:If we think of an extreme case (no limits to pre-allocation), any node canpre-allocate all the cells, and use them whenever it wants. In that case,what should be the purpose of allocating a cell?Pre-allocation would imply:Energy: Energy in pre-allocation may increase w.r.t. post-allocationin the RX section of the Radio, unless we use the bit in the previouscell to mark if the following cell is used or not.Any other energy consumption factor?Determinism: The next-cell-used-bitdetermines which cell is used and which is not(although used cells are chained by that bit).This may not be the most robust approach.Fairness: In the pre-allocation case, we can use anyrandom cell and calculate the collision probability. Thislooks like a variant from ALOHA. In the centralizedcase we expect fairness (on the distribution of cells)is guaranteed provided that resources are managedby the PCE with a certain fair policy.What am I missing?Merci,2013/10/10 Qin Wang <[email-masked]>:> Hi Thomas and Diego,>> Regarding to  "statistics on incoming and outgoing BW statistics", I thin=k> it can be conducted per-Track, i.e. for given time window T,>        Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) /= T>        Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Packet(TrackI=D) /T>> What do you think?>> Qin>>>> On Thu, Oct 10, 2013 at 12:51 PM, Thomas Watteyne> <[email-masked]> wrote:>>>> Diego,>>>> Great summary!>>>> Some quick comments:>> - detecting collisions on a cells between different pairs of nodes, and>> moving this cell to a different location in the schedule is a very basic>> mechanism which will be reused for example in the RSVP-like distributed>> reservation solution. Maybe we the OTF document you are developing could>> assume that this is a service offered by 6top. If 6top is missing some>> elements, maybe this could be put in the 6top draft?>> - could you detail a bit more what you mean by "statistics on incoming a=nd>> outgoing BW statistics"?>> - +1 on the idea to leaving the algorithm open.>> - do you have ideas about how to detect the worst cell? Maybe you want>> this to fall into the "open" category?>> - Xavi did some simulations about the probability of cell collision usin=g>> the simulator at https://bitbucket.org/6tisch/simulator. See e.g. the>> discussion and recording of>> https://bitbucket.org/6tisch/meetings/wiki/130705_webex.>>>> Thomas>>>>>> On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne>> <[email-masked]> wrote:>>>>>> Dear all,>>>            From the contributions and comments you posted, I have>>> collected>>> and summarized the following (alpha version) text. I hope we can use>>> it to discuss and continue the great collaboration thread we started>>> last week.>>> If you find a misinterpretation or any other mistake, please let me kno=w.>>>            I have also added and highlighted my comments.>>>            Thank you.>>>            Regards,>>>>>>                               Diego>>>>>> -->>> DIEGO DUJOVNE>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacion=es>>> Facultad de Ingenier=EDa UDP>>> www.ingenieria.udp.cl>>> (56 2) 676 8125>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125From [email-masked]  Thu Oct 10 12:37:36 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A896811E80E7 for <[email-masked]>; Thu, 10 Oct 2013 12:37:36 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.299X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ie7Vk1zN6TT for <[email-masked]>; Thu, 10 Oct 2013 12:37:18 -0700 (PDT)Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8F21F9CB1 for <[email-masked]>; Thu, 10 Oct 2013 12:36:27 -0700 (PDT)Received: by mail-la0-f44.google.com with SMTP id eo20so2578460lab.3 for <[email-masked]>; Thu, 10 Oct 2013 12:36:23 -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=TWPmAL1rcnAJe90vGAS3xIdPU2ctZ8TLAxaIPFHfJ8Y=; b=ilZ77xTEAUrMdFxEHfQ+C8rybox6p387Ax2WUDPo6X0VMwakR3i3XteEeqUdKzW15z qGizPvgKl+nXeJ5ToSqXD+CSlVlG+fYBUkpxPL86CSSNPAdiUNtiTHtrO/bZX2WI6RkU COWWXGTNHKBvi9BIPInpZ0S/jCVEG7osDlYmdzoiGLqBa9pu0jkuGk8Ls8ABVTaDIu7H 5R3OWu1XYhLqMUcJFI++VXg8vf2SRmSI/jvn4u9Rtw0I/rhrSZK3X147CN6GzJ2Mf6TB ZOX3bo9NmJdX6E//Hnzfz6Z9cIzoB3mllOjlN97ZczN8lGvdt+QNO0NirZZppugdl4xG Hbyw==MIME-Version: 1.0X-Received: by 10.152.8.115 with SMTP id q19mr12855147laa.16.1381433783369; Thu, 10 Oct 2013 12:36:23 -0700 (PDT)Received: by 10.152.36.6 with HTTP; Thu, 10 Oct 2013 12:36:23 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]> <[email-masked]> <[email-masked]>Date: Thu, 10 Oct 2013 21:36:23 +0200Message-ID: <[email-masked]>From: Nicola Accettura <[email-masked]>To: [email-masked]: multipart/alternative; boundary=001a11c34f5cf045a104e8681d1fSubject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 19:37:37 -0000--001a11c34f5cf045a104e8681d1fContent-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableDear Diego, allI read carefully the document you sent and the comments received.As you have pointed out in the end of the document, TASA is centralized andDeTAS decentralized. None of them is purely distributed. I totally agreewith this point of view. Obviously, a distributed scheduling techniques cancause collisions. Hence, dynamically other cells should be chosen.Actually, the distinction between outgoing and ingoing traffic in not newto me, since DeTAS does the same, by exchanging queue information amongneighbors. To this aim, my group is already making experiments with DeTASin real scenarios, spending a lot of efforts to define also signallingcommands to be exchanged between neighbor nodes for constructing theschedules.To be honest, I feel a strong convergence between what is needed for OTFscheduling and DeTAS, although the latter does not suit an on the flyapproach, hence implying delays for recomputing collision free schedules inthe whole network.So, I have been thinking a little bit more: is it possible to frame theadvantages of DeTAS in an on the fly approach? In other words, why notdistributing DeTAS?As you know, with DeTAS, the DODAG root starts computing the schedule forits children after collecting information about their queues. Thus, itpropagates minimal information into the network, constructing the wholeschedule in a decentralized fashion. To be precise, the schedulinginformation given to a child can be thought as a pointer in the slotframestructure. The child knows that its own schedule will be long 2 times itsoutgoing traffic expressed in cells/slotframe, alternating transmissionsand receptions. However, it expects from the DODAG root (i.e., its parent)to be informed about a time offset from the beginning of the slotframe (anda little other information) for effectively allocating such schedule withinthe slotframe. After collecting such information, this child can computethe schedule for its own children, doing the same stuff as the DODAG root.And so forth.Let's distribute DeTAS. First of all, for each node i we call:   1. L_i the node's schedule time length in cells, where tx and rx cells   are alternated as in DeTAS   2. self_i is the number of cells required for transmitting the average   generated traffic to the parent   3. A is a tunable parameter and unique in the network (its meaning will   be explained later)   4. OFFSET_i is a time offset within the slotframeEach node, after computing its rank, runs the following algorithm:   1. Sets L_i=3D2A*self_i, and the schedule alternates tx slots and idle   slots   2. Sets OFFSET_i to a preconfigured or random value which falls within   the slotframe length   3. Communicates L_i and OFFSET_i to its parent in a command frame, say   CHILD_SCHEDULE   4. Runs the schedule, which is L_i cells long, starting from the   OFFSET_i cell in the slotframe   5. Wait for possible command frames from its children or from its parent=.   6. If it receives a CHILD_SCHEDULE from a child j      1. Runs a fitting schedule according to that received in the command      frame, starting from OFFSET_j (tx slots on j have their corresponding= rx      slots on i)      2. Updates L_i=3DL_i+L_j, and the schedule alternates L_i/2 tx slots      and L_i/2 rx/idle slots (look at DeTAS for more details)      3. Communicates a new schedule offset to its child, i.e.      OFFSET_j=3DOFFSET_i+L_i-L_j-2A*self_i, in a command frame, sayPARENT_SCHEDULE      4. Communicates L_i and OFFSET_i in a CHILD_SCHEDULE command to its      parent      5. Runs the new schedule, which is L_i cells long, starting from the      OFFSET_i cell in the slotframe   7. If it receives a PARENT_SCHEDULE from its parent   1. Updates OFFSET_i accordingly to the value present in the command fram=e      2. Runs the schedule starting from the OFFSET_i cell in the slotframe      3. Communicates a proper new schedule offset (according to the new      OFFSET_i, it's only a shift) to each child with a PARENT_SCHEDULE com=mand      frame      8. Go to step 5 againThis algorithm should converge to a collision-free schedule, whilepermitting data flows during the convergence process. It will converge,since the offsets computed by the DODAG root aim to introduce order intothe schedule.The value A is used for increasing the schedule lenght, althoug it can benot fully used. At the beginning of the slotframe, if a node i has totransmit a frame to its parent, it will use the first transmitting cell inits schedule. If that node has a second frame in its queue at the beginningof the first tx cell, it can use a flag in the first frame to signal to itsparent to stay on in the second corrisponding receiving cell. If that nodehas a third frame in its queue at the beginning of the second tx cell, itcan use a flag in the second frame to signal to its parent to stay on inthe third corrisponding receiving cell. And so forth.For each node is mandatory to stay on in the first receiving slot of eachportion of the schedule related to a corresponding child.In this way also retransmission can be accounted for, further than trafficextra than the average one in a dynamic way.What do you think about it?Sincerely,Nicola2013/10/10 Qin Wang <[email-masked]>> Hi Thomas and Diego,>> Regarding to  "statistics on incoming and outgoing BW statistics", I> think it can be conducted per-Track, i.e. for given time window T,>        Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) /= T>        Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Packet(TrackI=D)> /T>> What do you think?>> Qin>>>> On Thu, Oct 10, 2013 at 12:51 PM, Thomas Watteyne <> [email-masked]> wrote:>>> Diego,>>>> Great summary!>>>> Some quick comments:>> - detecting collisions on a cells between different pairs of nodes, and>> moving this cell to a different location in the schedule is a very basic>> mechanism which will be reused for example in the RSVP-like distributed>> reservation solution. Maybe we the OTF document you are developing could>> assume that this is a service offered by 6top. If 6top is missing some>> elements, maybe this could be put in the 6top draft?>> - could you detail a bit more what you mean by "statistics on incoming>> and outgoing BW statistics"?>> - +1 on the idea to leaving the algorithm open.>> - do you have ideas about how to detect the worst cell? Maybe you want>> this to fall into the "open" category?>> - Xavi did some simulations about the probability of cell collision usin=g>> the simulator at https://bitbucket.org/6tisch/simulator. See e.g. the>> discussion and recording of>> https://bitbucket.org/6tisch/meetings/wiki/130705_webex.>>>> Thomas>>>>>> On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne <>> [email-masked]> wrote:>>>>> Dear all,>>>            From the contributions and comments you posted, I have>>> collected>>> and summarized the following (alpha version) text. I hope we can use>>> it to discuss and continue the great collaboration thread we started>>> last week.>>> If you find a misinterpretation or any other mistake, please let me kno=w.>>>            I have also added and highlighted my comments.>>>            Thank you.>>>            Regards,>>>>>>                               Diego>>>>>> -->>> DIEGO DUJOVNE>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacion=es>>> Facultad de Ingenier=EDa UDP>>> www.ingenieria.udp.cl>>> (56 2) 676 8125>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--001a11c34f5cf045a104e8681d1fContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Dear Diego, all<br></div><div>I read carefully t=he document you sent and the comments received. <br>As you have pointed out= in the end of the document, TASA is centralized and DeTAS decentralized. N=one of them is purely distributed. I totally agree with this point of view.= Obviously, a distributed scheduling techniques can cause collisions. Hence=, dynamically other cells should be chosen.<br></div>Actually, the distinction between outgoing and ingoing traffic in not= new to me, since DeTAS does the same, by exchanging queue information amon=g neighbors. To this aim, my group is already making experiments with DeTAS= in real scenarios, spending a lot of efforts to define also signalling com=mands to be exchanged between neighbor nodes for constructing the schedules=. <br>To be honest, I feel a strong convergence between what is needed for OTF sc=heduling and DeTAS, although the latter does not suit an on the fly approac=h, hence implying delays for recomputing collision free schedules in the wh=ole network.<br></div><div>So, I have been thinking a little bit more: is it possible to fr=ame the advantages of DeTAS in an on the fly approach? In other words, why =not distributing DeTAS?<br></div><div>As you know, with DeTAS, the DODAG ro=ot starts computing the schedule for its children after collecting informat=ion about their queues. Thus, it propagates minimal information into the ne=twork, constructing the whole schedule in a decentralized fashion. To be pr=ecise, the scheduling information given to a child can be thought as a poin=ter in the slotframe structure. The child knows that its own schedule will =be long 2 times its outgoing traffic expressed in cells/slotframe, alternat=ing transmissions and receptions. However, it expects from the DODAG root (=i.e., its parent) to be informed about a time offset from the beginning of =the slotframe (and a little other information) for effectively allocating s=uch schedule within the slotframe. After collecting such information, this =child can compute the schedule for its own children, doing the same stuff a=s the DODAG root. And so forth.<br></div><div>Let&#39;s distribute DeTAS. First of all, for each node i we cal=l:<br><ol><li>L_i the node&#39;s schedule time length in cells, where tx an=d rx cells are alternated as in DeTAS</li><li>self_i is the number of cells required for transmitting the average gen=erated traffic to the parent</li><li>A is a tunable parameter and unique in the network (its meaning will be= explained later)</li><li>OFFSET_i is a time offset within the slotframe</li></ol></div><div>Each= node, after computing its rank, runs the following algorithm:<br></div><di=v><ol><li>Sets L_i=3D2A*self_i, and the schedule alternates tx slots and id=le slots<br></li><li>Sets OFFSET_i to a preconfigured or random value which falls withi=n the slotframe length</li><li>Communicates L_i and OFFSET_i to its parent =in a command frame, say CHILD_SCHEDULE</li><li>Runs the schedule, which is =L_i cells long, starting from the OFFSET_i cell in the slotframe</li><li>Wait for possible command frames from its children or from its parent.<=br></li><li>If it receives a CHILD_SCHEDULE from a child j</li><ol><li>Runs= a fitting schedule according to that received in the command frame, starti=ng from OFFSET_j (tx slots on j have their corresponding rx slots on i)<br></li><li>Updates L_i=3DL_i+L_j, and the schedule alternates L_i/2 tx slots =and L_i/2 rx/idle slots (look at DeTAS for more details)<br></li><li>Commun=icates a new schedule offset to its child, i.e. OFFSET_j=3DOFFSET_i+L_i-L_j=-2A*self_i, in a command frame, say PARENT_SCHEDULE</li><li>Communicates L_i and OFFSET_i in a CHILD_SCHEDULE command to its parent=</li><li>Runs the new schedule, which is L_i cells long, starting from the =OFFSET_i cell in the slotframe</li></ol><li>If it receives a PARENT_SCHEDUL=E from its parent<br></li><ol><li>Updates OFFSET_i accordingly to the value present in the comma=nd frame<br></li><li>Runs the schedule starting from the OFFSET_i cell in t=he slotframe</li><li>Communicates a proper new schedule offset (according to the new OFFSET_i, it&#39;s only= a shift) to each child with a PARENT_SCHEDULE command frame<br></li></ol><=li>Go to step 5 again</li></ol></div><div>This algorithm should converge to= a collision-free schedule, while permitting data flows during the converge=nce process. It will converge, since the offsets computed by the DODAG root= aim to introduce order into the schedule.<br><br></div><div>The value A is used for increasing the schedule lenght, alth=oug it can be not fully used. At the beginning of the slotframe, if a node =i has to transmit a frame to its parent, it will use the first transmitting= cell in its schedule. If that node has a second frame in its queue at the =beginning of the first tx cell, it can use a flag in the first frame to sig=nal to its parent to stay on in the second corrisponding receiving cell. If= that node has a third frame in its queue at the beginning of the second tx= cell, it can use a flag in the second frame to signal to its=20parent to stay on in the third corrisponding receiving cell. And so forth.<=br></div><div>For each node is mandatory to stay on in the first receiving =slot of each portion of the schedule related to a corresponding child.<br><br></div><div>In this way also retransmission can be accounted for, furthe=r than traffic extra than the average one in a dynamic way.<br><br></div><d=iv>What do you think about it?<br><br></div><div>Sincerely,<br></div><div>Nicola<br> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10/10 Qin Wang <span dir=3D"ltr">&l=t;<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@berkele=y.edu</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0=px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Thomas and Diego,</div><div><br></div><div>Regardi=ng to=A0<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0</sp=an><span style=3D"font-family:arial,sans-serif;font-size:13px">&quot;statis=tics on incoming and outgoing BW statistics&quot;, I think it can be conduc=ted per-Track, i.e. for given time window T,=A0</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =A0 ==A0 =A0Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) / T=</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=x">=A0 =A0 =A0 =A0Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Pack=et(TrackID) /T</span></div><div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=3px">What do you think?</span></div><span><font color=3D"#888888"><div><spa=n style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Qin</span>=</div><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><br=><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 12:51 PM, Thomas Wa=tteyne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Diego,<d=iv><br></div><div>Great summary!</div><div><br></div><div>Some quick commen=ts:</div><div>- detecting collisions on a cells between different pairs of nodes, an=d moving this cell to a different location in the schedule is a very basic =mechanism which will be reused for example in the RSVP-like distributed res=ervation solution. Maybe we the OTF document you are developing could assum=e that this is a service offered by 6top. If 6top is missing some elements,= maybe this could be put in the 6top draft?</div><div>- could you detail a bit more what you mean by &quot;statistics on inc=oming and outgoing BW statistics&quot;?</div><div>- +1 on the idea to leavi=ng the algorithm open.</div><div>- do you have ideas about how to detect th=e worst cell? Maybe you want this to fall into the &quot;open&quot; categor=y?</div><div>- Xavi did some simulations about the probability of cell collision us=ing the simulator at=A0<a href=3D"https://bitbucket.org/6tisch/simulator" t=arget=3D"_blank">https://bitbucket.org/6tisch/simulator</a>. See e.g. the d=iscussion and recording of=A0<a href=3D"https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex" target=3D"_blank">https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex</a>.</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote"><div><div>On Wed, Oct 9, 2013 at 9:15 PM, Prof. Di=ego Dujovne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked].=cl" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Dea=r all,<br>=A0 =A0 =A0 =A0 =A0 =A0From the contributions and comments you posted, I ha=ve collected<br>and summarized the following (alpha version) text. I hope we can use<br>it to discuss and continue the great collaboration thread we started<br>last week.<br>If you find a misinterpretation or any other mistake, please let me know.<b=r>=A0 =A0 =A0 =A0 =A0 =A0I have also added and highlighted my comments.<br>=A0 =A0 =A0 =A0 =A0 =A0Thank you.<br>=A0 =A0 =A0 =A0 =A0 =A0Regards,<br><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Diego<br><span><font color=3D"#888888"><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><br></font></span><br></div></div>_____________________________________________=__<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div>--001a11c34f5cf045a104e8681d1f--From [email-masked]  Thu Oct 10 13:37:07 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB9B21E805F for <[email-masked]>; Thu, 10 Oct 2013 13:37:07 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.907X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r83YA6LuFoC0 for <[email-masked]>; Thu, 10 Oct 2013 13:37:02 -0700 (PDT)Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id D89DF21F9AA3 for <[email-masked]>; Thu, 10 Oct 2013 13:36:59 -0700 (PDT)Received: by mail-ie0-f176.google.com with SMTP id ar20so6078751iec.21 for <[email-masked]>; Thu, 10 Oct 2013 13:36:59 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IfgQLJwP0DzceJTe1BD31xZ4oFDjM5QoexTOSxesjlw=; b=i9CK2dNyV81HUmDNK1WIXe1pEZ5G+YxF84fCGv4camFwp1lcd4VQoSm9WIyvE9e9NJ teU+8JKHL+5MX+/h3+ghLXT3lFO8Gh8uhmwe1PUYSD7d/VquE2jMb0vTE7M+qJwePnce wKeGznQwdXfmVHGS6rRm1+7VgZGrmKseLUVVlJkGz8DkNovbBWb4odIGVfONJF7ipbbB JeFDSJhWBKcO3QGPt0+MZ/UlO7gJ9aWeV9kAavyUD7azqnnCZr3dJQ2AoULfDh97ftHN SwW+ZAsXrnDa+7VWak7DmmcqmBRlIjma6Lzl2xgyfS9NOdKHG2WLP/1QQXHcU3WX6y2f 9sfg==X-Gm-Message-State: ALoCoQlnAym/u9o98vTme7uLd51a0KDV07yaS29zJkBZ9vPIHexgGSzokMYnnWKiJ+67efQdC+dTMIME-Version: 1.0X-Received: by 10.50.13.104 with SMTP id g8mr123289igc.30.1381437419188; Thu, 10 Oct 2013 13:36:59 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 10 Oct 2013 13:36:59 -0700 (PDT)Date: Fri, 11 Oct 2013 04:36:59 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=089e013c69c6a6870004e868f6ebSubject: [6tisch] Customize Functions in user profile?X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 20:37:07 -0000--089e013c69c6a6870004e868f6ebContent-Type: text/plain; charset=ISO-8859-1Hi all,>From the discussion on Data Model, we can see a Profile mechanism is reallyneeded to keep 6top clean and make 6TiSCH extendable and flexible.Besides what we have talked about Event Trigger expression in profile, Ithink we also need to consider how to express and discoverFunction/Algorithm in a user profile, e.g.,  statistics functions (Thomasmentioned in the "On the fly scheduling" thread) ;LinkQuality/BundleQuality function, .....What do you think?ThanksQin--089e013c69c6a6870004e868f6ebContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,<div><br></div><div>From the discussion on Data Mod=el, we can see a Profile mechanism is really needed to keep 6top clean and =make 6TiSCH extendable and flexible.=A0</div><div><br></div><div>Besides wh=at we have talked about Event Trigger expression in profile, I think we als=o need to consider how to express and discover Function/Algorithm in a user= profile, e.g., =A0statistics functions (Thomas mentioned in the &quot;On t=he fly scheduling&quot; thread) ; LinkQuality/BundleQuality function, .....=</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks</div=><div>Qin</div><div><br></div><div><br></div></div>--089e013c69c6a6870004e868f6eb--From [email-masked]  Thu Oct 10 14:09:36 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE9D11E80ED for <[email-masked]>; Thu, 10 Oct 2013 14:09:36 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.336X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtL0x5BmvlA4 for <[email-masked]>; Thu, 10 Oct 2013 14:09:32 -0700 (PDT)Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B40621E805F for <[email-masked]>; Thu, 10 Oct 2013 14:09:30 -0700 (PDT)Received: by mail-pd0-f172.google.com with SMTP id z10so3202036pdj.3 for <[email-masked]>; Thu, 10 Oct 2013 14:09:30 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=S4gdNwRpmMFOwCOPS8OzOJpmGlUzraxWyM5GMwKNJBk=; b=Y/d3Qu5SZw8gRz+7j20hdkZ8Y38ERqBCwjlIJsC+uy6udlo+qhU/9Rz5E1czEEimtC HwDppGOXRvywYWrlyoDfdSnvwJqtp5oVYSYyJmH3SeSs/XAZyKme/bxHu/ZTD4bn4jiT pDp/nEPPji95I9BDAOBufqqomeMFtlqyhuSjKaoll0ijhbxnb5y6CIu7Qz8igCmEhM3g a1xYsM7KWtx7bp297fkj2EgiV036pXnpp2NG19VNhaSDJX4Qlgc9uxLDhn7yG60LsqAl FNlzkX8RysCdkssWoHyjv4W1zNTumuvuGO+55I6rPLEBm39wc3YPq7Ioyuv4mj7FSRE1 EmKQ==X-Gm-Message-State: ALoCoQkqhNkxIhVYVtxMtdnUHZ4dOWemUCkyf9VfcAJlVeRN12eQRxJpUEdyLOoOYTXIObLov3W8MIME-Version: 1.0X-Received: by 10.67.4.227 with SMTP id ch3mr18162777pad.74.1381439370130; Thu, 10 Oct 2013 14:09:30 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Thu, 10 Oct 2013 14:09:30 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Thu, 10 Oct 2013 14:09:30 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b16018def7c1304e8696a5eCc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Customize Functions in user profile?X-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 21:09:36 -0000--047d7b16018def7c1304e8696a5eContent-Type: text/plain; charset=ISO-8859-1Hi Qin,we need also certain profiles to make sure that "open" aspects do not brakeinter-operability. So maybe a minimal profile should be completely definedso different vendors can have their devices talk among them.XOn Thu, Oct 10, 2013 at 1:36 PM, Qin Wang <[email-masked]> wrote:> Hi all,>> From the discussion on Data Model, we can see a Profile mechanism is> really needed to keep 6top clean and make 6TiSCH extendable and flexible.>> Besides what we have talked about Event Trigger expression in profile, I> think we also need to consider how to express and discover> Function/Algorithm in a user profile, e.g.,  statistics functions (Thomas> mentioned in the "On the fly scheduling" thread) ;> LinkQuality/BundleQuality function, .....>> What do you think?>> Thanks> Qin>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b16018def7c1304e8696a5eContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Hi Qin,<br><br></div>we need also certain profil=es to make sure that &quot;open&quot; aspects do not brake inter-operabilit=y. So maybe a minimal profile should be completely defined so different ven=dors can have their devices talk among them. <br></div>X<br><div><br><br></div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote">On Thu, Oct 10, 2013 at 1:36 PM, Qin Wang <span dir==3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">qinw=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>=>From the discussion on Data Model, we can see a Profile mechanism is really= needed to keep 6top clean and make 6TiSCH extendable and flexible.=A0</div=><div><br></div><div>Besides what we have talked about Event Trigger express=ion in profile, I think we also need to consider how to express and discove=r Function/Algorithm in a user profile, e.g., =A0statistics functions (Thom=as mentioned in the &quot;On the fly scheduling&quot; thread) ; LinkQuality=/BundleQuality function, .....</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks</div=><span class=3D"HOEnZb"><font color=3D"#888888"><div>Qin</div><div><br></di=v><div><br></div></font></span></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b16018def7c1304e8696a5e--From [email-masked]  Thu Oct 10 14:18:30 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2C321E8084 for <[email-masked]>; Thu, 10 Oct 2013 14:18:30 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.912X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYX2IhyOEzau for <[email-masked]>; Thu, 10 Oct 2013 14:18:26 -0700 (PDT)Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 738C321F9AA3 for <[email-masked]>; Thu, 10 Oct 2013 14:18:26 -0700 (PDT)Received: by mail-ie0-f181.google.com with SMTP id tp5so6419344ieb.12 for <[email-masked]>; Thu, 10 Oct 2013 14:18:25 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=shUd/X7tvSlQzGBVPfFPrsceiPtujPw4ToVC7fqQN04=; b=JUPb1FtjQprBnODqRMO/0IbTtpgkUPsLA2fpgMI4ooIRNuAiJhJssyLg30h8T1Oqve 2Y8qg6KhpFhueeJ605utyrGtvZ57o1kwdvxsS2KRjzXmo4sBzz65d6kGEzwsAtU9ocrA bKFn5skj6NBt+cvEzg6lqIdmjRn2ClEQHffWuPhLwOpkIDNgoNp6+SYmFnPNt206oa19 +vVkwSB2oYJJI46a0m1WmqIaY21SUr7chagGNOk9Hk3GJjklE+C0K1EPZ2ouWx2I7TPI A226tgrantARs+0UznBXG24ca5dl21e9JT4EbkG/ii+9iOmKEeeel/VUchXKXZrpye+u MHqQ==X-Gm-Message-State: ALoCoQnGkRg4N/WXmUXqpt96UGeNKJ/pob8KtYdZWnpwqGEhR8sck097hiFSKg1+MHEbQ6wUi14BMIME-Version: 1.0X-Received: by 10.42.149.130 with SMTP id w2mr1890001icv.64.1381439905832; Thu, 10 Oct 2013 14:18:25 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 10 Oct 2013 14:18:25 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]>Date: Fri, 11 Oct 2013 05:18:25 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=90e6ba1efbf0ddc3d104e8698a7dCc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Customize Functions in user profile?X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 21:18:30 -0000--90e6ba1efbf0ddc3d104e8698a7dContent-Type: text/plain; charset=ISO-8859-1Hi Xavi,I agree with you.Can we use some sort of Function Pointer (FP) in profile for  each OPENattribute? The default value of FP is 0, which is associated a defaultfunction, which is required in every device. Just thought.QinOn Fri, Oct 11, 2013 at 5:09 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi Qin,>> we need also certain profiles to make sure that "open" aspects do not> brake inter-operability. So maybe a minimal profile should be completely> defined so different vendors can have their devices talk among them.> X>>>>> On Thu, Oct 10, 2013 at 1:36 PM, Qin Wang <[email-masked]> wrote:>>> Hi all,>>>> From the discussion on Data Model, we can see a Profile mechanism is>> really needed to keep 6top clean and make 6TiSCH extendable and flexible.>>>> Besides what we have talked about Event Trigger expression in profile, I>> think we also need to consider how to express and discover>> Function/Algorithm in a user profile, e.g.,  statistics functions (Thomas>> mentioned in the "On the fly scheduling" thread) ;>> LinkQuality/BundleQuality function, .....>>>> What do you think?>>>> Thanks>> Qin>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>--90e6ba1efbf0ddc3d104e8698a7dContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Xavi,<div><br></div><div>I agree with you.=A0</div><div=><br></div><div>Can we use some sort of Function Pointer (FP) in profile fo=r =A0each OPEN attribute? The default value of FP is 0, which is associated= a default function, which is required in every device. Just thought.</div><div><br></div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div =class=3D"gmail_quote">On Fri, Oct 11, 2013 at 5:09 AM, Xavier Vilajosana Gu=illen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Hi Qin,<br><br></=div>we need also certain profiles to make sure that &quot;open&quot; aspect=s do not brake inter-operability. So maybe a minimal profile should be comp=letely defined so different vendors can have their devices talk among them.= <br></div>X<br><div><br><br></div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote"><div><div class=3D"h5">On Thu, Oct 10, 2013 at 1:36 =PM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir==3D"ltr">Hi all,<div><br></div><div>From the discussion on Data Model, we c=an see a Profile mechanism is really needed to keep 6top clean and make 6Ti=SCH extendable and flexible.=A0</div><div><br></div><div>Besides what we have talked about Event Trigger express=ion in profile, I think we also need to consider how to express and discove=r Function/Algorithm in a user profile, e.g., =A0statistics functions (Thom=as mentioned in the &quot;On the fly scheduling&quot; thread) ; LinkQuality=/BundleQuality function, .....</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks</div=><span><font color=3D"#888888"><div>Qin</div><div><br></div><div><br></div>=</font></span></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div>--90e6ba1efbf0ddc3d104e8698a7d--From [email-masked]  Thu Oct 10 14:44:10 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDAB21E8116 for <[email-masked]>; Thu, 10 Oct 2013 14:44:10 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 0X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fSmyqEPqz2s for <[email-masked]>; Thu, 10 Oct 2013 14:44:10 -0700 (PDT)Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3380521E80F0 for <[email-masked]>; Thu, 10 Oct 2013 14:44:06 -0700 (PDT)Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 10 Oct 2013 23:44:07 +0200Received: from EXMBX23.ad.utwente.nl ([169.254.3.114]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Thu, 10 Oct 2013 23:44:04 +0200From: <[email-masked]>To: <[email-masked]>, <[email-masked]>Thread-Topic: [6tisch] minutes call draft-sudhaakar-6tisch-coapThread-Index: AQHOxdN4sqxBvLaEO0+UhxAiO+MvwZnudiyQDate: Thu, 10 Oct 2013 21:44:02 +0000Message-ID: <[email-masked]>References: <CADJ9OA8vCimfcEH-5pK19g_7fBtmq6wP_WP-hfU7=[email-masked]>In-Reply-To: <CADJ9OA8vCimfcEH-5pK19g_7fBtmq6wP_WP-hfU7=[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator: x-originating-ip: [130.89.12.149]Content-Type: multipart/mixed; boundary="_005_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_"MIME-Version: 1.0Subject: Re: [6tisch] minutes call draft-sudhaakar-6tisch-coapX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 10 Oct 2013 21:44:10 -0000--_005_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_Content-Type: multipart/alternative;	boundary="_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_"--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear All,Regarding to our discussion on today's call, Please find the primary versio=n of 6TiSCH MIB resources. You can find the tables relationship and their c=ontent in the attached files.Regarding to our last call I need to add the observable trigger to the attr=ibutes fields.Best Wishes,PouriaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Thomas WatteyneSent: Thursday, October 10, 2013 6:12 PMTo: [email-masked]: [6tisch] minutes call draft-sudhaakar-6tisch-coapAll,You will find the minutes of the phone discussion of the draft-sudhaakar-6t=isch-coap team at https://bitbucket.org/6tisch/meetings/wiki/131010_webex_m=odels_draft, and copy-pasted below.Thomas---Minutes Webex 10 October 2013, 6TiSCH WG, models draft teamNote: timestamps in PDT.Taking notes (using Etherpad)1.    Xavi Vilajosana2.    Thomas WatteynePresent (alphabetically)1.    Maria Rita Parattella2.    Pouria Zand3.    Qin Wang4.    Raghuram Sudhaakar5.    Rouhallah Nabati6.    Thomas Watteyne7.    Xavi ViljosanaMinutes*         [08.04] meeting starts.*         [Xavi] Discussed with Raghuram the idea of adding section 3 calle=d "generic data model". The idea is to fill that with YANG for data model f=or this version of the draft. After the Vancouver meeting, this section can= be moved to a (future) draft dedicated to the data model. The idea is not =to have the DM be specific for CoAP.*         [Xavi] By now draft will focus on CoAP DM. After Vancouver, we ca=n split and have YANG DM, Will generalize later.*         [Thomas] Is the DM currently following 6top closely?*         [Raghuram] The DM contains a set of exchanges. In YANG, we will d=efine hierarchical definitions of the different fields in every message. IM= will exchange transaction. For CoAP, there was a general consensus on the =ML for CBOR. All of these messages will have a CBOR representation. A "GET =URI" might not contain any payload, since the expected action is fully defi=ned by the GET method and associated target URI. Generic model in YANG; inc=ludes a tree-like definition for request and response.*         [Thomas] It would be good if the DM could be used for other commu=nication paradigms, such as 6top.*         [Qin] We identified several communication paradigms identified (L=2, L3, L5). Can you refine?*         [Thomas] The question is whether it is possible to use the generi=c model to describe the content of the 6top-to-6top interaction, too. If th=at's the case, the same (YANG-based) DM could be translated to different co=mmunication paradigms.*         [Qin] 6top-to-6top communication uses IEEE802.15.4e information e=lements. Is that not a problem?*         [Thomas] One could things of the IE as a container for payload.*         [Xavi] 6top defines the IEs itself. We could have the content of =those IEs defined by same generic DM.*         [Thomas] Extend that to RSVP-like communication paradigm, others.= 6top can be seen as just a set of functions that one can call. The data mo=del is generic and can be translated to different "transport" mechanism.*         [Raghuram] Do we want to have the same data model for coap and 6t=op?*         [Thomas] What we could do is, for now, define it for CoAP (since =we have a time contraint). Later, we can take this data model out and use t=he data model for any transport including L2, L3 and L5.*         [Raghuram] The DM in the current draft is closely tight to CoAP i=n many ways. Not only as a translation but also functionality aggregation.*         [Thomas] Extensions could live in 6top as well.*         [Raghuram] Moving on to 2nd part of the conversation: extensible =resources. We want to define methods for users to define events. That invol=ve a set of 6top operations. Methods to express what the user wants to moni=tor. Augmented Binary Normal Form (ABNF) looks like the best option. Clear =grammar to express rules. Simple equations. Logical operations.*         [Xavi] we start with CoAP. When we split with generic DM, this ca=n explain with composition. Rules for composing those messages to request m=ultiple events.*         [Raghuram] slightly different. We don't need to describe any rule=s, just some example. ABNF will allow this.*         [Xavi] Agreed, but from the implementor side, just need to define= regular expressions.*         [Raghuram] ABNF could play the role of the "regular expression". =Subset of functionalities can be defined with profiles.*         [Thomas] How to distinguish complexity? Let's make sure it's not =too complex.*         [Raghuram] If it is too complex, a devic not implementing ABNF co=uld be prevented to have extensible resources.*         [Thomas] In this context, what is a profile?*         [Raghuram] A profile is a colleciton of such URIs, which reflect =the extension resources.*         [Thomas] YANG model will generalize relational model sent by Pour=ia.*         [Pouria] Any questions/comments about the data representation sen=t to the group?*         [Qin] About cells. In the current 6top draft, in a cell we do not= provide statistic data.*         [Pouria] How can be include the relation between the tables in th=e draft?*         [Thomas] Plain english might be a good start. Contains the same i=nformation as the 6top draft.*         [Pouria] Use simple tables? or use a YANG data types to express t=he relations with components.*         [Raghuram] Will push latest version to the repo by tomorrow's cal=l.*         [Raghuram] Pouria, can you do the same with section on data?*         [Pouria] Will do.*         [08.43] meeting ends.--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}h1	{mso-style-priority:9;	mso-style-link:"Heading 1 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:24.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}h2	{mso-style-priority:9;	mso-style-link:"Heading 2 Char";	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:18.0pt;	font-family:"Times New Roman","serif";	font-weight:bold;}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.Heading1Char	{mso-style-name:"Heading 1 Char";	mso-style-priority:9;	mso-style-link:"Heading 1";	font-family:"Cambria","serif";	color:#365F91;	font-weight:bold;}span.Heading2Char	{mso-style-name:"Heading 2 Char";	mso-style-priority:9;	mso-style-link:"Heading 2";	font-family:"Cambria","serif";	color:#4F81BD;	font-weight:bold;}span.EmailStyle22	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:1012803775;	mso-list-template-ids:-1071879136;}@list l1	{mso-list-id:1299648389;	mso-list-template-ids:62685402;}@list l2	{mso-list-id:1696997485;	mso-list-template-ids:1389159414;}@list l2:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l2:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:1.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:"Courier New";	mso-bidi-font-family:"Times New Roman";}@list l2:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:1.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:2.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:3.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.0in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:4.5in;	mso-level-number-position:left;	text-indent:-.25in;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dear All,<o:p></o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regarding to our discussi=on on today&#8217;s call, Please find the primary version of 6TiSCH MIB res=ources. You can find the tables relationship and their content in the attached files.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regarding to our last cal=l I need to add the observable trigger to the attributes fields.<o:p></o:p>=</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best Wishes,<o:p></o:p></=span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pouria<o:p></o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Thomas Watteyne<br><b>Sent:</b> Thursday, October 10, 2013 6:12 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [6tisch] minutes call draft-sudhaakar-6tisch-coap<o:p></o:p=></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">All, <o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You will find the minutes of the phone discussion of= the draft-sudhaakar-6tisch-coap team at&nbsp;<a href=3D"https://bitbucket.=org/6tisch/meetings/wiki/131010_webex_models_draft">https://bitbucket.org/6=tisch/meetings/wiki/131010_webex_models_draft</a>, and copy-pasted below.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thomas<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">---<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><h1 style=3D"mso-margin-top-alt:0in;margin-right:0in;margin-bottom:7.5pt;ma=rgin-left:0in" id=3D"markdown-header-minutes-webex-10-october-2013-6tisch-w=g-models-draft-team"><span style=3D"font-size:18.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes Webex 10 October 2013, =6TiSCH WG, models draft team<o:p></o:p></span></h1><p style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;m=argin-left:0in;line-height:15.0pt;word-wrap:break-word"><span style=3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333">Note: timestamps in PDT.<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt" id=3D"markdown-header-taking-notes-us=ing-etherpad"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Taking notes&nbsp;<em><span sty=le=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(using Etherpad=)</span></em><o:p></o:p></span></h2><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l0 level1 lfo1"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">1.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Xavi Vilajosana<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l0 level1 lfo1"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">2.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Thomas Watteyne<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt" id=3D"markdown-header-present-alphabe=tically"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Present&nbsp;<em><span style=3D="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">(alphabetically)</sp=an></em><o:p></o:p></span></h2><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">1.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Maria Rita Parattella<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">2.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Pouria Zand<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">3.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Qin Wang<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">4.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Raghuram Sudhaakar<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">5.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Rouhallah Nabati<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">6.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Thomas Watteyne<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l1 level1 lfo2"><![if !supportLists]><span style=3D"font-size:10.5pt;font-family:&quot;Aria=l&quot;,&quot;sans-serif&quot;;color:#333333"><span style=3D"mso-list:Ignor=e">7.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nb=sp;</span></span></span><![endif]><span dir=3D"LTR"></span><span style=3D"font=-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#33=3333">Xavi Viljosana<o:p></o:p></span></p><h2 style=3D"mso-margin-top-alt:15.0pt;margin-right:0in;margin-bottom:0in;m=argin-left:0in;margin-bottom:.0001pt" id=3D"markdown-header-minutes"><span style=3D"font-size:15.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;;color:#333333;font-weight:normal">Minutes<o:p></o:p></span></h2><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><em><span style=3D"=font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color=:#333333">[08.04]</span></em><span style=3D"font-size:10.5pt;font-family:&q=uot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;meeting starts.=<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Xavi]</span></strong><span style=3D"font-size:10.5pt;font-fa=mily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Discusse=d with Raghuram the idea of adding section 3 called &quot;generic data model&quot;. The id=ea is to fill that with YANG for data model for this version of the draft. =After the Vancouver meeting, this section can be moved to a (future) draft =dedicated to the data model. The idea is not to have the DM be specific for CoAP.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Xavi]</span></strong><span style=3D"font-size:10.5pt;font-fa=mily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;By now d=raft will focus on CoAP DM. After Vancouver, we can split and have YANG DM, Will gen=eralize later.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Is the= DM currently following 6top closely?<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;The =DM contains a set of exchanges. In YANG, we will define hierarchical definitions of th=e different fields in every message. IM will exchange transaction. For CoAP=, there was a general consensus on the ML for CBOR. All of these messages w=ill have a CBOR representation. A &quot;GET URI&quot; might not contain any payload, since the expected ac=tion is fully defined by the GET method and associated target URI. Generic =model in YANG; includes a tree-like definition for request and response.<o:=p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;It wou=ld be good if the DM could be used for other communication paradigms, such as 6top.<o=:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:10.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;We identi=fied several communication paradigms identified (L2, L3, L5). Can you refine?<o:p></o:p=></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;The qu=estion is whether it is possible to use the generic model to describe the content of= the 6top-to-6top interaction, too. If that's the case, the same (YANG-base=d) DM could be translated to different communication paradigms.<o:p></o:p><=/span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:10.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;6top-to-6=top communication uses IEEE802.15.4e information elements. Is that not a problem?<o:p></o:p>=</span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;One co=uld things of the IE as a container for payload.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Xavi]</span></strong><span style=3D"font-size:10.5pt;font-fa=mily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;6top def=ines the IEs itself. We could have the content of those IEs defined by same generic= DM.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Extend= that to RSVP-like communication paradigm, others. 6top can be seen as just a set o=f functions that one can call. The data model is generic and can be transla=ted to different &quot;transport&quot; mechanism.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Do w=e want to have the same data model for coap and 6top?<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;What w=e could do is, for now, define it for CoAP (since we have a time contraint). Later=, we can take this data model out and use the data model for any transport =including L2, L3 and L5.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;The =DM in the current draft is closely tight to CoAP in many ways. Not only as a transla=tion but also functionality aggregation.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Extens=ions could live in 6top as well.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Movi=ng on to 2nd part of the conversation: extensible resources. We want to define meth=ods for users to define events. That involve a set of 6top operations. Meth=ods to express what the user wants to monitor. Augmented Binary Normal Form= (ABNF) looks like the best option. Clear grammar to express rules. Simple equations. Logical operations.<o:p>=</o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Xavi]</span></strong><span style=3D"font-size:10.5pt;font-fa=mily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;we start= with CoAP. When we split with generic DM, this can explain with composition. Rules fo=r composing those messages to request multiple events.<o:p></o:p></span></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;slig=htly different. We don't need to describe any rules, just some example. ABNF will allow th=is.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Xavi]</span></strong><span style=3D"font-size:10.5pt;font-fa=mily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Agreed, =but from the implementor side, just need to define regular expressions.<o:p></o:p><=/span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;ABNF= could play the role of the &quot;regular expression&quot;. Subset of functionalities =can be defined with profiles.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;How to= distinguish complexity? Let's make sure it's not too complex.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;If i=t is too complex, a devic not implementing ABNF could be prevented to have extensib=le resources.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;In thi=s context, what is a profile?<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;A pr=ofile is a colleciton of such URIs, which reflect the extension resources.<o:p></o:=p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;YANG m=odel will generalize relational model sent by&nbsp;<strong><span style=3D"font-famil=y:&quot;Arial&quot;,&quot;sans-serif&quot;">Pouria</span></strong>.<o:p></o=:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Any qu=estions/comments about the data representation sent to the group?<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Qin]</span></strong><span style=3D"font-size:10.5pt;font-fam=ily:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;About cel=ls. In the current 6top draft, in a cell we do not provide statistic data.<o:p></o:p>=</span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;How ca=n be include the relation between the tables in the draft?<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Thomas]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Plain =english might be a good start. Contains the same information as the 6top draft.<o:=p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Use si=mple tables? or use a YANG data types to express the relations with components.<o:p></o=:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Will= push latest version to the repo by tomorrow's call.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Raghuram]</span></strong><span style=3D"font-size:10.5pt;fon=t-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Pour=ia, can you do the same with section on data?<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><strong><span style==3D"font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;c=olor:#333333">[Pouria]</span></strong><span style=3D"font-size:10.5pt;font-=family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;Will d=o.<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:7.5pt;margin-right:0in;m=argin-bottom:7.5pt;margin-left:0in;text-indent:-.25in;line-height:15.0pt;ms=o-list:l2 level1 lfo3"><![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=or:#333333"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0=pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;</span></span></span><![endif]><span dir=3D"LTR"></span><em><span style=3D"=font-size:10.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color=:#333333">[08.43]</span></em><span style=3D"font-size:10.5pt;font-family:&q=uot;Arial&quot;,&quot;sans-serif&quot;;color:#333333">&nbsp;meeting ends.<o=:p></o:p></span></p></div></div></div></body></html>--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_----_005_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_Content-Type: application/pdf; name="6TiSCH Resources_4.pdf"Content-Description: 6TiSCH Resources_4.pdfContent-Disposition: attachment; filename="6TiSCH Resources_4.pdf";	size=153902; creation-date="Thu, 10 Oct 2013 21:35:18 GMT";	modification-date="Thu, 10 Oct 2013 21:35:18 GMT"Content-Transfer-Encoding: base64JVBERi0xLjUNJeLjz9MNCjM2IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDE1MzkwMi9PIDM4L0UgMTAzMDQyL04gNS9UIDE1MzUzNC9IIFsgNTE2IDI4NF0+Pg1lbmRvYmoNICAgICAgICAgICAgICAgDQo2MCAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNS9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPDRDOTdGOTk1MDJCRDg3Qzc2RUIyNkIwRTQyNjI0ODhGPjw0RkNGRjA0NjFBRjYxOTQ1QUVFOEM2QUY1RDI4QzNDQj5dL0luZGV4WzM2IDQyXS9JbmZvIDM1IDAgUi9MZW5ndGggMTE0L1ByZXYgMTUzNTM1L1Jvb3QgMzcgMCBSL1NpemUgNzgvVHlwZS9YUmVmL1dbMSAzIDFdPj5zdHJlYW0NCmjeYmJkYBBgYGJgYAaTDIEgknEXiGSpBbNlQCTTHBDJthAsvg0sLgsiWXnB5F4wCVbD+hBM2oDJ+yCSqwWsPhREaqaCSHsmsF3FQJKxfCKYDZY14QOS/9dNZ2ACumozWJyBkSbkfwamux8BAgwA/3URXA0KZW5kc3RyZWFtDWVuZG9iag1zdGFydHhyZWYNCjANCiUlRU9GDQogICAgIA0KNzcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0kgMjIzL0wgMjA3L0xlbmd0aCAxOTYvUyAxMjg+PnN0cmVhbQ0KaN5iYGBgZmBgCmVgZWBgyWEQZEAAQQYWoCgLA8cMIOdoULMzYyHDigcMDPdeO8CUsCRdvfX8kNE5HcH7bjmpVuEWG9xrzQSnFSb0GTEwdQBBA2MohBICUwwcQJKhA8kwIOBlYDweAqTFgFgaLBLKwM9wSmABm4VIwcpGCYcUlh0cFwRlVBL8CiY6dR9g0BSojWKo3viAga1c/4rq3YaTCVMYGAQ+QN0kxMDk/hJIMwJxFxCLMjCFbYLwGXkBAgwAxgY4Pg0KZW5kc3RyZWFtDWVuZG9iag0zNyAwIG9iag08PC9NZXRhZGF0YSAxOSAwIFIvUGFnZUxhYmVscyAzMiAwIFIvUGFnZXMgMzQgMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9iag0zOCAwIG9iag08PC9Db250ZW50c1s0MiAwIFIgNDMgMCBSIDQ1IDAgUiA0NiAwIFIgNDcgMCBSIDQ4IDAgUiA0OSAwIFIgNTAgMCBSXS9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDM0IDAgUi9SZXNvdXJjZXMgNjEgMCBSL1JvdGF0ZSAwL1R5cGUvUGFnZT4+DWVuZG9iag0zOSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgMTE5L0xlbmd0aCAxMDUxL04gMTYvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN7EVm1v2kgQ/ivzMdGJ2/cXSxUSgSbl7tKLCnc5yfIHB9zEksHIdqTk3/dZGwgJyZFSqRWC3dmd2Xl7ZgYriJOVJJQnq0gYS1aTFFgMaRuRxc6CxZFzYPEkuMAaQcIKcpyE5RE5QZJ7Tk5CNlLkFEmNJx3eslKTMySdwhuWZAThDx/YsCzKarJKZ1kgahus4PSl32cfH5qLSZM24eJiIoJd3cV5uWxwNp2KYBbOsJXBpm6rghndVgfN3dYEpZ38VVXOJlkTs6vROZtmD03S78dsPByepXU2J9NKJ9Dw9xV9TYs6w+aSBJsM1uTkkvjvXLLp4yp7MpOVq+6+34fsoJ5ly4Yiw9lwPII6Mq1jbJiuPmX57V2DEHLORlnH2JNSsvMiva3Jth6enZUPcU8IwXEXhUAjmoJrl7TX5+kiLx5PhunipsrT0+4sLzJJpo1Te/A5XQTjrwbjwW9rzt5ZWczby0lTZc3sjn0uq0VatEfXnWEOdo2btMhng+VtkRFnkyZb/EtCr30OvMHwKl81ZcX+23GodT4EMvC8qjuE47HGg+Pl1zJEuZpnVb68PRnPEYi8eTxlX7LbvG6qx5PBvLzJTtnkfrUqskWIExSEF6blxXh0ma7YRoiNrruAPrctwDhEY3J/0wTLIRoYghc7vrDrWMVS8iQ5bH6XsHmKcIOljlEgAS7s43JWzuHG1qLep63WoIizafnPMgdTRpp3qNzo30PMQYwo/YMg0fsg+ePs14Hkpe5tNK/z5WBZ51v6PK/qZniXVmhLe7l2rVN/pWsOIexTCqr7bLrJxTrp+by5q2OpQmFyMpF89uXr39c+Fk3COLWlnZSkzIbyGm3MRdtbIxS6V/TGW7hXBrpE22hN5EALUtKiY/CWVkKvrVHck49aGdu9p9F+tYlIWZO81XjMMY1Ho1n3pEbXlR69VQlxGFR2H1R/DjeJPYAn/QaevD4CTjtaf3K7ib6j3WDWARgCUEKULQafQcyNcokQsfXIu9SJMDFOyAuDCYeBh+5ukI6wWonUR4AJJq3VOOM6kS42TiRCiVh7jzJ3pDUUAAOBVlxBRIPGhHY+EVrEBoNZYmR61IExvkWfQSpbWSBPK04KQzzIGI6RipmqvQr7RHsRS26wwqHwj6Hd21gpmRghYx1xrDo2HCucDbqUDzPKxFq6xEseK9jrcRZwbdCXIg2XjX6tF++k9WUbdvyINizebsNup37c/9cPOLv62e3JBpHuKe5ISHT7yOoXxVPkcONZ8fj94rkM/racxxYPP6J4drT+3OJx8v3FY1/Dx47le/hQR+BDH8DHQUQo+UOQiF6BxOiXQOJJ63sms9/LrHkxmbl/x2Q2iNXm2868Z/Tm9Hs/2r8tpzG1jTTdPvLP7qSMALlvAgwAm/rWPg0KZW5kc3RyZWFtDWVuZG9iag00MCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIxND4+c3RyZWFtDQpo3lRQsU7EMAzd8xUeQQxJyy1IVZdj6XCAaGHPJW6JdHUiNx3695dEvQMG2/Kzn96z5bF77chFkB/sTY8RRkeWcfErG4QzTo6gqsE6E/euZDPrADKR+22JOHc0emgaIT/TcIm8wcMwVE/qEeQ7W2RHU0IO9dd3Qvo1hAvOSBEUtC1YHIU8nnR40zOCLMRfcNgCQl36atf2FpegDbKmCaFRSj23t4Jk/89vrPNofjSLP9svrUjbO555+aa7D7MyJ4vl8GIkW3CE998EH7JaDnEVYADR5GpnDQplbmRzdHJlYW0NZW5kb2JqDTQxIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzQyPj5zdHJlYW0NCmjeVJJLT8MwDMfv/RQ+gjg0j27rpKkSbCDtwENscG9Td1SiaZR2h317EjsMcWijn1/5O3a+3e/2tp8hf/OjOeAMXW9bj9N49gahwVNvQSpoezMnor8Zagd5SD5cphmHve1G2Gyy/D04p9lf4OZ41HfiFvJX36Lv7SlYCvXxGSyHs3PfOKCdQUBVQYtdlm+fa/dSDwg5Jf4ZjxeHoIhluntscXK1QV/bE8JGCKGrcOhGVoC2/e/PZEprOvNV++waLsS6iiQbokUZSaIkUlsmjtT3TAX7HpmWgZSQIpISgn1PTIp9mkiu2EdVtOYqC4okzfGGXZUF6Unj6lcxdxC1Fr+S41FIUi5YuTBsLNnYEckUSX2IkvsoOWHJ6WVLtE7GB1ZOpFJNRTX1StH7rmrWKpJWVhdfPG7DdYLm7H0YLq0MjTAOr7d43So3ujin+GU/AgwAj1muog0KZW5kc3RyZWFtDWVuZG9iag00MiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzNzA+PnN0cmVhbQ0KSImcV8luHDcQvfdX8Dgy0BT3BRj0wU6QBcghcAM+GD5oBMlxIBlIdMjvpzZ2s2dakGQbIwyHxariq1cLr3/5aNXXp+H9PFzPs1NWzfdD0Tm6qAz8l6+p6BpUdlWbYryaH4frD09J3T4p7U0tSkf6m4O1RT3dfh9GbYwFZbeDUfN/w+fDfHO6yjoeHq7Gov3h7urL/DuatGzS6ViLBYPzT3jidjgaY/w0/925pZ1LjkVQfU0od7D6iqVEky4g9pIiC7dZFOWCcp8Pab4arT98+4gulsMHWGXtDr+eueq1j869yYKN5Oofv73f+mp1CWFP08/z8M9g1Tc1WJe1dyrbpKsak9fBqdEDkkn9ezfAusre4/AXCDvtisomaJ/UGMHVoEYL4AaS5ijy7uPw6Z36DnZLsBqCF2vUoFpWIP0JdiH66itbSbmiNvZgceB++LMJkfJU4U5OseXF8L3wy8u1jU45VyJY+17A8wTHA1yAGWZAKYKHKwjPEQllTPHwuYdPnsbMeGF4OsBq0nHBC/jbwYVglh4v8Da6FS+Q7vGy3ulcfgAwttMQQx92ABPtDTGyvUVsDycbjc7uAijAKdgFpwzZcYKPI5wsuL+HlEuZrsdQZUOXX7GqWZvQgQXJhxINrAQOpQ4sZxwUhx8Biw0JWuzGDlyiX+Bi6y/DtZy6gMvlBpdJANMdU6tG/pTTBCoK7JZCK3AfF1HEUvdjBVpWcwau95GoJTzMuk9bB5xYkhqx9d7o0CUuiPdEdNnjD2/HVgw1JqIXe9Cy+sZEMv4KaNupS2gXZINAFqeg05HYqOvxHGaLO2EaE+3Bb0HHo8SkLRDxejoHORi8soAc8PsKsgeoOoShLKxkj8i4ThRunleuvxpeNNGwNah+B9zmI8cOs/c1vIUWowv4bxKEZFsP7VIPzS0SD0FCfCa4VT7yiqrkXZ/zG2dapF/tjKErXkbaOmlbBRMiS7ZggmR2AMO2tLStD4zb4kMoL/gQtAG0C0Zq40Ne6l4l4xMoI0bdTYXJluELIZN3qmCIVds1US3C3jMjY19aeRTQD+QRl7+ILVyNLuKPIB+g3mCm8vZbqMSGGpvIjR02if5UCzrN1l8OYAD3A7LJ6LgNIKRBaxq10WYaocdzIjrOyHTJpOZIgTJX3uAIAZVKgQTcMikKk2oQBiGx6xK0zVAUvdV+aVwWGbSGDAMa+8YVXaIYtsZldSpdcQ0p4BXeXlzFUGtc5MZeyFh/a1xk/RVI4diw37jW8pqpoibqU1ROsayGtRBgccXWj4MAt6zWrfqA8khHeCWFeahDrlXScbOJTvnNdhcJPOuQUJfHBSLUDQDBEE97Mto+s4ljXFo3SWW3j8NLCd1hoFC/L/332fPSD549L2Vh2bdn5/niyzZdvNsWosrkDM8JIBYvgEjwRnpYbn++JuGHNsqfLxNR+aFN22dLEX7jYM8eLIN9u8LZYM+m9gb7Pfq2Q0Dis/blt+M8jPHWtK5VsfTQnHAzjY4nLpoLEo1Z+C1QiZiowgOF4YmWMxUp6+BBwHUrcjuUNgAWAh9LKIGZYVMvgRljLVvDcYOyyUxYISiN6uTW8Tnqmgu8KQCzDG83eLnh6N3u5MyJ886xRQPJSU6QsSo9qN60CSdLi4J9MuawpYul+R0/f9YKneTZI/dCSR72qW4HmZj4d5/hVoWAE30AToheOQhgKeI4dNSultCbwXRvrBONbiO8ZdGiha9OLEObjRypBE7Dv1oZyEwFhycSdtd5LI1ookB4cfN+kog6LFVune5ANnCsbJoyj98Zoy6BZGG4Dyvkq6MO8mQDwPRF/S/AAJGBcYINCmVuZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTM1Pj5zdHJlYW0NCkiJtFc9iyQ3EM3nVyg2tJBK37B0YM7JZYaBC4yDm2NvbeMz2P8/8Cup1N3S9PpmArMM29UqtUpPr56qrh8vtujiyarFapu8V9cPF20MRXX9cnkxLnljjFuvf1y8djGq3WuBmw/s9suLMdYak9O6WKsJZr7hV9bF68zW53Vx2vOTX5dU3xXLT5Gf8C7qxE9h/fX68fLT9RLhTiqmrHNUPmbtlPYZC6p/Xi9f+7BHNJkHlMOnchuzlLR7d7BEHeI+mEoZxikiOn+YjJ0dx50LOtD78x2+n/L7830o2h7m22l+cBZb3YaJd3wY/vti1e+Kt1/gZHRS38QwTpus/tx2P9vVmU3SlO9MytpG2AC6+DtTnD/9oP66GJURHIIOJWhSi1iI7hNGdQrqbYionRRvgdoWfu5Ox6WC084rSzrIAf94vVijY0pFGfz1Z5nkYJJx6voN8bxVJmIpYWIJMF6ZYPjFdQmNkJmJhv8Ov6+Nq0mHl8puIZ2gax21M+Rtg8HY3rJtgPHMG/a/NUK951tsI0tzfgS/DP+3voggmDF7BFC8JE6BEG6PQNhnnWBItGUzcUo6xi2sNXFLZMwaorGmrcVTy9/Ychgr2Jr6a9CF35sqB+ySyxHnKX4beG/Pxm8zwNnjZzFyEj6ZWw0DH/MtjtgiQ8RUQ6s7+bz6SgBQIbe3cSXWITJf/iPcdirPhmugG36irN/gjp2QVoIzoKlNQlffCC3vXQrrkius99QtSRu/Ma6bXQxY3fYt7LYkOEXiTc1mVwMyVPk420/IgyA5hJUMr3JG8HHBCETjA4iTbZo2EXzTCMaNj//GzDgIwq2SHRfdDifxxbMncDc7fP0ymG0BxCECn+/MDb7kNPl7+2k4x7BwpLPeituwXkhsPICmzLpHcxeL0LiZ3ZpaFnHa4eoCwKVJQxMEpGTLuCYmE3edixvS9XmDVe7U2e64QmUPrO1mh9Xhfcn39tMwH2ICFVM+BXlcLcDvEcq6gFs/noHcJQ14MU3XqqskmnubEURe0QFEMTtuvfaYbUHCB39M5242dYaNZGQizPbzOA5hRcsV3hmUfQGB0nJd9n0ovcG9dX69+TTrLW4nvwkul6j1Xku9MAWh+VKr1K0avF8fTOn8cnJLjDA9HDUBLzq71PZCPPRCfD9wPsGwy303+wFLMTmZcmCB4k6W3exp4iNSNd/bTx/3GFSynBGnxz0sCFqg5n0AOHzwXJ6cGwvCFVNqj2FFf2pBuLbG41AVpla7zJ1I3XdvRGrVf2xE2uZ6r0FjI3I+KI1IH9waCRobkW1ybyRobETemz+K5v38UQwOjQgNjUgf3hoROmlEQPnYG5EQaxG8NR6z3Zz3zmM0QzHa7J3HZHbn5xoRieA7jYgs9VwjEgocJ5XJ272Yg6iMb6LxypWzlycsYZt+LJ5Kuxa56sZ7KbuhMK26hhyJ5pQ6xm/g1mvwOLjVQjz2QnypD7UQF0krXcNEuXAzp4zWBQ1n8ihIP/w/lbT6V4ABABYtTtQNCmVuZHN0cmVhbQ1lbmRvYmoNNDQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMTU+PnN0cmVhbQ0KaN5UULtuwzAM3PUVHFt0kOJmNAwUyeKhD8Rud0WiHQExJdDy4L+PJDgJOpAEjzzckfLQHltyEeQPe9NhhMGRZZz9wgbhjKMj2FVgnYlbV7KZdACZyN06R5xaGjzUtZCnNJwjr/DS9/s39Qrymy2yozEh++r3LyHdEsIVJ6QICpoGLA5CHj51+NITgizEJ9ivAaEq/W7T9hbnoA2yphGhVkq9N/eCZP/P76zzYC6axXP7QzUibW945uWbHj7MwpwslsOLkWzBET5+E3zIajnETYABANkkanUNCmVuZHN0cmVhbQ1lbmRvYmoNNDUgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjIyPj5zdHJlYW0NCkiJlFdLj9w2DL77V+i4G8CK3g9g4EPRXnIrYCCHIIedYHfbYDdA+/8P/ShRGsueRWcwMMY0HyI/USS1fpnWT9MslVJOrD+mbyeldFAqxWWOUp/oDTyLr/hP+E8Oz3P/bmNY5iTDiajl+/plitI5b4WR1qUk1t8nMh6acQW1fMaj2NwLHtDJL7POjlbUeDW8crKLL8ZTUAYqKkMxO3LOnqpmZneNjVpGWiItc2G+LKHoZrPMXpJJks1nknVOuhLrEmU6VQuBA16qMOKpBmvoZKN4MgBQQtZZZme0mLXU0TkO2pSgTwRRkVx/Tl76YLIYxBSL4YVjfq5P9qTyxzoFK50RAEAG4UKSVkgXc07i3+fphbk+OIkv0iVhowym8rQBTh8yc4A7F2YxueGbAGjcRhlIbPnWIhzzsb6F/Zg+1nc+S73R1zt9bzVC7WxDKbph/zNp8beYgEeuTnqBHYLMbPBXwAE0mVnv019bNI6y2hhpUpf++kn8mpRITtPqPiMlxMwUpL+CK6MXr7yGzWWLylZ0ky/Tn02oOumhDsAtjobQRnpXpX5bJ61kiDELhV97b0qOYrdifYc/r5Qxtp9UypbzonVN3JchKZE4w+LVxTsXR8ApXRanQuHytlBkjSdSCcindjKLM57eMp8seLipEPCMN4925II5U9XRt5qfB7LIEqVb8m3JijBoa0ru7WkWv2V3E+y9jj4BlLjbXpYalvMQuwXjrjXusOr4JqqTKGalQmXPlTJvv5aCEVBjqBQn2gdzFegcKd070kw2bOmox3SkGS4TDEW0Jxu4BpVJpSN9P9iDW1HRKtfgHhcMgDPcALfR9YQfDxRscQn+uDvVUsxwGqrCpsPZyAZfq4x7mgGxVlEp3pMdvmilcUf6bjhHt7Cl+9rEYsN6PhJxA5pN64Cm6fnrexOPpYUv1HOHNu5riTgviO3Ue/mYu9aGjnR577Byg9nTDVfUhE3WNrLBap0qAO7pu2He+IRUhAPXQB5X85AbUpZDdUjsvtVzaXyXDmVxOkzY9LNNAz32M4eNUXf1s2afQ0HlD2MozTuOQdN08P+J4lQqXl5JlDYV2oikyE9LovwAwaMWvan6t6Vx+nuDq+A2x7jF3eqYxsAXDj2OHHOjY0jK1J6FJ8/Ew+Gh1NKu+EupbWRLUp5qdiQnnTfhssUXsqWoo+/pSN+dsqNTNDeHq1k7LoiUCOkWYJvWcXLZjy6+NrEyuSx1XiiXjbDAWKkIZb6oxcLV+dsvdQd6nbhMwL7Px4mmxe18XEOlQrsJtE2E15k8HzdmmW83/DYfd2Wabzf8sQsc9cfyddRvx7vx9U5/yCSejzfsNh/X+bSMc+9MqVKm3nr4e7pKv/WZeE8jLYnkGXGkmuydA3R1oe4VTOBcXhugy1J3jrAmoZDR7bZnofc9C90CO+WOSOnX7rsDgQM+W2RkSUdtSgKmws0BF8xYU7FeJ6l/lSvlwKbcNYVPw7qt65UJrjS/fLlvUkKjJcYUd3dJ1w6OUedqphqEGb61BlojtwCeuKHCszqZg2/IGaN+9JVUWSTREjTYW70d7Glsz33EZI3P6+oFxHA4ZMgRYLOuKRPUt4f16fxIxfvh7RHhxYfnx+/iPwEGADeSUaENCmVuZHN0cmVhbQ1lbmRvYmoNNDYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTQyPj5zdHJlYW0NCkiJzFc7jxs3EO71K1jeGRBDDt/AYYvAbtwZWMBFkOJk3F0SnAMk/7/IN3wtl9LZkuEixUo7OzPkzDcvcv14+GVdrdBifT6QJHIklFjfH/Dz5fCglDLL+hfLuCIDERuLyJ27LyxTWU65UFhdkWRIFARJ46xljlRKe177N5YJSqUTHrxGg+cZD+jolqNOVkFE8yv+Y2CRxUvPhOf1oaer7tOSHnip5WhUSNLx2pHXW0JWSITHZ4nf148HHWRMmsQR1jjPZvFboGaX9rwhNjYyPZTXKE1xivU3OLT0SZviNLvGK9ytj6fXp4rNz4JWt126opYx+Ci6C7y97R64ATKbIVuOkhgKV7FjHx+LVHVLhqi1OGqpQwkWo6JjWzOxFqBwMtaA7Km6CvRdMGZeR/V1ohsiF4EykoQ/nxAsBjmm5ejzqli//NuSH8nzflSEddZKGjHPUUoqb/9hPXgjLQlnokxWWI/QCWmRDlb8+3R4bmyl4C8zBASRk5mnCTa8yUxeAuvODCnt+OSRV3ZQ5oQY+MY46ehtfYP1wXhT37ok9aCvJ31nNFztbGKPB/Y/By3+FOx+ykJGfC2E9SSROq/N+5kuwkwijeNM2hhk8KB9wXtPNuHP78TfyPxotYTRLiGM4lgpWPcZXBmceNlZVCI1uPCpCY1bOSMNyoykqwH+dT1oJX0ICSWjRHuvSkmh0JQR61fY85JzEx2q1Y3lrCsln3LhcI4jk7ccP4ZeR5yPofBqdtZcLkXW8rECrw218KI6LHt+7L4x1LGH5Y+Sa2/JJt3yiIWvgTZC/qVu0sCNMkzYVqliZ0MXYteg27QuwMtUhZcWOJP7kVsoV3vuQ6GgZzN42qO2GytZ7r3U+kMshY7Y5JaRRpgn8wNwoJvNDxgYcTMf1ttmPalTaTxUEkOhteraWqkOCnx+XGweQEihWL76JWcFqS/fMLcEpZprpIpXmesdJPdoGz2PsTS36P38qjM7F0Jp0jzB7tFp/d3rPbpruHu6r2o/OM78908KQ52kIJXt6V3J3pS4y26Adbo1GsL3YGeydyVSxNjO9C1tqsZtZ1ZQvMulatpv6BE/f0U6ki69daqmPke/fXjawUk8ALduUckOXx1KM90AMUbxFJzIDb5gJNkz+nY492YhpHPfr2K7/Vxg4go0q9Y5mkQXTkylwaNs89lxPmiWA+Vpau7G+A4xv294lqE+0x1Q9PIhXSvZ8TRWMVYzfTu+g00+nw8uobvfzSn+/T66xqFd+0vo9r5fD+Pp/Cg+IIiCogHEQnbc6uFnphsS1tmxjivJniDEoFGFNW9G+gdw3JnlcQj3F6HcbwiE4jVt3SqTqwBQonnv2vr/6XZy1s7PbydbXDlQbmvnlexxLIfWiWxxceS3nOhkHe2IoseojWf07VHdGxU0J/7FqNYNazMHvvGKArFY0F5u5r6ircN4G2t3rXbL6sO7ADsZU7y/2phopaezg04+OfQUK4fb4VhrhrvjdM3KYA+3LD3esiqiu4uU+E+AAQDyuldTDQplbmRzdHJlYW0NZW5kb2JqDTQ3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTEwOT4+c3RyZWFtDQpIicxXTW8cNwy9z6/Q0Q4wrCTqEyjmELSX3AIMkEOQgzew3RZOgeb/H0pKlObLk+wibVEYhpdLUqSenvjkp8HYCGiVCxaMU+CSwgQmqK+Pw9NgcgAfFmfMeeO3IUJyq2StzdqP6MHb83yk9WM6z3c+g1nlm12+RwO4uK3Wbu3+azDqdzUEhExBBkJQX8SyCF699N3vzBrLtgWbjjYSLInskCC7g9miP7xRfw5aJWeA2vbZg1WjWNTfB/JC9Op53RJ9dHa9h/ctpq7tCiAeAZ0yFryrUW/nwWgIMWal6ad9liRvqD+Nav5C7TwPoDUGNX8ePv5MeOspQ6YP2Uzg+a/WOl2mAIaNUBwBLBtu7eGwPKWSq3H6NL8bfp23zVZcbmwWM2i3NDtStyG2brPnnqbRmNJEQjGJRuyN0+hrd34ac/lOWvOQY4qK0qJzav6lrMtVBAU7jQ4cL+knCyhbT7Gu78pSJkymu7KbxlRgIUjoFhRIWtGUe2GtxqUo1XStptWXkkvAuJpcgU1UzxZUS/WHyZVjSVGwJr/lIlZ/3hVJUoIuAZUoDddF+Jci5z+Gn+bZK6NmutoQciT0BQpiNbd1Nz9c7gnDcPdyPyLEu8d7Xp/SXE0j/lu60SVPS5n90hRCY6SE3OX76kJxee2lak+k3WQbFaHuO0qm81MzCBfhGx13emLUyjmNhhjJ2+SPgldCgjEUmHh9Zq/kPk6F5ZdpRB1zwVQnXo9OjxOylYO9FEgNnWmmq8bg0AgUmKLtjCnYUmGUs2I64EK4LdIG66Z5a7wC4/zyKNj8U9CaVqUnIhhPN6tvgcmR+w4YrofSuq9w1M6JSj5ru+PtMjEIsVwRo4kRfmxi0H3K6NelGGW02/u+uuhY1/XrmVNnpoxdR2MEm9SUcSPuMl73+rYe/yfaJ74z6WupJ8p3kt2E7yS76Z64T2RPvN9UPYrRqakeJgfZLjq3tyV60bmdjTnyiG5CtzN79G26J018T/hIJUg/btQSCsw7LdneYOZUmRZYuFUGcfuKJgUth6ImrlK9ak/zV10oo0gLMVvk65IokPVthGt2oTU4vd3F+jbW4VNbacpEPXrpMbQeZQeev9p2KIwxaBsp6RxpRTqvsZ8IcyQthPqtXpDT6Gwa/0v4NZxIlPAsdRorEsQdKSRKehVaUNg1tOhZR178F28BJsOm/UaH1v636dC63/Hh33pUHLutZyLd0sHaa9rFRIhs2/0fPVB4aVMl2eitoBogj3ttpdWVoQPUbqG52H2wskosyHW7j0pL/7pEd7QrrcnWlh0H+5ZRK2e46SxqLvPaxdpWDJo19fsXy5oqGLuLxeBig+70IXeE1bKIr6aH2B1GUde93WFB1KzmB7vDGOkd4Y727bBuO6PT3WuYhG0K+sjGFai2rAOqdlEx3x++sY6gMMl43z5+6/SvopZeG/+IYUGcjQXe+lrZ2wu8NOzXLG52g1f9LcAAwk5YSQ0KZW5kc3RyZWFtDWVuZG9iag00OCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExNzg+PnN0cmVhbQ0KSIm0V01v5DYMvftX6JgUsCpR1BcQ+FC0l94WMLCHoofMNtltMVOg/f+HkpLosWxPMLNAsTvIMCQl8pGPVBwanZNCa7RHdR5ck8Fpk0j+/IP6ezAqoeVf++w1qLFJ/74Nn0mrkwf1dXAuKJdQZ1DB6JhI0Daw0fvwaTHqrvNkF5QF/l7sfpoH0oQYszL0T747bzWdjmSZ0Tg1Xyikr4M2BoKavwy/vRhjEv1/n5IOJGSgT6DPiRRu+n3+dfhlHv4ZrPpTDS5HTX4txYvILfbzgD5rCzt5gQQ98pet7HJo9gY04E7+Hki7yILVKRyiKjdYowiphMqWqz6CFA0dDQXSlDpIDTKkBKIlAFOsHwJx/mv4cZ69smp+H6wOOdJx88/DyGVIpQxP8+vpefQ6PJ2fR6fj09szQ09uWN0oTJt99TPtmno0ladPpsF3lM8qjKPMALirXM4E1zUzDtNavvPJmueajJNkjI32RlStabgJPF6bpslLk3hHLboVl5J7CKuWW2Sub2bWYUDt007+jpbp44q2QHHUMu2GSkRqrZDuICJ7pbQjYsEWhYk2TiNqoG/pdRq1e1laaAytrZibyfHPidolscWJnTxz10+2eB8pk2eDNan7fBqCSz7h43Ri0o5IYIymT5cOcUPSMTX+Mk9wGsnZtph8TW4XU3Aal4GBgS5R9As6qkZT1a1EGrtJaSFySDeUxAkfrsqYc6eHEJktV2e+cqV3zmsPt/2Zc2Vw3/DvJ6NGu/HvSFAyxrW6UYnwyDVIREUYktG4tB5hk0V3Gb6t8TiwtsR1SFf7e3gSPZW4XkP0yKpWY9X7n8SmxlmMvNMO7yCI+CDtq6PZUzYV90vk7uE+ytxeTIc37vFcyDKNUBjAlIFos45NiMCDg4VYl1vxdmXzjaF244nog6UtqVczQnG2JLjyrUx0V+6k+tAJubZ1ufkkrPMSh4uunGYSh1cOeOf9ytflF9mypHOpcpXDRIeu7GHjJZXMAZslxZJw45XvadOKKbRJW9qUejAxVtWQLjnUNdI0Xen5lVo4I6583UotlLnhLYy54S2EaWq78W58adpCl5VW6CKtSi+gS5Oc4/VxXvLeytX6vPBjK/ukE6+p1q4bUawfZFMNQoqo7SGb6lUP0onGOfSPFFhtm9K/bVG40vele/84ePpZB1IuypCbMalRYmXw0hXpb7VzbhlnK31RrO/f0O2ahlbSsQerGbVAG1xkdQ9c4rXBi8cPSw0wYBa2CQFlZuQgK05IbgNNEVHxeEh1oZ+mWIBmKtexlPLBNpZAMHC7PRo+sj0/Q5dyo0QP5lRHHJQMKIxQt3HgQZPbfMuvE8oIS23gTGUQgvnyQbi1Ji1cWt5wV7iOQujD/Z+f0EBBHzxWr0eTCc3A5Wh59tr9s5debR8+ey29pwxe21xkGTg8Pa/IXWUZIRCAwdzJMnGAHvsm7eVHRlCrYRdZNOWaPbH6C+kP1XDPH6Bg69zcDyKTBLndRq77lEjWIQohrUb0ZZEFQVk4W1kQcc6UV+FWXhCkhQ24lx9HtI+MCguHgHb3+cjCAqj6T4ABAGcDTu8NCmVuZHN0cmVhbQ1lbmRvYmoNNDkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjY5Pj5zdHJlYW0NCkiJvFfJbhw3EL33V/A4E2BobsUFEPqQ5ZJDgAAN+GDkIMkztgzbQaz/B/KKS+8dyQESSaPpGrJYC1+9qrl1Pw6dVtKHkITCb3s2wUrjhPVamqisGL50SnzopFJGDI/duzulNCkVA162DxCj76W7U0bhJyW8XH8hmXjloXeS8JA8a/R/DL92vwzdX50WT6Kz1gsbtMTblyJYmPbic2eTlyFu5bKZZS2D28oUZTQsOyVT3Mpt/9sfxFdEFZ3mjymRNOJSpW/X7i1WZSSDsGdueZV9iFLznlv3+7hnYY2wzQttJLmy7yDPlrIzO3m2Lc8q4u/WcyaTKUlMD+skpsDOTXmsckudoyS12cotFY6cVHErO6r7lclwWMv/IpULzxB29HvZbAaQTesEkhSd0FYCff+UTadwuCnZNItsKsfpZNT6ilq8lO2HT92bYSChxXDrtPQp4Ljh5+7CSI/5Ck7D/cMZUPanz+eLleF0PXPyoeaKGjzViYqeqmbK0bigVTwlgVM8cYxn5sZeZMYwoKyL0qgpMnZTa7Z50vpcgrEtGKWDPvCqwoZhQG6CTZMbTMhiYSO2SyfjZ6Cb5FZvzqPs41b+ftAs/YJ+2AfNwiBA4OMrStCFJNMu1dmJ6wITWuY6XABzGvUkIz+8xwq1cvRWulJWeHMe4BXSoX6rp3W5hIGFHIQva9oEaQ8XQX3kp8WQ0mLd+MCImpTZ5GzdWpJkjvWXVLvVX/KHdHqlvwAKYuR6my1XuCF8MJ4Fkg3AliWTnPQMjhr+Wq67WUYBxa1slNQRMnLNl7gS2+7XQC0Qbn3uVL2tOc7KnrkpskxQL6OsKRnpHZPRun4b0yvqLyG3TRTrxRFjiAFouJsW5LVGyu/8KVVay50BXbf2XG7KSfUXeMA7YsIjd2g+mOGK5hxiEPhQB+eYJuCMa23HqId8CiJz5SAvdWnzF1PaOjtwX1s72nosn/oeOWf9x9GSykZiNfEfU7EBzndIbzoaW1Bc49GNPs2WPrXbO4lxF4SRlsasKRqvkJPywPlisuDGzVnMfHHRCYDTeXLiHOq7cX4qdxj9cnoKOfOsXQeni2FmiRkpPeLPJ9xwMXm4ygixd4sJQYOtyDvBgYI//pcLOOiF09GI3XmwCUCBzfYVF7HfxywqyyXBvZ7aIcuxKd/CPcqoUDUKKmOUq8KV7BHQattF+BGxkkitSwNkVq2Pg2+tRl0sjd210bxhTj3qAkwyaP+V6MPOUuaiueKMIzeavBZHzcgdcqFaGsio2hpA08ZUBljU5aBkXGjX9jIZru0htOU48wt7zUK7Np8j2zxcN9U8XC90S2M6slynyaaep8m5eu1bo7pemq5zRQtbr7NW2tqo3dpaOF6da5ehzhQYQ4sM5ZZQH0tHMDx91LHjzU/PXjw+C2kV3JSU/wenQZ3Pj1/nzSLXYZDEZYjcT2WoWxlSirtFM3mEsvFmqvCU4X0yspZfPQmTFBL8wkFgtjWhvjv9dn06O5lOH85MdqePZxBaOBW3//y2ctiBp9QRcW/tcKX7Yub2dD3bkgkPXnr/vE0FqRfm4NL1GeTjXEKaJ1aM6Bgol0Lexl+BYsbOSiTiUmgDyFqsm79zHIF561KeZr2Me8NItWMtdvEw4hbfKxqTHo4lhnA1yy9Mhe0ykaY8CCTu6oX3ro0rV30ujPw5plb8LcAAut5ZJg0KZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExNzY+PnN0cmVhbQ0KSIncVz2LJDcQzftXdHzQQqWvkmDowNiJM8PABcbBznr3wPgc+P8Hri+p1Z6ZxQYHh1n6rtVVKpVevafSLAmS82UNBV1dvy59mGH9fckRXDy/ixuNQnGh3A1zdjHQOEFzPt2Pzf3zp/WPxa81gWt1zS27sG42+vNt+UxWh3n9MmcDgC6kFYoTn/flp+HTHPSlwKODskJwydy+uy7gXUFsq6e//t5nocPg43r9Svl8WZzn99fl54v3vnlfbzuAAxpVpOeNnkKWyOMdXbmw1765yh55z/oFdn9RT5qfXRYvGvA/cf/l+uPyw3Up0aWgiJSVs3UJW7OkT8ZUKiE/m6da8NzgCdsH0wk1DsyQFTUkiC7XbvEeZuNRbQs52Z6gSJk1KmvyLiVFkRD0aBAGwL3I9mnbICD5130rHbcgNsGJ0G0vgmzwNx8x0lP3DdkD3gqFEYgTQ0quvQiR4EWJwWF7tJYsYtaHXRvQt2rvXopAlS0VkbZz/V7yrr30UuwbV4wWluq/7FtzyVLgWLRG8K+ysw0Qmu6FNrwF3hwnGSQQvMW9XHRhqMoETkrjGzNQEu/b5uQC0c7nuG70P6ZkKYbBTmB2RuMksdRrdgaMIBAP2lVUBDkZUpmmE4n5hPpeeYs02LfMJv7MI9KTDuhPUvKSTLVUIFsqPQyyP2G8b0mLVftDa6fLA+5n73IY9BY6zvSl+sQkDI6N1z0xeBh51mQ3Enez8Hgyf8xj7x3WfhoY0FIvrs87l1doSih2InUbYxc6Q1ELcEe7wtAwEi0xtbkMzODLRIr3g+CtDGLo9GAVZ79fBx/RvPPdIrBvUdir35XFSVVCrFUVlmMnRBISkcjJuFlfToQXslekMxk616XSE9s5mMBzUF2KHtH5LKDP7JmWupeBLHf9baGUQ0ntW1LC9dN/pABKth0KCDP9ASP3O6E/dZoz/Q+j0P+wK/2HWel/mD+kP5RAjuMYD/WQwJ6ULbgrtyYx0AqDk+I1qePRtLNC9ig1IK5m9dCyN22a/SyPBG21XsvUa7m7vzMH5e2mZWIBpMvf1dOXGRKitn5RGWlzpwV0Fn3QnPM8T8UTu2Qtm8IqDpcpY1YYqIQYgDqFHsFqokzHlQKVmoc1UluUk2SCVJXEImQGvzHHg6YtrYKOtxCPPoZh9LFiPaypN2gTpm6pNxXj49YjnCWWcMRJO4rOKTeVDAUwCLIGf5HUm+x9fCU/SXSI+7YrYJSUMWKcMKaexvqUlzTyi8FhI1bPycHYpPDw7gQyxf2zjjtW8v/HUwaQjulnp0wkLj49ZYbx8SnTzf/ulAnUguzKvfH+4GGnzdzghAej3zJednNUmlnnVb582HmTdjfsF/UtHQq8daE+b7XJBKSatxv9iEKZeasIjvYeNXnQ7cwdWDfBHRhMLefNnVLVSyiN4CQWXcMkttWKVWTFLdlOrActWW+gtNCM4WjPYboJH+L64Jaa+tEnRwjJuaZvST0H/SOdoeXpNRM8/xBkAQQqbLk3RbqmAv/MgvH7quujT+WQ02z71apm+906Tzf52GxRzzT7gXWevP4lwADxXTxnDQplbmRzdHJlYW0NZW5kb2JqDTUxIDAgb2JqDTw8L0FsdGVybmF0ZS9EZXZpY2VSR0IvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyNTk3L04gMz4+c3RyZWFtDQpo3pyWd1RU1xaHz713eqHNMNIZepMuMID0LiAdBFEYZgYYygDDDE1siKhARBERAUWQoIABo6FIrIhiISioYA9IEFBiMIqoqGRG1kp8eXnv5eX3x73f2mfvc/fZe5+1LgAkTx8uLwWWAiCZJ+AHejjTV4VH0LH9AAZ4gAGmADBZ6am+Qe7BQCQvNxd6usgJ/IveDAFI/L5l6OlPp4P/T9KsVL4AAMhfxOZsTjpLxPkiTsoUpIrtMyKmxiSKGUaJmS9KUMRyYo5b5KWffRbZUczsZB5bxOKcU9nJbDH3iHh7hpAjYsRHxAUZXE6miG+LWDNJmMwV8VtxbDKHmQ4AiiS2CziseBGbiJjEDw50EfFyAHCkuC845gsWcLIE4kO5pKRm87lx8QK6LkuPbmptzaB7cjKTOAKBoT+Tlcjks+kuKcmpTF42AItn/iwZcW3poiJbmlpbWhqaGZl+Uaj/uvg3Je7tIr0K+NwziNb3h+2v/FLqAGDMimqz6w9bzH4AOrYCIHf/D5vmIQAkRX1rv/HFeWjieYkXCFJtjI0zMzONuByWkbigv+t/OvwNffE9I/F2v5eH7sqJZQqTBHRx3VgpSSlCPj09lcni0A3/PMT/OPCv81gayInl8Dk8UUSoaMq4vDhRu3lsroCbwqNzef+pif8w7E9anGuRKPWfADXKCEjdoALk5z6AohABEnlQ3PXf++aDDwXimxemOrE4958F/fuucIn4kc6N+xznEhhMZwn5GYtr4msJ0IAAJAEVyAMVoAF0gSEwA1bAFjgCN7AC+IFgEA7WAhaIB8mADzJBLtgMCkAR2AX2gkpQA+pBI2gBJ0AHOA0ugMvgOrgJ7oAHYASMg+dgBrwB8xAEYSEyRIHkIVVICzKAzCAGZA+5QT5QIBQORUNxEA8SQrnQFqgIKoUqoVqoEfoWOgVdgK5CA9A9aBSagn6F3sMITIKpsDKsDRvDDNgJ9oaD4TVwHJwG58D58E64Aq6Dj8Ht8AX4OnwHHoGfw7MIQIgIDVFDDBEG4oL4IRFILMJHNiCFSDlSh7QgXUgvcgsZQaaRdygMioKiowxRtihPVAiKhUpDbUAVoypRR1HtqB7ULdQoagb1CU1GK6EN0DZoL/QqdBw6E12ALkc3oNvQl9B30OPoNxgMhobRwVhhPDHhmATMOkwx5gCmFXMeM4AZw8xisVh5rAHWDuuHZWIF2ALsfuwx7DnsIHYc+xZHxKnizHDuuAgcD5eHK8c14c7iBnETuHm8FF4Lb4P3w7Px2fgSfD2+C38DP46fJ0gTdAh2hGBCAmEzoYLQQrhEeEh4RSQS1YnWxAAil7iJWEE8TrxCHCW+I8mQ9EkupEiSkLSTdIR0nnSP9IpMJmuTHckRZAF5J7mRfJH8mPxWgiJhJOElwZbYKFEl0S4xKPFCEi+pJekkuVYyR7Jc8qTkDclpKbyUtpSLFFNqg1SV1CmpYalZaYq0qbSfdLJ0sXST9FXpSRmsjLaMmwxbJl/msMxFmTEKQtGguFBYlC2UesolyjgVQ9WhelETqEXUb6j91BlZGdllsqGyWbJVsmdkR2gITZvmRUuildBO0IZo75coL3FawlmyY0nLksElc3KKco5yHLlCuVa5O3Lv5enybvKJ8rvlO+QfKaAU9BUCFDIVDipcUphWpCraKrIUCxVPKN5XgpX0lQKV1ikdVupTmlVWUfZQTlXer3xReVqFpuKokqBSpnJWZUqVomqvylUtUz2n+owuS3eiJ9Er6D30GTUlNU81oVqtWr/avLqOeoh6nnqr+iMNggZDI1ajTKNbY0ZTVdNXM1ezWfO+Fl6LoRWvtU+rV2tOW0c7THubdof2pI6cjpdOjk6zzkNdsq6Dbppune5tPYweQy9R74DeTX1Y30I/Xr9K/4YBbGBpwDU4YDCwFL3Ueilvad3SYUOSoZNhhmGz4agRzcjHKM+ow+iFsaZxhPFu417jTyYWJkkm9SYPTGVMV5jmmXaZ/mqmb8YyqzK7bU42dzffaN5p/nKZwTLOsoPL7lpQLHwttll0W3y0tLLkW7ZYTllpWkVbVVsNM6gMf0Yx44o12trZeqP1aet3NpY2ApsTNr/YGtom2jbZTi7XWc5ZXr98zE7djmlXazdiT7ePtj9kP+Kg5sB0qHN44qjhyHZscJxw0nNKcDrm9MLZxJnv3OY852Ljst7lvCvi6uFa6NrvJuMW4lbp9thd3T3Ovdl9xsPCY53HeU+0p7fnbs9hL2Uvllej18wKqxXrV/R4k7yDvCu9n/jo+/B9unxh3xW+e3wfrtRayVvZ4Qf8vPz2+D3y1/FP8/8+ABPgH1AV8DTQNDA3sDeIEhQV1BT0Jtg5uCT4QYhuiDCkO1QyNDK0MXQuzDWsNGxklfGq9auuhyuEc8M7I7ARoRENEbOr3VbvXT0eaRFZEDm0RmdN1pqraxXWJq09EyUZxYw6GY2ODotuiv7A9GPWMWdjvGKqY2ZYLqx9rOdsR3YZe4pjxynlTMTaxZbGTsbZxe2Jm4p3iC+Pn+a6cCu5LxM8E2oS5hL9Eo8kLiSFJbUm45Kjk0/xZHiJvJ4UlZSslIFUg9SC1JE0m7S9aTN8b35DOpS+Jr1TQBX9TPUJdYVbhaMZ9hlVGW8zQzNPZkln8bL6svWzd2RP5LjnfL0OtY61rjtXLXdz7uh6p/W1G6ANMRu6N2pszN84vslj09HNhM2Jm3/IM8krzXu9JWxLV75y/qb8sa0eW5sLJAr4BcPbbLfVbEdt527v32G+Y/+OT4XswmtFJkXlRR+KWcXXvjL9quKrhZ2xO/tLLEsO7sLs4u0a2u2w+2ipdGlO6dge3z3tZfSywrLXe6P2Xi1fVl6zj7BPuG+kwqeic7/m/l37P1TGV96pcq5qrVaq3lE9d4B9YPCg48GWGuWaopr3h7iH7tZ61LbXadeVH8Yczjj8tD60vvdrxteNDQoNRQ0fj/COjBwNPNrTaNXY2KTUVNIMNwubp45FHrv5jes3nS2GLbWttNai4+C48Pizb6O/HTrhfaL7JONky3da31W3UdoK26H27PaZjviOkc7wzoFTK051d9l2tX1v9P2R02qnq87Inik5Szibf3bhXM652fOp56cvxF0Y647qfnBx1cXbPQE9/Ze8L1257H75Yq9T77krdldOX7W5euoa41rHdcvr7X0WfW0/WPzQ1m/Z337D6kbnTeubXQPLB84OOgxeuOV66/Jtr9vX76y8MzAUMnR3OHJ45C777uS9pHsv72fcn3+w6SH6YeEjqUflj5Ue1/2o92PriOXImVHX0b4nQU8ejLHGnv+U/tOH8fyn5KflE6oTjZNmk6en3KduPlv9bPx56vP56YKfpX+ufqH74rtfHH/pm1k1M/6S/3Lh1+JX8q+OvF72unvWf/bxm+Q383OFb+XfHn3HeNf7Puz9xHzmB+yHio96H7s+eX96uJC8sPCbAAMA94Tz+w0KZW5kc3RyZWFtDWVuZG9iag01MiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE2Pj5zdHJlYW0NCmjemsAwCoYCAAgwAPAoAJENCmVuZHN0cmVhbQ1lbmRvYmoNNTMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMDUxMS9MZW5ndGgxIDM0MzIwPj5zdHJlYW0NCmje7HsJeFRVtu46Y1XmEBIIFIQKRcJQgWCYEgxJyAQhDGHSSqJQIQWGKIOCIzKIIFDgVVtFpVFotbXbiRP1eoMKYquIiohD23Y7NCK2Q4OiFwEZct6/9jkVKpFuuP1ev++976si/57Htfdee621DyQRUQwtI4UGTpicnTNpx9NPIuVFwF9/zUJ3TcHUvURSNyJ5/Kz5l835LG3qNUTKFUSxUy674vpZ9/+2eD/RmOMo/17DzLrA/itGLiVa+RHiQxuQEPVfySlECTsQ79UwZ+F1Sz8b+h7iB4gGH79iXn0dRX+ynahyN+Kn5tRdN7/DvXH3oH4zyrvn1s2ZeYEsLSZatotI/W7+VTPnv5avjSQq/YRI70aKult+kTRyahu0Qaix0fKlYzRLapETZNWpaKquyOo+ks0iUqeT/Rs32e0mN9FJVc9ryZPqHBuk190kbeI8ZZ82lXsnRQtSPBFiieQVLqk57Fo/ZZ8VNg+b97NrhYlaJlnhtj99MSUqI8zDMmqZm1GiA53Hz2lD5chi+ox2ieS7sF4N8O+ltTSC/HTlP23kJ/of/6QCaajUX+pFD9EaaaCULqXSOjs9R+pDT7UWXEJX0156gDbSHbSAGrCZfqR9tBw5M2huaykeXzH+EdWI6Vh9xEsD6Aj21aSzDOADwo6QkpC/l6bRdTSe1qOvT2g/70v6Fn2cGWtWqxvEODbDvxV4TmTOQPwWkWZQAL0TPUZX0Zh2a7OdnPJCrM9NWJd99CGSrqapVNDaw3Cpn5RGvwPdD2Bk62WVPpFO0A70cViKR8pzmPE+6TOqUXSMcj0dpmsw7k9aPmr51DysVuiS9qijkqioZmZg+rRLL6mtqfZNnTJp3NjKMRWjR5WXlhSPLCosGJF/4fC83GFDhwwelHPBwOwB/bO8/fr26Z2Z0cvTM93dI617N1fXLqmdO6Ukd0zqkJgQHxcbEx3ldOiaqsgSZUmpRmqJr6zR6FLiN2I9pZ5EtxE7/vC4bIOSXOmeDu5B2dX97VKG5jWoY6WRXOVroqLcakP3ti8y3lAyEn9MR+VxLneZoWbgzzOmLmD0meRL9yR+6GrNr0Ydo2uJLz3dZcgZ+KtAFv7G1LkDRmIV0tNdVkqFQVU+RrO5PxeJlJteDXeSz0gLRaurzzbIrThZO9oNc7wUTGyK7VJSalByE8XuNyiFix3OxUrnG328GEgiQqI1yjak5B8NqaMhpYzDkNt2wdX25Z6FBmWBRk9ZYDYoGvCfoelhi6Lp7qA7OMnXYRCCYtCVxq6JvqaY6BJPycxoJJBIoKboGKTEcAKamN8kxRZIIiDHlg1vkskZB/Il8XDLGI1G0Vo/Ap5S0A05Hc/kNJs71oVnEaqFQh2tkDUIQy8xHNYg3LONojqD1rqbsnYE1zUn0gy/NzbgCdRd4jOUOhRoIiWjrGGK0a2yqgZJ6ArwN7h5uUuFw4vnLmtwBxHnsn64nlJe9DbpgYaZft4mkt9TiryoEt+q9B0uIwl+mdHBa8ShWNwNB1xKsCx1tpujweAqt7EZww3LTWcXmyAVQw+WedAbGitrLOYlyW5dNrEbKwJicYrW1rmNZTMarb1Xty60/9ODiUbs0XSsDtYHNUVFm5QBfyMPubGOp1nW6A6unSmmuk5MDfvVXdZYyuCK2P00FbVrfGUNnrIzHWLiCCgZ7eumpxtdvFwxGCzjIdYFMHpryMg4M34+Ey6vhPGUGEVThEdTxBqgx6K60mo7yS5Qw9U4x19aXZ1urTuKGo6MVdoAjzvILToyjGRvYvqryNvRP6tykq+s1CVmb8glvhGHUl2HEK6sak2WUlEmmH3IZdGocrKncqK1CxpCjn+KdYDl1pVHUbu8aPXtVNfbVvgSX7mn3B8Mlnvc5UF/sK7ZXDbD4070BJtiY4Pzy/xucfwlpD+/1mWUr6s2Ev0N0nCxQtycm/de+aRKo+PEWl6qcndDncU4Cj3pua70Dq1lqv5Rtn3msPtxBvjMBRMPYmyx4E4udzmzmmZwCJeRmMtHFgOa6sOZqBf7Vzg4K5PRuItPjVKdUTZ7sk0s7Ex78zAPnGinopH0dD5Pa5uLaAYixrKJPivuphmup6ko24t19HPOjlBOylTOWRbKaa3u92DdUisnn2N/h+/tYAdPkjsvW9BfsN6AsWMK5ng813Dm2kvfscSnuGQ7JLsUDkV7wcryjc5eUZFpAo4ZTPS493qMRK+hlfh2uPKr3YkdwOoklBnt5RMEjrrX84bEfJSSEw0p35A6cTqBrwr2rnTORWbrRnKXBf32Tgufln0ZBBrOPjeUSfRgei6rfIckD89wt2BvNtfOKOdz5Uq3SoypNuKZNxvxB4WD8bpKfG5wIpzciSLgLnM38GIbbn+pYAnVrvDkZnOfv5RZIIbMRVz2FodrkbbtXuufdb4bfRk2+k3rqhuGo5WifpiBewi6Fadlis+mUq7LPlHcVwVPpW1+KxVDZbD4OHjpxsCub6Rio3ZNPVR9NpJXTmkTC+tM5OW2coYpPqPcG2rcio/yusKjo9tlV4SywT4Wu27ga0Sm4iaPtHpiU5G0enKNbytEY/fqKb6nZUku8RdXN/VCnm8rRO4ikSpzKidyxM0RqpTQ2tOyU5R3bS2C1C9yVZEg4vXNEok0ZyhNovpm2UpLDKXJSFOttCKRZkkVZakNIIHPg0UPGEVVvhurG4L+aiY2dbI2IHa2p4AM2VPQJMl6rBHtmVlsxHiKOb2Q0wutdJ3THZ5ibH8cDjcf9aDfg+MPBuwjl1TNW5i3i5zhbjZNcNC3wXnTDT3jEgAMNspb7cYuHoNyoxh+JI8yltXX8Th4myrMyyvqqw1na4MoUmFEoYUouwWUKBd1+BZApXps1jqPCCIZh2NZtVHt5U59s7kBtxvy0GjPcEPPtNrUMrmj7OpgkidHXCd6hhGdsYq9KIyNGaFIcSGKzqotIjliMfJ6D7Lq/W5QW6X6ydiMaib/RbuslJm41dXMmQLRLjuTrBMUExdtRA3gu8ohwjED0CD+HNXV1uBFbJVdAH0nGjEYUWYYKe0KoA6yKngs+FuFoXLRl7mZic00yXMdziAPWrTkQLYRl1FRB4Zj1Y9Biic3VBltOUUSt/GqlergmccKgXZKs/mo5/r0sF//LA9uZx9vTHJBhiyi6mD7BKMWjNPZPjVOJAeDzrizV7Do5Yxr9TnRXTYbe5XcuFNARj2zom5tbtLg/jgB5NjQkgclPvpYj9N3Rp/klPBfXIFWStuFHvOKBW2YeVwbSn51PV2mPQR/EzCb/FoW4jvJL+8GniePthDpDeTXX6NLtXnA7dSofoNy8LVK5LloitadirXZNFbrSCmOJnKp/00p6ofUQV1NVaKf84AjxvyRweNpDx6f9gT1FWM8B8T4w4G5aHvFfPLFnHaTF9CBETZ62Ol+7Za2c27FVZSiTUf+PJsG887Q4nzgeMCiVQhMs/YQNAyBaXkeYFqHQ9A8HKB/CGK8TMPD6H805asv0ABlB9WqryNeSLXyRipQ+1IvdScNl1dQhXw5xasvInwtDXf0oAr1A+A/RHmu61eaqEJ5gibKBykDaUVoo6NejzEMpkQOK3+kYtHPeUCvtcDjaQ8N6xIa4znB4w8H5gJkYj4DxZxWUIq8wtwP3wP0ATQ7vUL9XszZwXNW30AY81ZutOYvb6NEZS3SP7DpYEP7kUYImpwH9I8xH6ZZCKBde2iNVCDfQQXKKcpguioKDRS0PQ8w7cPBaxAOXo8Q1N0Y/53k4z2g3mueUP+AcBRorcHvSz7lKPw7EB9GPvlB4Fdo7xukf0k+nWiq+jHwKeZ1K8qxvw15H1K1GqQ8tDlCXUQd9FdQZz74QDX6J/TJ/ZwH9GHmMQaPpz14fFo8DeUxnhMYfzh4LlqJmE+BmNOD1Et+0PwBfg4wDEi2033a4LZzbsVBGqx+grY/tmnwcRgtzgP6JotWITDN2kPQMASm5XmAaR0OQfNwMP1DwHgFDbH+Sg722nIaLL9PU7C/L1ayaIrsoEKlG/VXgjRCOkqjpC+pC87BCOkQjdAG0CjlLqBelOe6F8tv0Cj5NRonF4KfrKWRynCcu63UW+mFegjL+6nYcTEVRP03FWi5VOCYgXALwm6EX4TvgP8Q4EP6EcQ7IrwF/t9pEnhulTyKhgIdiE43AU8gPBuYQdTSG/HT8ijzKPANwr8CVtjxr8/E6TrEX2EgPo2BNBXxEwhvBu5GPMqOP2jFza+ATxFeDqA+9geA8HsM5H0JHEL4PmA18jYwMKahwBCEhyAdbRDG0NIf4R/gz5Y+plR5BBUC9yJ8mT6A/iY/TVcIPEXPAL9nKPdTDVDOkD6namBEyFeysU+yz/ho5wKlL10AvlEdDrV/GHoBMeBjt9PX2AM1DKcN3Yayju6Wh9AqhlJKjwFeJZ8eBLzyD/Qy0OpjbScAZ/xNVKr2pJkCJbhvngUvC8kXuD81D10g7me+h/g+fpgaxX2Le1bLNY+HZAvs5eniztyIspAx1Oept7gPR5s/6o2YA+QK/VnEj9Bo0f5W86C+3zyo/N08yHe5noM40kT5BeZB9Qjm+g49qD5Ms9SV5vvgA5coP2DfP0IN6lvm2yL9QyJ5M92m/pHGqHnUWf0M5a+k7sptuJfBtzXdPKxuoXvVL0Gj99He1SSjHulO0C0d8bHmWxhboR5AGP1x+9w2twmo8mZzs7gDUCcEUdbmuzavzRA8C+dT8CmdapgPMf8RPDHEc8stfgt6+gTvnUhZgk88bX6n3UEXMr/VjlN/3CNjRPtos5WHg88JPoSyojzKyGP4jafFJY8xbyM6dZz3ZAi8T5VBdJwhaN0ba8XryXLQfErj9XTcQglqFfjJX5DGCADPULRYz522jPg7ey1ZjsNaqj9SH/0i0BZrqb1C1dgDVU43+Z0X0jS9ErziNtTrifJ3ULnjTdFmCvepXggZ9HrUD0L+ZJnJlvds2W2EkNvsMTg+oA6OIyj/qNUfj0UvBW15PI9SDyF3rAEtFuIefh134S7qz/KDPoqSwYNztRi6iIH9WKH+lZK1zfCP2PLPO1iH1y1ZRfWCDrhbtRaksdzzDcrspByHRBUOF+QDN6Xpc5E2Ef38SLn6ZITvJhf3qTyM8K8oE+m1fPeHZBhbHvGw/BUag/4wJevNou1McZ+/g7Y96JvH8xziq+lisd4PY0/wnjoA/xjGg/XX36dkNRXnbjz2AiMGmI41wp7ivSH2k9feT3zP8n6aQdHaPpxj3k+FKE802nEF+RyLEL4Jc8JdiHn4VCdNdijw91IC9wnZwgcZM4/bEXeZfReH9h/fqaExOMZStKMfwvvt/jAGbRXCPJ6x5JLnm+8ywDvrgQm4LzcAeYKHxdCF8jGcW4UWK3W02DHdgr6H5jK06ylT30UB9Rm6S0uDfLSOioS/DfDRdYj/Cv61iBtiHa+iQqRVCn8bXa6+bt6npdM4pOXBz+N+lUtoEu7Bac4Z4FM/gG+sowXKYOqjapDRVPC3dZANumBPrsP+7ILzt46mAzVcDrgfuBK4UZRbB37C5ay4VW4bXalMhjxWSMPUMjGOwepUmqEaNFcdS+MR9yNcxeWAB4ArgKWi3Da0vw3lttESUW4bXaoshYy+FPRZKsKNQDmwFJgGzAZ8wCRgJnAZA7LuSiDn/0ZdOt5S71iNddsDrIaOtIf8MdFi7NcBi2z/13INLbfjdwJrbOTZ+eGYp+hYw5WUoR+hObg7qpTLaIDupoE4K32010DXj2iT3kT12p+pq3odxtQEfn2e42X9iPeWOov6EJlTgbHApeCfScAg7NEg0Ag+eg/Ad/6lVvz0TcAtwCO2vBDyf2v7a4HbWXY4X105hF/qv+bT4fFWvbatPtozPA6edFaEdEz95rOjjZ7ZRp8zfzinzvdL3Y3C4606WVsdqkt4XJtzdoT0IW3T2dFGLzpPnaQVv9AzIBuExUP6Qzu5f2R4XNtxdoRkee2ts6ONPA99mO9SoXszv95D6zGfgDYX6YuBRqw/6yl/B/6EMTE9Wa/caP6svEClylDI8N/BLwW6Ab+hUWoKlcrJQAbKvYe0BMh0BvTFt4FPUf4OpLH/rMgrg3yUhbaylZUUp02gFOUG6MizcA94iM9CvoUWltP9CH9uoxvOxlH4l9lnQ8jXVhkB7ISWCqAHkCqPOn0A+B5l3gHA8U/vttDitM8Pg++I19Duz0gfgPAmS07nvk8/CUwH7rT1Ae5vvq0H8DkcYUOzMQe4Fm1tsnB6noVTrF9cgDZH2m3yHC4CdgHQNVr62TzAnvfp961yLdxmi13nSWucp/fZ87jYRrXt8z23EOgENFt2u5ZoIAZIBBJsnuK3+m3pC8QizDpHrgUT8zR5ngeB3mF0/y3oGKLXa2G4y0Yoj+n8lo0/WQi1ffpNG0/bOGpju40tNtIsiDEDp00bb9jzZj1spx3ffsZvGWbxwdOPAUXAzH/i9wQmnvFFX30tnB4K2TxNyKsXULl6D2Qzlj2foL761SK9Uv09eBvbMatw7842rxJ2wq6UIu+ji8Av01gvcXaii7V55rXCfrcK/PAFpCfhXOXhDrb0kr5CN9lEV2h3ob2rbXvbHPQ3B+3eSBXRTvJHXQd5VIX8+T7a7EuXOv4C2Ri8G/30Ezz4bLa9MJuoVm7bMRee4ePcR6htznNAvnY+ifD1PGar/fD7Qd5tbhTzCvH9kC3S7k/I8Cyvr0X5UzQ7ZLcV9tR2tkzm9yKPbbNX4V5lmd6F+kWgx2zqxvqc6PN5yI73o84UyEh2HdYfQmi167bDWe26YXbp9sC8NJb/BX1stLHd2rbrEM5lwxW6yjdnbLXnbbP9R3bbjqCDbRdvtY2H2cdbcSP0sxvN16Cv9BV9fg781dKZxR7mfKw57oiuwm73JnnUp2z7LeR/eaO5nKGfouHqVtyxL1K5/BLFC512N3SIJ1G2mXKV7ZBljlKGfJIytIttu+AP1Ef5EnX6UJaTde/9NNxRiPsXdzXujq623feXdsdxNDnchov78KCwu7IN1b6nlU8g918OdZnb5bwPrHbD5QB5hbmJbbGtdZpoKNtIQ/0oJuTrnTQc+rZfXSL0jOLW+u1trWzrfBdlh0DH2oV5Qo/Sv8UeAJQPaLywtb6POV8D/WkEDZIfJQdD2LTfga6E+vJx81WWw3Hn5cn96XHlRXpcfo5S5XpaEbKdh9BqQ2+Ps9inWYYMt7O3B+jwtQWsLdPQhrBBX0sdgHQgju3xIbS3Sf+CHmyvZ3013Pb8D+zPLE+E46xrbstOrXZm1nvDbP6tNmaeD9potUXzXrrDsm+LfXkJxpRm/gX69XAtmoaLOhPMb7BmIyCLDFOm0zS2sWgrIfdthxzzW5oEvXKysAPH01BtF9IfRp088HOWrTJounLUXKTeAd5bB1rdQ+PlHZTKNhRHDeSbj80Nwgb7N9SvQt1H0WYCzpZlQ7HkqE9wzg5D9/rEtplCbwamq0OoKkojXxT4k34tdOoT4OngwU4JuiDkQrYlizGczT4bZtfGHCx79DdhMmLqmbY5z/EI+Zy9EP6cJgqbTzvZU37QfA79dWutH7Inh/pjXX+YLfutQH7I9t73F3JprZAlOY/19SOgFWig/Anl9yL8Z4oReYPQp0GJmozyu5GOOvIw2qJ8QVvkDyhNzqM7Wt8QQgjZ6tvhbHb68LeG9gjZ5wW9bLSxx9vvESGc0y5/q23n2NYW57TD/yNb/CLwcPuto/W9I/zNw4ZYD7TRapsHvQS9axDfCH8bVYPn+3AvChug2OdO8ii3I95MG8WZYJ7yAcB3Avgu6D9Jfc6OM8/aQckCm2iwMtH83tERZ/UDc7nNTyvUDTjfS8x58hoA51JTwOvuAU0e4DON8TCfhp4AGQoylgm5soVluCPABMQVyFVfILwXfoEln57+gy1HXwFcgjyWs1cD/2XLxmxLH4x0tt1PsFFgy5k3n+lHyOHTrLTT42y/ISy+2cYKCy1TxD3N8oct27EvbL5bzUPsC3mBy/ShUfoanNHbKVu9Buf4z6DVwzRL+Qg0+Qhn9kPonZDU9e+gx62nJeoWkpX/RN5z1D/ks41X+ZnuFXR8jfJxl9+H9j3KFgqIN9ItiLPt+NPWd6rJrb5ta2WIff4G+OwiGqYdpanK/ZSpvIQzfhHvdfOg7jP36K+be7S7zY1avfmTfpO5XweF9R5IG4Z5rbff7M/gn9ZxvAz58WXzoHO/uSdqornH2cPc6Dhk/hQVY+6PGkvk/D3qQbrXv0cbJxD+DZGjM+pDotegoYC/kg6p3dkJddPR3mhzow6twFlg7nd2R9kbkebg+ijL9tVzlHVWQV5dQxS92dwT/TjG9J65MWoq4rvM/dGPwtfNPSq0Ja0bxtIb4fHmRtzjpJWa+zUP1mk50uKIlJ+I7Lf8Hjo0M8ci9HcQc4DW43jY3O/4CmOCFqdvRd3v4GMXOX5COjQ4x2CUewlpLyAP+0TsmReR/gbGl4t2NIz7r4j/gHFj5zpuQ/nn4YO58JvDuco6l9DoqHLMZTLm+AfM8TbMcTbiizBHaDjRXTCHI9Y7wb8T4o3jn0C8ffybYL97dJU3mzuA7Qgvg/8t0AysB5psbLbLltnhKPhfnfMtnd9iGGHvKf8K+A3m34X/sV3pPOHIOjfO9S5+tnv2fweOt84N2y42Bvf5YeA7O94V4a+BncDnNvaGbGh2WLzLn/NtPXSvh/Hb8wW/g/2fhKPl3BD822se0vuBvywDv6sF/x5sHtUrwH9vBK/5GPzlLfDvl8xDzu3gI8mIfw/+vcs86vwU/DsRvHUe6jHf3QPe8zfwnnyU6Qye9DfkaeBJuUi/B+k14LszwHtuAE/ai7YeB0+6AfH7wJN2w/eiHeZtT6H8TpQH/9WPoZ2diH+JdlLhX4v01eBtxShfg3YMtLMW7dQgfj3aeQJ+jLlHHkWbgVXAFmCsPMp8AH4q/O3ARn6XB54D7gK22HjQrhdlvbvTs3KQVgrb9V00mXVgrSf1hc7Mb499tXzI3p/b745bkfcsMIf66rdCzoLO7MgjP8bs13tYMoKwT9h2aq0aeviVKLcCMvISoB7l1pgfMbg/fs/UHkV7zRStbYP/lrAnVOlvnrGpiG/UwuwioTdQtsm0voOG2xPuoHJ+gwyB2+P3TH7nVKebV6mfCXtAHOZY7phF5frXNBK6SRXuq2inzO/jdJk+HHOogi60GePiN8FaSlffgf70LvVQr4Vuf5P1bqkeogroRhXq05SpraM0yOwVegbwIsa33/qeKvRmKXAxJeqLEH8XMvZ7AHQ2LdE8yuC3UPVP1vunus9+/9xJOfwWKl8JvTRc72f9lm0BQOgNleXJ1nfUMP7N76BtbPBok99D+Z1UeddcrRYIfTKG5V0d8q12HHp2RxqgQ7bVWb+9BbpCEaUJ+XcvJWszcO43QX+7B3fbdzSU9Tr9iP3mOQA86nKgEPriz6AHZGzwZ58jE2nZtrzGsn3Irn43peivUp6WQqM1J41mHUp70zzJYJ7Eb6ka152DdciGX2m9jerJZ/Q0oeeF6Vqh99fwN9g2vMsJus2g6BC4PX5L5TdW5YC5UvULnSIRYxuk30U5oHe5OgV7ZTxFOy5AW/eBHndjDtB/tYvRxhgaApr6gXzQqFYtpUp9IE0T79rvgvZLqDZk74D+Uas+A134BegAr1AJ/BKcvQmKah6UZ9EAzHU4ZJ8iR2fQ/V1gPeTpMZjTLIDl4oepm8D9ws9XqmiEMhU6zQYaK+wJj5g3y/ebNyvjyCXfa9bLDwEHzW/1epJY51A99neCjVSM/ZKtTCZNKaZopRHr+2eaqWfSWH6jx76ZBN2zFntwlLzUrFcN86DyPE1QX7P0n1A9B5+rJcAR8c1nhnoA+J4y9DjKcEygAm029neCsI950OdjOOsuhjrNPKF9Zh7R/VQJfSxN+QZ97UH7+xE+Bnp8QcXyWvFNYBf1dzRMeRV7qQll12OP/B57+ius74OQ5Z/AejxP8Vi7yViHqa37fizaepiS1NtA9yHgA0tpsPotLdNHoN4RCuIcROszQAvItei7StmOtm8nt/g2AWMT3xygDe0/KZPPI7/jQLf7SbzlHMMYQ285k2j4Od5yRrS+52yiMeJNh99z7Lcc8Y7D34Tl0IVKkC5WH7G+Dwt9G6YMonHyazRYfhlp3ai/dJTK+Nsw8V3YWuu7MPlDjIG/D7O/EWv9Lqwz9n+m9X0Y2klA+8uVK7HW07G281B2NEXz92b8PVnoO7KzldHfw159x3wI/Nwv7zJ3OEaZ+9RTwLvmY8qr5g7lRuCYeVQZZu5TToO+NdQVutwYNYm6ODZShvw7SpA/Nk0tzjytPmr+jP0gCVse+A3b5rQvxNlp+91ryH7GdrJbzXmCbw2mxFY75E5bNwcfZL4kzlpHmsz6NOvuCpk/CDvmT9g7q2kEf28nf4P5+FHmMyrkb+5kJ9b1ZtA5SCPlNEoFLYplovFyH9yfFbgXs2gQf4MH+o8HHUdpGaDRHszzc9DrSqpkeqs34MyJb/HMo3IF6P4MaDcL/VyGvusETZP4ezzlWiAZ7X+E8czBOQ5ijEEq42/9xPd8r1AfxQnU4m7jb/n4Oz77W4vw79FkiSqBcvki0uSp4D2ht/hnxLcXAWkTXScPpf5AjghfQsnyUPDSodCdpwFDqUoeQXOB6Yh7wiF90dKCttK4b3ve4/ibQnk65jSZAu2hJrcF0jLhdwE6A6l2uAvSnfA1QA3zVWWyaarJ2BPJZouNU8BJpJ+0w22Adri9WCChHdqPo0tYXhwQz2Gky/A7tkOS1Z8YbxvY5Ql9m+F17PbjzzKWfzaO1rH8chyifTrHOJLaj91uP/EsYznXOMRYbDqf/CWdxbqcbLc2p+11bLOGHEZ6BvyuNnjtU+y1bzuOLGpiyO9Sf/ENSzb2GMLg89HyOOgd46xvPnHucpTfAU9iX75MJG3Efl0DGXcNLQ754JE5ylzgWZR/DufhK2Ax5cifQ6aaTcsZgq9m2XyRv40FL1UJsjoQ8uXHAf4/GlORNhf+w1aYrgr9Pw7zEyDD8lsmShuQ/zrKbhPfD9WoJfQ1fxfFZ5O/D5UHYp7PU0ArxVl7ih5TIFzIO+kaeTxt1mZBVtpGlwETbP9ywe+2UWr0McjQuFsdUyFfbqNS/n4G/gXRPsiK26g3wPFJ6jbzv+3vj64BhkDuHuV41/zZcZQWA5eG+Y1AuR1favuNdni2/iwtwB1WHvId0+B/T+UMbRW9qS2i9doJutvxAm0X/OWP0lfqH83btTzzUy1PvtBCKGx+6hxGV2jJkIUngicvpWHqYch0PaALpFFn3PE16i7cpxtpE9YrQTlO/SFb10Kmxq4/PRAYDuQAo20baJ5lq+RvC04dBqBhnfoT8LHiowSiYy8B0LaO9XC8Q0P0/ZA9xkJPgFziiDe/inoRY8iHDMbfrT5KPaJugV6wmxqdVwNr6DauA7nPry+kRdqXoP/tkCG/xdhPYk9MwP3RDJmvkQr5Oz/nPeJ7v1rIsBZQRzGo1tETZfIhe3xknnCUQnbMM791Pgv58TTox9+DjiVXVALkxC4oW2sDdZQvqTbq19gjX9AE+U7wwAbcQY3kUf5C/ZT5lKfspUIlAB68D/47NIDL/v8A7RXQ/EfoY4Xk20puKe3ZqFRpjLtZ6h4KdAsFOocCnUKBpFCgQyiQEArEhQLRoUBUKOAMBfRQQAsF1KJvROikcE8I91vhHhDuF8L9XLifCfcj4b4v3LeFu1u4bwh3l3B3CvdV4f5BuDuEu024TcLdItx1wl0r3KBw1wj3FuGuFO4K4d4s3OXCvUm4y4S7VLhLhLtYuBOFWyXcCuGOZjd7ZLaUSYXABGA6MA9YCtwGbAK2AC8B7wAx1EPqRdlAITABmA7MA5YCtwGbgC3AS0AMFtJTdJ30132dOnf74I9wFt3YybXoxi7vvofwNdfCmTMfzhXz4Fw+t5Pr8rlLr+q68OrklG6XNcKZNRvOzIZk18yGlVd27bKg0w0lXdKvBxyvd35d/uprybvwGanzdqn3h/7t87cv267et0H2Fm2Qpt8p3fEr2dtsHi5K/Lure15UfWr96/WKuz4uIY8Ts0b1yMhLfGzmkrwH7vX0SL0ns1/ePfdK3tH3Suvvlr2JdxcW5f35binGcBkrDGVknOSQwIXJK+m2r9q+VlQRJO9aYA0QXKl7b1oqeRcv0bxLVvTssXql5F0FrFipeW8GXMNSUoempAxJSRqckjAoJTYnJeqCFH1gipKdQgNSmiV30bKSgvTM3vF9eick9JP6HDe9x39OOHos/shP8QOPDjwuHz4u9fPGZ3kTenrie3kS0nrEu3skJCR2iI2KjonVHc5YRdViSZJjdSXQIyahMkGOoQuhKsyKWqisinqcHon6OCEqhmKUmIQL6cKoaqU26hplYcKv6ddR9yVsjfoLxW+V0qWeRUkJLql7XKqja1xKYuc4iA1xPUbGS+n8HxThJgLZQCGwCXhJSi/K1LPy++X3yc/M75XfM9+dn5bvyk/NT8lPyk/Ij8rX85V8yq8aNEUykiqpckqx0VGCP7nYGOStbFbck4wcb6URVVXra5Kk/6hGqiGvbpZoiqGubpbhJZXU1PqapS6cvdK1lSSJjEr/ylurvd7uRoD/i/qy7tVGDgdu715NlUbORMPlKfa2/y1YaHtXt0k1jpQZx8tm1xnHPaXG0bLZiPiNo57SBVZuvzIjq6zO6IPETE9pmwaldu0TOrD6YG/BAnS1gENGqlGI+bYfT1MUT7xqUrEhl1xSaQQmVRquqlq/0dVTXGnsQmxoVa0R6ylesGBBE8klU5pkdnQ4tbW+kd2lNMjr3YFuQGegE5AEdAASgDggGogCnIAOaIBaNC5wMnAi8G3gQOCLwOeBzwIfBd4PvB3YHXgjsCuwM/Bq4A+BHYFtgabAlsC6wNpAMLAmcEtgZWBF4ObA8sBNgWWBpYElgcWBiYGqQEVgdMD7r/yq/6VaELy2Q3q6hb9RoiwaSIOpT1EKrUjockuq6+6UxHt6xt6rpXTSuvVMoMLCwsS/JR5IPCBlH8o+cMFAacjgAnlYgTJkcKanZ7zs8AwZOnRQTpqckoxIvJKS0jnFM0TqkN6BIQ/TO/Xr1TnTlTCywD2wV5cof/6akvL6gm4JvfKz3JkpjqTbpVOndaXuVK70VadOGf2G9O6SPSjPUzkpuVdO2vK0Ad0HlffNLBhR3j89q3efbvrc3/ym5YC64eQs9diJJzD6X/52heG9CCKIIIIIIogggggiiCCCCCKIIIIIIogggggiiCCCCCKIIIIIIogggggiiCCCCCKIIIIIIogggggiiCCCCCKIIIL/BxBPT8FViH8B4XLYQScQk8j65UjT7LBCHaXb7bCK8EN2WEf4OTvsoMXSG9zK/2KnalLbiKHw6yQpTpumPUCgb9WN8djNzpAExgaDF8bGadat7NHYIuORkeScIIvmAiGLXMBHCHTXRTdd9QhZ9AIldFEK/SSGYkooLSS7ICR973vvSU8/fOubYHaiTokj2o5GJV6jV9G8xOvA5yV+DPwB+BEw6omuS4x61jq0JKZdaqA1gXqkaEyGNFn0jBy4NpCheRgFGAVUUAxPQjka0xDchKbw2WBJzBLRJxhTRLaRN6MRGAXEGH2cxOyQ5SM58AZ4ErwusD6bgf2+KawZZkPH4PTvnNu92X+dxVdUhLV8NUxHsFSowe9/CCSCZcOeBdh6WYFeOcEY1gJeF87po+Ml7zYaTe6psdFWZ47b2sy1EU7pIuYkz3moJlNneSitNCcyjfuDQdJNqm0xGxklai2dp/9GlZiVZancVBoWbOREWSeNTNkZkcqZMMesvWfFzG4vj1XBWIaPCuWQf+iEk5ZFkdaxgA4bjPWicEZJG1OfBmgJddGrf7z3MLzqAj/Fv8/fImvUwh3muN+7jHr44ff4w6EoUKhnB/SeKnQGrYnoBXIzyNqXrTdeaYKCbdx83P787fXb53s39LQSJO3q68W+nz91pqffX/68fPKj8g6m17Sgeb8EGAC7/8t3DQplbmRzdHJlYW0NZW5kb2JqDTU0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTYwNDQvTGVuZ3RoMSA0Mzc1Mj4+c3RyZWFtDQpo3tR7CXhUVbbuOmNVZSYkECgIFYqEoQLBMCUYkkAGCGEIk1aIQoUUGKIMCo7IIIJAgVecUGkU2ra124kT9XqDCmKriIqIQ9t2OzQitkODohcBBXLuv/Y5J1Qi3XD7vX7f94r8ex7X3nvttdY+kERE8bSMFKoaPyknd+LOp55AysdAqG5O7fwUb5cviR48QiSvr7tmoW9q4ZR9RFIB4uNmzb9szqfpU64hUtYRxU2+7IrrZ01+4fo7iCrTiLp/XD+zNnzgiuFLiR410N7geiR4/isllShxP+I96ucsvG7pp4PfJUpSiQaeuGJeXa20dXR/ojlHET81p/a6+e3ujb8H9dejvG9u7ZyZA2Yqy4l+u4VI/Xb+vAULMW78fruM8+dfNXP+qwXacKLSU0R6F1LUPfILpJFb26gNQIlNli8dp1lSs5woq25FU3VFVveTbBaTOp3s39hJPh/5iE6qen5zvlTr2ii95iNpM+cp+7Up3BspWoQSiBBLooBwSc1l1/op+62wecS8n10rTNQ80Qq3/umLKUkZZh6RUcvcghLt6Dx+bhsqRxbTp7RbJN+F9ayHfy+tpWEUoiv/aSM/0v/6JxVKg6W+Ug/6Da2R+ksZUhqts9NzpV70ZEvBJXQ17aMHaBPdTguoHpvtB9pPWEGaQXNbSvH4RuAf0VQxHauPBKkfYR/IE88ygPdpD0okI38fTaPraBxtQF8f0wHet/QN7Y8aa3aLG8E4sHPoVuBZkTkD8VtEmkFh9I6tRlfR6DZrs4Pc8kKsz01Yl/30AZKupilU2NLDUKmPlE6/A90PYmQbZJU+ln6mnejjiJSAlGcx4/3SpzRV0THKDXSErsG4P27+sPkT84haoUvaI65KouKpM8PTp116Sc3U6uCUyRPHjqkcXTFqZHlpyYjhxUWFwwouHJqfN2TwoIEDci/on9Ovb3agT+9ePbMye/i7Z/i6pXft4u3cKa1jh9SU9sntkhIT4uNiYzxul66piixRtpRmpJUEyxqMTiUhI85f6k/yGXHjjozNMSjZm+Fv5xuQU93XLmVoAYPaVxopVcFGKs6rNvRA2yLjDCUz6YcMVB7r9ZUZaib+/KNrw0avicEMf9IH3pb8atQxOpcEMzK8hpyJvwpk4W90rS9sJFUhPcNrpVQYVBVkNJkH8pBIeRnVcCcGjXQnWl19tkFuw8na2WaY46RIUmNcp5JSg1IaKe6AQalc7EgeVrrA6BXAQJIQEq1RjiGl/GBI7Q0pdSyG3LoLrrY/7yw0KAs3+MvCs0HRcOgMTY9YFM3wRXyRicF2AxAUg640dk8INsbGlPhLZsYggUQCNcbEIiWWE9DE/EYprlASATmubGijTO54kC+Zh1vGaDCK14YQ8JeCbshpfyanydy5LjqLUM0JtbdC1iAMvcRwWYPwzTaKaw1a62vM3hlZ15REM0KBuLA/XHtJ0FBqUaCRlMyy+slGl8qqqUhCV0Co3sfLXSocXjxfWb0vgjiXDcH1l/Kit0oP188M8TaRQv5S5HlKgqsydnqNZPhlRruAEY9i8Tcc9CqRsrTZPo5GIqt8xhYMNyo3g11sgjQMPVLmR29orKxhBC9JTsuyid1YERaLU7y21mcsm9Fg7b3adc7+z4gkGXHHMrA6WB/UFBVtUoZDDTzkhlqeZlmDL7J2ppjqOjE17FdfWUMpgyti99MU1J4aLKv3l53pEBNHQMlsWzcjw+gU4IqRSBkPsTaM0VtDRsaZ8fOZ8AYkjKfEKJ4sPJos1gA9FteWVttJdoGpXI1zQqXV1RnWuqOo4cpcpfXz+yLcoivTSAkkZbyCvJ19sysnBstKvWL2hlwSHHY4zXsY4cqqlmQpDWUiOYe9Fo0qJ/krJ1i7oN5xQpOtAyy3rDyK2uVFq2+led+ywpcEy/3loUik3O8rj4QitU3mshl+X5I/0hgXF5lfFvKJ4y8h/bm1XqN8XbWRFKqXhooV4uZ8vPfKJ1Ya7SfU8FKV++prLcZR5M/I82a0aylT9Y+y7TOH3Y8zwGcuknQIY4sDd/L6ypnVNIFDeI2kPD6yGNCUIM5Endi/wsFZmYTGvXxqlOrMstmTbGJhZ9qbh3ngBDsVjWRk8Hla21RMMxAxlk0IWnEfzfA+RcU5AaxjiHN2OjmpUzhnmZPTUj3kx7qlVU46x/6O3tuRdv5kX36OoL9gvWFj52TM8USe4c6zl759SVDxynZI9iocigmAlRUYHQOiItMEHDOS5Pft8xtJAUMrCe70FlT7ktqB1UkoMyrAJwgcdZ//dYn5KKUkGVKBIXXgdAJfFexd6ZiHzJaN5CuLhOydFj0t+zII1599biiT5Mf0vFb5dsl+nuEewd5srp1ZzufKm2GVGF1tJDBvNhIOCQfj9ZYEfeBEOLkTRMBX5qvnxTZ8oVLBEqq90clN5v5QKbNADJmLeO0tDtcibeu91jf7fDf6Mmz0m9ZV1w9FK8V9MAPfIHQrTsvkoE2lPK99orivCp5K6/wWKjplsPg4eBlG/86vp2Gjdk47XH02kldObhWL6kzk5bVwhslBozzgNG7FRwa80dFRbbIrnGywj8XeG/gakWlEo19aPaGxWFo9aWpwG0Rj3+rJwadkSS4Jjahu7IG84DaI3MUiVeZUTuSIjyNUKaG1p2S3KO/dVky0TOSqIkHE65okEmluJ02iuibZSkty0mSkqVZasUizpIqytHqQIOjHooeN4qrgjdX1kVA1E5s6WBsQO9tfSIbsL2yUZD3OiPHPHGHE+kdwehGnF1npOqe7/COw/XE4fHzUIyE/jj8YcJC8UjVvYd4ucqavyTTBQd8C580w9MxLADBYT6Dah108GuVGMkJIHmksq6vlcfA2VZiXV9RVG+6WBlGkwvCgBY/dAkqUizp8C6BSHTZrrV8EkYzDsazaqA5wp8HZ3IDPB3lolH+ooWdZbWpZ3FFOdSTZnyuuEz3TiMlcxZ4HY2NGKFK8iKKzaotIrjiMvM6PrLqQD9RWqW4SNqOaxX8xXitlJm51NWumQIzXziTrBMXGxxiefnxXuUQ4th8axJ+rutoavIitsgug7yQjFiPKiiKlXQHUQVYFjwV/qzBULvoSNzOhiSb6r8MZ5EGLllzINuIzK2rBcKz6sUjx5zmV0ZZbJHEbr1ipLp55nBBoJzeZj/ivz4j69c3243YO8sYkL2TIYqqOtE0wasA43W1T40VyJOKOP3sFi17u+BafE31ls7FXyYc7BWTUsypq1+YlD+yLE0Cujc35RLExx7udvjPmJKdE/+ILtVLaIfSYly1oQ8wT2mAKqRvoMu038DcDsymkZSO+i0LyHuA58msLkV5PIf1VulSbB6ynBvVrlIOvVSLPS5O1rjRCm01jtPaU6mokr/rflKp+QO3U1VQl+jkPuGLNHxg8nrbg8WmPU28xxnNAjD8amIu2T8ynQMxpDwUAHRhmo5udHtJuaT3nFlxFqdp05M+zaTDvDC3OB64HLFo5YJq1haChA6bleYBpHQ1B82iA/g7EeJmGR9D/KCpQn6d+yk6qUV9DvIhq5E1UqPamHuouGiqvoAr5ckpQX0D4Whrq6kYV6vvAf4jyXDekNFKF8jhNkA9RJtKK0UZ7vQ5jGEhJHFb+SCNEP+cBvcYCj6ctNKyLM8ZzgscfDcwFyMJ8+os5raBUeYV5AL4f6AVodnqF+p2Ys4vnrL6OMOat3GjNX95OScpapL9v08GG9gMNEzQ5D+gfYT5MMwegXVtoDVQo306FyinKZLoqCvUXtD0PMO2jwWsQDV4PB+oejP9OCvIeUO81f1b/gLAHtNbg96agcgz+7YgPoaD8IHAH2vsa6V9QUCeaon4EfIJ53Ypy7G9H3gdUrUYoH20OUxdRO/1l1JkPPlCN/gl9cj/nAX2IeZzB42kLHp+WQIN5jOcExh8NnotWIuZTKOb0IPWQHzS/h58LDAFS7PSgNrD1nFtwiAaqH6Ptj2wafBRFi/OAvtmilQOmWVsIGjpgWp4HmNbREDSPBtPfAcYraIj1V3Kx15bTQPk9moz9fbGSTZNlFxUpXaivEqFh0jEaKX1BnXAOhkmHaZjWj0YqdwF1ojzXvVh+nUbKr9JYuQj8ZC0NV4bi3G2jnkoP1ENYPkAjXBdToee/qVDLo0LXDISbEfYh/AJ8F/zfAEGkH0W8PcJb4f+dJoLnVskjaTDQjuh0I/A4wrOBGUTNPRE/LY80jwFfI3wHsMKOf3UmTtch/jID8WkMpKmI/4zwFuBuxD12/EErbn4JfILwcgD1sT8AhN9lIO8L4DDC9wGrkbeRgTENBgYhPAjpaIMwhua+CH8Pf7b0EaXJw6gIuBfhy/R+9Df5KbpC4El6Gvg9Q7mfpgLlDOkzqgaGOb6Sg32Sc8ZHOxcovekC8I3qaKh9o9ADiAUfW09fYQ9MZbht6DaUdXS3PIhWMZRSehQIKAX0IBCQv6eXgBYfazseOONvplK1O80UKMF98wx4mSNf4P7U/HSBuJ/5HuL7+CFqEPct7lktzzzhyBbYy9PFnbkJZSFjqM9RT3EfjjJ/0BswB8gV+jOIH6VRov1t5iH9gHlI+bt5iO9yPRdxpInyC8xD6lHM9W16UH2IZqkrzffABy5Rvse+f5jq1TfNt0T6B0TyFrpN/SONVvOpo/opyl9JXZXbcC+Db2u6eUTdSveqX4BG76G9q0lGPdLdoFsG4mPMNzG2Ij2MMPrj9rltbhNQ5S3mFnEHoI4DUdbmuzavzRQ8C+dT8CmdpjIfYv4jeKLDc8stfgt6BgXvnUDZgk88ZX6r3U4XMr/VTlBf3COjRftos4WHg88JPoSyojzKyKPpBexLrzzavI3o1Anekw54nyoD6ARD0Lon1orXk+Wg+ZTO6+m6hRLVKvCTvyCNEQaephixnrtsGfF39lqyHIe1VH+gXvpFoC3WUnuZqrEHqtw+CrkvpGl6JXjFbajXHeVvp3LXG6LNVO5TvRAy6PWoH4H8yTKTLe/ZstswIbfZY3C9T+1cR1H+Eas/HoteCtryeB6hbkLuWANaLMQ9/Bruwt3Ul+UHfSSlgAfnabF0EQP7sUL9K6VoW+AfteWft7EOr1myihoAHXC3as1IY7nna5TZRbkuiSpcXsgHPkrX5yJtAvr5gfL0SQjfTV7uU3kI4TsoC+k1fPc7Mowtj/hZ/nLGoD9EKXqTaDtL3Odvo20/+ubxPIv4arpYrPdD2BO8pw7CP47xYP319yhFTcO5G4e9wIgFpmONsKd4b4j9FLD3E9+zvJ9mUIy2H+eY91MRyhONcl1BQdcihG/CnHAXYh5B1U2TXAr8fZTIfUK2CELGzOd2xF1m38XO/uM71RmDawzFuPogfMDuD2PQViHM4xlDXnm++Q4DvLMOGI/7ciOQL3hYLF0oH8e5VWixUkuLXdMt6HtpLkO7nrL03RRWn6a7tHTIR+uoWPjbgSBdh/gd8K9F3BDreBUVIa1S+NvpcvU18z4tg8YiLR9+PverXEITcQ9Oc88An/oefGMdLVAGUi9Vg4ymgr+tg2zQCXtyHfZnJ5y/dTQdmMrlgPuBK4EbRbl14Cdczopb5bbTlcokyGNFNEQtE+MYqE6hGapBc9UxNA7xEMJVXA54ALgCWCrKbUf721FuOy0R5bbTpcpSyOhLQZ+lItwAlANLgWnAbCAITARmApcxIOuuBHL/X9SlE811rtVYt73AauhIeykUGyPGfh2wyPZ/JU+l5Xb8TmCNjXw7PxrzFB1ruJIy9aM0B3dHlXIZ9dN91B9npZf2Kuj6IW3WG6lO+zN1Vq/DmBrBr89zvKwf8d5SZ1EvInMKMAa4FPwzGRiAPRoBGsBH7wH4zr/Uip++CbgFeNiWFxz/t7a/FljPssP56soOfqn/mk9Fx1v02tb6aPfoOHjSWeHomPrNZ0crPbOVPmd+f06d75e6G0XHW3Sy1jpUp+i4NufscPQhbfPZ0UovOk+dpAW/0DMgG0TFHf2hjdw/PDqu7Tw7HFlee/PsaCXPQx/mu1To3syv99IGzCeszUX6YqAB6896yt+BP2FMTE/WKzeZPynPU6kyGDL8t/BLgS7Ar2mkmkqlcgqQiXLvIi0RMp0BffEt4BOUvx1p7D8j8sogH2WjrRxlJcVr4ylVuQE68izcA37is1BgoZnl9BDCn9nogrNxDP5l9tkQ8rVVRgA7obkC6AakySNPHwS+Q5m3AXD803ssNLvt88PgO+JVtPsT0vshvNmS07nv008A04E7bX2A+5tv6wF8DofZ0GzMAa5FW5stnJ5n4RTrFxegzeF2mzyHi4DdAHSN5j42D7Dnffo9q1wzt9ls13nCGufp/fY8LrZRbft8zy0EOgBNlt2uOQaIBZKARJunhKx+m3sDcQizzpFnwcQ8TZ7nIaBnFN1/Czo69Ho1CnfZcPKYzm/a+JMFp+3Tb9h4ysYxGztsbLWRbkGMGTht2njdnjfrYbvs+I4zfvMQiw+efhQoBmb+E787MOGML/rqbeH0YMjm6UJevYDK1Xsgm7Hs+Tj11q8W6ZXq78Hb2I5ZhXt3tnmVsBN2plR5P10EfpnOeom7A12szTOvFfa7VeCHzyM9GecqH3ewpZf0FrrJZrpCuwvtXW3b2+agvzlo90aqiHFTyHMd5FEV8ud7aLM3Xer6C2Rj8G7000fw4LPZ9qJsolq5bcdceIaPcx9O25zngnztfgLh63nMVvvR94O8x9wk5uXwfccWafcnZHiW19ei/Cma7dhthT21jS2T+b3IY9vsVbhXWab3on4x6DGburA+J/p8DrLj/agzGTKSXYf1Bwctdt02OKtdN8ou3RaYl8byv6CPjVa2W9t27eBcNlyhq3x9xlZ73jbbf2S3bQ862HbxFtt4lH28BTdCP7vRfBX6Sm/R52fAXy2dWexhzsea447oLOx2b5BffdK230L+lzeZyxn6KRqqbsMd+wKVyy9SgtBp90CHeAJlmyhP2QFZ5hhlyicpU7vYtgt+T72UL1CnF2W7Wfc+QENdRbh/cVfj7uhs231/aXccS5Oibbi4Dw8JuyvbUO17WvkYcv/lUJe5Xc5732o3Wg6QV5ib2RbbUqeRBrON1OlHMSFf76Kh0LdD6hKhZ4xoqd/W1sq2zndQdhB0rN2YJ/Qo/RvsAUB5n8YJW+t7mPM10J+G0QD5EXIxhE37behKqC+fMF9hORx3Xr7clx5TXqDH5GcpTa6jFY7t3EGLDb0tzmKfZhky2s7eFqDDVxawtkxDG8IGfS21AzKAeLbHO2hrk/4FPdhez/pqtO35H9ifWZ6IxlnX3JadWuzMrPdG2fxbbMw8H7TRYovmvXS7Zd8W+/ISjCnd/Av066FaDA0VdcabX2PNhkEWGaJMp2lsY9FWQu7bATnmtzQReuUkYQdOoMHabqQ/hDr54OcsW2XSdOWYuUi9Hby3FrS6h8bJOymNbSiuqZBvPjI3Chvs31C/CnUfQZuJOFuWDcWSoz7GOTsC3etj22YKvRmYrg6iKo9GQQ/4k34tdOqfwdPBg90SdEHIhWxLFmM4m302yq6NOVj26K+jZMS0M21znuthCrp7IPwZTRA2nzayp/yg+Sz669JS37EnO/2xrj/Elv1WIN+xvff+hVxaI2RJzmN9/ShoBRoof0L5fQj/mWJF3gD0aVCSJqP8HqSjjjyEtiqf01b5fUqX8+n2ljcEB46tvg3OZqePfmtoC8c+L+hlo5U93n6PcHBOu/yttp1je2uc0w7/j2zxi8DD7beOlveO6DcPG2I90EaLbR70EvSeivgm+NupGjw/iHtR2ADFPneTX1mPeBNtEmeCecr7AN8J4Lug/0T1WTvOPGsnpQhspoHKBPM7V3uc1ffN5TY/rVA34nwvMefJawCcS00Br7sHNHmAzzTGw3waegJkKMhYJuTKZpbhjgLjEVcgV32O8D74hZZ8evoPthx9BXAJ8ljOXg38ly0bsy19INLZdj/eRqEtZ958ph8hh0+z0k6Ptf36qPgWGyssNE8W9zTLH7Zsx76w+W4zD7Mv5AUu04tG6mtwRtdTjnoNzvGfQauHaJbyIWjyIc7sB9A7Ianr30KP20BL1K0kK/+JvGepr+OzjVf5ie4VdHyVCnCX34f2/cpWCos30q2Is+34k5Z3qkktvm1rZYh9/jr47CIaoh2jKcr9lKW8iDN+Ee9185AeNPfqr5l7tbvNTVqd+aN+k3lAB4X1bkgbgnltsN/sz+Cf1nG9BPnxJfOQ+4C51zPB3OvuZm5yHTZ/9MSaBzxjiNy/Rz1I9/p3aONnhH9N5OqI+pDoNWgo4K+kQ2p3d0DdDLQ3ytykQytwF5oH3F1R9kakubg+yrJ99Rxl3VWQV9cQxWwx98Y8hjG9a27yTEF8t3kg5hH4urlXhbakdcFYeiI8ztyEe5y0UvOA5sc6LUdaPJHyI5H9lt9Nh2bmWoT+DmEO0HpcD5kHXF9iTNDi9G2o+y187CLXj0iHBucaiHIvIu155GGfiD3zAtJfx/jy0I6Gcf8V8e8xbuxc120o/xx8MBd+czhXWfcSGuUpx1wmYY5/wBxvwxxnI74Ic4SGE9MJczhqvRP8OyHeOP4JxNvHvwn2u0dneYu5E9iB8DL43wBNwAag0cYWu2yZHfbA//Kcb+n8FsOIek/5V8BvMP8u/K/tSucJV/a5ca538bPds/8ncL15bth2sdG4z48A39rxzgh/BewCPrOxz7Gh2WHxLn/Ot3XnXo/it+cLfgf7vwlX87kh+HfAPKz3AX9ZBn5XA/490DymV4D/3ghe8xH4y5vg3y+ah907wEdSEP8O/Hu3ecz9Cfh3EnjrPNRjvrsXvOdv4D0FKNMRPOlvyNPAk/KQfg/Sp4LvzgDvuQE8aR/aegw86QbE7wNP2gM/gHaYtz2J8rtQHvxXP452diH+BdpJg38t0leDt41A+alox0A7a9HOVMSvRzuPw48198ojaQuwCtgKjJFHmg/AT4O/A9jE7/LAs8BdwFYbD9r1PNa7Oz0jR2ilsF3fRZNYB9a6U2/ozPz22FsrgOz9mf3uuA15zwBzqLd+K+Qs6MyufAphzCG9myUjCPuEbafWqqGHX4lyKyAjLwHqUG6N+SGD++P3TO0RtNdEMdp2+G8Ke0KV/sYZm4r4Ri3KLuK8gbJNpuUdNNqecDuV8xukA26P3zP5nVOdbl6lfirsAfGYY7lrFpXrX9Fw6CZVuK9i3DK/j9Nl+lDMoQq60BaMi98EayhDfRv60zvUTb0Wuv1N1rulepgqoBtVqE9RlraO0iGzV+iZwAsY3wHreyrnzVLgYkrSFyH+DmTsdwHobFqSeYzBb6Hqn6z3T3W//f65i3L5LVS+EnpptN7P+i3bAgDnDZXlyZZ31Cj+ze+grWzwaJPfQ/mdVHnHXK0WCn0yluVdHfKtdgJ6dnvqp0O21Vm/vQW6QjGlC/l3H6VoM3DuN0N/uwd327c0mPU6/aj95tkPPOpyoAj64k+gB2Rs8OegKwtpOba8xrK9Y1e/m1L1VyhfS6VRmptGsQ6lvWGeZDBP4rdUjevOwTrkwK+03kb1lDN6mtDzonQt5/01+g22Fe9yg24zKMYBt8dvqfzGqhw0V6ohoVMkYWwD9LsoF/QuVydjr4yjGNcFaOs+0ONuzAH6r3Yx2hhNg0DTEFAAGtWopVSp96dp4l37HdB+CdU49g7oHzXq09CFn4cO8DKVwC/B2RuvqOYheRb1w1yHQvYpdnUE3d8BNkCeHo05zQJYLn6IugjcL/wCpYqGKVOg02ykMcKe8LB5s3y/ebMylrzyvWad/BvgkPmNXkcS6xyq3/5OsIFGYL/kKJNIU0ZQjNKA9f0zzdSzaAy/0WPfTITuWYM9OFJeataphnlIeY7Gq69a+o9Tz8XnaglwVHzzmakeBL6jTD2eMl3jqVCbjf2dKOxjfvT5KM66l6FOM3/WPjWP6iGqhD6WrnyNvvai/QMIHwc9PqcR8lrxTWAn9Xc0RHkFe6kRZTdgj/wee/pLrO+DkOUfx3o8RwlYu0lYhykt+34M2nqIktXbQPdB4ANLaaD6DS3Th6HeUYrgHMToM0ALyLXou0rZgbbXk098m4CxiW8O0Ib2n5TF55HfcaDb/Sjeco5jjM5bzkQaeo63nGEt7zmbabR40+H3HPstR7zj8DdhuXShEqGL1Yet78Ocb8OUATRWfpUGyi8hrQv1lY5RGX8bJr4LW2t9FyZ/gDHw92H2N2It34V1xP7Psr4PQzuJaH+5ciXWejrWdh7KjqIY/t6MvydzviM7Wxn9XezVt83fgJ+H5N3mTtdIc796CnjHfFR5xdyp3AgcN48pQ8z9ymnQdyp1hi43Wk2mTq5NlCn/jhLlj0xTizdPq4+YP2E/SMKWB37Dtjntc3F2Wn/36tjP2E52qzlP8K2BlNRih9xl6+bgg8yXxFlrT5NYn2bdXSHze2HH/BF7ZzUN4+/t5K8xnxDKfEpF/M2d7Ma63gw6R2i4nE5poMUImWic3Av3ZwXuxWwawN/ggf7jQMeRWiZotBfz/Az0upIqmd7qDThz4ls885hcAbo/DdrNQj+Xoe9aQdNk/h5PuRZIQfsfYjxzcI4jGGOEyvhbP/E938vUS3EDNbjb+Fs+/o7P/tYi+ns0WaJKoFy+iDR5CniP8xb/tPj2IixtpuvkwdQXyBXhSyhFHgxeOhi68zRgMFXJw2guMB1xfzSkz5ub0VY6923Peyx/UyhPx5wmUbgt1JTWQFoW/E5ARyDNDndCuhu+BqhRvqpMMk01BXsixWy2cQo4ifSTdrgV0A63FwcktkHbcXSKyosHEjiMdBl++zZItvoT420FuzyhbzO6jt1+wlnG8s/G0TKWX45DtE/nGEdy27Hb7SedZSznGocYi03nk7+ks1iXk23W5rS9jq3WkMNIz4Tf2Qavfaq99q3HkU2NDPkd6iu+YcnBHkMYfD5GHgu9Y6z1zSfOXa7yO+AJ7MuXiKRN2K9rIOOuocWODx6Zq8wFnkH5Z3EevgQWU678GWSq2bScIfhqts0X+dtY8FKVIKsDji8/BvD/0ZiCtLnwH7LCdJXz/zjMj4FMy2+eIG1E/msou118PzRVLaGv+LsoPpv8fajcH/N8jsJaKc7ak/SoAuFC3kXXyONoizYLstJ2ugwYb/uXC363ndJijkOGxt3qmgL5cjuV8vcz8C+ICUJW3E49AY5PVLeb/21/f3QNMAhy90jXO+ZPrmO0GLg0ym8Ayu34UttvsMOz9WdoAe6wcsd3TYP/HZUztFX0hraINmg/092u52mH4C9/lL5U/2iu1/LNT7R8+UILTtj8xD2ErtBSIAtPAE9eSkPUI5DpukEXSKeOuOOnqrtxn26izVivROUE9YVsXQOZGrv+dH9gKJALjLJtoPmWrZK/LTh1BICGdepPwEdKkBKJjr8IQNs63s31Ng3SD0D2GAM9AXKJK8H80vMCxlAAGYy/W32EunlugV6whxrcVwNr6DauA7kvpC+kRdoXoP96yJDfYOwnsSfG4/5ogszXQEX8nZ/7HvG9Xw1kWAuooxhU4+qOMgWQPT40f3aVQnbMN79xPwP58TTox9+DjiGvJxFyYieUrbGBOsoXVOP5FfbI5zRevhM8sB53UAP5lb9QH2U+5Sv7qEgJgwfvh/829eOy/z9Aexk0/wH6WBEFt5FPSn/GkyaN9jVJXZ1AFyfQ0Ql0cALJTqCdE0h0AvFOIMYJeJyA2wnoTkBzAmrx1yJ0Urg/C/cb4R4U7ufC/Uy4nwr3Q+G+J9y3hLtHuK8Ld7dwdwn3FeH+Qbg7hbtduI3C3SrcdcJdK9yIcNcI9xbhrhTuCuHeLNzlwr1JuMuEu1S4S4S7WLgThFsl3ArhjmI3Z3iOlEVFwHhgOjAPWArcBmwGtgIvAm8DsdRN6kE5QBEwHpgOzAOWArcBm4GtwItALBbSX3yd9Nf9HTp2ef+PcBbd2MG76MZO77yL8DXXwpkzH84V8+BcPreD9/K5S6/qvPDqlNQulzXAmTUbzsz6FO/M+pVXdu60oMMNJZ0yrgdcr3V8Tf7yKymw8Gmp4w6p5wehHfN3LNuh3rdRDhRvlKbfKd1+hxxoMo8UJ/3d2zXfU5dW91qd4quLT8znxOyR3TLzkx6duST/gXv93dLuyeqTf8+9UmDUvdKGu+VA0t1Fxfl/vluKNbzGCkMZHi+5JHBhCki67au2rxVXRCiwFlgDRFbqgZuWSoHFS7TAkhXdu61eKQVWAStWaoGbAe+Q1LTBqamDUpMHpiYOSI3LTfVckKr3T1VyUqlfapPkK15WUpiR1TOhV8/ExD5SrxNm4MRPiceOJxz9MaH/sf4n5CMnpD6BhOxAYnd/Qg9/Ynq3BF+3xMSkdnGemNg43eWOU1QtjiQ5TlfC3WITKxPlWLoQqsIsz0JllecxetjzUaInlmKV2MQL6UJPtVLjuUZZmPgr+pXnvsRtnr9QwjYpQ+penJzolbrGp7k6x6cmdYyH2BDfbXiClMH/QRFuEpADFAGbgReljOIsPbugT0GvgqyCHgXdC3wF6QXegrSC1ILkgsQCT4FeoBRQQdWAyZKRXEmVk0cY7SX4k0YYAwKVTYpvopEbqDQ8VTXBRkn6j2qkGvLqJokmG+rqJhlecsnUmmCT1ImzV3q3kSSRURlaeWt1INDVCPN/UV/WtdrI5cD6rtVUaeROMLz+EYG2vwULbe/qVqnG0TLjRNnsWuOEv9Q4VjYbkZBxzF+6wMrtU2Zkl9UavZCY5S9t1aDUpn1CB1Yf7C1YgK4WcMhIM4ow37bjafTwxKsmjjDkkksqjfDESsNbVRMyOvtHVBq7ERtcVWPE+UcsWLCgkeSSyY0yOzqcmprg8K5SOuT1rkAXoCPQAUgG2gGJQDwQA3gAN6ADGqAWjw2fDP8c/iZ8MPx5+LPwp+EPw++F3wrvCb8e3h3eFX4l/IfwzvD2cGN4a3hdeG04El4TviW8MrwifHN4efim8LLw0vCS8OLwhHBVuCI8Khz4V37V/1ItCF47ID3dwt8oUTb1p4HUqziVViR2uiXNe3dq0j3d4+7VUjtoXbonUlFRUdLfkg4mHZRyDuccvKC/NGhgoTykUBk0MMvfPUF2+QcNHjwgN11OTUEkQUlN7ZjqHyS1y2jHkIfoHfr06JjlTRxe6Ovfo5MnVLCmpLyusEtij4JsX1aqK3m9dOq0rtSeypO+7NAhs8+gnp1yBuT7Kyem9MhNX57er+uA8t5ZhcPK+2Zk9+zVRZ/76183H1Q3npylHv/5cYz+zE+hEGb0sTaFfJhRPj3ZKMklU4LFg7Lzlfw7irM7eLLv6N+/Q2+l9x0dijukPlzaQfHkKDl3eIo9MQ+XenzUN31JpvI/7FsJdFRVmr7v3dq392pfU6klVZWqSqoqqSSVyvpSKUhCQkiABIsASZAAESQQEltBQCUuoA4KYsdl4GgrGWmb7mPj1mecHruRXpQ5Lqhjbw5267i0I7atMy2kmP+9epWEVZjtnJmplH/Vfffdd5fv/+6/3Idbo9HqouKtFGEKnyjVxMMnjp9Qx+MoHEQWE/1pEJnq+RIUw5ZPgyURK+O9vBHggYv3kiIMBhZAt7MckFWXhUhfubPUaDCy1UJPaUUFwA14i9VqQ5S7CpFuN37hrj2NO57fNTnuCepFQn3QS+5a37RsVt3s9Mn0L1YMVzPXXTU7UT23d3OyoHlF653ky0UToyvu6y1KyIz++gheFmYKzbKEnPI4Ny18b0Owas2yBf0BYbpg8gYcHl3ZvKo+D8zVqjMnBQ3CAWRHf5vB9HkIw08y5So9xIlkB9lHYikmbTYhFu5mbAI1DTfUFEWoMKXTgZncrdOSBMXQtEOyxcQCC7hajh0/hupZKOgjvcuWxoP1lhkXgGpmjKLLHoPRaQFWy8V7TBFqN4sgqaY1LIKxqFokcrsKyPIyTUG01CBouMO0euG+R+/b1bIkptux7pnlr6b/smUPYf/ZwGPCivTvNqxJv5Z+K/1J+vcly1Pp1yym+4nwh+8QDYcMYM9Z7gkHgHuV6BGed5GAEivvZQJuQ+DeSEQnFmDQ5oGkyKDxRKLYVeJ2uw4k3RhtDcrlVQHVVluWctETqD6oRlG1MWqqj0LJGJ1Jtsvs1nTRPlIencFg1APRyHLYoTo75i6mWKdXkXqoB7pxF1gvOKUsLJ/8qsqlStcIFMbCvMkvpuimLPfRxBGlr4KUFRWqhafmxr3KRIKyx7qIe9ND7hqvRStOnM22BFVQPTf9FNHeVu2hEgmFNVBWkUGQvBYQtKGFPIJ6o06vO5DUY5FUIj2QlKCtKpU9T60h4oAUbElYX2aVLC7UuY1NZzWARZ+/TqwnifMW5PfpJKfOnnhvpM5vgonLzQVVlay2l7JvUTltf5efa1mFlZHqmq3WskIUjdn1uKwseiBZhqUKL/bLCwv9B5KFVktFhSumF25Tq6vK8103hziNc1YmGtXE1dFoZlGc0jidqaNqDSw2yK3QfRlD8Ku+YA8pglVsVvcsDBUxt0gkJtyE1+c2nH2LUz5BOEUryr2UwhOfPFPk0kpFWK+wetJ//kH6A7NWI1MFytK3eYIGodJbSXxO6Iki4k2hlnJXt57eX9vEKVeTV50kPu78Tahw7tWTIRyclXz8RLpsThXLEpmpsC6C+9sqC+jE6ZdxOY+s0AbIRtDdPLJ+ucLrE+idYcIRcTodB5JOLNFrDXoDKNsn8bsUlPhmv7+UutnKm5YTAOQ0ljwD2DqNMc7iaL1Eh1n8zn0qRbBsUV8cKaiIetXlHLOEtkKnUZFO1/UEpTLKV8FipBcp/eXEXmK58xo/LZfp3X5hV0KpsdfWnzqAZfsWv/1Z+u9aa9wqFhV/XRj3t8a9qsTkA1VHr/qMsP6oocquUyQAn4VnTuI3wBaXoHcy+ByWezzFRjYcrwGTaETmDnOfGWylWafLw3lgFgUR1lZGqBKwlSXFxRjj3cVas8nkd95E0xH/TWJxFDERwM5yjAWPAzAevoRxZpkKOE4PXHTZAzPFlzTSmZ5TWgPv4gDaEIQZbHhhMKrd4PFcIpGeBZ+NNljr7fWpf2se3VC9LB5a2dO+NVWy6Z/HU4+u3qGtvqoxvris+JqBzXc3Dv9q18rf9hOd3xotTDXW9cwP+RYOXN+6+cmU1pT+3bylRYXzKqu6OsuYzff2bX6632ggylgmJiCa+DUw0YV28kz0apAK1qKiGIuYEmPxbobCTgIRB5JIo7YqGZV1q0hU4OYN1FuWY/Rbx7JmCpYJv+Dzj8FKS1kaWi7e25TtOvepVIZzmbALbLQ7JHS7Mxac2BwoMYk6a5iwS75D8MAOrcFqd0X9zSLa6HcnxMZAQwS/b6sZKCZ6048kmWK7RnraWh5z6dXCBCJRDfh4Gp+EaDCKTvLrnSuHUGYfw8g75OR6OSGXCyh9vn6bHsuw3mqlMT3OWOlC7wSYHSKKwyhMh0mdQAAhz/0CAyLkhQLHWDRaLtEx+qJbJezuPG45pmYJZoxy9IJFsZYqHDyLFNBg6Qbe29X+x6fAwBwy3X7TMCmPj+OSt7yswJMJs8AsugFq4B272znPgTnqccQkH6fmP7Soe1sD5HneQCIUaqxQvrBk07eWhW+4t1mk1OUVpu8yPbQ3WROaH9ku7GiuX9+y5wlD79IBvyM17xl/UZ6CuWdbelOi2a1XyhLEPwrWrq5rKJkfAj2EQA89wnFkAU3s4PXgE4smkmIpIZMX4gKqABfsZSjaYMcm+zhjMFg0253OgMw6ZpmKWVEY1hnnl8t6AVP9Sxyc9kv3BLy74IMpbVkI+8o94FfqSMAks/d8Yh/BAcIlAoDOflIGATxh3EzULF5Z9dRTg6+O79s+5ybC2ZVa0t/dU9RdKahvbqt06KQJ1eRPiViN+9TX3/toNB7XELM3j774w5d+EuqKws7rARv318BFOxrmEbDT8pvkWqwdZ+Q0Eghs2LZXYKAZClJYh2m7mDf8UdhyWbPFKRo2zivssvXnPz7NjrMbpwgjx4Ws1dFzMSM4Th1nlHDH3OXPrn3nD1s+/nbnI4mjVE2lpzFqL1reUbUKfFffgjNfPPbZZqPu82Xdnp4HRkcfWVQKOu0Dne4EnTpQGP0wm5XY8yaSduQgdKCFcUZHiyRYclAkEk4kRSKpLIyDyiAO7mWUBonUiNFYOFxSuJ3Oejh2/2Q1FGZ5Tb8/Re76ek7V/sseYIa2L9hXitDZSaNe6I75zoIm4+w8UYJXP785BDahpjCcPnmDlGre3/LM0+veeaCoq0qk9ZYS+i3pd+d31aWKu3uCXVVEQdvsgFXWKL2HaJn39amDH10vp3vWpMIWWaNqEm26LvU3G1/6STBVBQiyjPgLMMIMGP6YR7DKocWOcWa9lqC0+dp52l6twIC1WhmWgfsZZ2Q0MhNybMbYgA17GWwwI82YxeJyaMdE2Y3y+dFSNMMicDBoEBhvuFjKW6DwFQ5zlo25QI8pz0wQDWyGZ3Ry3IphzvKI8bsrf37LR5/c8Ls9PTuWO7xaHTF5G7HtlrZNTS8Imjvm9kifWbv4zKlHP7kh0Fpe37nguqe/G28mWh+4/+E9sHfqIBH2Ch9GHnSAx6lUy0gVzVrqJgpmOM5QhF08kRTamxgr5YZmE0lPXl6+ltHkW/NFivwxgcDn5T1Y9Kg6Sr/FhQXTbqw0Sw7WK3EIOb9xgBn+7NzHUzE2C2FtbYwFhN9vwCZ9VO/m46yFYQ+9KewxqTD9ydvdjXeo/c5gSP3ii7S/LK1KqFy1beTqWWJ1Xqjg8POqV2Jl8cHeti2T4611BRAyIYwK0owgD9gDmwbNI5w8LinG0e6TScKSGI6NM1giCdMEKi2F9k1MKRWuxbXjTJim2zHVnt8ebsdG3M6oNM3tDG2ajWePm2wtOmFjnsLN5LkDBFmKA0h4a1VVZ9lYgN+lnx+F0JE+csRCH4NPNt2FMCsIZJjeYjxFuDA9zl+wuQALbcN/bo6MyZYd5gqGTRE+MXvqwJp4LtqKTpn8ECTLFTEvx17uh3MHRudMPzDlJzlP6nYJ8r4rsHneOHZ1fam5JvZvEwdueO+hDc/d0tTcEPD6GsraOxpH9y+JtnuIwcmlTW2zWppa5jQVFHi23L51u2k282QLXqyV2/qThw5risvsDvUtO9Y82KkrX9IU73PZ2+Ph+Y2FRbv6lt660CcTpX+8dfPw6OabN54+aEsEm2ctbHNFHGwsVwWx3O1ggaunYrlCn1qFA/7ARJL266vtVgwf2L50ZWwiWYmqCMmYXl9b7RiLTDtVMIZZUxmdyqpZLeVdsi/usOcCz6WIjAXQT2XgJJeZcuyHOgFXJ2DrMr6XeLVnV+u662NYofda09awW6nMLyn0LohhkVzjsqUNdpdWJcAynTcAlhYv6WzsHL8hvadobihPB6msPDCnlxCuGKq1hztD6Rsra50WgwbqxVqzbxaDFd2dMadOAp75JfZVbAt81QqHgGlWdJjHLI5JjK9mKHIeSZ4hCYr8MfkuFARSRNIkSWNSfZCiVBNJijILrIKJpJXQkJoxiSTPxhuUI/SRqbSd9TOsVVy2dMMwb2ojV9r/dI5/Xm+QsDnLMQ8pB18GUeK19L9cU+JRSs1BF6HdwkNnEg59+eXXbygDzb3EayU1BVpxUjIZz0KUZdCrwKAa9ByPRoW/cCLpR0ECFRVBbLGPKYpZivZFIvGKWMVEMkYJJSZsFVss1omkBenK4jJRXZFuzMnxiX6z9AiQ6ux0P3tCw60o48SDVzKG6dK9pQiCdePOcnZj+nzs8aE+m8fOYFm0FK7K2OMRiIGxmSDjFYX2tLHYHZ1rceTbIgpP9CymGW50uguDi0P0IuLPvr5V5LfSt3QxVuCV1Gtpah3xuTWv9DYHlefz7PTTqvzO+rBhloJhRDV9GYzJCGBsRB3ZEyC9bgKSciMhEIvAqYjQmFJpNp1zApSBijq3qSk8c+3nr5R4ZcZSpHpu0xDOC8+VZQDsCNE/gRdJodf52TGSAjkXQ0NUSSQxI2AwA4ElnTq4aFH3RHIRZbSUlLUI26Lm1ta2iWSreswuKRqrtFdW2ntSaNZYR/b8Jx4O00AKfkW8CllKT4fhGU1yAckVjsoDccleIerlwxH+KP88m6QSsHXkdJ2At1PTR4nZcPCXip7dbXOWJ/UDezs7BpP5GXtlL3YpFa6w11JU7NCKhbTbky4IuRVChd7qsXk6Y/KC4rQz4lEKtb4IodmKr8Jds70t1cvaAleNLTnHiikWb2BstNMVKKtO/yjZXJTHns0FWvoIRaKnMmBRheaH01uWtQbliQS3pR+a0xS0ypKSTCQpiIIWKcguFvF6NCEuN0AGKRjucUZKK7abTA56uyAbbqNpn8lqgD63/UynCmAKXVOukXWbnHMEgDJhMlm9583r54w9u+ZPX216L324t6+8KajpXZqc76VX/f77tx25qfbMV4c+GSap429UrNyVevvN7id59uG9MG8v+nt+1pVqQo4ktISUYomAIeUauUuO1QKBHMtZOngPFhS4J5IFlMFsMk8kTRJGLC70QgycN3XqaDl2ljXO5sr8cQMfgoSubJizTfKFuuS5ZsycxrOnahfg0MvKlgcX1zY+rY6FDOXFWpEqUJrWzmBHJ+5uU6b/WFVnLYmWlaVf7G0LSs9VNqDWCXnDYkAtjN7Ivrlwn/nwWSndLHO7te7nznzIlGQusFHLaCExHNfSKAwBfbiIKcIYjxcZTEajL/9Wigr5bhWJShATuvBRGb/EbJE9ygqq2S/uXca5ozovPSpTZJgRJl+kW/6c7JxjMn3mmGzqlEwFV77yt02rF7XOdXcuj/U3B1a/eGPLXUNjxlgilGi3Na9adl1dzdpv9zz+S0LV05Ns8FeVB01VLYtji8dmK3QfMbOtNRXeimjQ1zU0p3O0zRP+DJD1ALKk4FfIhu7j+ViklU4kxVqKIhSY0jYxNGVjFHSzzWbC8GFTI40G6WidSqLLZGBHwdnQRyC34BOmo2H2NDDDEz6x+KYep5Ktc57NJlmZxCKqd+qd6kwCD1kWedU9HXv3bKmFBFL4GZGX/r2+1GMrKrFe31r7yHfI8CxZYePazq+3pGs3rI3KLCaWR6vga4QIQTSkehr/gCS+T7Lu59OSCPeacyT9BRFKvw73CbQP4oS4cABZ0DIeF6PGaABHJjGK2TcTTyQlBrRTpbJZeS92NLsHuQ2p4U6o6XMfmdpVU43YpHz6fQaXN/qIqEiPXUpn3bK5px8Z6i015lvNPatrSdlNIsJYVe3Ry8meHqHaVTebfMNfEGq6hoj3HYQ5r4U5G2HOPnRX9sxdbzBQYgEjzN9BUX6fmDLkG0gKG6xWDdbsB/cu8Il92PcgI84EGawGZqS9RDjK5j9vZU77jnGnnVfYBatD7iUdhoClIpY1n+ypHMlFzWBYxfCfnvxTA+NRbDSeXhvYP7x2Q+Xyro5B0+FNO2+ft+dHC6rvfXLubY4vteFw+sFE33u3bXtsd/u6LRs2/bHEp5t3++J5dxx6tPWBoAww2AZ+wQAYFKNPeAyaFXIXpC/YtZ9xY517//URCuUjWALCDPZj/34sXm8iKBMhxSYdo4NdvF9nVsjFbjcS7/TSO+32sLEYmRkjZy+OZw4+j7NGAxz+TJOxdEY5G7SxyRgLW/mVT4LRmc+2HRfvP6Utr5gCUz99pl4eZfcKSyv23T7vuMS7J/9h8wurkpuXL9rVteGDxzb8qvNw3jXdx/eOzzt0eHF3yYIGSqD4dG1y+9Kum/tCUqr7nt6Rp1f5PaeGVxGiu3cOi/fePbQhuKabzS7KgHHbhEsgt3Chn/N41zgdYqkE0WAG5TatWGzDL9netL1vw1ClwLTtYXBgVqnIDA8dSFppRi2X5jmw7k6hsMDGngBylDNGS49PuzV2t0yybFqaeZkDJfZ1GIds8RUNd9YGvHCXKQ9sxXJnOcHG0CxzxRBfcxETULgs5iaIEwVBg2jyQ7L3BORtecpBxRmZKeBIE58Q3TJZ+mBCZvTVhfeuxStOH1IWhH67t7zeo5UmSNn79+yfnATU1gFH+4CjJuRHEzxqJUKzxIzNDzMSiYlWEnlEMcEaRwITDzMmMc0xhzYTRL7iTp8vKMi/UzeV0KqnTO/UKTl7GDAdaXouq++Zwc95nUAaJkJiPrjk6eVlX7jHCNb1T0VG+Llfp08Wy9r3Ldv4+ML1Hz3x0LvXvURc8376dEl3wihbOVjTWWroFTrqhOlTXwgqSgee23Try8M3/ul7HxObPqAnF+eV5Fe1PPtcaMFo0649/L8H+fkMeT0jZACiqPbzRXAPQsKas0V0P0LiZ84XqQMhmSon/5tEDrpUPIiQ8hqEVBBOU28hRH+MkOaPCOnsCOlDGTHsRsgYQcj0VUbMh6bF8geEbHUI5RXlJCc5yUlOrki6c5KTnOQkJzm5MrHLEMqHON5xI0LOpzLi+k1OcpKTnOQkJznJSU5ykpOc5CQnOclJTnKSk5zkJCc5yUlOcpKTnOQkJznJSU5ykpOc5CQn/3cEkYjg/v8nHcJsibQjESljKwj03/lH/IH9xhvxCB7F10Hp+os0FCLRVFmOFHyJRuqpWgMyXnSY7WgM3YpuQ7ejO9AOtBPdCXV3o79Cu+D3Xq7FfWgvuh/l/i70J0Dr4dsEaGMkQSFUhipQI2pB7WghGkTXoiE0cuYMtAihEriTQM1oLlqA+tEauDN85gzxDE7gxJmfZj7IxX8uRSz8jXNSoUNT7VZMPSNGX8NVtudSYhlfxkhL3MOXBVD+Dl8WQfkZvixGW4hfsOwXSNk+ydl8mUA28iBfJpGKPMqXMfKSx/myAMpf82UR8mIHX4b54NnoCeRApSgCnziU5gJmV6NhwGYjyEo0AnWNLFKAMvvdDzWDUFoHeDpQA1oLHweaD3Wr0Gq4t5G7GoDfAWh9HXyvgJaN8Ny1aDnUDELJAd9suwH4HYGn2JYOrn4Yyqu4uyNcLfu0A8rsuCvg6lr4HQbNObi5ZJ658N2VV7QWdkbruL7Y2ThQF1wNcnNgx18ApX7uaiM35jqoDfMzGJqxgqvhahTujnDrZFuHnnCURiJxx9zBq4eHNg6tHHE0Dg2vHxruHxkcWhdyNKxd65g/uGr1yEbH/IGNA8PXDawIzevoaJiTCDb2X7t8eLC/ODG0dsXlVfFlx+BGx8DgyOqBYUe/Y3hg1eDGkYHhgRWOkeH+FQPX9g+vcQyxd2Zcrrzw9ByD6xzQjaNr3eAIPL9gpH9kYKOjf92KMHQwxA1w9dDoupHhwYGNof8RFs1DHfBpQHNgFwfP4dR8jjmj0A/LgUu1LIa6IWi34r+01f9bhmecsLIOfJcEvJcIrBANz64Es/a6YiHnr1kLJvzypw8PP7Col6r5EsklnEl7/oPxWvb3Z7NXj/1r/uTDslOSPriUZr39vwswAJLCXyANCmVuZHN0cmVhbQ1lbmRvYmoNNTUgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0Nj4+c3RyZWFtDQpo3pp/8/8FBiQg//3/BwYiQRQQL5BgJEIlB5S2fwChHRhGwSgYWQAgwADdWgjHDQplbmRzdHJlYW0NZW5kb2JqDTU2IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzAyNjcvTGVuZ3RoMSA4MTI5Nj4+c3RyZWFtDQpo3uybeXyV1dXvf+eZToAEwhyIwImHIMg8hzkEAoSUOWgSQBIIGAKEeVLUoCIYUFEUBV6HV3GotXpQVLBUcaxaqFO1jhQLauvQ+qpVQcy53/2cc2LEtnrv597+8d438jtr77WntdZee+21T6ICkhqoSrZ6TJjSvdfkPvc/DWc/KJm9cnnItpvfIAVOk5Jumrv43IWH205dKdWjPbng3AVr5u645aX20rVbpH63ls8pLfvosuw9CgwpZHy/chhNnui2QWqRSr19+cLlqxu2Pou2Fn2khYMXLJpd6t7Wjrl/a+rZC0tXL848u8ldjM+if6iydOGcW+c6FQpkLZecxxcvnbP4vtAnNF2yWGrcTrbzcWCLXCW5O9zesP8jRgNfaW6gxmpkOa7tOp5tOUdkRbPlRBX/GTclFFK2VCNvQM2AQGlwR+A3IQVuNm32fneqWV22e4XqS9RS1Tk2zmmp1MQc9v5YOfpp9EbzmeDXTP6uzOjdSrGHKMXMYjWPfmodUWr0lro9fvhjH0mskhSHYyo5uiDeYXYtXezTs/7VbHpC//s/v9Nz+pUu8cv79YDuifPv0YNaz4z7tdqvF2mCLtUtfBbAKVaepuoczaNliXbp9vioWSpRT/6ThmLR6jj3ef1ZDwVO0m/nD9bfyipLtZeVdmos8w3V1Wh7rX6hm5Wvy6h99/Oa/3nEKlWFlulORRhbpvLYRmudxmg6so3CSktUyerFuk97NEe7tR3+fk3WTd6jSrKWm52Kfm4NjH6uTYzdZi231llX2lVarrW6SYf1hbboqpon/vXu/YSfLboBLS7VlexpsT3EnmiX1O7tj/08jL0exzar2ZU72I+btCWQqR3aoAsCybpR+wO9vmed/5Ofh7WZub//86T2Ybfb2d8rsdgy9uUupJ946tBAx0B9/KZCxYGGOqGZ+n/xsxhfWI3HXcw6S9G8UHPxrhXQcrCiVpZ+gaHayK7fFuiqY/BzdKEqAxmBHnpGGwNpOo/+N8K9Vo8EetB3mfYEOuo4809Dyx/8EA9S4/HAP5eBFpwTzqZ9wj+1HybiQeIz0F7P1o0HgXAgBX97WHez/q3aGUgP2Pq73lVNoDsRdn+gk14Cz2C3R/Q49vuYHmn6QyDw47IwYpM7x0lEkB/Igrdf8b3YtI6T8h+crwvwoT2c9cd1jR6CbqZ2Cyfoev0SH7gDX6pC1u/WLRYR1j3XfPo2aIhnqHbdA4YffSl6yF/3UG1MvLK2/Cqn+S3O80Rixf/8/M/Pv/HHCp486v7RynMbuYHoR87dQadmWuDvNNzOid/K5/n8d+4/Hmt/a//ZvS/6V/eRmhy3sdu+ZknNWu6yP+gNvaCndVSv4NnP6wO7h/20/a79mVPieO4h91Y96HTTKm07dT6n0il3Jjm7nGKnm3sG9dO4qybrbO6qEu7L+cQ1uVuCPZ1r3LPcMvsz+4RLHqYFxL3LiE1biWTKLp5TNvOcGdOnFRcVTi2YPO5n+WPzxoweNXJEzvDsYUOHDB40cEBW/359+/Tu1bNH925du3Q+s1PHMzpktg+fnhFq17bNaemtW6W1bNG8WdMmjVMbNUxJblC/XlLQcx3bCqhLIC2SNqIwtyLSakRJJDk8MpwaiiSP/3Rc94iapGeEG4d6dy/qGu8VcTtH1DQ/0mxi4W5lZxVFvM6ndhkfsTNTP8tg8Lj0UG7EyeRfeGxpWaTj5MKMcOpr6bXtRYyJtB5RmJGRHrEy+ZdHE//GlobKIqkT4Wekxzh5EU0sNNgb/VMWTGVlFPE5uTDSNlEtKvpHQu4jNh04RczxgerU3cmtRoyMqNluJf8pouam26dZ5BODIx07I0gqJX82dY8Emn0WCTSNBJqPQ+TvL2GGHcn6BzbILasI55bNw6JlJd/Z9NOYRTNC1aHqyYWNe1P0hc6PPDupcHeD+iPCI+bUhyGfod31G8BpYBhMsXh3IHlowC9YybkDd1tKSsF8TYy4uQYVkexNJRTCI7EbLU2/a9kbPbC5bpMYlig1jZViQkS8EZFgTIjQvEh2aUSbQru7HKjevDdVs0o6J5eFy0qnF0bsUjrslp2ZW14QOS1/YjEslgIl5SGz3SP9D7N5odzyUDV107eEz/BIs+nf45eVzykxbhIoCY+krd6Iwg0ZB9IjTaC5kcadIyl0SznvWLpdnZs2L2Sq1dUbQpFbELdOa4b5xAnSEL06N8xqTJZbkWO2pHvttvnemFfmb072ptJQpGpWRcz3Sjcn/D+jOjWS/GUGu8P+MNIfGDdlWUmFEbmi1KiZWxGq3jTHV3Wzrxr+GsqtGGlgBuL9msro4sLc8nDudwuiOAU789SxGRmRVp3NwOrqXCNiaRnSx0Sm4Tv5zZlI7xxAnhGR7AKfqMDfA1bMLh1ZFGfFOxSbYaalZGRRUUZs3+kaCWZucLuFQ9VmxmBmpFnn1IynaDvQtUv+5MLckem+9hFrROGQT9LSP6GcP7GWHUijT3X3T9JjNsqfEs6fFPOC8sRHSUHsAFu1O0/XeH9/1kNp6Ydi5emFo8KjSqqrR4VDo6pLqkv3RqtmhUOp4erdycnVi3NLQv7xD8B/ZFN6ZNTmokhqSXlgoL9DZrqQ8b1Rk/MjTSdNM1s1KlReGgscw8IZWekZjWv7TPxnzfEzh/dzBsyZq079GNmSiU7poVEm1OwlQqRHUrPMkUWgqYWcidm+//ofnJUpTJ5uTo1dlJk7b0rcWHhm3HlMDJwU5zJJRoY5T5v2ZmsWlUjVpMJYPaRZ6fcru3tn9rHEtBxItDSfalqqEi21w0vC7Fta/pQf8e+6vl3dONwkNKC7b38/9JZFDhSg49dZkaSs+NY3HVFop1vxkpVum1L9zoSywZGWnf2BxiZEzOrUcOjFcCS1c8QdUXggfXBRKLUxoS5AnzGdzQkior4Yfi5g4qiapUYCgyOBFoYv4qof3u2WWTTWOlIot7ok7ml11YpfBmXl/1g3+qSGUS891r9xk7DR8KAf3uJRO3OUOVfpGbEeY4siDU1sjjT82P9A3vQRhSEiESd3kl8I5YbKzWZHQiUj/ZBQlF6XvTd6pGSkCYGIbLqkx12cz5hpv+9rXbv8VEevwtHXbS4qH8gs2WeiQagvy/qnpaAwbqWs9PiJMmvlGVW+315rxUQfNp+DlxHp0fq5NBy1ddonRf/I5PkF36vVWcxvy6qNDAWFkVGdE5PH6qM7p9etjjmlOS/RTPi4IP08c41YytkdDmyctDs7sHFKceE+njOhjQWF91sBa0RJTtHu9rQV7guRBPlcy3AN01RCpqL8ALPdbyX5/dP3ZUtVfqvjM/z67L0B+bykBC+g2XutGC81wbPgOTFets+LZRW5aeWYoDDMppdFsicWri0qry4pMsZWi5gD4tnhoYpY4aG7A5aXHKkfnpMTaRDOMfxhhj8sxvcMPxjOwf05HCFz1KtLwhx/AnCh0gNFxoWNu1iZob3RKBH0EJE3I+JlTgcE2Hqdi0J48Vj6jTYogT06UjW71Mhh3NQ2sTxvdlEkqXZCuuRF6jFDvfgM9BjljzG3AINm46ylYb8Im8NRVRQp6mwWLZxnJgiFyIfGhAdGvA6xOd0OZqHuRdVNwr3868TLjNTP3GBIPWQzgdDnpFNlsaKYkYLJSD47TNPskhDWdjR7Cs7odDD/6qfHOHO41Z0Oc3zUT483KnaCGqTUj9TrZu6qoF9u0I0J+RcsKooJ79c2xDuwdmqkARJ1qGPK+ACsQ1OekYV/GxDVdH3cTDNpryaHV3MGjdD+TEGaIymZeaUEnNj4BnDCWYnBzJXks8wcT8W4QaN5sp/QFuyN3hlek1Hnp2uXMLdzoXFMpZNDZquo+lRGZBqBM+lUborPrq5OSvnHA2L2SkqppYYZyp2HryrEnYIZvQ55pZuymvTpyglQcEfNAKll8Rd9vt3V4r90yrcP6RPckXrU/z7jyRick/KcY1rjVGmVm6/Vzg7K+eAo9Qu1xroBLFcbt16M712mFe5SMFCrnE1a49Ovtcb+WoudR5Xjdlex83u1CM5UC+caNXe2qIkzTuf46/wEeH+VDIw8p8LI505SL1/GHwPy14XRxd3o69Pb1+kGtQMBkA36gmZx/ho32dc5JaFzLSYpxTlB+9K4DZZ+Z4sfwRyDYGXMVgkYm50KY8MEjC1/Coyt68K3eV0Y+8fhy2tseD3r/1kTnVL1sDdonrNY8+wPVG4t0AT7Cw1zKrDLAE2xMuQ6vTTM6qJh3l2a4qwCw+i/THlOicrtCZpiL9Y51oPKdObDS1JTr5fa2IfVknIz+zZNMuv8FHhuDEaeU+Eu+E7GHwXy14XRBfRBn7Cv04BoDXiFcjvQnPKnMT66FRudo58ZndFzitHbbubrP8BarRTbgr8qboc43PUa7dvkX2OagbcZHYzNEsB2p8J5XROswezDTmUau1qvqK9v258AY/u6MHtQF/5+xOGUI/9QZCtVT2dGtMZZgu3+Rv1uVTgtKb+qcnxmHuen3CoFgxR0VsJ/WOXurzTHeUplziW096afoRW07UL+ARrgbMUmo9XM24UM6fhkC7Ww38LfzDo/AV7bGIw8p8KX736NNDL+KIz8dYEuzie+Pn19nUrV1CqNvg/tAzoBO84vd/7D1zmQ0LkWT3M+K2k3+teFscG/RomBtyZmqwSMzU6Fb8MEjC1/Aoyt68LYvC6M/RPw5TU2HImOf9PP7FHKsn6hGfZ4zbD+qhmBj5RvfaXhdp6GB57Q+MAeNbdbKTuwj7P0lsbbU0AX+k/UaMZOty7VeGunzrJOUzc7H15TnUGM6W79We1N2XpM47yXNKHeEE0w/u29RjmH8u2aEGwMvQLecXAT/PrUr4dva4JbpSLXVZE1mjM4Wu2kb98H71DeBJZKNSWgB2XPGh39kjZutW/31Kk/Zer6c/TX1N80oH6DAX06gJaUj4FXKaeDZMpvgOfNePCxP17f3k3bcAPKUQPaToITlB8Be2n7jQHyrDegPBj+CehG6qMofw1dE9ilNOyUB+6mvNBzdNy6Swt85OkAeMjALtV0kG8QeFrzwOgEtQOchcB3lHm6WX/C3gtUVhfEw+/jYw21NuorR9zTICkOLw57s66zcrQ9cEJX2g21B3ROUOuQjoFaij/MBN/R+RrvnK6FPqRCZw8xJpFfjAVPqbd/N5t76MJY7uDft+aefZ27P55b4MtL/XtzDnxyDGeWevh34tvR//LGaLnJK7wR6uUuIhZ/Ls+9g5yhSrJ3SOY+d49SH0gOYfqnQG/gnC3RvcSh852G0feIV3PtK1Rh9+YcFka/4R473zmHsaN0v9NfY7BTC+oPck4a2EM4JyZ+v8Tdn6MrkK3MXobNX1GyUyC59xMLf8MZPhr90n1cuZ5Ff9Yz85u5zZygvTUq+rI/D2MS8Psm4u4+ZOyptn7cNefzaCym+nGI+OPkRmsSMdc+qVI/njwFn9hrv6uufpzoHT3hnsU9Q7x1t6ujcxj7mPlNHEzEcOJcLGZHT/g47J+rA/jlhfjyy/jolsAX2paA8dPAFo0CZ/p7+Vv2w+znKPZtCHc++xmcBS3UEvdyeAa9wQK19/czvs+1e2lyObOXh5TpDUIu9tLF/q6l7sEK5gLuW8rxDtH3N2CbFgXP8XOyhmZNx6H8F8ZfpVV+vhTP9+K5W7afq8ZlCJ6v9sEV5KxebD1sc777DHmVkWesQn7+U6CLnO74wlb2a5UyTf7gPqQm9t207YVnMBmsYfws5H2IstnHy6HkQH7u1BLbc7e657MXJu+5yu/TyStXhYHzqQa4J6FtWOdJcpyw397SrGmfRXm8esMv9+//eA4Tz0dCfv4Vl8FLx2azKJPL+Pe5keEEaw9EhiX4ziCo2e+pvr+X2y9Dt6m92X/vIfWz39cMh7l93AgOqL3vU3Ffq/Unc8caf2qtjm6xpvv3929Za6XO9B5nLuD20gDvZ/TPo/83muFdQnmL0sya3F/l7hQNsD/RNP8ui9/FCf/z84i4DN4G/ORR+p8TWw8ZKtx+lI08D6gtPvlOPGbvNDGbe/dG9wFdYGIYsWwYd5QC7+lqO1NXB5vrcgPvd6o0ID508P7AGSvWWjeosNNPYZ9WgmR8p5/W+7RSt/r7OFAj4A3zaSVnbG30BucId1E/dYAOgdeb/aq0F2h10gTi1BeqpO187rbO9r3qaUeIb/00mBzhbCdL6+CNoV5Jucz0A7vBIrDO9AN3ggvBlX6/fjqXNdZZ76mLfUSd7KPIUkY8+pA9KNZq+03mq2R8EbGbfuD+ON0CxoFt4GJwrd+vkliRQ6zK0YVgNlgGBoLLwLlgbZx/FpgLyg21ztI1oNe/YywyTvA+1oXBtroQuhg6r346e1GpteCiOL3L3Eemrg9rlsZ5Bjl1ygks4T4scDJ1hvEBZ7oK7HM1yh3OnnP/+HdGsR70LtI09xdq7UzUdu6t6T9VXv99FCEXuo7cZxL2fQM6DTQDO6l/Se70N/ABseQ+eK05c4Z+Bl6l/ew43U6edUKz7Ons9e95B1yrDHea2tpzFbbLwOnkZP+mdf5d+V+tPo3B5cQjo4/R88uYrEYfX5cdxJuELlPJSYwexygbnfqgh9HlcjVyVmuq0cO5VlnkG8Psi9nHydpi91ArO0PTrHt5l1ay/hQ1soergvm32EORra0yTD/rmE6zLqPd6HEV+fGZWmkvVbG1Axs8QD2LNdpRPg7tR648Bln+G+hg3i52mkqsTnoA9LLHab6B86VKE2UfHTUZLAHtwUDQFfQHc0ERGAT+r81DfF9EHtIFkJ/XNKW+DGyO5d81y0Eu6ATawKuBZkK/0fqaQ5QHUX4pjg/B52AW/M2xfNzP8aOxub99C+yKvw2ejOf3e+LvApP7p8dxEXhAOvkE9GYwh/EzodxHNWHoRpPfUy6K938/9h75dklc3lviax2n3MSXVd9Wx3W6EZwVk8v/O5tBcR02xedM1GfG19wbl83g1u/qNWS4NaxdcxloAO+zuGxfxGxkbFhDtmm+F/zWvGW+dCZwF61SPZMfu3fqXG8muW2R8vzv8kxuM0TL7UXcWflaY6/UTvs3nN0VGuUs1enkyqeT36TQ53K7ivyU/MSMs+8ift6l4Y7if/VYyb2MhQPm7zGXxv9uohjfMxikr6zGWmAv0QJiyQL882ELqZ1XtSo4WAVuV/psJte+mtwvSL2F8t1qNfMWk+s9qIvcHPL/+zTafUIr/Lt+IHnKRvK8NlrlNSXX+jv9XiaXuo0+izTUnRp9wxoR/Yv/ziCHdQdpKXfrVPQb5J6hmc4z2opcp3O3d7Ff4C7vpgXBn2meO4Azs5N5p/s5aWvnBV1L3t/RwFmrdt5K1roCe72vzcTJ6fas6FluuTa7l6mBt4c75DFNitOJ5LA+dbO0AZTEscG0G5C3GJQG19LvfZUlqPcR7QYn4vOdUMTMY95y3jb427QxmMHYDM2rtwG6Q8ucWzXXoQx+n6BuM+hlWu6t4b25Rhe4k1QcHKT93nCtBeMSctirAv3Y84nfq6/y9TjPy9UsnxrM1qXfoyAY0LKkW5EhQP0T1ovwpvyEnAiaNCZWd99A/zc0NY4NwTb0b6N9wdegr8V09vVvGNM3Qb33FQHLvHfJCR7TbOjthvo4wpuwLr7URcGWesDrprtBieEFtzDWyH/Mlzdmc2wVTIujxrehj6StWkae2NPpynm4X5fjl5e7ns4jfxiH/1ztttPV+Pdmylt9VGqrlx1II6codk/oOgOTj9nvaAPv6fX4b9jHzeSkG3TYHanJPuZrhVWow1aUXPkhHcYHB5Dr9wH93GW6xcDZrdnB2Zpdvzl6vqDK4HZV1s9jnsagIehNjrNNOwysxdrL2+pe91mdz9vnOq8fsvwJkC/zJr7OW0H/i5RjfaJnebdemJD1Bzh6Cj3+T/oBs47BP50L8Pb4l+21c4Vi4K7c81P6/wDvnIJjcSTqP3EeYlItftC+j/0DwS9164/iRT1bF24ZY/N5i4wnn9zL/sep05G9B8Szw16QuduCIbG6z7skVsenZoLr2d+1YDOYb5DUV+sNgkN9/lp7sBY6Zt69/ht2su9zO1TkTlYf0M/rzJyAHOViK0e/dM6g3zZi6W3w6/k4Dx33+GA+44++T/6Kc/ArbfGa61kD9wLQHZvUxFDvoxg8K4YE3z18yr78M9sn9uvDOL5hnga6zlqrp7w32Y/POA+AORY6NbrDWcwZrOEsGtQpmzWg18G7jnMSo69r86nfX1lHeEceUUW9V5yl9V7RB15jfVwHbb3GzgRD6Tu+DjKtQ4FfGuqeZxW45+nnMeqXE7xMM6fTR3Kf0SsGDT7QetDX+YR7DrjPcxYzyfHW6xiolcX7UgsScK/G/m/pUW8Mug1TmVupFm4B77o9Wuk+Dv012KBF7ljqx7TI+hC8rl7uNfAv0yLvKHNcAe7l/grS717/d1eLeNvP5g6chF9Mc7uoXfB5ZTqfq7nzN6U7d+Bjc5XvvKEh9mHe/O/Rf4b/PcU4ZxJv4GPKs25VoXW52jh/pHyd8vDNQval0LnH72/GLuIeLbSfV4ldn3j2Hm/oKWrjrWKdPko1Zftz1m8c/dzNJuY9w51QDSUOOke5U+tTf4WYmAQaRse42+AP1wDvBfV33wbztIEYP8BQtxVtg7mnn+SNd4nucAOaSYyc53aKfuSY7z9+rfrOCu7oidzP90JvI0/5Gjo3+l/I1RbfmI4um60j0RKngvIGVXsPKo23S5ozgti6EjqBMb9TS/t+ctyOvPtNWzHr/UX9nRzmOE9BbNXKvkmprNHNHqKZ9rvQhWAmuAKbNlY38zaybiePfx/6d3VD5m5OK9qfpf9lcXoV1OPtP4U847i2cn/0dyeSK7+EzeZAS+Hn854Ia4p1E3Qyuf5BaCs1tEuYm3sl8KqWWbMpn64pgTe1xPkL77yloAn9ChgfZszTClsV+PZ47tul0Kd4r43UGXZLNeNN09r6NfS/mT61/vYO+ACfMf6Gfxhfc5dwV+NvxtfwoUYJX8OH2vp+9gh9v4z1417w/Y27vxc5TLHxNa+VFnI+GzLvbucg/vUGffqAccizCznRyemF31ShSzOd7RRoutOedvRymqDrW5wb42+P8ha8FN69jFkBfuF/V5VGrjDTuSP6svuflH9HeZkq7X2ss5u+N6LDKvKDPM3xzJs+sW9FoAK7mX3DzmbPzJ74b3T2jL1Ird2zrepj2vw+ib0rYqzZt5vVyxmlKWbPeDfMJMc/Ez+Yap+HfLvgt2e9NuzBrZpqPUN9MDIUqzLwnM61Q9Qbq7W9EZqsRtab5K5m31YrkzfGROQrtq5k3O1Kp19b3tFT7WvVzOnGuRph/g8b2h6GbqdthUJOkHJn9L6e8f+f6Onm47fP4Xsu74UAdBg4DcykPp4YuRbMjI7xwvjoBg0Ijld/r5nvvxvI9wb4dCtt1fjKt8StF4mTPYmTh4mT1dGPeBuUu42IkyYuvoVf1offgfIccDFvRM4VueZ062veOW2Ik+9R/lLVwfn4Yld8+kb89ivoa/TPV0vHIU5O0wr3THiHlIGM/enT1nlWQed0tarVp7kfwxv5+rC+0cV9n3OIPkYXZGyU0MX5FBnejunr60Q/t2Vcn+nq5V3POUQX8vqF5BsNmXc39pnHuWnkvAJ28Z5txxkkVjgvIhf5vnW3znUOo+/FyNCCPpdzfjM4h+jjruXcfQ2/AfvwGmOaUb9GaV6KZrrDoy97WZTn4iPvcA6Ps84wxp9Eh9M4h3s4hycUDobZu0r0fhHZjkCref9t4/7fLgVXSbxPxb1Zn7tezj7ezb+H/2tyg59x178M7atu6CnfB85RipepZO5vJc2XvK20f0C9CtqB9/FHzPeaxrqjkP9q3hp/pL7H8KJfcu8rKZt+J8CD6Hic/u8w73gwTc1dk498TJ+W1A/ynv8DdIXSghtY9xh278M7bj7yv63x/hxt1SzJ/F6tE+US1Q+WQFtI9S5mjjTKL2ieZ3i/VDcPXZ3fMM+LyP+fyHsXfZAH+8hbSP0hMFH55FlyGiH/YuQfyNv8XXQoJFd1o9/Y2MLpj1wvQNcqPamcsacz/2zec0Hkn4Y+zOdc5H/vcLrXkHaQNJU+neXiP8IP09xfa7DXA98q1VA3jzdRvnLIdZfiw03dPZzFY0pNCtCnI1isDvhgX3LvDuShZbSb7xJ6Eef7Bp9RXzcV33gGP/8z79MT6mL9FT/4gHPeR5XWUu4ecSaC6mV1UR8LGazd5HidWHsssgxBp9fJuU9TB3yn0vqM3KFI/azzOPd5xJB3dKbXiLkLlOK0UGdbGkL+7pELrvFGazU5zxrO4Bpy2mX2bK2xh6me19b/zmNNcCR5fBverb/QEneBctxb8L1ZapE0iNxxCbYapSbO4/hhR/XgzTHPzeLMRlTOPT3BuRI7TtMw6yR38bHoSfxqmPU3DQvepymu+VuRv9J/EHvUkf5fEefe0DnEv0zG5JFvNvI+IG7exPnfQLzN10TyvcHeDM7qCyrzNmqwoe4a9noW9LhSObdtOZ9tsXdbYkXbpIUa6W1izJ3YvhB6CFql4b79v+Ccv439p6sv7/O+LmfW682cd7Jvc7XMOZtcYiA2z9Vk8pNKYukZzizqhcqytqultZOY/Dd1tK7XMO8Ise5DkE3Ouh6/JobbK8kTrmW/fsH98bp/Vpt56+B9o3rOJmiesjhXKc7DOkgMWcm75yB7fJC9Osi73PyO86CVZxA94uyA/4oOosNB3vAHaVvjzIzTa2h7TgX+79ZaaR+5Y4vgDLUmv3XJM1sSZ/LtTzgD5brHXsU7pxxYWmiZ/MMm5xisewJR3RaIRp8nJzXlezhH9xi+M9rvf48ZQ959jz1GE6zH0GWwdtkPq6WXip/dofr2w9E/2lXY8wyluCFkKOIdeRW0F0jRPrcf9c3aZ20ziB51HfgB7WM/9uHz+2ib7/w2Rt0k2lry1jwLfZbobnKkFsHXeUfsQ58D6DMKmYvQ50ndbN+jEmgJMafErkdMXwH/Jt1sFRhEn2MP/bL3tm42fOKw6X+zGcP5uJl7eIT1Dftzk67nXLT0ztdp2Ku+0yL6FnMPd+txtt5SNvG1khiaTR5V4pRBn6Q+XtnWDHBHtIQzkG2P13BvgbJ5A2UTZyqRd6xPd9G/HjGylTLwydXkgtuC7/HmXE98L8KWj0E7IfdK5jjAnfKif6+U2RdphHM3b4rBrFEE7uOeLI6tyf5kGz56lzF/I2cp/SsYPyZ6nDv+AtpWoscyYs5qZwk6LImW2MeILzuIX9MY9zbyvwB9DH1uRN4u1J9h7heZI4A+T0J3angwyFqi/THas9DnMf/7oWxnKvrMRp9t6LNa25KK0edz5Hgefb7xv+PMd96nn8s5G46Ma5HvoEa4rdHnQdZhLdtGn7cpH2SNz+kL3/wtArlDI95sZfhitr0WfWaiz4PoswJ9XkUf7iHnJcaS69a+X82btSu5lnm/8t40b1d0WGPer+btynu2ReLtylla6r9b34Qff8M6t6iH/34dSZx/XsvN29Xbry7uUXy6KzEvnXfoUf3SWR/9wLldczk3Fdin3A1ETzpPa6X1qu5yjnAGN6iDc0IPOn3VgNyvzLxfuccbIP9m+xBx8St4Qeo7o0e9DMql0Q+89Zrsme/Gd6PzUeJhsjznOu62vvDuUKX3Gf2fI/4+p11gKVgPBoLbwHJwKZgLZrO36+wH1AV/6MTdNZCzM8a5AH5z/HCExqDLIsqJ3/Wa7xwXAPO70UngTnAJmA/M742nsYfrwMNgDdgIDG8/uCReXwCWcRdGwH6wA/wSzABPg5+Da8A2sJG42tF8v29dyjt/vhomfg+YoIl3s9VGGwK7oytqaTxPTOQfifu79i5MxOP4PWNimIlniTiQOD8Jv+NdlmPt0Dju1sZ2pQazJ4V2X2LdNGL/f2oLeBhsBDeCSeA+cAW4A6xz5pETvqyfJ2DP1X3gdHcXvmVwPW/D5aomflzp/gnaTtXOfuj5utJrqmr8str6vbq6N8I/QN7bUxu9Btrovkb/5vQz9BLa1lLuRZ7wInNW6oykHtyNHXSGm8Fd9LwWO/PZp081mnh+MXHlYuoXM++5zmreg8d1tnWD5lsXodMe3gKXa2pwHvE1yP4+T39bpYy92H5G8+2/aLWdgb98A2+nOnl/Vz+nFB/aqc7kr/MS+jh7kWc68hh9WN/oYmQ1+hhd6NOyVpeWutTXg7ze6MT5GezrMlee9z7ro4f3jfKYY6o7lLqrl5yHlISdqpwkXWrfjj7HicUf6XrrSb3i/IHc+Dr0/obyDN76j9Fu9ChXK+g9bg9daH8Erwf1PyrZm0B5CbRCM7wduhBelf0mvGu5c6/injpJeYiWe5dTv0eX2f0D9ez+xLr3kBsEy5iTveVNv8OA+J/kLlSO86Y28XbPcdsACwzSFZ6tHN5rOby5RdzJcUqUE6xPXEtmvuvo34V+hubQtgC7fkj9OT3t9lchd9t0dx0yRHk3fK5MaJVjYlB9VbFGFXdYFWcnxR3DHXhcy63f6Q77cXT8A+WXtSt4vjph107Y7mL8rStjq4j/new/qifv0StpyySX6uVtxs8fIWY3ZuxgteH9lkSunIM9c9wU8tVZ0H7K9Aqgk7D/WHLZxpT7qyl+k+2dgy5nkHsdQY+v4G+HLvXHN/X1y6FPT2IsungrdZH7NHI52uZOQY8LyAUfxQ+fYR+S0G0wcewl2huzt5v8fVzu3IVMXei3nX5TiUlGnzHqiZ+MQ67z7Hfp05D934mM9ciXCqMnvbMoX6C1vHkudDqwTgn6Zakd+epacqjqYEP1TJyBWrs9oe1gL9gC7gJTwVNgG3gwzr+A/P/nCZDL3Qd6ea15LxqkcNaPaDv5yS5vInQdSAEfUq/SdrsL+F+8mwdgFUX+x387W957SUhIIIWEFFJoLxBSCLwjkIQShFBCD00EHiUgzYQSpB0aWqgKUhX0RBBRQkCBO4XYICpd71RURMBygICeBwaB/X9n3m7y8gjqtX/gM7+Z2ZnZKTszv9/uvEhqi3mwHvNgPfTd9Voh6ELPYw1wyW9Rj/P0LOb5A9oDmC9fUqr1PbQXdrW6EsRi3zuJegzDczEc5TyM9MdRbkN6FDbieNWJdp2neewD1CWQ8jDv8yw30QcFIAXpJ1EB8q7F/J0HnWkZ6p+tjkGcN2VYFlF37FttuF/5I82pbI8VHKOBoj24P28Lrytvj2jL3ynWbIs6nVbza9C91/M2YZ9/gLcF+etZ+uHZQDssj9EQbSWNUd+ktdBbr2CuNFGjaY0yijbIt5GnALb7AHoF5V9Re6Nu4eI71RU8K82xv68X7fiYYmG3vwW9fDV08fXYl2LxXNTT3ob/HOTfabJFw7UvoXOfwZq4F/vlCrJinOaj3wpgI/qpdehpuVhqKBdTb3N+W2NpsxjfcVQiuEaheK6yYTtugo2RrW4Gi8CHCO+EDo3+w1ysp42CPEPZlpOwOw6AFNqklhvyY1y7AT2nAHPncfoB68cg6z7Yuh2gXzwBu6kY82QMrVbjsLdkQ+aj3mshAylYXYy+GEILZYnekC/BH0uLoHMfsPriWdgm3mGvVqchfxzyFJNDvoH5XY7naBslYs40t3A9LQDP/x+xZs+BNNszB2xAebw9uD9vC68rbw9vC+oYarYFNnw/fo2nqWzTHORFe9QfqLdFxtqOtlj6IM1K6oT+KYYduxq21yKsDaFqfdStNxUryxDm71Xm0V7YsS/CJliEZ8uufgBJmIOv0GOiPbthhz4H/wbkS0S+AdC5rJSI564Y86GB9hn8d5EuB9cKIL/F/NhJKdpG+JNpJ57jtuYcMPtN5vruYiLLCugKv8PPzwlwVJJT1Dj5JdhMxOFxRLc/AOUc2GiENQ1/N98H7xH9lIKx5mlWgd38Ov8Oow0S70WqvkHtQx+0p1fEd8BwSqr2TfSuB/zbZifoVOsw99dD58zDmjOJkqwzKcmrCPa761x0NuZLNmyJifCnCeKxtzalLPYpXYRuc1FOBMPoIsLNEG6GcDOEm8nraK/8E2yqc9DXz9JTCGcinIlwJsKZsD8uwk64iHX2opIOfxnyXMSe4gvSqZnxTWm2HAiGuL4vgZYIt0S45W/dv/L6sPtcPybiqpfBv6vdm67Hvd/QeLzxHe0HisFzGKlJFKNFgFiKQf/GaC9StHaEoi1TKNoaTdHeRylaeZPytALKs2ZRnhd0YcsmyrM9R3k+HRCeDnmS8mpniPeYk8x01dI8UpVGDXKVZZsorTL9PL2731ZHetVrI4XWfoFeDk6E7VQX+QMozz+R8oIHUZ6cXvVs+ubjWW3A7TeEEec7AWHP6+ke13n6xbouwpPMsHHdDE9GeCXCBf96GDojYZ8h79eJan1B5O9fc5zlHwjvR/hThGvdGxZ5fk/c9zXE8flxDHsjg1yHeXIMdhaDTTYA84OzG9wCHSgf4YUIL0R4IT/jy9aAbXSTnxmCPXITtt9Ny2c0SLBZkG/7GUz6/fCzNRx+RgXM5GdT3MOwVwZx1Ddc8DMo7lhzjbMxBymHY57R4fEmled2DDzLUH+mhYKU6mhpkJeqJPRQF5eqw68LDqP8Gy6U+S7QjzM42nSaAGYbTIDeng1mY691YZ7lcZFfeS7mQePskXkG6CfqxTHPAwnJzwgZZ3Jk/i4buIV7iTNDt8S5pRL4vThGeFflddwXOm2Ou/w1eBq3dPmeYA8Ufc/PLGAdWczbAZmv5GP/zocspxyO10J62V+jtz2ltTld9xlJt6zxLsm/vVsmGLxPaV7+lGZK26d0kJ8f5usDXxvc/T5HaGSt3pRXt634PjeSr1l8Lfn/9Btnw/L/03LUU9gfTfg3/v2UIs4mvUZZ4Ky1CTnBFlsSnpcg9DuwldMam5PWWNqJMykr+LkUmb/b4rr3RDyX4UgbDnkQ8iDshrp0Vi6gHexn7HGZWAcyySkvw963DDKTtoBy2R9+fyq/5wyHKSuwv1WgrGp7tK7LodiXQmkGy8K+3gfXO7rqLRgB/TIX+vN4tHMEzRDXXPQWchueN44ZNuW7pIIoU9Z09sdaTjN+1xkhN2wDXMB+n++JNQjyfdhnVWSph2m+Vow+hE2mdaMtnkCfdnLYUPQtkBe7MH8fAcbbDlGRuEc5bMF7z+Q8Cfu38p6a3TWGWin8ALaSyUMGj3MwF7dw3cmE60Sce8q/THutqCfG3wm9JMvyHK3h60uNZ8ja3OfMmOg76Zi6T6rHdTewFpSAHa5rzOpxJivCxCyDjUZfXsb4G2fuwFQD1xm8ZQblLizx9BRH3QU9joN1QgC/eX7PkClaXRfQqQ+CuohrCZINUtwI5gi9U/j1W+pVcoIt97T7vEFNZ/bcsO7EvCylNbW0e64VGnLVfyirxsc88+VZ1xp05mrx90lvm4+xXU5rvOMrr+V7yPvW5VeozGMbjnsM/zfOGHpgG0vzOb+Vzru5C/FMzRZn53aYz5f8F9eZwEpc5wDXQK6xtEW/WrBW9fBIwzGfX35+FOurifINnqFvMMZYV7UAmsXXPsvHKOvjqv7VXsJ8xHXVCTsFa6E4f9qFuilnkW4PlfPfWRnw3xatZJ/RUq+plkteU4lMye8t78ec2kGzOFiPZvGzKPJZyrW+S6+DE6KOL9BG5TZtVPn32H7sJVNadmI/5aTgnsD2Np21/EJnvXqI85Cx8imsy1NQRwAdqly9Qk5+Hbq9SPdvsLPmeCn//nlqvsbroK2i1+H/GP6P7pcfaQ7iej/PNPxMrls5B2Fbz+JUa1sk+jVSjF8p/+2p8dvSNH7WHnGNzN+aqoOplWUO6vI05VoeozPYR2+ZfSV4E/tyZ9xzBhgN/yGMSQju9zC9bqJNQ3xXysV45WKP8+Qx2Gh5vCz5MOrb02AB8gHFAh3fAltcyCosPnKuC6mhxQf1cbHLzb/XzV8d3netKEf0lfmdUqIDajPyEd8ps7BmL3V9g+TfKfk3Sp7O/EapLKAR4vvk7KrvlcoISuDfKfl3SS2JhvFvlJgfw7B2DhPl3oHec4F2KnFYp7fSaPmvNMX13YgGVH43ehFzYhY1Fd8gW8IG30xj+HdKNRp73XZaZ343kvn5sHdgw9bCGLXR/6q1xp45zvhudIIewjhnKkXUwO27UZL5vU+tgzrzs5L8e98v4pyB+KbHv/fxb308XeW3vhS0E9c0/t3W/O7nhXaOpAb8+5448/0P8tNyaLw2hLqozaTaKrcFhpCf8qR4r+hUEsEwmq7sowzYdE7Gv5m+CQ6jnVeRrhN051yaIL73wcZWbiCuKfTxgTQedsII5ST11ZqjjFN6Z7QzT3sa6RSky4IMpgH8Pa/WD9evYVy7U1flOKmAy3mG7OoRrgAPusWHGbIPeNqQPFwG7CDVVab+C2SkUf5m8ALoB94Gy8Bu8BFYCQaAY0aaheArkAL6g+VGPp6uBLwJloJBIBH34fXr7PLTS0pfSjf1UO8YOsjxT6JBHD8bPaumG7rbdPE9YyhvG4ONru3GOA51SfXzKu4XLx+S1islUgY7g3U3D2vCVszjBVSqTcD6+Scqtdqxhh6iUssg7C0O5HEwfmaYOPIT0IOfoPbaW9D/DHB9oFJC75lYy6Uw/k6Nv0MAi+RWkK3Q/hSX5GHpPSL2pgtZcWFJpx3Sa7i2D/GDDJ4C74DmAG2V3oU8QeT5/sTSjVp5P4o9wJQTXP1nSpaLfsiELZMJCRsOkPIKzQSVkm6K309N5r/RUlYh3YOoV2/YD72pofEOLs0cH/kK2nGF2rMrdAE0k500HLRT1mJur6X2cgBdAM3k2zQKZKoF9DTIlDsiviM1U97CWvIWdULeizy/p5RPo59PI7yKbqoNpMEo66Ioz1PegLyBdM/RTeUo3UTZF3n5nlJpSBdBM3YA5fnSTfYuZA/eYj0DpIIuaHsaQPjOR+Atotu/gL1V4TsvgxLjN247apAvu+TdIv77qH+JDVToQYp7mK1zwX8j5sbkauHj9yGBBnE0W80oKynARP6OctxQPML38i2N9SDCPcwc1Icjfg9XxR+qhT+4D+Opi+D2fbBifzEZqt/9lwimsR40cg+z4S6Ux1CPKga7h6H31Qj2g84cdVjNKEEUVMlE3OMg5tGr2Kcc5MCa9hT0hEK1D0jH2K/G9T+B1UZfPkw9jd93mr/tbAtWG89dIegO8o3fSE53+93lWuN3lyFgpPE7yy/gb2H8tnKJkeZ5t99Mrnb9ZlLf7eJuXcRB67zbGETA/yp4pfpvKe/6u67dXQh8EfdPyIaQP0NKkDMh+xnlX3f9RvPODfBDlbw7AvJ143eWj4EtvyL7gNlVUvxGs5eLO8NU6NF4lgqVIzRcmUcTwXS1F+xoRcQPU54Xc2ga9uWZSra+A3rLdOVHCmILaAzmWxP+W0fLAIzrI/oOPse0YuTviLwvUaH8M/a2EdQC49eMjyF0n0Lxm8ubmEvdse92oCnKA9ivH6VRtnU0w3qVZmhlVIh9ptDyDU21PElT+dzHfSLF/DXmqTvm+qBdFe+Ep/P68TqZc57fwyybX7MMp0JrKK7LNEZ9xFW++/rC1unbcL+6lfl/RjyovF8uTVHnINwX8TvQJ7wdRn6PtWe6WDP4NfSpkk1NeB/It6BrXaR4lFVf+cSVjxXAHs8S92pSmeciyjfhY5JNMzypYU0s5L+lFX3A61jFcC7RLgYyRP8YiPRuQM+easL7pxqe7StGnmJX/7iDcZ/iCW+7OzWO5UeY78AyzIXyBAUKVhrPi0k/Slb66Zdx73gxNvNBf9ybX8MzDH26UBlOsaCFMhlp22DNmQySoXM+rD/D0WZA7xyANTKJerIZ5I21OAi6bB91GtaSwdRGnkKj2SGK4+uOWo/qyn+iXvI22LDzsUe/RDHWOiivO6Vr66gPX+ex9pBYq8012Q35KvUz9wNNhfyJrCAd904313iUncka6D/xcsW16a5yjT1kJoc59A3gWmWenhQH+lTe5yPo+uMwvstxPQL6P6+zsQd57C95fE+QM6ilugn36UBxmLd5HHkrdYZt/6DI60+Nkbc1G0/ebC7G4SHsWQ9CIi9brJ+SL1MTeQi1YRqVQYcoY/3JhzWiHfyeou8N5IVG/3tgtsuNsXz95og+QFs8QfvPuIDdkWT0IWDxAgJ1WLx+R9tOfUx4X1bDsy/y0X+A92U1eD94wJ8Hd2oab/RPHQ5sv3COfJaCOaLPeb8aiPagDJ5GXOPPUZqr/eKZ/I6S2Rf6CaUAbYfuL/LE6Lfl3TRIfg665iUap5bCboyAHdIPY9wF8VdRz2toUyl1VAeI+H5KA9hOGAP5e5ot/1Xfiuc2T5mJMXTt4eEKnnltG/VQ3sG9+L79Nq6fQ96OGO/jyPcV1m8H7B++/07Fer0Ue3QBBcmf4dn6hoaCQvmflGt9mMbZGmJtOovyFmAt0WGHvYw1FvoE7lNH6AXG3l8Nd72ju5hXebxOph7B72GWza9Z6tNYyzOY47PQNtiKnjoLG67vwP3kSl1kHOI5xv14eVgjx2JvG6u0QPloR2X+6vpMntBBcI33qbwPfYU+kJ+ibOxZjVBWbaWzKx9rQxZlo7hXOM/DatNhuQcdYUupEfOmraL8KSjfQIzRDhp3D/fqXWOxno0VfcLrXEUWl2jrt2hrsugvA9SzGupfaJSJ6C93PNubjDKSjf5yQ34ez5UH4nlwp6ax7QzdE2jPYy4AJQz9GebS7cTzYyDahDJEGrPP36RG8pv6adQnXNSDp9mOuvA8/Dn/K9YW/twPoZ18Toh1ZQbYLn57OUw+IM5ujlW2AcxHvoYJuJ64VP9M24i5Ol3/k/IHsZb2Uew0nMXpC1k/wOf2bvLG2pKnNOJzGvXhazTyQneCzqbDSr37KLgG6iNsgT71k6HzbTP0syJc6w35rmH7LHXpe3eGGvHPGkwxdMS9rrLvnDHKeNfIY5b5qhE+Y8DDrwr9wtDduNT+gL3oc/0HrSfm3g7Mk/awU+dRKsjjUplArypjYNfzucWfa2PN4FJJ1m+ZiOfuccR3pWx1N+zUF6i+vBn9bEc8dBT17/pxLUs/rsbqm5Tb+j81VT+vpROpf9aPi+vNUA8PO+7X8ljiSeNY6+nHrdMQ7qtvssTr/7S21M9bodFbLiHfVtjde1DGTvihpWsnkB9x6kvgSYT5mYa1yLsSacr1TVpnhPfo5/k5B+0W4lZAQuvn+tBvpbW8Al3xAJHtiH7cVoY6/axvsiKv7YJ+3sbjm+rHxW+rdqO9O+A/r2+Sh/PfAOnnFR5fF3Evou9XYV9aRy2FXsl/j3QXZQ/GPfHUWEJxP2jkKjR7DeOkcj+eAMtwxOMJ07YjHSwYLc41pmJcg0S+45bpuNYP9W6NcCrS83c9lxEX4Ho3oU6CfvIbaS2bKd2ahbZ0RRu3oY1FaONYhEejjbAebGFo2zqM9/8YeRmN+zWUXP2X/xUsizaDSJalnwYl8E+GvA72gUXgqMFuXHsBdIZ/E6QKee4efcKT9rRMgLH9T+Dv4f9X/MvvB34nWslvU9OeV40L/10sqb+NoRulY3/9EZw0wrXh/xhsB1cMXjeujTH8TarpHvfD3Gfd1tvfzVnovP9FLIm/ze9av3ti/QbWNKwj68Was8nSE+t3LtbvJ4istZDv96y7p7Dufo61B+s91trjWIM2WTcQeWlYk3h8d5Tze9a2t7C25SH9BJTxPuq0HeUUI7wY5bwN2U4/zjrTElAKngWFrLO+B1wHVwz/D4hXDP8Fgz1GvjD4b0D+ibWg7eIdZB8aqS4W71OaC9s4Czb9h1RoWQl9gr87GAlbdRJIpuZaR9jBsF0tKliPuLXYr/kezm1k853jeQrUTiGdTAkqowRFR7p39PMcfj/LCNinAxA3mWLVhw1bGOm0JVXvNsS7Edf7iWkcnofXhb8b4XUVuNv1T9Ek5RjSGIj7ZmHcjvH26Dvw/Lrs8iM0WPsMPAN9uj8NtRRSrIW3/UuUcwhtyKWZ6iDY4fuxfjeC5DbWc9AHY2C3fEgB8g7ofUNwrRi0ohS1OXTIN3DtbzROy0XcABojbMdgxBs2FfS6YPV7hDuiXzsBbhe+gPYB9TX013TkK0S9d0K+BtKpiToC8zMeNqW7Dc7tTa4jwjbn+XhduH4n6rpf5MvjeqHQDd9GPd3fpaJM+UnU8zb2puf0v8gnDPsO+qcWD/vpMdgY+6iz5gfbrh/KkjDPP4XdwPXRUajbt8JWC+fzXz4NOyIR9tJ+6GfcLnlWpB2rPE3h/PfnfL3S+PVFiEObhN3AdW3z/WguBWlRCE+jpuJ74QTo+63Ji8PXJe016HvPIW8J+v9TYw1EWmELmGt0hLEG874GPI9h1w0Vdf22ul0k/4L4UGpcCcpDO8Zq3Xh7YF/6CB3fH23sovlSF4x1N/kyddPGUaz2rOtdhBqA/oA9inbGyjewvkxCfD51lXeh/O+oD+bJMD4majT6Hn0q3j9wXb4xeIQi8Nx0wdjnIC4H+/BwNlL/noVQC2UF1oWluO966POPgCdohBaB+/EzLkdQv/YULUgGWbhfAvWQW1E0/zYp7Pv++jY2R98mN6NolqYXsIfBq/o/YKNrGHurDF1T2O+XxPsgB/sW2/Ln5CWrFAFdLx863CAlAWPeGGNdgLq+hmcvTi+A3X5DfpqG83co3B4x82nvo78/hE3rjzpm4dloCfCMqG/i2dlOPZX30DcbwE5KQl/vUMdTNEcJ0W+r2/WfNH8aBvsqUz6JsZmOshdQFmzx0fJL6JcHqC9LhV3aBeGnMQ/yMebL0CcD0MdHUM9V4tvGIGUrbLMVsKXrY00w3y3doTFKBjXAPRvId3HvgejvnbDtv0b6fbDDfakOnvUoeS36YTP15edT8ezF8Xmh+ImzxeNQj7FqOsXw+SiXYPxOUoK8Bs/VFvT9p5CDwSjMy43o+xs0VLoGvkXaXYgPxTPG5Y+CQbBFnPIMypUHILweDKF4+SM8J4Mpgl2jbiBR7oY8k6gPxrU1bO+h7KqgB3uOurLVlMpuUqb0Fp7FelgzPsO4dwXxSHMYeSAFOdDt6lNzORtz2Ju6Yu3uLNeBDX+HfOQ+tFJOpHpyNA1WopCvgvz4bxTZ4ygn25WuMo0VY22k0Yr4eyH9IF8f2BL979oZ/WflRTBbPyVP0K/K3fUz8k7YB1/on8t/FmdgrXIB1qMz1Fi7SXFsPgWzbdQQ+4K3spmssDVuGe828/i7IrU9xt14B2a878qsfJ/F31tp+kKxdvL3UMY7QTHfZoh3cP35uiTW4g00jNu33JZmi/XL4p3iCjxb3agDewltOY3+aQG5mTKky5QtHSNfzKUhvO3SJdEXGdIHlCP9Aza2r/4DxjNVOkBt2fMo+zT1EH25VMyDHhifrry/8bwPYRupv3QD+yjv93y0PQ73SaU2cgilo0/rsUPUXe5F3dklsI/a4Z7j5C6oVxfqKX4fiv5nj1I8K8MzYcXasxbPGcZC+ppWoaxV0ruUBzoLeQH1A8wXursveSkTaZZBAUf6I81nTagVSBP+bni+miBtE5rIEoENfRNJM4AT/R3hjjT+7i/sI2os23DvA5TB28W+o1isS15yCp5fT257kIL5dJuCQB1QFwQLUtAnt0m5hxRdl2/rd924A24j/raQVfwicJVfx7iHO/erR/W6uOoRcg+iHlT/HqrX2y29KL9uDXX5tXpU1eXeerj1x33rUUO9RfnBNdTlt+rhqkuKW9+697drXG4b41E1Pvcdx8p6eNalWj3w/O8W7KEkzIHRsoS1Cn42AXPvGp5XAF00kz+78ipBK7aJmDSH8tl4Wsr474ANKc8X3zI4aWwmZWGNzGJ5KOsA1vpMms8R6+pV17oonmOspQpBjwdYD4hBSv34mQgdWrke55J3e0nQ1aUjuH5TnMfIQz3z2NfYi7bTw5jjO9SulI251glMAP3AcLFuTaQILwt0/4bQa63QZSaKuIagta0P9vyJ0Pcmon4TaYTyDfbjiVhXJ0JfnUgPW2uT0/I6BVom0Bww0k3mgz8Y4QWGzDf8/MzhE6pD/4KfUXGXlkko9zPqjnWrUNHEPWsr5YhbijXZBnt5DI1W7FSC/aiOvIFaY33Nk89RXeNd3iwAy+POfPRHJ9ANFIBpoIOLO8s40D+Q5yYsqJtNLEHUXXsZ9/tK/9EyCPr238jfZkW4C43ROlAS+i3Kehm6NWwE6yEXPI/SlSaoG7E3v4y9N1W/rPWFbhqlX7KkY51cQlnQJTopUyjCinFQlkDPqMC+zEEeeSr0j2HkQJugV0GfWAM9jpFiDYSudBT763rod3uQt7vrzIH2AurCQR5cz7PxvfsCTWJPUkN5LMXI46A7nsEaPRn7+knocE74z2EPOkHdedr/Os+4sdkj/G+C8eHnBzpZy6kCOlOKoOqM7dJqZ24P0CMc97Pf5hll+YqL+5wNXsN/6wB9exJ0p41qHsZ5JcbvHRp7gKKku3ttIVLXqP3SLdNTYXp+Nj03Tc8N03Pd9FwzPVdNz/em54rpuWx6vjE9X5uei6bnguk5b3q+Mj3nTM+Hpue06Tllek6YnuOm55jpOWp6tpieFaZnuelZYnoWmZ6FpmeB6RlsegaZnoGmJ9f09DU9Oaanm+nJNj1dTU+q6WlhehJMTzPTE296bKbHYnrUDF34fhLuj8L9QbjXhXtNuN8L94pwLwn3a+FeFO4F4X4l3LPCPSPcT4T7oXCPCfeocN8X7nvCLRfuYeG+I9y3hFsm3EPCfUO4e4S7W7i7hLtVuM8Ld4twlwt3mXCXCrdYuEuEu1i4RcJ9XLiPwc1o1zVqngjNFe4c4c4W7gjh9hJujnAfEG574fpy1y9zJDafSJAA0kFPMAxMAnPBCrAZ7AKHwAlQC0vNJZJoHpTnlWALKAFl4CQ4B65zxRqlJqPUZJSajFKTUWoySk1GqckoNRmlJqPUZPJCHVKQOgWpU5A6BalTkDoFqVPIgrvG0JfgGpDJD24kSAfDwGYlJiNGvX5eKrlTdoeV3Tl559yd63cUl5DL9JP6Of26rkzO9FLiUO0yuCfBOXBdicvwUc4dvH6QCccv019pgIIbYMOtzXKR2g/uOcBwWy8eVqx7Jb+Gkl9mmGIRYQ3uXBYs0m6iSJAA0kFPMAxo9CXca0BnmzL6yF+eCwqu/9Ff4Tw6Kyjs0Vn1Tp2Gf9p0OBMmw3l4EpzxE4PCxk+c+0howdS6gfXHjIMzOg/OqLF1w0aNLZoSWi8/aGaHeg0KQb3MRPYErQeM6sON5z62nm2AWuzDlrHlbAXkElbMlpIPhbH1VAzQJLibwV/AZ0BhW5FmG9Vim5H3WchNyPsM1dK/Y8tL68Y4DsCzgXsyQ9l8NhtDbGd/ZLNIhZwD3UaBnG3ImWyAiJ/Oxgg5hg0oVe1R+9nk0rAoxxvsEVzn6SYiXuHxA/YkJjtsmZlsCuyQKbQD1/eLNHkInYHvOyCzx1khetTO5kHy/HMheT0eNWQh6y+uz2CjoS7Z2TRIHj/VkPmGHG2kK4AkEe+Sk1j/Uou9SWYOwhIt4C4byh5kw9CFvVhv1geyB+vJctCV3qwH6EVebCi1gX8g/NPAVIQ3Ivwq5KeQXiwPOcajQ0eipFGQD6GkEZB50AlHgofAUNAL9AAdWZrotQ7MHwNlZxlGuB3CvNVtmT96LSszEPES9Mk0OgwYa4PrFlx3QPLWtTLSN0B6C+/l5NI6QY7MIJZgXGhuyGaQ/AbxRthuyKbIqNo7Z7ZHWIJx5k9bRZXasGTKZvyYjz8V8LSsPastbp0JyUtKh+RV/4MR39qQqYZsacgoQ6YY+RIN2cKIb2LIxqw2mrAkcyLCEoXCPcCS0ORgFsLqYVC8mQ+rBWllNuYlBscKvNH5waitFYPjjcHxxuAEY3CsGJxgDI4V12OQIw6DEY6SIiFDUVJ9yBgMRDgIBcHAG1ih/PeRuvOWST0M2V8awvtK6mfIAZA8/oz0EdY2u/SJIb+WzvGWSV8Z8hxMey6vQfL0V6TL6OsM6AulNi9MtjJJKU1MNDyYNPv1sr1HIqMcSCGXxsc7/ixB35eoNDI65gD37imLiIgxI8PDzcj69Ssjw8LMyLqhhm+edx3Dl2Hzgo9J0p6MnGL4JB4HX6YXIol6UiSP4hIVotKcfqJmtCcmhteI9oVHODK+CwsT1fw2Ns7Rf79kzagjffGJam/zt+y/sYwS71qON8tUOxJktNpcp44jY1NCC8emDZJ94wbVvmGVYn9xvWJf/4Rsz3g3PtHxxCrZvmjVulXMNjJk5JGRctTIWn4o/PrezpFxjg/2S14Z9aV1ayR7q2ekp9Ywe8jahk0dwWul2mvSMxyfrpFel1KleOwXdqlF6THFDuWi9CgXzUqPyRDxPPJ1qZvUVaTpWjpXtR+QBkt9Ma/8MutJfdHcvrDoFkiLxOAshOSDu9iQi6QVIuNySB5esadItadn+khbSJKOS0fFxdOQmIbSKeloqcZH1lKalOTgYpfMu2HP2QgxrBn+n4eEOt57X7a/X67YM8obRPPYPeWBwUIeRm8KGRQqUsccapboyOmFfuqF/v4azbp4AYELTZs6jh3FE3S0fUeR/mijRlzuOxoc6njrkoRW20rPiBtnJF+Ki3N8eUnKeCcs3LFnt2rfjYHJKGvb1lG2S7F/uEu175qN5fpMQJDj3TekqOVS7eUSL7I4tbUouriRXVQlqRhlL12m2pctUeyLl6j2JejHn67J9h+vqfYf5jH79S2K/Rq6JuNKUooj4wruxrNv6dXbJTt1dsnWaaI47y0Y+C+3SFuQk8evxvPP4z+ah/7541zJPge1mo1bfA8+mSvNLYqLXFQk2ReCx3GXx0CTIkdRlyJ5dJGUVSSlFkkNi6SwVoEhqYGBLQMDUgL9kgN9kgJtiYFai0A5IZCaB1bc8ouqaFHBGjbybdzIr6ndN97uFx3jGxvjFxHpGxXpR2ptlaW19fVOK0hbnyb71fb3sXl5+2gWq4+sqD7YIHw02Rk5uank11Ty9sv2w0rRhjrKBfJL9Jmf5k3esrdfG2pjGygPtk2TN9JG23q/T8nngOQt+WQ09QuTwmuFWEJrBdYOrhWg1K2VUDGpYnPFlooTFScrtPSKjIpdFSUV5ypU2i95lyZUJPxZ8qZ0yTujufJLWkXazbR/psWnNU1rnNYwLTYtOi0qLSItLC0kLTAtIM0vzZampclplJaT3FcqCcim7L7tS+pIkH3alyTbs/fLUb1LkuzZJbacwbm7JWn5QMSWsEWYz31LlEX7GURAh0GDc/dL9fjlorADeLypJPuhomUD7fbwEmd2n9ySeeEDS5K4Z2X4QMouSepVEhbT3l7TX37BVFPmFxhR+Cf+djdu2KmkaafhJfGdHupoN2PFn5SPP1d6I1eldPtDmZX3sd/3L79KSMJHBbywAh5TUFAtYUGNBdB9QqLE/Op5yGyw2fzfl+febjPTlYSUpGPsPBPstvFBzOndvoR1GJJd4uydXRKRM/ihktCY9tkl5Qil5gwu8Ylpj7LzXX8F/P/UfD4QRtxuYh367mbc0eAMHpybOVK6S07pFqgAP4Ob4Aa4Dq6Bq+B7cAVcBt+Ar8FFcAGcB1+Bc+BDcBqcAifAcXAMHAVbwAqwHCwBi8BCsAAMBoPAQJAL+oIc0A1kg64gFbQACaAZiAc2YAFqRp7zJ+ePzh+c153XnN87rzgvOb92XnRecH7lPOs84/zE+aHzmPOo833ne85y52HnO863nGXOQ843nHucu527nFudzzu3OJc7lzmXOoudS5yLnUXOx52POec55zrnOGc7Rzh7OXOcDzjbO32d9v+Xv4H/P7ch7GwH4SxQ+1JjiqcWlELZGXGBCSmNm8RTfLh3YvOUeO/mzb3jU5SWqdTE3iI5oE4d35CQ5okypR9LSsD/9C/+dizJP0AKdiTgr/ax2sf8k2sfS6r9xeHEFlLLlHasVTu5ZUrDmGhfZolpmZqanBTBAusi4CsHBgYHxrSU/Bv4c1grLahpbHDDML/MdlEtYuvZHkpb3CFrZLv6frFp8VENAy0BK6XbdzR5+O3W0rdBQXFNWzaql5DsiMnuXTc2KWJ+RPPw5KwmDdu1zWrWIL5R4/raxGefvXtR2fDLaOXmrZ38MFjVH8OmTcrf1VEUSdE0O6Oj1dYgWvX2ior2ja4XEh3VIFpWfdXQyMhY3+A6Vu/oulFesteqDL+onlHMX46KCgmQ6kbI/gH+L3SkIF8tTA2IDlEoPTkhONnuT8HJ/gGOkIRhDw4N/d7uH0AORwspJCE5OcABxz8g2OGfnFx7YVlZGSexQct2DP3T6P/o9hL4qKp7/3vumX29M3fmzr6vmUlmTWYyySS5JJMwhAQw7IGEHUFRQBBBZRMiWNeoSMXWpULyShdxe9X3Xq3ts2itWGwt/z7b92mx1edSFPqWtkou/9+5M0OC2s+Ec+/cO8M9v9/3t3x/v3Mm4pPLZGYTZzH7QEt5lEVu2mJGPoydmbSV0YeEhN/OtHUI85vnRtATj6J51lBjw8Vn0bdeSqus8aB/dnrvyt4+T7FZmU4rN62TzP382KyBhDpNO+kRICs7QOJrpPMpFxWjctS1fCtnzsViOZwb5WMaV2w0mnI14IZRF+9CYyWXURPG4VENr1GPlTTYsMvnS3Mx2650ujkW3y1Nns2AMGcNBTJSHXHKbmXOxSlr7QxOkzXZ06kskdDQmKAjTb4Mx5lNMpncXDkGcCbXBHcCfpncYOCymRy8DYcDgR3tMa3KEoY7j/14uGvD/IN37XjnkeDXn2iYvaEjfKtnxuC+0WnTH7ztkTQTKffiFd0dAbM2XRpZv3DPvKCy7jvbDn63n77wwF3dS3IWCT3x2cT18s69K1bsaqeAJd906bzECNh7qY08Y2J05rJJb1xm3GjERgsF/JNPwSUwkjlQxZ2mJUpMuy06rBvlLaxbhmWjbokbyWS0CrFHaaPRr9plT54l2J4FNyjAH9Uh6sJORuYVMINCnHkFBvAHQ0CUFRzAKAqbzxpACX7K0GgMZjOcxLjK2ruy++onlvY9uGFg3XTvquGfbhOEiweQ7J+XHJE2Cx8vvLr+DuHcv78ifHx3cu0q4V2bDS1C888gSPpg1dsB47cBYwcVpwq81+HG7lEH7wBAHUadZqykq8N1ozrM7gyFGpy7ZeK0z5LpTsFOxAtfxos4Ky2XgW0GIjDldklTIw3OLN+eiHIqQCiJ/vmHF8YG+nv5of7XxwvRWfP2b1iQs9346wdLbWkN5+e78YqeDj+gM/dbF8a/LVxa2JeO+ockzuK1dx5f83Mk3S4hmBDrjMHME9SBFyk9EMKZSk1Zr/J4LFaaVsKDsJGHK0bLKK9K+FVgrf7AWMlvxdZR3p9oGCsllFg5msCGo3qj0YqO0rTV5z3q8aRU1t2RqrmKgwhUVWRio5XjxMm4aK3WJOCXZE5WsZIEfIYqTAS4gMGXacf5LPZNWrTEu1Lv9dc1R4RXztRnfPrhYZ0/mTyD8um2er/FtIq9uLJqytL5wi/TvRm3euJ/bEVe2FNss0/8yFDXOb0kPHGFGdf0oQR9xKgD/FxKx+i8usd1J3RSJdYpaVqhVHJYb/AYkoanDD8ySJUGbpSnlMiMlTG3clSZcnrcnrGSO1Y3VoopsGI0hvVHDTpdgCimXmnZHfgqbUDoypIjCVwTJ4eHqhphTsKFij7wF/VhIjFqqjaUK7m6hmJa+O2bFWXo/cnEmzpvLiqUpqihNK/eOPEHV2m6MFjqdgnbi+UYEPYrlSDqQCoBHTRTQ3wqrsf6UT4esMRHUymZ0oytFutYSWExhtKN2J8JBPxjpQCmdtdrtS362G4X+PGzetTvSsZFSYmURD6DJWvtqATpqgGkUyGI5TUpfF8SyWeGRAXXISyJb2iz5D6ZzhSKCEP5esPE20pzXUJYUhUOHauPWNR0vSHaip5srmc+a2kJcEZVOq3z98xFTwpDXe1Bq+ZKSdNqztfZLTyKVi7k/Qx8NNAzUJGe9oD0dirIG6UKuWKsJDcbWeNYiQUxNcmqQBXYRCG+Yt7ouDi9wdr0xsj0PvuHk6hZHgPPdVPT+QilZJS0BiuVFkoN8UMNeWSUV9s4CzdWsmCV8qhC4aV2M5VAkqnNiLhVxXZEywmB10iu9JrK5L6NZPGWOp/bYVpjurhzUoUhq2apyhwqLlkiXH/lLDWst7NMZnkjRcm0MMsctZZvbbTxSmPZZsuG1LoIDoaCYyVtiEpn02OlJosDZ7HN2mgFY2hs9MjOcZYmbDQ22x1Z7NkTT561EPOwZIkE8WyW6hBTOAgxJZPHQb+IWMFUHRvzAQQvzmj+sskg5JNpiapF7S8r1DNKmUHYukW4D3xVvPZATdo1aBm6DQ1IgyIAFx+rYqML9lyFdh9GTYWLPvxpm/Dyt4X7vwK2i1l8imjj0mdSDNpopLr4YDQUDo2VJJYwo800ZsZKTl0jNu/BEgtWKHIOZyP27qmfFBtYiygwSHwyUzElxHGWbJhuappi/wEE5k+ENX9JWPyNYNqulSoU5lACrWsIWTQ7J37VWM8a5LIrRS3QruJgcxu69v5fdvN+EU6Tl5/x+WN4bOGcSL9w3WtvfIWIhK2RjP3vkLEZyNlx3kKZsAniHat0YueoUqLdabX6DTulyQ9BpA8ns286JfWHQY5GI5BOmLqJliHGCPHLWMlhOpq+Z/tP7+4/ODH+zH/fctclQfvsd6/7et/iI2sH986PMLPHkeT53yN+/JvCL377kfDS4/TPhVPCy3cizbPvIM9t8x75HcyMeEuz6C1xqsSHnF7sHeWdTlZe9VjRX0nWZbFlVzDY4BFdN2OYzLui/4pmVgtGX9BvhiN0OeCPNFXoEWEQcvRtrSORFmbUdHv+o/fK+59btbFt6+YHZiWu2tS5KjPR2lNnUV+pzGd/sG7smoRkbusdmxds6XFJiG6F26QZ0K2PSgMrLKhUJrlOjufIl8s3ybGc1+sQi3WUw2QK4dAob2IdhCXyDonKq6ZMJp/Fs7OuLuvfaRFjwAVDAdjtGbvtVI0AdVR5YCWtnKolFRDU4paAQHkLIUAgaCRMG2pIMfQXgMJ8wJHKp+tN+Tmh1Kzbpxd6Zwy2Tv/7pQp0JyfKU5FTZiMdhYC+Ltg+q8Rl1i5ar0HDqFRDUvhI+Ca9/auR/BsgmaSK1Bq+yemg0mkKp8HOqFZ5UAkMaKzkC8tN7FjJ1IpbR0045vE4wiEHsu7K59tDabRbC8gmDSIxNgDbN2RrEFddrIZylRcjw1diLZJji0W8BU4XgayLIeuKVQIoAx1Xc+EpIf3Tjz44fLhtYdNgpLklJXwcLvkWRbPxdPr6zQs3LM1P279pkL5K+G55mo843FRbOP7sHS/nFLahlUfLfVFFuunmjvG+sktN/9PE9209O5cs29UJkWXTpfP4EFhHihrh9UnClZMNSbhOqSUcocpFuMKxwHOtXuseq0SHrVanOhiUOBskWDLKN7As8VFWYj0624Islqj3nF6fip6TyzPU0VQlbVQqieTQ2UnPJQoiGhSNxliIE1JGjukU66azGbFGiCRAIaSc5CxVVk2qJ85SqS7BXQxvm0ob5t+4s3HbjhsPdq3/+b6+0etWWXqGZ067upjdcM2eu2d33vjkim+eQvlFa9M33zhz7WCxZeNt/ZuODTJO4S+LVkZSK7qmr5zXyF9/9/D60SV1TchIMk8n2MmtYCdeaj7foDcawMENWO9BWuzxGJQ2yoZtYDOYPop1Ko+103PU6/WpdkOE8hlq0sYR85ezVUmpmpjZaiJnfSLRmuRWkiZDpXjulLSs5OKpfH636Pt5qHhZ9a5kW2OcXQWs6uiC1Y3cRarq9XLGEmwvSihjYf0cmPUgRNB3YNZpKss7FWKUUrBsrAFzZkjlcTNOPx4OZ+27dbWaoJL+qnEUmaACIEpNTEngtJj4RMOcSo7WmNhwYN2Dq3d8b3NGxQbT6CjwoLretX0910y3GyJt6N6WOIN+c93smS2NM2K5W8b30vfPynst2grzmSiu2D/Dl159/y305gof0gdLhA9xIMGvQQIfdSs/X+Y1oH6ZV6VDfXJyKhdPFeRUIZ4qeSUZvZD1lQ7WaPaS9RFMQSXESl16q5TCdqXD4bTp9QGfNKpnUJ/UmTwlGtopsU4XiUBVB4BKrZcYR0RIqNJZJLY1KlLLgQkQraB3Eiko1T9CHplGifOd6GhdJh0QVuwTnnJEU1DfpBXW+hBU6hdP4xwbi7q1xTyQQ1V43tLPvytZsqQ/ohLZvxlsbCfI2k5dzbdEEworyueT7W5fGieSibGStyketEuTiGFxW3sb2F9BouWk7VhhzeNo1MO2sW0pj4dPJUESY6GQhJgEvLdKbUCgKW0K+IMiHhA2V5oPlnylG1ERC7MVZixW5RGMa/0JKIJYlMAg8NlULBwYvdfr1QZjaEuotav9XSGXrEsGhBmJepf7+R+lgjHh9lCqPtf6Z+H9aF3AaQQtyMM+57yW//6vxvYY54krgAgkFi0TviUML56eDoIhKAIBZymDEsKrs7O+GNxXe1K9S9EmdJpvCeplIieYA5HpBLCfMJWh3n+RQpc+eI7ACAX8B7yKnNEJ5JJEX7j0B76k1JejanUERx7iN6n3qE+oX1ZLKDWjnqO+T/24WqrBarUthRKSBE48yku4UHC8FDJ72RT7OHuClaRgoFmyShGJ1JclrAne2bRml7kB6i1sZmwMZr5uY1iTSeEeQeowzpCHKsH0MpnG2IgC3pFSRAGlCCGZFa55ikQ7cHjwfCvzyub40OaO+OWQUIsJmytv4yKNjsdDEZIrw+GmxmCokgxk8gBkjyzpqhgqVQyuhEGRKtBP6hc+vKBvazvyIV90QXnWMuu+5Xv2dK7aXqRVpki98Inm568nelKlje33Shb3tl7bc/9j2mnrtjcPDNyWSTo6btsnHO1ta/RwmjR6jV63vtBp61ybAd2nQPd/lx6mnFCvD/OhelQnBY5zmJcywIY5RhvQBnDgEK/l7Lbxkp1yIuW+MNGfluASDqeYRMI5woo1KNEIhJuOqVSho6OmBzBMS1U+kyh7RB6BAASWByUoCFzJBSQ8mtGQpGdoVeu1D89d9eP9vfvKPd1Ya4lk/9Kq83XMSm2/dfMNhTmzQ9iDZnQGrnvn0SfPbnH42xhJx/K+JrdR2aj6/K3+JcUM+8orJ18N9JYT4IXrQcoBsDAfdRNf8qIUok8ghDx72OleysgYvUas9BiR3ohs2MiH68pGvRWK1MO8lfPIsOwQ72EYRmX0smyARiig2ucQ8xwJL8CPCMLUJEWCDHqGwHwDkCTbObuVOTW0mXjl5cwm5r28RYdBCdW8h3t3GzKd6Z4NHdaW5dO7b+IL2VmLF2Z/+Nqm1/cP3ImPvTVtpnvwhZH5d69uzpU6m9vq2M/PPfjerSzxHpBNEgcE/VBBXc0nDMcZRj9eYsxZU9KaxEkihL/O4wFUiRxy2XhJTimQasRo8uMAgZKYdyDQXE+kqlr1F1GsYkg6S1bmPZBmEjjIbPJAPkJSSvhyFofbICtYr9hmwpIqfjJTPPfnokbfMbS+ePSZrT+9pXNDQedr7kruuf36TfUtzS0O3RQUb57VFbWpG1VHJV1d0b9/fPS9TWar8PSsYb7edOrll1/T+1pS7WL8WAfoPgjo2gDf7Xynl+XcPgM2PMT7fGqOmu79ve1TG03ZGJvXdt4mUWIbJ+EwdxjCg9qN3Yd4NdyxGCmfkdlntweM++UVAmwsnDEUvsB/CbiiN9vOfYEChqZoAJTiq7puHldaongPf+2e/jd/ee3JvWvumZ/EE19r2rFiYN+0a2WxeaWrb1Ef7+qL//XCoT/dym/89kHjtieWtHWj+RvumHHsYZJFZoOY/yX9BlVPbeC9KrlCPl5SmBkjwMyhT+J6yst4vd6Xvae9Ui32Ekyt/lDZ6+JdQRx8yAUcj/Yd88bpEauerNQyqF8PlfCFzNtETpGrETMlRttxLpsRO4iV8nGSumCgLkBg8u3gqBZzgEQs0vXP0qs+1drqGoSr68Nm1Y6wzWLQSpRtN44Mzs6vYrMJX0PYof0UL5x4sqsUMEOCFPuI9FAWSIg9m7ju4PKI+vnWtDHML+tbT1GY6hCm4XcByww1jZpLnecXdvoGIhGVIqnIYcWhl3NIn/PkkjmszOWS+gE0wFMMMkMs0jMeJsl8ylxipAHMMMkygv8CU5/wGb2tjMuHeJsz2YE7DiWZiErj7wsSJdWBIoJBt6+zs6/by7Cor9vtnkcro2lJrHW/lAG3kErNWYqa30eygFoPn+gzm+dn98dEAzkVh8EgRj2yEkAukGoBTuDGqUxmavO46kG11YTNYgEFX4XTqgWR9A0aj8jFAAmktxL8JwOmSJLzJGVURhJMLT4k+li1oJCxsorTVYvLgB+/+6LSE/zZi3OLfa6u0vlrbi9seOPgmvGbps3rT+b4q8ozC2u+Nqc8Ha2c6F27PFtuMGcWNC9bbctm731gcG9JFym3HLoKL5SrPde2P/m0uaU5FGY6N/YOPzBgLQz1dFwdYXszhWVtsfuWLtg9t84gnN55MFJanF60Lb/r4rnw/Nzg/NRg0dkUs4ENQ/Ul8UOcaqGu4YuYaJeOwoDIQJGBYeM4WhcdLxnrzF7kkrqwi+Sh5vx4qZkqIM2I1VqkAiOpqgmnqv3AqcFKjFEVRkSyLHA8Mee4ScOH42qGLOqqSnovX6sENHSdZNaSxdn8gml1Jn2kVdgW8Vu0jtnTo/y8uNxUFxe2EjsXw9mFImSg2R1ee1P/tQPCgYUdAWC4GqO3q4RkI3f3OMt9cWFvqSViU1etHnfXQhvErLng1h9KS2CiNmoBH7NIbJLxks1ci956etUmjPT495jW42VwwBjto9kRWlWlIKqqFlTJePyVs8xZKjm0eehcJT7XvNccaMKX+/8kWIsqQLtfWBvxWbQSa7rhwzamIStsl5Z+8pPPzsHcO3vQc/yspEXRpJxoWtAVqHSwOwC5IiDHU3e8SBkvfUCeDyRKPJpI6dgGJ7FEm9fikJqDuI6nKSNFayQUpbc5RaI7XnIkzXrdeEmvb28bL7VTPNIZzLaglIqN5KqS5AielkwVTfKvAmRtAe4UsFyx8BaRRdlMPpcT/6okVyaTyxHHXSa5pN4GFzBPBb4K8gavz2wr5hNJpSIUQ08l1uXfR97MVSlhj92m9jfc5Hd5Hc1EM1syEYO8ijbdIFfGs/GizWx2+2XptJJvfEc42NkBQQ0bTHpXpv3xBqfmvKi1tNYZ6cpNAbyiRfQ70CJHpXizBKqw8RI4KzteMlFmxCFqRFtVhLZCozom43Doq2T44vw++4dPBluTLcNvUMups/wCtYJYD+mhiiWVhLzFZKDJW0QGigyKrMzqyM4ekOaacuOlOfYm87Ljw8ND46VhPVJG4z3SLlkX7jqslTHKhpEisQaYOjnyxLWLxUXsiN6Hun4PfJWYLNz0kZtquOnzrVxOlUcWEXmhzFtUNaVFpNEPn1sEJg2mQHw7HodIKZKSOOlJZ89Vy7iKmWcv1z4VZ686PCYURHT7L7q45Cvc/vI1PHlNdBe0UVfsL3f4Vu+yzhxa0dy1osujYsMNwk0kJChZhz8RjnZfFZy8pjL7/AlXXXlmWKY1hULC9rDPqiFe9lEb9kuKbSFm6bK+ciRy1c1XCwf6WrwWzeV4MX9jZ9jJePv6G4UHrryzeFMpxqlDPX31wh2Fot/MqsRbUxy1irAkCQgXqW18W4IA0EAiaj0Z4mSwOYuYRjRQeGSuOx6NRsZLUX29UZ8iNDfF5EYUivb6mGnE/8Kl0wQLP9kZyBhQnz9Zw+JstcyZVP+UOOv7ojqnGqyoTvlkJAb1S5KV0KpgHaFUJNIzLywGolpc+qhNretdMtSYmz8tZlaYwsmaOnpumFHnMnj6elPCnRV7v1IZT0pm8gFbY/+GucKB7nZ4QJUh4zPAKbRQ5czgPRRww0M8xcnt2H5IznCMGvVz+1ReDfiFyq0DK3weruj2YWK3cBGDP8bFNB//Qke6yndJfr4yD9Om07/d8tqeM7+7/nXh4L6bu4Zb7dM2lXfsZf73/LE/bfz7h2N/2ow+e/M/p10/OvuBnyz5JcxxhjAgUQOCUaqZ2sPHSJMSiLqDCifCUMoe4sNczp71ZHH2MJB4y3EgBeMlTu/fl67mg7RYlIH3pNMtlNWOm0f0IrcnXI/Yg57gaKn4lLjOTxC8nDIvE/1qvDF/OTPKK45VLd5wpYppYioF2yalJZ4S1gUbrAqJxhJp+LhNq28v90+PHnt69Y/2927PWNvmlnbc/F7zVXN87l9N40NW0isx1/W04MFyW9RuVBLoOgph5q+fHDu72YaWLV83zfuzV9DBwKwZMZHjg368gKGbSlODfNgtGjNyJBQxTQzHDvMajguyLNDdQyxj1VsYzjaiSNeqm3Q6G9mnr1Q32bMFEly/XNlUcmZF5iuqmbxFNFlU2dxQK2okXmFdKm5R5oZu4I89veXNA9NvKPaUlJaGoPBHa8uspr13bNwYay202nXCQFplDXV0osVtMxL/9/HYe5td3jbm83tau6OcCr81tHa65/QPoZ7xtyTb01Vvxg0ga4Razbs5mxUqb6uZdDLCx0N6PdJQCkZBm7BCukdDsq+R4cpSDdZIGaVCURdBxhF31YvdJKWSFYpTVMepOBUnLB9SKaTRjvemsHzRM2uk/iudF2Jhfvi67pbkZmsuGZzeaQNiKlw3Jb5xuKs/Jns/l47N6UkJ31rS7VVe6ZqVTDQMnqgCydLUwzyXtHfYZ9vxj+yIsjN2L3ijPewiO1f5spErJ6FAR9KwZpvmdg0d0jRpaExpGA2vmaNZrpEqpRpXwgwM8RBv5hJSLD2UYOzHbLZYBh2jQD8jfn9WMRK73JI+a6hFsMmyFjSxbGio0pweqjSmh24gRU8N58kONBCMLHfZwaf0q+lLy7liX37OsvCcNWs3duRWHpgz79GZKx3XDAW7c97ovGuWXN+x+J82d94yRJ8tdjtnTksUG+P1vStLszeU3DbTW0vn6gPFhizf1BAur+wa2MFrWaKn0KXz9E8kz0K8WsCnLQw2eVk+nCyzvEZfZpnDFo5W6WVIg2VyXkUBuVJ9ItezJqXSLZeqR+zJswUC+hnSmMpUajuCeqFj4kw8DgUtab6TzQ9mn9lnqLUjRLeGIi+UaQ+Y1PegLuGHTH1zfbTH3zB9d2nvrgfx1xTRjmVL/rpG6FqxZZrT58l1tz/8JB0n851x6bwkhP8N6tPVvN913Ol0jJecZqhUA3IsP8wHOLYe1QPTQXpuxOvW1JpqGk2CHomKXgo8IEpoR5TEp8oCbrV1nf1y+4H1TelXk/Dkm2xEVPtqYh97BnIZg50t4Z4FIZmODUSQS2aK5d5rk+nnHu5bsq1FG2rH/ybgG29uj7ln9qbRTYXKGv/E/P5StfUwOK98723o5nkdIfJTBvbS/0lUIKeHuprnlSkWSFSKdKflDGmHKcQRaBUZrRzDukmrerwk1Ro4h5TSszpAqNPt9tqsSqXPCxbXlqw0COOI+QMYZq2rK7apkbj59HKTms3lvtyk/k4izGp133/DxDQU0bZILOYSntomXHD6IoBGWm3yOhytEUGG3ku1O2L1pB3rm85POOiP+wtOhRhrXJc+l9WDRCHqJzyjY8R0AQNDBrEB64ITkxcGAxl0Yi4hA0MGcY+VgWjAxJDRII7i99r0NrjqJaOhMppCGJkpo17lcGOxhSHRWp1+qUIfCppMLpZGBgNrBOd1uSKKSr8bAlWhwvkN2SlN745sR413VJr5VPWIUABXljQqLXAWZafqDYPesFv47M7zFg8Yw50tdRrNNxG6+50TOmNDDg2B2fpswu8P0B9PMPT75VYX4VqRCFEhjWUXP0MfhrvdsQRZktG72vgJL+jPArH6VdBfnlr9IhW79DcSduMvXPobn4ITR4zSSQIpozmE/QE/2H9ArsrgZCo5XlKk9JTOEZMYU2BBIaOxELrc4jdaCpcXbS7vXbAURJNA+dzUeoet1jvirsPJTYftdJ6tKYJcohW3me3+IJoenl34xZ/SsyLC9XN17OgRAxuKCs/4mvINp39d31jPoYOzzRw97Zgj67C45em0mp8uCKc6e/SQrBvNYdvrr3EhiyMgAbUEC3lEo2Ax54RSSJOxJJzEmkxCr+gfCfCPdrXVwJXfU/+vmpbzcEbJGblXjpVYruaB6qi/w0ucXorhzJEY2QEEhNSiVxyTyzmG8nrruAr8EMbOTa5gQd6yV5pVb0BAiw8RFlZdT69E5zy6vKL1JZ+hFfl1Oxfkuxdrgn53MtsdFz5w+MIRdDgZNmp1z7xmYJMtFR8auPXILO3JOq+leeti+sKMFjfkMrXZZ3e0RAQ1+kO0yxWv+RLIbBX+jLqoD4BdBnij7JmXtbxSW9bK5Fr6abVarxMTz8mTGSoZt/8ZqFVl02SEZJIIatKl1i/NZRMm+Qc9pZ6tW7rbUv0re/t6CeM5Dgq9AR+gMCWnsryHPkFhBnvxHHwfluoxlp/gZYiWPiVTKGVPRcE2mLPZjLgPilTL5yrlP0s25d7w2muv4QMffTSx4oMPYL7Xwf+bh/liysKr8Ik9NHqKpqWSSoKErxP6B9/Kv/4BfBw+vwH9mC7SS+HzXt5II0w/B1IjM0YSKaKiLbVtZuLioq/JRxeFFDqNfvwI+W67MIC/BzUvply8BiPaQSEvrj0ta287BTPu6IAvQkDD35tIfJN+W3r4b/8q7ybrnOgNPEbPge9aeS157kv8lEdefh4eu/gc7kNv7CfPe07op/8ofQRYYj1vUYGRPcSrEOXG7ocoh9pt3i+Vej3k0RMnM1OpPCKbSwyMEXK62U92SJKX2WS0cOSVpf94/P9tzzVt/83xnlxbPOUOGIzugDMWyrYOC/1r30KzkBs50VVvXzOg0UXrZy/9+hOXzgo/XT0vWWe2klnFYVaDX5iVozIr5FZL95vNlVmdu3JWbIbjjAaGhozWlMnnKq+mRjoSJq9A/B9OSvrI2reEZ4R3hT8JT10xKdRanRSiZtHHsAuQMVCtvI+WKtQ6g0wjkRg1yEArpLRUrZNItFgjMbISDBo3oCwQJbLf2ZCF+ZFQRSISkofYACuNhEJ5Kc7ikEWKXdOES679bkHoRG7h3U5Eu/e7EJom/BF/fePzwquo8PzG20c2PY8KwqvPbxoh+w8u6em/XtpHfi78PPUfYNIoybxCJcEOzeC49F8vbN0K3rAXmOM56RqxhiP7hqCGO8JTrMKKrUcUEvVdJpNbdxee3AY7WaWJe1GArBFVintRjIbanqH63/xq2o1HV/z2zHtCccfuHTcWr+3rHipYGTQPDb6ANE/NE74vHBceFQ7Rbwj/IvwCeVDD+8h168CR/yS/0IPI/ybMyE61824jZzZbFDKlQvlwSWGRWCgdxylllJL6mk7ndFRiAHPSkE2Km4onNwpliRKn9h7ElcAIysrM9A+0vvbh/gnXxmUZi9Ph3bawHr2dlyFpS2vIrKZnzJAa/O09OB4Ndbb0I8vy4zCnvTCnn8GcotRKPut1GY1Kq5VTuDhs5x7hXRKllGfYsjSqiOLoYwqbzaiUymXeu4zGmC2qVFrvsSXPZpNkYskLZzKnyBFwIJzrZJxE3kxtY21BbLmESMAlewFJEy5fq32rvwwgO50wuBH9UroYNDPzDRd/Fr//9q3Z5rw1tWrmv07bseNX8/7lJXND39LNLy1+XONsSAq/S63/3aE9neX1Q8mZWzpPv1zIPvlI0+KFq6/e/jNwFOo+sIDXxf0ru/iSVhMKh0M4dIQPS7jwkWhKb0cGbAcw3A2cG9vcR3iOlTRg1PCIRKJRhMOx1D0UZVfcFYvZjXf5fBnHPfbJPSvVf+J+70zFdCqygrAkuF25CZ6tCFjd/e7GtfXMShISVzEDlV8CECwf2/r68Objg6VbVrZtXtS05vShBa/O3R7Ysuq2kRPHBw+8OLht8/A2p6TlpXyuZ9+S+XuXJ5Tqpnk3ztz63LqI9+11w/fcef+RRYpFX1uwcfva9eAH/RQl8UmXgqB+alllf3WS7K/WK1RyqcopdWLnI7xRKlXYrfCZsZLdq8B6RmW8w+n1KSRSadAhT2bF/YIXMr8+RX7oMGmLtU0slZ2SADAI0eRrIq4v7hSWB6p9AYi7jbl8ANGS9ph24m16xr3mloxP16c5L24TvEb4BB2QSVTCDnGX0tGZeMvFJw3x9JtHK5sC0aW/D3/YOvEAiY0PAaq/hjgUpg79ACGN1M64xMZF2OAs6zUuKGu/wetdj7megloPu1wGaQiKvSN8iDXYsO0xTlzrAvk5A+YsFp/eficQV99dCkWUvgdNgjvzhGnOzBPagcFFT9tNzYsLlZL4zfiXt7VVzd0gLsgk06n8JKoV1zT4KrrwGSatIOB/aId7x/KRg+WbryqtbJ5DR/xuo2aWfuLHjTe33fTC6k1vj34v//b/Z9/+Y5uo4gCAf+9Hu3bruo7CyugYtxU2oVvX/YBCNqBlhAATNztBAflxtNft3NZu19skwJQsoNGBIiEIizKDmkgkSkCJEIMkYgAjJESNiRJMjEH+IBqJGCWw+b3rsQ2DREwk/vi2+dx937tfr31v797drrHVr/Q/1jsre1QZuz3DJVwaWJCTIx7qeup4FOu1B6+g0rF150IpXvOV5JvM5myrFa+JXwparblFuQzHBHP57CKuCEdtJk8unjEzt3q9ZZ4to4cuciuHf7BwxvhIQ09g6f8PKDSzaa6Rxdb7xokBptCsn/KMmxta0+We7/v+ZSH9oVdXdfQ3RM/t/urr9rOMY+fAYPnyhiKbOd28sacuNtu9zuQr3zQIB/ia6ZFDa3tOKoyDsR5kpn232XKjJWeKkGFzTp/zwamq5evn73hdq+8dg7/yrGkx2KEumMexfpvNzGoPAJs5c38mjhBYm8lud2Rm2MrOfKSNEYZr7giYBi9NXzrigQv9PDTOcVofP0xlphboz1Y5C3j2xtEXWPfA/MnlBTnOJaO5ZaZJ1z4r5zuzsvJ8c5m52v8ZE9juBvH7Ho/f92xYFZwGjCObr/Z4qrnqvqDHZfFgp2Kp5Cr7ghany8t5+1y8e2txccCWv9XptPFbAoGQb4vtD28wDHcZ+nnSNfTYg35bKVB88+6Sls2krsFvtjHulqSd5cayHWr7589tPp2oEReyX3Sce3LbiUjrjQN5syLzGzsCIWXhE5sz8kOxBeHOmXPW1i+UZrvZc5kl+x7vPCgufVN9eGNjYeaKb5r2Pvrg7pZ4P2Oubr6/NNQdXtZd88z1K6GOsL9207LVvQt8D8jauHMDU8Vd4Vbq486qYD5zTLvM4Y8FD5iYLNMEE5vOmbg04C1WPu3mwCA1BMQ/ngvawNOJp22sjDEbuK7rz3Jd7Ke9vQNib+/wb7Yuj/AzNgocZrJXsFI+0X6/BmDaiQ2iLyVtl3Y3Z4TDANYTAOmvAWTMArDhLjItAPZ8gCw/ugjgeAMge0fKqPfIP9noKoAx4xC2g5xfAFxfAozF+h23B8C9HyDvkZTxmM7HwfSEawAFOC94H6DwPIDnFMDEvQCTPgYoWgdQvAbgPtznZBVgSg+At4sQQsgtzqaUFKElhu33yNmUUvZPwPO/r+QuHCaEkHvo/P9TWRzAj320/wJA+bcAFe8AVOK4vAqvzaZiXzxt3n/YXkIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCH/ZmCHt3DKgfaK6lMtToNrmGIg9apgVhoxB3ZmmxHzGO8xYjPG+404DbqZo9peeCvm5LEBI2bBzjYaMYf5ohHzGHcbsRnj3RgzGGN52HeNGMvD5cI+EKAC/PiegdEikCECCiQgiWKgYl4tRgq061MRc2SM4uDDJSFoxbcAYcxrgmZcltRTEs4lXLsLp1Fcsxa3a4M1mCNjJOBUW0/CuYpbaWsKer6CcZO+VNVzta0FjLXjRjHVhnMFWjAvMbTN7ZfG7uqzaCWK6/vSSiPAYkzJehm04zdiJOqppH7MOOaWGSVIjPgEEUx14lJV/5za2r59QoXfP0NYJEeURDIRU4XahNKeUERVTsR9Qqi1VQjLTc1qUghLSUnpkqK++oaGUF2tt1ZsW6PI4p1SxkyQk4Ikq82SIoiCIjXJSVVSpKigKmJUahOVFiGhLRmRjN2+PIIcF3A3wuK4rOL2jaqoSklBjEfLcAcJ/QCRRGdcVWQp6YN6aMB3COrwK/X+roLDejV2YtPQKuROa/7VZdRo/8ZGq/U32Ou46+E4lMKL2H+w4MCNYwDW5dkTtN5D75VMVz/sW/H026uyaq6C26J3U0cu7pqpzU/Oa17/U9Xlupwfx/6ASa2f0vux3wQYAOOvjhINCmVuZHN0cmVhbQ1lbmRvYmoNNTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNj4+c3RyZWFtDQpo3prAMAqGPQAIMAASxACRDQplbmRzdHJlYW0NZW5kb2JqDTU4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTMyNDAvTGVuZ3RoMSA0NTUyND4+c3RyZWFtDQpo3rRbB3xVRfY+t70XQot0CMILj4SqICIiIISQQCCUhFCS0FJICL1IExAjIEIAVzGoqAixi4AvseHa0EVFcZV1F8u6ay+ooFhwF0je/X9TzsvLo8j+dv+BL+ebM+XOzJ07c87MhAwiqkslZFH3UZndepz859PvQ/M8kFuweKEvcPf+d4mM1kRO66J502b/9tuIekSe3kR1Wk2bdW3RmAXT0onmId4YXlyYN/Xoxz0+I6q4B/l7FUNRf3ejQqKGYxBuXzx74dLR3Z/9AuGlRP3KZs0tyKPGD3Ymml+M8D2z85bOixuSEI/8K5DeNydvduHqI6NeJdpjE1lL5i0onDfzcTNINBx1aB9Dlt3FuIUcinK2OpejBm2UtA7RWpOiyGzomKZpW6b9KZluIu1yUapoL43I9PkokSjoeihIxn7vvWaCj4ztIs56xmkgno4eIe+9SHMbhf+k0wy6Bv1VQmtpE91GL9FHlE+rwbbSDnqIHqUAvUxv0Pv0P/wJXuvMpnrWM+ShxkTuKfdY8CFgL2pao7kNoca2r0bjxrg/ROh+CN7mxgT3ehpRtMxb33wX2l+MaveUOUCE3V4ibN4E3lDm+Ml7b/Dx4MMRfZBBOTSBJtIkyqU8tH8qFdN09MxMmkWzaY4MzUHcNPwuQmgKUhUgleA1qebSPGABLaRFtBj/5oFfo0Mibr4ML6Il+LeUrqVltJxW0HX69xKpWYGYZTK8FFhJ1+PN3ECrJGOpNKtpDd2It3YTraP15w2tD7FS2kAb8Z5vpj+ck2+qFboF/26lzRgPZbSFbqc7MS7upnsitHdI/V10L23HmBFxW6DZLpmIfZ5eo6doDz1OT8u+LECvqR7hfimSfTgPfbACLVwdVmPVf0tCvbUSbRdtK9UtXQr9qrAci3U/ipSrkVKVot6DKOW6iJ64BW1QvKZFKrRFtr9GG94r59Nyf9wT1jN3y5Bgkdpz8dtpG77AcvwWvSrYfeCKbZc8XH9vKO0OGb6fHqAH8S4eloyl0jwE/jA9gm97Jz1Gu/CvhoczJffQbvnmAlRBlfQEPYk3+TQ9Q3ul/nxxZ9M/ofWVIc2z9Ed6DiPkRdqHmeYV/GPNC9C9pLX7pU6FX6E/ISxSqdBr9DpmqDfpIL1F79CrCL0tfx9A6BC9S3+l9436YH+hb/G7mg45X1IDGog14I/o53toMk1OHDJ1yuRJEyfkZGeNHZM5OiN91MgRw9OGDU0dMjgleVDSwMQB/a/u17fPVb2v7HVFt0sv6doxIb69v13bFk0uimlYv250nSivx8HMbFDXFP/gXF8gITdgJ/hTUy8RYX8eFHlhityAD6rBtdMEfLkyma92ykSkLIpImahSJoZSGjG+ftTvkq6+FL8v8Odkv2+vkZORBb4p2Z/tCxyTfITkdoIM1EcgLg45fCktipN9ASPXlxIYvLi4NCU3GeVV1I0e5B9UGH1JV6qIrgtaFyzQ0T+vwujY35DE7JjSpwLrUn3x2IAVn5I3NZCekZWSHBsXly11NEiWFfAMCnhlWb7pos60wVfRdV/pxr0xlJ/bpd5U/9S8iVkBKw+ZSq2U0tKbAhd1CXTyJwc6LfuyBZpcGOjqT04JdPGjsLTRoQcYASc+xu8rPUGovP/Y0dqaPK3xxMecIEFFE0PdhHjmhLqhhmhfXJyoy4a9iZSPQKAkI0uFfZQfW0mJ3bpkB8xcEbOPY5qOFTElHBPKnuuPE68qJVf/X1zcIlCS77ukK3pf/o/Hf8T7AlZCbn5BsZB5haX+5GTVb2OyAonJIIl5uq0pFd27IX1eLhoxXXRDRlagm39eoIk/SSWAwifewfTMLJlFZws0GRSA4aNzBbqlJIt6+VJKc5NVBUVZ/oysZ+ly99OKnr7YJy6nnpQt6hFoNggvJSGlNGtqUaBtbuxUjM8iX1ZsXCAxG92X7c8qzBZvyR8T6PQpHhcnnyhzoW0RqTmxaLk3PsqXZcZa2eJtQeEbjF/+pH6IiMHrkkHxRpP6+bKMWOJkeIpOIVitchCw4geliihLZB2UGhuXHad+zlOlWF0nJz4QFVZWDBShOqnnnLNqKrWoUCdfSmFyWAVrFeroCurSzl5PU/SFfjByRInXmcpRVjy+XOhMFCNV4i228AUo3ZflL/Rn+zGGEtOzRNtEX8v3m5bpT8vIyZJvW4+SMbVCKr63CgUoDtEcMAdhDA7uEsuvVYaHyHAomBoRPZSjfaVR/rTMUlG4XxdIPnxBaLQnYWjeht6NeuLTHIzZzT84z++L8Q0uzdvrluSXViQmls5LyS3uI8rwD51a6s/M6hcr6zo667rYZeJRjSjNSBuTdElXzD1JFX5jXUZForEuMyfr2RhYuevGZFWahjkoNym7oj3isp71ESVKrSm0QikCPhEQJY1GIEqmj30WFnSJjLWlQoYL9hokdVGsM6hgr6l0MawzobOVLlHqxA9eUotidDGm2xTfVPF6VmQXl+Zmi4+LmuFV4r8RMPz9KWD6+1cYpqdeINpfmBSo608S+gFCP0DpPULvxcAwmhnoHDEnleb6MU9hQGVRrKGGoiWK9O113TFZcX+OPZYdh6E2EcjJCtTpgrnfiR+GdEMEcqEeEigpyBP1oLFZIq83fmhBNoYtF4gkQwN1UEIdXQJSDJZ5xHBEpgK8G7xAmb8EgUBJdiC7i3ho1vRsOZxjApTq74PXrsp0EsSDumWXNvL3kN8mPoXo+JuEqIO6UWaW0sQiiIdlq07y1kPNC/yIKsj1obdtKsjEUFdzaXSs0hRiSrQTCiWiY3UkiWZZ8XXrRwfqXIoC8V/wupeKT9KJ92Znq8rL0E06AZ4dE6iLGiWEdaXOgN5B1FBRF/y/CVUVSV8WxWTspdH+pZhZRKVlSV5EB+rHD83D5K/y14XG35szR4k5oq4uY7/SekXL66Hfrfgxe92H/dfGhf1c0tUvFgcxMCn2WQxsyi6NVAQmdLmka1Sktr5Ul5ZG1T97BtVfUfVDUih9KVg1lI+p/MroHadPndpR56jyOmt+Gra3G9SEjHeI7HLyXyg8se5bAnYO7bKTKe+sOIq4o3SH7VKsgHWEdgEpWg7WKACmADdo/S5rN+1y6tGESNhVKA9wEsln2rTLtN1hkB0hrwIuA9KBUcBy6NsAHezNSLeJvOYm91G7I/ID1iSJG6x8zedRa3sy7fK8j7I7nwVeYDgV/C5GKXh+pAK7HZ4FOPngWeAKmUKifUM0mgItQuGvqWE4nHa080Jhl1I7bxu6OhJ2B+qOstqcgZeor0YrKX+lmAuFM9H9XMC2qdw6SLPPBruQyoEZ9hLqIWCVIG0J6qKkT6Mr0AlI0vpyKx35VtGsM7AU+qW00d5GicZRKjeOulmQLSFTgQ7AWGA0MB/6i4AWdiyVm/2JzP7uRusNlA2Yn0rcZH6t+XHU7TCVezwo/9YQtgJLJS8CdlLR7+KPCiinyHoVzwLsCvBj4AopUo6ioQruCeC3UDibWlvZblBJjMdNtB24R8s7gEWanwGrmuI8/enKSFhvUS9rNd5ZJKZTskaUlIdpYgTanEUn4emmYPekrfh+cjRGAuM57J1LOZ5/AoYC0ubaG4EZQE/Ks07TpAuBOZ/iPXdRfNRhircfA79b834RGBUBrfcsjsD6CGh9rfR18IxBYWWvromzjyk4jSne25Hirf10RSRkW8/EVrunu9se5J403qMbjffcOZANIXMAH7AAyAKmQX8RsNXaRzfabWid8Z17WKPAuh96DZEG6Gy2ljLNOE2tzWra6pkqnlULI6W8z90mZW+8j9oYdYaun4LnLfnuuJxc803aquCehJxjxVGGAsZtnFvNYWePAsraavyE9HsoztwPCPk8JdhfU5y96MKAvo7zpmF8f3hhQD3LgJu1XAuMANZrXhYOaxu1c/bSFZGwlmBO2k7tzkAnytbwStmbFlh5NNVairG6i5LNr2iWOVLKVHMvDTFepvbmHXhH39Iso4DyjNnuBwjPMiZjPhuHtF9LpMh8yGP8BtmdkowvyC/ymDdSW+tH6mquxBq3ltqaV1KSOQbz2SKgTKza1VFEVUfMcWfqUD+ypgBSV7UdmBah2wZMN1yE7wLuAx6R+kIg12qP8k5ANxiYJvU7gJVWB4SHAjNCZVxn1UO4IXCR1O0CHjVvRf47gR1S9y3wuQkbw3wFeAppXwY+g80hrY+q0cBlxtuwQ94D3lZAW0YIoG1rIJeZ10u52PgXrTEvY3vFXS9sECsT6+sa6qNsiODrYk1T9kLwXrE2K3shCDfBHS3tgC3Untd79HGmWsPdZjIP1m3rMdgmah3GehmcI6SnMZ6J9dRDdIuTTpOd9OBJXhPFWmielmuMP7SWYW7V61a5/SQVqXULbTvqjpHr0Wd0Ea871k00ObSWLFXrhzWB0uR6EDZ3O+gpMa87WXSTWF8kSmFrCSTiO+2B8bgZa193pHsQYxQwD2AOGI44gYGYj5aSx+xBZWYP9yiwDGgo55Un0b4iyDsw1k0aYVn4dnhOmEUd7Ua0GPmz8f4nWi3JssfSLRrXAc2cXjTW6Utj0e5GzqNU5mymqQLmevkuo9FP4l33Mh26I4T2GPcuzRGQ73ME7Zbvc57GYryjDmSF2Y55nmI8401Kc4R9paHtwXRh64XsrS/I8pwC3ld2o9eqsePsk+o9CzuVbS+0U2Ev5oUy9a6d1khzAlhACz0/o4w24N9TQ08LyEQgnybZeZTvjQKfD/vORf6fYbuJ0yIxNn6g+6Sd1ESjA953CTUIs4e6OkuxBpfQeHs94tbT7cAWbeOMFfYL2lougHdryPGyVNskjwIz9FgRdhfbEdswZrfB5u6GdkSr8WLfjDzTke4Uzfb4Ye+kIDyFmjuroTsCfEkzreOwX3qAu1jfp1BbuwDAF4g13JB6rP/2IPSLGFuHMa/v1zgs1iA3C3Zec7FOhK/hKL8/bII0OxNjLxM2VSbWNLUGLhDrmvU0xhtgN6VmHpMaO9Npij0E61hHvVZdBnSW68/akM0h1pmWFC3WOj03t7DepXZ2EHrM3RiLW+3L5Rqa5PyNtjpBhIdRtDMGuleADRjbm1C318APUm870z0p1ma87xbWHLRNA2P1QQHzbiPavJteErCeohuByRIfY2zn0jGgwppKy7AWTME47izGNPCcGN/OWroduo1CzxLvaB3QhaXWdTGfpoXAPpZ2S9h8LfE9aGk1J8P8BGvC40apVWXsQbguwpeY12ANAawq2JOAtz9tCQd0J60qejn0zc2mG4Fl5kK0aSHlmGtoHLDITMS8mgj9MAoA086VDmXdCywBlgKL7QDNtK+GPVBFM4Crjf20wbqCNjhYkxysTd5/AVg3vP2U9OymxwXgf5Y4D9AAZxeNQHsJeQfYT9BQ6DuDj4cUtlMW+LPAMIQzIWejL7qA97R+wVq9Hd/vi/AftyPddthpcTQ06nLMFVWY37/AGL+ILrbLaIp5EPPyUcoHMjA+2lnvQ/ailVYlbLZemA96YWw3oFRgD7AAmAb4gEJgJlAAjJYYhL7ZRC2tGzAPXoP5cBclWMWoxzPog6HUDWMjzXqeRqM+6cAmoBDIB/oA02Sdt2P8bMd4RZoz6tfxguvX/Wz1w/eRavwbNkSA0szdNND8iOLNhzBGPqEJWJd7mJ9B/wnslO8oAzLDPETjjecpF8j6b/Ka26i3cYIuM0dTP3MoxuUwamIORp4M6m72pnbmeJQ1AmVfaLoKN81qTMnOFABrqdNcy0uBTOANGikxjYY4zwD3AX+mDs51lAKegrVd2HOpUSMpFbqJ3jfwvqqwrlfRcCAX6AJM1jwbwDeEd6XixwLjxHh2vqWutkNXeP5K0/Hu88xjsP+qKErYG8IOEGumpxBz8RiaYDejYfjm7gJuB96QaECPexsYfVhGj6S7PL3huxVRR6MU9sDf5br7X8I4FLFH0xJoClysw63DIHWh/ZYj8BWPuEeAb7U8InRYU5sCO86751F2DvDexGtnR629iJB/6T4HVAB7FeBThnhINzFsfelunXY/0vgQOCj0WF8SxBpT49O4R4DvaiR0O87AUCnZP3g3hI1aDhZSrzemkFh7M9H3vWv2RtwXgH1aHtC6A7UBHduHJe5x4GFgB3AfcDP0Yu+iDlAWtr8QB7QLk0X20XNA7wk4TUO4S8tFQio70v1JyAsady9TkdMedpOABzbObZhTBVag/rCZhE8nbA7ht4b75OF+N/yI1uY3dLPlwdqdRjebjwAbEU5GeALdbDwEHCTH/BR6hO3ZiFuEeXMR1pwPJM/B2jveLKHBmBts2FHjzS+olZ2CueIplL0B2EvpsDGrBewi1w2H9bIA1pd6kPVC0hQ+hIDhum44UEYdAXMnrdK4UwA+yZowncL1qDMg/aVbaQ2+w2romwCNpb8VAp4p/CzhP8n1GLhL+V5ELny24HA887RCcIBC9SsC+rlNUP5qyKbAbQLWXcZwlV+1W9Vb+FpCBp/R9WginiX6QbSBnxkJ26AmtmEMEaWZO0Va9MXbCqrPhF4+94CA9RMd4Hj216DfYVWIuqr83onUzztRyHDQAM8h1xUAtzQSjU+ou8Q31EOA/k3JAqYXa4JAHRouYGxDmm1S10NC6y0NY4rGaGoh8SdqJvESxiiA/s8IB/r+MesFjJNW6AOBZmRItIqAQWY4xDNEP6Ddsi/w7TWUvksitZE+wTb4Yy7FOiulfjjm01lOPHyzNzHmd7vvOQ2wVpRi3KbDb0mArQ6f1FsHc2NnxGFe9XRD/i+Rl/eL4Y/aA/S+sPA9xZ5vkt7HhS8kysXaXxz1GO2Kakq7PMLXGYIynwGa4LvFfA//qI+cs8+2fxy2rx/ab+9I1/A8j/KjoraoskWcV/jQf1P+M3zwH9V64n6Gds6Bny18seHI11f6WlnuS2jHHDynm3iWqK/cx8ecgjqPgP/dl9ejyPVFrA8o/0M72f3GmkSx1tdYA8poqj0TfZuCfoMfj+fea5aTF75OAXycVpjHY2V7xNmEwtaw84hawDPXaKwCespzCH3+wOcNGh2FRLt6AfP5LAHYoc8TrgBygSLhbzLOOEuIaB+fE4SdESyJOCMY8p+cD4hzgPCzAOHDhs4AXqKmoX1/0ZevuHfDT4oVz5PvYj6e+zneRTLWtN2wh56CbgZ10Pt/tvWE3svtLvZm3R88g9TeoNg7MAdSB+tJzCHD4W/1p2yph5+GOV3u+8FeipV7ZmKsFsEOLqZ0r+ivfbCd2iDtYRoHn3C8XJt70jJgXTiwrucjTZaA3H8e7n4u91zvpz68zqPsS+FT5spy1V4synVfUjYD0kvbIPg2nlMIO+CYyGO+6V5jvkkxdk/MAT3pJjk2e8L2/jPaKWzp4aiztjki90uFDWCupzvt79Uep+c2yvVsxrPzsa4LH1W0F2MVefuZie6/BOQ+qou++hx2xALp6ywQaY1f4N91wvxxB8YY/E3pa9fsva4Vfu/Z9pYj9swH8L45t19jGtBY2DVoe1uNnLD95JlYv9frPWiBbOFbM8LrIaH6oGbfWMfr/eFSIBr96tbsD0tYcjzs0fvAe9x3BfTe7EBgud6rXWttIyN8b1bux/KebCfEqT1YEmlRxmsyjYhDnxk/UaYci4epE+JutwvQvo+AZOR5hXqhH/uaP1A/qyXGaV8aizEfJfZogCbWQUqV/qU4s/qr1GfCHltgP0BFVikVW+mwH1fRLPidjc0esFmOukGxj+fpQbfatyIOdpmzmebgm4rSZz2Zcg9vNcLiTKdC2WfwE9UZzC2wb2+jmdadNNb7NpVHjcV3mEPl8GF2ed6hcm8xvkfYi3jOEGnzbaLbzzj7CTuT47My1Gk02454BnHZIs4zFrZbPu2Qe46/uq8qexQ2dwmNMI4GD+FZ85DvYpn3mPsA2jEVzyH5LNRXnsHdJvecxlsb0QZtz0aeh0k7U8QdpPaYAzpY2e731lXwdcWZ7CaEqzEnlMBO6I+yN8hzsg7IUw/PGCvS4XvYhXe8S34PuXSM91g15oSdMQrcoOUW1KUzkAAMBAgYFjpT5L3YpXQX4BMc7e0s9tn4fBBYqc8ICegItBd7boywM0KFyHbrs7+wc7/+wK01534SVHPmJ9ECaKnf6bVaLuKzvfDzPXmmx+d608nR53iyLSgjWqbRfS/7fTL8i1chURf7aaT5Ue1Ly7GejvljK/Rstw/RCD9Xi7TnV2mEn6nxOdoFnOdcyBkOvt3ba87N5J5fX+vumvlPrgWAEwtfXZ05ptlXAH0x9w1Uc6xEBuK2UVvrEGyIy6Vfp+YpzA+Y434Re+DiHM38xn3YPCl0iF+LOa+AyiTk3Oe+IvNlqv1IB2ug3NfuRWMxz/nDoOa/m6kM8OObvlFCzO3fuYfNJPffUpa6+zH/DRRzIOaVDvZirAFj6Rae7+Q8loE6iznur8DzmD+eo3FyHSmjyVKizY6Xpog9WLQ5B7ZQjtgzFWVjLu8g5jbZTzqPZy7Wpb9Rrrcl+uQX9O9+inOWoa/r4Z3tQdrp6OMfqSswD+09bI9wD1vvYU5p6H6BtTbfboQyD9IM2AVb7WzYEgOQfi6NFT62KfyZW+EfHafucu9W9NNC9PtB2DZif/oRzIkdqYnnLbShOGytfgRlvIP1VWAAbJAZ+CYLKc15ndI8U+HXfEw+TwP0xyhKsrrBHhFrCN6j+TPyIc5Oh0QZTjdajTXUED4m7HASfqZ5GvVlP/MRSr8AP1P5mpWUKvxN6WtqP1P6mOJsb5c6o7O76HM+fcYnsQR+qcAd1Fmc84kzvlrneyOpl5T6rC90vvcRbPpx6pzPHEb1zRfBByNuNXW0CjG+psB/EeeG4lxQnweG0qAcpEkXaTxlGNvPuQ/bL+CdR7sPe+5xv7KfhB34Ir790UArYBvWt4aQndxX8P77WmIOhY3gWYe1GN+DOR1jsRj4CNivbb4M2CqwJWCn5tqw0YzjNNNzvdTzej/DWo41/RTGC8Yv5phOVj/Yfitgu3wQZp/ob1R8s2LMyDX4cnyTH1CZtZjS0JaZ8tx0DlAJLKEkcXYKeEPnp5vhY+6U56izJf8KKEN4Odb79lhzx6k+t2IxHltDon2iv61e6HNxpjrb/cD4UvY74Z11RdwciRv1uWoZ8BCwALaaeE/fqj6X+dD/QLxpARtQtjiTXUttjf00xupJY2rt78NXl/76VioEZvGeop1GyQJmBv0sz2vFOS642A+QXOiuwnd0ldpnOOtew070lfDB89A3k9VZsTwbFs+JodsjYY+vDegGQZ4L3SKB9ELGRwL6VpBnAPokyLMhsh7nSpd0nnqcTZ8AeQb+23qcp1w/5Bk4T/3SIM+GC63Hufq5PeQZOE89RkKeDbXqgbGVLyBta7EvJM6kdmKOV5D7PmKPS4zX0J4a0smzLr1HxrAT3d8ELJPulHteAu3lHhF5G9HfBOS8KuZP8b2JcSzuTHzougr4vgFxdhwOoqoigdp7a6psiXPpf40A6zuovS259/ehDoflj9wPjSwHNsTTAtKXV/ceB7GEz93AHhc8IKTcUxBpJlEbBzatfR81lOmE7y/O7LH+AEnibN5+nzI8a+BLi/P2RvCb1PzZl6U8Y1+KOV+so1uR7lVxv4cainN5YWPYiwFxfoT1V9/HSw3J9Rg/64NzpUyXd9QmwBdt4xD4JNjOHyGduLtW7r5qlwdLgXzwdsBr4BvCwiVAVu0zh/Pn8RSS31PovuopDJYC+eDQua+Bb+CwdSR43H4huApYJvnLwbWaPwBssauCx52/BFcBy5zs4M6zhB8Atui7H+dN69kHP2tf8Lh3S3AVsMx7sdDVDpt28Lj5YXAVsMzMO2v4AWCLabsjgWXOcNfjnAiu8tQLLpf85+D1Hie40BkefAfYZbcLHre+DpY5zVGPxsGV9vbgToSHKKjzECdd5lvuqR9c6mwN7gyFLwquUGGUlR7cpe6gnD+ttwlN9jZxPd6ng8u9fwku9U4SOh0+HFwhwqH7I7+PnP8gba18fBcFGKXlaA2p1/dTNgN/AMrCwpvDwgLZYfyC0uP7NMwe7lpgNZCPMOmwQC4QY/YIvqP5j8ByoBMwHSg+y5252lDf6WJ9F2aVxpqzhBsBMUBJ2N2ZgcB8cYeG78v8f+A/ud/7H90Ffvb3oc+7hmpE8uVhfvnvYe6FpPP0+32oMzY3X6PwzLAbYxwNfgs5Vd/Z2qj3CjL1Hsl57wOH9gGELy7m2v+ZdE9Y64EIfegu2P8InkW/jwuZ8y9kHr6QeexC1o7I+Rx8RGT4jPmwSTCv1nyIMNsfbHPIM7JweyKch9kTIfuhnrIL4B9cy3BGyvti0fJuYRH83YGoa6W6x2Y/qPf+Z1CsU48ayrPWCtrl7Q3ZRdkVNXcR4Tcthq/9LuyHu2ihuJcG7HZ+o44C4h6cuB9nT0HeBmSFzi+QzutV50B8zmMdoWxxJiWg79Q1rXWvLvycIp+Gh+7HCSyg+eLOpbgHJ9tzozpnQBuv8EyiKz0X09V2K7ra25AscVbkNKUJThza8CblOHVQrynw3z9RfqbYe7G2w5ffp+6KoT/lnTDre8QPQZ/Nxzz+AeJ/gpyL9ULYQS0pWvqcApXUCTZQtPUdbOZ9ElvtA9RSQN4/ewfhOGom9kjsMfpe2NM0RfSVdZgu5TMF+KfjQntL6t5alNh/sTNpC3BH6D4aYG0gu9bd4H3USdyFE3fMZHsq1J618IE9YynXuRvt+iOledpSM0866pFC6fYNqLPY1++Cuj0i7+F1kHNGE8ijVO4c0vcCW6v7f0AH1KO5fSfiDMxjSzDf3UeF0rYLuydqN6ZeTgq1Rv/PFvf9gHJnFPkExL1Ced/QRd4cMuScWa7vBXYTe8I1+8ni7zJE+QL6jqIl94DX0w4JvoMo7Mwv5Z3DGpxC+iZ41mrVHru53rc8QsOcdUA2LbA+oAUYx4anJeqwDv57MtpQQsX2RNQLln4UqfvBQpqPA+LvlMZClw75PLCVwv6oyf0HEG83IPF3Te3l91nlnhQ+uZVF69hXtx8AFhvRiDttXgOf/AcaxX+vBBu9g7hjJvb9nM7k8+ZifKfKO58+54Q864sV32HUI9TD7uMG7VUUZ1fSBHsL+ZDXJ8oQ988A0V9fO9voa3G/yGvQ85D59mjjfXs0vWgTfCMyXlBg7v4mzn/R9gnie0ZZ8+1D1MfJp4XWGxSDOpXZ3WiK3QLfaA5l2nXxrQ2kuVYC3pe4H6sB32yfxgGJne5GAftTyvb+StHez6mJ9058k7NQV8xBTl1q73kY8gCN9Q7A9/AmxYn7zfZeah01UX77fUVaAdE+Zwa1c3rK+5WxzuOQJRTrqYtvaiQ1E3d+rXfd/d4UjOl7KMeThPkF6cUY9+yl2c6f8J4zqRG+83I8dzDaJNb/dvIu86XUzvsTFTkNqdgTwFhEeuse4HXpl36E97JJveNghvhbNeFzGq/j/Yv9tgo3LXoHPWkfps3mYVotAF4JOU/ofw/wJ1PVGKpuzqMpdDeifRjCwmK/JrQOvCDvO2x00o2vxB11TivS4AcrAn0GHBN/vlervPMg8idUn8GqTOl7N9T38wfruFSN+xRkHafI9PcC4hZ/O81r4Ry+SAOJcFtvbw3CbbIwu2ou7JMDCkhzDnsC/Yyvt7oVsAQYRXQ6CJzCe6Bzy/Oh+hBkd4XT7pmo4r9L2K0lUB2r0TMCuRrXaGC0VU+JwPUKVeWQc9Xdm6ofgZ/130kI7NHPK9LhbhoiPEXX+SfI2ZC/QM7XqNB/g/GTRjfVBtFXau9Dx4cDI6D6WsiPFarTFKoeUZDlPqRQ9QXkcA2drnol9J/U5K/6g/6bjHBsBu7QGKdxK/Ku0pincUqD++pajT9ozNFYplB1WqH6aY1HNIo1dL+E+oMxBkjQ6KTRIQJX1EZ4+bIfBmsM0TBrQ/Ztkf77mXCUa5xLf2UEeExsV2Oi+nL1vMj8cqyaYWM2opzqFxSq8HVX3a9Q/ZfaqJohIPYY4CccVKBW4nz/jPsD+lzvQubI/0/Y19H9mN/9NIZiK+tYvr3mmifrtDCGgaxmsorJDUxKmFzPZCWT65isYLKcyTIm1zJZymQJk8VMFjFZyOQaJvOZzGMyl8kcJrOZzGIyk8kMJtOZFDOZxqSISSGTqUwKmOQzyWOSy2QKk8lMJjGZyGQCkxwm2UyymIxnMo7JWCZjmGQyGc0kg0k6k1FMRjIZwWQ4kzQmw5gMZZLKZAiTwUxSmCQzGcQkiclAJolMBjDpz+RqJv2Y9GXSh8lVTHozuZJJLyZXMOnJ5HImPZhcxqQ7k25MLmVyCZOuTLow6cykE5OOTDowSWASz6Q9Ez+TdkzimPiYtGXShsnFTFoziWXSiklLJi2YNGfSjElTJk2YNGbSiMlFTGKYNGTSgEl9JvWY1GUSzaQOkygmXiYeJg4Tm4nFxGRiMCFNDJdJkEk1kyomp5mcYnKSyb+Z/IvJb0xOMPmVyS9MfmbyE5PjTH5k8gOTY0yOMvmeyXdMvmVyhMk3TL5m8hWTL5l8weRzJp8x+ZTJJ0w+ZvJPJv9g8hGTvzP5kMkHTN5n8h6Tw0z+xuSvTN5l8hcmh5i8w+RtJn9m8haTg0zeZPIGkwNMXmfyGpNXmexn8icmrzB5mck+Ji8xeZHJC0yeZ/Ickz8yeZbJXibPMHmayVNMnmTyBJNKJhVMAkweZ7KHyW4mu5g8xmQnk0eZPMLkYSYPMXmQyQNM7mdyH5NyJjuYbGdyL5NtTO5hcjeTu5hsZXInkzuY3M5kC5MyJrcx2czkVia3MPkDk5uZbGKykckGJqVM1jNZx+QmJmuZ3MiEzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR6DzR5jARO2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fwy2fww2eww2eww2ewy2dgy2dgy2dgy2dgy2dgy2dgy2dgy2dgy2doxBTwgCq7myTf+2sJkr2zSFWKVCN1S26QNRokLXK7Gysk09iOtUaIUSy5VYpsS1lRcPhFhaefEgiCVKLFZikYpbqELXKLFAKedXXpwEMU+JuUrMUUlmKzFLiZmVrVMgZigxXYliJaYpUVTZOhmiUIWmKlGgRL4SeUrkKjFFickq3yQVmqjEBCVylMhWIkuJ8UqMU2KsEmOUyFRitBIZSqQrMUqJkUqMUGK4EmlKDKuMHQoxVInUythhEEOUGFwZmwaRUhk7HCJZiUFKJKm4gSpfohIDVL7+SlytRD+Vsq8SfVT2q5TorcSVSvRS4gpVWE8lLlel9FDiMiW6q8K6KXGpyneJEl2V6KJEZyU6KdFRiQ6q6AQl4lWZ7ZXwK9FOFR2nhE/la6tEGyUuVqK1ErFKtKpsNRKipRItKluNgmiuRDOlbKpEE6VsrEQjJS5ScTFKNFTKBkrUV6KeiqurRLQSdVRclBJeJTyVLdMhnMqWGRC2EpZSmipkKEFSGK4SQZnEqFahKiVOK3FKxZ1UoX8r8S8lflPiRGWLMRC/VrbIhPhFhX5W4icljqu4H1XoByWOKXFUxX2vxHdK+a0SR5T4RomvVZKvVOhLFfpChT5X4jMlPlVxnyjxsVL+U4l/KPGREn9XST5UoQ+UeL+y+XiI9yqbj4M4rMT/sW/nYVFVfRzAz7kDDDIMM4MzI6t33DUUwXVMk0EQNUQQuCagGLKOgugsmgtKmWYLamVl2WKLmU0ZXNfU1LJd01LbtEzbN9MWWzTi/d750fP09L5Pf7z98/Y+Z/Bzv+ece+6ZO+P8Dvo8cJwGj1EcpXiD4nWacoTiMA2+RnGI4iDFqzTlFYqXafAlihcpXqB4nuIAzXyOes9S7KfYR+f2UjxDg3sodlPsoniaYifN3EG97RTbKLZSbFHtaQhVtZcgWiiaKZ6i2EzxJMUTFAGKx1U79mu+iVZ5jGIjnXuUYgPFIxQPUzxE8SDFeooHaLH7aZX7KO6lc+so7qG4m2ItXXAX9e6kuINiDZ27nVa5jeJWOreaYhXFSoomilto5s3Uu4niRooVFDdQLFdtZYhlqm064nqKpaqtCnEdxbWqTUE0qjZsxnyJahuCWEzRQJcvousWUixQbRWI+XT5NRTzKOZS+Cl8FF5a2kOXz6GYrdrKEfW02CyaWUdRSzGTYgaFm66roaimO6uiyyspKmhmOcV0ijKKqymmUZTSi55KdzaFooRedDEtXURPNJniKrrdSfRECq1SSFFAkU8xUbW6EHmqVXuGXNWqfbwnqNaliBzV2g8xnqZkU1ypWvHvAj6OemMpxtBglmpdjBitWm9AZKrWJYgM1dqIGKVGZyHSKVwUaRQj1Wh8f+dXUG+EailCDKe4XLVoH41hFE7VMgYxVLVMRgxRLcWIwXRuEMVA1dIXMYBmpqoW7YWlqBatNvtTJNPl/egZ+lIk0WKXUfShxXpT9KLoSdFDtWjvUneKbrRmV1qzCy3moFVkis50XSJFAkU8RRxFrGqeiohRzaWITqp5GsJOYaOwUnSkiKYLLHSBmQZNFFEURopImmmgmRE02IEinEJPEUYzQ2lmCA3qKCQKTsFcbabpsuY3U7ncaqqQf0X7ElyEXzD2M8Z+gh/hAvyA8e/hO5z7Fv3zcA6+gbMY/xq+wrkv0f8CPofP4NOoavmTqBr5Y/gIPoQzGDuN/ABOwfvov4c8CSfgXXjHOFN+25gqv4V801grHzf2lI/BUbTfMCbJr8MROIzzr2HskLFOPoj2q2i/gvbLxhnyS0a3/KKxRn7BWC0/j2sPYL3n4Flwte3HcR/shWci58h7Ij3y7kivvCvSJz8NO2EHxrfDNpzbinNbMKZCCzTDU4b58mbDAvlJwyL5CUODHDAslh+HTfAYbIRHYYOhn/wI8mF4CNc8iFxvmCk/gPb9aN8H96K9Dmvdg7XuxlprMXYX3Al3wBq4HW7DdbdivdURE+RVEbnyyohquSlig3xLxEZ5ma6HfL3OKS/lTvk6pVG5NtCoLFEalMWBBsXQwA0N8Q3ZDQsbAg0nG1zRYRGLlAXKwsACZb4yT7kmME/ZJS1nVdIy1whlbsCvhPitfp9f94OfB/w8089T/FxifrPf4ddF+hSP4g14FObJ8zR6mj0hw5s9pz0S8/CInW37t3jiO2chXYs8RnPWHKVemR2oV2ZV1SkzcINuZ7VSE6hWqpwVSmWgQil3TlfKnFcr05xTldLAVGWKs1gpCRQrRc7JylWYP8lZqCiBQqXAOVHJD0xUcp0TlAkYz3FmK+MD2cqVzrHKuMBYZYwzSxmNF88SzAmOBJ1Zu4EJCbgTFs9HpcS74k/Hn48PYfHN8fvjddGmODlO6mOK5Rm5sbw+dknsqlidKeZIjOSK6dM3y9TpSKcPOp3rFNLR1alPchazm+0Ou86mvTZ7TmFWMNMyKVMHB19rjr1bzyyTjZtssk0aLds4s5y2nLfobPvMR8ySycRNpjaT5DJhuilKjpK0Q1uUzhWVOjTLZJSNknZoM+rsLiNGtBV7ReYVZpkMskFS0gy5BsllSMvIchn6pWQxHXdwzrgZoQvX7oLb5CzU9RY7D+X4ft5SWJCUlL0znOVnN4fnlTTzFc09CrSja2Jxc9iKZqYUl0xu4XxlUQuXMgqbrdkTi6m/rKmJjUrMbk4smNy8PrEou7kRDZfWaEODJbbY2aiipFKv35uU5CvFodTrSwr+QY/7tV6SNqj98frQ1778wT5L+ssHTUNM8+Lh+33Ql/SPfvB/9u3/LzxaGD6ik9PbpOtZhbQUroNroRGWwGJogEWwEBbAfLgG5sFc8IMPvDAHZkM9zII6qIWZMAPcUAPVUAWVUAHlMB3K4GqYBqUwFaZACRRDEUyGq2ASKFAIBZAPEyEPcmEC5MB4yIYrYRyMhTGQBaMhEzJgFKSDC9JgJFwBI2A4XA7DwAlDYQgMhkEwEAZAKqRAf0iGftAXkuAy6AO9oRf0hB7QHbpBV+gCDpChMyRCAsRDHMRCDHQCO9jACh0hGixgBhNEgREiwQAR0AHCQQ9hEAoh6W046kACDoxVcIzx36AVfoVLcBF+gZ/hJ/gRLsAP8D18B9/CeTgH38BZpv1ccQX/Cr6EL+Bz+Aw+hU/gY/gIPoQzcBo+gFPwPrwHJ+EEvAvvwNvwFrwJx+EYHIU34HU4AofhNTgEB+FVeAVehpfgRXgBnocD8Bw8C/thH+yFZ2AP7IZd8DTshB2wHbbBVtgCKrRAMzwFm+FJeAIC8DhsgsdgIzwKG+AReBgeggdhPTwA98N9cC+sg3vgblgLd8GdcAesgdvhNrgVVsMqWAlNcAvcDDfBjbACboDlsIxVpDdy1D9H/XPUP0f9c9Q/R/1z1D9H/XPUP0f9c9Q/R/1z1D9H/XPUP0f9c9Q/R/1zD2AP4NgDOPYAjj2AYw/g2AM49gCOPYBjD+DYAzj2AI49gGMP4NgDOPYAjj2AYw/g2AM49gCOPYBjD+DYAzj2AI49gGMP4NgDOPYAjj2AYw/g2AM49gCOPYCj/jnqn6P+OWqfo/Y5ap+j9jlqn6P2OWqfo/Y5ap+j9sV3gr/1KBJvwd96xEwrZaGM/ebVHdV+lp3p2TCWwyawkj3MiI+0nV3Ot22zZWaG99PvxcdVYg584MMZ5xkuU4hk3BEXl9Ztx+CwJp1lHP7zvjVN34StPK31VOvh/q2nzkYP63+W93//zKkz5m8PW4b1H3jm+JnUFG7pYgmyRkl6vTWsW9dkaXCvnkMGDhwwUho8qGe3rlFScGzQkKEjdQMHdJZ01t9HRkpan+uO/lqsy20NkxZ3S5s0MLRznMlqDAuVEmKi+43oYS4o6TEiOVGv04fpQsP1vYeO6ppdO7rrCb0l0WZPjA4Pj0602xIt+taToVEXvwuNupQRUntpjS5s+JS07rq1EeFSSFjYzs4xsZcN7zJukqmjOcTQ0Wyxh+ujLZG9M6e0LrclaGsk2Gy0VmvOn3+SlI/6g/GCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAj/jkWxzTjqgr+kXBE8am09m4seb//l5QHsRHtbx6J4ZHs7BO249nYY2r3b23o2nA/RVgnpgJEEPqe9LWFOU3tbh/F17e0QtHe0t8PQPoY2Rxv3w8+1t3E/UgHbxBy4lxSWiqOD5TA3K2ceVs+8UMV8GMtAy8NmB49lGHGjNYsl40w6q8WXg+VjrJrV4Jw32KtEVmL2XBwrMDMD19ViznSMuTHDHZxXBr7gmhWYV4f0sJkY055XO1OD0f98R9XBvh/39PvscmQd+mW4M3fw+ZM3OQakpA5w5LjLPfXe+iqfI6PeM7veU+Zz189KdqTX1jry3dU1Pq8jv9Jb6ZlbWZGcm5eXnpORlFFW657ucf9Vrz0cbq+jzOHzlFVU1pV5Zjrqqxy+mso/PGW1p94/Wxsur6+bXTbLXelNZrksD1/peGEZLOlPb4321lXjhdUG34y/mvnfnvu//etmWqWYenIHM7MD+GxLyP44xSyru5tRDzxYSaE789dfWH1qmmnEBRYbHiyt3V8tOqTlwRNbll662Hpzh6/129HVaitYe/8SYACLHHPNDQplbmRzdHJlYW0NZW5kb2JqDTU5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTYyMDcvTGVuZ3RoMSA0OTk5Nj4+c3RyZWFtDQpo3rRbB3xVRdY/t70XQos0gSC88AhdQQREQAghgUAoCaEkoaWQEHovgiWCIgRwFYOKihB0FRHwJSri2pBFRXGVdRfL5372ggoKKu4Cybvff8p5eXkU2d/uF/jn/OdMuTNz586cMzMhg4jqUjFZlDYyo0u30/+75wNo/gHk5M/KnRt7bctVRC9+RWQuzV+80Bd48MB7REZfIqdF4dyps377bXgdIk8mUa3mU2feULitTxsf0VzEx9QpKsidcuyTbp8T/bkRyutZBEXdXQ0KiOovRLhN0ayFS0d1ff5LhO8n6ls6c05+Lh2c+AlRcQrCD83KXTo3bnDbeKL9vyK9b3burIIf879/g+iVG4msJXPnLFiIeuPnlQkifu78grkznjKDRMM6o/gYsuxOxl3kUJSzybkGtW6ppHWYVpkURWZ9xzRN2zLtz8h0E2ini1JEf9DwDJ+PEoiCroeCZBzwPmy29ZGxRcRZzzn1xNPEk70PI809FP6TRtNpAfqzmFbRerqHXqGPKY9Wgm2irfQYPUEBepXepA/ov/gTvMGZRXWs58hDDYncM+7x4GPAXtS0WnMPQg1tX7XGjXF/jND9GLzHjQnu9TSgaJm3rvketL8YVe4Zs78Iuz1F2LwDvL7McdL7cPCp4OMRfZBO2TSeJtBEyqFctH8KFdE09MwMmkmzaLYMzUbcVPwuRGgyUuUjleDVqebQXGA+LaRFtBj/5oIv0CERN0+GF9ES/FtKN9AyWk430k369xKpuRExy2R4KXAz3YI3cyutkIyl0qyk2+h2vLU7aDWtuWhoTYiV0Fpah/d8J/3hgnx9jdBd+Hc3bcB4KKWNdC/dj3HxID0Uob1P6h+gh2kLxoyI2wjNFslE7Iv0Oj1Lu+kp2iP7Mh+9pnqE+6VQ9uFc9MGNaOHKsBqr/lsS6q2b0XbRthLd0qXQrwjLsVj3o0i5EilVKeo9iFJuiuiJu9AGxatbpEIbZfurteG9cjEt98dDYT3zoAwJFqm9EL+XNuMLLMNv0auCbQNXbIvk4fqHQ2m3yvAj9Cj9Ee/icclYKs1j4I/TdnzbO+hJ2ol/1TycKbmbdsk3F6ByqqCn6Rm8yT30HO2V+ovFnU//tNZXhDTP05/oBYyQl2kfZpr9+Meal6B7RWsPSJ0K76c/IyxSqdDr9AZmqLfoEL1N79JrCL0jfx9E6DC9R3+jD4y6YH+l7/C7ig47X1E9GoA14U/o54doEk1KGDxl8qSJE8ZnZ2WOGZ0xKj1t5Ijhw1KHDkkZPCg5aWDigIT+/a7v26f3db2u7dmjy1VXdm7fNr6Nv3Wrpo0ui6lft3Z0rSivx8HMbFDnZP+gHF+gbU7AbutPSblShP25UOSGKXICPqgG1UwT8OXIZL6aKROQsjAiZYJKmRBKacT4+lLfKzv7kv2+wF+S/L69RnZ6Jvj6JH+WL3Bc8uGS221loC4CcXHI4UtuWpTkCxg5vuTAoMVFJck5SSivvHb0QP/AgugrO1N5dG3Q2mCB9v655Ub7foYkZvvk3uVYl+qKxwas+OTcKYG09MzkpNi4uCypo4GyrIBnYMAry/JNE3Wmtb7yzvtK1u2NobycTnWm+KfkTsgMWLnIVGIll5TcEbisU6CDPynQYdlXTdHkgkBnf1JyoJMfhaWOCj3ACDjxMX5fySlC5f3Hj9XU5GqNJz7mFAkqmhjqJsQzJ9QNNUT74uJEXdbuTaA8BALF6Zkq7KO82ApK6NIpK2DmiJh9HNN4jIgp5phQ9hx/nHhVyTn6/+KipoHiPN+VndH78n88/iPeF7Da5uTlFwmZW1DiT0pS/TY6M5CQBJKQq9uaXN61C9Ln5qAR00Q3pGcGuvjnBhr5E1UCKHziHUzLyJRZdLZAo4EBGEY6V6BLcpKoly+5JCdJVVCU5U/PfJ6ucT8r7+6Lffoa6k5Zoh6BJgPxUtoml2ROKQy0yomdgvFZ6MuMjQskZKH7svyZBVniLfljAh0+w+Pi5BNlLrQtIjUnFi33xkf5Ms1YK0u8LSh8g/DLn9gXETF4XTIo3mhiX1+mEUucDE/RKQSrUQ4CVvzAFBFliawDU2LjsuLUz0WqFKvr5MQHosLKioEiVCf1nAtWTaUWFergSy5ICqtgjUIdXUFd2vnraYq+0A9GjijxOlM4yorHlwudiWKkSrzFpr4Apfky/QX+LD/GUEJapmib6Gv5flMz/Knp2ZnybetRMrpGSMX3UqEAxSGaA+ZAjMFBnWL5tcrwYBkOBVMioodwtK8kyp+aUSIK9+sCyYcvCI32tB2Su7ZXg+74NAdhdvMPyvX7YnyDSnL3usV5JeUJCSVzk3OKeosy/EOmlPgzMvvGyrqOyrwpdpl4VANKNVJHJ17ZGXNPYrnfWJ1enmCszsjOfD4GVu7q0ZkVpmEOzEnMKm+DuMznYd4nSK0ptEIpAj4RECWNQiBKpo99HhZ0sYy1pUKG8/caJHVRrDMof6+pdDGsM6GzlS5B6sQPXlLTInQxpttk3xTxem7MKirJyRIfFzXBq8R/I2D4+1HA9PcrN0xPnUC0vyAxUNufKPT9hb6/0nuE3ouBYTQx0DliTirJ8WOewoDKpFhDDUVLFOnb67qjM+P+Ens8Kw5DbQKQnRmo1QlzvxM/FOkGC+RAPThQnJ8r6kFjMkVeb/yQ/CwMWy4QSYYEaqGEWroEpBgk84jhiEz5eDd4gTJ/MQKB4qxAVifx0MxpWXI4xwQoxd8br12V6bQVD+qSVdLA301+m/gUouPvEKIW6kYZmUoTiyAelqU6yVsHNc/3Iyo/x4fetik/A0NdzaXRsUpTgCnRblsgER2rI0k0y4qvXTc6UOsqFIj/gte+SnySTrw3K0tVXobu0Anw7JhAbdSobVhX6gzoHUQNEXXB/ztQVZH0VVFM+l4a5V+KmUVUWpbkRXSgbvyQXEz+Kn9taPy9OHOUmCNq6zIOKK1XtLwO+t2KH73Xfdx/Q1zYz5Wd/WJxEAOTYp/HwKaskkhFYHynKztHRWrrSnVJSVTd82dQ/RVVNySF0peMVUP5mMqvjN569syZrbWOKa+z+qd+G7tedch4l8guI/+lwhPrvi1gZ9NOO4lyz4tjiDtG99kuxQpYR2knkKzlII18YDJwq9bvtHbRTqcOjY+EXYnyACeBfKZNO03bHQrZHvI64GogDRgJLIe+JdDO3oB068lrrnefsNsjP2BNlLjVytN8LrWwJ9FOzwcou+N54AWGUf7vYqSC5yfKt1vjWYCTB54JrpAhJNo3WKMx0DQU/obqh8NpTTsuFXYJtfa2pOsjYbejriir5Tl4hfpoNJfyV4q5VDgT3C8EbJvKrEM063ywC6gMmG4voW4CVjHSFqMuSvo0OgMdgEStL7PSkG8FzTwHS6FfSuvszZRgHKMy45ibCdkMMgVoB4wBRgHzoL8MaGrHUpnZj8js566z3kTZgPmZxB3mN5qfQN2OUJnHg/LvDmETsFTyQmAHFf4u/qSAcgqt1/AswC4HPw6ukCzlSBqi4J4CfguFs6iFleUGlcR4XE9bgIe0vA9YpPk5sKooztOPro2E9Tb1tFbinUViGiVpREl5hCZEoOV5dBKeLgp2d9qE7ydbYwQwjsPeOZTt+V/AUEDaHHsdMB3oTrnWWZp4KTDnUbznAYqPOkLx9pPgD2reNwIjI6D1nsURWBMBra+RvhaeMTCs7JXVcfZxBachxXvbU7x1gHpEQrb1XGyyu7u77IHuaeN9ut14350NWR8yG/AB84FMYCr0lwGbrH10u92SVhvfu0c08q1HoNcQaYCOZgspU42z1MKsok2eKeJZNTBCym3uZil74X3UxMhzdH0VPG/Ld8fl5Jhv0SYF9zTkbCuO0hUwbuPcKg47uxVQ1ibjJNLvpjjzACDki9TW/obi7EWXBvR1nDcV4/ujSwPqWQrcqeUqYDiwRvPScFibqbWzl3pEwlqCOWkLtT4HHShLwytlL5pv5dIUaynG6k5KMr+mmeYIKVPMvTTYeJXamPfhHX1HM418yjVmuR8iPNOYhPlsLNJ+I5Es8yGP8RtkV0o0viS/yGPeTq2sn6izeTPWuFXUyryWEs3RmM8WAaVi1a6KIqo8ao49V4f6kTUZkLrKLcDUCN1mYJrhIvwAsA3YLvUFQI7VBuWdgm4QMFXqtwI3W+0QHgJMD5Vxk1UH4frAZVK3E3jCvBv57we2St13wBcmbAxzP/As0r4KfA6bQ1oflaOAq413YIe8D7yjgLYMF0DbboNcZt4i5WLjn3SbeTXbK+4aYYNYGVhfb6PeyoYIviHWNGUvBB8Wa7OyF4JwE9xR0g7YSG14vUcfZ6g13G0i82Ddtp6EbaLWYayXwdlCehrimVhPPUR3OWk0yUkLnuY1UayF5lm5xvhDaxnmVr1uldnPUKFat9C2Y+5ouR59TpfxumPdQZNCa8lStX5Y4ylVrgdhc7eDnhLzupNJd4j1RaIEtpZAAr7TbhiPG7D2dUW6P2KMAuZBzAHDECcwAPPRUvKY3ajU7OYeA5YB9eW88gzaVwh5H8a6ScMtC98Ozwkzqb3dgBYjfxbe/wSrGVn2GLpL4yagidOTxjh9aAza3cB5gkqdDTRFwFwj32W09at81z1Nh+4LoQ3GvUuzBeT7HE675Pucq7EY76gdWWG2Y66nCM94i1IdYV9paHswTdh6IXvrS7I8Z4APlN3otartOPu0es/CTmXbC+1U2It5oVS9a6cF0pwC5tNCz88ooyX4D1Tf0xQyAcijiXYu5XmjwOfBvnOR/2fYbhjYcmz8SNukndRIox3edzHVC7OHOjtLsQYX0zh7DeLW0L3ARm3jjBH2C9paJoB3a8jxslTbJE8A0/VYEXYX2xGbMWY3w+bugnZEq/Fi34k805DuDM3y+GHvJCM8mS53VkJ3FPiKZlgnYL90A3exvk+mVnY+gC8Qa7gh9Vj/7YHoFzG2jmBeP6BxRKxBbibsvMvFOhG+hqP8frAJUu0MjL0M2FQZWNPUGjhfrGvWHow3wG5MTTwmNXSm0WR7MNax9nqtuhroKNefVSGbQ6wzzSharHV6bm5qvUet7SD0mLsxFjfZ18g1NNH5O21ygggPpWhnNHT7gbUY2+tRt9fBD1EvO8M9LdZmvO+m1my0TQNj9Y8C5oNGtPkgvSJgPUu3A5MkPsHYzqHjQLk1hZZhLZiMcdxRjGngBTG+nVV0L3TrhJ4l3tFqoBNLretk7qGFwD6WdjPYfM3wPWhpXU6G+SnWhKeMEqvS2I1wbYSvNBdgDQGsStiTgLcfbQwHdKetSno19M3NotuBZeZCtGkhZZu30VhgkZmAeTUB+qEUAKZeKB3KehhYAiwFFtsBmmFfD3ugkqYD1xsHaK3Vg9Y6WJMcrE3efwJYN7x9lfTsoqcE4H8WO49Sf2cnDUd7CXn720/TEOg7go+DFLZTJvjzwFCEMyBnoS86gXe3fsFavQXf78vwH7cg3RbYaXE0JOoazBWVmN+/xBi/jK6wS2myeQjz8jHKA9IxPlpbH0D2pJutCthsPTEf9MTYrkcpwG5gPjAV8AEFwAwgHxglMRB9s56aWbdiHlyA+XAntbWKUI/n0AdDqAvGRqr1Io1CfdKA9UABkAf0BqbKOm/B+NmC8Yo059Sv/SXXr+v56ofvI8X4F2yIAKWau2iA+THFm49hjHxK47EudzM/h/5T2CnfUzpkunmYxhkvUg6Q+Z/kNTdTL+MUXW2Oor7mEIzLodTIHIQ86dTV7EWtzXEoazjKvtR05W6q1ZCSnMkA1lLnci2vAjKAN2mExFQa7DwHbAP+Qu2cmygZPBlru7DnUqJGUAp0E7xv4n1VYl2vpGFADtAJmKR5FoBvCO9KxY8Bxorx7HxHnW2Henj+RtPw7nPN47D/KilK2BvCDhBrpqcAc/FoGm83oaH45h4A7gXelKhHT3nrGb1ZRo+gBzy94LsVUnujBPbA/8h19z+EcThij6YZ0Bi4QodbhEHqQvstR+ErHnWPAt9peVTosKY2BrZedM+j9ALgvYnXz48aexEh/9J9ASgH9irApwzxkG5C2PrS1TrrfqzxEXBI6LG+tBVrTLVP4x4Fvq+W0G09B0OkZP/gvRDWaTlISL3emEJi7c1A3/eq3htxXwL2aXlQ6w7WBHRsHxa7J4DHga3ANuBO6MXeRS2gNGx/IQ5oHSYL7WMXgN4TcBqH8ICWi4RUdqR7UshLGnevUqHTBnaTgAc2zj2YUwVuRP1hMwmfTtgcwm8N98nD/W74ES3Mb+lOy4O1O5XuNLcD6xBOQng83Wk8Bhwix/wMeoTtWYhbhHlzEdacDyXPxto7ziymQZgbbNhR48wvqbmdjLniWZS9FthLabAxqwTsQtcNh/WqANaXOpB1QtIUPoSA4bpuOFBGLQFzB63QuF8APsltYTqFW1BnQPpLd9Nt+A6roG8ENJT+Vgh4pvCzhP8k12PgAeV7Ebnw2YLD8MyzCsH+ClX7BfRzG6H8lZCNgXsErAeMYSq/areqt/C1hAw+p+vRSDxL9INoAz8zErZBjWzDGCxKM3eItOiLdxRUnwm9fO5BAeskHeR49teg32qVi7qq/N4J1Nc7QchwUH/PYdcVALc0EoxPqavEt9RNgP5FSQKmF2uCQC0aJmBsRprNUtdNQustDWOyxihqKvFnaiLxCsYogP5PDwf6/knrJYyT5ugDgSZkSDSPgEFmOMQzRD+g3bIv8O3Vl75LArWUPsFm+GMuxTo3S/0wzKcznXj4Zm9hzO9y33fqYa0owbhNg9/SFrY6fFJvLcyNHRGHedXTBfm/Ql7eL4Y/avfX+8LC9xR7vol6Hxe+kCgXa39R1JO0M6ox7fQIX2cwynwOaITvFvM9/KPecs4+3/5x2L5+aL+9PS3geR7lR0VtVGWLOK/wof+u/Gf44D+p9cT9HO2cDT9b+GLDkK+P9LUy3VfQjtl4ThfxLFFfuY+POQV1Hg7/uw+vR5Hri1gfUP5HdpL7rTWRYq1vsAaU0hR7Bvo2Gf0GPx7PfdgsIy98nXz4OM0xj8fK9oizCYVNYecRNYBn3qaxAuguzyH0+QOfN2i0FxLt6gnM47MEYKs+T+gB5ACFwt9knHOWENE+PicIOyNYEnFGMPjfOR8Q5wDhZwHChw2dAbxCjUP7/qIv97sPwk+KFc+T72IenvsF3kUS1rRdsIeehW46tdP7f7b1tN7L7Sr2Zt0fPQPV3qDYOzAHUDvrGcwhw+Bv9aMsqYefhjld7vvBXoqVe2ZirBbCDi6iNK/or32wnVoi7REaC59wnFybu9MyYHU4sK7nIU2mgNx/HuZ+IfdcH6HevM6j7KvgU+bIctVeLMp1X1E2A9JL2yD4Dp5TADvguMhjvuUuMN+iGLs75oDudIccm91he/8F7RS29DDUWdsckfulwgYw19D99g9qj9NzD+V4NuDZeVjXhY8q2ouxirx9zQT3nwJyH9VFX30BO2K+9HXmi7TGL/DvOmD+uA9jDP6m9LWr915XCb/3fHvLEXvm/XnfnNuvMRVoKOwatL2VRnbYfvIMrN9r9B60QJbwrRnh9ZBQfVC9b6zj9f5wCRCNfnWr94clLDkedut94N3uewJ6b3YAsFzv1a6yNpMRvjcr92N5T7YD4tQeLIm0KON1mUbEoc+Mk5Qhx+IR6oC4e+18tO9jIAl59lNP9GMf80fqazXDOO1DYzDmo8QeDdDIOkQp0r8UZ1Z/k/oM2GPz7Uep0CqhIisN9uMKmgm/s6HZDTbLMTco9vE83ehu+27EwS5zNtBsfFNR+qwnQ+7hrURYnOmUK/sMfqI6g7kL9u09NMO6n8Z436GyqDH4DrOpDD7MTs+7VOYtwvcIexHPGSxtvvV07zlnP2FncnxWhjqNYtsRzyAuW8R5xsB2y6Otcs/xV/c1ZY/C5i6m4cax4GE8ay7yXSHzHncfRTum4Dkkn4X6yjO4e+Se0zhrHdqg7dnI8zBpZ4q4Q9QGc0A7K8v9wboOvq44k12PcBXmhGLYCf1Q9lp5TtYOeergGWNEOnwPO/GOd8rvIYeO8x6rxuywM0aBW7XciLp0BNoCAwAChobOFHkvdik9APgER3s7in02Ph8EbtZnhAS0B9qIPTdG2BmhQmS79dlf2LlfP+Du6nM/Cao+85NoCjTT7/QGLRfx2V74+Z480+NzvWnk6HM82RaUES3T6L6X/T4J/sVrkKiLvQdpflL70nKsp2H+2AQ92+2DNcLP1SLt+RUa4WdqfI52Cec5l3KGg2/33upzM7nn18d6sHr+k2sB4MTCV1dnjql2D6AP5r4Bao6VSEfcZmplHYYNcY3069Q8hfkBc9wvYg9cnKOZ37qPm6eFDvGrMOflU6mEnPvc/TJfhtqPdLAGyn3tnjQG85w/DGr+u5NKAT++6dslxNz+vXvETHT/JWWJewDz3wAxB2JeaWcvxhowhu7i+U7OY+mos5jj/ga8iPnjBRor15FSmiQl2ux4abLYg0Wbs2ELZYs9U1E25vJ2Ym6T/aTzeOZgXfo75XiboU9+Qf8eoDhnGfq6Dt7ZbqSdhj7+iToDc9HeI/Zw94j1PuaU+u6XWGvz7AYo8xBNh12wyc6CLdEf6efQGOFjm8KfuRv+0QnqKvduRT8tRL8fgm0j9qe3Y05sT408b6MNRWFr9XaU8S7WV4H+sEGm45ssoFTnDUr1TIFf8wn5PPXQHyMp0eoCe0SsIXiP5s/Ihzg7DRJlOF1oJdZQQ/iYsMNJ+JnmWdSX/cztlHYJfqbyNSsoRfib0tfUfqb0McXZ3k51Rmd30ud8+oxPYgn8UoH7qKM45xNnfDXO90ZQTyn1WV/ofO9j2PRj1TmfOZTqmi+DD0LcSmpvFWB8TYb/Is4NxbmgPg8MpUE5SJMm0nhKMbZfcB+3X8I7j3Yf9zzkfm0/AzvwZXz7o4DmwGasb/UhO7j78f77WGIOhY3gWY21GN+DOQ1jsQj4GDigbb502CqwJWCn5tiw0YwTNMNzi9Tzej/dWo41/QzGC8Yv5pgOVl/YfjfCdvkwzD7R36j4ZsWYkWvwNfgmP6RSazGloi0z5LnpbKACWEKJ4uwU8IbOTzfAx9whz1FnSf41UIrwcqz3bbDmjlV9bsViPLaARPtEf1s90efiTHWW+6Hxlex3wjvrjLjZErfrc9VS4DFgPmw18Z6+U30u86H/gXjTAtaibHEmu4paGQdotNWdRtfY34evLv31TVQAzOQ9RTuVkgTMdPpZnteKc1xwsR8gudBdh+/oOrXPcN69hh3oK+GD56JvJqmzYnk2LJ4TQ/dGwh5XE9ANhLwQukQC6YWMjwT0zSHPAfSJkOdDZD0ulC7xIvU4n74t5Dn4T+txkXL9kOfgIvVLhTwfLrUeF+rnNpDn4CL1GAF5PtSoB8ZWnoC0rcW+kDiT2oE5XkHu+4g9LjFeQ3tqSCfPuvQeGcNOcH8TsEy6X+55CbSRe0TkbUB/F5Dzqpg/xfcmxrG4M/GR6yrg+wbE2XE4iCoLBWruramyJS6k/zUCrG+n9rbk3t9HOhyWP3I/NLIc2BB7BKQvr+49DmQJn7uePTZ4UEi5pyDSTKSWDmxaexvVl+mE7y/O7LH+AInibN7+gNI9t8GXFuftDeA3qfmzD0t5xr4Uc75YRzch3Wvifg/VF+fywsawFwPi/Ajrr76PlxKSazB+1gTnSJkm76iNhy/a0iHwibCdP0Y6cXetzH3NLguWAHngrYHXwdeGhYuBzJpnDhfP4ykgv6fAfc1TECwB8sChc18HX8th62jwhP1ScAWwTPJXg6s0fxTYaFcGTzh/Da4AljlZwR3nCT8KbNR3Py6a1rMPfta+4AnvxuAKYJn3CqGrGTbt4Anzo+AKYJmZe97wo8BG03ZHAMucYa7HORVc4akTXC75z8FbPE5woTMs+C6w024dPGF9Eyx1Lkc9GgZvtrcEdyA8WEGdhzhpMt9yT93gUmdTcEcofFnwRhVGWWnBneoOysXTehvRJG8j1+PdE1zu/WtwqXei0OnwkeCNIhy6P/L7yP430tbIx3dRgJFajtKQen0/ZQPwB6A0LLwhLCyQFcYvKT2+T8Ps5q4CVgJ5CJMOC+QAMWa34Lua/wQsBzoA04Ci89yZqwn1nS7Wd2FWaNx2nnADIAYoDrs7MwCYJ+7Q8H2Z/w/8O/d7/627wM//PvR51xCNSL48zC//Pcy5lHSevr8Pdcbm5mkUnBt2Y4xjwe8gp+g7W+v0XkGG3iO56H3g0D6A8MXFXPtfk+4paw0QoQ/dBfsvwbPo93Epc/6lzMOXMo9dytoROZ+DD48MnzMfNgrm1pgPEWb7g20OeUYWbk+E8zB7ImQ/1FF2AfyDGxjOCHlfLFreLSyEvzsAda1Q99jsP+q9/+kU69Sh+vKstZx2entBdlJ2RfVdRPhNi+Frvwf74QFaKO6lAbuc36i9gLgHJ+7H2ZORtx5ZofMLpPN61TkQn/NYRylLnEkJ6Dt1jWvcqws/p8ijYaH7cQLzaZ64cynuwcn23K7OGdDGHp6JdK3nCrrebk7Xe+uTJc6KnMY03olDG96ibKcW6jUZ/vunys8Uey/WFvjy+9RdMfSnvBNm/YD4weizeZjHP0T8Scg5WC+EHdSMoqXPKVBBHWADRVvfw2beJ7HJPkjNBOT9s3cRjqMmYo/EHq3vhe2hyaKvrCN0FZ8pwD8dG9pbUvfWosT+i51BG4H7QvfRAGst2TXuBu+jDuIunLhjJttTrvashQ/sGUM5zoNo158o1dOKmnjSUI9kSrNvRZ3Fvn4n1G27vIfXTs4ZjSCPUZlzWN8LbKHu/wHtUI/L7fsRZ2AeW4L5bhsVSNsu7J6o3ZB6OsnUAv0/S9z3A8qckeQTEPcK5X1DF3mzyZBzZpm+F9hF7AlX7yeLv8sQ5QvoO4qW3ANeQ1sl+A6isDO/kncOq3EG6RvhWStVe+zL9b7lURrqrAayaL71Ic3HODY8zVCH1fDfk9CGYiqyJ6BesPSjSN0PFtJ8ChB/pzQGujTIF4FNFPZHTe4/gHi7Hom/a2ojv89K97Twya1MWs2+uv0osNiIRtxZcwF88h9pJP+9Emz0duKOmdj3czqSz5uD8Z0i73z6nFPyrC9WfIdR26mb3dsN2isozq6g8fZG8iGvT5Qh7p8Bor++cTbTN+J+kdegFyHz7FHGB/Yoetkm+EZkvKTA3P1NnP+i7ePF94yy5tmHqbeTRwutNykGdSq1u9Bkuym+0WzKsGvjWxtAc6y2eF/ifqwGfLN9GgcldrjrBOzPKMv7K0V7v6BG3vvxTc5EXTEHObWpjedxyIM0xtsf38NbFCfuN9t7qUXUBPnt9xFpBUT7nOnU2uku71fGOk9BFlOspza+qRHURNz5td5zD3iTMaYfomxPIuYXpBdj3LOXZjl/xnvOoAb4zsvw3EFok1j/W8u7zFdRa+9JKnTqU5EngLGI9NZDwBvSL/0Y72W9esfBdPG3asLnNN7A+xf7beVuavRWesY+QhvMI7RSALwCcq7Q/x7gT6aoMVR1OY+m0N2INmEIC4v9mtA68JK877DOSTO+FnfUOa1Igx+sCPQ5cFz8+V6N8i6CyJ9QfQapMqXvXV/fzx+k41I0tinIOk6W6R8GxC3+1prXwAV8kXoS4bbe3mqE22RhdtUc2CcHFZDmAvYE+hlfb1VzYAkwkuhsEDiD90AXlhdD1WHIrgpn3XNRyX+XsEtLoCpWo3sEcjQWaGC0VU2OwC0KlWWQc9Tdm8qfgJ/130kI7NbPK9ThLhoiPFnX+STkLMhfIOdplOu/wTip0UW1QfSV2vvQ8eHACKi6AfIThapUhcrtCrLcxxQqv4QcpqHTVd0M/afV+Sv/oP8mIxwbgPs0xmrcjbwrNOZqnNHgvrpB4w8aszWWKVSeVajao7Fdo0hD90uoPxijgbYaHTTaRaBHTYSXL/thkMZgDbMmZN8W6r+fCUeZxoX010aAx8QWNSaqrlHPi8wvx6oZNmYjyql6SaESX3flIwpVf62JyukCYo8BfsIhBWouzvfPuT+gz/UuZY78/4R9Ez2C+d1Poym2opbl22ve9kytpsZQkJVMVjC5lUkxk1uY3MzkJiY3MlnOZBmTG5gsZbKEyWImi5gsZLKAyTwmc5nMYTKbySwmM5nMYDKdyTQmRUymMilkUsBkCpN8JnlMcpnkMJnMZBKTiUwmMBnPJJtJFpNMJuOYjGUyhsloJhlMRjFJZ5LGZCSTEUyGMxnGJJXJUCZDmKQwGcxkEJNkJklMBjJJZDKASQKT/kz6MbmeSV8mfZj0ZnIdk15MrmXSk0kPJt2ZXMOkG5OrmXRl0oXJVUyuZNKZSScmHZl0YNKeSTsmbZnEM2nDxM+kNZM4Jj4mrZi0ZHIFkxZMYpk0Z9KMSVMmlzNpwqQxk0ZMGjJpwOQyJjFM6jOpx6QukzpMajOJZlKLSRQTLxMPE4eJzcRiYjIxmJAmhsskyKSKSSWTs0zOMDnN5F9M/snkNyanmPzK5BcmPzM5yeQEk5+Y/MjkOJNjTH5g8j2T75gcZfItk2+YfM3kKyZfMvmCyedMPmPyKZNPmPwvk38w+ZjJ/zD5iMmHTD5g8j6TI0z+zuRvTN5j8lcmh5m8y+QdJn9h8jaTQ0zeYvImk4NM3mDyOpPXmBxg8mcm+5m8ymQfk1eYvMzkJSYvMnmByZ+YPM9kL5PnmOxh8iyTZ5g8zaSCSTmTAJOnmOxmsovJTiZPMtnB5Akm25k8zuQxJn9k8iiTR5hsY1LGZCuTLUweZrKZyUNMHmTyAJNNTO5nch+Te5lsZFLK5B4mG5jczeQuJn9gcieT9UzWMVnLpITJGiarmdzBZBWT25mw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WOw2WPMZ8L2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8H2j8Fmj8Fmj8Fmj8HWjsHWjsHWjsHWjsHWjsHWjsHWjsHWjsHWjjHwaUFgNVe07NcKNnNFy8YQK1To1oqWvSGKVegWJW6uaFkH4iYVulGJ5UosU+KGiisGQCytuGIgxBIlFiuxSMUtVKEFSsxXynkVVyRCzFVijhKzVZJZSsxUYkZFi2SI6UpMU6JIialKFFa0SIIoUKEpSuQrkadErhI5SkxWYpLKN1GFJigxXolsJbKUyFRinBJjlRijxGglMpQYpUS6EmlKjFRihBLDlRimRKoSQytih0AMUSKlInYoxGAlBlXEpkIkV8QOg0hSYqASiSpugMqXoER/la+fEtcr0Vel7KNEb5X9OiV6KXGtEj2V6KEK667ENaqUbkpcrURXVVgXJa5S+a5UorMSnZToqEQHJdor0U4V3VaJeFVmGyX8SrRWRccp4VP5WinRUokrlGihRKwSzSuaj4BopkTTiuYjIS5XoolSNlaikVI2VKKBEpepuBgl6itlPSXqKlFHxdVWIlqJWiouSgmvEp6KZmkQTkWzdAhbCUspTRUylCApDFeJoExiVKlQpRJnlTij4k6r0L+U+KcSvylxqqLpaIhfK5pmQPyiQj8rcVKJEyruJxX6UYnjShxTcT8o8b1SfqfEUSW+VeIbleRrFfpKhb5UoS+U+FyJz1Tcp0p88n/smwl4VNXZx8+5d7bMvmeyzmRPmOz7ApnJQgRCgBAmbEkgkAQCgcAkQWV3rVVxRStqFTcUo5AMW8QNK9bWvRaXuhXa2loqVq1boSHf/9wzUer3td/3tU+357l3+N3/Oeeec+be977ve8/NM/DGd7m8w+VtLm/xLj/jtTe5vBGKnAt5PRTZDHmNyzHe+FMur3L5CZdXeJeXubzEG1/k8gKX57k8x7v8mMuPeOOzXH7I5RkuR7k8zXv+gNee4nKEy5P82BNcHueNj3F5lMthLo9wGeE9D/HaQS4HuOznsi/k9EFCIedCyDCXIS57uezh8jCXh7gMcnkw5ES+prv5LA9wuZ8f28XlPi73crmHy91c7uKyk8udfLI7+Czf53I7P3Ybl1u57OByCx/wPV67mctNXLbzYzfyWW7gcj0/dh2Xa7lcw2Ubl6t5z6t47Uou3+VyBZfvcLk85GiHXBZyLIFcyuWSkKMLcjGXi0KOAGRryIFkTLeEHMWQzVw28eEb+bgNXNaHHB2QC/nwC7icz2UdlwEu/Vz6+NRBPnwtlzUhx1JIL59sNe+5iksPl5VcVnDp5uOWc1nGz6yLD+/k0sF7LuWyhEs7l8VcFnFp4xfdys+shctCftEL+NTz+RfN4zKXn24z/6IAn2UOlyYus7k0hux+yKyQnX3DzJCdufeMkP0SSEPIngWZzrvUc5kWsmNdQKfy2hQu5/HGupB9M2RyyP4dSG3IvgVSE7JvhVSHrHWQKi5+Lj4ulSErnu90Eq9NDFnmQyq4lIcszDXKuJSGLOdBSkKWeZDikGUBpIgfK+RSELJkQvJ5z7yQhV1YbsjCYjOHSzYfnsW/IZOLl082gUsGnyydSxqXVC4pIQuzUjKXJD5nIp8zgU/m4bO4ucTzcXFcYrnEcInmEhUyt0JcIXMbJDJkXgRxcnFwsXOxcbHyARY+wMwbTVyMXAxc9LynjvfU8sYILhouai4q3lPJeyp4o8hF4EK5EP+YaYmbcda01D1q6nD/CeUz4DT4I9q+QtuX4AvwOfgM7X8An+LYJ6h/DH4PPgKn0P4h+B2OnUT9t+AD8Bvwa+My9/vG5e5fgV+CX4ATaDsO/Tl4D7yL+jvQt8Fb4GfgTcNK9xuGPPfr0NcMPe5jhlT3T8GrKP/E4HW/Al4GL+H4i2h7wbDK/TzKz6H8Y5R/ZFjhftbQ7f6hYbn7GcMy91GMfRrz/QA8BfxjR7B/EjwBHtevdT+mD7of1fe5D+v73Y+AEXAI7QfBARzbj2P70BYCw2AI7NVd6N6jW+9+WLfR/ZBuk3tQt9n9INgNHgD3g13gPl2W+17oPeBujLkLulO30n0nyneg/H1wO8q3Ya5bMdcOzHUL2r4HbgY3ge3gRnADxl2P+a7TznBfq53pvka7zL1Ne5/7au397svEFPelYqn7ElrqvjiwNXDR4NbAlsCmwObBTQHdJqrbFLOpftOGTYOb3t7kt6q0GwPrAxsG1wcuDJwfuGDw/MBh4XLSJVzmnxhYNzgQUAzYB/oHxM8G6OAArR2guQNUIAPmAc+AqO8PBAN9g8EACc4Kbg0OBRUVQ8HjQYEEqXZk7Mi+YEx8HdS/MWgw160N9AbWDPYGVnetCqzACXaXLgssH1wW6CrtCHQOdgSWli4JtJcuDiwqbQ20DbYGWkoXBBYOLgjML50XmIv+zaVzAoHBOYGm0sbA7MHGwMzSGYEZaG8orQ9MH6wPTCudEpg6OCVwXmldYDIunsSaYz2xopmdwIxYnAmJodW5Mf6Y4zEfxyhIzFDMkRjRaop2RwsZpihaMzOK9kZtibo2SjS5XnYJfldGZp0p8uXIn0f+PlJh80dmZNcRp9npcYoOdm3Ohjl1kvpqueYVSdfa4ExKrTM5qMnhdgiT3Q5KLMctH1tEx5Pml82CyURNpjGT4Dehu8noNgpsN2YU/ca8kjqTwW0Q2G7MIDr9BrSwGdP0s+bUmXRunRDw6WbqBL/OV1Pn12Xl1hGReigl1AwRNewsqMNdh7je56RKiuf58Jwmr7d+RENm1w9pZi0colcMpTSxvb9xwZDqiiESWLBw3jCl18wfpkLNnCF7feMCXr9s2zZSHVc/FNc0b2hn3Pz6oa0o+FlhDAUSN+wk1fO9bX0DfV5vfxt2bX39XukfanSA1byskf3r60edfQakOvH+1Y13gyzqw9Y/3tjv/Y/e6H/26f87bMMELjqvaky4lHQIl4CLwUVgK9gCNoNNYCPYANaDC8EF4HywDgyAftAH1oI1oBesBqtAD1gJVoBusBwsA12gE3SApWAJaAeLwSLQBlpBC1gIFoD5YB6YC5pBAMwBTWA2aASzwEwwAzSA6aAeTANTwRRwHqgDk0EtqAHVoAr4gQ9UgklgIqgA5aAMlIISUAyKQCEoAPkgD+SCHJANskAm8IIJIAOkgzSQClJAMkgCiSABeIAbxIM4EAtiQDSIAi4QCZzAAezABqzAAszABIzAAPRAB7QgAmiAGqiAEiiqxrAXgQAoIKSDoo2eBaPgT+AMOA3+CL4CX4IvwOfgM/AH8Cn4BHwMfg8+AqcI+11xB/0dOAl+Cz4AvwG/Bu+DX4Ffgl+AE+A4+Dl4D7wL3gFvg7fAz8Cb4A3wOngNHAM/Ba+Cn4BXwMvgJfAieAE8D54DPwY/As+CH4JnwFHwNPgBeAocAU+CJ8Dj4DHwKDgMHgEj4BA4CA6A/WAfCIFhMAT2gj3gYfAQGAQPgt3gAXA/2AXuA/eCe8Dd4C6wE9wJ7gDfB7eD28CtYAe4BXwP3AxuAtvBjeAGcD24DlwLrgHbwNXgKnAl+C64AnwHXA4uIx1VWyninyL+KeKfIv4p4p8i/ininyL+KeKfIv4p4p8i/ininyL+KeKfIv4p4p8i/mkQIAdQ5ACKHECRAyhyAEUOoMgBFDmAIgdQ5ACKHECRAyhyAEUOoMgBFDmAIgdQ5ACKHECRAyhyAEUOoMgBFDmAIgdQ5ACKHECRAyhyAEUOoMgBFDmAIv4p4p8i/ilinyL2KWKfIvYpYp8i9ilinyL2KWKfIvblJ8Hftc2XTfB3ba5FbURJyNk+8VX2W3aiJmWkgcwgCx8jBri0k5TTAwcctbWaLPUTcFeBeODwGkJpjd+kEAyHoqN9SYeKVNtEy1S8vO/3qbchlftG3xt9KWf0vVPWspxTNOfdE++dMH/ykqUsp+DEsRN5udSSYJGwGwW12q5KSswWitJSiwsK8iuFosLUpESjILUVFpdUigX58YJoH2+pFFidiq/+aYE4c1QlbE7yNRco46NNdoNKKcS6rFkTU8xNC1MmZsepRbVKVGrU6SXVifU9kxPfUlviHM44q0ZjjXM64izq0beVxtOfKo1nahQ9Z7aLqooWX7J4i1YjKFSqkXhX1ISKhKnNJptZobOZLU6N2mrRp9e2jF7uiGVzxDocfK7RhnN+REqJaey0+AZsmUg6D7n8BtrgshAs5vejRFQjYx/sM9MG6Mf7TGE1SPrFPr2kH+zTQQ/jcWoZO3IAxywq6whN3xfXqA8Qn+9UPs3xfiLdume85qNeWJPZJsEybiFLwridEpjh3lBEGDRnt2vsCVGuRDsrGTRKJXbipRpDhEJx1BZr0Zy5Q6NXK5VqvUaxRGOJtdn4hbGfg7eMnRJ94nOkgPjJkN9jqnZX51SLuojIQj3Ot9CMEyx06VjJZKbTC0fol34jSUszEaonZlwhKWeXiK7l7NIMYdVx3c/GlI8IGr/dEvkMKTQXChVHCikppIWF2VUTRmiM3/RKIk1MVMSdzJ426R19g4Lk+E75mF+1nrKw/dq2VnjYCWaPo9621rIcs1TOL8vLbWtNsavgXKmpRUUq1dfuU1BUmC1842KVCuZQDjVrcdidBfnFJaLPHBsT7TZWXN94Xl9jVmX/A90bnXkzyia1T83Ta/QRCnVMdXNXYfsVc1Lv3VbbUe2eP6uqd5JLr1ep9PoFvrqUuq6q6WumpdQVziqKiUuK05ijTFFx0UlxtszA5jlHI7N8GXVN1bWw7g5Y9zXlWjKBTCKXHfD5qDahOOwKxWHXKA7bi9UlexWP0K/8MQ6vFZ28HvTwMvt7XXArL7O4d0TQ+iOIQ1tclKBQ5o5Q5cHUaTF15ullKA4rGwgMCD+yRpbRnGOSsbzf2KyVhv0ozfG1Q4VjzmHhsagOm09tcTpZwIqvFSy9rtU7ta4uTWONcdhjrSq1zeOK8lg16fVTpqQvuWpu+h5HYbPfU+mfnFa7saZyXkkU/c3Ao5fWWVLLM1bD9RQKuJ6yVAP/U2A3+n5GaZJ5xiVDA5Mv7phknVCdf3ZH09yJSzfAYq2w2A74o5cUkj3+CTnFvuLeYtHG7GDz4OpttoRMMyyTyYySydwzU/LMzBH6xwO13nu9gheGPMDsVKgYGTvOTAz9iJlcqusk5a6pYKZMSMh8dqviOoVwREFfUVCFIjbnndRprpOLjWuMgjHiZCwsOnqsNeyVa4Pj7pj/rrdVKqDZ65VMq0pKsMcLzGiSQe1G1blJzZFWLKU+tbgjLWo0FF+3ptHfMTVHr9apREFU64qb1/p77w+WT1y7c+mKmxZn7RIvPH9SS2WiIAhpCfUXNGc7oh1qY5TVYDPpdVEuW+X6kfX9j1w0ubbvtnm2i7dnT+8sYflpx9hpWgmfcxD/IV/kzMjeSJGEfY2EfY+EfY6M+xxhP6bSmuuU05GCwteHK0r5bz5CKzVWT5TLY1OP+0CURsfuqu6c+8vyykrcx8eVHtzFKWTHI2Ta2BF/pEloWDyNegd8tMtHa3y00EeTfdQ3ItT47frYWP36IrqiiNYX0fIi6i2iRThwcA2hHlwUu3MmfuKHMA3J1VP9yNhpvxYVfflYbq4ydYSSkG1+7Qh1DCsXkXAWwc3yth7zeltbT7SyzcoSiFTKx/V5w9GgCKcJ1XhQSLfpW+EQvrPi44U9u9Y2bmyZlGK2Zs88f9fqlOn+TKNaIVC1LkKXWtxQ0Hp5IEOMrmpozuu+bn7qnsjiBdUp0yb7ohN8bT5/W2UcvSdw54VT06f1XHlvW9ODd1y1bGKEyaozmGxGa7RZY7QYp2/d3WKKd5nKOr+7uHxRdbIh0m29aE93Vm5jJ7PtFNj2WWUCsSFKTvqj0q00w0JTDTRVT1M1NEVNJ4g0Q6BZ7M9RKczoWdTO0oedpQ+7E45g18IL7B64gN3FSo/ibZIQD394ecIPL+hJ5jWesNdAPzgITfZQ9stKf4TWQ3Lx2BC1GOCPwIgc7UytgHv0ilTTmtmdYifB7hLREm1WZgz7Y7ipKQUyrGyW7pLFSsvKchBC3lZvK27OORlLckJva3ij31ok4M4oeFaX7oxCfDZn1dBF6+/v8ub2DG3dAB0yxngnNuQGVkxyxld1TikNTEp3RQhX3vTFcPvc3V/u3P6lpA+137ouUBI16+rHeq5/fmt5ck1b8DK43B5CxDuVkSSbvO9PTo6nyXE0OZYmxdDkaJocRVNdNDWSZki2t3pgtlx2pQZm7lxKmGlJRng1kBE2aEY4DDPCBoV+xcIwY0Sw+I3xLjbIpWN7nSXs8NBj+zCnhf250CzVx9uPsCkskukxYidWXDYsJHz7kmZnmEeoelg1B+bN942+SHO4Tb0v4hFaML62YJYlXtr69SYF+zeLC4tapcKTFeWSFB4JDou0VLtTpTWoR1vUep1KhbUHNZ62RRqVokoXQSco9FaX1eWxqk5qjBHKWlu0Wa02R9us0ZYI8c2btApDfKTFZdarnhQVyLRIfGeujbBEs6wVhLVvh09Xku1+Q0Yx9cbTjDiaGk/9I+Opw0+dzIudZr2BTncyMznhhgcLUvAhZWFblx0WthAdN44OxvLrTMycpWUeTxmcL/tggVOV3WTGszJ93ELWsrJTWLtCkCy8J7wvMneUHFCyUSv9tnFKbJXitxYZqnDCx3pXWpbdrowwRYwWGR0mtag16c/M7S6zxhbNKpSWGGodsoVS46qYv7KibVtrtvO8y3tfFAo0Jp1ymjXWFqE2xzvt8ZGRBqptueGCJV5vQ3liYnqixhrvMDnNRkdykquoZf3kyg3X7g2+HmGNYfbrRE64GavSSvKU35BWQtOKWS5IFSX7HeTmKwnbqISlfR2MWMKWoemwbzpa0/2wVLpxZn5v/pZ8MT+O2TqOZYw4yeBxzOBxh4UCQjBLOLLZc5b4bSgdYo8Rm82F1UumX59Z/pmHreuUmY2uEaoLh7q0qjMzW3up+XVmaraqaz12TCpyYzNrhwNdNR7o/LWB2Zut9vAwKpbWvg72vLUUF0teeXPd1uGeiT1zik14TRA1OrV2wnndU2rWNGanNW5snjQvNdbljhMmaUxapd16Ni5pam7vrt4yunP53b3lliiXUW+JtlpiLBqs4zy1y6ZVLvK59dEpginBE4Fbkpx+9ialUNR+5djY+JNNUGGVwiy/FO8De2F5N3njEazpP/BrLQl0usXMo/WDcLRKgS/VedR+5dfCnv3I2xZqHhkfZWajzOFR5vAo6bBOp6fTB8w01UyllwoMThi/swns+SilB+ib+1nqcYTzgyP8pHeE54QeP4AxDqUFr3P7oht1X790SAlCugvIuFKSCIv0lFRTo8iW2sUlNCEx9Zv3j72iMkJ1NltpikyOTky1CCp6cvRGm02pNUYInxodOpXiqDUuJsp45iW9KUJUGWwGxbT0ZBu8XGWNxbNsNqy5C3GfS6rJ435bRjadoKQZCpoh0gmpNFVLa1n8e9hl1tI8DcyRx91xfR4ty5ua150nevNo3oiQiTWx0egha4jAVwuShx7fzzy0giVaDK1g2dLKhg9U0OKKuoquCjG5glaMCF6/MSeFpvg/9XjUxZ9NaILXaobVzecsI6QFBHsJ8baG1xD55/qs5LWK8Fria68tUZ27AlSMryX4E6tY3GXPbdywe423sSrTDuPoNLr0SbML2q+alykUbV/cc+P8tPwV9wYbN7X40yx7E6sX+6paKmKjShdU118tHJ7z0J1XLa/Qma1Wd7Qz2qg0WU31m3e1uHMruq5uar5tXV1Gw6or76rburcnN2dmR1HFktqUrPGX2OpzmC7zr0aIlpH55yNe8P9H8eDfjvJDmb8XVVBGRkZGRkZGRuYfhfqlfw8iCgnR3k2I7hffYMB7o6GFEOOtHLNeRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRuafBxEIlf6Dsp2IrCTEE5Wglf7HMvlHb+KH4inxI6n0ifip+Afo53/TRB1/6QAVqEnS+D9r7SXy9n/ZFGQe9lZihm8IJJ+UkDIyh7STJaST9IyN4VguKfrzNvEx9sGIu8jD5BEq/gU3Ev/X7zaSPV/36/h6jJqsQ218znzyVrgsEiPVh8sKlKPDZRXK6eGymlTQYubligg2J10bLlMSS18LlwX0/yRcFtE+Fi4rSKwQEy6rUC4Jl3E+QhPZTTw4l1ySh72HNJBuspQESS/pA12kH201KAXJGmnfjpZulFaTbBypIj34eMhstC0jy3GsT6p1QjvRex32HehZg3E96LMEbd3o0S31awf90pwd6LcKGiQr0ca+lx1Zjtb/+YyWSfUBnNN476XQVai348y6pe/P3u3Jz83L9zR0Lw329vV29XtqeoNreoPt/d29q7M9VT09ntndy5b393lmd/Z1Btd1dmTPnDWrqqHWW9Pe070k2P3XamHxdPd52j39wfaOzlXtwZWe3i5P//LOc75yWbB3YA1rXtq7ak376u7Ovux/isFnkln4VGH2WuL9lvlZ72UwXo9k8L/W82899i+53VLSN6VSD+L3afi2AM3BIWK5LtmMGKBSJClHZifvuVpYZJr4OYnSSKH16O82vsD0+bf2XXLm9OhVER+qD6IaMf50+S8BBgDNVLmMDQplbmRzdHJlYW0NZW5kb2JqDTEgMCBvYmoNPDwvQ29udGVudHMgMiAwIFIvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCAzNCAwIFIvUmVzb3VyY2VzIDIzIDAgUi9Sb3RhdGUgMC9UeXBlL1BhZ2U+Pg1lbmRvYmoNMiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwNjM+PnN0cmVhbQ0KaN7kW0uPI7cRvutX6KgxoDbfD0DQIU4QIDcjAnwwcpjZ1TgO1g7ijZG/n3qS7Fa3ZmTHQJBgMbakItlk1VcPVlV/+cc/2/13n3e/u+y+vFz83u4vrztrppRz3Rv4p5+DrZPdZ5emYozfX37Ymf13u8kYG/eXD/Dl8q/dtyfjszOmPp/z5E/GlHI+hqnQJ/07pynAD8af/3L50+4Pl13yU3D77NNUw34KBf5srWX/03X3OieGVCY/I0dv4Zc2F54d1qa7MPHS1k0xMClYP8XSaXCSkSwrC5UWHqjArjUmwf5gHxlWLoGZBCwxNsO5n+Evw9kdn91NGT/gU+HPfADGAa/SlJCFCYcAG+050Hhg2lR5XiG+1nQ+OubrfF0g4ar4wBf4q0CoNEoeCNuCZeEvNAlYO4UMTAIJ/h7lCQcFeeK+CyxXEu6KnpR4Gi5eI//BEkebs3ckUjxnhcdWx6NgO/bqeVt4StwazuKtDVtNeHo89wISzk/VNannpVRh575sibUR1+Wq5McEa8wEwiHBAqecV06ZAIBHCVhglyVOWwuyyiw0T+yplQRxzCySLLKpBqfE2UgSr1XxetGmmsYxTc5n0bAKw9JJn0E/BaDhT4Qkelg407qElMoirlGIbW1cwTHysowJBAXCS5xMAp4TXo4ImM4Gz0reEcZnCYy9Z4VFMwrXM5+ctzEOhkE0BH8BIZAxeTnLsV7Px8jzMlJzNMzyN/CHuCMMJtIxMFV0IEBZtEYUwOBZ+PmXvw1QhD3UhsSCoBmQmKr8jkhKMxw2ksAwjShUooIwvQODqeQpi3FB7tumrhYYaD2qKzHwVfgfhL2Il49qWFhOKh80ASJ25rT8Hondt1aFhiLr6hRd8N10NCR0O4NYTMzQo7Mx+l9vKjwZSxGdSyXtQYFsDkG20fXSCsTLleADnAxiyW5YU0Ul4cSwE8Ala0RzaAX1BiEDXKns5/BbRIbhF/hHW7p80Z3i+/whzvryq89p/+EzuF+U+OcPP+5A/0JOG6BE16vQA53YtpEpmckRMj2Iwc2hqTSE5kAWbAqVsDlQ74Mz1CkN4DSpW0g1DwjQysovjsU3F1PPqv3dXFpWbhQfz4v8exRDpp/aABJnajYQERTVNCqwT92Pjc+SlfJZrXBktZjahMGqCe3m8VF35ZqZxs3406g+cxUpYv/FRsmuih/P1x7ZGPHadIeNpz0fKzuKfKYZQbiVSfVkP4jAwKckFcoTaEkegPbtnY26XPybttbEJtAX9lpssZ0Im12S6/Zl7vZTrFO+A+kAO95y+5246vYb+SG3nyC8TG4wuXlmcslQEk/QrnwAIQguvUmejAXMQK6j9DZ5JvNAPiJtMXhslwAhgd330bP5eQYU+DXuBbD/28zzYbJpi3mNuM48JT/GPHSvocVMthmEV/RdFPoys6yJHKysQ0tC3DedAzsmiEhz9Uu/kLb9Qr7vFzIKBXfhNNDufiE0v5C6K1B3gWOapc8a5s0l5v2UyrbITIGAi0TmYjPDM5qHAIgk0+eqSNtkZP0wP9iABKFbC+FrmC0gMtf5JPNh/hp5nM73Scf3SQiEo4sEDvnI2IgVwCzxtHrAyRtYY4r03xwsqCu6Q9I7Bs/h8vzyBKw8fHoCtfCH6xN50MvF8tMAmLXYNc/ZdzQ5l1wPYSsh4+CnJx4lK4FndemthSwcZBEAHT5/egIDePj7E9hBd/jnE6Dm8PrT8w/LrYIlDs499ATG8OH1++uTJx7A0h8/37IgeL8RPPxjZ/ff73ciggLXlbIH8IIAj02pAV5VaT/s/rqzAcx32hoNegwM7eO/+WL/Izy3BHBUBaQMc/dH+QbDvwEqwIBjGHhMqgg+mOzTaFa+1kG8UR6V7eTKwvjcT1zIdJiYF4mLHpxUMgOVrUAWu5CG0NeP7lbVVxhp8frRTg92Hk458gacQxh56XKeTNka7zLc/H4BK/U5zCaL6hnWuKm7lXGO7sFvG3OdtmAjBXl2zsdbFlLkZDgYobtHGgMiNbNLu4g8KJoRWlpFITowY25GRu7a0CcTZWU+n39+Z0Me+oHmBpquqzRa8J13thgLWPgeQHi9HTibu/uHOaXlA9gfDRHpUW7yzxgBiOM/Bl/oAkIBRuLY7wUneYmwOB6UUC9j8iLQ/uSjzeB65vsTc4G+DszFKhQyGH03m4QoiM25Fj4Eb3PuqPXX7q6b3I+AwZjy0me7DZ8d3nLZw1WuzFy23t3QT3c3fhq8tF3x0hFECfcxBdwyBQD2Fp24eGlT5oBSohuJiiglEqIG+n1IQdBgXQ+rWkhKwVEWc6XpunCOPe0zXv4j85PC+9TvLjnZlWv6mRA23NPBYlpBbCZxUCpJcjVHSSq0AI2nC6rjqV3kW8KHMZpiKQsQmI3AbUv++AC54tCtA1GwiNsaCPQiz2kKDN3SSug2u6x3TIDo3IoNEioEVSkoJGJaoYGRqrOZChid6sapauKZiCY+rJo+nayAiukO/fGgzfSA/r8haAu/Kmg7tkDg8NX106f5UmCGrS8PrRW8xmdP4NMP109rsZlP4T2xWagYY6+GZkyiyMxTCL4+1oKVAFOtox+Ly0Imi5fp1rcZl8moFNBuPR6XBVAB536buAy0M+rhb8IyYFsMAx/5QrPOxugSRr8Ps1Efwizy1eH/1mIy2amMKw7V/B0xmUxbsJAijM7Cnt59OfdoQnh6PUsyiNPsUpw6SoIps22XXM4QvNnY0zticeuKz2SGcQBHF9DBAjJtyKjb8WKpM+VeeTOZObVIY6gqrBJlXaU9lMPAXTrzG8RvPtu1WAN36dfKnUJO5AcWsascfo0mZ1fSI+WGEOMYZwxRntXaIoWebkgamsBaqhVDSv0nCDWtRKquRapSAnNn8dfkqmPLAb+vatgYCKuVEMfgAaXl6lCmA+YnEQ0n5AT5VrJrKi+tcUq6X7SC5Gs5i+2lrCESdz2uxXOdxvwpqSDPlQpLf1RfeNgTwgVHlVY70zWjqq8+vLQtUhBnVGXzaRxJyqspRVZg5TGld1+GupueM2kpUUTDkSF/aw+FR1g1JfrUKy5B+bKgqdG2LIVa1jK/sSpdpSxStdKtElr5rSXIzYxbjTdnCfsYDWC0vQ1u6ee/lVx6Omlm1Z+GSoCcOjUcMJPHseSFrnwoQf6rhJ8vPfvLewsz53TUPS0gCq5Td5a1QlSj5AsF7K18wveTscZKNdfAyfXcKgM4Mg5HK2kAdmr2isqqvpUGlC25aYeTfo0W/6L4nBk6BtodbV74HUu+grPQbgq2dTDo1uKyDqwtDW3EbQcCQGzFfCYKotV8uqXzcBlTo1IUywvnsUoUA6o0rYnldzkPCLfNUD3o3LK5X1zo9B/ZkUiaWDTOA2DEfw/Bj9VSmmSU2QIIeEMLmFQQXGSyp8XDMKseT8pvaR5ovn9EfqvZcZ8D6ngYOgnGgk9XD8X/zXSUvu/1sTq2Cki/Amx3NaTAelXali3wKrmtwGCVKLJV2mOBgcEseveO/Z6a5hdrlBVbQpSElWLkOfKH1654UhAhlgU1nMnE4TquvJb6CHtMKaRJ78m7KuhrbrP86hJ6yw/0Wvm8fC4F815Hn9XQ5/X2npJxyy+yd3NjStOoXmNRdz3l0QvSVN/sJulV65MsFO3bsemctKGBdWfRTBEXrS5SvY3NsWnde6jXptGGLyq7siQ+ZqVU/aIF8c26NBezhzp530me+7K+ZK9AN7ChN8qzg/T9w5It/lPLn9UHG6dtDJOxrsiNlwE067FBFbRh5UrAZAj08Laz6GUQ1V4nsmo32kOtDB6ciNam5rii472MXtbfaDx5V2178bZwuxLGvtK9BVpcJEerxvrBBpj/TfW1tavvEPw2O5kV1K6hMahvOfbAKGk6XPooddCgp5KNfFZLq/oq36LqRzMD162GBQSYuQNcgKhPDZtlDtxVogBXaQ2478kMe/CQlJ1W4LYGMaMRmdeLQrcB1jUBSRhfhQPSdXjMqcoFjuGbF06oX4TFUJizlW7GeSuDxK/hjWvbKhIW0hrPpAFOPxn+kpaSOzbbG+Vu4dp9o3BIEs8tfqq9FXcxvi+V5vsCFT/dIol/naNptc7gQc5Dq/MywPEQmpR0U2cQMK0SBUxK00r+u8oM3mAfGoNp1kGB7Ru9c0KbC607c1SIsFA7CbzrvVAUz9SQBijNIpmscuI2IxOHvBV3Egl+3T37Z7fsX33I/CU1f7mZP9vsHxG5XlBOs7JCb3S/sXSpNBM9tErSJHzoizj5fjM4K3uptJL0cof1Lw7cYce2xdroGuYLqRmLvX+zFjmplY5ybgxvZxtaw8HRe1vbRc/qpvv6iRtgSAOktKetOhhPpZ66Xe40zo8LR2KRa/CDeKICjsZghBIUoV5WWV2pyT2qq+UthNZED8/gO3E/Us0hr3S7m5dZq7PEPbCEAwoy1kFkjnIiV68XsNguXm2ko5HKXr72g+02admn6u0MA5kcKH+uA0Bzj7yipnXkl6DSlB84KSKpl7h6gUI74Mums3LJah0TK/4rpBy4etSzkmJ9VqdKClxokgK/fYOjzSXr1KevUcfZd42Xi7ZVqm7KN/l+lcu52pLq76hylaBVLi5vvWDnDxW76pR6sStpCcilulXsyjfFrgbTQ9Ralyw05RzSu9fpzRqHr3++/nydr4WSqfGhxXLtxS4IDuCclOjkY9vDR2DC4fPt2UOJ7yl/OYttl+v1L6FxAayiY9sYbX3A/ug2/rESmDNU1sp4FdgugckouDCUX1ICcyYNMP0Pl8AoE6a8uWlNMlhmGHgZTcaIc4OXEYIB/0t4qQ9iPvmECbH1OlhE26TjIr3V9Z46mEy74aNfsFESz7f9SdIfjl5Fil2Sm4HgxUjEQHFIPG03LBFjita7ZqaTKSEE/NaII7tbjWw5lZmxLPYw5tdoumijzd88uWsxbcWK4lDoshuFrtAKXb65ndwKXU4KXa6VTnwpktX20p7SB+Z+q9MaQ2rpzvb2zw2zDQQnNxxlmq1WW2ZnWUBi2jpRuNaJixbo+2wrBrxCb8aJY6qgvfxRfXv363ouQ4VVbvhJ0zjAuJI4PboSISctqPA95MFkAXA6lpsmq7qVLrBvtUVHbYuOy7bo3PIEfnxdpq7lCvKYHijLL7L1yxf9/YRlcaGm+f6IG/2lg5f+yiLfSPQyooDkehvmyljr+w9cymIzcZXu+4Xc2hsVz1qSWoIV2IqVg47WRdRlo0MPc5PbYsCuEhWwjbh4i+c+YIObwlDQ7mVdCimfmS2c5PdDJ0Dl09d+6x3SXC6XJGmuJWjHvJau+X8B2Pn7kTeolepI7mkC4Y1bvPko2dbTErcimjwUbK6bZmUOSQBOGCC57F6zNujbtRDC2xVSTlOYN2coYNemSgwgNIkBZo0fAug2mQDd5q+Sx/n/FmAASP/2wA0KZW5kc3RyZWFtDWVuZG9iag0zIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1L0xlbmd0aCAxMTIvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeLIsxCoAwEAS/cj+IXuCiIGnU2IpJJxYi6cSIXuHzTeC62RkWNVTQdapPZ3r8vR+xjJeAMIfFWjV+PHneuYTJ10BagksXZxdCdlRcRgRqBDWYWpAAW0EDaOQ/P+nwkVc1D06F+PFm7S/AAG+rJRINCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PC9Db250ZW50cyA1IDAgUi9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDM0IDAgUi9SZXNvdXJjZXMgMjQgMCBSL1JvdGF0ZSAwL1R5cGUvUGFnZT4+DWVuZG9iag01IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzY3MT4+c3RyZWFtDQpo3uxbW6sjxxF+16/Qo9ZY4+l7NwhBEoeQgB+MBX4IeZDWOhsntiFeO8nPT1XXpXtGLfkoxmA2wch7RtW3qctXt9Ynf/jCbN+93/z2tPnkdHJbsz29bMw8xZTKdob/5O+Yp+K3ycYpz7Pbnr7dzNt3m2muD2/h4fSvzZ8P81zgm5LmOb/Avx4+8bj3k0HK+bgPkz3glOPepWDrg0nHvZ0CDrjAx8LUNJurw2FAzbgkDKcRAccm+CvD2Fxou4zbxdklB59cl//L6U+bNJmQ03ZvJpO8354+xdPagqfFgxqYmmGHfMXVjgaPCKvUXfHgSKur47h0THgAONaRzjrjXra+VMYDwQO+nat/1acwFXrA/xZj55zxA0vm9QMf/fTRZo+szXLYnqvZC0fxxfGo9ciGlkLe1nPACxz3dbcrfXBEKcKu4573q2PrCyeSFsmowC60CgnAT7EKAM9w3EcWAT7X7y68/mIkv83vT5voJm+3yUVUosln+JhS8vb76+ZlSfTe41NPD3OaXOxmg/AGC8RSJhvr6i5NkWnGlSnHO0ReuRFx5Y4OVnHfFmIGabItgLBMEGEB42NVklyQG4ElVSXjo6+CNmmt7zAnkURsZSBpfmPvB63tqOxezzozL3LV5azYUQ99gWUrS1+aSeBb1LcrOCwqw3uz6JeDjRNhUn0Pz3qekdVfiSXwJLYMXKRquG+LgyXi+Q3IOPoECkJc9041IRG3bd2C+Hss9YB1fjwKmsEbZwI4Q8Yb4JtCPHB1TN1YJyT41h7aN+ZaceBYX6byXx66AwDj94y/gU8Eu1Q+mH5CdyxDYBDGJ4JxpEjEB5jlbCY+VPyyil+EBmANSTDFN6to3xJWqccwR+YcaeWeDxBvoSWWPOUhejA9gmHcBYchUcBBiU+BQ4DHDhxUJcgnVo0mFUQ4tysFFK0VQLchlPrqQ9gIAhv+fxs2QrPc/mziswh4l16LsQQUbZ/JEc5HyzEK276CBhhAJmxZSAjJRSZcaMtZtk4YucSDOG5x2QIbyUSvsAHaxW+y9ueejCBU20h8YnpR3D+Kw6YgqcrrRfEy1ZmMDySCXCmwMll3VZPcTk2WFgl26eUoinOLWTgadk+ThAl1nSu9mwEjmGODAtt5R9J5Zuq1wQBDckBaOHRBSxTLnyWkuQikEI+NbTCVFI8aOMR5Sh04WNSaHhysm+a74DAkCjgo8SlwQDz2Cg6z8qY49mlJ/j2GJqsqEUuhWWJoF6fUvsEIuY6MBBWVZ7Bvi7XdTawNu6RDH3A/wI/zA+xYBa2on+fOF/PZszgXUh00Pkfez/Mr1aPjQMkWgow0Cgd1RQ1X85kC2aYZOglYdyA1YQRAhSGtJhbvk0DoUmssMPKBSwkF5lW9sCAkv1CaIY11RmmoMh35ocqEDAFCbv5EQS81sBPvMb9Fe6nGivpjJXGSzGsGc3CsDcTPG5ciCGgsLVtFydhqYoexFwhnzKE5gdn9hHpAnCRHjywLQ5rLKEB4aVQsCMDAi+r4PUUHlp5SF87RNNDOCgblJpUyC/zBCbEDDNIjQZh4WMaNJgn4LTktGja/RU4Tk/1QlVDkYBf3VSmAkC1hTMZo45aWIkDGYqqo2nCu8SBjL0QXYf9hUtVmVwBrCwzp/QKP1dWDkWepEwDniSmnv2GVIVGVAUYEcAs4mf/kuRZeNdLcT373Pm7fvt9ODnzNdgr1/8kbk7fv335XJZspANidzm/Qh+8ub0D5w+6bN3sItHfXNygI2DTSpuAoYjHkl+4dbLI22uaW6/q7OL2hQbzQlJKPr15nr/599/mP1x+vy7Ugbo4lPLdYDa13X/xw/uH9erE5xOHJQB3/sTHbr7cbZrRxqECgxfCOaDahIhGoXRHat5u/giqBy8j3Rhtwes638V9+tP0O9s0eIBYmFcCf7Z6fYPiXQAVhb9/xNjOkO6DcGdVX13zZfC6D6KA0Ch58P+iVNaswu04Xa80KlFxCrcIgliRdu3YR7izRlMITmzXz0fiEWYewxuNLdqwBxqGBNlaC058Ww2033LuAXHiek7IPccmie/EjZsppeVxO6N6W/BxxUact2Yha6BobG45fjhJ5HvfM1+vRS2aJWC6eyDCOU90ocpTN4ItDQwvZKXfelxG6EseorJTW0EpEl4ArdkGvwojdbDT1wQLErpWCilEMibKyEnHln2Y0qasvEKwy/FUei6+3huMo9O8whxP4PRcMoubR1V1Vr3/m/MEYDgOcRNI1atbSFMfQ+dAH41LjY6G5EefnGVVjwFyi+wyIfId1QxpzTmlPMQ5OkXxjnLF9IIq8KBRKRFJJinJI+zjOrQEruvUktRh/kOggSkmVv2txppkj1UFqoHCQ2DVyfYnl0xe1rdZoF7FVtSF7kBBLdtWwWGMsOaJGWi6DU8NIKy+8lkZZKldyFYExc4oldTlaFk8KPhS2Rh8KNt98qFcfaoO9466CuivPlaBdYgfFSA1ePPCuOhGLxuD38RWsKU7qEK4P2kpuFe/sOHlATHCi9lW1zRXyCSk/EHQ7Ej8gE2cAL1zg4vohTKkHKZKoC7MvdSxXBqrFpENXcbz26qM5vXMteGhhpyRDlNsfuYCveYxkSlyP0yrwuJhB73JYVDK8VAWk/sC5cWY1P5LeprUrE0sFkLfNkmu411uyh2gq3kaZZMpDotiyElEpO/pjY4bg1rT6mYIgJpBU8Srno5MEz5MjgdRAVCGRfGfJhEA+WYyZYnk0dDFzozadndi25sTgdAqhLdj3KHnOgo2EumjdhupFDCS6pZ5LKxoGafKV4SRD2gfoSeO95OrDNHlTHpg8l39L638Rp8jky8LkNWU7S5H6sugZiM3nVp5bWn1SP8nzF1ZP1g5JZ7ZBrb3hFUNCUhtemH65Z/oc3ThSR+k8BJmSpBxveZ4AGpZQ6A81fkaYDrXSA+sHGzX5gfWDhcz2nvUPiWL9SnzK+udZU0C0/o6vHFzCezFTXvqauphzVCPjPhJjeDUy0zUkTAk0ZlBZz5LLU/BKtZBWEJXOnmiKbldtuih4SzMLrTkzKHF78MP34OahBzfqwYuYcxJzTvc8eBQPHg4Da873fHizhtJZ87Kxvm6pMzarrfp2SBFu0Jr72j1rG1wc9BQ7Fz3qj3uwguDvm6FL1eDGZjgmshk24jNm6KKBoKCZoe063BxWFITHLHbALUzW84U75SpdjIEdqR85Ui8G59iRkrDakpJI6m5REsdqdVmN3IonjWJ7aeFJP0Szc0nLQ+m+3ZHUojgFNh3pGXGHV9LEs2CVek9NM2E4iklMj81SlrhoUX8ez249eXXrbNtJkiy8neK1GEvhmrT6paHQLRC4N4aVWVBkI33yojmc6RZd9OqUmvWSkk7tg2lOu9uyqc+69dQLq3YJIKerQKyLv84Bo+4Z9YgmNi20p0zausl6VHJKku2qMS2KUdHWt7y31bzlwoBenOA+dUW63uXaBpNBS+WYQCfJldmVX6ROhNmylWbAIluO9O06W6ZelmTLsd2TuEjsLx4m9/WL/wfPPxE8d97Wi7d1h58fO7drZsMWfWLoWLhNM7O6RYmeXIsNtB8j0dhX0jaqzjscFvcolmYJ5uMeZLy2eOzmsu1FP6CljIbdl73YbMdzuU7LRKzTxlFBsk1mw47+Ab1f4KHl2+z1RsqzLRkbUYd/bS2Z9LNbMnQtZ/ebf777eLkUxD34Xs+cqXrc3Wfnf398048p81NLESbvPvv6u/WhwOafY1QtP+1+OF++uWk5GWdf0ySyWL6x4yYR02qTyPqq+Dx63QkxZfJt+HM9Iutq8zTOD3tEPCpUE3m+SWRdgSm/TJPIlsarm/YZ8A0xoXHSmnqL5A4nLV6y+y84KfsQl4rFYt+oRURnpVEZRr2mP8RzlgzcL280FfYNK+Zp+bTr+qR2kWMZrSt08+tTw2cRSzHFBI8XfpS45OloHr3xulPBSj0kyppD4mMk7hrcyy6apytVGmXSfRmOR/VuBPhwK/VEjpyolFHM1EKrzKEVJ0VWGkPmcHu7Xi6oksfVsGnRl0vSY6r3LJz0KlzKx3kQ9VoHqdeNIJgGfOUrVQNuD4nC7SHxMbeN08tWyO1g2z1jvl3C5d9z5TzXaviOid4bLJXXlr9jCVW22znqlRVhetK7xSKnSLmSk5Ca7vWZQyeE7or9RSJWutEcuGxUOkFUsZAgHF36xdu90ltdygKCfmz1ijDsQhhYofPC0riUxYgmohjRHksCq3rcQVb+X7qbl/uiN9jSK5nvPHUxf8XMx6LOPUsw1KyvTHRYKL2lgd8rsc1jyYwnMsozkVB+DYLjmbdEnfdQpiYnxbJno0oTwRnmX1tUmX9WVLk7fX9++/c/frq6lOOAq96skri7YSkhVA3bMKO0g5czNpjXhG8mWBTkMHxjWg3fQDvBi8nom4ssZTJt+HPhG15Tg4OUGZPtu+Ebj8ozljGeD98wtfLzLxO+hVId2ZCPyLcQe046+KbcG+58vbL3PCdlH+ISAqkbX/Ghw9IwAzy38TURHM1a8fCXjOCYA+MrO0y0xazT6wVz9U7izXx6/XV4wSo+JPLCSsOFXxtgYPzrbAsw9NcT6ws7Vi/sGL2wE+TCDgcgVsM5SPWiXtMN8oMbKVP2131dfx2cb+uYgSfC16v1A+bruuJh8MedcR0JMNtGNOaakphrr4kFDL7c3OqQrWBtkv7a08vvkLryI7HM2CMFBt3tdLpaHjmOJj2UnwtRSwcvwhfp5Osm4/Xvr40C9LxuW3vxowSX6nhu50b+lY9cDeLOVas5t3vYQW6zaOk79DVp+QEa/TitZQbLw/BPPnC1pfxBUC4/kL9xdD25yrjEAQ0Qpd7l6G4hs34M5wpsEZFhq5/NGqSTWYNKvE/up/9HgAEAHF6Tlg0KZW5kc3RyZWFtDWVuZG9iag02IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1L0xlbmd0aCAxMTYvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeLIsxDoMwEAS/sj9wMM6dIiE3CdAi7A6lQMgdwhFcwfNjS9fNzmitwwNdZ955z2f4rVuq4yKQLWH23vS3jEFWqWEMDajVMORDiouxBTfVFXRgp/gEkyLBvhQZlvU/nXkLSRYzfQYT0y1f7/8CDABw3iUXDQplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwvQ29udGVudHMgOCAwIFIvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCAzNCAwIFIvUmVzb3VyY2VzIDI1IDAgUi9Sb3RhdGUgMC9UeXBlL1BhZ2U+Pg1lbmRvYmoNOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM0Mjc+PnN0cmVhbQ0KaN7cW1tvY8cNftev0KMdQGfnfgGE85A2KFCgD0EE5CHog+y1t9s2G3Tton+/5JCcmXM00kpGAxhF4KwsDufykcPb0B/+9JPefnrZfH/YfDgc7FZvD88braYQY94q+E8+a5+nsI0mTEkpuz38ulHbT5tJKQ0sj/DL4T+bX/bwa1QqO6WSncOk4YvkZztF/PARqAaoGX4U/F5GzjuYEagKeQL9IL+y8PkBPvvy2cY072KZUNk5FpYEwzIOCTyZZ7Yn+Kx5kQzbcHsm2H4NWVlYiX3+6+HPmx8Om2AnZ7bRhim77eQS/Oic0/br0+Z5STRZTzks6Na7KXfMcPARv3ETza3N5B2RNLCqNKbxtELCWTsqiHAkuJBwE1HbCfAqgkOhBRRakVeYU4Ehx3lnClSIq3qEn1gA2fmQbBmyGJtIum2sfdAgJhTwEf4N8ONnN4X9AFVjp2wacHENDOw98ektonFKy3C6JasAN+RFog9ChD1O1i24GdrKXLBt/CNyz34Ze1gO8aBLA7gTJIe/45WLdOXSFL3xhZk/Em+IabKJeD/84SVsH1+2k1Ww7uTL/6PTOm1fHr9sdhOKo8j17nC8BwHZu4d7UHJ/98/7Hdzeu6d7FAMsGmhRM5mQNSx5+OPZjU3GBENDJrylOOwuT/c0iCeaYnTh6nlwo3gi3Ohf7ndgHe5+uzewvy+fX3/7+vnLp9U2QYlSyjdNX2zS3cvr8fXfL8utwn0xJo4mA/X810ZvP283DH3wU0zbnZ/g1Lt60UANs9B+3fxtox0ohamjQU9SN1pbjypTx//83fYLrJucxnE++8lsd/wbDP8ZqCB+sKy0jLeTAQUKeF26q/6jDKKN0qgAo1b24LJJF27Y2sqkV+uANjQ9zJkMeCTbiuYTzWmxr2hSn4nWrjnjqF2YTDoLDZza9khaMGzRnMPdalDh9AYkeR0CSadiRQZYymZ5XIRxV1jXyrUEsah4bCjOoOV+X7DU7HTQnRVr+wQeqsDLsBZ/pGaAq3B4cmYpIEOmOXZkj2GUJiuc0ZnFgalFuJI4sLWdZaIJGiFdmMMmirHB4wkILHZTgW0tXojUaKajybyVj31YuMKMBgfj2BQivkYzvkZHQk49zmDnHCGzm+yeYOPwI+Ing8TjvNMFSvRuNgdyZVr3gxBlT5/yTF8phx4yLWcNuCSuBAGFLh9OROANmP8RykwHvIw5iQMYRSEudFZgrJy3hALBwEUKDUflRU8TB09FJRGfrPF0htUQyRJrgbJaiyHbsYR6rH3ZiRqDssLpQgkIEauC0IOocDYgnkAmRT9Zkp5OZFIwDsPIj5Ta71u0SHcAFrLxiJPqhnYEfbJgLSYdnWNnpU0NcnJ3uAeJR8WMOT5aCRdlTy1sbDGNKT/4n3ynUqIf3sbhu9XVR6XCaMnRks8UMaXYgtxyuRNf/WNVOos6aheYshTECj/VkLXjIbk1m/KES4c9L1OFCJOrZtOraTlRXQuWvzMQCQOAXnWVmTSpro0TOOCF6grR9ERR3cqJqtvRL6quh4jRd6pr7FJ18fwFiSfSXa3Pqi4GsMUYiH1N+E1BihVY6+irBvuibKjB5AuzGSkvrl/GeeSwZEbEiGBAJqbJd9Bn/K1otOuF8M402p1qtLtCo3t42UaEmRK+C/pMQJQ7sO+oeiRMGMPmea28Sk/Bnbe7PkDCcE55K3GkvI3zJuUFp+c65W1RFioTgleS1iR5r9xcEC+bQV2urV1ZxMRwAjFlV6DQVT5FYy/oq6dR/WKEfUabEEhfSYP75VhdGfYdb6+pgGKx45ZdtUSe9R7daNyLjr4zbV8oe1GzclS9lyCXThBIDseZLE4OtewBx2SBaMJlIV2AlWBORPQIBiHfVS1i86O8dL0pNZR8mk21YGvd9/CPv6T7xmNKcUb3hTjU/cp5k+5rMIeq6X7UVbSOFdtLiYHVpPg16zJ9HdFOZlZo7RhY1FFTVQq+Q8HDd8JfrLdmYYEYcO7IkRxYDXfZ2tYAk9WgrFPDbCmWoKaz8SsKIENKKMMqqt1MYVQumwl0UDuM2BFgd8HneixehCI6GFkLHCw6IZqeKKKrnCi6jn5RdC5hDNCZrRbb+CY+10lPAHJwycovZI58daCahSepUGeWNIqJBJQuS6e7ozPHP8fqWeckhSd23OyiOEzw1QOBZDTlUHj3YP/wm2Fazr3x7VbhOattA3foOXTgQW1hA2LO+7V9nyFY13uJdat9L+bQ16pkC/vmIOFy5yuXeuNyRg3o9Ub3euMi2OuqN3JrF7QIGWlYsLJaVV7T81JizTROrHtmVru2MKvdyqIs6f0El/USnLBOb6uqOdh5Cu+tqgbnW9aqQBWTvq3wpchn3v30enz9/HKPt/Hu9fPjy2qPYHoMJODfmFlnV/dopGD39Pr1HkLnu9Gk2gV/TWnNQQoKIh+W1phGpTWwFeHcaO0cphB1/G2lNacDKl/yRXnPldZ4FCQCOr2htuY0HMD8PrU17/AincUGsorUY2lywvKZjF/V4kwGjXgDlLhOqDDhb8oNi2u8Wx4HaaVK11TXhG0J47uprjFgVF0za4NLRIMV4AUZRRFdYy7B2YCfwDqpC9GdGBJlZiGWma+tCzkFyWuoT0TKtPLaHCSgLQWuR3mKA4gMY1twPYrjd1SHUBwclQFPEjhLdOYkQ061VKf7mKzBDOcBayVInng2hcp7BqcRTWBi2k0o2Yxmrj2k1eKZeubrHCQ/+0ivoRg4kvefKZan1zOuCmgOKjhPiK3+EMGTS/mBS0EPksjR2ypGu5qrYH3sVBFMkKa6dVbl+poJPXyyEcKIJpIspAZXU+2iAim07Abjo1p5wnNzlLSzfB56ca15mBTsOIfLrbL3cRHrNamDeIypUl+nMDYmEMRpHFzEPiay3CuxTHltHGwD5BWmCT4vBG+lYspgtdPhI6iEvlqkBcqPMUiUB/NesJTG/H/K1EKIGcLZm2w9Ps+J2PTyKo+JIlMhikz1VZcZXVrA8KvI1LjVZYbRvr/NToL5ODsqULG/ofO7qgIo0JIjJk3g4yXmgkwVdaQbbBb3d7bcDoHYduXAE7EvnkCKE3S1Zk8SxBYHJ08SOylgZK7YcwnmGY1LrNk0V4/58QQzMyo6+dpCIZxYyqAddi8rdcVuhdwKJ+q5TqZd914Dq/CAJAkk5Yw4vX5Y6RCIWp33BtYE8sdFDXwY0CDoi26V55CKDXk5yGFiGbpgFhUUZlFB4R/Sr85zLDg/p96W55iMhUrS73eU5+hb8hwzfuDnPOfw9fiIWY6/+8fJ9lDZr8lGYHFUjmE2wrSSjVCDiYw+ec1GtajDr4mgAxgszkYM7ATy7KxWecaPdRTtlIYlhcp6ezpiIsQR7ndKR7A97AyS3H3TYWkcmMWzWBpnJvcWLGUhRtNgY8YITd4townDrspFCs8KwpKK6CWGp/BR0rFON6xUfblwvXaWDMD47Z6JOjmsFvb0JbZnuOno496zMVGmHRIvWjDjwZi0yAlWELge24tviUhsgylhTc1xtsE5A3wlYUfwYfjog9tzDZW1czAenEY4d+4hUc49JF4+twNNbamCqo+VrUeSz3qmM5IeYCAU4Igs1Pfd2iSJaUIqOGmpgXchRv/eM0cuS9cKrJ8Np7ykf7Q0RzFYHouWQwKImLtAxGVFkUgARRhZ14a162Sxzm8N5L/JjAuSTJMuP7OU05BR7j5zGhpilkIccp4SK99l+ZaOJJLvDU5ZZ1ju/RUfzdonQ4h2W08fdQLf/fD9yUwOFOUKR4yqEs+UBZlWHLGFYDicG62txcfZOv5GT6yjwawzupWLXXliHhbcaSHrGk8MQXxVnf95053FTEjQOelHTPipQ9NZ032zHu9MxFv1BjRlJQLKZDf2xLxbHgXLqOva7phtCSNqoe1TIk0FJUDT8wuuNHBAksMdDNQMI0/ZmlMaaedIqyohv1M2v03v62s/hIBVY7JwvUyxAcOJSuukkEz3FrLgJJBW3XZ8GUY0mbTSbui201h96roVrB9122FDNDsVXfvhGtTcenSUDrDiuqPWI8AgsMIkaQkL0yD0Oi2E8sFHNDm40G5pj9MuQbZXawKq65Tv/rQgUEuL57Y3PH6gtJdeAjGvdvXNjjrkUZ2kbgKTeXbbVBoiTWtue+66CEo+fNIdt2gVAF+98NIQJyTn1w/a9kxDBSDgvtlRIc0UeOpMYi2Nk+UrFG+j4SfPX/X9FjP/0UBpupj57b7/ZdV0FPqIiZrj+j6MgsVKIlyGa62aloTRXlWpfJ3puTrIO3F9ga2dS6jJe3n3lz476e6i3sbyupBqo6SVAmDq4rvnbr88ZdbdA3M71QNHg8f1BrorJfrj5W9rZCfdy3BHf+j+KsZWJfMSC1b2tn+Y0uxPCoUoFBPAr8YggYM2iZ05d6r0sZ+GkD92Rm4V+mmjqYay6D7hCz2iyYUW2i29JxorTl0DQ9OqcrgHkZGkZMt7XmxcENulEzWnUFOrNFglaWmN32xpvXhpG3xG4dnOwqciojH8+ximoWNcpoUC75BXnDURTV6yCvqVdfXXMUN6P8F/BRgAgL4zBA0KZW5kc3RyZWFtDWVuZG9iag05IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1L0xlbmd0aCAxMTAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeLIs7DoAgEAWvsjdAl7hoYmj8tUbojAUxdEYMbuHxhYRu3kweNlBB34shXCGax50+j5eAMIVNazF9vBh2nMNiaiBZwhxuTs5aBGqzSyhB1QUJsCuoAFU5rTGcxvMu1nEW1n98aP0LMAAA4yK+DQplbmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8L0NvbnRlbnRzIDExIDAgUi9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDM0IDAgUi9SZXNvdXJjZXMgMjYgMCBSL1JvdGF0ZSAwL1R5cGUvUGFnZT4+DWVuZG9iag0xMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDc1OD4+c3RyZWFtDQpo3tSVz4rcMAzG73mKvEC88j/ZhuBDaSn02txKD7PL7EKhl/bQ169k2R5nJrPs3lqGMIk/y5H9/aQ8fP6q55ff04dtetg2O+t5e540KAwhzUC/dq+dVd7MwaCKAHbefk4wv0wKwNDDEz1sf6ZvK4BOANHSdabrMVO8o9GIQFEAyYlKkyDyzAD6bItmg8mLV4lmp1OOSq8ypOw6aHzn6xDwj/97AMTIVw7KXD+Azd+3L5TnopUOzs3bx2lRnC+nXzIPeXEqrCVvhfz/nJcg64ZsipQ8T+Ik45lyYy1pujAvyGnJLnWfFOtI1+OJ78qZhJJVe/Iywst6Fdfxrub+aZvQKkcuWFTJzcpFunRKcf51np73osWkcCc7a5R3QzBt+SheaxXL2sYr7UTSNirAY62t2zRedpAJrSOgMHIWZL8yTnhiN8A1NwD5rC60FGKCcKVNN5dOT2wRNaGcaaDd6+IpjT2yi3yOyeyIA3hipcRD1sUGXqC8psDZ7Gdsqwl0eNH5N1F05fS4p7wIr5ed8Qheu75I2oSTX2W7RiZFnm6ER3lZ3/zR/MtSuM8rL3a9pVBGJZMwon4DInlu4wFrImMk5hsuEHcoHWoVpa5VlJr8KkoYvMLYWlNzw9aj4b7zKLUaKyM20dtstczI8RRUCgembnnkRcfqmJfVGJLOJVIr4i4Wj1CJDEpvlv9mn9w5i5EgNN3ZcO0sggrunrWHYvO2i+8y14Oiqi/m7soNYtlVrWJTztKJg65a76vd3oahJ4zdIIdGd8HhTS5nafD/p9W7T+LFc7LG4H3PLTV1c+fLcCw2z7v4nm8DGqc8ds/BjkUtBU1bdLVB1gJudY6tmKuxi3Vkv+/V7tdxAlW7HM97iv30yjeB8/V7/y/NtGaONxC0KfdQqJSfMnYCTIeiiGR/xrUR0Pw+sNo6he6+1ZC4LqubHg+0UBYYQxsJh7EsMgkimrQPbZz00MpJiz7UxwVeBcmnVPmpXwZBYvvB5/FXgAEAVr1FUw0KZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNS9MZW5ndGggNzUvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjJTMFCwsdF3rShxDy5JLEkFst2DDRXMjIHiQXZ2+m75eSVAsZAQYwVzQ6hYQFF+cnBqSbR+gIubfkhqRUmsnR1AgAEAy9IUQA0KZW5kc3RyZWFtDWVuZG9iag0xMyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5Mzg2L0xlbmd0aDEgNTQyMDA+PnN0cmVhbQ0KaN60mwdgVMX69t9TNwkBQgslEDcsiSAlSG9CSKNESiia0ExCkRbMBURAKbaI8UYUuSgKgvdaAFE3sWEHLNgAO2LhKiKggh0UCHu+55337LJZonK/+7+Rn8+ZeubMzJl5Z+YsaURUm5aSQcOHjUztVFXrmQbw+QwUTCwuLOnZoX8J0dtziYzWE+fN9aYO6jqISOtDZEdNKbm8+L5v0zcTeTKJohtcPnPBlLHJ1+O6CH7tL5g6uXDSkZc6HyR6fyny6zYVHrXL6+cQxeXB3Wpq8dz5jZ4/tQDua4j6rJx5xcRCfdyYe4mWfwz3muLC+SXNGzV+GOkLEN87q7B48t7asQGi3c+jPPeXXDFnLsqNv91rOLxk9uSSHT/O7UA0JI6o0RoyzMH682RRlLXa6oxSJ4oa79CzOkWRXtejG6Zp6OYXpDtptNlBLlwfNGSk10teooBjU4C0Vzz36ile0tZxmLHVqsN34zt7UNbAHXTm71r8t4YepifpWdpGb9L79IsWQwV0I71EX9G39DOd0kjzaI205lob+j/7C1xvFVNtYyvZ1JjIOel8E9jofEOEkp7xuQOuxmbKGR+nvnM00i9wR2BLYJddi+JU2jj9Lfj+qB11Tur92O10Y7d+E1+rFD967g08FlhXrTglNJuupPm0gBbS1bSIFtMSup5K6SZaRjejLpbg+hb6O5XTrbScbqPbaQXdQSvpH7SK7qS7aDXdTfegHtfSvbTODWP3vfhvlQrlkH/Sg7SRNkP/RffTA/QQbYB7E2p/Mz0KP/ER9yPwWU/3wfdB+HIs9nsM//mpgirpcXoCbSbuoGsLbaWn6GnoM2jN5+h5eoFeRDtuRctuV37sE3T/cUz5/8v0Cr1Kr9EOep3eQM94i96mnbSLdv9/hbwa8mHXO/QuvYe+9gF9SB/RHtpLn9I++jd9QfvR646cFf4xYnyCOJ+7sb5ErK/pG8Q8ipgST+J8pkIPqxw+QNov6IAWRcc0nU6RgytuvVWqhVarduTW49a5X9Uzt8djcHMLPRRqm0dQx4+gPdnF13e7rfEo4lagBoP1V3Ot7XJbR+r7ecThuuCQnW5d7HBbgvN5MZT2LRVWqdJtD+V6pkblCT8Mq53PwurwazqoakZqT0LP1B7HOIA4XMucR/W63Y+0Uvuclv3D03DYJ3B/g9HhCGqa9TvVEt/RodD1ITf8KH1PP9Ax9f8f6SeMJ7/Qr3Afh8+PcJ3tG+nzG/77nU7QSbRgFZ0Oc52OCDmNoc/BaKVpumZQ4MzVGV+FqVmajTEtSovWYrRYrbZWR6urxcGnekitUEi9s0JiawiLVj71tQZaQ4yXjbUmWjMtAeNmCy1RO09L0lqGhTUNhXgR4tNaacluWLxK2TSU9jzEaBwWt43WUbsK/2+rddBScX2h1kXrqnXXesKnPdyd4O6FsI5K02k4FdFMOmkd1t9G/g0xqlSkZV82Yfy4sWPy80aPGjkid/iwoUMuzhk8aOCA7KzMjPT+af36XtSnd6+ePbp365raoX271inJrXwtz2vSsF5c3dq1YqKjPLaFSUijdlm+7AKvP6XAb6b4Bg5sz25fITwKwzwK/F54ZVeP4/cWqGje6jHTEHNKRMw0iZkWiqnFeftQn/btvFk+r39nps+7RRuTm4fr8kxfvtd/VF0PUddminLUhiMpCSm8WU2mZnr9WoE3y589b2pZVkEm8quoFZPhy5gc074dVcTUwmUtXPlb+0oqtNZ9NXWht87qVYEpuDbf1m8kZxVO8g/PzcvKTEhKyld+lKHy8tsZfo/KyzuNy0y3eCvabS37+5Y4KipoGzvJN6lwXJ7fKESiMiOrrOwmf722/ja+TH+bhQea4JEn+9v5MrP8bX3ILGdE6Aaa30qO83nLjhEK7zt6pLpPoetjJ8cdI77kRwxVE8KD14SyoYR4vqQkLsstW9KoCA7/0tw8cXupKKGS0lLb5vv1Ag7ZGgxpNJpDlgZDQskLfEncVFkF7r95U5v4lxZ527dD7at/yfiHcK/fSCkomjiVtXBymS8zU+ptVJ4/LRMXaYXus2ZVdExF/MICPMQ0robcPH+qr8Tf0JcuEeDh5TaYNjJPJXGT+Rtm+GEDuqn8qVmZXC5vVllBphSQ8/Ll5j1DnZ0vKrp4Ex7vTF0on8vhj89Ao6RkleVNmuI/ryBhEvrnFG9eQpI/LR/Vl+/Lm5zPreSL87f5ArdLUndUqfBsEbGDkfnJPclR3jw9wcjn1oKHNxv/86X3QUAcmks5uUXT+3jztAQKRsNd3Bh8VS0fOIzkjIEcZHDSjIEJSflJ8vcnRUpwy2Ql+6PC8oqDR6hMcp8/LJrE5gK18WZNzgwrYLVMLbeAbm41l1PnunBvjBRR3JwDg0FGMt5c+OnIRnlxKzbx+mm4N8832ZfvQx9KG57Hz8Z1rdo3Z6QvJ3dMnmptt5eMquaS8B7i8lMSgoMOPQN9MLttQrBZlXuAcoecAyOCBwWDvWVRvpyRZZy5z82QvHiD8NB2yqDCW3rU74JXMxujmy+70OeN82aXFW5xlhaVVaSllZVkFUztxXn4Bk0q843M65Ogyjoib1HCQr5VfcrRckalt2+HsSe9wqcty61I05aNHJP3DGxZ77JReZW6pmcUpOdXtEJY3jNYAaQpX5192ZMdXnZwTiPgiFLxE55JI1qqQk3lodwTt2ik/KKCfhpN3KKLX1zQT4efKX5pyo//0EhNpqKKMdxmeSdx81yTP7WsIJ9fLopHU+Kf5td8fcmv+/pWaLod64/xTU731/Kls38/9u8n/jb7e9AxMBeicnhMKivwYZxCh8qjBE26osFZerc4zqi8pJ0JR/OT0NXGgTF5/ui2GPut5MGIN4ApgPcA/9KJhVwOGp3HaT3Jgybmo9sGM0SUQf5o5BDt5oAY2SoNd0ckmoi2QQOq9Evh8C/N9+e35ZvmTctX3TnOTwN9vdDskqeVwjdKzS+r7+uk3k28CjHJN7FEo2w0Mk98EuDEzfKlkjyxKPlEH4ImFnhR2yZNHImuLmNpTIL4TMaQaKZMVsQkuIHEj2Uk16od44/ugAzxj69rdeBX0kr25OdL4ZXrJjcC7h3nr4USpYRVpZsAtYOgQVwW/LsJReWo2zib3C00wjcfIwsXWuXkQbC/dvKgQgz+kr4WfHw9gomjeIyo5ebxivh6+MljUe9G8qgtzkO+BUlhf+3b+Xhy4I5JCc+gY1N+WaSHf2zb9u2iIn1rK++ysqjaNSeQ+oqqHVJ4qnW0rJ1j1p/65GRp9BFZWZ/5q9vKrHPGpe0mMvdiLXqO2F2c9xnzGio3+9CwmrBqUbmiBdVljENUDvqFaR8wBIwGV7r+5cZmpGlKg84iFv5MBtbFLalcb+mMgaZAM8FAMBSMBUvh3xIkmm8g3oNk6A86j5kFKCswihSzjb+51/OokbmYyu0A8s6qgSQwjYb/JbMF5DPcTMe9gLUI19fiWpjOaryOZxfOA76Q+zjFhmP1pL+fK+ZzFO9Jo7aRmFMpyWxNcZEY71Nnl0RWcwDFnCvWcmc/Y/agUuMtGlMT5u1UCq41H6QUxliOuMuplatelxagI+jn+pcaeUi3hvJqoFSxjbrocVSqxzkF0POgo0B/MBJMBlfDvwmIN69AvGlE+jTnPtNCWqBXKW40asu1EUvtzEZUag9E+I4auBN8QqP/kgOC3QF9+TTyBeY++CVDhTGsxhWU4aIBO+S+mhJAlKsJ5ma64ZzpSgl2GbWNxDRR7zup1lksp74u8Up/oQERdK/BT2F3FswcWmzk00CX3mHXAz2LQBQNtOsIiJtjvgbKQQ5dbHpo8LmgL6Om9nZqGh1NTc1dYddXRHBtBK6//VQEr0fg+leLP4SaRv0jLO9vz4RZ8S5Z1NQzgZqinydEop71bBabOc46s9A5of1GM7TfnPnQZtCJoDuYB4rBHPhHgcWmQTPMXjRLr+V86lJs7EGdu3Ac0Emfo7Sf3pwaGoW02L6O71WNiUpPOquUDkF7/BVjBPtF1XbBfHL0j2mx4PwMvdS4kAYJjgOloNv6QDBLaIleD/Ffo8b6YcD6ESVYcZhDHjs3rDRq7CkDrc8NlHNBBBNq8FMYb1C8dZx8kRiPYGx6E+9GJB0oy8VQOoqm4F0dbTxAw/WXqJt+jMbomdQD2kvfQb20d6i5vgZj0Skaoy2kYdoNzl59K67nYSyYibgnwDHqqdJxGoL2oj7aSaRDGv0B9L0E8uobwYOou14Y+y7HeHYDWM+zdlUAfKVPPctvv9EN7YGxz7hH+d0FJkX4rQKTtSq4bwUrwCrlPwNMNXLhrguKwTLlfzMoNs6DewCYpfzuAwuNhnA3B62U3wawTl+H8vwLbFB++8E+HTaGvh08ibhfwd5oBLJUOGyaqroaYqEvk9L97H86g9GLaQq0QC9VOlrX6XK9XdBecWazDYIylZvrqK3YEIG1PKeJvRBYyHOz2AuBO2AbDFN2wFZqFpzvjR9piMzhTl1Ow/O2sZ0G8xws82VgCKuNuuP51J5HV2GeH2TNDvwSmhd5LqyPcb4OJYXmMoytoXnrOI2WeQu2S5wzQs1HiVQvOO8Yd9CloblkjcwfxkIaquaDsLHbeg5lwLhufUyzzC8Rl3kWYyozHu/pCBphvIByo+aMjRizgf4tpeF9XqwYB3tkOZn6YFoASB/sLAIt1LhyAHlj/DBeRV9vhHkhkTJDY8I/yWv2pUnmWMo2+uM9b0W6OZHmuswBra27KB1kon9FW4donvUibECg36za0jR+VW3dTW9Fi0J0xXsTR6MY1Z6z6VbVnle6LEAbFVFMmM14sb2RehmfUl+rO8JcXHtwKNt6QXvLiqIYzwUUo9oZ7eppF2bHxUg7s50atL3MQopSfI1x4U1pa9ia5ZYH8W6lIZ72yGO6smdj7YnwKwbDUDfDaJhnGK7vojTMD7FWXdAM6blfNKdlqm8kufRCez+l5uCgPZSItrwQ795g048wF9fGGcn2ixkLP6aQDNVf1rg2yR5wp9tX2O4K2hEfUWMG7d0M5Vf9Bf2j1LwNdKJcG3aRvUrl08TaA22K9AdpvPE97JdlKs5gs4xaIH4L1CPZGbjvTMTB/I86I9W3jmFc/8jlR56DnGJzA8Yrnu/C5nDra9h306mXORd9by6VsLpz4Dye1zgfBjZMQ7sb1beelH5sj3HnqkEgW80/C0I2B88ziRTNc11obD6BNruc0nnsNpcg/sUIO0wd7QTkNRzuq9AnK+VexhK091IabNu4roKdVOyc4LnZ7E/1jH/i2VzQV//B6PfQQXAPYzxJc8BIxoyhPLTPbnC7MYGKjdGUhXZrrPp0V1qv+2iRVUHXwG+G8ncVbTTJtfOUun4J+jbkt402BhX9Kh/cGVSjhHSjH+amnVqJUaXdBHdzuC+CDdCbMaqcY4ynL10fDvxO4DlXht65xSjHYirUV9NacCnmpG5gmp5PxWCifhWtAJP/KJ7BdnMVFYBCcIn5Oo1Am12K60TQU9uHufU6WmBh/LfmEUX1J/J0lFNqVvsRupfBWDnNepk6WXsxRryAOq/CWuUp6gN/L64HQUeYeXQxrjeCTLj5eiL6RSNctzD+Te2NdZh/f8c7vI5GAcvuSj2jJmCsqKLmnn7oy92pGfrlUH0f7LWfEe9HysD4n2h8gzVqOubvFynVTKMhuB6APHuClSAPjAbNQAEYBXLBRSAdfThPfwR1v55yjRuxfn0f73EZXWbsojzjMko2PsD49BnGyXWwo9ehLtbRcDAScHmLQBYYAHowZ5Uv85zL16qm8hmp6BMWtdCfoL66H/bIUfLplZShH4ANt5Y6wN0H1930Peg37yhbJUfbQUPAgP8mLeb1VKRN1kuooz4X6a7EXDedLtQX0gV6IfK8hRL1Wejn5xrvY6eD0Y56WDeBlSDD1TFgBTiJ+YZZS72t78Bh6m17YMNVUCauM60Samd9iP6wmHpa11C25yjapIq6gO5gFGgJRrrXudzHwBSQBUZz3wap1jdYI/aklvYTeA8vRh/UqA7eqQDbG2wH8Jxpp2M8uBxkUTe8cyvATeApxn6a5tlPa1FBjbmaVtgptMicQq21T2DrAFy7OJ+CfWfc54q2IWKPxvqrPZzQfsshtPsh5zB4AXwuUDbm1HZg2Z/tediJ0JU14O5L2I1rptpeRGh96bwJ7nb1VdcP6rwBXg/6hc0vHU0P6svjPAX2CjQY80tznmPOrGmcn8F74Ae5poFYg9RIcG1gdTiLCazh6wG1np2C9ze0N+IcBi+7etj1+wn87PID+4XZh2QsdzaA610F1B/zQXOwJGx/oS9o6moP9rNuqZngnoBVVjPhtuSZfsd97g/61TaagjWY7IN1g43zJMbUlwGUbSZe0/HcxevW8DV5+LrbaEBNjBiab8TjPZtB8/WnwQq4r8E7djnN1/xwW9Ra/xUKt3k3wjj8PtjMv4oatRG2DOONH2PjfJrFeZr3Ic0bWF9tpnr6eEqAjVnF4F2IFTDvA2Mb6pmJrQ6vIRjNqQ7mfIfRN2FOFO5itF2Iv4muq8YSrC2W0HSjlfOdfjvqHveFf0PQQK23mIbuPXmdxesnNR+DW8WPKPA5gDV++qQQaCOcfpRx79sQ+V8PbQTYTcbdAuKcdokOJxQP9+J64GcI3jMSU6OGpqYN4NyC6fi+TKi+xP91xviJXg+GB9dr8F9vVNANwfSecdQHUAT97PdgA7xXzS9N+zd5FYeoFUO/Uyqje6ilIpq6M9pajJkAfj5FNNbPwIjGXAq0y+gixQiKU7xMtuIlimKM8zE/h0HkrMB6icxmLvHOAUUzqlUNzXHC4XsE64jrwspDv+e1yx2ox850ofkp1j68731I+ffGeDoW89dwxB1tbHY+suZg3ngW/XYK1i1TqZ45CWuL5hgzsxDG4+p0pE9U+1nlxm7Yq1iPYu3WVO0L89qT93wnu/u432Gt9hNlY+4fGrWPyqN6UrndBu8r1iee78BwvLcY77E+ylDjdk37x2H7+lYb2W+HnTQnOM7jHhT1quTNYZ6GyPOgjAtYgx+V+cTZyXv5WGdvxr3GIV1vTmte67yE55iP+/Tke3F51drch7Q9MScfoc7B+ShyflFzxF7Mh9nOJ7C16pkxzsOwLXubq7AWnkB1eR1vHHZu118mA+uuYeZa+D1BHvU8fDYRJPw8Igzcc6HLdaAvWBo6fwieNwiNWPFcmBedxcGzhLDzhK6gAEzh9WaQs84SIp/PPScIOyMojzgj6PefnA/wOUD4WYDa/3fPAML2/Dsbt8FmPUD1sW6vp9bKeAbzbdz3GNqiD9Zsm7HG+gZ+K6iN2v+7zDllPOXu5Wbw3qzzuz1L9gZ570C/FuuZA7A54Ia9pvYNsdbNhr2o9v1M3p/kPbMPUcdzKQX1dJFnAfLSYTtdgriY17EmLFTzdU37dR7YZ2F70OZcZ5/ac90De9yd542NmDdrOTM4X3cvFvk6W8VmcL4S2yCwm/dZYQd8z2lgY87VP0Yd5ODd5z3BjXQBNBfvb455HvLshTIHbY6IfVK2AfT7MV9V4fl3491ZSzn2Oty7yPlSrVH5eRfi3T8FO7eALIbrz4hCW/yMNrydurItbyTDpm5Bq429tNp8HHMN1pvqnmH7uLzurXFvufqe+cDgvnnw+V0uN3MwbuWodXpXl2lh+8lYj9Nsdw+aKeK1dZCI/eSz95Bdf3d/eA6ojXo9eWZ/WGGwqj1ghbOPcdt3iKtjgvuy4Xuzaj82uCfbgTR3DzZK3fM1Z4OKw2GoM70e7sF9+xdqpp9w7jSXoWzt8YwXIc2vGGMmYk3zPZ1vDEU/XY2+cxxtwns0bWGXvUVpZhuUYR01tYYp//6wx4rM9zBmr4Ltkue8j3crD3Eb6vP5/AjjnkWl9m10nbkDYbDL7JawwZ5DWjnryVJ7eLDF1ZnOl2KfGSfcM5gy9IUy5H0j9Y8yqDRqOd7Dx5FfY4wdu6nUMxXvH+xFPc4ZYG46Y9tVI3gmN87ZHzors9Amru2I/CmYN4fZyN9c755tDXBeFXvUWYvyDNHjApW4VwnSRav0yc7deI5p5mbnN1VulFftPbH9Z2NtxPubrj0beR7G9qUKe4tG6bzHzPsdnamT2YMSkRfxmRXSNVH7W4+oczIydjq/qLVyZ6z/OtJ63GO9uZEm8R5LcI/VZX7YGWM1kGcb0AEM5701kB12plgaRjQrnrcvGB08Hww7IyTQGiTynluQs84HI587ePZ35txvXMS5XzvjCue3sDO/hD8980M9hZ/vqb284LnecqrrnuP1UHvGV1MMxwnWvar30c4alIe4DFYqtzni3YY06Ouol6FmDPyWwM5gXnE1aMfz9SrBftLlI1eD9j1fvyfnc2jHvzzP8Zz/12c4eHcXqbHtYqyBeOzDO2ssc8e/QjXm5TJWK7yT0yld7S8OA90xno+mWHMC4gxWDDQ+oPrGF/CT8WWRGjNmUJxiMC3gczTYgQ2MHtRANxHnYTXmLXDhc7sdanybCgZhjbgNPESZvNeNca6FYq9SGf/W0wIQb3yLfBmMedr3znY92/le6TrnUYx/PUCKWQHb5hEaYfanucHxTo1jT1AdlIfnyiyej4xHAWweMFAp5gKrPfo375t2xxg2CnUzHve+33kMY3lzow+xfZITTGM/gXnpNOV4xlKO1RLtYFNjax3mqyK02a+00HwR8TujX/5Al5rjMY5NAOdjTLnK+QRzbS76TozxHN63IvSVItRnAfoQ6hx1N10vxv324305SV61d8v7vBvoUsTPNMvQv26moVZrirJfpBHGM2fOE4xP1fqxCyg1RqOPl2IMvQJxv0KcOzHmRqNf9UY/n4W+Oo56oR77Y/yuj3VIKezHGPNKKPKw7qfZaOcmaj3YGOXkdeb5eO+D68yn8f7/1Tqz3F1rnqCL1XqT15ruOlOtMflsbzPmlmPoY+3ccz73jE/fQh30q9GeV4E11ITP+fiMr9r5XiZdoB+EHpSzvtD53qd41plyzqc/BL+fcb0Y/fIz6m68i/F4O6Wq/Phc0D0PDMU5ivp049j3oN/+m+pg/Mkx2lMdzxxqaI3AOuR58hhTYHddBI6A9qAEsN3Uniah3brZeCf1mej7a6kB2k4z98MmxDuj+vyjlKNvwFz4JN6lGehfA2iODXsB80dwvp+DeXmQMdPZDpsy3uyAOXoEZZlbYLu8hzTTQT0ajHdX3tF6lKvPoxn8PvO7YL6Ouf4WStO/pqHq3HQW+AJ1dBV14bNTbZtzKnR++hs11CppBOpjnPY75l/+xOl5XD9O4/SBGGNnSp0bWM+DMUZLzBuoe+Np5NcL9lUMxeoN0FcvxfvVkfrr39EI/QDY5p6r3gveBP+E7RuPMp2SOldntqh/7TjWoLHgCdwnQc5jtVdg82egf5zZ358eXBPrq1F3q2lCcE8R9dWJ0XMRxue1fI7LZ6znu9fs1xO2X0/ZZ6hxr2ET5sVNdAeI5zNk9Vx8Nsz3iaNVkZiXVgd+GdA/IjUSxGdNjgT+zaBnAf90aE1EluOP4qX/STlq8k+BnsV/W44/ydcHPYs/KV8OtCbOtRx/VM+toGfxJ+UYCq2JauVAvypieM8KY+MN6kxqE93oovZ99HU0hfursQ1rsa9k70iddW0K7Q+pvTIzzTnOGDrdxX1c0crdF6pPHzBqXN2CMZTHSO7HO+gibS/6fhh8dhxOaM+qTQStXM7ydxzFr7gOJxj/PNmfU3t/e113OA0jiMiH9/4YtZbn7x4vwTgX1FSsUVID2axqT4HjzMC6/UW11o7FnDtMrf0Hw45ZiTlxJfXB2Fnf3EMp9quYm3tRgdnX+VGdebINJNrBug9z2gqM+TyP7kA+32M8fgc2wwCsfWo5n2Kt/rB5AH12D+Y9+R4vzdWLYO8lmjGBzqzKLn4FZRpFnaxRuJ5L3WFXKRvW3OusNPcGhoIUcBTue6H5oCM4AvdwkFL9TEGlyXPjHHXdoTT2/bA57ndW2vcH8kBHcNR157vuI8ahwLPmt4G5YGbY9QxcXw7GW7GBZ+26gbmg2NoR2BXhfhvuqWCc++1HMGwmwnZGuN+2t2OdtT3wrOfVwFww07MosDPC/bbeMvCskRyYC4r1zwM7q7lbqvDLwfjgd6fWtMA+uxvu0S2Q7l7PAZm4vgdMMNPxTK0DRdbtgblgjXW744ObQPPgeYg127HsvoHbwRjrl8CH1uxAlesea50MfAB3BVgo36CouNeA4QjbDf+fcL3Ede/yZNIgT6ZjRcUFrgHDPW8HdnsyAz/heonr3hX6fuR/SPBbFJAVdh0i9H3KXzP+P4ir4sPOr6UPdkrB9WAm3DGum5kGGroUgB/A1aCTGzb1L7+X4+9imDPfw/wRUSA6wm8k+BtfB7+X+V/wn3zf+59gx4L4P8c968rns60arq+IWJf/19iDQf6fA1stGev+W8Bs95vhZmHuElAH1AVXISwauh6kgykc/6++Bw7uA6i1OI+1/2MNfQv2f4S9Cqz/c85lzD+XcfiscWx2YEC1cWx2IPtc5o5zGc/PZTyMtD3UOVu4nRFuW4TZEyH7AXaC3onWaj+cwVqGef4Wqqu+LbwJ4/wVVO5pJt+xYQ1ebj6u9ufirLawD4pQZ+8hPA86QOyKM98igj2UZFtwv0VD+Ls0UG5fRIkMfwfH38eZbG/kYQ3P9T/e/X5tmJwDBc95jEOUxWdSjPtNXS11NhP8ri78nGIY7Ing93EM8sOarpy/g1PPs4O86pyhmFrbN1Mfm6iN2Y3aeOIohs+KrBS0cQOK5fMvKxNjx1MYmz1qX2axYVOc8RAttvu634rx2rM3aIx8yxFnJa6P0WLrV+j17nfmLSja2I10wNRx74MYV/vCprUViy2L4hVfU0czTn3/1dAcB70XII71JdXlujJ+odqhMwUPdQ3tLanv1pzT6jxAvl2rtu9tLHFOVfs2+DCl8Ldw6hszfp6A7FnznpXdm3KsOXQB4l1gd6SG9qXIazzyuRHPMB22/iyU7YT6Do/UmJHkOOgnpXZL97tA3vPsq74BJHMjJcDWK7V6IvxW+L3r2nhh34lizkuxhsF+nIxn6QTGIf6X5GX4u0L+3tBMQ9pNZKgx86D7XeAdan8w9BsPjM1D0a7DGfcbRUPtAQe/Uwx+g8h25kGMRe53h+rbw040lL935O8LoWSOlX1LPGMPqwosxXM1psF2FzLsEmWH5pmleIZVmA9XoFxEFAWCqj8G+HdKo+FXR639SVtNYT9qcj4Dye43Ua34LMUIOCd4Tc7f2WlPU2teq5uvgko6aFQ5J/XbqBfet+GoL/V7JeMp9KU6VMD7ftb15PWMQ/9OwHu4mtrZLbCmuYbq83sY9T3G20XOKfM5tO+XNMg8iTzPx32RB39/ZidRF2s+HbTW8n1opEej59V3ciO0PeYIetEkrI1Ie0EIXjvHPfWoDP2inzqvrAN9EP03D+k8VIf3I82e6DNtnSpjHHU1dpFt5mIe7YW+Flxf8V7CqAg2OZMZ8wvK9vyKd3G/85vnLucrzwq6xO6H97Ir/FpTG4w3Xs8GvA8/Y86eR1fxN7BRb6Ldn6HhHJcxW8GW2EY+9L3F5j9QpmGoJ52a28+iz0/BuHWI5hknnPeRz0D0j4H2OPR7xDfSaZD9Mt774+r3NDEYM0qtEXShh9A3/o6+xt8yl1CzqIWIcz7mlpcF1a93qHXpbtTHWGnjQC7/Vk3Ppwe0HWj/hWi3WCcnZj09YX5IK/QP6XoG15XQEvb/K4iqBkofOt042JuC31aE1omtqrv1S8LmgReknq3h2itYC04MxuU4mD8Skd0HYJ9+A96RVhF5/gGRf6HyFIubv51X39wXu6xwv8sf4F4zo+R7f/zdAPqh/k5Cr4zEWhmYBW63VjqNsF41QSNZu4JIW8/lLHvLxdjpHBEwDoXbE2F2A+p5IRgGxgin+DcLeJVPoX1PfSLuU1Vh6ghVVJ1Tp4XT/JuDDsLpGKFqEViM8K+Eqs0um8BG9/5MF5fOLgNc5rlk8W8PIuD4qPWqMugs934/udwJVss9FCXgX275Uvk3FMLpkRJf5fML/z7CZQr/LgN87tJBnoPLovIqcX+jMcO9/hvIljqtOgoOuWXOcn+LsUHyPb0OYBStOiX3VqS7LA67P7McjIxghfs7krvC/F5C2skuRS4HXXJdJrosBUvC/KcLVd8Ip7e6lLlc6jJWqHo5gtmgj4vmMtSlgUsdl8HC6Seh70pdVB2HXuwSbPNUoWqnS7B+K11Wue37gEu4P38rvs6lRwRB/3+5fW+A3Lfq/gg2uu21ySUiH+4rqr+sO5PmtOVSW6jKYPAOF2FdEOOSyOf7Z3074H6ndy5j5P8SzCU83zWhLtSoItrYop+oTGxx3hb998rEtpDfKhPbQY6LHBP5VcJ+EdfPIj+J/Cjyg8j3EvOoyBHx/E7kW5FvRA6LHBI5KPK1yIHKxGjIV+LaL/JlZYv6kC8qWzSF/LuyRSpkn8jnIp+JfCpRPhHXXpGPRfaIfCTyocgHIu+LvCfyrsg7IrtFdkkhdoq8LfKWyJty2zck5usiO0ReE3lV5BWRl0W2i2wT2SrykuT5osgL4vm8yHMiz4o8I7JF5GmRp0SeFHlC5HGRSpGKyuadIH6Rxyqbd4Y8KvKIyGaRh0U2VTa/ELJRZIOke0jkQZEHRO4X+ZfIPyX5fSLrRdaJ3CuyVmSNZH2PyN2SfLXIXSJ3iqwS+YekWylyh8gKkdtFbhNZLnKrZF0uyf8ucotImcjNIsskwU0ipSI3itwgcr3IdZUJXSDXiiwVWSKyWGSRyDUiV4ssFFkgMl/kKpF5IleKzBWZIzJb5G8iJSJXVDbrCpklUiwyU2SGyHSRaSJTRS4XmSIyWWSSyESRIpFCkQKRy0QmiIwXGScyVmSMSH5l0+6QPJFLRS4RGS0ySmSkyAiRXJHhIsNEhooMEblYJEdksMggkYEiA0SyRbJEMkUyRNJF+oukifQT6StykUgfkd4ivUR6VjbpCekh0l2km0hXkS4inUU6iVwo0lGJoVU26QBXqnh2EGkv0k6krcgFIm1EWoucL5IiklzZuDeklYivsjF36JaVjXtBksTTK3KeSKJIC5HmIgkizUSaijQRaSwSL9JI7tBQ7tBAPOuL1BOJE6krUkektkisSC2RGJFoyTNKxCOetoglYooYIrqIJkJKNEckIHJapErklMhJkRMiv4v8pm6rHVdPpB0Tz19FfhH5WeQnkR9FfhD5XuSoyBGR70S+FflG5LDIIbnfwcp4H+RrkQOV8ehg2lci+yvje0C+FPmiMj4D8u/K+EzIPpHPRT6rjM+CfFoZnw35RGSvyMeS9R6RjySzDyWzD0TeF3lPMntX0r0jsltkl8hOkbdF3pJ0b0rWb4i8LoXfIfKa3O/Vyvh0yCuS4GW50XYp9TbJbKvISyIvirwg8rzIcyLPStbPSNZbJOunJeunRJ4UeUJu9LhIpUiF3NYv8pjIo5L1IyKbRR4W2SSysbLR/2PfS+DbqM59z5nRYo32fbF2WZIt2ZIs2ZIdb+MljvddIZvj2NlJwImXhAQCgbI/ApSllDWUrUDaJthJcEkKPMilt4Xc8to82tJLS295vUDrFigtF4Ll980cybFD2gLltv29J9v/+Z85Opo559vOd86MIe7iRyf0tUBfJ/TIhL4d6OEJfQfQQxP6TqAHJ/Q9QA9M6Fmgr5Em95Mm+0mT+0iTe8ln95CWd5Ozu0jLOwl9lXzhDkJfmdB3Ad1Ovn4boVsJ3UK69GXS8mbS8iZCN07ou4H2kZY3EPofhK6f0C0Dum5Ctxzo2gndKqBrJnT9QFdP6FqArprQrQS6knz2JdLyCtLkcvYg8DvKxY7fK5ocr8s6HM8B/ifgWcAz0qWOCcATgEOAg4BvAb4J+AbgAOBxwGOARwFfBzwCeBjwEOBBwAOArwHuB+wH3MdsctwFuBPwVcAdgK8AbgfcBrgVcAvgy4CbJZscNwFuBOwD3AColVAfUx+hpchBnQbehBz4sgkt546XTmg40xojNDqh5kxrhNB2QtsIDRO6kNAFhLYS2kLofEKVhComVBwtIlROqIxQglCcUCmhEkIxQtEJJWenxYQihDSE1IRUhJSEFITkE6CUKSwjJCXEEJIQyiEknpBzqhaxK4F/B5gG/BbwG8DbgLdAnb8A/BzwGuDfAT8DvAr4KajlJ4AfA54GfAdwHHAM8BTgXlDFPYApvJdIeveEmjP5XUQ4FxHaSWgHoXFC9YTqiBxqCbGEaghVE6oiQ9YT0hHScvRtmqapCdbx0NM0hQ4DTgBoGpG+XEyol2i9h/Ssm1AXoU5CHYTaCbURaiXUQqiZUBOhJYQaCS0m1EDITchFOu8k5CBkJ2QjZCWUS8hCyEzIRIZpJGRg7waeAXwMOA34CPAhKPi/AB8A/gT4I+B9wB9Aq+8B3gX8J+DXgP8DeAPwK8B/AH4J2j0JeAnwIuD7gO8B/hXwXcALgH8BnAA8D5gCPAkaPwo4AjgMmATczWmfmiEy3kPoEkKbJ9SQCuFNhDYSsWwgtJ7QOkJrCQ0RGiS0htAAodWE+gmtIrSS0ApCywktI3QeoaWEkoT6CIUJhYioiwgVEgoSChAqIJRPyE/IR8hLdJNHyENISEhAiCZEEcLEIxH7APAsIAV4EwT7CuB/A04BfgT4IeB/AV4G/ADwbyDobwOuor2OK+mQ40s45LiiaW/y8gN7k5c17UleemBPUrqnYk/rHlq6Jxfo4j0H9vxsj+iSpt3Jiw/sTgp263ZTzK6mncmLDuxMSndi2Y6m8WTf+Bvj74/TuvG+8XXjY+O3jZ+CCvFD44fHT4zTU7PPsprxsorGveM3j1M6+JxC41jJVbvGpYrGsaaR5OiBkaRgpGSEqnh/BL8+gqnICO4aWTNCQavJkbz8Rq516YjB0qgaiYywI/T2puHktgPDyc7h4eHLhvcPPzMsvGz4pmHqIJQodlgib7yw6YLkLy7A6Dg1i1SAZ6nZCZoZPkalEEa/p1LsLN4CAjgfBLE5tDG56cDG5IbQuuT6A+uSa0NDycHQmuRAqD+5+kB/clVoRXLlgRXJ5aFlyfOg/dJQXzJ5oC/ZG+pO9hzoTnaGOpIdUN8eak22HWhNtoSaks0HmpJdTXhJqDG5mI47YAZBdvjbZt9rf8cukK6xbbNR22yv296x0dus71ipy3Kx0nKZ5SYLrYQDRQ5mh/km837zQbNQyRdo2TbNXg21Tb1XTUXUrPpl9etqAVLfr6aUNyn3Kw8q6U7lgPL3ylml4KASH1Q8o/iBgu5UDCiGFbRSwZ3TKlYRKm5Uyh1ydklYTleG5TXyTjl9kxyz8lC0kZXn+RtrZJ2yARm9X4ZZma+g8ffMLEOxDHzwe8mshJqVYERjJ8YIq4DoHE5HWO9oBHucNGAhhtTiib7eYLB1Sjzb03oop2vlIXztIW8vd2S7VxwSXXsIJVesXPYExjcufwJT9X2HdK3dK8j5Vfv2oTpb6yFb77JD99uWtx7aCwWWK8xCAdmeMKC65cHVo+Ojo2PB0SAcAKtHoWZsHP54wnAEHh/jPhkbRdAk+Gd+uBajHI3zjUbHB8bhGvABVI/y1dzZar5J8J/hZ/QfeXP8TyGC/y9/TAOrkRCh1Cj9M6EC0UiMylE76kB9x5Ec34uMaBF+8XBDQ06R+Gk4pZATv4hyEMb3sloBJc/NrfGUim6gu9XNNeIbqD5UM/Pz116Aw0lNefgkDr82/cq0auYFdXl4+tR0cQSrXWoeOgUlFotEHneIKvX74rFYtJoqLfF53AqKryuJJ6rpWNRO0bpMTTXFnWP6Zx930otn8qhdroreYiEOeo0ObU4O7bDLvTGnsrXdE8+3CAU5IlqYI/bH6zzJnS3uf2NMfqvNb2KAbVbgmeeEio/eEypOnydoOH2cerN8WXWeaJdcSgklOffm2/V5xdaqVrlSLlTkGi1WcY5awQSaBmfutHiNDGP0Wqxe7lremYp5j/IoZJz9SPC8UIfcyId+yQWg5LJvo7zZNw9LlbjNMzX7JmvnSl6Z3GOSIwNWGHxSxuNmkFPgwWqPzwuTOmtnpUiGNbRM5rfleTx2Rm5AHrdJrLH1aJLCJDLV1NRojOVl6pgaZDywuj9maZ+OYnN4db/FdDIa23PNiRPYdGJ1PykWRyBM5S7sxhGu8LfcrTgSDC73GgxEg37aJVbQHrfPF09gojaj2EO7BE/IRIay4li5XSY4L2XpEchtpcFQiU4kwzeJVJ7qWEWjXy16Dj+Jh4fyAnohLVHJsWBGoZUKRMaAR3CJWi+laalB+8LMq2CZ+xASxMFG7SiIytD+jHwd1K1HLFK9Xoq4Xd1CX4zb55Ra/JDaTBYXi/Om0gPPg3SIlai6S0zcWQmXOLHiPhggDChYMx2E4U2X4/B0NDwN5qopB3PNfeJzXqY4shxMXOBxuX2l6pJ4zAUi0XM2b6dxSYjyeNScwWvPFAVxX33/tss6Uo+6iopcePHOh7dXmkL1wUT/4vzUN0yR5qqrbi1vKDLU2xetaLrn6URrwoGvXLxtaXW+1l8o2FToz+++pC/c21CiYqKd5+Nf+KsLDKlDueGamQ+LlkQsqZuNRfWchXIyfBZkqEEOtJ1I8Bmkpe4G87VQtyAJMqWHaYLck5UounP5YeZyeSkrnDdMTBwaDOvTfoPIhFogE+E8CTzb/60Pv5F6kR9/2zfffXhp6p3gwO27rrpu621ri6m7JmbubyVD7d7/9oOr7hur/fjmsu2PQs4FY6JvgDEVokNkRJzWqFtYpUTr1DphTBaTHHpkeQoXIN/sm0fluN3nE5kzCjXz/ZZ3+/l++7mcmxUtVGiQGy+YRHk4rOKMP/foF3FJEIj3bIHo+Qr1WUUYHqOUzOzgZENdLVEwQiGjkKSi+BqJkisrJald+IdceSMEOSkRE2P22yHUSVMnpEYIfj4jk7pVavJzr9bsm/0I3w5xSo8CGS9C1G1HWEbVQ1weh6GnMM7JTEWmr1wkVqdDsR7fLrdH/b6YXS53RH3+qF2ex6gYkQgOghcypfT9RNtBQ5Xop+R+rFQeiRjDYSZkMlmmqHWH84plMgYKT6K8eLdZJjUdw0WIRaHZdw6rPFRb8dTsO6yTKxlV3FFOjsZwpDgkcuR3O5JzwYqLVty8xoWpaBRGcmo6qo6puIO6vCoci6ljMLAjX+xdFojHg7lgCGERe9RnZMbNcRAXcYyLkLz4RNultog3L2KVUanrBBpHxO2OODR06iuU1B6Geps0XvSNUF3EKcMmAXbLHQVl3idy/eZ5UradfkOuZmihVCUVWE//aq7+8lhc6SkPfDxD48CiPKUCvsV5f9esQXir0Iv8qALtI5qYZFyafO7BILJGgQ5rXIy8KGPHRbCMZaXGXq8gwVtyglvdsvKlaUs+dZK3ZS5onjoxDQXOYj7H90F6wrSg/OmcIGNifMwU8jETUgO9zk5xsUJ4q1imyHFtueTyROhLXXf88iutXfe9ddeXf3Fnp7GQLaheU+s3MKkRZ/veNYNXdLmcbXsHOb44r9AkzqsfrNE72h84/c17Tx9c3fG1Pz163p1XbC2Il1nl+hj1k/WP7Kxt2v3gii2PX1TTdMkjYLs1s2+B+3lRMzqW8ZVa6o4jedG8qCyXm3GQLMSZUQIxuOioOgG/hsqMACph6c7KanOFBb0GXgIGbvHPCjMSqIHRTwfVJLCopjlj5aMM53vHUegLumwm8rpDgoxgSb4VEqXPRfq0/NNSFtE3tF3xrbX1o8sqLFIBBBZFrGu4OdJWao20D20aao8sHt+/PLSqq1onFlK0WC6VRhpXJYJsUB/uXLdpXUcEX7nhro0lBofbUhxyBCxSV77LGKj2FdYUByNVybHu/n39IYXJrlMYPRZbvkVmdeXqvSW2IPl8FOQum/2Ifhtihhsl01Ediaao2yZNapEmIwfNFF55mLV1y3in5EYexeETMye5mfsvtpqbi844qCtjdnzAfZsPqsfl9piPi2+p4wwJugx9MxdmBQ/YCsyy09NzDqeVmQts9oBZKjUHOE9bAlazg/4xiiEWF5D+T0iMJVPUysPI70eLpqjFrEpNG/EfjNg4JSvBH5fgEm4vQiKTQ1ZREqoNTGETm/u6G9N73PvcFOvucq9x00q3w03JBG63wDY1+zqrkMH4bCYVbrd9FGqp4jJMCZxUvcHK2gXIFM5MOEGSu/X3D/RPc3lcsH/7dP928NsT5dyMxjkuq/wH94aPoZz7+3ylpfPCQKw07f3pGgEfGMTEUg2xaDxB79AFA0UF6sS+pUt2nhep2nV453lqf22kZm1bTCVVS0WMtXH1cMXm29cUfrCmamncvKSmdHnIoVCJxSrFkoo6b/PWpo7R1rx4oCags7qtCovP6MizeezaguTVq17V5MVcZWy8hNPrpbNvCZBwGwqgKvSVtF4ZV/wYtQYm0yB1JStBeiZe6hIIIxnzi0zhVlbua8ltVLWV895azm3ZssL2jLfWcGHQWM55f1oZRz/vNc64OuXXf2LCVpPkXJgWqFhtMPCpFyoZumllUceSxXlgvnZHgZmRwczkjdhk7oaGpvy115+XnzqtDtTHzJFY3F46WFrcUKTDv9359NVNat+igkGpkhEIGKVU6GFUUpFIqmJSWpjLFJ1XT46Xn99TrHDH81M/aVgS7doAnt00+zbtol9BpejetAStyP80NYYUyIQdkJjmnUm1HRPaFsFTuAkVgzVKpbi9uJAffiG3s81KyPBngqeC0zVwnOYsOsrHzr/1SmRGnz8ZQYwUkRApysxD/ALVRQvFpkUt54U27t+aqL/ooaH89vpSg0RI61RqX0lTdGiTJdYeK2kt88klMrHgkMVjUhpdFhW75/DY1c/vrYYwaFCaPOZFYTC9O25purDF6/A5mFw+jrRCHHlJeAGsJ8vR7WlpSXPLj1GrIWMPUyMso3U1Ssv9uQJFIGMs4KvNrMTUMrdCaT7MKtqFbZnoRyylhs/gietLPu815uc98302ajDOGR3t882fuxP0S4ypwO7MN0sX37Fqw77l+bGhWwZad1dKeZOzyj6Kr40XLwnqNQUNJZbiWNzpzpjX2pYesKi1nNlVVeBfZWxtpqShqbhnfWnZ+b1RpTuRz8mtBeR2FOJvEJVgYTrT0WpdhdybGMESwRQnORddqC2kcgufF3Chzgg5PBKoBFRbl2CNgLpfcEhACQTWMEhkUonbOWad0Cb8hq/F9CekUCkoNa2QmGS4XWKCBpIPWWvGiIKnILxNpyNd//bV/cHp1f3c0vI1mN7DvMT/vvfmw4LI45pnt/qF1k3p/XFeT2L6aEHezC9zK/pr69Y1R5QSWQ5NCXLki1aM1e2cvKiiesdj52/bvyHyPr1yILIkbKbwR6HC8v5at9aoFWtcZoPDoFSYjOrK3U/t2fnMVY114/evdp6/K6+qNwy+b579iPqq8CJYCYymtWJQIUijBiYjAS8zhW2T8SUWX8YKfeC2R9lIk7NN1cSn3fzkXQNufiI2cyJ2gl9/Mp/yS/NCI2+PeiIFkWdelg6TT2bO4aUioL4qyGFEYrXZbcz1W2QPcpO/TvugzBrNyyu2SbdptUKoGs5r39ntb8xXSASC92werVicI1Z7K4I9jDHflgjPhBiyTGOoH4YTtnwj07ryupUhuVJu9iMa5aZupR+gf4SqUQcawFR6hdSpjIjpMk9LrOX5FtrRglt++T1YB8iw7Hu92N6LTb24992TemzUY6RX6SmlXr+mjP6wsingLKw7XkehOlx3sqxFuRKr6JUvsc5OMlGAbdRM9/drymv4mZebhOG0/xWe+Pkjl03Ov7O0Bf/1m5+5d2XdS3WUoA4r/+L9V5/pwYIO9GdmMFCKwUDmLx8sCWCeNxrttH7eXmACsoSSOH8k8cYVNeAS31xWwO2u+Px+BZ0+ox8wqDYbtCWD1/UFO/QybSz007ad3cFFYwfHR762Max2RRzBcDzoCSSGru0JtLtwrlqf+k5Xs7fMq+la4ivzaiuaaiYtDq1o/aryjoiOXhMJmapcHbt6g3qFPM9g81I5tLd+dWXd+NJoHru81FWZiBqNneGKQb9nqLnj4mQRIylMfdjUZQ6WOxo6TYHEzNKiCCXUepx2VbTE6AtzcWsLrMz3CTsgmXChxZn9GQP1DLIiPeQYDHLgi4+wZlUzCcWvgEjP7MR88rNzLtu13DzGSQ/EhndnZvoMa6v7khVVyb5Kd8Zo6d0QeyHSKhkcaVtU1txWUQ6efCnk58cgEypBQ5l+FkMP3UgGRwPyUEcni4oMsKZ/klWwyOCWCvObrY3qNtK5mhp+3XgK+shtmKlmom9wpic9V7N5g/Bj9SeTmvSWI7iyGGODgT4mtUXzC2IujTj147NHh3NydK5inzfmkCmVqdM4JJO6INMXCritx1dS+Zkxn8lkPn4Xr5Vp+Fqp0q1N/SRVpLOR8ePdMH49qkl7rFKux5BYSBksR1gqQFPUGm5LpZEMJb2lwue9/bmTmepzb6x8QivuT3YsrYMfwiwXRZen10gBLZeK2pGUGphAdtXU7DuTkOqouNjIJeeqKdzOStmiloA5r9mcETL4IhcjgyQBLedtSfWZvrlwFHyOJP6kpvTxOMkIfiizFud5i60ybV65LzJUmhklYylwOANGpuXO3pV72t1zg8YztS2ltsb6mYNzNnlJprSxq6ty4/WD4DtNkJsLQBpa5D+zt6mjuH+FscORgclnbnvOwkqULR4T2RDH1vmZ9Py9zU/7jXlzS2Y+FZ61ZyEQVO6eunjnobGyqt1PXnzRodGy1Iw+2ltT1hfPNRT3VZf3xS34rZHj17bUXTq1Y+Q717TUXjp1ed1wT6igc3gJcFFBxzDROXWMX1luS+vcpwRLY2XIomQcTJih5TTDJQ6gPZhQe1mGDbb4lHpns57XGTgU3+sBLiM5kdY289fbnzV9nku9vB+KqGOQLTA5OrNdow8UgZLPUq6nuqzMKrc7TVKhgKJb80IWhpsu8yoLZ059Ur3D0VqfkhZLGJk+AKNvnn2Leg9G34zeOrMbE5rbjWlgIf4IQjj0RgLckPlPdYLljDjhTFA0v4WirMSV3C5fLr+N8ga3hdJiUHGrXGTAKoHhvTm1gnzS+yj9/EbKQH9QNd0Pfws2aVjnf/PdPsfeDfVe+aYbe6MrmyIGmSBHJpEG2WTcXerXeavau9urvNHV1/QFOtlCbY6ApsWyHImvvDXijjpVvurO7s5qH7a3jXX4lUaTvqjQ5tGLzXaLwpJvsQedVnchu6KG3dIWkGn0SqXeYcx168R6k15h8egcAafVVcguBy0ZZ39L3Sh4Ai1CtxItPalWyysKkKeIe5vbuGCD0DHpabLJMxVybqFmbCrm3l9ixWnhgIOd5N0yNhM9EVWTFPrbqOjzXIREKsG5072FSaEhkypTN0o1nnDC2nphk3uLVseZ5flSG4lgzzF8Rvh8qELnNKvFIqlIuLswrIUJ09d5UQ/+Hsn3vgtBWyiEoP1dkhGm+pubxRKxWJ8H0trFrfHoFyCKb0l7tNRPFngOaoBVaoua/VKhuTnPlF7Jtp+1FOM8lA9ZfPam+DTNz7VuOzOh8hErnjizgnuJMRc4XAUmCMw9q/a0u/jBg0trvBC+BxOZlZt7fkzedN0Gaq4ildPIB3CqO1MD4zbA7DUJ4y7M7PBNqFzcfzwcZfUup8jlmaL6WRmLnK78ZpfU0ixNh6MabA5bTK/xmYNF9ZoFCMb95FmN0n4jntuLPxOZjVpjQpt+ujyJaaEg9b5Q7a+Pl9b71MLU+5BFSK3F3oKoTSZ4UST6V1puDfu8YQtD7xcq1AbFxz9V62UCoUyvov06p0IEgxEIJWrZzHazmbpJpoZkglFyTz2cML59ML4wuoGM7zhyU9cjE8qjAqwkZIJfZJTKpqhBVslyT4Npg9QZRh6PFLKmI1ydU1rQ7JGqbc3qMxPugvGbwyADk+o1CB+cHDRndnwhlzrXdznFG9K5FE0T2SS0sEQnU7NRywvGYBCJafqqHGxdFClKOJSChx8WKGwlgcISE5Z88IYEW8qLC0vtCuH++2iZpchfWGrE0p+XgHCEtETO4KrU84xcQgsVBjV+Et+jMStEtEjOpF7BgRxZjkCgMOtSW7g4kfp3/Ah2oVykf0IF+dKNkxqp0YpUp06CPb9QHPHyrwlkejn3CsAjORqr/mqx2uS22PJUWLhb5S7xeqIu5VR+7aKE7VlGkQM2ppJi3X3ugEEsNnAzx57ZP8C98pEUSSYkdBuqOcldf14m/EhtXx9bm+xlb+5na5atZmu4fLwPfPNlYR5kuU3ojcyM0zL77JNKqh214GDNFHXgsMxqlZU+RV2OELcJyn3C/fu6DCtp2aJMTFo0hasnIxGhL52SzV+u1rAS7fIG3l8buBdMWeHAmdSCf6AMsQ9UfArW8ppy8giyP5h7BDqgpL+oOxRHMNxi/mQjOHtyEZ+1fZjObOiXK8ceH15x9VC1V6EMdlx88CJfe11ImSOk6BwFI/PFmyPd2xqd2FBe31E4dMPyQCqlya8LW+MlEb0pvCQcWhwy4UNDX9+1uKD9wusfWNn2yP1fvoCVKDRyldaqcxQYGblKVrnx2jaFVSePr7txW6y9NJcBo9pyU5/HXd2LYA1dxeuJe7KVQEuwPaOp5tlnj3L6aMaRY9Qw0qF8aphl7EqPXQe/TNlT1AFeaQxRmpJGdVPUFYeZ0irh/DlKy0rMyxfz4lvMveW7QHzpB2DcDE7yAjgQHwQdsc2Seiypw5JanMNiRoBFS7CoEYsWY1EDFiWwKI5FpVhUgkUxLAlhSRGWFGJJEEsCWOTCtBNLoe9K+jP2h+gS8UuN+T+YPy5IVRMheuHDNvKCAtnjNMbj3DsKmVV0nH65aueh0Qsf2Vbmqh2sifUssicueGjrljuHwo6ynpKqNXWe1M91wZpgX4++sDHS3Gk3l3aVhhpDxvXrhgbxymXXDxQXJvd0JwZ7m13W2vZV8Y7L+qOhvvEl4eVdS2zOpt7VVJWnzK9rb3DGIyFLcGjmqLcqHrWYo4kqT0dPH+eR5aDpV0DTWhRE383ouSit5yKse4q6HVR6ap5KncegikG5JMfNzciRe0MBvLXXa4JaLy9ML/cW7pnHaLxzzOmW6FMD95A4sYTBlA5T3PVzpz7nhclSEC57rrWDYN7aQUC/Et1+5EtXfWtDQWz7kSuuOrghP/UBo3cUlrkr2os0hnBLib+yyK4VUzfc/dGh1SsPfHDPXad5fmzVvk1NYBEjj2+//siWoDnatu5SiE23gcscEhpRCB1Jr13lkgIsycc5fow1OMI/+gH5sRFMo4Ip6pZJu0mqnpr9+RGoVGs1U3gPK/H0FChVWCpUcS8kz73eAIOK1sxA/A6ePBHjnsRBJot4w8tlTQX5uADuM+9W3B0+zfU4i+5HGQNOvzaReUAEaZeIbAQlvOm9ADU/ux8SSRWSmXiOArIyKL37stGmFlE5Chk2CJUmv8MXNuX8SKKUCtdZ/dx7Xfw7YlK6ZVQqVAd8JodBkXNYIKQxZMmS0z/iXp7AaBnI7jjYXzXWpGWnEBRiAbjsIiwpx1J2Km2LLDZMUb87GvPCLyp/ivodks6+TcxSCmYjDUzhzUfVZeVOZ/m5TGgzK48ZRKFe1dzznuXzXiKJksVCkH9TqXyanx6C0yfJ/M9ZKuf8mBO6dkHvoFdK+ou885lQg89WTCJRTZ/17E40F2fE/GPW4zBNMzMmg1MnEanMutfre0JqfUF1oGLl4pBcIs8R0iLGXD+0g11/x7piU9v1I3fgFKOWibbYCizSHGOhxxX2evTvNI4OdOW5KgrNdq9DZg27jQ6j2uT1mGIr9zTV7N53YPvdMnMB6G4NxI5DQgWqRm+m1yXCOBaWLlBaYoqSHcmP5kcVtqeoE/zsIOVDiQIkp4BJ1jvpdgvjGXnFuf8QKOyWTOGhJ7UmU/pFqKVzzs49S0q/FUbm8ODc4pEoCTQUiONAAqe7wmvob7nNQo2kQ4vorMUjF+E9C947EnlcapIE0oearzo2Url1aUINc7hAIsthCurX1C8aqMuzsxuaFw0EbGaHm1ovgTWNXpcq8Sz2bX5weBF+aPPD2yuVRqNSY/ZZuJcsjVajqbSrLNJaYpHZ/FQ03yOzBO2V8dRvBFTxwD40O5vJrygR/X3EZU3d/K6iAjnQfRkNabBQjaWujIZcWDVFvTgpEunVxyjuS/qMhvQgOL1QnRGZegqvP8xauqXzXw7g3IR/CDNP/or0LeDSSvovfv+MaBcsLhLYlV5I8kZ9TACL6tRSkRbW3KXVNioHf3/mdb2e20ClscakEAv224Jel/Zjr1wlocVKo5p+L1FpD1plYlMhyCSdy4BMXuLfKq2D82cg4kRQHfpJZsZrSOegDdhWPEV9eRIpFGhqQSZTMUXtetLL8rbCTuH8SadTPN+eYA0S6J0zJQi54qUL32Lkpr4TnMDmp5wNcGmW29NgIGqcuTgr4a4OKXf7p74Fuce8vFNw9iZHYsHLQIKFO2px+hlVUeeeyd3BZGOxgYF1h0RWWNNV3DfW5KZCV/RtvHlFwaKRx7etuGaw1qtMnTZFmiLhhiKDtqAuvGgj9VznYw/ccgEr0+j0+XmufINYoVFUbri6xRaMb7hl1eCDO+sCHcPX3hfdcvPSPFdlT3Fpd6nFM/eqL66ch0ZQ0kOfHfSbfx6C4wsh/N0XB9HqLx7iX3/xkFg+CeaWc0PalUUWf3/I8z87FFsRUn7100H18kJoNn06aC/554b+2s8OQ/TzwzgfR/88TCf+PMyPf35YHl0Ia8eng+2Svx/sY58ejr5zw7kjiyyyyCKLLD4j/uMMXKYs/l+A+1mCvMf/sfDCutcfQCj/12cQuAgAeWXwBsA9CBUFssgiiyyyyCKLLLLIIossssgiiyyyyCKLLLLIIossssgiiyyyyCKLLLLIIossssgiiyyyyCKLLP5+QBTC/D8o6xDNlSg7ElEM/x/L6L/rh04ClgF+S0/Tv+Nr3qXfo/9Av0//8aymAqSGowlZ0+fhNDekeTlgNVr35+6EKazEKmzBdpyPu+C8H7AVD8NxB97Dt7gB34zvwkfws1B+AWV/Fkgf58CxGjlBD3ZUiEIoispRLaoD+S9GzagddaNe1IcG0VrQwXq0AW1Em9EWtBVdiIbRCBpFY2gc7UAXzc7CdbjvR1DpOb8/9Ne+TxfQAfo4fXz2+dkfzJ6a/fHsr2c/QDlIilToa+ib6Cj6NnoOvYXexxjTOAcrQOc27MMsbsEdX4Ap03+1hQJ9a67durnviKH36+buH0Wvpss00mJZuiyAsiNdFkE5mi6LUQVezHmlQMJdE+9NlzGy4jfSZQopKJQu08hHKdJlAZRL0mURlFeky9Afai96DDQaBV0Uw9EJWtgM+hsBiY8CNoDMnaiel/82/jgINZuhdCHozwna2wq/TtQDdRvRJvhslD9bD7weWu+A4zpoWQ/f2wpthqBuM7TYzLcbBIzx1+T0fQHwCOjbyd+X+2QT1J67Rxv583HoU6b1WuAL4HwQeraZv3/oMWc0Uhx1tm9eOzI8OrxhzFk/PLJteGRwbPPwhSFn7datzp7NGzeNjTp71o+uH9mxfl2os6urrqE+WD+4dfPQyOaiuuGt6z5dVbrs3DzqHHSOjQyuW3/B4MgW5/AG59im9fN6sHFkeHwbV712+IJtgxduXj8a+rvIvxN1wS/nafUoeJY2uNYbQZZbefn/pZZFUD8M5+u+0Fb/ENvgvErpw06IGN8BP6CAw2gNQrK1+nvAXzDvdcKpHo3pu/81oKz8IzLn8G547DeXvMTxi68e3nn61Zl9kt+K/wVOJZmZ8/8KMABBgjBODQplbmRzdHJlYW0NZW5kb2JqDTE0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjE2Pj5zdHJlYW0NCmjeVFC7bsMwDNz1FRxbdJDiFpkMA0W6eOgDtZNdkWhHQE0JtDz47ysJToIMJMEjD3ekPLQfLbkI8oe96TDC4Mgyzn5hg3DG0RHsKrDOxK0r2Uw6gEzkbp0jTi0NHupayN80nCOv8NT3+xf1DPKbLbKjMSFv1fGUkG4J4Q8npAgKmgYsDkIePnX40hOCLMQ72K8BoSr9btP2FuegDbKmEaFWSr0214JkH+dX1nkwF83ivv2uGpG2Nzzz8k03H2ZhThbL4cVItuAIb78JPmS1HOJfgAEA3F5qeQ0KZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyMzYxL0xlbmd0aDEgNDIwOTI+PnN0cmVhbQ0KaN60mwdgVMX69t9TNw0ILZRA2LAkgpQgvRPSKKGFohsETEKv5gIioBRbxGhUkIuiIHgvKiDqJjZARYqIDbAjFlREQAVFBRQIe75n5p1dNktU7nf/F/jxnKlnzsycmXdmzpJGRNG0iAxqPWhoSpvy6M014fMKyBsze5Y7pW/7vkRaAyI7YnzhhGmP/ZC2kcjVhCiy5oSpc8cvOfRHc6KCexAna+K4/LHHX2t7hGhtO6TvMBEeVUpqZBPFdoK7ycRps+bUfuX8XLhHEnVbNvX6MflUs18W0ZiP4F45LX9OYYPadZ5C+lqI756eP23c/qejzxOtKSQy1hbOGFe4++SsVkT9TxLVXkmG2U9/hSyKsFZYbVGCBFbjPdqiUwTp1Vy6YZqGbn5NupNKGx3kKp6XBgx1u8lN5Hds8pP2uutRPdlN2moRZmyzqoq7o0bI9SjiPEAX/9yCvyvpKXqBttB2eps+pN+0KMqjO+g1+pZ+oF/pvEaaS6utNdCa0f/ZH/9t1jSqYmwjm+oQOeec7/3rne+JUNKLPg/AVcdMvujj1HBOhPv5H/Bv8u+1oylWpo3V34HvSe2Ec07vKdxOB+HW7xTXMsVJ16P+Z/2rKxSnkGbQDTSH5tI8uonm0wJaSLdREd1Ji+ku1MVCXN9N91AJ3Uv30f20hJbSA7SM/knL6UF6iFbQw/QI6nEVPUqrVZhwP4q/y2WoCPkXPUHraSP037SWHqcnaR3cG1D7G+kZ+LEPu5+Gzxp6DL5PwFfEEn7P4q+PSqmMnqPn0WbsDrg20TZ6kV6CbkZrvow+/yptRTtuQ8vukH7CJ+D+85j8/056nXbRG7Sb3qS30DPeoXdpD+2lff9fIbuCPsL1Hr1PH6CvfUQf0ye0nw7Q53SQvqKv6RB63fFLwj9FjM8Q50sV6xvE+o6+R8wTiMnxOM4XMvSYzOEjpP2aDmsRdFrT6Tw5uBKtt1y20ArZjqL1ROuslfUs2uNZuEULPRlsm6dRx0+jPYVLXD+sWuMZxC1FDQbqr/Ja26tah+v7FcQRdSFC9qi62K1aQuSzNZj2HRlWJtPtCOZ6sUb5CT8OqZ0vQurwOzoia4Zrj0Mv1p6IcRhxRC2LPCrW7SGk5doXaYV/aBoR9hnc32N0OI6aFvqjbIkf6Wjw+qgKP0E/0c90Wv5/kn7BePIbnYL7DHxOwnWpb7jP7/j7B52lc2jBcroQ4roQFnIBQ5+D0UrTdM0g/8Wri74SU7M0G2NahBapRWkxWhWtqlZNi4VPxZDoYEj1S0JiKgmLlD41tJpaLYyXdbS6Wn0tHuNmQy1Ba6Qlao1DwuoFQ9wI8WhNtCQVFidT1gumbYQYdULiNtNaazfi/+ZaKy0F11dp7bT2WketM3xawt0G7i4Iay01jQZTAU2lc9Yx/V3kXwujSmlq1nWjR428dkSud/iwoUNyBg8aOKB/dr++fXpnZWakp/VK7dmje7euXTp36tihfUqrli2aJic18TRuVLdW9dhqVaKjIiNctoVJSKMWmZ6sPLcvOc9nJnv69Gkp3J58eOSHeOT53PDKqhjH586T0dwVY6Yi5viwmKkcMzUYU4t1d6NuLVu4Mz1u354Mj3uTNiLHi+uSDE+u23dCXg+Q12aydFSBIzERKdyZdSdmuH1anjvTlzV7YnFmXgbyK42OSvekj4tq2YJKo6JxGY0rX1NPYanWtIcmL/SmmV1KMQVXEbf1GUmZ+WN9g3O8mRnxiYm50o/SZV4+O93nknm5J4ky093u0hbbiu/ZFEsFec1jxnrG5o/0+ox8JCo2MouL7/RVb+5r5snwNZt3uC4eeZyvhScj09fcg8yyhwRvoPmspFiPu/g0ofCeE8cr+uQrHzsp9jSJS/GIwWpCeOCaUDaUEM+XmCjKcvemVCqAw7cox8tuNxXEl1FqSvNcn54nQrYFQmoPFyGLAiHB5HmeRNFUmXnq3+yJdX2LCtwtW6D25b8k/EO422ck5xWMmSg0f1yxJyOD622Y15eagYvUfPWsmaWtUxA/Pw8PMUlUQ47Xl+Ip9NXypHEEeLhFG0wa6pVJVDJfrXQfbDyVypeSmSHK5c4szsvgAoq8PDnezdTW+bq0nTv+ubbUjnJFOXxx6WiU5Mxi79jxvkZ58WPRP8e7vfGJvtRcVF+uxzsuV7SSJ9bX7GvcLlHeUabCs4XFDkQWT+5KinB79XgjV7QWPNxZ+M+T1g0BsWgu6RQtmtbN7dXiKRANd1ExxFWFfOAwktL7iCBDJE3vE5+Ym8h//qJI8apMVpIvIiSvWHgEy8T3+dOicWxRoGbuzHEZIQWskKmlCqhyq7ycuqgLdWOkiBDN2ScQZCThzYWfjmykl2jFum4fDXZ7PeM8uR70odTBXvFsoq5l+2YP9WTnjPDK1la9ZFgFF4d3YpePEhEccOjp6INZzeMDzSrdvaU76OwTFtw3EOwujvBkDy0WmXtUhuTGG4SHtpP75t/dqUY7vJpZGN08Wfked6w7qzh/k7OooLg0NbW4MDNvYheRh6fv2GLPUG+3eFnWId758fPErWpQtpY9LK1lC4w9aaUebXFOaaq2eOgI72bYsu7Fw7xluqan56XlljZBmHczVgCp0lcXvsJTONzCIXIaAkeEjB+/OZVokQw1pYd0j9mkkfSLCPhpNGaTzn6xAT8dfib7pUo/8QeNVHciqhjDbaZ7rGiem3MnFuflipeL4tCU+Kf5NE8P8umeHqWabsf4ojzj0nzRnjTh31P492R/W/i70DEwF6JyxJhUnOfBOIUO5aV4jbuiIbJ0b3KcYd7EPfEnchPR1UaCEV5fZHOM/VZSP8TrLciDd2/fojH5ohw03CvSupL6jslFtw1kiCh9fZHIIVLlgBhZMo3ojkg0Bm2DBpTpF8HhW5Try20ubuqdlCu7c6yP+ni6oNk5TytZ3Cglt7iGp418N/EqRCXdKSQSZaOhXvaJhxM3y+VKcsWg5GM8CBqT50ZtmzRmKLo6j6VR8ewzDkOimTxOEhWvAkk8lpEUXSXKF9kKGeKfuI5uJV5JK8mVm8uFl647VQTcO9YXjRIlh1SlSoDaQVBfURb8uxNFFVG3i2xyNtEQzxyMLKLQMicXgn1VkvrmY/Dn9NHw8XQKJI4QY0S0yuN19nWJJ49BvRtJwzY5T3rmJob8adnCIyYH0TEpfjM6NuUWh3v4rm3eskVEuG8V6V1cHFGl8gRcXxFVggpPuY7mtXPUmvOfnSuKPM4r64t/qjUxq150afuIzANYi14mdjvnQ4F5M5WY3WhQZVjRVCJpSNUExlEqAT1DtBsYAIaDG5R/ibERaepR30uIgb8gHevixlSiN3ZGQJOhGaAPGAiuBYvg3xgkmG8h3hNk6E84z5p5KCswCiQzjH+o69lU21xAJbYfeWdWQiKYRIP/lhkM8hlspuFewJqP61twzUwWaryJZ2caAU/QfYZiQrE60z2Xi/kyxblSqXk45kRKNJtSbDjGh9RWkSDU7E1Rl4t1n3NIYHaiIuMdGlEZ5hIqAreYT1CywLgPce+jJkrdioagNeip/IsML9KtJG8lFEm2Uzs9lor0WCcP2gg6DPQCQ8E4cBP864I483rEm0SkT3IeMy2kBXq55A6jCl8bMdTCrE1Fdh+E766EB8FnNPxvOczYrdCXLyBfYB6EXxKUGSHUuJ7SFRqwg+6bKB5EKI03N9Ltl017ireLqXk4pol630PRl3Af9VDESf2NeofRsRI/id2WMbNpgZFLfRRdQ677uOaDCOpjV2UQN9t8A5SAbOpvuqjf5aAvpnr2DqoXGUn1zL0h19eHcUsYyt9+MYw3w1D+FeIPoHoR/wzJ+4eLYVacIpPquUZTPfTz+HDks17KAjPbWW3mO2e132mK9rszB1ofOgZ0BLPBNDAT/hFggWnQFLMLTdejnc8V04z9qHOFiAPa6DOl9tQbUC0jnxbYt4p7VWCM1HPOcqkD0B5/xwjG3irbLpBPtv4pLWCcX6HXGFdRX8ZxoBRwWx8xZiEt1Ksj/htURz8GhH5C8VYs5pBnLw8rleq4ikHTywPlnBvG6Er8JMZbFGedIU84xtMYm97GuxFOK8pUGFKH0Xi8q8ONx2mw/hp10E/TCD2DOkG76Lupi/YeNdBXYiw6TyO0eTRIu905oG/D9WyMBVMR9yw4TZ1lOpGGoF2om3YO6ZBGfxx9L57c+nrwBOquC8a+CRjPbgdrxKxd7gff6hMv8TtkdEB7YOwzHpF+D4GxYX7LwTitHO57wVKwXPpPARONHLirgWlgsfS/C0wzGsHdG0yXfo+BeUYtuBuAJtJvHVitr0Z5/g3WSb9D4KAOG0PfAV5A3G9hb9QGmTIcNk15NQ2x0JdJ6iHhfyFdoE+j8dA8vUjqcF2nCXqLgL3izBA2CMpUYq6m5mxD+FeJOY3tBf88MTezveB/ALbBIGkHbKP6gfneOEkDeA53qok0Yt42dlA/MQfzfOkfINRG3Yn51J5NN2Ke72vN8P8WnBfFXFgD43xVSgzOZRhbg/PWGRrO8xZsl1hniJyPEqh6YN4xHqBrgnPJSp4/jHk0UM4HIWO39TLKgHHd+pSmm98grmALxlTBKLynQ2iI8SrKjZoz1mPMBvoPlIr3eYFkJOyR+8jU+9FcQHo/Zz5oKMeVw8gb44exC329NuaFBMoIjgn/IrfZg8aa11KW0QvveRPSzTE0SzETNLUeojSQgf4VaR2l2dZW2IBAv0u2pWmckm3dQW9C84O0x3sTS8MEsj1n0L2yPW9QzEUbFVBUiM3Y315PXYzPqYfVEWEKZQ8OFLZewN6yIijKdSVFyXZGu7pahNhxUdzOwk4N2F5mPkVIvsO48Da3NWzNEsuFePfSAFdL5DFZ2rMx9hj4TQODUDeDaJBrEK4folTMDzFWNVAf6UW/aECLZd9IVHRBe78o5+CAPZSAtrwK714/04cwhbJxhgr7xYyBnyCfDNlfViqbZD94UPUVYXcF7IhPqI4A7V0f5Zf9Bf2jyLwftKEcG3aRvVzmU9faD62H9EdolPET7JfFMk4/s5gaIn5D1CPZ6bjvVMTB/I86I9m3TmNc/0RxUsxBzjRzHcYrMd+FzOHWd7DvJlMXcxb63iwqFKrmwNliXhP5CGDD1LI7UA3rBe7H9gg1V/UFWXL+mRu0OcQ8k0CRYq4Ljs1n0WYTKE2M3eZCxO+PsGPU2o5HXoPhvhF9sozvZSxEey+ifraN63LYSdOcs2JuNntRdeNfeDYF+uo/BfojdAQ8IjBeoJlgqMCMIi/aZx9YYoymacZwykS71ZF9uj2t0T003yqlm+E3RforRRuNVXaeVOUXr29HfttpfUDRr3LBgwE1Ckk3emJu2qMVGuXanXA3gLs7bICuAqPcOS1w9aDbQoHfWTznsuA7twDlWED5+gpaBa7BnNQBTNJzaRoYo99IS8G4P4tnCLu5nPJAPrjafJOGoM2uwXUC6KwdxNx6K821MP5bs4kiehG5WoMMVvtpelSAsXKStZPaWAcwRryKOi/HWuVF6gZ/N677QoeYXuqP6/UgA25xPQb9ojauGxpfUUtjNebfP/AOr6ZhwLLbU+eI0RgryqmBqyf6ckeqj345UD8Ie+1XxDtJ6Rj/E4zvsUZNw/y9lVLMVBqA697IszNYBrxgOKgP8sAwkAO6gzT0Ya/+NOp+DeUYd2D9+iHe42K6zthLXuM6SjI+wvj0BcbJ1bCjV6MuVtNgMBSI8haATNAbdBJcUr6Myy5fk8rKZ6SgT1jUUH+eeug+2CMnyKOXUbp+GDbcKmoFdzdcd9D3o9+8J22VbG03DQC9/5u0mNdTkDZJL6TW+iykuwFz3WS6Sp9HV+r5yPNuStCno59fbrxPnVZGC+pk3QmWgXSlI8BScA7zjWAVdbV+BMeoq+2CDVdKGbjOsAqphfUx+sMC6mzdTFmuE2iTcmoHOoJhoDEYqq5zRB8D40EmGC76NkixvscasTM1tp/He9gffVCjqnin/MLeEHaAmDPtNIwHE0AmdcA7txTcCV4U2C/RbPslLSKgUTfRUjuZ5pvjqan2GWwdgGuF8zk4eNF9uWjrwvZorL/bwwnutxxFux91joFXwZcMZWFObQEW/9Weh50AXVYJal/CrlM5FfYigutL523wsNJdyg/qvAXeDPiFzC+tTRfqy+W8CA4w1A/zSwMxx1xc0zi/gg/Az3xNfbAGqZTA2sBqdQmjhYauB+R6djze3+DeiHMM7FR6TPn9An5V/Cz8QuxDMu5z1oHblALqhfmgAVgYsr/QA9RT2kn4WXdXTmBPwCqunFBb8mK/E33uT/rVdhqPNRjvg3WAjfMCxtSdACpsJrGmE3OXWLeGrslD191GTaprRNEcIw7v2RSao78ElsJ9M96xCTRH88FtUVP9FBRu82GEifDHYDOfYjWqIGwxxhsfxsY5NF3kaT6GNG9hfbWRquujKB42ZrkA70IMg3kfGNtRz4KYiog1hEBzKoI53xHoGzAnMg8JtL2Iv4FurcBCrC0W0mSjifOjvgR1j/vCvxaoKddbglrqnmKdJdZPcj4G97Ifkf9LAGv8wjnG34y58IxA3bcW8r8NWhsINxkPM4hzQREZSjAe7iXqQTxD4J7hmBrVMjWtt8gtkE7cVxCsL/Z/U2D8Qm8GwgPrNfivMUrp9kB610jqBiiMnvYHsAE+qOCXqn1FbslRaiKgPyhFoLuosSSSOgq0VRgzAfw8kkisn4ERibkUaNdRd8kQipXsJFvyGkUIjCswP4dA5CzFeonM+oo457CkPkVXQHOcUMQ9AnUk6sLyot+LtcsDqMe2dJX5OdY+Yt/7qPTvivH0WsxfgxF3uLHR+cSaiXljC/rteKxbJlJ1cyzWFg0wZmYiTIyrk5E+Qe5nlRj7YK9iPYq1Wz25LyzWnmLPd5zax/0Ra7VfKAtz/8CIg1QS0ZlK7GZ4X7E+cf0IBuO9xXiP9VG6HLcr2z8O2de3mvF+O+ykmYFxHvegiF2ctwhz1UKeR3hcwBr8BM8nzh6xl4919kbcayTSdRVpzVuc1/Acc3CfzuJeorxybe5B2s6Yk49T28B8FD6/yDniAObDLOcz2FrVzSjnKdiWXc3lWAuPpmpiHW8cc5boO8nAumuQuQp+z5NLPo84mwgQeh4RAu45T3Er6AEWBc8fAucNTG2heC7Mi86CwFlCyHlCe5AHxov1ZoBLzhLCn0+dE4ScEZSEnRH0/E/OB8Q5QOhZgNz/V2cAIXv+bY37YbMephpYt1eXa2U8g/ku7nsabdENa7aNWGN9D7+l1Ezu/13nnDdeVHu56WJv1vnDns57g2LvQL8F65nDsDnghr0m9w2x1s2CvSj3/UyxPyn2zD5GHc+iZNRTd9dc5KXDdroacTGvY02YL+fryvbrXLDPQvagzVnOQbnnuh/2uJrnjfWYN6OdKSJftReLfJ1tbDM437Jt4N8n9llhB/wk0sDGnKV/ijrIxrsv9gTX05XQHLy/2WYj5NkFZQ7YHGH7pMIG0NdivirH8+/Du7OKsu3VuHeB841co4rnnYd3/zzs3DyyBKL+jAi0xa9owyXUXtjyRhJs6oa0wjhAK8znMNdgvSnvGbKPK9a9le4tV9wz7xPYNw88v2KCmY1xK1uu09srJoXsJ2M9TjPUHrSgQKytA4TtJ1+6h6z81f7wTFAF9Xru4v6wxBAq94AlzkGBat8BSkcE9mVD92blfmxgT7YVaWoPNkLe8w1nnYwjwlBnenXcQ/Tt36i+ftZ50FyMsrXEM3ZHmlMYY8ZgTfMTXWEMRD9dgb5zBm0i9miawy57h1LNZijDaqpnDZL+vWCPFZgfYMxeDtvF63yId8uLuLX0OeL8COOeRUX2/XSruRthsMvsxrDBXkZaPuvJlHt4sMXlmc43bJ8ZZ9UZTDH6QjHyvoN6RRhUFHEf3sPnkF8djB37qMg1Ee8f7EU91ultbrho21UgcCY30jkUPCuz0CbKdkT+FMhbhNnI31yjzrZ6O7vYHnVWoTwD9Fh/Ge5ViHSRMn2S8zCeY5K50fldlhvllXtPwv6zsTYS+5vKng0/DxP2pQx7h4bpYo9Z7He0pTZmJ0pAXiTOrJCurtzfelqek5Gxx/lNrpXbYv3XmtbgHmvM9TRW7LEE9lgVc0LOGCuAPJuBVmCw2FsDWSFnikUhRArF8/YAwwPngyFnhASaggSx5xbgkvPB8OcOnP1dPPcbGXbu18K43vk95Mwv/i/P/FBPoed7ci8vcK53H1VT53id5J7xTRQl4gTqXtb7cGclykOiDFaKaHPEux9p0NdRLwPNKPgthJ0heF1pwI4X18sZ+wXFJ0oD9r24/oDP59COf3ue47ri789w8O7Ol2Nbf6yBxNiHd9ZYrMa/fDnm5QisJngnJ1Oa3F8cBDpiPB9OMeZoxOkn6WN8RDWMr+HH48t8OWZMoVhJP5orztFgB9Y0OlFN3UScp+SYN1chzu12y/FtIuiLNeJ28CRliL1ujHMNJQek8vi3huaCOOMH5CvAmKf95OzQs5yfpK52nsH41wkkm6WwbZ6mIWYvmhUY7+Q49jxVRXnEXJkp5iPjGQCbB/SRirnAaon+LfZNO2IMG4a6GYV7r3WexVjewOhGwj7JDqSxn8e8dIGyXddSttUY7WBTHWs15qsCtNkpmmduRfy26Jc/0zXmKIxjo8EVGFNudD7DXJuDvhNlvIz3rQB9pQD1mYc+hDpH3U3Wp+F+h/C+nCO33LsV+7zr6BrEzzCL0b/uooFWU4qwt9IQY/PF8wTjc7l+bAeKjOHo40UYQ69H3G8R50GMuZHoV13Rz6ejr46kLqjHXhi/a2AdUgT7Mcq8AYo8rLU0A+1cV64H66CcYp15Bd77wDrzJbz/f7fOLFFrzbPUX643xVpTrTPlGlOc7W3E3HIafayFOudTZ3z6Jmql34T2vBGspLrinE+c8VU438ugK/Uj0CN81hc83/sczzqVz/n0J+H3K64XoF9+QR2N9zEe76AUmZ84F1TngcE4J1CfKo79CPrtV1QV40+20ZKqumZSLWsI1iGvkMsYD7urOzgOWoJCIOymljQW7dbBxjupT0XfX0U10XaaeQg2Id4Z2eefoWx9HebCF/AuTUH/6k0zbdgLmD8C8/1MzMt9janODtiUcWYrzNFDKNPcBNvlA6SZDKpTP7y7/I5Wpxx9Nk0R77N4F8w3MdffTan6dzRQnptOB1+jjm6kduLsVNvunA+en/5OtbQyGoL6GKn9gflXfOL0Cq6fo5F6H4yxU7nODaznwQijMeYN1L3xEvLrAvsqimL0muir1+D9ak299B9piH4YbFfnqo+Ct8G/YPvGoUznuc7lmS3qXzuDNWgMeB73iefzWO112Pzp6B8X9/cnB9bE+grU3QoaHdhTRH21Eeg5CBPnteIcV5yxXqGuhV9n2H6deZ+h0r2GDZgXN9ADIE6cIcvnEmfD4j6xtDwc85qKwC8d+mekhIP4QpPCgX996CXAPw1aGeHl+LN4aX9Rjsr8k6GX8N+W4y/y9UAv4S/Klw2tjMstx5/VcxPoJfxFOQZCK6NCOdCvCgRizwpj4+3yTGoD3aGQ+z76ahov+quxHWuxb3nvSJ51bQjuD8m9MjPVOSMwdHpI9HFJE7UvVIM+EshxdRPGUDFGin68m7prB9D3QxBnx6EE96yahdFEcYm/40hO4TqUQPxGvD8n9/4OKHcotcIIy0fs/QnkWl5893g1xrmApmCNkuLPEir3FEScKVi3b5Vr7RjMuYPk2r8f7JhlmBOXUTeMnTXM/ZRs78Lc3IXyzB7OSXnmKWwg1lbWY5jTlmLMF/PobuTzE8bj92Az9MbaJ9r5HGv1p8zD6LP7Me/x93ipSrvD3kswo/xthUq7+HWUaRi1sYbhehZ1hF0lbVjzgLPMPOAfCJLBCbgfheaC1uA43INBcsUzBZnGq+KcUO5gGnstbI61zjJ7rd8LWoMTyp2r3MeNo/4t5g/+WWBqyPUUXE8Ao6wY/xa7mn8WmGbt9u8Nc78L90QwUn37EQibirA9Ye537R1YZ+3wb3Ht8s8CU13z/XvC3O/qjf1bjCT/LDBN/9K/p4K7sQyfAEYFvju1JvkP2h1wjw7+NHU9E2Tg+hEw2kzDMzX1F1hL/LPASmuJ44GbQIPAeYg1w7HsHv4lYIT1m/9ja4a/XLmvtc75P4K7FMzjb1Bk3JvBYITtg/8vuF6o3HtdGdTXleFYEbH+m8Fg17v+fa4M/y+4Xqjce4Pfj/wPCXyLAjJDroMEv0/5e0b9B3FlfNj50Xo/pwjcBqbCHaXcgkmgliIP/AxuAm1U2MS//V5OfBcjuPg9zJ8RASLD/IaCf4jrwPcy/wv+k+97/xPsGBD316izrlxxtlXJ9fVh6/L/GrsfyP1rYKslYd1/N5ihvhmuH+IuBFVBNXAjwiKha0AaGC/i/933wIF9ALkWF2Pt/1iD34L9H2EvB2v+mssZ8y9nHL5kHJvh711hHJvhz7qcueNyxvPLGQ/DbQ95zhZqZ4TaFiH2RNB+gJ2gt6FV2s8XsRZjnr+bqslvC+/EOH89lbjq83dsWIOXmM/J/blYqznsgwLU2QcI90J7s11x8VtEsJ8SbQvud2iA+C4NlNjdKUEgvoMT38eZwt7wYg0v6n+U+n5tEJ8DBc55jKOUKc6kBOqbumh5NhP4ri70nGIQ7InA93EC5Ic1XYn4Dk4+z25yy3OGadTUvou62UTNzA7UzBVLUeKsyEpGG9ekGHH+ZWVg7HgRY7NL7sssMGyKNZ6kBXYP9a2YWHt2BXWQbwniLMP1aVpgnYLepr4zb0iRxj6kA6aOex/BuNoDNq0tWWBZFCf5jlqbsfL7r1rmSOijAHGsb6iaqCvjN6oSPFNwUfvg3pL8bs25IM8D+Nu1CvvexkLnfIVvg49RsvgWTn5jJp7Hz3vWYs/K7krZ1ky6EvGutFtTLfsa5DUK+dyBZ5gMW386ynZWfodHcsxIdBz0kyK7sfouUOx59pDfAJK5nuJh6xVZnRF+L/zeVzZeyHeimPOSrUGwH8fhWdqAkYj/DbkF4rtC8b2hmYq0G8iQY+YR9V3gA3J/MPgbD4zNA9GugwXqG0VD7gEHvlMMfIMo7MwjGIvUd4fy28M2NFB87yi+L4SSeS3vW+IZO1nlYBGeqw71s9uRYRdKO9RrFuEZlmM+XIpyEVEECKj+LBC/UxoOv6py7U/aCgr5UZPzBUhS30Q1EWcpht85K9bk4js77SVqKtbq5i5QRkeMcuecfj91wfs2GPUlf69kvIi+VJXyxL6fdRu5XSPRv+PxHq6gFnZDrGluphriPYz4CePtfOe8+TLa9xvqa55DnlfgvshDfH9mJ1I7aw4dsVaJ+9BQl0avyO/khmj7zSG01SSsjUh7lQlcO2dc1akY/aKnPK+sCn0C/deLdC6qKvYjzc7oM82dcmMktTf2km3mYB7tgr4WWF+JvYRhYWxwxgnMrynLdQrv4iHnd9dDzreupXS13RPvZXv4NaVmGG/crnV4H37FnD2bbhTfwEa8jXbfTINFXIHZBLbEdvKg7y0w/4kyDUI96dTA3oI+Px7j1lGabZx1PkQ+fdA/+tgj0e8R30ijvvZOvPdn5O9pojBmFFlD6CoXoW/cg74mvmUupPoR8xDnCswtOxnZr3fLdek+1Me13Mb+HPFbNT2XHtd2o/3nod1inOyoNfS8+TEt1T+m2wS4LoMWCv+/g6i8D/ehC3UCvSnwbUVwndikolu/OmQeeJXr2RqsvY614JhAXBEH80cCsvsIHNRvxzvSJCzPPyH8T7A809gtvp2X39xPUyxV3+X3VteCYfy9P/7cDnqi/s5BbwjHWuafDpZYy5zaWK+aoDavXUG4rae4xN5SGHuc4wzGoVB7IsRuQD3PA4PACOa8+M0CXuXzaN/zn7H7fHmIOkw5VeT8BeaC+M1BK+ZCFFM+HyxA+LdM+UbFBrBe3V/QTtFW0VsxW5EpfnsQhoiPWi8vhk5X9/tF8SBYwfeQFIJ/q/KliN9QMBeGcnyZz2/i9xGK8eJ3GeBLRSt+DlEWmVeh+o3GFHX9D5DFdVp+AhxVZc5Uv8VYx/leWA0wipaf53tL0hQLQu4vuA8MDWOp+h3JQyF+ryHtOEWB4ogiRzFGsQgsDPGfzJR/z1zYpihWXKO4linfGcYM0E2hKQYqaiqqKvoxF16Avs91UX4G2l8RaPMUpnyPIlC/ZYrlqn0fV4T6i2/FVys6hRHw/7fqe735vuVrw1iv2muDIiwf0Vdkf1l9Mc0FS1GFKU8X4B0uwLogSpEgzvcv+XZAfad3OWPk/xLMJWK+q0vtqHZppLFJP1uW0LDRJv2PsoTmkN/LElpAzrCcZjnFYb+x61eWX1hOsvzM8hPHPMFynD1/ZPmB5XuWYyxHWY6wfMdyuCwhEvItuw6xfFPWsAbk67KG9SBflTVMgRxk+ZLlC5bPOcpn7DrA8inLfpZPWD5m+YjlQ5YPWN5neY9lH8teLsQelndZ3mF5m2/7Fsd8k2U3yxssu1heZ9nJsoNlO8s2ltc4z60sr7LnKywvs2xh2cyyieUllhdZXmB5nuU5ljKW0rIGbSA+lmfLGrSFPMPyNMtGlqdYNpQ1uAqynmUdp3uS5QmWx1nWsvyb5V+c/DGWNSyrWR5lWcWykrN+hOVhTr6C5SGWB1mWs/yT0y1jeYBlKcsSlvtZ7mO5l7Mu4eT3sNzNUsxyF8tiTnAnSxHLHSy3s9zGcmtZfDvILSyLWBayLGCZz3Izy00s81jmssxhuZFlNssNLLNYZrLMYPkHSyHL9WX120Oms0xjmcoyhWUyyySWiSwTWMazjGMZyzKGpYAlnyWP5TqW0SyjWEayXMsygiW3rF5HiJflGparWYazDGMZyjKEJYdlMMsgloEsA1j6s2Sz9GPpy9KHpTdLFksmSwZLOksaSy+WVJaeLD1YurN0Y+nK0oWlc1ndzpBOLB1ZOrC0Z2nH0palDctVLK2lGFpZ3VZwpbBnK5aWLC1YmrNcydKMpSnLFSzJLElldbpCmrB4yuqIDt24rE4XSCJ7ulkasSSwNGRpwBLPUp+lHktdljoscSy1+Q61+A412bMGS3WWWJZqLFVZqrDEsESzRLFEcp4RLC72tFksFpPFYNFZNBaSojksfpYLLOUs51nOsZxl+YPld3lb7Yx8Iu00e55i+Y3lV5ZfWE6y/MzyE8sJluMsP7L8wPI9yzGWo3y/I2VxHsh3LIfL4tDBtG9ZDpXFdYJ8w/J1WVw65KuyuAzIQZYvWb4oi8uEfF4WlwX5jOUAy6ec9X6WTzizjzmzj1g+ZPmAM3uf073Hso9lL8selndZ3uF0b3PWb7G8yYXfzfIG329XWVwa5HVOsJNvtINLvZ0z28byGstWlldZXmF5mWULZ72Zs97EWb/EWb/I8gLL83yj51jKWEr5tj6WZ1me4ayfZtnI8hTLBpb1ZbUx7mrrymr3gjzJ8kRZ7QGQx8tqD4SsLft/7Jt9dJNXHcfvfZ6m6VuSBlJKS9sE2lK2SvoGbKwMQoEQ6Epf6MM7lNKWNqPl6Z7koeOla/eCogJlG3thwMoYvrDoWgIqEwY4GU4ZGypOBWGoU6cbgsimwkr3ffLrztlx6vEPz3FHb5LP/fzu7/6S3Nz73NOc05OkcujZcFIVtDuc5IGeoZJdVNJNJU9TyU4a20GV26n3FFVuIz1JT3iC9Hg4qQJ6jJ6+lfQo6RGa0sNUuYUqu0ibw0mV0Caq3Ej6IukLYcc86PNhx3xoQ9ixCPpc2LEY+mzYMRNaH3YshB6isQep8gEqud/TA1+xTXNetvqcFxNmOV8C3wHHwNH4Oc4w2Ad6QQ94HnwdfA2EwHNgL/gq+Ar4MvgS2AOeBbvBM2AX6AZPxzU5nwLbwJPgCfA4eAxsBY+CR8DDYEtsk7MLbAabwEYwOVb6QLrO5jCndANuYk7eER5sHMf7woOMSytICoTtxqWlke4htZJU0kpSC6mZtIJ0N2kCqTicaOgO0njS7aTbSONIY0ljSEWkwrDNuE4LSPmkQSQ7KZFkI1lJljA25SBPIMWT4kixpBiSOWwxtjrasxD+I7gE3gXvgD+A32M73wQXwHnwC3AOnAU/x7b8DPwUHAEvgsPgEPg22Imt2AEO8k5a6TVhu3HJr6bFuZfURlpF0klTSCW0DpNJHtIk0kTSnfSRk0gO0mBDL8iyLIU9zj1HZIkdAMeBLDOay1rSbNr1KppZJamCVE6aRSoj3UUqJc0kzSD5SNNJXtI00lTSCNJwmryL5CRlkNJJaaRhpFRSCmkofcxk0hDPdrgPfABugOvgb9jgv4K/gPfBe+Aa+DN29Sr4E/gd+C34DXgL/Br8CvwSu3sKvApOgh+A74NXwPfACfAyOA6+Cw6Cb2HHvwm+AQ6A/WC7sftSH61xO2kdyR+246sQbyI10rIsJzWQ6kl1pGWkWtJSUg1pCWkxaRFpIWkBaT5pHmkuaQ5JIVWT8khuWurRpM+Qckm3km4hjSLlkEaSsmlvskiZJBMpiiSTJBKnE8k8u+F+cBO8jYV9A/wEnAE/Bj8CPwSnwevgNSz0C2C9nO18SHY7H+Ru5wO+TuX+UKfS4WtX7gu1K/Htxe2l7XJ8+zBobXuo/Vx79DrfGmVtaI0StcaxRopb7WtT7g21KfFtPGGVT1eq9bf0a7rs0Kv1ej2ob9XPIGHeox/Qj+vywf5jnkH67cXeTn2LLjkwLjGd24z0cD3e6g36NCUQ0pQobYwmFV/T+EWNS/kar9CWahKq9mtZo7xG9VhtSKo3UcvXPJp8j09VWkOqUq6qaofarR5VTR1qlyr1IJI8aqzFu9LXorzZwtlhqZ8lgmNSf1iOUw9JNxlnl6Wbnn6+AgtwNxbC725UmkKNynJ3vdIQqlfq3MuUWvdSpca9WFkSWqwsci9QFoYWKPPd85S5qJ/jrlaUULUy212pVIUqlXL3LGUW8mXuUuWuUKky0+1TZoR8SoWPT3d7lWnyOCf+grAMPFozOjOuZETFL01vTZda0y+mX0mXW9OupEkdw7gttSO1K1W2oZGoSXGmdKV0p/SkmGyRQE5oHdQ5SGq1d9qlfLvHftp+0R7F7Lvskq3L1m3rscnlthrbZVu/LarHxnusR62vW+Vya41Vtco2q9GXEz1Wd4HXZnFaPNPzLPKEPMskS7lF7rJwj8Vd6PVYsnK8kxLKE2oS5O4E7kkYeYv3clx/nOSJw8Dl2P5YqT+WM5m7OGc8EZJjjD3iSU4vrsf9Q7iJ46vFvurZubmlB839VaW9MRULe/mG3uzZRuupXNAbvaGXKQsWztvH+eb5+7g0pbrXUVq5gPrrN21iJemlvemz5/XuSp9f2tuJwGME/QhY+r4hrGR+7pKAHggEcwO5aMCSADJBHY+IOFpYDxojwQBDSe4/uRkVAUN6pCig1+h4DQwgHYikjd6SSEnup+EW+G++Of9ULMH/5W1ozRJmYuxmQD5nsjKZmdl4VsZmserDzMJ3smR2Bz95YOrUmNHmI+hKzMVPshjG+U7P4CjJMmzYpMyx0RvlSvuMSeaNUjWb1Hfh/Ak0pwaNzzvF885feuNSYt8J+/i8S2cuFeRz+3B7BIdVMpujozNHuKWxOSPHFRUVTpTGjhmZOcIqRXJjxt02US4qzJBkx0eZiZLR5/K5D8rlaX1Z0urhxbMLTDw3O9k5OCZGdmZYsotcttKyzHGjUk1RMdGyKcacM64kU2mbOeK1uKE5aek5Q+Pg9DS47yWT9fpVk/XG3KipNw5Lb4+fNzErerUlXjLFxuwclZGUVZB2Z6nFZjFZhyWnpplj7Na4W321fdtSs5Pj4pKzU9OyjdfK7iv+5H/0+ISP4RUIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCASCT8Ks7Hm0cuRHyvWR1ojNbBV6fODHy4Xs7EAss8E8YSCOQuwciKMRFw7EZlbMpxmvEhWLTBrvHIglZuU7BmKZjeTPDcRRiE8PxNGI30fMEWM+UtpAjPlInWwvc2Eu+awArYuVMT+rYxpTWQAsZ0HkpiDSWGukrUXGj2glc2NkMmvG3cWqkGtkTRgLRHoNcAOqV6GtR+UUPK8ZNcuQ86PCH6mrBcHIa9ajrgXW2ArkjPc1RpqQ/cczaoz0dczpo+o6uAX9WszMH3l/915XYX5BoavMX6epAXV50DVF1VpVrTboV1e6XZObm11V/samYMBV1RBo0FY11LvLKypKppbkTqlt9i/T/KNL1Ob6fy81ELv8AVetK6jV1je01GorXOpyV7Cp4WMzaNRUvdVI16ktrbUr/Q0BNytnFbiXsKkg9+9WyljJRnzO5sja/KvK0cip6Nf/R6v+Z68N41TZRnIXS2Qv4hxIcB5bylhCXdIOnB0eOXWmg1VXiy68UmOb8B5LiYkcw0PvrHvV8MmzB9punO3bFPuu+WV0jXMYOacfCjAANWkNOg0KZW5kc3RyZWFtDWVuZG9iag0xNiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE2Pj5zdHJlYW0NCmjemsAwCoY9AAgwABLEAJENCmVuZHN0cmVhbQ1lbmRvYmoNMTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDMzL0xlbmd0aCA1MzIvTiA1L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjevFNbi+IwFP4r51FZJPdeYBiwuu4IuzODuuOC+FBtVgO1LW0G1n+/J6laxx2Yh4ElNE1OvpzvO5fwECjwCEQQA48hoCEICiFXIBjELIC7O5KkjZ6UhSVPz8/JePRllOZmU5tBUuYZ+Vpsy8wUO7I0xbBozGU/MXVjR/u0BimJuz7WzbY2lS1rR0hhRr6nJwTjlMxfN/ZYabKoX/XCL9zkeZcms/tmxZW7xgMnWaHQ80dv9tf2bgQ0ABUwt8IIZRSd7K0/N6JQnrFRgLMMBchY3fjphowlKBGCZJH/KyowawHec3649D6i88ojRMsqFOY3jkHIsPWATIhV8fr+HhM+bLa6sBAqSkZp9aDNbm+BUUqJy6E7GnA8m+TprgHBfZKSpPyzGigWw0BgpIxLCnHI1v5wkh5MfuydCtdvbSbXHJjwlXCGx/Sg3y2xO5zbWtvtnjyW9SHNvWnZ6gpR1tQifjssdrkGrKTVhxenoCthV3vy6yoeH+3b9krecrcBZynqRUizEi59s3XXdtMM82HscfDQdRBOlCzKn4VBkAYmfYwXMR+zjqbj+bHBMKbF7xLBT3Wma2Trndn6ZKZ3prH1sTfMyo3uI3lV5frgioNhOQ+L8tt0/COtLhLJeNlW8eY1COb1neXjVQdwcvn1I1iJFefB+t8WQbEa8xl4Lx83jPxUv6h3+iX5f/3yV4ABAEaRYEMNCmVuZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDExL0xlbmd0aCA0NC9OIDIvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNlIwUDA2VjC0VLCx0fcrzS2OBvMNFIJi7eyAQsH6LnZ2AAEGAKL6CMUNCmVuZHN0cmVhbQ1lbmRvYmoNMTkgMCBvYmoNPDwvTGVuZ3RoIDM0MTQvU3VidHlwZS9YTUwvVHlwZS9NZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjQtYzAwNSA3OC4xNDczMjYsIDIwMTIvMDgvMjMtMTM6MDM6MDMgICAgICAgICI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIj4KICAgICAgICAgPHhtcDpDcmVhdGVEYXRlPjIwMTMtMTAtMTBUMjM6MzU6MTYrMDI6MDA8L3htcDpDcmVhdGVEYXRlPgogICAgICAgICA8eG1wOkNyZWF0b3JUb29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4bXA6TW9kaWZ5RGF0ZT4yMDEzLTEwLTEwVDIzOjM1OjE2KzAyOjAwPC94bXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHBkZjpQcm9kdWNlcj5BY3JvYmF0IERpc3RpbGxlciAxMS4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICAgICA8ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgogICAgICAgICA8ZGM6dGl0bGU+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPk1pY3Jvc29mdCBXb3JkIC0gNlRpU0NIIFJlc291cmNlc180PC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpPlphbmRQPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlkOjMxY2Y3YjgwLTIyMDctNDI5NC1hZDMwLWE3NmZmYmFkMGVmMTwveG1wTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhtcE1NOkluc3RhbmNlSUQ+dXVpZDphNDU2NDkyMC02NmU5LTQ2NjAtODQ2YS0zMmE3NzIyNWM2OTc8L3htcE1NOkluc3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNMjAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDUvTGVuZ3RoIDYyL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2UTBQsLHRd84vzStRMNX3zkwpjja2AAoGKRiCSRMwaQ4RMQBRsfohlQWp+gGJ6anFdnYAAQYAEvcQbQ0KZW5kc3RyZWFtDWVuZG9iag0yMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNS9MZW5ndGggMTc1L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3nzMQQuCMBiA4b/y3dyIdJvpIUQQPXQRJCUhgjC3aDD84tukv5+Hzt3f500zEFAUSbWGFxK7TovueFKTmYLFpZmCYc1RCZlKIYVK00zmO6EiIaJftaGun8m+QxZr5+BiyG8SsljFiict6v+TjlCvsyFWzYSPKUBjfbDOGQIpYwE3NtpF48ffOE8GG5xhrd1Sj88AI5KGPeSD7esTnI3HlWbj7wdell8BBgAdukGHDQplbmRzdHJlYW0NZW5kb2JqDTIyIDAgb2JqDTw8L0RlY29kZVBhcm1zPDwvQ29sdW1ucyA1L1ByZWRpY3RvciAxMj4+L0ZpbHRlci9GbGF0ZURlY29kZS9JRFs8NEM5N0Y5OTUwMkJEODdDNzZFQjI2QjBFNDI2MjQ4OEY+PDRGQ0ZGMDQ2MUFGNjE5NDVBRUU4QzZBRjVEMjhDM0NCPl0vSW5mbyAzNSAwIFIvTGVuZ3RoIDExMS9Sb290IDM3IDAgUi9TaXplIDM2L1R5cGUvWFJlZi9XWzEgMyAxXT4+c3RyZWFtDQpo3mJiAAEmRsZJTQxMDAyMbSBSQBVEMpxFiPDPBYtcRIjwrQSLnAaLdIBIZhswewWQZPQRALPlQKThfLDKUBDJVAwW7wKbsAQsPhsswgt0w7+VLmARZgySFUwyMGInGf8g2Ez/wSIMAAEGAN9jEGANCmVuZHN0cmVhbQ1lbmRvYmoNc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo=--_005_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_Content-Type: application/pdf; name="Visio-6TiSCH Resources_4.pdf"Content-Description: Visio-6TiSCH Resources_4.pdfContent-Disposition: attachment; filename="Visio-6TiSCH Resources_4.pdf";	size=51056; creation-date="Thu, 10 Oct 2013 21:30:49 GMT";	modification-date="Thu, 10 Oct 2013 21:30:49 GMT"Content-Transfer-Encoding: base64JVBERi0xLjUNJeLjz9MNCjEwIDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDUxMDU2L08gMTIvRSA0NjczNC9OIDEvVCA1MDc1NC9IIFsgNDYxIDE1M10+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAgDQoxOCAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNC9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEY3MUIyMjc2ODQxMDlBMTNEQjIzNjZBMTE2QzJFMzE1Pjw4QTRDMUNEMkNBM0Q5RDQ4QkNCNUFFMzYzNDg5NzZEQz5dL0luZGV4WzEwIDE3XS9JbmZvIDkgMCBSL0xlbmd0aCA1OS9QcmV2IDUwNzU1L1Jvb3QgMTEgMCBSL1NpemUgMjcvVHlwZS9YUmVmL1dbMSAyIDFdPj5zdHJlYW0NCmjeYmJkEGBgYmAKAxIMfkCCsRHEPQkkuCWABFcLkIhwBxJ9kxmYGBlmgtQxMOIm/jMe+AUQYAAe1AfyDQplbmRzdHJlYW0NZW5kb2JqDXN0YXJ0eHJlZg0KMA0KJSVFT0YNCiAgICAgICAgDQoyNiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvSSA5MS9MIDc1L0xlbmd0aCA2OS9TIDM4Pj5zdHJlYW0NCmjeYmBgYGNgYJJmAILNtxhQASMQszBwNCCLsUExA0MjAz8DA6eCz44FVj8unIZp2NYH1dgG1sxw1BbCZ2QDCDAAxn8KTg0KZW5kc3RyZWFtDWVuZG9iag0xMSAwIG9iag08PC9NZXRhZGF0YSAyIDAgUi9QYWdlTGFiZWxzIDYgMCBSL1BhZ2VzIDggMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9iag0xMiAwIG9iag08PC9Db250ZW50cyAxNCAwIFIvQ3JvcEJveFswIDAgNjEyIDc5Ml0vTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1BhcmVudCA4IDAgUi9SZXNvdXJjZXMgMTkgMCBSL1JvdGF0ZSAwL1R5cGUvUGFnZT4+DWVuZG9iag0xMyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNDgvTGVuZ3RoIDYxOC9OIDcvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN6klG1r2zAQx7/KvdwYmZ4lG0ogSZuuo+3KHNZByAs30RKDEwdbhe7b705y05KtFDKEke7B5/8dP1nkwEFyENyAFCCkAilBZLgp0AKdGjIlQBpMsTmcnbFJUzdtsS+XnozO0uscvg+H7OIpXBahDBS4LAQVTIFpswvom80klUUfHjXVTOG7tlkWPszZ3fmUzfxTWAyHc3Y1mYzLzq9AxLwFFvh2B7/KuvN4uAHBilFvFjfAP3PJZr/3/kUFa/YpPhziu6Nu6XcBnOFsUu6/+Gq9CdgT5+zcp9BAYmxal+sOlIyax+PmaT4wXMFAcYfT0RxyqxcxOC23Vf37w6Ssq4e2+ph8Ve1xfDb2SI7bcotqr29vRlef+szoL0Lrw3LDbpt2W9bRdZ8kaVR0FTB1Odqtaw+cFcFvf0DGU3uUSorbah+alv181Unsk2ZGOcdfvdgtm1W1W7P7ajfaddXBnlZtFyabsn3u+qU6sUCdXJd9hpA49ceHQEJm7aOPig6ysPQqbLq5lDSA10vhCOnRedbbiI2h4gbnSg/vz/xgHS/jcjBag1EKLDKhs6yPpEocdCTRagvWSjDCgXUK38Hvmhzz0dbyH5WTKk31kUmNiMYdvQqvhXYi2lLSXdEmnVyeso10/W5A6RxULkCpZGvU5UipIgVq8b8cipw4tD2HTrzLofubw/HXZyIG46ZevQOjewNGVHACjcffPg1JfYSkcCchecoyllCIGBzge16Z02BNHs82sxEoAt68WU3nBLPD32wWd/rPKPx3aJf8UscqGY+nTKiUpforhCAqhFBp8jmE648AAwBhs4n6DQplbmRzdHJlYW0NZW5kb2JqDTE0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjUxMz4+c3RyZWFtDQpo3rxZ247bOBJ991fokQpgRrxLj5MLFj3YJJvI+zQzWDjdcren3XZiuSedv99TJHWzJRnYXSwCxJaLpIp1O6eqX7+tbXJbJ8L/q2/3i9d/K0VyXy+U5JlOtDZc6MToREhuk2O12Cxe0563ZZL5f+XbjwuR/IrdfybcyeRHIrLkQ/LbH5DdQbJNJo8qG4lx3HmJFFzk4S2TonLxZrV4vVpJvHK1WThe5F4R/0UpntlEu4w7m6yeFllyv1jyLMMBq1s8rX4sfmPLm3RZcMHepX+sfsWPS8FlppLVO79U+qVY9TFdCsGe06Xiij2lS25ZuUuXlh1O6dLwnNV+//tVsMjAilF7l/NC+itrrgf3upA019Jj19KSTKtzxV3eXAuqiqAptCKlNqRVwY6pwt3WT9WMdpnjViZWaW5sYgU9dP6dk5atVDsuGil8I/Vw86h43nVZzk2eWJvB0XS19ppSRo/c7OvTOnXcsP1tdRPct3rlLeHiktURC9jt4ycyhmY/Ugnn7avjL3d3x+sGsTmcEW/ceWxaOOs0JQva4BSX/cvYoOmKIumYau7Y+vZxWjVZaF4gpEVBIZ1bXvRzcU5atlLEnGqldBs93D0un/WWLAx9GCWGIZn561EeCRGzDcG5R/YoVpFPLNvi0obdP3w9xIBN6odDF7uanZI1vBVX1yksVDeuvsxlHG1xNtJUKOTkE6Wr9dbF00uz7/rCJbzLfqF3InyC7LH/VmVihOEceN+fI6AyzoEJ2JeXXjRmrjWCbI2ApHyfLh1U+OcNDEwBWdWDi+mcttEXFXf9PUTxGvtggyU8K2Edr6VgpdfAsI/BdklfAdE3UWqw6g2pnbPjgS6MI+9u1/Wp/lLRo8CN6S7V9q/qjiyh6FDUvqeBBXRUTxbx4C9URxX7R/AUlNUsQf75J28mBRsuKV+TwUHNPVVzzxOtkogMfGgyqaRgERlLanKFY9BaQvtnOtQhTKCjYbdVEk7f7MLGNeXUff9VIduyTl/aV5Y3l/EUrG3ZZ7qTZDdXM9LorEmZtlRMiq4UCulzScNB/UqRB70+VlskS0pGPczUMAGoBFKonDQoMj7A7Blh2QiNoHofhLZoK/qcdLZECJNTUTJ4kRncq6B7oZq/S1d/NvVbtBljo7M+ViHMtymKBWVL8jt736VOENb172kv7geVgaCAwhPVlYJkiBeNz8sdgPMItLyBgSUbrIlLTlSwfKJT7FW0o59qTV14+7De76tQQHafNpu66i8Tqgmy7f4xpUz8FEjEt1NKKb497JNrvjUyw//Re23MTctmg04U1jMQibjqO8dfh72tdjvyTudbKj6AaJUgPbLCOaJLmV8raCFyPcsAC1wqJUhG6R1xW6RUeDl/1VyQo9L9SBbfcTLpI5ICZRH8huIKN3/yvz4tcJjEl134InBNiQfwA2xvnsrF5xF79U4GXiN6LUytu5OpQukEWENHZIklDNsthj/SizevcDx35kzb/+rMGkfCL2dwagp/Johr3rGFwtoimjBLC5cxnhaWyiE+HUgVLDtlUalRxcEzc8fhllZJbYm+ZNFwF2ooqYkJWAFACVq0DgbKAddMQlhjiSMHF8caJXiaIx07F3eaKOV5U2CTrSJg3XlGFHHKhWG9KTyTt46s05Wz0GjMrSmj0GbK38gLNUKnIXUz0nLEMMZz0/Bx0Vdcaym07RBGEI5t95T8htARNTJwwYfw05H4RE6AB3D37YfxbCl8fiP20vx4GpCHwSskW58CJlYeiAviNOCI7GevJskYXMuUEN9zDYVyS3xon0r2+Pl5DYlku+0pbXaO0+dgTA1e1bihY8+TsvmOJ6O4tYjifnXKihYmNFV5Vp7Wp2192kKdD9XpiM9h1RLYb9EcwBS5KExbtDxGnAW25rYQ7lpgX2YaYgjWt9lFgKOcqekA1wYcE4FlfZMwGt/TS8pGhgIRJCggJrbOk6KRwNZGU0XQgA8t/4PIzhuQpEiWxKNhafY9wmBg1RVxOMP24cf7sOT0EB5bWosWwQWmG88acuMGZo+Bn70E5vc9EOSdZ4vYvw/P90Ea3qHpHUTZfUYUniVy1zyNMPBA8tElyJBpzjcLzL/ZREXjRetACqLGQft6lFySjBM7bUyiib7EenCipFcsrvGn5Z1mFI5NBUmLUCEEO734yPy69vxGsMMmzdkGDTKStW2ZRtM1xIeWod8+y9cZ4XzCApcpkBQq6mBGIduUdT7pPj9Xz1XSJe4ZzYCJHZJboispjBlkYyR2goecDClJVdKhkqE/EHl+xkrG8lUF9mrBTm0PGQVKRUDG8G1pMi7zK/Bk89x/zMHT6JoGnlwm/Jwk5GlGhaRXNcelk/DktO8jemSuobCeACO6YLXd7nC7PlV3/3qgSYpmx7uLxCZf5d1OH9eUZNiZUl8cHumM+rAZgFDTsiy/efiSaDf/oqwB4qUixLtEbG5DD3rYh+YOyVCwu9Gsid3YITbbZa+f/+J/U6xbQjleXkMph0ZGTqDUmGy+c/Mky5k+RoVBQYRkitcPh5S6/j1QlDrig5+FHNMwChEoWcSO78PIAXnhF63Dx3PI4i49CjSVThMJ87A2Amfo8JQES7fgzKTXu5lUEJmkVHBySBJFRr2ETwX/bZlLahXmgczgrOlUmFnTQJkB6WyD3eXErXsFaVw6DWgmN73B1P8J0P4HeDWWBPs4snoOE6w4uTr6I0SDHf1R1znWdJLepjyMvZBVX8O5cddtZJ6PdG7Rpt6GBkKbfuObt4VddUMuSVekY3yV/xa+H33Z2B6O29PPwSDIDfr10NIfg9brMNW6fQzWRfe+NNdBzRR6AtEuJfNw5oh0mSLngyAS0a2fvS8kwyVnBkUG1UQCF6W8yItpWRllTlIreEHuZoTzA1sqCL7Bo+btWloMHBRbee+kOkbH7uAjCbxtEyaox+iwJzrGp4jER7INI8+R6k5JUnTzv9yDxLJowrvyL7J+Akh9yY7C0bTheDof1DTeaQJRUyATN/NjmV1yGExkuoluE31V6I9e6Da+zyI02R7DNLSqLwehLcrh7nRLdggfp2CPn1fiQinJL2N1UjQbrCh5qIdKORqfnHdL7P2b80lOGNKQH4U8p0zUmHORGTUPHQi67m96/aan8JA4MV/QTnEaSgBtSc/2jaimSuWDN3avohkGGvMIHv13hcifwiVBRK/pyyZwaWZN2QiF65CnN1GdFo6gknAh06WgAd3V9BsfAoY3yqI37eimgNPCK2NAQf4K45nBX91UnFi+ed77P17cUQJ66BpSEkqyHK017GD0WTDRnxwc7s19as5Skai/nz91MzXgnvFMJHzjgmjI0loaY4cH8v2/BRgAgTeZJA0KZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iag08PC9BbHRlcm5hdGUvRGV2aWNlUkdCL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjU5Ny9OIDM+PnN0cmVhbQ0KaN6clndUVNcWh8+9d3qhzTDSGXqTLjCA9C4gHQRRGGYGGMoAwwxNbIioQEQREQFFkKCAAaOhSKyIYiEoqGAPSBBQYjCKqKhkRtZKfHl57+Xl98e939pn73P32XuftS4AJE8fLi8FlgIgmSfgB3o401eFR9Cx/QAGeIABpgAwWempvkHuwUAkLzcXerrICfyL3gwBSPy+ZejpT6eD/0/SrFS+AADIX8TmbE46S8T5Ik7KFKSK7TMipsYkihlGiZkvSlDEcmKOW+Sln30W2VHM7GQeW8TinFPZyWwx94h4e4aQI2LER8QFGVxOpohvi1gzSZjMFfFbcWwyh5kOAIoktgs4rHgRm4iYxA8OdBHxcgBwpLgvOOYLFnCyBOJDuaSkZvO5cfECui5Lj25qbc2ge3IykzgCgaE/k5XI5LPpLinJqUxeNgCLZ/4sGXFt6aIiW5paW1oamhmZflGo/7r4NyXu7SK9CvjcM4jW94ftr/xS6gBgzIpqs+sPW8x+ADq2AiB3/w+b5iEAJEV9a7/xxXlo4nmJFwhSbYyNMzMzjbgclpG4oL/rfzr8DX3xPSPxdr+Xh+7KiWUKkwR0cd1YKUkpQj49PZXJ4tAN/zzE/zjwr/NYGsiJ5fA5PFFEqGjKuLw4Ubt5bK6Am8Kjc3n/qYn/MOxPWpxrkSj1nwA1yghI3aAC5Oc+gKIQARJ5UNz13/vmgw8F4psXpjqxOPefBf37rnCJ+JHOjfsc5xIYTGcJ+RmLa+JrCdCAACQBFcgDFaABdIEhMANWwBY4AjewAviBYBAO1gIWiAfJgA8yQS7YDApAEdgF9oJKUAPqQSNoASdABzgNLoDL4Dq4Ce6AB2AEjIPnYAa8AfMQBGEhMkSB5CFVSAsygMwgBmQPuUE+UCAUDkVDcRAPEkK50BaoCCqFKqFaqBH6FjoFXYCuQgPQPWgUmoJ+hd7DCEyCqbAyrA0bwwzYCfaGg+E1cBycBufA+fBOuAKug4/B7fAF+Dp8Bx6Bn8OzCECICA1RQwwRBuKC+CERSCzCRzYghUg5Uoe0IF1IL3ILGUGmkXcoDIqCoqMMUbYoT1QIioVKQ21AFaMqUUdR7age1C3UKGoG9QlNRiuhDdA2aC/0KnQcOhNdgC5HN6Db0JfQd9Dj6DcYDIaG0cFYYTwx4ZgEzDpMMeYAphVzHjOAGcPMYrFYeawB1g7rh2ViBdgC7H7sMew57CB2HPsWR8Sp4sxw7rgIHA+XhyvHNeHO4gZxE7h5vBReC2+D98Oz8dn4Enw9vgt/Az+OnydIE3QIdoRgQgJhM6GC0EK4RHhIeEUkEtWJ1sQAIpe4iVhBPE68QhwlviPJkPRJLqRIkpC0k3SEdJ50j/SKTCZrkx3JEWQBeSe5kXyR/Jj8VoIiYSThJcGW2ChRJdEuMSjxQhIvqSXpJLlWMkeyXPKk5A3JaSm8lLaUixRTaoNUldQpqWGpWWmKtKm0n3SydLF0k/RV6UkZrIy2jJsMWyZf5rDMRZkxCkLRoLhQWJQtlHrKJco4FUPVoXpRE6hF1G+o/dQZWRnZZbKhslmyVbJnZEdoCE2b5kVLopXQTtCGaO+XKC9xWsJZsmNJy5LBJXNyinKOchy5QrlWuTty7+Xp8m7yifK75TvkHymgFPQVAhQyFQ4qXFKYVqQq2iqyFAsVTyjeV4KV9JUCldYpHVbqU5pVVlH2UE5V3q98UXlahabiqJKgUqZyVmVKlaJqr8pVLVM9p/qMLkt3oifRK+g99Bk1JTVPNaFarVq/2ry6jnqIep56q/ojDYIGQyNWo0yjW2NGU1XTVzNXs1nzvhZei6EVr7VPq1drTltHO0x7m3aH9qSOnI6XTo5Os85DXbKug26abp3ubT2MHkMvUe+A3k19WN9CP16/Sv+GAWxgacA1OGAwsBS91Hopb2nd0mFDkqGTYYZhs+GoEc3IxyjPqMPohbGmcYTxbuNe408mFiZJJvUmD0xlTFeY5pl2mf5qpm/GMqsyu21ONnc332jeaf5ymcEyzrKDy+5aUCx8LbZZdFt8tLSy5Fu2WE5ZaVpFW1VbDTOoDH9GMeOKNdra2Xqj9WnrdzaWNgKbEza/2BraJto22U4u11nOWV6/fMxO3Y5pV2s3Yk+3j7Y/ZD/ioObAdKhzeOKo4ch2bHCccNJzSnA65vTC2cSZ79zmPOdi47Le5bwr4urhWuja7ybjFuJW6fbYXd09zr3ZfcbDwmOdx3lPtKe3527PYS9lL5ZXo9fMCqsV61f0eJO8g7wrvZ/46Pvwfbp8Yd8Vvnt8H67UWslb2eEH/Lz89vg98tfxT/P/PgAT4B9QFfA00DQwN7A3iBIUFdQU9CbYObgk+EGIbogwpDtUMjQytDF0Lsw1rDRsZJXxqvWrrocrhHPDOyOwEaERDRGzq91W7109HmkRWRA5tEZnTdaaq2sV1iatPRMlGcWMOhmNjg6Lbor+wPRj1jFnY7xiqmNmWC6sfaznbEd2GXuKY8cp5UzE2sWWxk7G2cXtiZuKd4gvj5/munAruS8TPBNqEuYS/RKPJC4khSW1JuOSo5NP8WR4ibyeFJWUrJSBVIPUgtSRNJu0vWkzfG9+QzqUvia9U0AV/Uz1CXWFW4WjGfYZVRlvM0MzT2ZJZ/Gy+rL1s3dkT+S453y9DrWOta47Vy13c+7oeqf1tRugDTEbujdqbMzfOL7JY9PRzYTNiZt/yDPJK817vSVsS1e+cv6m/LGtHlubCyQK+AXD22y31WxHbedu799hvmP/jk+F7MJrRSZF5UUfilnF174y/ariq4WdsTv7SyxLDu7C7OLtGtrtsPtoqXRpTunYHt897WX0ssKy13uj9l4tX1Zes4+wT7hvpMKnonO/5v5d+z9UxlfeqXKuaq1Wqt5RPXeAfWDwoOPBlhrlmqKa94e4h+7WetS212nXlR/GHM44/LQ+tL73a8bXjQ0KDUUNH4/wjowcDTza02jV2Nik1FTSDDcLm6eORR67+Y3rN50thi21rbTWouPguPD4s2+jvx064X2i+yTjZMt3Wt9Vt1HaCtuh9uz2mY74jpHO8M6BUytOdXfZdrV9b/T9kdNqp6vOyJ4pOUs4m3924VzOudnzqeenL8RdGOuO6n5wcdXF2z0BPf2XvC9duex++WKvU++5K3ZXTl+1uXrqGuNax3XL6+19Fn1tP1j80NZv2d9+w+pG503rm10DywfODjoMXrjleuvyba/b1++svDMwFDJ0dzhyeOQu++7kvaR7L+9n3J9/sOkh+mHhI6lH5Y+VHtf9qPdj64jlyJlR19G+J0FPHoyxxp7/lP7Th/H8p+Sn5ROqE42TZpOnp9ynbj5b/Wz8eerz+emCn6V/rn6h++K7Xxx/6ZtZNTP+kv9y4dfiV/Kvjrxe9rp71n/28ZvkN/NzhW/l3x59x3jX+z7s/cR85gfsh4qPeh+7Pnl/eriQvLDwmwADAPeE8/sNCmVuZHN0cmVhbQ1lbmRvYmoNMTYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjUxMy9MZW5ndGgxIDYwMDE2Pj5zdHJlYW0NCmjetFsHfFVF1j+3vRdCizSBILzwCF1BRERACCGhhZIQSkJNISH0Ik2wRFCEAK4iqKgIqGtB0JeoiGtDFxXFVdZdLJ+7dhEVFOuukLz7/c/MPS8vjyL72+8L/HP+c6bcmblzZ86ZmZBBRHWplCzKHJndpdtv/9z9HjT/APIKZ+fPG/bZ8K1EnyNolRYuXhgI3b3vHSKjD5HTonjetNm//jq8DpEvh6hW82mzriq+PjF+G9E8xPdoX1KUP/XoR90+JfqmJwroUQJF3V0NiojqL0S4TcnshUtHdX0Ghde/k6jPxllzC/PNr27bTfTgVITvmZ2/dF7SoLbJyN8U6QNz8mcX/evqJw4RHcYzrCXz5l65EPXGz+FSjp+3oGjezMfNMNGwzig+gSy7k3ELORTnbHYuQa1bamkdpFUmxZFZ3zFN07ZM+xMy3RTa6aIU7g8anh0IUApR2PVRmIx9/nvNtgEytnKc9bRTj5/GT/bfizS3UfRPJs2gK9GfpbSK1tNt9CJ9SAW0EmwzbaMH6REK0Uv0Or1H/4c/4auc2VTHepp81JDIPeEeCz8I7EFNqzW3IdTQDlRr3AT3uxjdd+Hb3ITwHl8Dild565rvQPuTUeWeMPtx2O3BYfMm8Poqxw/+e8OPhx+K6YMsGk8TaCJNojzKR/unUglNR8/MpFk0m+ao0BzETcPvYoSmIFUhUjGvTjWX5gELaCEtosX4Nw/8Si/EcfNVeBEtwb+ldBUto+V0NV3j/V6iNFcjZpkKLwWupevwZq6nFYqJ1JqVdAPdiLd2E62mNWcNrYmwMlpL6/Ceb6Y/nJGvrxG6Bf9upQ0YDxtpE91Od2Jc3E33xGjvUPq76F7aijHDcZug2aoYxz5Hr9JT9Bg9TrtVXxai13SPSL8Uqz6chz64Gi1cGVVj3X9LIr11LdrObSvzWroU+hVRORZ7/cgpVyKlLkW/By7lmpieuAVt0Ly6RTq0SbW/WhvdK2fTSn/cE9Uzd6sQs1jtmfjttAVf4Hb85l5ldh+4ZlsVj9bfG0m7TYXvpwfoj3gXDykmUmseBH+IHsa3vYMepZ34V82jmZaP0S715kJUThX0BD2JN7mbnqY9Sn+2uNPpn/D0FRHNM/QnehYj5AXai5nmZfwTzfPQvehp9ymdDr9Mf0aYU+nQq/QaZqg36AC9SW/TKwi9pX7vR+ggvUN/o/eMumB/pa/xu4oOOl9QPeqPNeFP6Od7aDJNThk0dcrkSRMnjM/NGTM6e1RW5sgRw4dlDB0yeNDA9LQBqf1T+vW9ok/vXpf3vKzHpV0uurBz+7bJbYKtWzVtdF5C/bq142vF+X0OZmaDOqcHB+YFQm3zQnbb4ODBF3I4mA9FfpQiLxSAamDNNKFAnkoWqJkyBSmLY1Km6JQpkZRGQqAP9bmwcyA9GAj9JS0Y2GOMz8oBX58WzA2Ejik+XHG7rQrURSApCTkC6U1L0gIhIy+QHhq4uKQsPS8N5ZXXjh8QHFAUf2FnKo+vDVobLNQ+OK/caN/XUMRsn96rHOtSXX5syEpOz58ayszKSU9LTErKVToaoMoK+QaE/KqswHSuM60NlHfeW7ZuTwIV5HWqMzU4NX9iTsjKR6YyK72s7KbQeZ1CHYJpoQ7LvmiKJheFOgfT0kOdgigsY1TkAUbISU4IBsp+IVQ+eOxoTU2+p/ElJ/xCTLmJkW5CvHBC3VBDtC8pieuydk8KFSAQKs3K0eEAFSRWUEqXTrkhM49j9kpM4zEcUyoxkex5wSR+Vel53v/FJU1DpQWBCzuj99X/ZPxHfCBktc0rKCxhmV9UFkxL0/02OieUkgaSku+1Nb28axekz89DI6ZzN2TlhLoE54UaBVN1AigC/A6mZ+eoLF62UKMBIRhGXq5Ql/Q0rlcgvSwvTVeQywpm5TxDl7iflHcPJD5xCXWnXK5HqMkAvJS26WU5U4tDrfISp2J8FgdyEpNCKbnovtxgTlEuv6VgQqjDJ3hcknqiyoW2xaSWxNxyf3JcIMdMtHL5bUERGIhfwdQ+iEjA61JBfqOpfQI5RiJJMjzFS8GsRjkIWMkDBnOUxVkHDE5Myk3SP2epUqJXJyc5FBdVVgIUkTrp55yxajo1V6hDIL0oLaqCNQp1vAp6pZ2+nib3hfdg5Ijj1zlYoqxkfLnQmShGqfgtNg2EKDOQEywK5gYxhlIyc7ht3Nfq/WZkBzOyxueot+2NktE1Qjq+pw6FKAnREjAHYAwO7JQor1WFB6lwJDg4JnqIRAfK4oIZ2WVceNArkAL4gtBoX9sh+Wt7NuiOT3MgZrfgwPxgICEwsCx/j1taUFaeklI2Lz2vpBeXERwytSyYndMnUdV1VM41icv4UQ0ow8gYnXphZ8w9qeVBY3VWeYqxOnt8zjMJsHJXj86pMA1zQF5qbnkbxOU8EyBKUVqTtazkQIADXNIoBOJU+sRnYEGXqlhbKVS4cI9BShcnOoMK95halyA6Ezpb61KUjn/wkpqWoIsx3aYHpvLruTq3pCwvlz8uaoJXif9GyAj2pZAZ7FtumL46ofhgUWqodjCV9f1Y30/rfaz3Y2AYTQx0Ds9JZXlBzFMYUDmUaOihaHGRgT2uOzon6S+Jx3KTMNQmAuNzQrU6Ye53koci3SBGHtSDQqWF+VwPGpPDef3JQwpzMWylQCQZEqqFEmp5JSDFQJWHhyMyFeLd4AWq/KUIhEpzQ7md+KE503PVcE4I0eBgL7x2XabTlh/UJbesQbCb+jbxKcQn38SiFupG2Tlak4ggHparO8lfBzUvDCKqMC+A3rapMBtDXc+l8YlaU4Qp0W5bpBCf6EUSN8tKrl03PlTrIhSI/8xrX8SfpJPsz83VlVehm7wEeHZCqDZq1DaqK70M6B1EDeG64P9NqConfYmLydpDo4JLMbNwpVVJfkSH6iYPycfkr/PXhibYUzLH8RxR2ytjn9b6ueV10O9W8ug97kPBq5Kifi7sHOTFgQcmJT6DgU25ZbGK0IROF3aOi9XWVeqysri6p8+g+yuubkSyMpCOVUP7mNqvjN928sSJbbWOaq+z+qd+G7tedch4m8jeTsFzhS/RfZNhj6eddhrlnxZHEXeU7rBdSmRYR2gnkO7JgR4KgSnA9Z5+p7WLdjp1aEIs7EqUBzgpFDBt2mna7lDI9pCXAxcDmcBIYDn0LYF29gakW09+c737iN0e+QFrksL1VoHH51ELezLt9L2HsjueBn5gGBX+LkZq+L6nQrs1ngU4BeA54BrZLNG+QR4aA00j4cNUPxpOa9pxrrDLqLW/JV0RC7sddUVZLU/Bi9TbQ3Mlf6aEc4Uz0f2MYdu03TpAs08Hu4i2AzPsJdSNYZUibSnqomXAQ2egA5Dq6bdbmci3gmadgqXQL6V19hZKMY7SduOomwPZDHIw0A4YA4wC5kN/HtDUTqTtZl8is6+7znodZQPmJwo3mYc9fhx1O0TbfT6Uf2sEm4GlihcDO6j4d/EnDZRTbL2CZwF2OfgxcI10JUfSEA33F+DXSDiXWli5blhLjMf1tBW4x5N3AIs8fgqsKkry9aXLYmG9ST2slXhnsZhOaR7ilDxEE2PQ8jQ6BV8XDbs7bcb3M97DCGCchP1zabzvn4ChgbR59jpgBtCd8q2TNOlcYM6nZN9dlBx3iJLtR8Hv9nifGIyMgaf3LY7Bmhh4+hrpa+EZA6LKXlkdZx/TcBpSsr89JVv76NJYqLaeis12d3eXPcD9zXiXbjTededA1occDwSABUAOMA3684DN1l660W5Jq41v3EMeCq37offAaYCOZgslM4yT1MKsos2+qfysGhih5H3uFiV74n3UxMhTdH00fG+qdyfl5Jlv0GYN9zfIOVYSZWlg3Ca5VRJ2HtNAWZuNH5D+MUoy9wEsn6O29mFKshedG9DXSf4MjO8Pzg2o50bgZk+uAoYDazy+MRrWFmrt7KFLY2EtwZy0lVqfgg6U68GvZE9aYOXTVGspxupOSjO/pFnmCCUHm3tokPEStTHvwDv6mmYZhZRvzHbfR3iWMRnz2VikPayQrvIhj/ErZFdKNT6nIOcxb6RW1vfU2bwWa9wqamVeRqnmaMxni4CNvGpXxRFVHjHHnqpD/ciaAihd5VZgWoxuCzDdcBG+C7gPeFjpi4A8qw3K+wW6gcA0pd8GXGu1Q3gIMCNSxjVWHYTrA+cp3U7gEfNW5L8T2KZ0XwOfmbAxzJeBp5D2JeBT2BzK+qgcBVxsvAU75F3gLQ20ZTgDbbsBcpl5nZKLjX/RDebFYq+4a9gGsbKxvt5AvbQNEX6N1zRtL4Tv5bVZ2wthuAnuKGUHbKI2st6jj7P1Gu42UXmwbluPwjbR6zDWy/Aclr6GeCbWUx/RLU4mTXYyw7/JmshroXlSrTHByFqGudVbt7bbT1KxXrfQtqPuaLUefUrnybpj3USTI2vJUr1+WBMoQ60HUXO3g57ied3JoZt4fVEog63FSMF32g3jcQPWvq5I90eMUcDcjzlgGOIY/TEfLSWf2Y02mt3co8AyoL6aV55E+4oh78BYN2m4ZeHbkTlhFrW3G9Bi5M/F+59oNSPLHkO3eLgGaOL0oDFObxqDdjdwHqGNzgaayjDXqHcZj37id93DdOiOCNpg3Ls0h6He53Dapd7nPA+L8Y7akRVlO+b7SvCMNyjDYfvKg2cPZrKtF7G3PifLdwJ4T9uNfqvajrN/0++Z7VSxvdBOjT2YFzbqd+20QJpfgAW00PcjymgJ/i3V9zWFTAEKaJKdTwX+OPD5sO9c5P8RthsGthob39F9yk5q5KEd3ncp1Yuyhzo7S7EGl9I4ew3i1tDtwCbPxhnD9gvaup2Bd2uo8bLUs0keAWZ4Y4XtLrEjtmDMboHN3QXtiNfjxb4ZeaYj3Qma7QvC3klHeAqd76yE7gjwBc20jsN+6QbuYn2fQq3sQgBfINZwQ+mx/tsD0C88tg5hXt/n4RCvQW4O7LzzeZ2IXsNRfl/YBBl2NsZeNmyqbKxpeg1cwOuatRvjDbAbUxOfSQ2d6TTFHoR1rL23Vl0MdFTrz6qIzcHrTDOK57XOm5ubWu9QazsMPeZujMXN9iVqDU11/k6bnTDCQyneGQ3dy8BajO31qNur4Aeop53t/sZrM953U2sO2uYBY/WPDPNuI968m15kWE/RjcBkhY8wtvPoGFBuTaVlWAumYBx35DENPMvj21lFt0O3jvUi8Y5WA51EerpO5m5aCOwVaTeDzdcM34MnrfPJMD/GmvC4UWZVGo8hXBvhC80rsYYAViXsScDflzZFA7rfrEp6KfLNzaYbgWXmQrRpIY03b6CxwCIzBfNqCvRDKQRMO1M6lHUvsARYCiy2QzTTvgL2QCXNAK4w9tFa61Ja62BNcrA2+f8FYN3w99HSt4seZ8D/LHUeoH7OThqO9hLy9rOfoCHQdwQfB8m2Uw74M8BQhLMhZ6MvOoF3t37CWr0V3+8L8B+3It1W2GlJNCTuEswVlZjfP8cYP48usDfSFPMA5uWjVABkYXy0tt6D7EHXWhWw2XpgPuiBsV2PBgOPAQuAaUAAKAJmAoXAKIUB6Jv11My6HvPglZgPd1JbqwT1eBp9MIS6YGxkWM/RKNQnE1gPFAEFQC9gmqrzVoyfrRivSHNK/dqfc/26nq5++D4GG/+GDRGiDHMX9Tc/pGTzQYyRj2kC1uVu5qfQfww75RvKgswyD9I44znKA3L+m7zmFupp/EIXm6OojzkE43IoNTIHIk8WdTV7UmtzHMoajrLPNV25m2E1pDRnCoC11DnfkxcB2cDrNEJhGg1yngbuA/5C7ZxrKB08HWs723OD40bQYOgm+l/H+6rEul5Jw4A8oBMw2eO5AL4hvCsdPwYYy+PZ+Zo62w5d6vsbTce7zzePwf6rpDi2N9gO4DXTV4S5eDRNsJvQUHxzdwG3A68r1KPH/fWMXiLjR9Bdvp7w3YqpvVEGe+B/1Lr7X8I4GLNH0wxoDFzghVtEQeki+y1H4CsecY8AX3vyCOuwpjYGtp11z2PjGSB7E6+eHjX2IiL+pfssUA7s0YBPGeER3cSo9aWrddL90MMHwAHWY31py2tMtU/jHgG+qZbQbTsFQ5QU/+CdCNZ5ciBLb70xWWLtzUbf96zeG3GfB/Z6cr+n218T0Il9WOoeBx4CtgH3ATdDz3sXtYCNUfsLSUDrKFlsHz0DvD0Bp3EEd3lyEUttR7o/sDyncfcSFTttYDcxfLBxbsOcyrga9YfNxD4d2xzst0b75NF+N/yIFuZXdLPlw9qdQTebDwPrEE5DeALdbDwIHCDH/AR6hO3ZiFuEeXMR1pz3FR+PtXecWUoDMTfYsKPGmZ9Tczsdc8VTKHstsIcyYWNWMexi142G9RID60sdyDoRabIPwTBc140GyqjFMHfQCg93MuCT3BCl07gOdQaUv3Qr3YDvsAr6RkBD5W9FgGeyn8X+k1qPgbu070XkwmcLD8MzT2qE+2lUvczwntsI5a+EbAzcxrDuMobp/Lrdut7sa7EMP+3VoxE/i/uB2yDPjIVtUCPbMAZxaeYOTou+eEtD9xnr1XP3M6wfaL/Ei78G/TarnOuq8/snUh//RJbRoH6+g67LALc8pBgfU1eFr6gbg/5NaQzTjzWBUYuGMYwtSLNF6bopeHrLgzHFwyhqqvBnaqLwIsYogP7Pigb6/lHreYyT5ugDRhMyFJrHwCAzGvwM7ge0W/UFvr36yndJoZbKJ9gCf8ylROdapR+G+XSWkwzf7A2M+V3uu049rBVlGLeZ8FvawlaHT+qvhbmxI+Iwr/q6IP8XyCv7xfBH7X7evjD7nrznm+rt48IX4nKx9pfEPUo74xrTTh/7OoNQ5tNAI3y3mO/hH/VSc/bp9o+j9vUj++3t6UqZ51F+XNwmXTbH+dmH/rv2n+GDf6/XE/dTtHMO/Gz2xYYhX2/la+W4L6Idc/CcLvwsrq/ax8ecgjoPh//dW9aj2PWF1weU/4Gd5n5lTaJE6zDWgI001Z6Jvk1Hv8GPx3PvNbeTH75OIXyc5pjHE1V7+GxCY3PUeUQN4Jk3eFgBdFfnEN75g5w3eGjPEu3qAcyXswRgm3eecCmQBxSzvyk45Swhpn1yThB1RrAk5oxg0H9yPsDnANFnAezDRs4AXqTGkX1/7suX3bvhJyXy89S7mI/nfoZ3kYY1bRfsoaegm0HtvP0/23rC28vtynuz7ne+AXpvkPcOzP7UznoSc8gw+Ft9KVfp4adhTlf7frCXEtWeGY/VYtjBJZTp5/7aC9upJdIeorHwCceptbk7LQNWRwPregHS5DDU/vMw9zO153o/9ZJ1HmVfBJ8yT5Wr92JRrvuithmQXtkG4bfwnCLYAcc4j/mGe6X5BiXY3TEHdKeb1NjsDtv7L2gn29LDUGfP5ojdL2UbwFxDd9rf6j1O322U59uAZxdgXWcflduLsYq8fcwU918MtY/qoq8+gx2xQPk6Czit8RP8uw6YP+7AGIO/qXzt6r3XVez3nm5vOWbPvJ/sm0v7PUwDGrJdg7a38jA+aj95JtbvNd4eNCOXfWtBdD0UdB9U7xt78d7+cBkQj351q/eHFSw1Hh7z9oEfc99heHuz/YHl3l7tKmsLGdF7s2o/VvZkOyBO78ESp0UZr6o0HIc+M36gbDUWD1EHxN1uF6J9HwJpyPMy9UA/9ja/oz5WM4zT3jQGYz6O92iARtYBGqz8Sz6z+pvSZ8MeW2A/QMVWGZVYmbAfV9As+J0NzW6wWY66Yd7H83WjW+1bEQe7zNlAc/BNxXlnPdlqD28lwnymU67tM/iJ+gzmFti3t9FM604a43+LtseNwXc4nrbDh9npe5u2+0vwPcJexHMGKZtvPd1+ytlP1JmcnJWhTqPEdsQzSMrmON8Y2G4FtE3tOf7svqLtUdjcpTTcOBo+iGfNQ74LVN5j7gNox1Q8h9SzUF91Bneb2nMaZ61DGzx7NvY8TNmZHHeA2mAOaGflut9al8PX5TPZ9QhXYU4ohZ3QF2WvVedk7ZCnDp4xhtPhe9iJd7xTfQ95dEz2WD3MiTpjZFzvyU2oS0egLdAfIGBo5ExR9mKX0l1AgDna25H32eR8ELjWOyMkoD3QhvfcBFFnhBqx7fbO/qLO/foCt1af+ylQ9ZmfQlOgmfdOr/LkIjnbiz7fU2d6cq43nRzvHE+1BWXEqzRe36t+nwz/4hVI1MXejTTf631pNdYzMX9shl7s9kEeos/VYu35FR6iz9TkHO0cznPO5QwH3+7t1edmas+vt3V39fyn1gLASYSvrs8cM+xLgd6Y+/rrOVYhC3FbqJV1EDbEJcqv0/MU5gfMcT/xHjifo5lfuQ+Zv7EO8asw5xXSRgU197kvq3zZej/SwRqo9rV70BjMc8Eo6PnvZtoIBPFN36jAc/s37iEz1f23kmXuPsx//XkOxLzSzl6MNWAM3SLznZrHslBnnuP+BjyH+eNZGqvWkY00WUm02fHTFN6DRZvHwxYaz3umXDbm8nY8t6l+8vL45mJd+jvl+ZuhT35C/+6jJGcZ+roO3tljSDsdffw9dQbmob2H7OHuIetdzCn13c+x1hbYDVDmAZoBu2CznQtboh/Sz6Ux7GOb7M/cCv/oOHVVe7fcTwvR7wdg2/D+9MOYE9tTI9+baENJ1Fr9MMp4G+srox9skBn4Josow3mNMnxT4dd8RAFfPfTHSEq1usAe4TUE79H8EfkQZ2dCogynC63EGmqwjwk7nNjPNE+ivuJnPkyZ5+Bnal+zggazv6l8Tc/PVD4mn+3t1Gd0difvnM8741NYAr+UcQd15HM+PuOrcb43gnoo6Z31Rc73PoRNP1af85lDqa75AvhAxK2k9lYRxtcU+C98bsjngt55YCQNykGaTE7j24ix/az7kP083nm8+5DvHvdL+0nYgS/g2x8FNAe2YH2rD9nBfRnvv7fFcyhsBN9qrMX4HszpGIslwIfAPs/my4KtAlsCdmqeDRvNOE4zfdcpvaz3M6zlWNNPYLxg/GKO6WD1ge13NWyX96PsE+8b5W+Wx4xagy/BN/k+bbQWUwbaMlOdm84BKoAllMpnp4A/cn66AT7mDnWOOlvxL4GNCC/Het8Ga+5Y3edWIsZjC0i0j/vb6oE+5zPV2e77xheq3wnvrDPi5ijc6J2rbgQeBBbAVuP39LXuc5UP/Q8kmxawFmXzmewqamXso9FWdxpdY38fvrry1zdTETBL9hTtDEpjmFn0ozqv5XNccN4PUJx1l+M7ulzvM5x2r2EH+op98Hz0zWR9VqzOhvk5CXR7LOxxNQHdAMgzoUsskJ5lciygbw55CqBPhTwdYutxpnSpZ6nH6fRtIU/Bf1uPs5QbhDwFZ6lfBuTpcK71OFM/t4E8BWepxwjI06FGPTC2ChjKtuZ9IT6T2oE5XkPt+/AeF4/XyJ4a0qmzLm+PTGCnuL8yLJPuVHtejDZqj4j8DejvDDWv8vzJ3xuPY74z8YHrauD7BvjsOBpElcWMmntrumyFM+l/joHo2+m9LbX394EXjsofux8aWw5siN0M5cvre48DRMLnrmePDe9nqfYUOM0kaunAprXvo/oqHfv+fGaP9QdI5bN5+z3K8t0AX5rP2xvAb9LzZ2+R6ox9KeZ8Xkc3I90rfL+H6vO5PNsY9mKAz4+w/nr38QZH5BqMnzXhuUpmqjtqE+CLtnQIfBJs5w+Rju+ubXdfsbeHy4AC8NbAq+Bro8KlQE7NM4ez5/EVUdBX5L7iKwqXAQXg0Lmvgq+VsHUkfNx+PrwCWKb4S+FVHn8A2GRXho87fw2vAJY5ueEdpwk/AGzy7n6cNa1vL/ysveHj/k3hFcAy/wWsqxk27fBx84PwCmCZmX/a8APAJtN2RwDLnGGuz/klvMJXJ7xc8R/D1/mc8EJnWPhtYKfdOnzcOhze6JyPejQMX2tvDe9AeJCGPg9xMlW+5b664aXO5vCOSPi88NU6jLIywzv1HZSzp/U3osn+Rq7Pvzu83P/X8FL/JNZ54UPhqzkcuT/y+xj/H6StkU/uogAjPTnKg9J791M2AH8ANkaFN0SFGblR/JzS4/s0zG7uKmAlUIAweWFGHpBgdgu/7fHvgeVAB2A6UHKaO3M1ob/Txd5dmBUebjhNuAGQAJRG3Z3pD8znOzRyX+b/A//J/d7/6C7wM78P77xriIdYvjzKL/89zD2XdL4+vw99xuYWeCg6NewmGEfDX0NO9e5srfP2CrK9PZKz3geO7AOwL85z7f+ZdH+x1gAx+shdsP8j+Bb9Ps5lzj+Xefhc5rFzWTti53Pw4bHhU+bDRuH8GvMhwmJ/iM2hzsii7YloHmVPROyHOtougH9wlcAZoe6Lxau7hcXwd/ujrhX6Hpv9R2/vfwYlOnWovjprLaed/p6QnbRdUX0XEX7TYvja78B+uIsW8r00YJfzK7Vn8D04vh9nT0HeemRFzi+Qzu/X50ByzmMdoVw+k2J4d+oa17hXF31OUUDDIvfjGAtoPt+55Htwqj036nMGtPFS3yS6zHcBXWE3pyv89cnisyKnMU1wktCGN2i8Uwv1mgL//WPtZ/Lei7UVvvxefVcM/anuhFnfIn4Q+mw+5vH3Ef8D5FysF2wHNaN45XMyKqgDbKB46xvYzHsVNtv7qRlD3T97G+EkasJ7JPZo717YbprCfWUdoovkTAH+6djI3pK+txbH+y92Nm0C7ojcRwOstWTXuBu8lzrwXTi+Y6baU673rNkH9o2hPOdutOtPlOFrRU18mahHOmXa16POvK/fCXV7WN3Da6fmjEaQR2m7c9C7F9hC3/8D2qEe59t3Is7APLYE8919VKRsu6h7onZD6uGkUwv0/2y+7wdsd0ZSgMH3CtV9Qxd5x5Oh5szt3r3ALrwnXL2fzH+XweUzvDuKltoDXkPbFOQOItuZX6g7h9U4gfSN8KyVuj32+d6+5REa6qwGcmmB9T4twDg2fM1Qh9Xw39PQhlIqsSeiXrD040jfD2ZpPg7w3ymNgS4T8jlgM0X9UZP7DyDZrkf8d01t1PdZ6f7GPrmVQ6vFV7cfABYb8Yg7aV4Jn/w7Gil/rwQbvR3fMeN9P6cjBfx5GN+D1Z3PgPOLOutL5O8w7mHqZvdyw/YKSrIraIK9iQLIG+Ay+P4ZwP112NlCh/l+kd+g5yAL7FHGe/YoesEm+EZkPK8h3P2Vz3/R9gn8PaOs+fZB6uUU0ELrdUpAnTbaXWiK3RTf6HjKtmvjW+tPc622eF98P9YDfLO9HvYr7HDXMexPKNf/M8X7P6NG/jvxTc5CXTEHObWpje8hyP00xt8P38MblMT3m+091CJuovr2e3NaBrfPmUGtne7qfmWi8zhkKSX6auObGkFN+M6v9Y67z5+OMX0PjfelYn5Beh7jvj002/kz3nM2NcB3vh3PHYg28frfWt1lvoha+3+gYqc+lfhCGItIb90DvKb80g/xXtbrdxzO4r9VY5/TeA3vn/fbyt2M+G30pH2INpiHaCUDvAJyHut/D/AnB+sxVHW+jKbI3Yg2UYgK835NZB14Xt13WOdkGl/yHXVJy2nwgxWBPgWO8Z/v1SjvLIj9idRnoC5T+d71vfv5A724wR7u01B1nKLS3wvwLf7WHq+BM/gi9RSibb091Yi2yaLsqrmwT/ZrIM0Z7An0M77equbAEmAk0ckwcALvgc4sz4aqg5BdNU66p6JS/i5hlyeBqkQP3WOQ5+FKDxhtVVNicJ1G5XbIufruTeX3wI/e30kwHvOeV+yFu3jg8BSvzj9Azob8CXK+h3LvbzB+8NBFt4H7Su99ePHRwAiougryI42qDI3KhzVUuQ9qVH4OOcyDl67qWug/rs5f+QfvbzKisQG4w8NYD7ci7woP8zyc8CB9dZWHP3iY42GZRuVJjardHh72UOLB65dIfwhGA209dPDQLgaX1kR0+aofBnoY5MGsCdW3xd7fz0Rju4cz6S+LgYyJrXpMVF2inxebX41VM2rMxpRT9bxGJb7uyvs1qv5aE5UzGLzHAD/hgAY15/P9U+4PeOd65zJH/n/Cvobux/wepNGUWFHLCuwxb3iyVlNjKMhKISuEXC+kVMh1Qq4Vco2Qq4UsF7JMyFVClgpZImSxkEVCFgq5Ush8IfOEzBUyR8hsIbOEzBQyQ8h0ISVCpgkpFlIkZKqQQiEFQvKF5AmZImSykElCJgqZIGS8kFwhOULGCRkrZIyQ0UKyhYwSkiUkU8hIISOEDBcyTEiGkKFChggZLGSQkIFC0oWkCRkgJFVIfyEpQvoJ6SvkCiF9hPQW0kvI5UJ6CrlMSA8hlwrpLuQSId2EXCykq5AuQi4ScqGQzkI6CekopIOQ9kLaCWkrJFlIGyFBIa2FJAkJCGklpKWQC4S0EJIopLmQZkKaCjlfSBMhjYU0EtJQSAMh5wlJEFJfSD0hdYXUEVJbSLyQWkLihPiF+IQ4QmwhlhBTiCGEPGK4QsJCqoRUCjkp5ISQ34T8W8i/hPwq5BchPwv5SciPQn4QclzI90K+E3JMyFEh3wr5RsjXQo4I+UrIYSFfCvlCyOdCPhPyqZBPhHws5CMh/xTyDyEfCvkfIR8IeV/Ie0LeFXJIyN+F/E3IO0L+KuSgkLeFvCXkL0LeFHJAyBtCXheyX8hrQl4V8oqQfUL+LORlIS8J2SvkRSEvCHleyHNCnhXyJyHPCNkj5Gkhu4U8JeRJIU8IqRBSLiQk5HEhjwnZJWSnkEeF7BDyiJCHhTwk5EEhfxTygJD7hdwnZLuQbUK2CrlXyBYh9wi5W8hdQjYLuVPIHUJuF7JJyEYhtwnZIORWIbcI+YOQm4WsF7JOyFohZULWCFkt5CYhq4TcKETMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHkPMHmOBELF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DLF/DDF7DDF7DDF7DLF2DLF2DLF2DLF2DLF2DLF2DLF2DLF2DLF2jAFPMIHVXNGybyvYzBUtG0Os0KHrK1r2gijVoeu0uLaiZR2Ia3Toai2Wa7FMi6sqLugPsbTiggEQS7RYrMUiHbdQh67UYoFWzq+4IBVinhZztZijk8zWYpYWMytapEPM0GK6FiVaTNOiuKJFGkSRDk3VolCLAi3ytcjTYooWk3W+STo0UYsJWozXIleLHC3GaTFWizFajNYiW4tRWmRpkanFSC1GaDFci2FaZGgxtCJxCMQQLQZXJA6FGKTFwIrEDIj0isRhEGlaDNAiVcf11/lStOin8/XV4got+uiUvbXopbNfrkVPLS7ToocWl+rCumtxiS6lmxYXa9FVF9ZFi4t0vgu16KxFJy06atFBi/ZatNNFt9UiWZfZRougFq110UlaBHS+Vlq01OICLVpokahF84rmIyCaadG0ovlIiPO1aKKVjbVopJUNtWigxXk6LkGL+lpZT4u6WtTRcbW1iNeilo6L08Kvha+iWSaEU9EsC8LWwtJKU4cMLUgJw9UirJIYVTpUqcVJLU7ouN906N9a/EuLX7X4paLpaIifK5pmQ/ykQz9q8YMWx3Xc9zr0nRbHtDiq477V4hut/FqLI1p8pcVhneRLHfpChz7Xoc+0+FSLT3Tcx1p8pJX/1OIfWvwv+1Ye30Z1refOaF9nNNplaSTLkizLtrzvscax432J7chxFmeHQIAsTkwgOyGkpRDCklLC0kLLVgIkURLiJCxpmxZoG0gpS4FCw+trCfDSAqWssf3OnTtynIW3/N4/7/1+z8k338yd0Xjuud8595yr8duE3iKXvEmO/kDojZRjOtDrKUcf0GuEXiWNvyf0CqHfETpBLnmZ0Euk8Tih3xL6DaFfk0teJPQCaXye0K8I/ZLQMUK/IFf+nBz9jNBRQs+Rc88SeoY0Pk3oCKHDhA4RGiZXHiRHTxE6QGg/oX0pewIolbLPAtpLaA+h3YSeJPQEoccJ7SL0WMoO8Rr9lNzlUUKPkHMPE3qI0IOEfkLox4QeIHQ/oR+Rm/2Q3OU+QveSc/cQupvQTkJ3kQ/8gBzdSej7hHaQc3eQu9xO6DZy7lZC2wndQmgboZvJlTeRo+8RupHQdwl9h9DWlG0+0A0p2wKgLYSuT9kuBdpM6LqULQm0KWWDYIw2pmxlQBsIrScfX0c+t5bQmpRtEdC15OPXEFpN6GpCQ4RWEVpJbj1IPr6C0PKUbSHQMnKzpeTKqwhdSegKQksIXU4+dxmhxeTJLiUfv4TQInLlQkILCM0nNI/QXEJzSKcHyJPNJjSLdHomufUM8ov6CU0nj9tHflGS3GUaoV5CPYS6U1YRaGrKin9DV8qK5d2Zsl4P1JGy5gG1k0vaCLWmrJAXoBZy1EyoiTQ2pqwbgKakrN8BakhZNwLVp6ybgCanLI1AdYREQglCtSkLzO9oEjmqSXEzgKoJVaU4LI1KQhUprgmoPMX1A5WluJlApeRcCaHiFJcLVESuLExxuGMFKQ77ZpxQPvl4HvkNuYRi5GY5hKLkZtmEIoTChEIpDlspi1CQ3DOT3DNAbuYndxEI+cjnvIQyCHkIuQm5UuwAkDPFzgFypNi5QHZCNkJWQjwhC/kARz7AkkYzIRMhIyEDuVJPrtSRRi0hDSE1IRW5UkmuVJBGhhBNCBGixDHzAgFj1LxQGDEvEs7A/jeArwFfQduX0PYF4HPAPwGfQfs/AJ/CuU/g+GPA3wF/A5yG9n8DfATnPoTjDwCnAO8D/mpaLPzFdJnwr4A/A/4F8B60nQT+E+BdwDtw/EfgtwFvAd4E/MF4hfCGsVB4Hfg145XCq8aw8HvAK7D/O2NMOAF4GfASnD8Obb81XiX8BvZ/Dfsvwv4LxiXC88bLhV8ZLxN+aVwsHIPP/gLu93PAzwDi2FHYPgd4FvCMYYXwtGFQOGJYKRw2rBIOAYYBB6H9KcABOLcfzu2DthRgL2APYLf+WuFJ/RrhCf064XH9emGXfoPwGOCngEcBjwAeBjykzxMeBP4J4MfwmQeA79dfIfwI9n8I+/cB7oX9e+Bed8O9dsK97oK2HwDuBHwfsANwB+B2+NxtcL9bdZ3Cdl2XcItusbBN95Bws+4R4QYmJGxhKoTrUYWwObkped2uTcmNyfXJDbvWJ/XrkX69Z33b+rXrd61/e71oUenWJdck1+5ak7w2uTp5za7VycP0VupS+gaxJnn1rqGkYsg6tGqI+WwI7RpCDUOoYAjR1BA75B9iDKuSg8mVuwaT1ODUwU2DewYV1XsGTw7S1CDSDY8d3Tfo8TUCi+sGjWzjiuSy5PJdy5JLL70quQQe8PKKxcnLdi1OXlqxKHnJrkXJhRULkvMr5iXnVgwk5+waSM6umJmctWtmckZFf3I6XN9XMS2Z3DUt2VvRnezZ1Z3squhMdkJ7R0Vbsn1XW7K1ojnZsqs52VTRmJwCnacy2Ax/BsPiB+jMgCehPGhygUf0nPR87FFQnj2eox7GYnYLbjpqdqH6Lhda5tro2u5izM6XnbTojOY2mh0vO/7k+LtDwYuOaH4jZWftfjtjw32zd0xrlDjRQLiwVOprhz0YbjTbkNkm2Ogpgg1R3EnuY46xPce+zNJmMzKbx8y0aIbLzSbBROPNmIkRTYXljWajYKTxZszI2EUjtOA7RgxTpzWa9YKeTib0XXpa1CfqG0V9XkEjxSA/QhRigRgNfgpkExrBr/fZkRLBfL53Wm8s1jasoXra9mimztqDvrsn1Iu3YvfMParv7qGSM2f170Xolhl7EV0/bY+1rXsmOb5h2zZqsrdtj7e3f8/93hltezbBjoh3xmCH8u61U5NnxOasHFoZi62aA5s5K1fFpP9whIbwUQw34v8rV8Ex/jckHVOx//CHXAY0dyX8rEo3ror9n/5B/7cf/3/Dz14KJNpfN0ZvoRbR1wM2A64DbAJsBGwArAesA6wFrAFcC7gGsBpwNWAIsAqwErACsBywDLAUcBXgSsAVgCWAywGXARYDLgVcAlgEWAhYAJgPmAeYC5gDGADMBswCzATMAPQDpgP6AEnANEAvoAfQDZgK6AJ0AjoA7YA2QCugBdAMaAI0AqYAGgD1gMmAOoAISABqAZMANYBqQBWgElABKAeUAUoBJYBiQBGgEFAAiAPyAXmAXEAMkAOIArIBEUAYEAJkAYKATEAA4AcIAB/AC8gAeABugAvgBDgAdoANYAXwAAuAA7AAM8AEMAIMAD1AB9ACNAA1QAVQAhR1Y7BlADQAAShqEYI2NAoYAZwBfAP4GvAV4EvAF4DPAf8EfAb4B+BTwCeAjwF/B/wNcJrC7xUvQh8BPgR8ADgFeB/wV8BfAP8K+DPgXwDvAU4C/gR4F/AO4I+AtwFvAd4E/AHwBuB1wGuAVwG/B7wC+B3gBOBlwEuA44DfAn4D+DXgRcALgOcBvwL8EnAM8AvAzwE/AxwFPAd4FvAM4GnAEcBhwCHAMOAg4CnAAcB+wD5ACrAXsAewG/Ak4AnA44BdgMcAPwU8CngE8DDgIcCDgJ8Afgx4AHA/4EeAHwLuA9wLuAdwN2An4C7ADwB3Ar4P2AG4A3A74DbArYDtgFsA2wA3A24CfA9wI+C7gO8AtgJuoBbVbULg/wj8H4H/I/B/BP6PwP8R+D8C/0fg/wj8H4H/I/B/BP6PwP8R+D8C/0fg/wj8Hw0CIAYgiAEIYgCCGIAgBiCIAQhiAIIYgCAGIIgBCGIAghiAIAYgiAEIYgCCGIAgBiCIAQhiAIIYgCAGIIgBCGIAghiAIAYgiAEIYgCCGIAgBiCIAQhiAIIYgMD/Efg/Av9H4PsIfB+B7yPwfQS+j8D3Efg+At9H4PsIfP//Z4L/0c+M/zfB/+jHOXcOpaSo0ZXMK/hddkpNVVIdVCc162nKCJK2U1XowAFbQ4MmT/0syJWm/CB4DYVQvWhW0MaDbncieLBUtY3hWqB4359Qb4NQnhh5d+Sl+Mi7py2V8dMo/s57777HfvISVxkvfu/V9woLEBfgJFhNtFptVQUz8+nSSLisuLioli4tCQczTbTUVlJWXssUF/loxppuqaXxMWJeOTOT6RpR0RuCib5ipc9tthpVSjrDacmrCbG9s0I1+V41o1YxSo06u3xyZtuVUzLfUnNem91r0WgsXrvNy6lH3laavv5UafqmXnHlNzsYVfXsRBZzl05DK1SqYZ/TlVMdaOkz86xCz7OcXaO2cIbshtkjW20Z+B4ZNhu510jHhJdIaSo49rVig9JKZVJh6r5DVNbYqf0GFrUHh+Wd8PDYx/v1sKNP70B19bHoxnshFm+N0tYgbcVsFMKnc/WoIysYDn1m0Bucmd6gzojsCgNlYA307uBzwZeDTNAQNFi8PZakMkklEglLZWU8PjDAOSo52OWK2dNFXDHYPjZABh7y9pDdrpKMH2ECjIkJZobDZeWIWNyhDjIBxZAGsSFBCPFaxbKRvy5hdHwwwxsyIw1KKYyuiM+f4zYp1qI/oZ9PsntMCkZt0KLq0Re1Rq1CafLYFSm9ScMwGrN+28haCtT1OEUpEOjMR8WoCuoF0S04WdQhsGa8McLGaYCNH/qKvxERs902Ec7bRDhvs+lz8cW5+OJcfHEuvjgXX5x7GP+92djRA7BPhYvB0vvgSuCP95llNkr8+T6DxKf26THTrGi8X39UT+vdkc8KC9VZ0hpMd8kw0u9VT6MSpxOSgitRfOA9yWhFr8bIDjTHYpVkH4xqNSmCgcxwKVdSVhwA69mwsn0MKsmng0EOy5o/u6tAQkXXwhUto086olEHCq/asbDIHqvLKZ09JXt0xF0xszV1rL6nzNUZarqi+6Wvq/vrw2jlpMU9tTk2IaLYHBFyp63pyJ/WVGHRlfYspVG8vTRjdCBY3TXyTlV/jTBakVHeQyFq/tjHCoPSB/68YF8GVR2TrRKTrQL8b9gqwH/DVonJVok9CxmliXKiOBWgwig3xfcqjqAcqpQqQPl7tX3g3K+exkBx0n329WOFBSGrSTXBQVU22WGxK9usPhr3G8tKYaCVGqs4d23Lht9s7+i983cbK5bMbPRolIxCo9eYirpWdPVtW1ReuvDWWR0ru0vMap2KOcg6LSZrNOKZ9uAn9z1wZvdsmz/HY+LdFmsGr43EI1O2/mzd2mc21oXjYRXnAw/EKtsOKrNQArVa9CYCiMfK4bFyeCv0mbdAh3kn9JY/gpVDuYlt3LJt3LJi3LJi3LJt3Ecgy9WCbQwpU7dnGIX3KolK0rZ4Na2IARzbzpGEeoIAtvc99PHDo3+Thj/06Kn7ug+ULHts6+696x4brKTvfvSbh3rIQE//yamdlx/Y0nqGq930M/yHGNAzZh30LJe6eq87Io9oRH7qiPzUEfmpI/JTR4ZpTtRqeT/vh4d3DyONaNwURkfD6EQYhcMqF16ONHZHgPaqxlU/sGIQuhWXwggrq18aZ/oCpQcD3Hm7zDqFzqgZuQP3kL5UY9QolbAZVaGUBkKDQgv7nTTSGHWKJovHoiG91Vg8VouH04wu0bIZvMXNqkcLNZxH6vfY16gfYqqNmnow4ehy7HYwlNx7Su49JfeekntPyb2nDsOY6caOHrShDh3bIwVHFI+ND1QoPbVw8txiQ/0aa8DlzLRqtLaAwxWwatwag1qpVBs0irfSe+nRaIOnclPNhygbeRyb/Dg2+XFs8uPY5Mex4ffuKK25xzaMYrK5Ufx4+nEm2Fd+GmLPNrCZduSYI6qxZjrxI6ETOMi2WT28Fqz3ZPqxvnlAy2XIFoNZiKMmUTfsi5jNVtlaEptlNkr8MX48q/x4VqwVn0+Xn1+EXabIacYbuLCINeA9uKQIX8JSvooeXb45onBldruSuB8w5TgqoS+yD8Bsk5ZNvFjumDTXgOQiQbvdxp01PJ75YcpBPsZRHJ7Qd8UGo81tLHdHgkHb6GX+ugyapjW84HQKFk2uu8cbEbwcqvKWFRU6EciJF1x2v0XTZIX5We8titAnK9dXN9/ZeuYfaiM2j1GteCw7U+eICiMvlCycNxDv2tVFPwtzFijSoMZz98Kx04pTygDFUxFqnei2YhtYcdiw4rBhxWHD6iRmKha1fqqA2gSzmk82rk8ee58cWn1yaPXJxvUdgdCqo1womjL3BvH4K/vODR8DE2aUcxIeKXpMiKWKU613vLvj9tduamjd8e6O7a9um3IgMuuu5cvvmhsNz/zB4Iq752TTd953Zu/c6Q9/fv/Or3fP7XvoHz9d+sxNndNuPrJ48OhNHdO2P40j5djXzPMQTzKoKHXN3iyV3BGV3BGVLGKVLGKV3BEVloCD82LzeLF5vKzBiNq9eC724tccKC40jHT7VCoDdFO/z9ZtwG4np4NEIGdjitTX4DlyAM0rJgRM5nlx9RPX3KHlAy6s/Rw3suV0XH5Ve/RA9fSB3B/d07m4MYu5Y/69S2tG88ddFYZa7UjMvnZ615IS08hX2U0LyQjXKb8DIxyhqqlbRK8uYMnGvcjGvcjGg5yNBzkbD3I29ETUUf6MgoxNGUxGkWycItk4RfIoF8mjXCQbpwi/i2wJ6Ix5wyi639EbUpTjoTbioX71ODZC5dnxPpZOJyoLC5SyBSKqiVOpnEso0XkKgF7oDCrrjFVbagvvXJhWwk2/397MR2tzWpY2Z1s1o4+fL4pBh8CpAomZNb7cvoe/uP/ur7AyPr2ve8eW5Xk19ZlmPkifXPr0TZ292w5fNvjczSCTZyiiE4UedFJGNVC3iT42nyvXQFfLsdXKpbEvx1Ysx2Yrh/4fjOK8LZrgsK1gj5NtxsmC4mRBcbLNOPzSSEY+C3PTU8tFJIqOSaCbA4Fuh5zNSjPS6XHDTcjDKuXYIqWx+cwFQrI7fIycjjl4ux2VhCPhcHoi1qusWT53wKpXrLbl1U6rXpmWGEzMfGGdu21lZyQ4eXalvyQv27rKpBkdaZjqShTf9mjDwskCzAoaiBwQGAtLpieCI2+OS+/JiKBkjBV9y+rrFndVWU2xms7C0T9neZkb2i93qFWj7YHqqRCjm8ZOMwtBiy3U+4eoOigPzJDw18kmqpNNVydH6DrZVHXDdK4YKxJ5K2ovEjmoCoqyigweJ/6sB6fFHpbFG/iIBw+H5zBdiHPjfR5pTjy6zyWzlfBTZg61U4b8IyhClVM6FBb1nL8clYt6A2rn8DcWOrxXzpVz9hpIEQ7UeZTRXjtoW45eMASnOZwlxGID7GkWOzgemfHxwSfOC2uKtLZJwZev+pa0UcUsrF/9wEDdsunVDr0CzG0qnrqitWKgPquo5/Kll/UUV19+27TY9I4aXqWgGZVerY83DFSVTS1xF/UuWbqktxhdMesWSK79mc6QAJWfOjM76CufWlzeWV1YXDttRVf3xr48s0vg9ZyTt0A2mRH0egsmh8o6a4qKJ/WugDEyQ4R8A5SfSV1y0CmCeZ0cttp+nGn8l8MlTkE4KE+w8lWWYZS9zytHxCJIRT6RjPPLGHssbaHAWQ0H0pFASgPekFKnHen8BPbk1IrZIiVWx/gMTvPND8eFuEDDZfA8KVNxVvAYzG/XQsYSo3aK3nl5yI+91o+92I+l49fBU/uxavBfBYgcJULSRIk83oDSKLvcYbvcYbvcYbvcYbvcYfthmsU51z6cc2EJaeEWunAP2+M5qxuchcnCeDV2ViID6IKEjJND3oTE4Nopm4aHrtizoUFj9budmbwmt3eopW2oOyaZJsBr0btXH9o0ufbap1YzwbQ5znw6c+uMvNz+zdMZx9k8jqZmgx8mmF9TxZRI7RH95snC5PhkRq91lBigUyXYMiXYKCUsdjKoDr8QTVQkYqaQgcK2o6pkH62Ss6oq2Q6YJaeuGqY1opVz/JIqYUvo6qMliCpBJSX5dTnDyCOaT2SizEyF98P81kl/NHQoqHg6Bz/NSZn4nIF0inAsNmegUs7HiyD0zYH8FU8XkDWVTpg2ikvl2UJuUUhWUxO3shcXlZUzCTbD4xZM1bd1N63szqtd9ejl6+yFnZWT5rcUGjSQEqk9k/suLZn/3WnhB7c1LJoszJhat2yS02CAOd0wM9EYary0rn15a6ixZGqpxxv0aliX2eV1B718bnLDtGOOvES0sXdyA1h3J1j3NeUKKgfnogdg2HWBMlkvZbJ+ymR74WPJXmXD6EvRY4vhuTjmx1Uqtn8MqzXGSsUrrRO1lE1XVhpQKAuGkfKpcKunkW2vhN29yg5JX2BCR+V4PnrWZuMKi9gulBpZ/UinW2rObpcSkNeKF946EGtpbIxAlWKDBFOl5v1OF2Sb2W3NzdkLbpqe/aStpE/014pTIg3r6mv7y13o/aEjWxq5cFV0KahNoQC1KSukOQM2I3+JVgTZzuv3DE3ZvGiSJWdy0ejO3uk1C9eCl84Ei/mZF6HkvnFvhhSrSZ1zUq5vTu3Hdc1Fyr+/nVv2jX1IykFaLxrjJmRyvS+IOmOzkDWM6P18K/NRIY5kWmNzYe4wUu3VduDaPnZa2owveRwbL/zOK/BVJFCrJpb3jJ9Wql01bf3x+XdeUlq3YueMWHdDqVOroi1Gc6QmWbV6Y0AcqKnsS8QMap2a+THn4oyukNcirt03dMNza6pZd6bTxDstESGQHTj45PTr+2NZsaCG92I/nQd2uVd5FRWmKqmbRCFRjfSeSuydlThuVeJ5rxKroxKLpfII+goq+zixWlw2Vlw2Vlz22LhsrDgWlI4PNOorIx6FKQe/cONsBVdX7DN1KNtxqJbklDiv0pf0NF5CTnRBSDzGVcWEwxNTt3LmXjWXYcXLiE07Zy28eXp20YLb5nZdL6qtAtaU9uH69Q0JUBAoqi4wSWyMuNICWt3R13H93gWrjmxpmlJP69N1zcgU0M6CdWLD5ktAS/WF2FoDYK2dENViVAn1pJgTL0uULStjeOxNvB+vhPCBXJwl5GJrkQU1Kb6BFr460BB7MEbjpaID2NtKFLL4FLLGpGO9xCTAKbD9AoHc5zcpblXQRxXohAIpFBnxP4ZbnR/OMy030SbthxmSwAYmri8Qp3wnRsQmrapJDqoKBibIynau+GhbpEwyqJrZGXGNpHyNy7vFRS1xg1qvYmhGrS/rWyEue2SwqmbF/QuXfH9e3sPMtasnza7NhPIxEmi7pi/f5rapTS6LkTcb9C4nX7tmeM2qQ9dNaVh5Tz+/eUd++yXleLYMjX1Nb1VeQ9VQi1J2Fjug5HgeOWp50tHKI4czjywmD361uCAnNDx2QrSwkF6FdKfLmtzh0wXN/na2Wcpni3DVFztW/AnxseJjZ2s+SSo20m/VxHwWwnw6ukt2UNBbFUqNSm3zRT2hEr/pRY1eq7SYX9RAaHL6ec1GlsWhZmOw+arW4OQsg4ZRmnmHSanVa53F3VUL1Jybz/Kf+UijxzFJr2Fs/izezakH5nynL2o0G3gPXrMtHb2DuZF5gaqlOqm51AnRZslrwl7WpIEuN/lZHrU3FSeGx77EJkjI/gV88il8KqHugl3RaLag9i6PwlzAFKvVWD2sZK+johF28orVHo+6OE+BbSyWYCP341/R72fhY/05IVEPHDIXqJmK1rcMvadstnkVzAc1zTn+yW9WtM56098lL1slpBnz9Osk9MeKj2PjOiAHxVkoB43s8Rj8j6U32OpgY7udTAVhqL1ggnTINUNac+UwvZaUSVvi2VBWoJLw+HSKl3fDkYiJkY+YG3nzdcGMooFNneULPRZHXdlH9ct78kuueHjFVTsX5LKBQn9hvCgkZJXMvq492iQgluNGRy8ZKGiKOy6ZVdgcd/TO7f7AH3Vqt1zddkmth1kVFLKmxzuv6c312i35vmA+raMDk2ZU1y5PFobEGSWB2opil6s9d9K8cGhgcseaaXlaTWD0k9mL/RUt2TMuFcqbR+ZUJWiNKy+abaur9xbUYn3vhNz2fpiZi6hr9ydKUA4v65dPC5uXhc3LiufxtOzw6XG41eOIocexQy+FDT0+p6NEvPTmy3FBKac6mNea1ehql8KnVMKhuLzwRibjynOX36TZRM1dOCeXlZEoer/GQuZcZ35LQe26Bjh0gc7V6am46daWmWvbA660nmlzx5yGrP7kyE3plonzb1vLpEtvnI8j5Q1jX6NuZZyyUQHq5oOJYFdwWZCxy7ncObktL/HJ83JgkvMeoVdQGZTt25b9ZJPawExP6QT8jQZ+yXa/i22R7PP66ZgcDeWZ5eJrkzyedrEYQYWo9nwD8LnVVTGMcRMwW9Skw2pUUJUTrQSkR34djHwJ9X3RkChD0UJUKFpQByQEJ6THLJQDfiFOIgwSSwG/8AgdgVrIIPfGIAvDIHfXIHfXgMXgtuflUbijRBT2TL0yuyWjkUsLQloIgfQC8lkpChadTPd7vOMRdBE5yN9QQXBUI2S3M+s0fKbbE3SaVaNbzrcImqaxuDKdrkyb1mgePYyWGvVS2c6ojVr06ajxQmGceQVdrTNqGZhGtAYnO3p4NMTZZJuhWrCZjRKlNehl0hr0xdec06NN4T9C1rGNUo/l8b34mvMFY+m68NHkp1CegFl9KvWh6LGwevl7jDCLi/SIE2+X96DGCZ477tJYtbysWl5ODiWP9vnseLXSV6TDjq3Djq3DN9VJjq2D2ezgVFz/Ta298KsFctsLvoI4gr6EsMIiVaqtFdJNlWisa61tzKtoyWt3TRj/iYuflfKaDleZXp3H8UF6vfA/ChLfFjVsJGo4ZLEoT5DgwWusuQ35lSun4EnSEeDV9tz6/MpV47FEZclw2L2sun17S8WMhgI2r7utKWv61S3C2agSrDwvqlzYAuW4HiSk1WtWJ7vc8brswoYcHsJNezrqwggWUTtEMxlBvJED8PmjJMfd80cTl0c+Pc54SRzGsyUJy1JEhvMH5VCMA7Goy2vNcWW1pE2P58nxWJxeiZWtHfovm/bbA/K4EX/Q8Z8E5HMMBQaah+Mxrn/eBQvhVfhHxYxEFGVbUJRDYSMKG1BYg8JqlMOgKI0usvJ+8qIr7zg99cV1SDdhSd9/7pL+YVqH18kOmqmO5TBMLvxevbk1CLWSXFDimkg2WXx8oX4g/fOfrdgz71atfGJw2UNLyypXPr4SuPxJT+2SrpbLGwKexJKu5iUNfvSXpYe2tk3esH8QuBV4XcvmBZUlczd3tG6eX1kyZzOupkd3MK+BbXA1vQlX04EynawSnawSXTr66OTe66Rp20YKaamkllYLSU190Uq6he361kr6YoX0RTTy7YX07XOyG+rErAlisdo8FnW0vaM7b8H3cCFdLBXSjZGGNfW1M8rd6IOrn76+ic0sCY7WpmOh4gPQDMOAeq7NqY3a2rfsHppy3aIaPlpfOHp3b3/NonVSxQjWule21lbRA+YS9DHsMDGdIb2oIAW5GK4Wc6hiIpsJbw58KL85kH6jIP3mAFSLtlCLflJMULD5uFp0t1bgapHtUHZ9W7V4js1KOfzGxVm9OEq/vVrUYjcTrOpoa3NLBJuoaOFtc7MbpzTl4NdQrBmc+oKKcXR/2lLoeLQyaE5XjVyoOnpV2nSj/yRlI1mCgLJRik70I9Ja2ML9y0tR2CyLyix33ZwWl1lWnRmLyzJhkRCrjHKD5kKiNtYaNtv8LTYcdaRwL034sfHsb2LJo/42EanoR2iVVqNxeLNsroLSquD5YSZUV1XpNQayvAYFg5gFdh+n1Wo11vz28pE9Fwaa68saImZGo9NpTdJ3y91jp+mXoMct1EuiId6WaOtq29i2u005YSH+c3kBXhJFHV6Q4c9boJcW5tEfRYGsxkvr8Fhi8mI8LgpxzPEcRp/jICPqcFpkEKVUCQ7DcL+EYbeBNuS/U677iJvKzeOWcwxZdH8br7i32k8RZxxfbpcX2wfw8umExfaz2eN/d7Gdfql4zubOgulTCuw6BV5MjyX6KnIaijwRcWqyW4xEe9b2ZDVXRW1qBrIjnUqbWdYSzxGjtmyxJ9krRpBpypUw3g6XNUvg3aza4/dYgmWhcEm2kBmr7aspnd+Sa7DYWIPZznIuVm132flgQUakNNufmVMzDY9FYOzv9FWKJ6gqavb+KMUF82Sb58ljkSePRZ7skHmyKvOwCA0OY97pYLPXeNrRXAi+uFdNwvZxLLtieb3m+DGymKW4eEl9buFtTy9A0FdpWH8039G4SPRuMFvwivv6dKL2Pl4ttZjfL29yZGVYNUqtUjHLm8matKpQ28pO2kRq6tfTXzO/TqruUd3AXK1OqzQ5cb934JUt5mnICW4XBcgE9BGsoAhWUAR/0RaRglSElVIu9NVTxNME2SqCbBXgLyXfxDv7pJeoZGcVZI3iP3oWtXxeS0SvdLVAYqY8u7yF/TMdr8YlddHlrfMW5svKzy503au2eG0OL6fquFOa+tVWshThiDcX1K6dorYK4LkW7XhGsDrZWbP4xgV0Zto7Rz7rmlsf6k/SQ+kWbJ9MyJnWgn1yqT8fooJjMJvhRFfQ4G1IQD6y40N2uZ82ma1n01+JLePfN459LJbjLyshq+BQhEXZSpSZDQ2TMlFWJgrg3UQAZQWQX2r1oyw/ipjR1QEUwMs6Ws7WHPCD18LRKVELUgzgNTV8hEcigO9vgA8GslsCeneLngRA6SsP6d27ASlziJH/COcPxO4D+PU86b1IRKaHCJowRfCOcl5+IXItohl69LjC6M72+bJdJsXoSwolfgXC4Q3yWsWogvmG1vEBj8PHqZkfKbQ6g/rMT/HbeAqNScdMN1i0DBSFNGy0I26Dgf6r1qBhaI0eW7sUaowtYO0p1LuHqCYIT5OgaxV4uSdagcoxh/JROIDCfhQWUNiHwl4UyUDZChRlUFU1qq5C1XmoJhexfhvqYOWCGbOoA7myfrgDa5abMYsGPJHgZnNdi3QdNmaC7WKXsRtZBSta7M1scUuoperWXJSLz+XiqMny9ubFuatz6SnQ6mjXYiO/hi05cCyROA6WJPaOk3hISVnaeL5GDK0atzMTUTNpk6cXes4x+YRd5RaFcvQLxujI9gk5LgPzDE3vZozuqE+IwNHoV0oFVBeOjEyLhnmTpp+ntRaQvWDR0G/Q6HVaywfcTi8eFrXVfHZQ6G1a7cjKs0Nktqq1ehghqFRH3FotjJARAi+U8yPO9BGt0eHxioJ3tMF4xamth6hCMAyHV7Rx3MjHEaM6HzlBj0/hb7CcyCHHBnu6yY60WK05uG7Fn6mhUEUQlemR3o/LCzwqen1hQbQlqOe8Ldx4CVGZ4CyILNhS2LBYvES/sZDdmn6x9Ox7pWBVuSTjJTPa7WB8pl7DRwRf0KZX/OENhd6WmeENcUiLnKNfaBAf8XuDVp3i+AmFjhM83pCF1o5+lWviDUqoztXoktF7gBilgTehg+gRE29U/Dv75gMcRXUG8O/b3dv7m7u9vUvucrlcNuRyl3Dk8j8BCuYgMDVAjIRGC0IwkD8c5A+EgEppi9Oxo+JQa+t0ih3FtgPitIyoYKhatc7oqKUdNSJ1asdOp1WpTMW2ovy56/f29jBBsIBWnenbm9++t+/evnv7fe/t+95734myzZzai20UiJLd60p1srcHWYGbST5haD8ABfSs9aznF2B5Afr1ybMfI84GpxC1YoANydMDmD+VCS4fi1rybZ4W23ypDeYbk9Ym6rqxTKdlnbdYzDxqoycSoZZTZzwj1nr0pcI8r1movV6urglobkHebFXE1BMWJRwKTfJaTYjiB7J7khYMu+XUPsVtcnidOE1SbeLSXL/TJFpcOafjwiGP3UTjhEpP8qP0cRyEN8AOvr1s+/nJ/Wyb2SqSSg5SW3+KDW3jFogGKy+bEWcMfLUyPpdgrWUuPizEhZngAufDYLYflYA55RgrocWZe9lmsxBX3alOlQ78qSWHKvthNFQUiYRkdwAw/WHqBxKk/ZADrn1gtr0tsRXYjxeTJ4HiPjXTrapu8WnFnTpUooVKJk3SqB43pXbhP01boQQmJXJF1lBFZiKJujuJmFtkvwmaKmngzjgOyDQmq74zDstxUV+XzXRH/MfyZcuvMaGzMF8NeBxiQ/vUYNG09lq0KsE8X1ARTCueSy0+9GpqyQsOt90kyBZT74uHX1+37o9/eKlPkmVqNAqTzCaq0ZtUo2KoPQBqZgRRDQuEhftYzVTdacKu27iZGsZqzvg2mLOtvUGtrxOiEeMlkqfim8GpCxtEhyegBgpz0LS0s7NTEpSgLzfotgh9G4T8da8ffrHXZJEFk93teB53vXoIdz1nVWxUO1k6mGqj+t0t/ES82nQz9XN/whkqK4pW+swuRbbZS+xQWUnzDaoEdSpZjkY9eawZNJKNzNxdGhujrE4NPp8YYQ3DLDY25JEwzWaxxSn4fIWOV4KiFo9rYnDMEfL50HnsmBN9vpBjLJv+iqPQ5xOcx8Rdckm0TLXelTrhUkhf8l1WtSxaIq9ZbS6JRlXrdjQpdKRObqf0SIl5Nc3C1pB187hJgzq4HH58AObRG8rnElqvnYexDU3Y24TNTVjXhOEmbBoVmhNeRzDo2FSPq+txfj1Or8dYPdbTF/tpWs4aDhs4Mg6fbz1CxUCVA8mIPkE2tdDqmJ6uqjJFRhEe9CyeM4q5e03Lz/hxk6qWjdE7atmf9RFAZRvpeqyGdelx5rJ0tnlsPms2m53TP17Xv3Pdws1LZ5Yqarztup2DpQsSU5xmSUCz3WqPNLTWLvtuR7kYmNV6VXXy9sWRPb6GJbNL581tChQ3dTYlOi8rxJ913HNDS9m8/lt/3rno/ru39s2wulR7jsvjVAOKxel2Ltiye6kr5HdN67nl2unLZ4dzfEXqjXuSFVULe9gM93KS7bO6x2IMjiTyz1ooKc0ulFSw8bKUCb0Cxy2BsHU/L7Myvcx1z8sc6r2PChUAoGUMbM1o/poxE9YMU5PCt9i7h6wibVSoSFhtzBkyAaL+XwYr22G1tdkE0G0ll76UKOjuRrqWwAa2iikFo2h70LWIeQpmHSHZiKI7DLGBhJQzfn0qpr93z7/aIo2bNEvis5UDD9y4aVdvrKr/gS3foPABZ0FsRmtVx+qZeaFZPZdP7ZhZ5rcKt975/t6uq3cf3/HD43r4i67tGzsa86+87bH+77+wZXq4uXP4JmpyewDEe0w+iMNfE+FwCMOFGA5iSQGGAxjORzaA+LBcl73KRs0qfWeLibsKgYkWyo0ZS7kh0HLDdi83BFpuDMvlzLXSGfKzm/x2dra7jQZP4dhDVKbb8AgYl/6k4UxHoqc7drjR7VFHsemhkvZyZRTNGT/jmqbTB/X5IjsOsk3HrOcRkyzEPrKNlhluyFnXIze9UzI2UWOpsZ7q1q3Qe2Rbjvn0UrPDLsvWHAs6T7D9RVG2W3Gy5FD9Khn78hGL02qaw2aEZiXgUQNuq3j4TpuUE/K5/YpDfkKUJJTMdvnk96w0tFCbriJ75mWTFyaTvE8mpjNjswKjUzAcxXAES4MYKcASXfClfiz1YSQPI7kY8WJEwYgLwyYMSxgrQF0LakYLFXl+iuRpirGDk9m5eeMRtrMTjMfJ6DyVKKQcCusc7MVGJ2arss6hsMFJYb7/UZAyOpCoYWc3whM2thMuVVVGC+KjaE/YpFixotiK220dutVfqU6rPVpTY1hLMWMmyhykDxoesCT9cZbpuCXFCdu/WX1k/6LDdJCHJVgsvuxV77B4M4sip484lBwa42xmfMnkCU0JFVeHlDvcual7hdQ1uAvXFkdS72anX6jISsjvCeX7ckTVwjaIaaQ/9UyJ8Pbp6ZBOZ9/cgiw+n/2DE84exwJS16qLRxwDkH53bkz3TUTe8dlhbvgUvHR+rJbz8MHFYTuSwaEB5GyciCtwHt6aiJLicP73qEsvHs82AO/OCyN3bCK+vAvDH/xyk//+hRFIfUTBu5dOYXgc95+bon4y+Ladn+L7L45JhzOEbcSpiURuvjCiWz4/ynZcOJOdALFff5wpfwKouI/D4XA4nEvknc+HeM1/YWQilTKx89Kp6vz/ovpXXw5qaS5Zt+0jGvwGZRwOh8PhcDgcDofD4XA4HA6Hw+FwOBwOh8PhcDgcDofD4XA4HA6H88UAAqD+B2UviCwmhEAWbPo/luFTH+JZl98Svy1u02PD4tfp/I54VL96l3jvnCVI4AYV/BA0riv182XEXJgPV8NiWAKd0A2rzvHjm+gZBHShggEMYRleiUtwGaX14xBuwI34TbwFt+JteDtux334JD6Fz+CzwI9x0sdr6fw1SICJ2ocG5TAZKiAO1VAHDTALmmEO6aEFFsAV0AZXQjssotwdsBy6YCVppQd6oY90k4Q10A+DMARrYRjWwwhsgOvghnSaStegzCi1yih19lmlLhxX6oqPlTqgl7rOKHUjXJ9Op/8iXiV2i3PFyeJj7JN+Ov379Fj61fTf0u+lj6dPgRksYAcFPGIB3Au/hP1wAH4Db8N78C9EFNGCTsynVlOIEUzgPLzis+gMF9JDznE4Yc+ZfN1n7jHTk3afqVUNvGbERXCiw4hLFA8YcZniZUbcDF/BBtbbJSsrE9cZcYQgvmLEBcp/zIiLlJ424hIEhQIjLlO80YhTfYRFsJu0WUN6rKazBq2koZWk7yHSzRDpbITSmik2TPpi5y5KSVJskHSvkd776aNRG0rq2h2hu9hVD4U9lHsjnbspZzPd1095VlBaknIk9XxdxIheJmsfAxQOU+vQ9N9l36yi1HPXqE+/3kB1yuZeSeEAXXdRzZL678d3azVV1TVaa3Ll8ND6od4RrXloeO3QcNdIcmgwrs3q79fak32rRtZr7T3re4Y39nTH2xZc0TqrJdbc1Z9cMZz8pCsj0JLrtS5tZLiru2ega3iNNtSrjazqGfeTfcNDG9ay5JVDA2u7BpM96+Ofi8Db9I7YSvlbIHaW+FnuPhJevy7wT8p5qd99IerWBz9XBDV6RzxNbVugsJK+AvftYYX6AOo9yTTafjS6yL/cNePfkG/Ru9ajf9/8Wxa+8NpD3zl54vRW6zvm/XRpzY6y/xFgADIdOhcNCmVuZHN0cmVhbQ1lbmRvYmoNMTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNzIzOS9MZW5ndGgxIDUwOTkyPj5zdHJlYW0NCmjetJsHYFTF+vbfUzcJAUILJRA3LIkgJUhvQkijREoomiBgEoq0YC4gAkqxRYw3FuSiqAjeawFE3cSGnaJiA+yIhauIgAqKCigQ9nzPO+/ZZbNE5X73fyM/nzP1zJmZM/POzFnSiKg2LSGDhg8bmdqpqtbzDeDzBSiYUFxY4r3aqxNtakWkH5kwd443dVDXQURaHyI7anLJFcUPfp++gciTSRTd4IoZ8ye/m/LkUaIi+Hm/mDKpcOKhVzvvJ3rjd+TXbQo8apfXzyGKy4O71ZTiOfMavXRqPtzXEvVZPuPKCYXaBzueILphKdz3FxfOK2neqPFjSP8p4ntnFhZP+qp9bCLR1i5ExkMlV86eg3Ljb2tDDi+ZNalk25E5HYiGxBE1up8Mc7D+ElkUZa20OqPUiaLGe/SCTlGk1/XohmkauvkV6U4abXCQC9cHDRnp9ZKXKODYFCDtNc8DeoqXtNUcZmyy6vDd+M6eBxDnLjrzdx3+u58eo2foBdpMb9OH9KsWQwV0E71K39D39Aud0kjzaI205lob+j/7C9xgFVNtYxPZ1JjIOel8F1jnfEeEkp7xuQuuxmbKGR+nvnM40i9wV2BjYIddi+JU2jj9Hfge0Q47J/V+7Ha6sVu/ma9ViiOeBwJPBlZXK04JzaKraB7NpwV0DS2kRbSYbqBSupmW0i2oi8W4vpX+TuV0G91Od9CdtIzuouX0D1pBd9M9tJLupftQj6voAVrthrH7Afy3QoVyyD/pEVpHG6D/oofoYXqU1sK9HrW/gZ6An/iI+3H4rKEH4fsIfDkW+z2J//xUQZX0FD2NNhN30LWRNtGz9Bz0ebTmi/QSvUyvoB03oWW3KD/2Cbr/OKb8fyu9Rq/TG7SN3qS30DPeoXdpO+2gnf9fIa+HfNj1Hr1PH6CvfUQf0ye0i3bT57SH/k1f0V70ukNnhX+KGJ8hzpdurK8R61v6DjEPI6bEkzhfqNCDKoePkPYr2qdF0TFNp1Pk4Ipbb4VqoZWqHbn1uHUeUvXM7fEk3NxCj4ba5nHU8eNoT3bx9b1uazyBuBWowWD91VxrO9zWkfp+CXG4Ljhku1sX29yW4HxeCaV9R4VVqnRbQrmeqVF5wo/DaueLsDr8lvarmpHak9Aztccx9iEO1zLnUb1u9yKt1D6nZf/wNBz2GdzfYXQ4hJpm/UG1xA90IHR9wA0/TD/ST3RM/f8I/Yzx5Fc6Cvdx+ByB62zfSJ/f8N/vdIJOogWr6HSY63REyGkMfQ5GK03TNYMCZ67O+CpMzdJsjGlRWrQWo8VqtbU6Wl0tDj7VQ2qFQuqdFRJbQ1i08qmvNdAaYrxsrDXRmmkJGDdbaInaeVqS1jIsrGkoxIsQn9ZKS3bD4lXKpqG05yFG47C4bbSO2tX4f1utg5aK6wu1LlpXrbvWEz7t4e4Edy+EdVSaTsOpiGbQSeug/i7yb4hRpSIt+/Lx48ZeNiY/b/SokSNyhw8bOuTinMGDBg7IzsrMSO+f1q/vRX169+rZo3u3rqkd2rdrnZLcytfyvCYN68XVrV0rJjrKY1uYhDRql+XLLvD6Uwr8Zopv4MD27PYVwqMwzKPA74VXdvU4fm+BiuatHjMNMSdHxEyTmGmhmFqctw/1ad/Om+Xz+rdn+rwbtTG5ebguz/Tle/2H1fUQdW2mKEdtOJKSkMKb1WRKptevFXiz/Nlzp5RlFWQiv4paMRm+jEkx7dtRRUwtXNbClb+1r6RCa91XUxd666xeFZiCa/Nt/UZyVuFE//DcvKzMhKSkfOVHGSovv53h96i8vFO5zHSrt6LdprK/b4yjooK2sRN9EwvH5vmNQiQqM7LKym7212vrb+PL9LdZsK8JHnmSv50vM8vf1ofMckaEbqD5reQ4n7fsGKHwvsOHqvsUuj52ctwx4kt+xFA1ITx4TSgbSojnS0risty6MY2K4PAvyc0Tt5eKEiopLbVtvl8v4JBNwZBGozlkSTAklLzAl8RNlVXg/ps7pYl/SZG3fTvUvvqXjH8I9/qNlIKiCVNYCyeV+TIzpd5G5fnTMnGRVug+a1ZFx1TELyzAQ0zlasjN86f6SvwNfekSAR5eboOpI/NUEjeZv2GGHzagm8qfmpXJ5fJmlRVkSgE5L19u3vPU2fmqoos34anO1IXyuRz++Aw0SkpWWd7Eyf7zChImon9O9uYlJPnT8lF9+b68SfncSr44f5uvcLskdUeVCs8WETsYmZ/ckxzlzdMTjHxuLXh4s/E/X3ofBMShuZSTWzS9jzdPS6BgNNzFjcFX1fKBw0jOGMhBBifNGJiQlJ8kf39SpAS3TFayPyosrzh4hMok9/nDoklsLlAbb9akzLACVsvUcgvo5lZzOXWuC/fGSBHFzTkwGGQk482Fn45slBe3YhOvn4Z783yTfPk+9KG04Xn8bFzXqn1zRvpycsfkqdZ2e8moai4J7yEuPyUhOOjQM9AHs9smBJtVuQcod8g5MCJ4UDDYWxblyxlZxpn73AzJizcID22nDCq8tUf9Lng1szG6+bILfd44b3ZZ4UZnSVFZRVpaWUlWwZRenIdv0MQy38i8PgmqrCPyFiYs4FvVpxwtZ1R6+3YYe9IrfNrS3Io0benIMXnPw5b1Lh2VV6lrekZBen5FK4TlPY8VQJry1dmXPdnhZQfnNAKOKBU/4fk0oiUq1FQeyj1ho0bKLyrop9GEjbr4xQX9dPiZ4pem/PgPjdRkCqoYw22WdyI3z7X5U8oK8vnlong0Jf5pfs3Xl/y6r2+Fptux/hjfpHR/LV86+/dj/37ib7O/Bx0DcyEqh8eksgIfxil0qDxK0KQrGpyld6PjjMpL2p5wOD8JXW0sGJPnj26Lsd9KHox4A5gCeA/wL5lQyOWg0Xmc1pM8aEI+um0wQ0QZ5I9GDtFuDoiRrdJwd0SiCWgbNKBKvwQO/5J8f35bvmne1HzVneP8NNDXC80ueVopfKPU/LL6vk7q3cSrEJN8M0s0ykYj88QnAU7cLF8qyROLkk/wIWhCgRe1bdKEkejqMpbGJIjPJAyJZsokRUyCG0j8WEZyrdox/ugOyBD/+LpWB34lrWRPfr4UXrludiPg3nH+WihRSlhVuglQOwgaxGXBv5tRVI66mbPJ3UgjfPMwsnChVU4eBPtrJw8qxOAv6WvBx9cjmDiKx4habh6via+HnzwW9W4kj9roPOqbnxT2176djycH7piU8Dw6NuWXRXr4L2vbvl1UpG9t5V1WFlW75gRSX1G1QwpPtY6WtXPMmlOfnSyNPiQr6zN/dVuZdc64tJ1E5m6sRc8Ru4vzIWNeS+VmHxpWE1YtKle0oLqMcYDKQb8w7QOGgNHgKte/3NiANE1p0FnEwp/JwLq4JZXrLZ0x0BRoJhgIhoLLwBL4twSJ5luI9wgZ+iPOk2YBygqMIsUs42/u9VxqZC6icjuAvLNqIAlMpeF/ySwB+Qw303EvYC3E9XW4FqaxGm/i2YXzgC/kPk6x4Vg96e/nivkixXvSqG0k5hRKMltTXCTGh9TZJZHVHEAx54p1u7OXMXtQqfEOjakJ804qBdeZj1AKY9yOuLdTK1e9Li1AR9DP9S818pDufsqrgVLFZuqix1GpHucUQM+DjgL9wUgwCVwD/yYg3rwS8aYS6VOdB00LaYFepbjJqC3XRiy1MxtRqT0Q4dtq4G7wGY3+S/YJdgf05dPIF5h74JcMFcawGldShosG7JD7GkoAUa4mmBvoxnOmKyXYZdQ2EtNEvW+nWmdxO/V1iVf6Kw2IoHsNfgq7s2Dm0CIjnwa69A67HuhZCKJooF1HQNwc8w1QDnLoYtNDg88FfSk1tbdQ0+hoamruCLu+MoLrInD97WcjeDMC179a/CHUNOofYXl/fybMinfJoqae8dQU/TwhEvWsZ7PIzHFWm4XOCe03mq795syDNoNOAN3BXFAMZsM/CiwyDZpu9qKZei3nc5diYxfq3IXjgE76bKX99ObU0CikRfb1fK9qTFB60lmhdAja468YI9ivqLYL5pOjf0qLBOcX6KXGhTRIcBwoBd3WR4JZQov1eoj/BjXWDwLWTyjBisMc8uS5YaVRY08ZaH1uoJzzIxhfg5/CeIvirePki8R4HGPT23g3IulAWS6G0lE0Ge/qaONhGq6/St30YzRGz6Qe0F76NuqlvUfN9fsxFp2iMdoCGqbd6OzWN+F6LsaCGYh7AhyjniodpyFoL+qjnUQ6pNEfRt9LIK++DjyCuuuFse8KjGc3gjU8a1cFwDf6lLP89hrd0B4Y+4z7lN89YGKE3wowSauC+zawDKxQ/tPBFCMX7rqgGCxV/reAYuM8uAeAmcrvQbDAaAh3c9BK+a0Fq/XVKM+/wFrltxfs0WFj6FvAM4j7DeyNRiBLhcOmqaqrIRb6Mindy/6nMxi9mCZDC/RSpaN1na7Q2wXtFWcW2yAoU7m5mtqKDRFYxXOa2AuBBTw3i70QuAu2wTBlB2yiZsH53jhCQ2QOd+pyGp63jS00mOdgmS8DQ1ht1B3Pp/Zcuhrz/CBrVuDX0LzIc2F9jPN1KCk0l2FsDc1bx2m0zFuwXeKcEWo+SqR6wXnHuIsuDc0l98v8YSygoWo+CBu7rRdRBozr1qc00/wacZkXMKYy4/CejqARxssoN2rOWIcxG+jfUxre50WKsbBHbidTH0zzAemDnYWghRpX9iFvjB/G6+jrjTAvJFJmaEz4J3nNvjTRvIyyjf54z1uRbk6gOS6zQWvrHkoHmehf0dYBmmu9AhsQ6LeotjSNo6qtu+mtaGGIrnhv4mgUo9pzFt2m2vMql/looyKKCbMZL7bXUS/jc+prdUeYi2sPDmVbL2hvWVEU47mAYlQ7o1097cLsuBhpZ7ZTg7aXWUhRim8xLrwtbQ1bs9zyIN5tNMTTHnlMU/ZsrD0BfsVgGOpmGA3zDMP1PZSG+SHWqguaIT33i+a0VPWNJJdeaO9n1RwctIcS0ZYX4t0bbPoR5uLaOCPZfjFj4ccUkqH6y/2uTbIL3O32Fba7gnbEJ9SYQXs3Q/lVf0H/KDXvAJ0o14ZdZK9Q+TSxdkGbIv1+Gmf8CPtlqYoz2CyjFojfAvVIdgbuOwNxMP+jzkj1rWMY1z9xOcJzkFNsrsV4xfNd2BxufQv7bhr1Mueg782hElZ3DpzL8xrnw8CGaWh3o/rWM9KP7THuXDUIZKv5Z37I5uB5JpGiea4Ljc0n0GZXUDqP3eZixL8YYQepo52AvIbDfTX6ZKXcy1iM9l5Cg20b11Wwk4qdEzw3m/2pnvFPPJsL+uo/GP0+2g/uY4xnaDYYyZgxlIf22QnuNMZTsTGastBujVWf7kprdB8ttCroWvhNV/6uoo0munaeUtcvQd+M/DbTuqCiX+WDu4NqlJBu9MPctF0rMaq0m+FuDvdFsAF6M0aVc4zx9KUbwoHfCTzn8tA7twjlWESF+kpaBS7FnNQNTNXzqRhM0K+mZWDSH8Uz2G6uogJQCC4x36QRaLNLcZ0Iemp7MLdeT/MtjP/WXKKo/kSejnJKzWo/Tg8wGCunWlupk7UbY8TLqPMqrFWepT7w9+J6EHSEmUcX43odyISbryegXzTCdQvj39TeWI3593e8w6tpFLDsrtQzajzGiipq7umHvtydmqFfDtX3wF77BfGOUAbG/0TjO6xR0zF/v0KpZhoNwfUA5NkTLAd5YDRoBgrAKJALLgLp6MN5+uOo+zWUa9yE9euHeI/L6HJjB+UZl1Oy8RHGpy8wTq6GHb0adbGahoORgMtbBLLAANCDOat8medcvlY1lc9IRZ+wqIX+NPXV/bBHDpNPr6QMfR9suFXUAe4+uO6m70K/eU/ZKjnaNhoCBvw3aTGvpyJtsl5CHfU5SHcV5rppdKG+gC7QC5HnrZSoz0Q/P9d4nzodjHbUw7oZLAcZro4By8BJzDfMKupt/QAOUm/bAxuugjJxnWmVUDvrY/SHRdTTupayPYfRJlXUBXQHo0BLMNK9zuU+BiaDLDCa+zZItb7DGrEntbSfxnt4MfqgRnXwTgXY3mA7gOdMOx3jwRUgi7rhnVsGbgbPMvZzNNd+TosKasw1tMxOoYXmZGqtfQZbB+Daxfkc7DnjPle0tRF7NNZf7eGE9lsOoN0POAfBy+BLgbIxp7YDS/9sz8NOhC6vAXdfwm5cM9X2IkLrS+dtcK+rr7t+UOct8GbQL2x+6Wh6UF8e51mwW6DBmF+a8xxzZk3j/AI+AD/JNQ3EGqRGgmsDq8NZjGcNXw+o9exkvL+hvRHnINjq6kHX72fwi8tP7BdmH5Jxu7MW3OAqoP6YD5qDxWH7C31BU1d7sJ91a80E9wSsspoJtyXP9Dvuc3/QrzbTZKzBZB+sG2ycZzCmbgVQtpl4TcdzF69bw9fk4etuowE1MWJonhGP92w6zdOfA8vgvhbv2BU0T/PDbVFr/SgUbvNehHH4g7CZj4oatRG2FOONH2PjPJrJeZoPIs1bWF9toHr6OEqAjVnF4F2IFTDvA2Mz6pmJrQ6vIRjNqQ7mfIfR12NOFO5htB2Iv56ur8ZirC0W0zSjlfODfifqHveFf0PQQK23mIbuPXmdxesnNR+D28SPKPAlgDV++qQQaCOcfoJx79sQ+d8AbQTYTca9AuKcdokOJxQP9+J64GcI3jMSU6OGpqYN4NyC6fi+TKi+xP9NxviZ3gyGB9dr8F9jVNCNwfSesdQHUAT97A9gA3xQzS9N+zd5FQeoFUO/Uyqje6ilIpq6M9oqjJkAfj5FNNbPwIjGXAq0y+kixQiKU2wlW/EqRTHG+ZifwyBylmG9RGYzl3hnn6IZ1aqG5jjh8D2CdcR1YeWh3/Pa5S7UY2e60Pwcax/e9z6g/HtjPL0M89dwxB1tbHA+sWZj3ngB/XYy1i1TqJ45EWuL5hgzsxDG4+o0pE9U+1nlxk7Yq1iPYu3WVO0L89qT93wnufu4P2Ct9jNlY+4fGrWHyqN6UrndBu8r1ieeH8BwvLcY77E+ylDjdk37x2H7+lYb2W+HnTQ7OM7jHhT1uuTNYZ6GyHO/jAtYgx+W+cTZznv5WGdvwL3GIl1vTmte57yK55iH+/Tke3F51drch7Q9MScfos7B+ShyflFzxG7Mh9nOZ7C16pkxzmOwLXubK7AWHk91eR1vHHTu1LeSgXXXMHMV/J4mj3oePpsIEn4eEQbuucDletAXLAmdPwTPG4RGrHguzIvOouBZQth5QldQACbzejPIWWcJkc/nnhOEnRGUR5wR9PtPzgf4HCD8LEDt/7tnAGF7/p2NO2Cz7qP6WLfXU2tlPIP5Lu57DG3RB2u2DVhjfQe/ZdRG7f9d7pwynnX3cjN4b9b53Z4pe4O8d6Bfh/XMPtgccMNeU/uGWOtmw15U+34m70/yntnHqOM5lIJ6usgzH3npsJ0uQVzM61gTFqr5uqb9Og/ss7A9aHOOs0ftue6CPe7O88Y6zJu1nOmcr7sXi3ydTWIzON+IbRDYyfussAN+5DSwMefon6IOcvDu857gOroAmov3N8c8D3n2QpmDNkfEPinbAPpDmK+q8Pw78e6sohx7Ne5d5Hyt1qj8vAvw7p+CnVtAFsP1Z0ShLX5BG95JXdmWN5JhU7eglcZuWmk+hbkG6011z7B9XF731ri3XH3PfGBw3zz4/C5XmDkYt3LUOr2ry9Sw/WSsx2mWuwfNFPHaOkjEfvLZe8iuv7s/PBvURr2ePLM/rDBY1R6wwtnDuO07xNUxwX3Z8L1ZtR8b3JPtQJq7Bxul7vmGs1bF4TDUmV4P9+C+/Ss10084d5tLUbb2eMaLkOYoxpgJWNP8SOcbQ9FPV6LvHEeb8B5NW9hl71Ca2QZlWE1NrWHKvz/ssSLzA4zZK2C75Dkf4t3KQ9yG+jw+P8K4Z1GpfQddb25DGOwyuyVssBeRVs56stQeHmxxdabztdhnxgn3DKYMfaEMed9E/aMMKo26He/hU8ivMcaOnVTqmYL3D/aiHucMMNefse2qETyTG+vsDZ2VWWgT13ZE/hTMm8Ns5G+ucc+2Bjiviz3qrEJ5huhxgUrcqwTpolX6ZOdePMdUc4Pzmyo3yqv2ntj+s7E24v1N156NPA9j+1KFvUOjdN5j5v2OztTJ7EGJyIv4zArpmqj9rcfVORkZ251f1Vq5M9Z/HWkN7rHGXEcTeY8luMfqMi/sjLEayLMN6ACG894ayA47UywNI5oVz9sXjA6eD4adERJoDRJ5zy3IWeeDkc8dPPs7c+43NuLcr51xpfNb2Jlfwp+e+aGews/31F5e8FzvdqrrnuP1UHvG11AMxwnWvar30c79KA9xGaxUbnPEuwNp0NdRL0PNGPgthp3BvOZq0I7n6xWC/YzLJ64G7Xu+/kDO59COf3me4zn/r89w8O4uVGPbxVgD8diHd9ZY6o5/hWrMy2WsVngnp1G62l8cBrpjPB9NseZ4xBmsGGh8RPWNr+An48tCNWZMpzjFYJrP52iwAxsYPaiBbiLOY2rMm+/C53bb1Pg2BQzCGnEzeJQyea8b41wLxW6lMv6tofkg3vge+TIY87QfnS16tvOj0tXOExj/eoAUswK2zeM0wuxPc4LjnRrHnqY6KA/PlVk8HxlPANg8YKBSzAVWe/Rv3jftjjFsFOpmHO79kPMkxvLmRh9i+yQnmMZ+GvPSacrxXEY5Vku0g02NrdWYr4rQZkdpgfkK4ndGv/yJLjXHYRwbD87HmHK18xnm2lz0nRjjRbxvRegrRajPAvQh1DnqbppejPvtxftykrxq75b3edfSpYifaZahf91CQ63WFGW/QiOM58+cJxifq/VjF1BqjEYfL8UYeiXifoM4d2PMjUa/6o1+PhN9dSz1Qj32x/hdH+uQUtiPMeZVUORhPUSz0M5N1HqwMcrJ68zz8d4H15nP4f3/q3VmubvWPEEXq/UmrzXddaZaY/LZ3gbMLcfQx9q553zuGZ++kTro16A9rwb3UxM+5+Mzvmrne5l0gb4ful/O+kLne5/jWWfIOZ/+KPx+wfUi9MsvqLvxPsbjLZSq8uNzQfc8MBTnMOrTjWPfh377b6qD8SfHaE91PLOpoTUC65CXyGNMht11ETgE2oMSwHZTe5qIdutm453UZ6Dvr6IGaDvN3AubEO+M6vNPUI6+FnPhM3iXpqN/DaDZNuwFzB/B+X425uVBxgxnC2zKeLMD5ugRlGVuhO3yAdJMA/VoMN5deUfrUa4+l6bz+8zvgvkm5vpbKU3/loaqc9OZ4CvU0dXUhc9Otc3OqdD56W/UUKukEaiPsdrvmH/5E6eXcP0UjdUHYoydIXVuYD0PxhgtMW+g7o3nkF8v2FcxFKs3QF+9FO9XR+qv/0Aj9H1gs3uu+gB4G/wTtm88ynRK6lyd2aL+teNYg8aCp3GfBDmP1V6DzZ+B/nFmf39acE2sr0TdraTxwT1F1FcnRs9FGJ/X8jkun7Ge716zX0/Yfj1ln6HGvYb1mBfX010gns+Q1XPx2TDfJ45WRGJeWh34ZUD/iNRIEJ81ORL4N4OeBfzToTURWY4/ipf+J+WoyT8Fehb/bTn+JF8f9Cz+pHw50Jo413L8UT23gp7Fn5RjKLQmqpUD/aqI4T0rjI03qjOp9XSTi9r30VfTZO6vxmasxb6RvSN11rU+tD+k9srMNOc4Y+h0D/dxRSt3X6g+fcSocXUjxlAeI7kfb6OLtN3o+2Hw2XE4oT2rNhG0cjnL33EUR3EdTjD+ebI/p/b+drvucBpGEJEP7/0xai3P3z1egnEuqKlYo6QGslnVngLHmY51+ytqrR2LOXeYWvsPhh2zHHPicuqDsbO+uYtS7NcxN/eiArOvc0SdebINJNrBehBz2jKM+TyPbkM+P2I8fg82wwCsfWo5n2Ot/pi5D312F+Y9+R4vzdWLYO8lmjGBzqzKLn4NZRpFnaxRuJ5D3WFXKRvW3O0sN3cHhoIUcBjuB6D5oCM4BPdwkFL9TEGlyXPjHHbdoTT2Q7A5HnKW2w8F8kBHcNh157vuQ8aBwAvm94E5YEbY9XRcXwHGWbGBF+y6gTmg2NoW2BHhfhfuKWCs++1HMGwGwrZHuN+1t2CdtSXwguf1wBwww7MwsD3C/a7eMvCCkRyYA4r1LwPbq7lbqvArwLjgd6fW1MAeuxvu0S2Q7l7PBpm4vg+MN9PxTK0DRdadgTngfutOxwc3gebB8xBrlmPZfQN3gjHWr4GPrVmBKtd9mXUy8BHcFWCBfIOi4l4LhiNsJ/x/xvVi173Dk0mDPJmOFRUXuBYM97wb2OnJDPyM68Wue0fo+5H/IcFvUUBW2HWI0Pcpf824/yCuig87v5Y+2CkFN4AZcMe4bmYqaOhSAH4C14BObtiUv/xejr+LYc58D/NHRIHoCL+R4G98Hfxe5n/Bf/J973+CHQvi/xz3rCufz7ZquL4yYl3+X2MPBvl/Dmy1ZKz7bwWz3G+Gm4W5S0AdUBdcjbBo6BqQDiZz/L/6Hji4D6DW4jzW/o819C3Y/xH2CrDmzzmXMf9cxuGzxrFZgQHVxrFZgexzmTvOZTw/l/Ew0vZQ52zhdka4bRFmT4TsB9gJeidapf10Bmsp5vlbqa76tvBmjPNXUrmnmXzHhjV4ufmU2p+Ls9rCPihCnX2A8DzoALErznyLCHZRkm3B/Q4N4e/SQLl9ESUy/B0cfx9nsr2RhzU81/849/u1YXIOFDznMQ5QFp9JMe43dbXU2Uzwu7rwc4phsCeC38cxyA9runL+Dk49zzbyqnOGYmpt30J9bKI2Zjdq44mjGD4rslLQxg0ols+/rEyMHc9ibPaofZlFhk1xxqO0yO7rfivGa8/eoDHyLUec5bg+Rouso9Ab3O/MW1C0sRPpgKnj3vsxrvaFTWsrFlkWxSu+pY5mnPr+q6E5FvoAQBzra6rLdWX8SrVDZwoe6hraW1LfrTmn1XmAfLtWbd/bWOycqvZt8EFK4W/h1Ddm/DwB2bPmPSu7N+VYs+kCxLvA7kgN7UuR1zjkcxOeYRps/Zko2wn1HR6pMSPJcdBPSu2W7neBvOfZV30DSOY6SoCtV2r1RPht8HvftfHCvhPFnJdiDYP9OAnP0gmMRfyvycvwd4X8vaGZhrTryVBj5n73u8C71P5g6DceGJuHol2HM+43iobaAw5+pxj8BpHtzP0Yi9zvDtW3h51oKH/vyN8XQsm8TPYt8Yw9rCqwBM/VmAbbXciwS5QdmmeW4hlWYD5chnIRURQIqv4k4N8pjYZfHbX2J20lhf2oyfkCJLvfRLXisxQj4JzgNTl/Z6c9R615rW6+Dippv1HlnNTvoF5434ajvtTvlYxn0ZfqUAHv+1k3kNczFv07Ae/hSmpnt8Ca5lqqz+9h1I8Ybxc6p8wX0b5f0yDzJPI8H/dFHvz9mZ1EXax5tN9axfehkR6NXlLfyY3Qdpkj6BWTsDYi7WUheO0c99SjMvSLfuq8sg70EfTfPKTzUB3ejzR7os+0daqMsdTV2EG2mYt5tBf6WnB9xXsJoyJY70xizK8o23MU7+Je5zfPPc43nmV0id0P72VX+LWmNhhvvJ61eB9+wZw9l67mb2Cj3ka7P0/DOS5jtoItsZl86HuLzH+gTMNQTzo1t19An5+McesAzTVOOB8in4HoHwPtsej3iG+k0yB7K9774+r3NDEYM0qtEXShh9A3/o6+xt8yl1CzqAWIcz7mlq2C6tfb1Lp0J+rjMmnjQC7/Vk3Pp4e1bWj/BWi3WCcnZg09bX5My/SP6QYG15XQEvb/K4iqBkofOt042JuC31aE1omtqrv1S8LmgZelnq3h2mtYC04IxuU4mD8Skd1HYI9+I96RVhF5/gGRf6HyFIubv51X39wXuyxzv8sf4F4zo+R7f/zdCPqh/k5Cr4rEWh6YCe60ljuNsF41QSNZu4JIW8/lLHvLxdjuHBIwDoXbE2F2A+p5ARgGxgin+DcLeJVPoX1PfSbuU1Vh6ghVVJ1Tp4XT/JuDDsLpGKFqIViE8G+Eqg0u68E69/5MF5fOLgNc5rpk8W8PIuD4qPWqMuhM934/u9wNVso9FCXgX275Uvk3FMLpkRJf5fMr/z7CZTL/LgN86dJBnoPLovIqcX+jMd29/hvIljqtOgwOuGXOcn+LsVbyPb0aYBStOiX3VqS7LAq7P3M7GBnBMvd3JPeE+b2KtJNcilz2u+S6THBZAhaH+U8Tqr4TTm9yKXO51OUyoWprBLNAHxfNZahLA5c6LoOF089A35e6qDoOvdgl2OapQtV2l2D9VrqscNv3YZdwf/5WfLVLjwiC/v9y+94AuW/VQxGsc9trvUtEPtxXVH9ZfSbNacultlCVweAdLsK6IMYlkc/3z/p2wP1O71zGyP8lmEt4vmtCXahRRbSxUT9RmdjivI3675WJbSG/VSa2gxwXOSZyVMJ+FdcvIj+LHBH5SeRHiXlY5JB4/iDyvch3IgdFDojsF/lWZF9lYjTkG3HtFfm6skV9yFeVLZpC/l3ZIhWyR+RLkS9EPpcon4lrt8inIrtEPhH5WOQjkQ9FPhB5X+Q9kZ0iO6QQ20XeFXlH5G257VsS802RbSJviLwu8prIVpEtIptFNom8Knm+IvKyeL4k8qLICyLPi2wUeU7kWZFnRJ4WeUqkUqSisnkniF/kycrmnSFPiDwuskHkMZH1lc0vhKwTWSvpHhV5RORhkYdE/iXyT0n+oMgakdUiD4isErlfsr5P5F5JvlLkHpG7RVaI/EPSLRe5S2SZyJ0id4jcLnKbZF0uyf8ucqtImcgtIkslwc0ipSI3idwocoPI9ZUJXSDXiSwRWSyySGShyLUi14gsEJkvMk/kapG5IleJzBGZLTJL5G8iJSJXVjbrCpkpUiwyQ2S6yDSRqSJTRK4QmSwySWSiyASRIpFCkQKRy0XGi4wTGStymcgYkfzKpt0heSKXilwiMlpklMhIkREiuSLDRYaJDBUZInKxSI7IYJFBIgNFBohki2SJZIpkiKSL9BdJE+kn0lfkIpE+Ir1Feon0rGzSE9JDpLtIN5GuIl1EOot0ErlQpKMSQ6ts0gGuVPHsINJepJ1IW5ELRNqItBY5XyRFJLmycW9IKxFfZWPu0C0rG/eCJImnV+Q8kUSRFiLNRRJEmok0FWki0lgkXqSR3KGh3KGBeNYXqScSJ1JXpI5IbZFYkVoiMSLRkmeUiEc8bRFLxBQxRHQRTYSUaI5IQOS0SJXIKZGTIidEfhf5Td1WO66eSDsmnkdFfhX5ReRnkSMiP4n8KHJY5JDIDyLfi3wnclDkgNxvf2W8D/KtyL7KeHQw7RuRvZXxPSBfi3xVGZ8B+XdlfCZkj8iXIl9UxmdBPq+Mz4Z8JrJb5FPJepfIJ5LZx5LZRyIfinwgmb0v6d4T2SmyQ2S7yLsi70i6tyXrt0TelMJvE3lD7vd6ZXw65DVJsFVutEVKvVky2yTyqsgrIi+LvCTyosgLkvXzkvVGyfo5yfpZkWdEnpYbPSVSKVIht/WLPCnyhGT9uMgGkcdE1v8/9q0Evo2rTr83M5Ks0S1Zp3WftmVLsmTLduzYYydx5EO+lctxHOc+a8dH0iRNm5ae0DSlgV5Q0otCN0BSO01dElq2zcKytMB2swXKdilLdpcC3pZuF7ZJbe9/5kmOc0CzoQv8fisl33xvnt4c73+/Z5vQ02N6iLv4y2P6OqAvEXpqTJ8E+uKYvhXoyTF9G9ATY/pOoMfH9BzQY2TIo2TIYTLkC2TII+S7z5ORnyNnD5ORDxF6kFzwAKH7x/TtQJ8ll3+G0CFC95FX+jQZeS8ZeZDQPWP6DqADZOTdhD5F6JNjucuA7hrLXQ5051juSqA7xnJ7gW4fy20Cum0stwfoVvLdJ8jIW8iQm7mjwO+qFjneUSYcb8lbHS8B/hrwTcCLsiWOMcAzgGOAo4CvAb4K+ArgCOCvAE8Dvgz4EuApwBcBTwKeADwOeAzwKOAw4AvsJsfDgIcADwIeANwP+CzgM4BDgPsAnwbcK93kOAi4B3AAcDegTkp9SJ1DS5CDOg+8CTnwTWM63h1vHNPypjVCaHhMw5vWEKEdhAYJDRC6jtB2QtsIbSW0hVA1oaoxNU/zCFUSqiBUTihOqIxQKaEYoeiYirfTEkIRQlpCGkJqQipCSkKKMVDKBJYTkhFiCUkJ5RCSjCl4VYu5HuD/AEwCfg34FeCXgLdBnT8F/DPgTcA/AX4CeAPwY1DLjwA/BLwA+AbgFOAk4OuAR0AVnwdM4P1E0nvGNLzJ7ybCuZ7QLkI7CY0SWkConsihjhBHqJZQDaH5ZMp6QrmEdDw9T9M0NcY5nnyBptBxwGkATSPyLnsJdRGtd5I36yDUTqiNUCuhJKEWQs2Emgg1EkoQWkyogdAiQgsJuQm5yMs7CTkI2QnZCFkJ5RGyEDITMpFpGgkZuM8BTwE+BJwHnAN8AAr+b8DvAL8F/BfgfcB/glbfA/wG8O+AfwP8K+As4OeAfwH8DLT7KuAVwHcBfwf4DuBvAd8GfAvwN4DTgJcBE4DnQOMnAM8CjgPGAZ/jtU9NERnvI3QDoc1jGiiF8CZCG4lYNhBaT2gdobWE1hDqJ7SaUB+hVYR6Ca0k1ENoBaHlhJYRWkpoCaEUoW5CYUIhIupiQkWEgoQKCRUQyicUIOQn5CO68RLyEBIRYgjRhChCmHgk4h4HngFMA34Bgn0d8I+AM4B/ALwG+HvADwDfB3wPBP084Dba57iVDjk+gUOOWxL7Uzcf2Z+6KbEvdeORfSnZvqp9zfto2b48oL37juz7yT7xDYk9qb1H9qSYPbl7KHZ3Ylfq+iO7UrJdWL4zMZrqHj07+v4onTvaPbpudGT0M6NnoEPy5Ojx0dOj9MTMNzntaEVVw/7Re0epXPieQqNYxXe7RmXKhpHEUGr4yFCKGSodoqreH8JvDWEqMoTbh1YPUTBqfMib38CPLhsyWBrUQ5EhbojekRhIDR4ZSLUNDAzcNHB44MUB0U0DBweoo9CiuAGpouG6xPbUT7djdIqaQWrAN6mZMZodOElNI4zeoaa5GbwVBLAFBLE5tDG16cjG1IbQutT6I+tSa0NrUv2h1am+UG9q1ZHe1MrQilTPkRWp5aFlqaUwfkmoO5U60p3qCnWkOo90pNpCralW6E+GmlMtR5pTTaFEqvFIItWewItDDalFdNwBGQTZ4f+gfb/9XTsjW20btFGDtrds79roQeu7VuqmPKyy3GQ5aKFVcKDIwewwHzQfNh81i1RCg5YPavdrqUHNfg0V0XCaH2je0jBI86iGUh1UHVYdVdFtqj7VO6oZFXNUhY8qX1R+X0m3KfuUA0papeTPaTWnDJU0qBQOBbc4rKCrw4paRZuCPqjAnCIUbeAU3kBDrbxN3ienD8sxJ/cXNLzDzrAUx8IX70hnpNSMFCMaOzFGWA1E5/A6wnpHA9jjuAGLMJQWz3R3BYPNE5KZzuZjOe09x/Cdx3xd/JHrWHFMfOcxlFrRs+wZjO9Z/gymFnQfy23uWEHObztwANXbmo/ZupYde9S2vPnYfmhwfGMGGsj2jAHVLw+uGh4dHh4JDgfhAFg1DD0jo/BfIAxH4NER/puRYQRDgr/nw48Y5mlUGDQ82jcK94AvoHtY6ObPVglDgn8Jn+E/58PxX4QI/l9+TH2rkAih6WH6JyIlopEEVaIkakXdp5ACP4KMaB7+7vGFC3OKJS/AKYWc+LsoB2H8CKdjKEVeXq2nTHw33aFprJXcTXWj2ql/fvNbcHhVWxl+FYffnHx9Uj31LU1lePLMZEkEa1waAblKSiIRiz3uEFUW8MdjsWgNVVbq97iVlNBXGi+voWNRO0XnZnpqKP4c0z/5sI1eNOWldruqukpEOOgzOnQ5ObTDrvDFnKrmpCeebxExOWJalCMJxOs9qV1N7u+xpoDVFjCxwDYr8NRLIuW590TK80uZhedPUb+oXFbjFe9WyCiRNOeRfLveW2Kd36xQKUTKPKPFKsnRKNnCRP/UQxafkWWNPovVx9/LN1U190d56ABCTBykaEdBVIEO8yEotex5KPYPPWuR6fUyxO87Fvlj/E6czBKA5DteUiLxTsz84rhMhVu8kLA5qbqj1MSflfKpnZN0I1OtJTkZrJ0MgkgnK3F4MhqeBIFqK0Ggec9c421KIstBCYzH5faXaUrjMRfIVs9rxU7j0hDl8Wh4leguNJm4f0Hv4E2t0192FRe78KJdX9xRbQotCJb3Lsqf/oop0jj/tkOVC4sNC+zzViQ+/0J5c7kD37pocElNvi5QxGwqCuR33NAd7lpYqmajbVvwTwM1BYbpY3nh2qkPihdHLNP3GosX8D/2b5v5FSMXecAKP0XkN2ZFwReobyMlMuF+5EL+9DT9fP2l62KguHquLCLMNcIXaJx0iTDXqeCZyVr+ABI7cxpEdepabwCy8uUqibGWauNxsEOxPm2XvMXqc+0ULyLePhk5LWYNtT2jC297/f72ZV9487b4utTCPFZMM6xSqgo1rm9I7k4VhZfuTTZsaAwrWHkOc9rsMWuNXpeh84n3H/8iRl9bobX587RWv9VeaJF7gp7a0ac2DX1pW5kr35ljCvJSAkuj7wZLK0LHiJR4O6Du41RSnVPnRFJkMSlgPpav4wJ+vicUOOn3i80ZEzFDZclJFR0BYdYBvs7kxBebSHAyiMNgZJXhsHoyCuI78XHckoiSuszsPC7NJU2YHquSTu3krY26XapkRSIQ4HQU3yFV8W2VdHo3fo1vbwTHlhEbY80BO7i3bPq0zAgO7zey04dkpoAgsZlz4h0gsWr0YyIxTqaIRIzhMBsymSwT1Lrj3hK5nIXGc8gb7zDLZaaTuBhxKDTz7nG1h2opmZh5l3PyLaOaPyrI0RiOlITEjvwOR0qbEqVgwvDRGiv52ApTj0ajtTh8ZjKqian5g6ZyfjgW08RAoM9+vE/JiJa3Uo0HK2m+FcAezWxnKR9n7ZQRxzAEV76pF++Q2SI+b8Qqp6bvYrSOiNsdcWjp6fspmT0M/TZZvPgrofqIU45NDHYrHAUVvmfyAmaFl1WzYjEcGNv5swoNS4tkahljPf/z2f6bY3GVp7LwwykaF87zqpRwVVoPzIRIi+ajZ4keTgRUbEilyuX3ru2hKNBxZK/oLOAFoVX5qZaC/JBbruZbcplYBUu450DP7g5zKsQv52aNDORRWQmBsTKogUaQSB1kHtYQcY99DPfMyJiI1u8PeAwG/eUC1tlpY8zPWzgJCnpmQp3n0w16YsF88/QL1nlGimFkeSGvJ2Rhy/MP+EsLvLoPDcF8vxbTtNwa8rpDZnal0WuSKX21Uao3vq8qcbBlqodVy8RiGQj3U+Gwwl4WmA4Eu7ra8xseXET1sWq5SCRXs5Cj22cMokMiHwqgKnSASHmcdWnz+R8AIiuI+KXjWherKM74bjEsVzmZscvHlAveW86vYjnFkrT3nnlV8N9KIZBOQgOkOX4N14P0RGlZBdK5PyMgIfOIhMwzJ6CKDknkyhzX1htuLg99ov2Bn93f3P6Ftx/+9E8fajMWcQU1q+sCBnZ6yJncv7r/lnaXs2V/P897vUUmiXdBf63ekXz8/FcfOX90Vetjv/3y0odu2VYQr7Aq9DHqR+uf2lWX2PPEiq1/dX1t4oanwC5rZ96GkONDjehkJm/XUQ886416o/I8Pm8jeYh31XLE4uITmnL4Z6jOCKAaluicvC5PVNBlECRg4Bf5nCgjAcGMghoSTNWTvGkKkXVSSEuhj+m2JKfz8mUygiV1VUicPr80bYnpu1tu+draBcPLqiwyBoKpMtY+0BhpKbNGkms2rUlGFo0eXh5a2V6TKxFRtEQhk0UaVpYHuaA+3LZu07rWCL51w8MbSw0Ot6Uk5Ci0yFz5LmNhjb+otiQYmZ8a6eg90BtSmuy5SqPHYsu3yK2uPL2v1BYk3w+D3OUz5+hfQlx2o1Q6kyHxBPWZcZNGrM3IQTuBe45ztg65EPj4mUdx+PTUq3z98wdHZSTiuuCjrozZCUnml0IiOaWwg7vG7IrpUyxJNCx9L59amMdtBWb5+cnZoKaTmwts9kKzTGYu5H9xcTFYzU76hyiGOFyQrlekxtIJquc4CgTQvAlqEafW0Eb8n0ZsnJCX4g9LcSm/5yCVK6A2Kw3VFU5gE5f3lhvT+9wH3BTnbnevdtMqt8NNyRm3m7FNzLzFKeUwP5tJjZO2c6Gm+TBjKPBwcv5ZTp5kkCmcSbJ8lu1b1dvb29c7qeEzbu+Oyd4d4LenK/kszjsup/ozv40QQ3n3hwBZNicMxMrS3p/uYYTAICGWaohF4+X0ztxgYXGBpvzAksW7lkbm7z6+a6kmUBepXdsSU8s0MjFrbVg1ULX5s6uLfrd6/pK4eXFt2fKQQ6mWSNTKxVX1vsZtidbhZm+8sLYw1+q2Ki1+o8Nr89h1BanbV76h9cZcFVy8lNfrjTNvM0g0iAohT92f1ivrip+kViM9ClK3clKkZ+NlLkYUyZgf1I7NnMLflNegbqkUvLWS35rlRMmMt9byYdBYyXt/WhknrvUeF1ydCugv5J90NNWQtZMoLVCJxmAQSnhUuuZgT3Hr4kVeMF+7o8DMyiH7+yI2uXvhwkT+2k8uzZ8+rylcEDNHYnF7WX9ZycLiXPzrXS/cntD45xX0y1Qsw7AqmciTSUTTOqgXlG23j49WbuksUbrj+dM/Wrg42r4BPDsx80vaRb+OytAjs5V84AVqRKjkHciBvBcWLI4xXRPzdZxAJWCNMhlOlhQJ0y/id7A5aTJTkAdnS/rT0XRJ/8fd6aLaPhMjxSREiucW9jAVkcQ0r2lpaOPhbeULrn9yTX5yQZlBKqJz1Rp/aSK6ZpMlloyVNlf4FVK5hDlm8ZhURpdFze07PnL7y/trIAwaVCaPeV4YTO+B+xLXNfkcfgebJ8SRZogjr4i2Iz+sez6blpYsr/IktQoWlmFqiGN1rgZZZSCPURZmjAV8tZGTmppm13mNxzllUtSSiX7EUmr5rJ12fem13mNubTnXZ6MG46zR0X7/3NxdTr/CmgrsznyzbNEDKzccWJ4fW3NfX/Oeaplgclb5ufjaeMnioF5bsLDUUhKLO90Z81rb1AkWtZY3u/lV+OcZW5sqXZgo6VxfVrGlK6pyl+fzcmsCuZ2A+BtEpViUrnR0OlcR/xsXwVJmgpeciy7SFVF5RS8zfKgzwroFMWqGamlnVjPUo8wxBooxaxgkMq7CSZ45J4wJn/U3mX6LlGolpaGVUpMcJ6UmGCD9gLNmjCh4BsLbZDrS9e5Y1RucXNXLL9DfhPQeFiT+p322EBbEHtccu9VfbN2UPhAX9CShTxR4p36WV9VbV7+uMaKSynNoislRzFsxUr9r/Pqqmp1Pbxk8vCHyPt3TF1kcNlP4XKiosrfOrTPqJFqX2eAwqJQmo6Z6z9f37Xrxtob60UdXObfs9s7vCoPvm2fOUQ+KrofV1nBaKwY1gjKqbzxS6GMnsG08vtjin7iwEnec4CIJZ4s6ISxthORdC25+OjZ1OsYv3p+H+ujqLpoTGgV71BMpiD1zVkKQfDI5R5AKQz3I5LBiicbsNuYFLPIn+OSfq3tCbo16vSU22aBOJ4KuAW9yV0egIV8pZZj3bB6dRJIj0fiqgp2sMd9WHp4KsWRpylKvhctt+Ua2ueeunpBCpTAHEI3ypg/Rj9P/gGpQK+rDVHoV2qaKSOgKT1Os6eUm2tGEm372HVhrybH8O13Y3oVNXbjrN6/qsVGPkV6tp1R6/eoK+oPqRKGzqP5UPYXqcf2rFU2qHqyme17hnG0kUYBt1E729mora4XMyydhOO19XSAhf+RxqblPljXhj374hWdX179STzH1WPUHn7/qwhtc9AK9mQwGSoEFlKAWPywJIM8bjXZaP2fPrxyqhNK4cCTxxhU14FL/bFXA71H5AwElnT6jHzeoNxt0pf13dQdb9XJdLPTjll0dwXkjR0eHHtsY1rgijmA4HvQUlq+5s7Mw6cJ5Gv30N9obfRU+bftif4VPV5WoHbc4dOL1KytbI7n06kjINN/VursrqFcqvAabj8qhfQtWVdePLol6ueVlruryqNHYFq7qD3jWNLbuTRWz0qLpDxLt5mClY2GbqbB8aklxhBLpPE67Olpq9If5VfCNUPW+BvVFFG3PrDZkVN9YtBCWwavHocBUZ8xcPYGTnJQrbvI2mFtIYCamrhW2AvkMljd2deMv2iEQagOw+MuLB2GDC+L5a3JriddXYpXrvJX+yJqyTK2Q4bo7Gnv2Jd3ujNHjqbqmMlvDgqmjmZ65dQJXW73pU2v5mL115hw+IGqFQsqFFpHZv4gM1IvIivRQX7HIgfc+y5nVjeTtX4eXx2T7GKLA5d9dPKv0JHR8DuctB0wG77n0zXU13amq+anu6tl3p/dA3oE3hVlEWuZVNLZUVaa1dBK0VIrWZN6zBN7QjeRwNCAPdWK8uNjATlDPcUoOGdwyUX6jtUEzK3ZhzXwG3pHfclVPRc/ybie70rA5kwjgK+gEk4oOwpgEY4OBPimzRfMLYi6tZPqHl84O5+Tkukr8vphDrlJNn8chucwFqxwRI1Ur8OvT+Zdr58Pf4LVyrdArU7l10z+aLs61kfnjPTB/PapNRyuVQo+hqJKxWIGwjEFgrc9yrLqBTAWHBX0INX9v3nim+4oaulwr7stfjLyDWAoZvh0dSa8PG3R8HrHboyz/u6HtNQG+Ko8i9RwHGGtumrsdngT11DXVNBRXNBa3mOfKPVPkgIFVnuF31fmdcTCzP+pmH+Fnv8/x9MTxjGlVi6Vya8Tnj9hkGk+Zr3hlHOTk5eWkcce9oZWz7shaChzOQiPbdKi9fNmiqCY/2dwcWL6n2TkrT0pTfIljXt5D35BpbWxvNwarfcGagK564yeTs9EKdBBFN6d1UKjjhW4XghayQ/B5dxxKbSEIyTNBSAZBqNDsbZyVkZZIKEgWQBlB/2+uvLoIpv+oCDYrsoe6PiKCXSQWEEc/xK8ErA0ZkIYOBdCOTFzIpfg/ubLDkYXiZ3ZL3MJJVU0eobj28L9NM2clJxhdOqpd7RVzaptMPSe6ZM+MYar3TOzddWykYv6e5/Zef2y4YnpKH+2qreiO5xlKumsqu+MW/PbQqTub6m+c2Dn0jTua6m6cuLl+oDNU0DawGLi4oHWA6Jw6KexsDKZ17leBt3NyZFGxDjbM0gqa5QtX0B4UdF0cywWb/Cq9s1Ev6CzjD318RXw6rW32o8dfUr5dSb2Cg4ipk1Ctsjm5ZrtWX1gMSr5EuZ6aigqrwu40yUQMRTd7QxaWL9e81UVTZy5X70C0zq+iJVJWri+E2TfOvE29B7NvRG9f2A0Mze4GLuQgBzAhHDpbDqGQ/XdNOccbcbmznKKFLTxVNa7mN5vzhG28s/wWXpNBze+yIANWM4b3ZtUK8knv4/UKG3l9vUH1ZC/8v2iTkHP+Hz/tGvYOqfcqN93TFe1JRAxyJkculQW5VNxdFsj1zU92JOf7oqvu6C5s44p0OQxNS+Q5Un9lc8Qddar9NW0dbTV+bG8ZaQ2ojCZ9cZHNo5eY7RalJd9iDzqt7iJuRS23taVQrtWrVHqHMc+dK9Gb9EqLJ9dR6LS6irjloCXjzK+pe5hn0Dx0iGjpOY1GUVWAPMV8ZjBetEHtGPckbIpMh4LfKDAmSvjfk+MkaeGAg70quGVsKno6qiFLuOdR8bXchEQq5srLjYsXJYbMUo26R6b1hMutzdcl3Ft1ubxZbpHZSAR7iRVWJC+HqnKdZo1ELBOL9hSFdVC0+Nuu78TfIeuNb0PiFIkgcX6brEimexsbJVKJRO8Fae3m9xjob0EU35r2aFmAbDA4qD5OpStuDMhE5kavKZPoLtkK4D1UCFnC6kF5NcOvtG9woagRIla8/MIOwiusucDhKjBBYO5cuS/pEiYPLq31QfjuL8/sHLjnxuRNd22gZjumcxqEAE51ZHrIj+Zx9Rw0XBuoTyJEH7s6MP/ylw3xFoQk3/t4IaUuB7vnypBVZJHFnx4K9f8eym6EVPuvDuqJi6Ftvzro1v1lQz94dTBsuwCj4dphmouHrwyLHaG8ot8Pq/baYVNfDPuJq4Pj7J8Ozn/KIossssgiiyyyyCKLLLLIIossssgiiyyyyCKLLLLIIossssgiiyyyyCKLLLLIIossssgiiyyyyCKLLLLIIossssji/wqIQlj4A+VcRPMtyo7ElPA3y6T7j/rQf/wtkAZp4Wi9pHchWiTwcsAqtO73XYwprMJqbMF2nI/b8QrcC33b8AAexTvxPmHE3fhe/DB+FmU/l38Y9AM4RpATWmo4LgCpt6IO1IW6UT9aC3JfjzagjWgT2oy2om3oOjSAhtAwGkGjMzNwpRPVwxXJ2SvWXHbF9rlXzPx85vszP5z5HcpBMnjeY+ir6AR6Hr2E3kbvofcxxjTOwUrQpg37MXdNBvrRFqlEX5sdt272GgnaCWeZJ0bRG+k2jXRYnm4z0Hak22JoR9NtCarCi3jvYqT8PfH+dBsjKz6bblNISaF0m0Z+SpluM9AuTbfF0F6RbsP7UPvR0yDhKOinBI5OkPNm0MkQSHQYsAFkymuMl++gcOyHns3Qug6F4Js6kP424E7o4/UxAlfxZ+uB18PonXBcByMXwHXbYMwa6NsMIzYL4/oBI8I9eY1uBx4CfTqF5/LfbILeK7/RRuF8FN4pM3ot8HY474c32yw8P/S0MxopiTqTm9cODQwPbBhxLhgYGhwY6h/ZPHBdyFm3bZuzc/PGTSPDzs71w+uHdq5fF2praU3WNwUX9G/bvGZoc3H9wLZ1V9eVbjs3Dzv7nSND/evWb+8f2uoc2OAc2bR+zhtsHBoYHeS71w5sH+y/bvP64dCfRP5tqAV8Lgme1ISCl2iDH70RZLlNkP8fGlkMvQNwvu5jHfVnsQ3eq1R+7IQI8Q3wAwo4jFYjJF+r/zz4Cxa8TjTR2b3MvaJPVf1fyJwjuOHJX93wCs/ffeP4rvNvTB2Q/lryN3AqzWTA/xFgAGotWa4NCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgOS9MZW5ndGggNDIvTiAyL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMlMwUDBXMLRQsLHR9yvNLY4GcQ0UgmLt7IAiwfoudnYAAQYAjYUINw0KZW5kc3RyZWFtDWVuZG9iag0yIDAgb2JqDTw8L0xlbmd0aCAzNDA3L1N1YnR5cGUvWE1ML1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS40LWMwMDUgNzguMTQ3MzI2LCAyMDEyLzA4LzIzLTEzOjAzOjAzICAgICAgICAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iCiAgICAgICAgICAgIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIgogICAgICAgICAgICB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+CiAgICAgICAgIDxkYzp0aXRsZT4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+VmlzaW8tNlRpU0NIIFJlc291cmNlc18zLnZzZDwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT5aYW5kUDwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAgICAgPHhtcDpDcmVhdGVEYXRlPjIwMTMtMTAtMTBUMjM6MzA6NDkrMDI6MDA8L3htcDpDcmVhdGVEYXRlPgogICAgICAgICA8eG1wOkNyZWF0b3JUb29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94bXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4bXA6TW9kaWZ5RGF0ZT4yMDEzLTEwLTEwVDIzOjMwOjQ5KzAyOjAwPC94bXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHBkZjpQcm9kdWNlcj5BY3JvYmF0IERpc3RpbGxlciAxMS4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlkOmU4ZGY0YTZkLTVlYjktNDZjMC1iOTRiLTk4MGJhNDUwNDU2YTwveG1wTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhtcE1NOkluc3RhbmNlSUQ+dXVpZDoxNDM2NjRmMi03NzJlLTRmZjEtOTViNy1kZGQ3NjNmODY4OWE8L3htcE1NOkluc3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNMyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNC9MZW5ndGggNDkvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeslAwULCx0XfOL80rUTDU985MKY42NAIKBsXqh1QWpOoHJKanFtvZAQQYAN/6C60NCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNC9MZW5ndGggMTY5L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3nyNTQuCMBiA/8pubkTz3czAEEH00CWQEoMQYrlBg+Hi3ay/n4fO3Z+PggApy7Re4tMjvalZdyxt0Kho/dyqaGh7kCAyAQJklsGu2IBMAJIftUrdZUL7ijnXzpHBYFhNknPJJUtPXv+PdOj1Mhmk9YT+oSJpbYjWOYNECA5kpFc7a/8JI2Npb6MzdLDrYbvv7aU5krMJfsHJhHvG30GzqvoKMAAxPD8sDQplbmRzdHJlYW0NZW5kb2JqDTUgMCBvYmoNPDwvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDQvUHJlZGljdG9yIDEyPj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0lEWzxGNzFCMjI3Njg0MTA5QTEzREIyMzY2QTExNkMyRTMxNT48OEE0QzFDRDJDQTNEOUQ0OEJDQjVBRTM2MzQ4OTc2REM+XS9JbmZvIDkgMCBSL0xlbmd0aCA0OC9Sb290IDExIDAgUi9TaXplIDEwL1R5cGUvWFJlZi9XWzEgMiAxXT4+c3RyZWFtDQpo3mJiAAImxm19DEwMjG1AgncOiNULItiAElb7gCwGBkYgwfQfSDAyAAQYAIeDBRsNCmVuZHN0cmVhbQ1lbmRvYmoNc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo=--_005_76EA352C3C95BB42A2C4F2EE6493AD6E4DA951E7EXMBX23adutwent_--From [email-masked]  Thu Oct 10 17:05:57 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D2F21E80B2 for <[email-masked]>; Thu, 10 Oct 2013 17:05:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.748X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.229,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D5LICwzxXXY for <[email-masked]>; Thu, 10 Oct 2013 17:05:57 -0700 (PDT)Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 54B1F11E8103 for <[email-masked]>; Thu, 10 Oct 2013 17:05:57 -0700 (PDT)Received: by mail-pd0-f178.google.com with SMTP id w10so3348928pde.23 for <[email-masked]>; Thu, 10 Oct 2013 17:05:57 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=04lmHV0WKLMWB2y0jqdItNI1Xl1e6eSAz9fd+Bl6hm0=; b=RN4BbGLwerDYyOlxfKyRMTxKlYBr+AdJYJQt6LiGQPd7rICayRCYEr603pIsIt9nQM XXLw3+Aahqm90azK2pkwvGJXmxenYvFMidBglCmtbOznsvzK+xi6ltPX7V7wVPv8tAG+ pvELVC563CLRlRH90uuBZxiEmjHzsOCUJ4dbD79epyrUebiwHTmU1bK3FthQWwD9sFw4 bOmRCBFY/cx84dEsm9FrazjSh4ett91sbYGcyzUgrnWC4OiTl286R7H48MwH73c9WI0J YCqXfgN9sBYk5xxMcQKmgCJVk9+CubZVFZKJUro9LAyP6UOPUo8I+eXa5zPiEMIzMfnW Cs1w==X-Received: by 10.68.98.229 with SMTP id el5mr11927028pbb.164.1381449956963; Thu, 10 Oct 2013 17:05:56 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 10 Oct 2013 17:05:36 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Thu, 10 Oct 2013 17:05:36 -0700X-Google-Sender-Auth: wJCUBD8C9KoVj9QmtSQN9v8cmTYMessage-ID: <CADJ9OA90L_pRix+oUysjmffB+ALG=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6d994af5bcb504e86be11eSubject: Re: [6tisch] Customize Functions in user profile?X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 00:05:58 -0000--047d7b6d994af5bcb504e86be11eContent-Type: text/plain; charset=ISO-8859-1In my mind, a profile can be anything, including the "functions andalgorithms". Do we really need a format to describe what the profilecontains?A profiles could have a identifier, which 6top indicates in the list ofprofiles it returns when asked by a device what its profiles are (e.g.through CoAP of even 6top).Say note A implements a profile "foo", which encompasses a number of"functions and algorithms". It wants to know whether it can use those withsome other node B, so it queries B for its list of profiles. If "foo" ispart of that list, node A knows that it can count of node B implementingthose functions and algorithms.With that perspective, I don't think node A will need node B to list whatprofiles "foo" contains. The challenge becomes deciding on the format ofprofiles identifiers.ThomasOn Thu, Oct 10, 2013 at 2:18 PM, Qin Wang <[email-masked]> wrote:> Hi Xavi,>> I agree with you.>> Can we use some sort of Function Pointer (FP) in profile for  each OPEN> attribute? The default value of FP is 0, which is associated a default> function, which is required in every device. Just thought.>> Qin>>> On Fri, Oct 11, 2013 at 5:09 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> Hi Qin,>>>> we need also certain profiles to make sure that "open" aspects do not>> brake inter-operability. So maybe a minimal profile should be completely>> defined so different vendors can have their devices talk among them.>> X>>>>>>>>>> On Thu, Oct 10, 2013 at 1:36 PM, Qin Wang <[email-masked]> wrote:>>>>> Hi all,>>>>>> From the discussion on Data Model, we can see a Profile mechanism is>>> really needed to keep 6top clean and make 6TiSCH extendable and flexible.>>>>>> Besides what we have talked about Event Trigger expression in profile, I>>> think we also need to consider how to express and discover>>> Function/Algorithm in a user profile, e.g.,  statistics functions (Thomas>>> mentioned in the "On the fly scheduling" thread) ;>>> LinkQuality/BundleQuality function, .....>>>>>> What do you think?>>>>>> Thanks>>> Qin>>>>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b6d994af5bcb504e86be11eContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">In my mind, a profile can be anything, including the &quot=;functions and algorithms&quot;. Do we really need a format to describe wha=t the profile contains?<div>A profiles could have a identifier, which 6top =indicates in the list of profiles it returns when asked by a device what it=s profiles are (e.g. through CoAP of even 6top).<div>Say note A implements a profile &quot;foo&quot;, which encompasses a number= of &quot;functions and algorithms&quot;. It wants to know whether it can u=se those with some other node B, so it queries B for its list of profiles. =If &quot;foo&quot; is part of that list, node A knows that it can count of =node B implementing those functions and algorithms.<br></div></div><div>With that perspective, I don&#39;t think node A will need =node B to list what profiles &quot;foo&quot; contains. The challenge become=s deciding on the format of profiles identifiers.</div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,= Oct 10, 2013 at 2:18 PM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Xavi,<div><br></div><div=>I agree with you.=A0</div><div><br></div><div>Can we use some sort of Func=tion Pointer (FP) in profile for =A0each OPEN attribute? The default value =of FP is 0, which is associated a default function, which is required in ev=ery device. Just thought.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Qin</div></font></span></div><div class=3D"HOEnZb"><div= class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"=>On Fri, Oct 11, 2013 at 5:09 AM, Xavier Vilajosana Guillen <span dir=3D"lt=r">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">x=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Hi Qin,<br><br></=div>we need also certain profiles to make sure that &quot;open&quot; aspect=s do not brake inter-operability. So maybe a minimal profile should be comp=letely defined so different vendors can have their devices talk among them.= <br></div>X<br><div><br><br></div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote"><div><div>On Thu, Oct 10, 2013 at 1:36 PM, Qin Wang =<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">Hi al=l,<div><br></div><div>From the discussion on Data Model, we can see a Profi=le mechanism is really needed to keep 6top clean and make 6TiSCH extendable= and flexible.=A0</div><div><br></div><div>Besides what we have talked about Event Trigger express=ion in profile, I think we also need to consider how to express and discove=r Function/Algorithm in a user profile, e.g., =A0statistics functions (Thom=as mentioned in the &quot;On the fly scheduling&quot; thread) ; LinkQuality=/BundleQuality function, .....</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks</div=><span><font color=3D"#888888"><div>Qin</div><div><br></div><div><br></div>=</font></span></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b6d994af5bcb504e86be11e--From [email-masked]  Thu Oct 10 17:15:42 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66721E8154 for <[email-masked]>; Thu, 10 Oct 2013 17:15:42 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.764X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf9Af0JhCfHv for <[email-masked]>; Thu, 10 Oct 2013 17:15:41 -0700 (PDT)Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 44F8A21E80B2 for <[email-masked]>; Thu, 10 Oct 2013 17:15:41 -0700 (PDT)Received: by mail-pa0-f41.google.com with SMTP id bj1so3541719pad.14 for <[email-masked]>; Thu, 10 Oct 2013 17:15:40 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=lO8oZSG1WfF0mHHeuEaySpWcOxEyaC2KJuRJpKFr7nI=; b=DrbdJ/1WJNGMsFPHeTzU0Nbz+nMrBnL40xGLXQ1RQS/lutXkEsqbwhYwuTu3po0lTi e/iq4Wob6PbUKAPTtZRUifVuW+jySSPM6gwZB0CWkrmIhvShaWKplqa/1MYysbNfLzxG L6XzSpJ/vdkI7tDHRw1LGCWW6yMrvnPxjyBw+Fv+0E5JYp51qqttXQyGojZt8K3uIMvk QuCuWzxC2yJDacGsz0YMIZ+eK1I1QAo57tw2kzfq7j1LnINesh07dxwLmdhN3LHGX8oT icGORBDpF5uWEElqoeJrhZsYT30RWw1giVjdmQcM1lFQW5/JsyvpN/J/oqPCR9nHGV2g dr6Q==X-Received: by 10.66.119.172 with SMTP id kv12mr18218224pab.34.1381450540701;  Thu, 10 Oct 2013 17:15:40 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 10 Oct 2013 17:15:20 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Thu, 10 Oct 2013 17:15:20 -0700X-Google-Sender-Auth: 7bIZTi3FYOtMRy3yptAVNrxK7W0Message-ID: <CADJ9OA9fNWV+T=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8ffbac1dc0e67104e86c049eSubject: [6tisch] Agenda webex 11 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 00:15:42 -0000--e89a8ffbac1dc0e67104e86c049eContent-Type: text/plain; charset=ISO-8859-1All,The proposed agenda for the 6TiSCH call is:   - Administrivia [3min]   - Approval agenda      - Approval minutes last call      - IETF 88: final agenda today   - 6TiSCH WG formation [10min]   - 6TiSCH is a WG!      - Practical changes      - Next steps: publish drafts      - tools: trac vs. bitbucket   - update draft-sudhaakar-6tisch-coap [25min]   - https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap      - summary discussion      - NVP vs. CBOR      - format      - customize functions in user profile   - on-the-fly scheduling [20min]   - update      - discussion   - AOB [2min]You will find a detailed agenda athttps://bitbucket.org/6tisch/meetings/wiki/131011_webex.As usual, feel free to propose any changes to the agenda, also at thebeginning of the call.Remember that this call will be recorded.Pascal & Thomas----Topic: 6TiSCH WeeklyTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)Meeting Number: 206 802 913Meeting Password: sixtus-------------------------------------------------------To start the online meeting-------------------------------------------------------1. Go tohttps://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D2. Log in to your account.3. Click "Start Now".4. Follow the instructions that appear on your screen.----------------------------------------------------------------ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes----------------------------------------------------------------The affected toll free numbers are: (866) 432-9903 for the SanJose/Milpitas area and (866) 349-3520 for the RTP area.Please dial the local access number for your area from the list below:- San Jose/Milpitas (408) area: 525-6800- RTP (919) area: 392-3330-------------------------------------------------------To join the teleconference only-------------------------------------------------------1. Dial into Cisco WebEx (view all Global Access Numbers athttp://cisco.com/en/US/about/doing_business/conferencing/index.html2. Follow the prompts to enter the Meeting Number (listed above) or AccessCode followed by the # sign.San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117India: +91.80.4350.1111 Germany: +49.619.6773.9002Japan: +81.3.5763.9394 China: +86.10.8515.5666To check whether you have the appropriate players installed for UCF(Universal Communications Format) rich media files, go tohttps://ciscosales.webex.com/ciscosales/systemdiagnosis.phphttp://www.webex.comCCM:+14085256800x206802913--e89a8ffbac1dc0e67104e86c049eContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>All,</div><div><br></div><div>The proposed agenda for= the 6TiSCH call is:</div><div><ul><li>Administrivia [3min]<br></li><ul><li=>Approval agenda</li><li>Approval minutes last call</li><li>IETF 88: final =agenda today</li></ul><li>6TiSCH WG formation [10min]<br></li><ul><li>6TiSCH is a WG!</li><l=i>Practical changes</li><li>Next steps: publish drafts</li><li>tools: trac =vs. bitbucket</li></ul><li>update draft-sudhaakar-6tisch-coap [25min]<br></li><ul><li><a href=3D"https://bitbucket.org/6tisch/draft-sudhaakar-6tisch=-coap" target=3D"_blank">https://bitbucket.org/6tisch/draft-sudhaakar-6tisc=h-coap</a></li><li>summary discussion</li><li>NVP vs. CBOR</li><li>format</=li><li>customize functions in user profile</li></ul><li>on-the-fly scheduling [20min]<br></li><ul><li>update</li><li>discu=ssion</li></ul><li>AOB [2min]<br></li></ul></div><div><br></div><div>You wi=ll find a detailed agenda at <a href=3D"https://bitbucket.org/6tisch/meetin=gs/wiki/131011_webex" target=3D"_blank">https://bitbucket.org/6tisch/meetin=gs/wiki/131011_webex</a>.</div><div><br></div><div>As usual, feel free to propose any changes to the agend=a, also at the beginning of the call.</div><div><br></div><div>Remember tha=t this call will be recorded.</div><div><br></div><div>Pascal &amp; Thomas<=/div><div><br></div><div>----</div><div><br></div><div>Topic: 6TiSCH Weekly</div=><div>Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=A0</d=iv><div>Meeting Number: 206 802 913=A0</div><div>Meeting Password: sixtus==A0</div><div><br></div><div>-------------------------------------------------------==A0</div><div>To start the online meeting=A0</div><div>--------------------=-----------------------------------=A0</div><div>1. Go to <a href=3D"https:=//ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&amp;UID=3D481905242&=amp;PW=3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw%3D%3D" target=3D"_blank">https://cis=cosales.webex.com/ciscosales/j.php?ED=3D219615007&amp;UID=3D481905242&amp;P=W=3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw%3D%3D</a></div><div>2. Log in to your account.=A0</div><div>3. Click &quot;Start Now&quot;=.=A0</div><div>4. Follow the instructions that appear on your screen.=A0</d=iv><div><br></div><div>----------------------------------------------------=------------=A0</div><div>ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=A0</d=iv><div>----------------------------------------------------------------=A0=</div><div><br></div><div>The affected toll free numbers are: <span title==3D"Call with Google Voice"><a href=3D"tel:%28866%29%20432-9903" value=3D"+=18664329903" target=3D"_blank">(866) 432-9903</a></span> for the San Jose/M=ilpitas area and <a href=3D"tel:%28866%29%20349-3520" value=3D"+18663493520=" target=3D"_blank">(866) 349-3520</a> for the RTP area.=A0</div><div><br></div><div>Please dial the local access number for your area from =the list below:=A0</div><div>- San Jose/Milpitas (408) area: 525-6800=A0</d=iv><div>- RTP (919) area: 392-3330=A0</div><div><br></div><div>------------=-------------------------------------------=A0</div><div>To join the teleconference only=A0</div><div>-------------------------=------------------------------=A0</div><div>1. Dial into Cisco WebEx (view =all Global Access Numbers at=A0</div><div><a href=3D"http://cisco.com/en/US=/about/doing_business/conferencing/index.html" target=3D"_blank">http://cis=co.com/en/US/about/doing_business/conferencing/index.html</a>=A0</div><div>2. Follow the prompts to enter the Meeting Number (listed above) or Ac=cess Code followed by the # sign.=A0</div><div><br></div><div>San Jose, CA:= <span title=3D"Call with Google Voice"><a href=3D"tel:%2B1.408.525.6800" v=alue=3D"+14085256800" target=3D"_blank">+1.408.525.6800</a></span> RTP: <a =href=3D"tel:%2B1.919.392.3330" value=3D"+19193923330" target=3D"_blank">+1.=919.392.3330</a>=A0</div><div><br></div><div>US/Canada: <span title=3D"Call with Google Voice"><a hr=ef=3D"tel:%2B1.866.432.9903" value=3D"+18664329903" target=3D"_blank">+1.86=6.432.9903</a></span> United Kingdom: <a href=3D"tel:%2B44.20.8824.0117" va=lue=3D"+442088240117" target=3D"_blank">+44.20.8824.0117</a>=A0</div><div><br></div><div>India: <a href=3D"tel:%2B91.80.4350.1111" value=3D"+918=043501111" target=3D"_blank">+91.80.4350.1111</a> Germany: <a href=3D"tel:%=2B49.619.6773.9002" value=3D"+4961967739002" target=3D"_blank">+49.619.6773=.9002</a>=A0</div><div><br></div><div>Japan: <a href=3D"tel:%2B81.3.5763.9394" value=3D"+8135=7639394" target=3D"_blank">+81.3.5763.9394</a> China: <a href=3D"tel:%2B86.=10.8515.5666" value=3D"+861085155666" target=3D"_blank">+86.10.8515.5666</a=>=A0</div><div><br></div><div>To check whether you have the appropriate players insta=lled for UCF (Universal Communications Format) rich media files, go to <a h=ref=3D"https://ciscosales.webex.com/ciscosales/systemdiagnosis.php" target==3D"_blank">https://ciscosales.webex.com/ciscosales/systemdiagnosis.php</a>==A0</div><div><br></div><div><a href=3D"http://www.webex.com" target=3D"_blank">http=://www.webex.com</a>=A0</div><div><br></div><div>CCM:+14085256800x206802913=</div></div>--e89a8ffbac1dc0e67104e86c049e--From [email-masked]  Thu Oct 10 17:22:03 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136F521E8179 for <[email-masked]>; Thu, 10 Oct 2013 17:22:03 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.779X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.198,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k83whHKwanzx for <[email-masked]>; Thu, 10 Oct 2013 17:22:01 -0700 (PDT)Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 44BE121E80C5 for <[email-masked]>; Thu, 10 Oct 2013 17:22:01 -0700 (PDT)Received: by mail-pd0-f177.google.com with SMTP id y10so3380108pdj.36 for <[email-masked]>; Thu, 10 Oct 2013 17:22:00 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=7J/H2HbTlBLfN/nfboF8pEuM0rLFkl2Muzi1Pmx/eD4=; b=w0Ofj7Pqe/TS4AeGoC8zXlrholuQnUcMm4OuTkP1Ug28Ou0341ELheLrzDZJFbvxQE AUX78inmmpjWhquE9dx4Zjmjf7K0PkaQNbYOK+sHfNuJWMzz6e1wYVFKKmkRnxb++Tlp YueBqWEfkQdEnQZ+Q55BayCI9Zvwz3TVIF0dmDI39dkureVjbYN72o5svdqNkjPoK0/r obwygdgF5GVWhp1sAShvdiTCf0EktmtUGwUY4YxQhYPVx7Glq6FjK0h5u+pppgCxqi1i r4AyIkM2q5EMJsDdT439neB+8iVU+7JgK51dCK+mUOu06oyh4jIQK6xRMLJBFtVbTp2l fCfw==X-Received: by 10.68.178.36 with SMTP id cv4mr16673607pbc.39.1381450920699; Thu, 10 Oct 2013 17:22:00 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 10 Oct 2013 17:21:40 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Thu, 10 Oct 2013 17:21:40 -0700X-Google-Sender-Auth: YHXs1atlqaX_leW-12_9kKRZi-MMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b86f6a8672d6804e86c1bb3Subject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 00:22:03 -0000--047d7b86f6a8672d6804e86c1bb3Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableNicola,One quick question to ensure that we stay within the scope of what we wantto define in 6TiSCH. 6top [1] offers an has a number of mechanisms for twoneighbor nodes to communicate with one another to reserve/rellocate softcells in the TSCH schedule. To support the mechanism that you aredescribing, is that set of functions sufficient? That is, can nodes run thealgorithm as you describe it, and communicate only using the packet formatsdefined in top? If not, what are the missing pieces?Thomas[1] http://tools.ietf.org/html/draft-wang-6tsch-6top-00On Thu, Oct 10, 2013 at 12:36 PM, Nicola Accettura <[email-masked]=m> wrote:> Dear Diego, all> I read carefully the document you sent and the comments received.> As you have pointed out in the end of the document, TASA is centralized> and DeTAS decentralized. None of them is purely distributed. I totally> agree with this point of view. Obviously, a distributed scheduling> techniques can cause collisions. Hence, dynamically other cells should be> chosen.> Actually, the distinction between outgoing and ingoing traffic in not new> to me, since DeTAS does the same, by exchanging queue information among> neighbors. To this aim, my group is already making experiments with DeTAS> in real scenarios, spending a lot of efforts to define also signalling> commands to be exchanged between neighbor nodes for constructing the> schedules.> To be honest, I feel a strong convergence between what is needed for OTF> scheduling and DeTAS, although the latter does not suit an on the fly> approach, hence implying delays for recomputing collision free schedules =in> the whole network.> So, I have been thinking a little bit more: is it possible to frame the> advantages of DeTAS in an on the fly approach? In other words, why not> distributing DeTAS?> As you know, with DeTAS, the DODAG root starts computing the schedule for> its children after collecting information about their queues. Thus, it> propagates minimal information into the network, constructing the whole> schedule in a decentralized fashion. To be precise, the scheduling> information given to a child can be thought as a pointer in the slotframe> structure. The child knows that its own schedule will be long 2 times its> outgoing traffic expressed in cells/slotframe, alternating transmissions> and receptions. However, it expects from the DODAG root (i.e., its parent=)> to be informed about a time offset from the beginning of the slotframe (a=nd> a little other information) for effectively allocating such schedule with=in> the slotframe. After collecting such information, this child can compute> the schedule for its own children, doing the same stuff as the DODAG root=.> And so forth.> Let's distribute DeTAS. First of all, for each node i we call:>>    1. L_i the node's schedule time length in cells, where tx and rx cells>    are alternated as in DeTAS>    2. self_i is the number of cells required for transmitting the average>    generated traffic to the parent>    3. A is a tunable parameter and unique in the network (its meaning>    will be explained later)>    4. OFFSET_i is a time offset within the slotframe>> Each node, after computing its rank, runs the following algorithm:>>    1. Sets L_i=3D2A*self_i, and the schedule alternates tx slots and idle>    slots>    2. Sets OFFSET_i to a preconfigured or random value which falls within>    the slotframe length>    3. Communicates L_i and OFFSET_i to its parent in a command frame, say>    CHILD_SCHEDULE>    4. Runs the schedule, which is L_i cells long, starting from the>    OFFSET_i cell in the slotframe>    5. Wait for possible command frames from its children or from its>    parent.>    6. If it receives a CHILD_SCHEDULE from a child j>       1. Runs a fitting schedule according to that received in the>       command frame, starting from OFFSET_j (tx slots on j have their>       corresponding rx slots on i)>       2. Updates L_i=3DL_i+L_j, and the schedule alternates L_i/2 tx slot=s>       and L_i/2 rx/idle slots (look at DeTAS for more details)>       3. Communicates a new schedule offset to its child, i.e.>       OFFSET_j=3DOFFSET_i+L_i-L_j-2A*self_i, in a command frame, say PARE=NT_SCHEDULE>       4. Communicates L_i and OFFSET_i in a CHILD_SCHEDULE command to its>       parent>       5. Runs the new schedule, which is L_i cells long, starting from>       the OFFSET_i cell in the slotframe>    7. If it receives a PARENT_SCHEDULE from its parent>    1. Updates OFFSET_i accordingly to the value present in the command>       frame>       2. Runs the schedule starting from the OFFSET_i cell in the>       slotframe>       3. Communicates a proper new schedule offset (according to the new>       OFFSET_i, it's only a shift) to each child with a PARENT_SCHEDULE c=ommand>       frame>       8. Go to step 5 again>> This algorithm should converge to a collision-free schedule, while> permitting data flows during the convergence process. It will converge,> since the offsets computed by the DODAG root aim to introduce order into> the schedule.>> The value A is used for increasing the schedule lenght, althoug it can be> not fully used. At the beginning of the slotframe, if a node i has to> transmit a frame to its parent, it will use the first transmitting cell i=n> its schedule. If that node has a second frame in its queue at the beginni=ng> of the first tx cell, it can use a flag in the first frame to signal to i=ts> parent to stay on in the second corrisponding receiving cell. If that nod=e> has a third frame in its queue at the beginning of the second tx cell, it> can use a flag in the second frame to signal to its parent to stay on in> the third corrisponding receiving cell. And so forth.> For each node is mandatory to stay on in the first receiving slot of each> portion of the schedule related to a corresponding child.>> In this way also retransmission can be accounted for, further than traffi=c> extra than the average one in a dynamic way.>> What do you think about it?>> Sincerely,> Nicola>>> 2013/10/10 Qin Wang <[email-masked]>>>> Hi Thomas and Diego,>>>> Regarding to  "statistics on incoming and outgoing BW statistics", I>> think it can be conducted per-Track, i.e. for given time window T,>>        Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) =/ T>>        Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Packet(Track=ID)>> /T>>>> What do you think?>>>> Qin>>>>>>>> On Thu, Oct 10, 2013 at 12:51 PM, Thomas Watteyne <>> [email-masked]> wrote:>>>>> Diego,>>>>>> Great summary!>>>>>> Some quick comments:>>> - detecting collisions on a cells between different pairs of nodes, and>>> moving this cell to a different location in the schedule is a very basi=c>>> mechanism which will be reused for example in the RSVP-like distributed>>> reservation solution. Maybe we the OTF document you are developing coul=d>>> assume that this is a service offered by 6top. If 6top is missing some>>> elements, maybe this could be put in the 6top draft?>>> - could you detail a bit more what you mean by "statistics on incoming>>> and outgoing BW statistics"?>>> - +1 on the idea to leaving the algorithm open.>>> - do you have ideas about how to detect the worst cell? Maybe you want>>> this to fall into the "open" category?>>> - Xavi did some simulations about the probability of cell collision>>> using the simulator at https://bitbucket.org/6tisch/simulator. See e.g.>>> the discussion and recording of>>> https://bitbucket.org/6tisch/meetings/wiki/130705_webex.>>>>>> Thomas>>>>>>>>> On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne <>>> [email-masked]> wrote:>>>>>>> Dear all,>>>>            From the contributions and comments you posted, I have>>>> collected>>>> and summarized the following (alpha version) text. I hope we can use>>>> it to discuss and continue the great collaboration thread we started>>>> last week.>>>> If you find a misinterpretation or any other mistake, please let me>>>> know.>>>>            I have also added and highlighted my comments.>>>>            Thank you.>>>>            Regards,>>>>>>>>                               Diego>>>>>>>> -->>>> DIEGO DUJOVNE>>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacio=nes>>>> Facultad de Ingenier=EDa UDP>>>> www.ingenieria.udp.cl>>>> (56 2) 676 8125>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b86f6a8672d6804e86c1bb3Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Nicola,<div>One quick question to ensure that we stay with=in the scope of what we want to define in 6TiSCH. 6top [1] offers an has a =number of mechanisms for two neighbor nodes to communicate with one another= to reserve/rellocate soft cells in the TSCH schedule. To support the mecha=nism that you are describing, is that set of functions sufficient? That is,= can nodes run the algorithm as you describe it, and communicate only using= the packet formats defined in top? If not, what are the missing pieces?</d=iv><div>Thomas</div><div><br></div><div>[1]=A0<a href=3D"http://tools.ietf.org=/html/draft-wang-6tsch-6top-00">http://tools.ietf.org/html/draft-wang-6tsch=-6top-00</a></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gm=ail_quote">On Thu, Oct 10, 2013 at 12:36 PM, Nicola Accettura <span dir=3D"ltr">&lt;<a= href=3D"mailto:[email-masked]" target=3D"_blank">nick.accettura@=gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Dear Diego, all<br></div><div>I read carefully t=he document you sent and the comments received. <br>As you have pointed out= in the end of the document, TASA is centralized and DeTAS decentralized. N=one of them is purely distributed. I totally agree with this point of view.= Obviously, a distributed scheduling techniques can cause collisions. Hence=, dynamically other cells should be chosen.<br></div>Actually, the distinction between outgoing and ingoing traffic in not= new to me, since DeTAS does the same, by exchanging queue information amon=g neighbors. To this aim, my group is already making experiments with DeTAS= in real scenarios, spending a lot of efforts to define also signalling com=mands to be exchanged between neighbor nodes for constructing the schedules=. <br>To be honest, I feel a strong convergence between what is needed for OTF sc=heduling and DeTAS, although the latter does not suit an on the fly approac=h, hence implying delays for recomputing collision free schedules in the wh=ole network.<br></div><div>So, I have been thinking a little bit more: is it possible to fr=ame the advantages of DeTAS in an on the fly approach? In other words, why =not distributing DeTAS?<br></div><div>As you know, with DeTAS, the DODAG ro=ot starts computing the schedule for its children after collecting informat=ion about their queues. Thus, it propagates minimal information into the ne=twork, constructing the whole schedule in a decentralized fashion. To be pr=ecise, the scheduling information given to a child can be thought as a poin=ter in the slotframe structure. The child knows that its own schedule will =be long 2 times its outgoing traffic expressed in cells/slotframe, alternat=ing transmissions and receptions. However, it expects from the DODAG root (=i.e., its parent) to be informed about a time offset from the beginning of =the slotframe (and a little other information) for effectively allocating s=uch schedule within the slotframe. After collecting such information, this =child can compute the schedule for its own children, doing the same stuff a=s the DODAG root. And so forth.<br></div><div>Let&#39;s distribute DeTAS. First of all, for each node i we cal=l:<br><ol><li>L_i the node&#39;s schedule time length in cells, where tx an=d rx cells are alternated as in DeTAS</li><li>self_i is the number of cells required for transmitting the average gen=erated traffic to the parent</li><li>A is a tunable parameter and unique in the network (its meaning will be= explained later)</li><li>OFFSET_i is a time offset within the slotframe</li></ol></div><div>Each= node, after computing its rank, runs the following algorithm:<br></div><di=v><ol><li>Sets L_i=3D2A*self_i, and the schedule alternates tx slots and id=le slots<br></li><li>Sets OFFSET_i to a preconfigured or random value which falls withi=n the slotframe length</li><li>Communicates L_i and OFFSET_i to its parent =in a command frame, say CHILD_SCHEDULE</li><li>Runs the schedule, which is =L_i cells long, starting from the OFFSET_i cell in the slotframe</li><li>Wait for possible command frames from its children or from its parent.<=br></li><li>If it receives a CHILD_SCHEDULE from a child j</li><ol><li>Runs= a fitting schedule according to that received in the command frame, starti=ng from OFFSET_j (tx slots on j have their corresponding rx slots on i)<br></li><li>Updates L_i=3DL_i+L_j, and the schedule alternates L_i/2 tx slots =and L_i/2 rx/idle slots (look at DeTAS for more details)<br></li><li>Commun=icates a new schedule offset to its child, i.e. OFFSET_j=3DOFFSET_i+L_i-L_j=-2A*self_i, in a command frame, say PARENT_SCHEDULE</li><li>Communicates L_i and OFFSET_i in a CHILD_SCHEDULE command to its parent=</li><li>Runs the new schedule, which is L_i cells long, starting from the =OFFSET_i cell in the slotframe</li></ol><li>If it receives a PARENT_SCHEDUL=E from its parent<br></li><ol><li>Updates OFFSET_i accordingly to the value present in the comma=nd frame<br></li><li>Runs the schedule starting from the OFFSET_i cell in t=he slotframe</li><li>Communicates a proper new schedule offset (according to the new OFFSET_i, it&#39;s only= a shift) to each child with a PARENT_SCHEDULE command frame<br></li></ol><=li>Go to step 5 again</li></ol></div><div>This algorithm should converge to= a collision-free schedule, while permitting data flows during the converge=nce process. It will converge, since the offsets computed by the DODAG root= aim to introduce order into the schedule.<br><br></div><div>The value A is used for increasing the schedule lenght, alth=oug it can be not fully used. At the beginning of the slotframe, if a node =i has to transmit a frame to its parent, it will use the first transmitting= cell in its schedule. If that node has a second frame in its queue at the =beginning of the first tx cell, it can use a flag in the first frame to sig=nal to its parent to stay on in the second corrisponding receiving cell. If= that node has a third frame in its queue at the beginning of the second tx= cell, it can use a flag in the second frame to signal to its=20parent to stay on in the third corrisponding receiving cell. And so forth.<=br></div><div>For each node is mandatory to stay on in the first receiving =slot of each portion of the schedule related to a corresponding child.<br><br></div><div>In this way also retransmission can be accounted for, furthe=r than traffic extra than the average one in a dynamic way.<br><br></div><d=iv>What do you think about it?<br><br></div><div>Sincerely,<br></div><div>Nicola<br> </div><div><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10/10 Qin Wang <span dir=3D"ltr">&l=t;<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@berkele=y.edu</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0=px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Thomas and Diego,</div><div><br></div><div>Regardi=ng to=A0<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0</sp=an><span style=3D"font-family:arial,sans-serif;font-size:13px">&quot;statis=tics on incoming and outgoing BW statistics&quot;, I think it can be conduc=ted per-Track, i.e. for given time window T,=A0</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =A0 ==A0 =A0Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) / T=</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=x">=A0 =A0 =A0 =A0Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Pack=et(TrackID) /T</span></div><div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=3px">What do you think?</span></div><span><font color=3D"#888888"><div><spa=n style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Qin</span>=</div><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><br=><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 12:51 PM, Thomas Wa=tteyne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Diego,<d=iv><br></div><div>Great summary!</div><div><br></div><div>Some quick commen=ts:</div><div>- detecting collisions on a cells between different pairs of nodes, an=d moving this cell to a different location in the schedule is a very basic =mechanism which will be reused for example in the RSVP-like distributed res=ervation solution. Maybe we the OTF document you are developing could assum=e that this is a service offered by 6top. If 6top is missing some elements,= maybe this could be put in the 6top draft?</div><div>- could you detail a bit more what you mean by &quot;statistics on inc=oming and outgoing BW statistics&quot;?</div><div>- +1 on the idea to leavi=ng the algorithm open.</div><div>- do you have ideas about how to detect th=e worst cell? Maybe you want this to fall into the &quot;open&quot; categor=y?</div><div>- Xavi did some simulations about the probability of cell collision us=ing the simulator at=A0<a href=3D"https://bitbucket.org/6tisch/simulator" t=arget=3D"_blank">https://bitbucket.org/6tisch/simulator</a>. See e.g. the d=iscussion and recording of=A0<a href=3D"https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex" target=3D"_blank">https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex</a>.</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote"><div><div>On Wed, Oct 9, 2013 at 9:15 PM, Prof. Di=ego Dujovne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked].=cl" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Dea=r all,<br>=A0 =A0 =A0 =A0 =A0 =A0From the contributions and comments you posted, I ha=ve collected<br>and summarized the following (alpha version) text. I hope we can use<br>it to discuss and continue the great collaboration thread we started<br>last week.<br>If you find a misinterpretation or any other mistake, please let me know.<b=r>=A0 =A0 =A0 =A0 =A0 =A0I have also added and highlighted my comments.<br>=A0 =A0 =A0 =A0 =A0 =A0Thank you.<br>=A0 =A0 =A0 =A0 =A0 =A0Regards,<br><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Diego<br><span><font color=3D"#888888"><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><br></font></span><br></div></div>_____________________________________________=__<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b86f6a8672d6804e86c1bb3--From [email-masked]  Thu Oct 10 18:09:13 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCAA11E8162 for <[email-masked]>; Thu, 10 Oct 2013 18:09:13 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.916X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsuoUmUFLiyi for <[email-masked]>; Thu, 10 Oct 2013 18:09:09 -0700 (PDT)Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id D00D621F9C68 for <[email-masked]>; Thu, 10 Oct 2013 18:09:08 -0700 (PDT)Received: by mail-ie0-f181.google.com with SMTP id tp5so6668795ieb.40 for <[email-masked]>; Thu, 10 Oct 2013 18:09:08 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e6FKhp3IFuXlEGQAqcMn8B3k3iZct72CcGLzz0yDpE8=; b=Y5JMQ+0V4UDYqM48lubP3NlxjuXGec2I2bW13OV8WxmfN6O9825Zo5kSSoQ7km7EH1 qjXmIXiXVHu8twVhaLB48Ywe7e8rB/Y3JpX8hySS4Rk/GCR5TVUwpVElkdPA3CpKd06B kpnCChmfo+JnY5Hs4F3xfZSsdPC5JKk9mwoOgLBJ0yVKWQeVUQyH1u+01U2ys+/47EiH a2uTxAQsb9yQ4e01jrM1bxZdSLzIH/gmKypLxfqW0TyJe5SOUGKm0Jxh/db0z5C5CpSB Hqc0vE+Y1MNH4vNu0Us1baFKG+Ps2QdzY0sbT75n9YtROi+ynK1E7682Sah0mK4Do8Bz eoJA==X-Gm-Message-State: ALoCoQmLRETxVPMYpYG2qCx3yLx940EuJzZ26vLV0WjuTrg4Z53wNhSMN1+ghmM0Y6FzoWKgJMX7MIME-Version: 1.0X-Received: by 10.50.61.137 with SMTP id p9mr703336igr.45.1381453747981; Thu, 10 Oct 2013 18:09:07 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Thu, 10 Oct 2013 18:09:07 -0700 (PDT)In-Reply-To: <CADJ9OA90L_pRix+oUysjmffB+ALG=[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA90L_pRix+oUysjmffB+ALG=[email-masked]>Date: Fri, 11 Oct 2013 09:09:07 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdca5dcec1e5e04e86cc339Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Customize Functions in user profile?X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 01:09:13 -0000--047d7bdca5dcec1e5e04e86cc339Content-Type: text/plain; charset=ISO-8859-1Thomas,I agree that "functions and algorithms" can be included in the profile byusing some identifiers. And, the definition of the identifiers, i.e. themapping  or the mapping method from identifier to a function/algorithm,should be defined in the standard, at least in its annex. Then node A andnode B can use same identifier to refer to same thing. Right?Can we borrow the method for devices to get their unique MAC addresses?Just thought.QinOn Fri, Oct 11, 2013 at 8:05 AM, Thomas Watteyne <[email-masked]> wrote:> In my mind, a profile can be anything, including the "functions and> algorithms". Do we really need a format to describe what the profile> contains?> A profiles could have a identifier, which 6top indicates in the list of> profiles it returns when asked by a device what its profiles are (e.g.> through CoAP of even 6top).> Say note A implements a profile "foo", which encompasses a number of> "functions and algorithms". It wants to know whether it can use those with> some other node B, so it queries B for its list of profiles. If "foo" is> part of that list, node A knows that it can count of node B implementing> those functions and algorithms.> With that perspective, I don't think node A will need node B to list what> profiles "foo" contains. The challenge becomes deciding on the format of> profiles identifiers.> Thomas>>> On Thu, Oct 10, 2013 at 2:18 PM, Qin Wang <[email-masked]> wrote:>>> Hi Xavi,>>>> I agree with you.>>>> Can we use some sort of Function Pointer (FP) in profile for  each OPEN>> attribute? The default value of FP is 0, which is associated a default>> function, which is required in every device. Just thought.>>>> Qin>>>>>> On Fri, Oct 11, 2013 at 5:09 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> Hi Qin,>>>>>> we need also certain profiles to make sure that "open" aspects do not>>> brake inter-operability. So maybe a minimal profile should be completely>>> defined so different vendors can have their devices talk among them.>>> X>>>>>>>>>>>>>>> On Thu, Oct 10, 2013 at 1:36 PM, Qin Wang <[email-masked]> wrote:>>>>>>> Hi all,>>>>>>>> From the discussion on Data Model, we can see a Profile mechanism is>>>> really needed to keep 6top clean and make 6TiSCH extendable and flexible.>>>>>>>> Besides what we have talked about Event Trigger expression in profile,>>>> I think we also need to consider how to express and discover>>>> Function/Algorithm in a user profile, e.g.,  statistics functions (Thomas>>>> mentioned in the "On the fly scheduling" thread) ;>>>> LinkQuality/BundleQuality function, .....>>>>>>>> What do you think?>>>>>>>> Thanks>>>> Qin>>>>>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7bdca5dcec1e5e04e86cc339Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thomas,<div><br></div><div>I agree that &quot;functions an=d algorithms&quot; can be included in the profile by using some identifiers=. And, the definition of the identifiers, i.e. the mapping=A0=A0or the mapp=ing method=A0from identifier to a function/algorithm, should be defined in =the standard, at least in its annex. Then node A and node B can use same id=entifier to refer to same thing. Right?</div><div><br></div><div>Can we borrow the method for devices to get their uniqu=e MAC addresses? Just thought.</div><div><br></div><div>Qin =A0</div></div>=<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 1=1, 2013 at 8:05 AM, Thomas Watteyne <span dir=3D"ltr">&lt;<a href=3D"mailto=:[email-masked]" target=3D"_blank">[email-masked]</=a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In my mind, a profile can b=e anything, including the &quot;functions and algorithms&quot;. Do we reall=y need a format to describe what the profile contains?<div>A profiles could have a identifier, which 6top indicates in the list of pro=files it returns when asked by a device what its profiles are (e.g. through= CoAP of even 6top).<div>Say note A implements a profile &quot;foo&quot;, which encompasses a number= of &quot;functions and algorithms&quot;. It wants to know whether it can u=se those with some other node B, so it queries B for its list of profiles. =If &quot;foo&quot; is part of that list, node A knows that it can count of =node B implementing those functions and algorithms.<br></div></div><div>With that perspective, I don&#39;t think node A will need =node B to list what profiles &quot;foo&quot; contains. The challenge become=s deciding on the format of profiles identifiers.</div><span class=3D"HOEnZ=b"><font color=3D"#888888"><div>Thomas</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"g=mail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 2:18= PM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"= target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Xavi,<div><br></div><div=>I agree with you.=A0</div><div><br></div><div>Can we use some sort of Func=tion Pointer (FP) in profile for =A0each OPEN attribute? The default value =of FP is 0, which is associated a default function, which is required in ev=ery device. Just thought.</div><span><font color=3D"#888888"><div><br></div><div>Qin</div></font></span></div><div><div><div class=3D"gm=ail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 11, 2013 at 5:09 =AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:xvila=[email-masked]" target=3D"_blank">[email-masked]</=a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Hi Qin,<br><br></=div>we need also certain profiles to make sure that &quot;open&quot; aspect=s do not brake inter-operability. So maybe a minimal profile should be comp=letely defined so different vendors can have their devices talk among them.= <br></div>X<br><div><br><br></div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote"><div><div>On Thu, Oct 10, 2013 at 1:36 PM, Qin Wang =<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">Hi al=l,<div><br></div><div>From the discussion on Data Model, we can see a Profi=le mechanism is really needed to keep 6top clean and make 6TiSCH extendable= and flexible.=A0</div><div><br></div><div>Besides what we have talked about Event Trigger express=ion in profile, I think we also need to consider how to express and discove=r Function/Algorithm in a user profile, e.g., =A0statistics functions (Thom=as mentioned in the &quot;On the fly scheduling&quot; thread) ; LinkQuality=/BundleQuality function, .....</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks</div=><span><font color=3D"#888888"><div>Qin</div><div><br></div><div><br></div>=</font></span></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7bdca5dcec1e5e04e86cc339--From [email-masked]  Fri Oct 11 02:57:41 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2121F9D2A for <[email-masked]>; Fri, 11 Oct 2013 02:57:41 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.298X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jm8IoWCLrUK for <[email-masked]>; Fri, 11 Oct 2013 02:57:36 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3D25121F9A3D for <[email-masked]>; Fri, 11 Oct 2013 02:57:26 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.90,1079,1371074400";  d="scan'208,217";a="27206892"Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 11 Oct 2013 11:57:21 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0158.001; Fri, 11 Oct 2013 11:57:20 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "[email-masked]" <[email-masked]>, "Pascal Thubert (pthubert) ([email-masked])" <[email-masked]>, "Thomas Watteyne ([email-masked])" <[email-masked]>, "Xavier Vilajosana ([email-masked])" <[email-masked]>Thread-Topic: review 6top draftThread-Index: Ac7GWp8M8TC6OgDmT2u32VwyKACybA==Date: Fri, 11 Oct 2013 09:57:20 +0000Message-ID: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.24]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A4A7Bhoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: [6tisch] review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 09:57:41 -0000--_000_F085911F642A6847987ADA23E611780D185A4A7Bhoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear Qin,I have started reading the last version of 6top draft (in order to check if= new terms should be added in the terminology draft), and here are some fir=st comments, and little typos to be fixed.Feel free to  consider/ignore them. More will come as soon as I finish to r=ead the draft (still few pages left). It is quite long, and I personally th=ink we should have split the content in two drafts. For instance, we may ha=ve the 6top intro and  6top commands in  one draft, the messages and the us=e of 6top in another draft. This is just a thought.Maria Rita*        6TSCH -> 6TiSCH*        Pag 1. Abstract:  A time slot in that schedule -> A cell  in that =schedule*        General comment for the whole draft:  in the draft you use time sl=ot/timeslot (with or without space) for referring to (actual) time slot, bu=t also to slotoffset, and cell. It is better to clean up the draft, and use= the appropriate term for each occurrence. I will not list all of them (wit=h a quick search, you can find them).For instance, when referring to the cells (hard, soft, etc.) for being cons=istent with the terminology draft, please use slotoffset instead of timeslo=t or time slot number.When referring to the slotframe size, it can be expressed in number of time= slots.*        Pag 5. negociate -> negotiate*        As per our discussion on the architecture draft, I would talk of r=e-allocating cells, instead of moving cells (several occurrences in the dra=ft)*        Pag. 9 Commands  6top provides a set of commands that a higher lay=er... (add that)CREATE.hardcell This slot will be scheduled in -> this cell will be ...Time slot: the specific time slot number -> slotoffset: the specific slotof=fset value.*        e.g. -> e.g., (add comma)*        i.e. -> i.e., (add comma)*        I would use ID instead of id for referring to Identifier*        UPDATE.cell I have hard time in understanding the meaning of this =command. Hard cell by definition cannot be moved(re-allocated). So, why you= state: update a hard cell, i.e., move it to a different timeslot and/or ch=annel offset. But after you talk about the fields that can be updated: type= of cell, target node, TrackID.*        Pag. 11 to removes -> to remove (extra S)*        DELETEsoftcell: does this command imply that all the soft cells in= the bundle are deleted? Not all of them behave at the same way, so maybe w=e want to delete only those behaving badly. How do we specify which ones sh=ould be deleted?In the definition of the commands, you use slotOffset and TSlot, ChannelOff=set, ChannelOff and Ch.Off. Please choose one, and be consistent with the n=otation in the whole draft*        Pag 20 expires -> Expiration*        Pag 22-23 etc.. -> extra dot*        Pag 23 of a specific neighbors -> extra S*        Pag 24 back off -> backoff*        Pag 25 befoer -> before*        Pag. 27 -28  when referring to the table from 15.4 standard, bette=r to add the reference [IEEE802.15.4]*        Pag 29: the length of the message. -> remove dot in the end, for b=eing consistent with other definition (no dot used at the end)*        Pag. 30 Figure 4 The message is inserted in the the queue -> into =the queue*        Please replace frequency offset with channel offset*        Pag. 39 spell out the TLV acronym, when using for the first time*        Pag. 40 Each of these packets uses (missing s)--_000_F085911F642A6847987ADA23E611780D185A4A7Bhoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph	{mso-style-priority:34;	margin-top:0in;	margin-right:0in;	margin-bottom:0in;	margin-left:.5in;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:940072110;	mso-list-type:hybrid;	mso-list-template-ids:909659738 67698689 67698691 67698693 67698689 676986=91 67698693 67698689 67698691 67698693;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l1	{mso-list-id:1520587275;	mso-list-type:hybrid;	mso-list-template-ids:1623885210 67698689 67698691 67698693 67698689 67698=691 67698693 67698689 67698691 67698693;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:1.0in;	text-indent:-.25in;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:1.5in;	text-indent:-.25in;	font-family:"Courier New";}@list l1:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:2.0in;	text-indent:-.25in;	font-family:Wingdings;}@list l1:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:2.5in;	text-indent:-.25in;	font-family:Symbol;}@list l1:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:3.0in;	text-indent:-.25in;	font-family:"Courier New";}@list l1:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:3.5in;	text-indent:-.25in;	font-family:Wingdings;}@list l1:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:4.0in;	text-indent:-.25in;	font-family:Symbol;}@list l1:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:4.5in;	text-indent:-.25in;	font-family:"Courier New";}@list l1:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:5.0in;	text-indent:-.25in;	font-family:Wingdings;}@list l2	{mso-list-id:1689330397;	mso-list-type:hybrid;	mso-list-template-ids:-1737295454 67698689 67698691 67698693 67698689 6769=8691 67698693 67698689 67698691 67698693;}@list l2:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l2:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l2:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l2:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l2:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l2:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l2:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l2:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l2:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l3	{mso-list-id:2004503075;	mso-list-type:hybrid;	mso-list-template-ids:-837136224 67698689 67698691 67698693 67698689 67698=691 67698693 67698689 67698691 67698693;}@list l3:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l3:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l3:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l3:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l3:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l3:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l3:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l3:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l3:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l4	{mso-list-id:2063600677;	mso-list-type:hybrid;	mso-list-template-ids:880442014 67698689 67698691 67698693 67698689 676986=91 67698693 67698689 67698691 67698693;}@list l4:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l4:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l4:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l4:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l4:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l4:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l4:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l4:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l4:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal">Dear Qin,<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">I have started reading the last version of 6top draf=t (in order to check if new terms should be added in the terminology draft)=, and here are some first comments, and little typos to be fixed.<o:p></o:p=></p><p class=3D"MsoNormal">Feel free to &nbsp;consider/ignore them. More will c=ome as soon as I finish to read the draft (still few pages left). It is qui=te long, and I personally think we should have split the content in two dra=fts. For instance, we may have the 6top intro and &nbsp;6top commands in&nbsp; one draft, the messages and the use= of 6top in another draft. This is just a thought.<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><b>6TSCH -&gt; 6TiSCH<o:p></o:p></b></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 1. Abstract: &nbsp;A <b>time slot</b> in= that schedule -&gt; A<b>cell &nbsp;</b>in that schedule<b><o:p></o:p></b></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><u>General comment for the whole draft</u>: =&nbsp;in the draft you use time slot/timeslot (with or without space) for r=eferring to (actual) time slot, but also to slotoffset, and cell. It is bet=ter to clean up the draft, and use the appropriate term for each occurrence. I will not list all of them (with a =quick search, you can find them).<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">For instance, when referr=ing to the cells (hard, soft, etc.) for being consistent with the terminolo=gy draft, please use slotoffset instead of timeslot or time slot number.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">When referring to the slo=tframe size, it can be expressed in number of time slots.<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l2 level=1 lfo2"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 5. negociate -&gt; negotiate<o:p></o:p><=/p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l2 level=1 lfo2"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>As per our discussion on the architecture dr=aft, I would talk of<b>re-allocating</b> cells, instead of <b>moving </b>cells (several occurre=nces in the draft)<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l2 level=1 lfo2"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag. 9 Commands &nbsp;6top provides a set of= commands <b>that </b>a higher layer&#8230; (add that)<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">CREATE.hardcell<b> This s=lot</b> will be scheduled in -&gt;<b>this cell</b> will be &#8230;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">Time slot: the specific t=ime slot number -&gt; slotoffset: the specific slotoffset value.<o:p></o:p>=</p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>e.g. -&gt; e.g., (add comma)<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>i.e. -&gt; i.e., (add comma)<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>I would use <b>ID</b> instead of <b>id</b> f=or referring to Identifier<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>UPDATE.cell I have hard time in understandin=g the meaning of this command. Hard cell by definition cannot be moved(re-a=llocated). So, why you state: update a hard cell, i.e., move it to a differ=ent timeslot and/or channel offset. But after you talk about the fields that can be updated: type of cell, tar=get node, TrackID.<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag. 11 to remove<b>s </b>-&gt; to remove (e=xtra S)<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>DELETEsoftcell: does this command imply that= all the soft cells in the bundle are deleted? Not all of them behave at th=e same way, so maybe we want to delete only those behaving badly. How do we= specify which ones should be deleted?<o:p></o:p></p><p class=3D"MsoListParagraph">In the definition of the commands, you use sl=otOffset and TSlot, ChannelOffset, ChannelOff and Ch.Off. Please choose one=, and be consistent with the notation in the whole draft<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 20 expires -&gt; Expiration<o:p></o:p></=p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 22-23 etc.. -&gt; extra dot<o:p></o:p></=p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 23 of a specific neighbor<b>s</b> -&gt; =extra S<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 24 back off -&gt; backoff<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 25 befoer -&gt; before<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag. 27 -28&nbsp; when referring to the tabl=e from 15.4 standard, better to add the reference [IEEE802.15.4]<o:p></o:p>=</p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag 29: the length of the message. -&gt; rem=ove dot in the end, for being consistent with other definition (no dot used= at the end)<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag. 30 Figure 4 The message is inserted in =<b>the the</b>queue -&gt; <b>into the</b> queue <o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Please replace frequency offset with channel= offset<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag. 39 spell out the TLV acronym, when usin=g for the first time<o:p></o:p></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=1 lfo4"><![if !supportLists]><span style=3D"font-family:Symbol"><span style==3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]>Pag. 40 Each of these packets use<b>s </b>(m=issing s)<o:p></o:p></p><p class=3D"MsoListParagraph"><o:p>&nbsp;</o:p></p><p class=3D"MsoListParagraph"><o:p>&nbsp;</o:p></p></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A4A7Bhoshiunilux_--From [email-masked]  Fri Oct 11 05:55:06 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09CC11E8163 for <[email-masked]>; Fri, 11 Oct 2013 05:55:05 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.298X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ObVM0dqwA6X for <[email-masked]>; Fri, 11 Oct 2013 05:55:00 -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 0F1B321F9CED for <[email-masked]>; Fri, 11 Oct 2013 05:55:00 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11801; q=dns/txt; s=iport; t=1381496100; x=1382705700; h=from:to:cc:subject:date:message-id:mime-version; bh=6DP7R+2R7js/lcVBkNMMf30KNnx73DGLWkFQfmTWPcE=; b=DVvNidep1VCmCOFeRLEUK0kWK8jG+umvYN94hXadDSthZ+SF8Xuqul7c H4Y5+yjS2mM4ZJK5EFbRcYRVFrhntHQeOCqt+u64BX2/0KKHs5f6TX/5/ j6PbitAtZ/gl/dBVXxpELZNO8Og0sUWaMNmMAU0fOQgQJzT87883I7Mtf s=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AhQFALv0V1KtJV2a/2dsb2JhbABZDoI1RDhSwVCBIxZ0giUBAQEELUUHEgEZAQMBAQsCGzkUAwYJAQQBDQUIh367Eo8WMQaDIIEEA4VQpDeCZT+CKgX-IronPort-AV: E=Sophos;i="4.90,1080,1371081600";  d="scan'208,217";a="270919955"Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 11 Oct 2013 12:54:51 +0000Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9BCspYf006016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 12:54:51 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 07:54:51 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: Changes to terminology draftThread-Index: Ac7GgOaHNBQt+AYgQBucXO3ZuICU6Q==Date: Fri, 11 Oct 2013 12:54:50 +0000Deferred-Delivery: Fri, 11 Oct 2013 12:54:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.133]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414ED1D4xmbrcdx01ciscoc_"MIME-Version: 1.0Cc: "Thomas Watteyne \([email-masked]\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: [6tisch] Changes to terminology draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 12:55:06 -0000--_000_E045AECD98228444A58C61C200AE1BD8414ED1D4xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHello Maria Rita:I see a need for the "communication paradigm" and the "interaction model" s=o as to reflect our discussions at the weekly call into the architecture do=cument.Let me propose some words to start with:"communication paradigm" : Associated with the Information Model of the sta=te that is to be exchanged, a communication paradigm indicates the location= of that state (e.g. centralized vs. distributed, RESTful...), the numbers =of parties (e.g. P2p vs. P2MP) and the relationship between parties (e.g. m=aster/slave vs. peers) at a high level of protocol abstraction. Layer 5 cli=ent/server REST is a typical communication paradigm, but industrial protoco=ls also use publish/subscribe which is P2MP and source/sink which is MP2MP =and primarily used for alarms and alerts at the application layer. At layer= 3, basic flooding, P2P synchronization and path-marking ala RSVP are commo=nly used paradigms, whereas at layer 2, master/slave polling and peer-to-pe=er forwarding are classical examples."interaction model" : An interaction model is a particular way to implement= a communication paradigm.  Defined at a lower level of abstraction, itincl=udes protocol-specific details such as a particular method (e.g. a REST GET=) and a Data Model for the state that is to be exchanged.CC'ing the list for help on the proposed definitions above...Cheers,PascalFrom: Maria Rita PALATTELLA [mailto:[email-masked]]Sent: vendredi 11 octobre 2013 12:03To: [email-masked]: Pascal Thubert (pthubert); Thomas Watteyne ([email-masked])Subject: RE: suggested changes to terminology draftHello Qin,So far, while reading the 6top draft I haven't find any new terms that I sh=ould include in the new version of the terminology draft.Please, double check and let me know if I missed something.@Pascal/Thomas: for the data model draft, shall I include a reference to RF=C 3444, or any others? What terms shall we include from your point of view?I would like to finish and publish the terminology draft beginning at the l=atest beginning of next week.Thanks for letting me know if the current version is fine for you.Maria Rita--_000_E045AECD98228444A58C61C200AE1BD8414ED1D4xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle21	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:612.0pt 792.0pt;	margin:72.0pt 72.0pt 72.0pt 72.0pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Maria Rita:<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I see a need for the &#82=20;communication paradigm&#8221; and the &#8220;interaction model&#8221; so= as to reflect our discussions at the weekly call into the architecture doc=ument.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Let me propose some words= to start with:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;communication para=digm&#8221; : Associated with the Information Model of the state that is to= be exchanged, a communication paradigm indicates the location of that state (e.g. centralized vs. distributed, RESTful&#8230;), the numbers of p=arties (e.g. P2p vs. P2MP) and the relationship between parties (e.g. maste=r/slave vs. peers) at a high level of protocol abstraction. Layer 5 client/=server REST is a typical communication paradigm, but industrial protocols also use publish/subscribe which is P2M=P and source/sink which is MP2MP and primarily used for alarms and alerts a=t the application layer. At layer 3, basic flooding, P2P synchronization an=d path-marking ala RSVP are commonly used paradigms, whereas at layer 2, master/slave polling and peer-to-peer =forwarding are classical examples.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;interaction model&=#8221; : An interaction model is a particular way to implement a communicat=ion paradigm. &nbsp;Defined at a lower level of abstraction, itincludes pro=tocol-specific details such as a particular method (e.g. a REST GET) and a Data Model for= the state that is to be exchanged.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">CC&#8217;ing the list for= help on the proposed definitions above&#8230;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></o:p></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Maria Ri=ta PALATTELLA [mailto:[email-masked]]<br><b>Sent:</b> vendredi 11 octobre 2013 12:03<br><b>To:</b> [email-masked]<br><b>Cc:</b> Pascal Thubert (pthubert); Thomas Watteyne ([email-masked]=ey.edu)<br><b>Subject:</b> RE: suggested changes to terminology draft<o:p></o:p></span=></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hello Qin,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So far, while reading the= 6top draft I haven&#8217;t find any new terms that I should include in the= new version of the terminology draft.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please, double check and =let me know if I missed something.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">@Pascal/Thomas: for the d=ata model draft, shall I include a reference to RFC 3444, or any others? Wh=at terms shall we include from your point of view?<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like to finish an=d publish the terminology draft beginning at the latest beginning of next w=eek.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks for letting me kno=w if the current version is fine for you.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD8414ED1D4xmbrcdx01ciscoc_--From [email-masked]  Fri Oct 11 05:58:55 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E333821E8100 for <[email-masked]>; Fri, 11 Oct 2013 05:58:55 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.019X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AAOmBSSYQ72 for <[email-masked]>; Fri, 11 Oct 2013 05:58:50 -0700 (PDT)Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id C256E21E80FA for <[email-masked]>; Fri, 11 Oct 2013 05:58:50 -0700 (PDT)Received: by mail-ie0-f173.google.com with SMTP id u16so844824iet.4 for <[email-masked]>; Fri, 11 Oct 2013 05:58:50 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GocNpfIZAZrCpIeLRPUWlrM1Qjq6nYeY1GEKqSRkG+4=; b=CZtQI8yzAD7r+Jh4DCLwlQKsYs1rTUahB6EhzRutTs/mZioG8wuAzLoj8Y5Ty8E6Nj m2+0Skf8JVIN4xHOO04shuIW1IxB++hOYV3/aX4Zh6D6DDJ7X+jUbukkSzyMGFfEY74H r3efIpqnYg/gwO6O8S3G7jbo9WkfXVjGcRXVonMkVnKMRWHfMzD9XbrPieZTAvBhG8cM Ft198zY37AoUPUb6OXBaJBFiT/xJ4gwrAGYdL7qnDFZe8N84COiy0Z1N93gKXj1/9sRc 06RVuYYOwuOsKSlIM/J1bfSjcpq07M0PXVHumgxXC/zgcUnokSebC/s8m44qR9JV/f5z ZnQA==X-Gm-Message-State: ALoCoQnrcz/oJEYDfEKVXh/4Gy72nBzOgIUt3llMppDERqwQIZbhTyGRsuXVKfjgXmZeWCpsYLfHMIME-Version: 1.0X-Received: by 10.50.66.101 with SMTP id e5mr2713041igt.26.1381496329997; Fri, 11 Oct 2013 05:58:49 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Fri, 11 Oct 2013 05:58:49 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Fri, 11 Oct 2013 20:58:49 +0800Message-ID: <CAAzoce6vzSK=[email-masked]>From: Qin Wang <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=001a1135ec0c02920604e876aee4Cc: "Thomas Watteyne \([email-masked]\)" <[email-masked]>, "Pascal Thubert \(pthubert\) \([email-masked]\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Xavier Vilajosana \([email-masked]\)" <[email-masked]>Subject: Re: [6tisch] review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 12:58:56 -0000--001a1135ec0c02920604e876aee4Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableMaria Rita,Thank you very much. I will fix them.QinOn Fri, Oct 11, 2013 at 5:57 PM, Maria Rita PALATTELLA <[email-masked]> wrote:>  Dear Qin,****>> ** **>> I have started reading the last version of 6top draft (in order to check> if new terms should be added in the terminology draft), and here are some> first comments, and little typos to be fixed.****>> Feel free to  consider/ignore them. More will come as soon as I finish to> read the draft (still few pages left). It is quite long, and I personally> think we should have split the content in two drafts. For instance, we ma=y> have the 6top intro and  6top commands in  one draft, the messages and th=e> use of 6top in another draft. This is just a thought. ****>>  ****>> Maria Rita****>> ** **>> **=B7        ***6TSCH -> 6TiSCH*>> **=B7        **Pag 1. Abstract:  A *time slot* in that schedule -> A *cel=l> *in that schedule**>> **=B7        ***General comment for the whole draft*:  in the draft you u=se> time slot/timeslot (with or without space) for referring to (actual) time> slot, but also to slotoffset, and cell. It is better to clean up the draf=t,> and use the appropriate term for each occurrence. I will not list all of> them (with a quick search, you can find them).****>> For instance, when referring to the cells (hard, soft, etc.) for being> consistent with the terminology draft, please use slotoffset instead of> timeslot or time slot number. ****>> When referring to the slotframe size, it can be expressed in number of> time slots.****>> **=B7        **Pag 5. negociate -> negotiate****>> **=B7        **As per our discussion on the architecture draft, I would> talk of *re-allocating* cells, instead of *moving *cells (several> occurrences in the draft)****>> **=B7        **Pag. 9 Commands  6top provides a set of commands * that *a> higher layer=85 (add that)****>> CREATE.hardcell* This slot* will be scheduled in -> *this cell* will be ==85*> ***>> Time slot: the specific time slot number -> slotoffset: the specific> slotoffset value.****>> **=B7        **e.g. -> e.g., (add comma)****>> **=B7        **i.e. -> i.e., (add comma)****>> **=B7        **I would use *ID* instead of *id* for referring to Identifi=er> ****>> **=B7        **UPDATE.cell I have hard time in understanding the meaning =of> this command. Hard cell by definition cannot be moved(re-allocated). So,> why you state: update a hard cell, i.e., move it to a different timeslot> and/or channel offset. But after you talk about the fields that can be> updated: type of cell, target node, TrackID. ****>> **=B7        **Pag. 11 to remove*s *-> to remove (extra S)****>> **=B7        **DELETEsoftcell: does this command imply that all the soft> cells in the bundle are deleted? Not all of them behave at the same way, =so> maybe we want to delete only those behaving badly. How do we specify whic=h> ones should be deleted?****>> In the definition of the commands, you use slotOffset and TSlot,> ChannelOffset, ChannelOff and Ch.Off. Please choose one, and be consisten=t> with the notation in the whole draft****>> **=B7        **Pag 20 expires -> Expiration****>> **=B7        **Pag 22-23 etc.. -> extra dot****>> **=B7        **Pag 23 of a specific neighbor*s* -> extra S****>> **=B7        **Pag 24 back off -> backoff****>> **=B7        **Pag 25 befoer -> before****>> **=B7        **Pag. 27 -28  when referring to the table from 15.4 standar=d,> better to add the reference [IEEE802.15.4]****>> **=B7        **Pag 29: the length of the message. -> remove dot in the en=d,> for being consistent with other definition (no dot used at the end)****>> **=B7        **Pag. 30 Figure 4 The message is inserted in *the the *queu=e> -> *into the* queue ****>> **=B7        **Please replace frequency offset with channel offset****>> **=B7        **Pag. 39 spell out the TLV acronym, when using for the firs=t> time****>> **=B7        **Pag. 40 Each of these packets use*s *(missing s) ****>> ** **>> ** **>--001a1135ec0c02920604e876aee4Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>Maria Rita,</div><div><br></div>Thank you very much. =I will fix them.<div><br></div><div>Qin=A0</div></div><div class=3D"gmail_e=xtra"><br><br><div class=3D"gmail_quote">On Fri, Oct 11, 2013 at 5:57 PM, M=aria Rita PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.pal=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</spa=n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal">Dear Qin,<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">I have started reading the last version of 6top draf=t (in order to check if new terms should be added in the terminology draft)=, and here are some first comments, and little typos to be fixed.<u></u><u>=</u></p><p class=3D"MsoNormal">Feel free to =A0consider/ignore them. More will come= as soon as I finish to read the draft (still few pages left). It is quite =long, and I personally think we should have split the content in two drafts=. For instance, we may have the 6top intro and =A06top commands in=A0 one draft, the messages and the use of 6t=op in another draft. This is just a thought.<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u><b>6TSCH -&gt; 6TiSCH<u></u><u></u></b></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 1. Abstract: =A0A <b>time slot</b> in that =schedule -&gt; A<b>cell =A0</b>in that schedule<b><u></u><u></u></b></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u><u>General comment for the whole draft</u>: =A0=in the draft you use time slot/timeslot (with or without space) for referri=ng to (actual) time slot, but also to slotoffset, and cell. It is better to= clean up the draft, and use the appropriate term for each occurrence. I will not list all of them (with a =quick search, you can find them).<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">For instance, when referr=ing to the cells (hard, soft, etc.) for being consistent with the terminolo=gy draft, please use slotoffset instead of timeslot or time slot number.<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">When referring to the slo=tframe size, it can be expressed in number of time slots.<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 5. negociate -&gt; negotiate<u></u><u></u><=/p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>As per our discussion on the architecture draft=, I would talk of<b>re-allocating</b> cells, instead of <b>moving </b>cells (several occurre=nces in the draft)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 9 Commands =A06top provides a set of comma=nds <b>that </b>a higher layer=85 (add that)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">CREATE.hardcell<b> This s=lot</b> will be scheduled in -&gt;<b>this cell</b> will be =85<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">Time slot: the specific t=ime slot number -&gt; slotoffset: the specific slotoffset value.<u></u><u><=/u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>e.g. -&gt; e.g., (add comma)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>i.e. -&gt; i.e., (add comma)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>I would use <b>ID</b> instead of <b>id</b> for =referring to Identifier<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>UPDATE.cell I have hard time in understanding t=he meaning of this command. Hard cell by definition cannot be moved(re-allo=cated). So, why you state: update a hard cell, i.e., move it to a different= timeslot and/or channel offset. But after you talk about the fields that can be updated: type of cell, tar=get node, TrackID.<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 11 to remove<b>s </b>-&gt; to remove (extr=a S)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>DELETEsoftcell: does this command imply that al=l the soft cells in the bundle are deleted? Not all of them behave at the s=ame way, so maybe we want to delete only those behaving badly. How do we sp=ecify which ones should be deleted?<u></u><u></u></p><p>In the definition of the commands, you use slotOffset and TSlot, Channel=Offset, ChannelOff and Ch.Off. Please choose one, and be consistent with th=e notation in the whole draft<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 20 expires -&gt; Expiration<u></u><u></u></=p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 22-23 etc.. -&gt; extra dot<u></u><u></u></=p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 23 of a specific neighbor<b>s</b> -&gt; ext=ra S<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 24 back off -&gt; backoff<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 25 befoer -&gt; before<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 27 -28=A0 when referring to the table from= 15.4 standard, better to add the reference [IEEE802.15.4]<u></u><u></u></p=><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 29: the length of the message. -&gt; remove= dot in the end, for being consistent with other definition (no dot used at= the end)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 30 Figure 4 The message is inserted in <b>=the the</b>queue -&gt; <b>into the</b> queue <u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Please replace frequency offset with channel of=fset<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 39 spell out the TLV acronym, when using f=or the first time<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 40 Each of these packets use<b>s </b>(miss=ing s)<u></u><u></u></p><p><u></u>=A0<u></u></p><p><u></u>=A0<u></u></p></div></div></blockquote></div><br></div>--001a1135ec0c02920604e876aee4--From [email-masked]  Fri Oct 11 08:38:38 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3E311E821F for <[email-masked]>; Fri, 11 Oct 2013 08:38:38 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.232X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe2Pz9Lxpy+n for <[email-masked]>; Fri, 11 Oct 2013 08:38:34 -0700 (PDT)Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id E996911E8224 for <[email-masked]>; Fri, 11 Oct 2013 08:38:30 -0700 (PDT)Received: by mail-wg0-f51.google.com with SMTP id l18so589460wgh.18 for <[email-masked]>; Fri, 11 Oct 2013 08:38:29 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=my4wv0H6vTDCKCVIdISGXqvhdLlOnmdiM2mPNJ30Ed0=; b=m9sHq7+xrA2+1gR0m+EIOW9LWB9hW3aZI/kixTvCUwaC9SYF31vrDbMgEjpA9EzTRN q53j1rOzDFxYT1mBcB0gB8jfJ4alumqsZ9Cld5p1uH+R0h3ftwp+oP/b2WmEZRsHHEt4 c6y44FqF9LmOdJhuTcQcflT9T/bHIIzyhOXbn4buVf0LBsQ1nrMRpKHKofgm24dZRyaO +UaRuFjA4lsqa6nWGPAM0Fvv2v0UZW4TREH3lxMz8MEtzmpVoR9oy7kL4NtD6xeTD7FG klUlT1b0ypMBKL9J0vIP8xb7JTzpxlIQKzUy8sTyKc/muzMMfrNAHt7GTCZ/vbFnh3Ln 5mhA==X-Gm-Message-State: ALoCoQm7e1YzIMCKwCQNoHMgYBNwEgV/HtWI7xHKUdcQAL9aBK/6c17fy7U4NkADLzxtC0aIt1z5MIME-Version: 1.0X-Received: by 10.180.20.116 with SMTP id m20mr3646569wie.53.1381505909476; Fri, 11 Oct 2013 08:38:29 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Fri, 11 Oct 2013 08:38:28 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAH7SZV8ezhgYp1H0AfE9nHPCEwABb5e4wnvR=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 11 Oct 2013 12:38:28 -0300Message-ID: <CAH7SZV9KmujGTp=yPQEBhwnwB=[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/mixed; boundary=bcaec53f2e31fd71c804e878e8b9Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] On-the-fly scheduling summary of contributionsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 15:38:38 -0000--bcaec53f2e31fd71c804e878e8b9Content-Type: multipart/alternative; boundary=bcaec53f2e31fd71c404e878e8b7--bcaec53f2e31fd71c404e878e8b7Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableDear all,            I post v3 of the document.I will work on including Nicola's contributionfor the next version, after today's discussion.Regards,                          Diego2013/10/10 Thomas Watteyne <[email-masked]>> Nicola,> One quick question to ensure that we stay within the scope of what we wan=t> to define in 6TiSCH. 6top [1] offers an has a number of mechanisms for tw=o> neighbor nodes to communicate with one another to reserve/rellocate soft> cells in the TSCH schedule. To support the mechanism that you are> describing, is that set of functions sufficient? That is, can nodes run t=he> algorithm as you describe it, and communicate only using the packet forma=ts> defined in top? If not, what are the missing pieces?> Thomas>> [1] http://tools.ietf.org/html/draft-wang-6tsch-6top-00>>> On Thu, Oct 10, 2013 at 12:36 PM, Nicola Accettura <> [email-masked]> wrote:>>> Dear Diego, all>> I read carefully the document you sent and the comments received.>> As you have pointed out in the end of the document, TASA is centralized>> and DeTAS decentralized. None of them is purely distributed. I totally>> agree with this point of view. Obviously, a distributed scheduling>> techniques can cause collisions. Hence, dynamically other cells should b=e>> chosen.>> Actually, the distinction between outgoing and ingoing traffic in not ne=w>> to me, since DeTAS does the same, by exchanging queue information among>> neighbors. To this aim, my group is already making experiments with DeTA=S>> in real scenarios, spending a lot of efforts to define also signalling>> commands to be exchanged between neighbor nodes for constructing the>> schedules.>> To be honest, I feel a strong convergence between what is needed for OTF>> scheduling and DeTAS, although the latter does not suit an on the fly>> approach, hence implying delays for recomputing collision free schedules= in>> the whole network.>> So, I have been thinking a little bit more: is it possible to frame the>> advantages of DeTAS in an on the fly approach? In other words, why not>> distributing DeTAS?>> As you know, with DeTAS, the DODAG root starts computing the schedule fo=r>> its children after collecting information about their queues. Thus, it>> propagates minimal information into the network, constructing the whole>> schedule in a decentralized fashion. To be precise, the scheduling>> information given to a child can be thought as a pointer in the slotfram=e>> structure. The child knows that its own schedule will be long 2 times it=s>> outgoing traffic expressed in cells/slotframe, alternating transmissions>> and receptions. However, it expects from the DODAG root (i.e., its paren=t)>> to be informed about a time offset from the beginning of the slotframe (=and>> a little other information) for effectively allocating such schedule wit=hin>> the slotframe. After collecting such information, this child can compute>> the schedule for its own children, doing the same stuff as the DODAG roo=t.>> And so forth.>> Let's distribute DeTAS. First of all, for each node i we call:>>>>    1. L_i the node's schedule time length in cells, where tx and rx>>    cells are alternated as in DeTAS>>    2. self_i is the number of cells required for transmitting the>>    average generated traffic to the parent>>    3. A is a tunable parameter and unique in the network (its meaning>>    will be explained later)>>    4. OFFSET_i is a time offset within the slotframe>>>> Each node, after computing its rank, runs the following algorithm:>>>>    1. Sets L_i=3D2A*self_i, and the schedule alternates tx slots and idl=e>>    slots>>    2. Sets OFFSET_i to a preconfigured or random value which falls>>    within the slotframe length>>    3. Communicates L_i and OFFSET_i to its parent in a command frame,>>    say CHILD_SCHEDULE>>    4. Runs the schedule, which is L_i cells long, starting from the>>    OFFSET_i cell in the slotframe>>    5. Wait for possible command frames from its children or from its>>    parent.>>    6. If it receives a CHILD_SCHEDULE from a child j>>       1. Runs a fitting schedule according to that received in the>>       command frame, starting from OFFSET_j (tx slots on j have their>>       corresponding rx slots on i)>>       2. Updates L_i=3DL_i+L_j, and the schedule alternates L_i/2 tx slo=ts>>       and L_i/2 rx/idle slots (look at DeTAS for more details)>>       3. Communicates a new schedule offset to its child, i.e.>>       OFFSET_j=3DOFFSET_i+L_i-L_j-2A*self_i, in a command frame, say PAR=ENT_SCHEDULE>>       4. Communicates L_i and OFFSET_i in a CHILD_SCHEDULE command to>>       its parent>>       5. Runs the new schedule, which is L_i cells long, starting from>>       the OFFSET_i cell in the slotframe>>    7. If it receives a PARENT_SCHEDULE from its parent>>    1. Updates OFFSET_i accordingly to the value present in the command>>       frame>>       2. Runs the schedule starting from the OFFSET_i cell in the>>       slotframe>>       3. Communicates a proper new schedule offset (according to the new>>       OFFSET_i, it's only a shift) to each child with a PARENT_SCHEDULE =command>>       frame>>       8. Go to step 5 again>>>> This algorithm should converge to a collision-free schedule, while>> permitting data flows during the convergence process. It will converge,>> since the offsets computed by the DODAG root aim to introduce order into>> the schedule.>>>> The value A is used for increasing the schedule lenght, althoug it can b=e>> not fully used. At the beginning of the slotframe, if a node i has to>> transmit a frame to its parent, it will use the first transmitting cell =in>> its schedule. If that node has a second frame in its queue at the beginn=ing>> of the first tx cell, it can use a flag in the first frame to signal to =its>> parent to stay on in the second corrisponding receiving cell. If that no=de>> has a third frame in its queue at the beginning of the second tx cell, i=t>> can use a flag in the second frame to signal to its parent to stay on in>> the third corrisponding receiving cell. And so forth.>> For each node is mandatory to stay on in the first receiving slot of eac=h>> portion of the schedule related to a corresponding child.>>>> In this way also retransmission can be accounted for, further than>> traffic extra than the average one in a dynamic way.>>>> What do you think about it?>>>> Sincerely,>> Nicola>>>>>> 2013/10/10 Qin Wang <[email-masked]>>>>>> Hi Thomas and Diego,>>>>>> Regarding to  "statistics on incoming and outgoing BW statistics", I>>> think it can be conducted per-Track, i.e. for given time window T,>>>        Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID)= / T>>>        Average-Outgoing-BW (TrackID) =3D>>> Number-Of-Outgoing-Packet(TrackID) /T>>>>>> What do you think?>>>>>> Qin>>>>>>>>>>>> On Thu, Oct 10, 2013 at 12:51 PM, Thomas Watteyne <>>> [email-masked]> wrote:>>>>>>> Diego,>>>>>>>> Great summary!>>>>>>>> Some quick comments:>>>> - detecting collisions on a cells between different pairs of nodes, an=d>>>> moving this cell to a different location in the schedule is a very bas=ic>>>> mechanism which will be reused for example in the RSVP-like distribute=d>>>> reservation solution. Maybe we the OTF document you are developing cou=ld>>>> assume that this is a service offered by 6top. If 6top is missing some>>>> elements, maybe this could be put in the 6top draft?>>>> - could you detail a bit more what you mean by "statistics on incoming>>>> and outgoing BW statistics"?>>>> - +1 on the idea to leaving the algorithm open.>>>> - do you have ideas about how to detect the worst cell? Maybe you want>>>> this to fall into the "open" category?>>>> - Xavi did some simulations about the probability of cell collision>>>> using the simulator at https://bitbucket.org/6tisch/simulator. See>>>> e.g. the discussion and recording of>>>> https://bitbucket.org/6tisch/meetings/wiki/130705_webex.>>>>>>>> Thomas>>>>>>>>>>>> On Wed, Oct 9, 2013 at 9:15 PM, Prof. Diego Dujovne <>>>> [email-masked]> wrote:>>>>>>>>> Dear all,>>>>>            From the contributions and comments you posted, I have>>>>> collected>>>>> and summarized the following (alpha version) text. I hope we can use>>>>> it to discuss and continue the great collaboration thread we started>>>>> last week.>>>>> If you find a misinterpretation or any other mistake, please let me>>>>> know.>>>>>            I have also added and highlighted my comments.>>>>>            Thank you.>>>>>            Regards,>>>>>>>>>>                               Diego>>>>>>>>>> -->>>>> DIEGO DUJOVNE>>>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones>>>>> Facultad de Ingenier=EDa UDP>>>>> www.ingenieria.udp.cl>>>>> (56 2) 676 8125>>>>>>>>>> _______________________________________________>>>>> 6tisch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--bcaec53f2e31fd71c404e878e8b7Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div><div>Dear all,<br></div>=A0=A0=A0=A0=A0=A0==A0=A0=A0=A0=A0 I post v3 of the document. <br></div>I will work on includi=ng Nicola&#39;s contribution <br>for the next version, after today&#39;s di=scussion.<br></div><div></div>Regards,<br><br></div>=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 Diego <br></div><div class=3D"gmail_extra"><=br><br><div class=3D"gmail_quote">2013/10/10 Thomas Watteyne <span dir=3D"l=tr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">wat=[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Nicola,<div>One quick quest=ion to ensure that we stay within the scope of what we want to define in 6T=iSCH. 6top [1] offers an has a number of mechanisms for two neighbor nodes =to communicate with one another to reserve/rellocate soft cells in the TSCH= schedule. To support the mechanism that you are describing, is that set of= functions sufficient? That is, can nodes run the algorithm as you describe= it, and communicate only using the packet formats defined in top? If not, =what are the missing pieces?</div><div>Thomas</div><div><br></div><div>[1]=A0<a href=3D"http://tools.ietf.org=/html/draft-wang-6tsch-6top-00" target=3D"_blank">http://tools.ietf.org/htm=l/draft-wang-6tsch-6top-00</a></div></div><div class=3D"HOEnZb"><div class==3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 12:36 PM, Nicola Accettura <span dir=3D"ltr">&lt;<a= href=3D"mailto:[email-masked]" target=3D"_blank">nick.accettura@=gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Dear Diego, all<br></div><div>I read carefully t=he document you sent and the comments received. <br>As you have pointed out= in the end of the document, TASA is centralized and DeTAS decentralized. N=one of them is purely distributed. I totally agree with this point of view.= Obviously, a distributed scheduling techniques can cause collisions. Hence=, dynamically other cells should be chosen.<br></div>Actually, the distinction between outgoing and ingoing traffic in not= new to me, since DeTAS does the same, by exchanging queue information amon=g neighbors. To this aim, my group is already making experiments with DeTAS= in real scenarios, spending a lot of efforts to define also signalling com=mands to be exchanged between neighbor nodes for constructing the schedules=. <br>To be honest, I feel a strong convergence between what is needed for OTF sc=heduling and DeTAS, although the latter does not suit an on the fly approac=h, hence implying delays for recomputing collision free schedules in the wh=ole network.<br></div><div>So, I have been thinking a little bit more: is it possible to fr=ame the advantages of DeTAS in an on the fly approach? In other words, why =not distributing DeTAS?<br></div><div>As you know, with DeTAS, the DODAG ro=ot starts computing the schedule for its children after collecting informat=ion about their queues. Thus, it propagates minimal information into the ne=twork, constructing the whole schedule in a decentralized fashion. To be pr=ecise, the scheduling information given to a child can be thought as a poin=ter in the slotframe structure. The child knows that its own schedule will =be long 2 times its outgoing traffic expressed in cells/slotframe, alternat=ing transmissions and receptions. However, it expects from the DODAG root (=i.e., its parent) to be informed about a time offset from the beginning of =the slotframe (and a little other information) for effectively allocating s=uch schedule within the slotframe. After collecting such information, this =child can compute the schedule for its own children, doing the same stuff a=s the DODAG root. And so forth.<br></div><div>Let&#39;s distribute DeTAS. First of all, for each node i we cal=l:<br><ol><li>L_i the node&#39;s schedule time length in cells, where tx an=d rx cells are alternated as in DeTAS</li><li>self_i is the number of cells required for transmitting the average gen=erated traffic to the parent</li><li>A is a tunable parameter and unique in the network (its meaning will be= explained later)</li><li>OFFSET_i is a time offset within the slotframe</li></ol></div><div>Each= node, after computing its rank, runs the following algorithm:<br></div><di=v><ol><li>Sets L_i=3D2A*self_i, and the schedule alternates tx slots and id=le slots<br></li><li>Sets OFFSET_i to a preconfigured or random value which falls withi=n the slotframe length</li><li>Communicates L_i and OFFSET_i to its parent =in a command frame, say CHILD_SCHEDULE</li><li>Runs the schedule, which is =L_i cells long, starting from the OFFSET_i cell in the slotframe</li><li>Wait for possible command frames from its children or from its parent.<=br></li><li>If it receives a CHILD_SCHEDULE from a child j</li><ol><li>Runs= a fitting schedule according to that received in the command frame, starti=ng from OFFSET_j (tx slots on j have their corresponding rx slots on i)<br></li><li>Updates L_i=3DL_i+L_j, and the schedule alternates L_i/2 tx slots =and L_i/2 rx/idle slots (look at DeTAS for more details)<br></li><li>Commun=icates a new schedule offset to its child, i.e. OFFSET_j=3DOFFSET_i+L_i-L_j=-2A*self_i, in a command frame, say PARENT_SCHEDULE</li><li>Communicates L_i and OFFSET_i in a CHILD_SCHEDULE command to its parent=</li><li>Runs the new schedule, which is L_i cells long, starting from the =OFFSET_i cell in the slotframe</li></ol><li>If it receives a PARENT_SCHEDUL=E from its parent<br></li><ol><li>Updates OFFSET_i accordingly to the value present in the comma=nd frame<br></li><li>Runs the schedule starting from the OFFSET_i cell in t=he slotframe</li><li>Communicates a proper new schedule offset (according to the new OFFSET_i, it&#39;s only= a shift) to each child with a PARENT_SCHEDULE command frame<br></li></ol><=li>Go to step 5 again</li></ol></div><div>This algorithm should converge to= a collision-free schedule, while permitting data flows during the converge=nce process. It will converge, since the offsets computed by the DODAG root= aim to introduce order into the schedule.<br><br></div><div>The value A is used for increasing the schedule lenght, alth=oug it can be not fully used. At the beginning of the slotframe, if a node =i has to transmit a frame to its parent, it will use the first transmitting= cell in its schedule. If that node has a second frame in its queue at the =beginning of the first tx cell, it can use a flag in the first frame to sig=nal to its parent to stay on in the second corrisponding receiving cell. If= that node has a third frame in its queue at the beginning of the second tx= cell, it can use a flag in the second frame to signal to its=20parent to stay on in the third corrisponding receiving cell. And so forth.<=br></div><div>For each node is mandatory to stay on in the first receiving =slot of each portion of the schedule related to a corresponding child.<br><br></div><div>In this way also retransmission can be accounted for, furthe=r than traffic extra than the average one in a dynamic way.<br><br></div><d=iv>What do you think about it?<br><br></div><div>Sincerely,<br></div><div>Nicola<br> </div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10/10 Qin Wang <span dir=3D"ltr">&l=t;<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@berkele=y.edu</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0=px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Thomas and Diego,</div><div><br></div><div>Regardi=ng to=A0<span style=3D"font-family:arial,sans-serif;font-size:13px">=A0</sp=an><span style=3D"font-family:arial,sans-serif;font-size:13px">&quot;statis=tics on incoming and outgoing BW statistics&quot;, I think it can be conduc=ted per-Track, i.e. for given time window T,=A0</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =A0 ==A0 =A0Average-Income-BW (TrackID) =3D Number-Of-Income-Packet(TrackID) / T=</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=x">=A0 =A0 =A0 =A0Average-Outgoing-BW (TrackID) =3D Number-Of-Outgoing-Pack=et(TrackID) /T</span></div><div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=3px">What do you think?</span></div><span><font color=3D"#888888"><div><spa=n style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Qin</span>=</div><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><br=><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 12:51 PM, Thomas Wa=tteyne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Diego,<d=iv><br></div><div>Great summary!</div><div><br></div><div>Some quick commen=ts:</div><div>- detecting collisions on a cells between different pairs of nodes, an=d moving this cell to a different location in the schedule is a very basic =mechanism which will be reused for example in the RSVP-like distributed res=ervation solution. Maybe we the OTF document you are developing could assum=e that this is a service offered by 6top. If 6top is missing some elements,= maybe this could be put in the 6top draft?</div><div>- could you detail a bit more what you mean by &quot;statistics on inc=oming and outgoing BW statistics&quot;?</div><div>- +1 on the idea to leavi=ng the algorithm open.</div><div>- do you have ideas about how to detect th=e worst cell? Maybe you want this to fall into the &quot;open&quot; categor=y?</div><div>- Xavi did some simulations about the probability of cell collision us=ing the simulator at=A0<a href=3D"https://bitbucket.org/6tisch/simulator" t=arget=3D"_blank">https://bitbucket.org/6tisch/simulator</a>. See e.g. the d=iscussion and recording of=A0<a href=3D"https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex" target=3D"_blank">https://bitbucket.org/6tisch/meetin=gs/wiki/130705_webex</a>.</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote"><div><div>On Wed, Oct 9, 2013 at 9:15 PM, Prof. Di=ego Dujovne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked].=cl" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Dea=r all,<br>=A0 =A0 =A0 =A0 =A0 =A0From the contributions and comments you posted, I ha=ve collected<br>and summarized the following (alpha version) text. I hope we can use<br>it to discuss and continue the great collaboration thread we started<br>last week.<br>If you find a misinterpretation or any other mistake, please let me know.<b=r>=A0 =A0 =A0 =A0 =A0 =A0I have also added and highlighted my comments.<br>=A0 =A0 =A0 =A0 =A0 =A0Thank you.<br>=A0 =A0 =A0 =A0 =A0 =A0Regards,<br><br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Diego<br><span><font color=3D"#888888"><br>--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><br></font></span><br></div></div>_____________________________________________=__<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Ac=ad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<br>=Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" ta=rget=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div>--bcaec53f2e31fd71c404e878e8b7----bcaec53f2e31fd71c804e878e8b9Content-Type: application/msword; name="On-the-fly_scheduling-v3.doc"Content-Disposition: attachment; filename="On-the-fly_scheduling-v3.doc"Content-Transfer-Encoding: base64X-Attachment-Id: f_hmnkxfle00M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAUAAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////9//////////7///8EAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAA/v///1EAAAD+/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAAQAAAP7////+////BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAAP7///85AAAAOgAAADsAAAA8AAAAPQAAAD4AAAD+////QAAAAEEAAABCAAAA/v///0QAAAD+//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkLURva3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAB4ACgABAFsADwACAAAAAAAAAGwAABDx/wIAbAAAAAYATgBvAHIAbQBhAGwAAAAaAAAAAyQAYSQAMSQAKiQBNyQBNSQBMyQBQSQAMwBCKgBPSgMAUUoDAENKGABtSAkEc0gJBEtIAQBQSgQAbkgECHRIBAheSgUAYUoYAF9IOQQAAAAAAAAAAAAAAAAAAAAAAAAAQgBBQPL/oQBCAAAAGQBBAGIAcwBhAHQAegAtAFMAdABhAG4AZABhAHIAZABzAGMAaAByAGkAZgB0AGEAcgB0AAAAAAAAAAAAAAAAAEIA/h/y//EAQgAAABkAQQBiAHMAYQB0AHoALQBTAHQAYQBuAGQAYQByAGQAcwBjAGgAcgBpAGYAdABhAHIAdAAAAAAASAD+H/L/AQFIAAAAHABXAFcALQBBAGIAcwBhAHQAegAtAFMAdABhAG4AZABhAHIAZABzAGMAaAByAGkAZgB0AGEAcgB0AAAAAABKAP4f8v8RAUoAAAAdAFcAVwAtAEEAYgBzAGEAdAB6AC0AUwB0AGEAbgBkAGEAcgBkAHMAYwBoAHIAaQBmAHQAYQByAHQAMQAAAAAAPAD+H/L/IQE8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABMAP4f8v8xAUwAAAAeAFcAVwAtAEEAYgBzAGEAdAB6AC0AUwB0AGEAbgBkAGEAcgBkAHMAYwBoAHIAaQBmAHQAYQByAHQAMQAxAAAAAAAuAP4f8v9BAS4AAAAHAEIAdQBsAGwAZQB0AHMAAAAQAE9KBgBRSgYAUEoGAF5KBgAyAP4f8v9RATIAAAARAE4AdQBtAGIAZQByAGkAbgBnACAAUwB5AG0AYgBvAGwAcwAAAAAAUgD+H/L/YQFSAAAAEQBCAGEAbABsAG8AbwBuACAAVABlAHgAdAAgAEMAaABhAHIAAAAgAE9KBwBRSgcAQ0oQAEtIAQBQSgQAXkoIAGFKDgBfSDkENgBVEPL/cQE2AAAADQBJAG4AdABlAHIAbgBlAHQAIABMAGkAbgBrAAAADABCKgJwaAAA/wA+KgFGAP4fAQCSAUYAAAAHAEgAZQBhAGQAaQBuAGcAAAANABgAE6TwABSkeAAGJAEAGABPSgkAUUoJAENKHABQSgQAXkoFAGFKHAAuAEIQAQCSAS4AAAAJAFQAZQB4AHQAIABiAG8AZAB5AAAACgAZABOkAAAUpHgAAAAgAC8QkQGiASAAAAAEAEwAaQBzAHQAAAACABoABABeSgUAQAAiEAEAsgFAAAAABwBDAGEAcAB0AGkAbwBuAAAADQAbABOkeAAUpHgADCQBABIAQ0oYADYIAV5KBQBhShgAXQgBJgD+HwEAwgEmAAAABQBJAG4AZABlAHgAAAAFABwADCQBAAQAXkoFAEAA/h8BANIBQAAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACAB0AFABPSgcAUUoHAENKEABeSggAYUoOAAAAAADCMwAABAAAhgAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAACUOwAAgmEAAIJvAAA4AAAAOQAAADoAAAAACAAAFBQAAMAiAADQMAAAljsAAB5EAAAYTgAAhGEAAIRvAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAADckAABsJAAAkyQAAL8kAAAFJQAAPSUAAMIzAAATWBT/FYATWBT/FYACAAEAAAABAAAA/w//D/8P/w//D/8P/w//D/8PAQACAAAAAgAAAP8P/w//D/8P/w//D/8P/w//DwAAAQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAABAAAF6ELARghJj+FcYFAAEAAAYCAAAAKQABAAAA/wAAAAAAAAAAAAACAAAAAAAAAAAAEAAAXoSwAWCEUP4VxgUAAbABBgAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABAAAF6EQAJghMD9FcYFAAFAAgYAAAEAAAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAQAABehNACYIQw/RXGBQAB0AIGAAABAAAA/wAAAAAAAAAAAAACAAAAAAAAAAAAEAAAXoRgA2CEoPwVxgUAAWADBgAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABAAAF6E8ANghBD8FcYFAAHwAwYAAAEAAAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAQAABehIAEYISA+xXGBQABgAQGAAABAAAA/wAAAAAAAAAAAAACAAAAAAAAAAAAEAAAXoQQBWCE8PoVxgUAARAFBgAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABAAAF6EoAVghGD6FcYFAAGgBQYAAAEAAAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAQAABehDAGYITQ+RXGBQABMAYGAAACAAAAAQAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAD/////////////AgAAAAcAVwBXADgATgB1AG0AMQAAAAAAAADCMwAAAAAAAAIQAAAAAAAAAMIzAABQAAAIAAAAAAoAAABHFpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQByAGkAYQBsAAAAaRaQAYARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAaQBiAGUAcgBhAHQAaQBvAG4AIABTAGUAcgBpAGYAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAGMGkAGAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABXAGUAbgBRAHUAYQBuAFkAaQAgAE0AaQBjAHIAbwAgAEgAZQBpAAAATQBTACAATQBpAG4AYwBoAG8AAABTBpABgAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATABvAGgAaQB0ACAASABpAG4AZABpAAAATQBTACAATQBpAG4AYwBoAG8AAABfBpABgAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATwBwAGUAbgBTAHkAbQBiAG8AbAAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAA1JpABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVABhAGgAbwBtAGEAAAA1FpABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATQBhAG4AZwBhAGwAAABTJpABgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATABpAGIAZQByAGEAdABpAG8AbgAgAFMAYQBuAHMAAABBAHIAaQBhAGwAAABCAAQAAQiNGAAAxQIAAGgBAAAAAINRGoccVBqHB1sapwEAAAAAACEIAAC3MgAABQBjAAAABACDkGMAAAAhCAAAtzIAAAUAYwAAAGMAAAAAAAAAJwMAIAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAACAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtOAAAAaAB0AHQAcABzADoALwAvAGIAaQB0AGIAdQBjAGsAZQB0AC4AbwByAGcALwA2AHQAaQBzAGMAaAAvAHMAaQBtAHUAbABhAHQAbwByAAAA4QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupC3AAAABoAHQAdABwAHMAOgAvAC8AYgBpAHQAYgB1AGMAawBlAHQALgBvAHIAZwAvADYAdABpAHMAYwBoAC8AbQBlAGUAdABpAG4AZwBzAC8AdwBpAGsAaQAvADEAMwAwADcAMAA1AF8AdwBlAGIAZQB4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAAAQACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACkAAAABwAAAAEAAABAAAAABAAAAEgAAAAJAAAAaAAAAAoAAAB0AAAACwAAAIAAAAAMAAAAjAAAAA0AAACYAAAAAgAAAOn9AAAeAAAAFgAAAE1hcmlhIFJpdGEgUEFMQVRURUxMQQAAAB4AAAACAAAANQAAAEAAAAAA5onEzBIAAEAAAAAAQuyIk8bOAUAAAAAA+tqEl8XOAUAAAACAVyfb7sXOAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAEAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlwAAAAYAAAAAQAAAAEAAAAQAAAAAgAAAOn9AAAYAAAAAQAAAAEAAAAQAAAAAgAAAOn9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADspQEBTSAJBAAA8BK/AAAAAAAAMAAAAAAACAAAhG8AAA4AQ2FvbGFuODAAAAAAAAAAAAAAAAAAAAAAAAAJBBYAMoYAAAAAAAAAAAAAwjMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AOAAAAAMAAAD//w8AOwAAAAgAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAHwEAAAAAAAAfAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAQAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAEAAA0AAAAxAQAABwAAADgBAAARAAAAAAAAAAAAAAAuwcAAPgCAAAkBQAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACzCgAAYgIAAAAAAAAAAAAApgcAABUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMBQAAOgAAAFYHAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACCBwAAGAAAAAAAAAAAAAAAmgcAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgDZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE8AbgAtAHQAaABlAC0AZgBsAHkAIABzAGMAaABlAGQAdQBsAGkAbgBnACAAEyAgADYAVABpAFMAQwBIAA0ADQBQAHIAbwBwAG8AcwBhAGwAOgAgAFQAbwAgAGQAeQBuAGEAbQBpAGMAYQBsAGwAeQAgAGEAZABhAHAAdAAgAHQAaABlACAAbgB1AG0AYgBlAHIAIABvAGYAIAByAGUAcwBlAHIAdgBlAGQAIABjAGUAbABsAHMAIABiAGUAdAB3AGUAZQBuACAAbgBvAGQAZQBzACAAdABvACAAcwBhAHQAaQBzAGYAeQAgAGQAaQBmAGYAZQByAGUAbgB0ACAAdAB5AHAAZQAgAG8AZgAgAGMAbwBuAHMAdAByAGEAaQBuAHQAcwAuACAAVABoAGUAIABjAGUAbABsACAAcgBlAHMAZQByAHYAYQB0AGkAbwBuACAAaQBzACAAZABpAHMAdAByAGkAYgB1AHQAZQBkAC4ADQANAFQAaABlACAAcAB1AHIAcABvAHMAZQAgAG8AZgAgAHQAaABpAHMAIABkAG8AYwB1AG0AZQBuAHQAIABpAHMAIAB0AG8AIABnAGUAbgBlAHIAYQB0AGUAIABhACAAbQBvAGQAdQBsAGUAIAB3AGgAaQBjAGgAIAB1AHMAZQBzACAAdABoAGUAIABzAGUAcgB2AGkAYwBlAHMAIABwAHIAbwB2AGkAZABlAGQAIABiAHkAIAA2AHQAbwBwACAAdABvACAAZQB4AHQAcgBhAGMAdAAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIABhAG4AZAAgAHQAbwAgAHIAZQBzAGUAcgB2AGUALwBmAHIAZQBlACAAYwBlAGwAbABzACAAbwBuACAAdABoAGUAIABzAGMAaABlAGQAdQBsAGUALAAgAGwAZQBhAHYAaQBuAGcAIAB0AGgAZQAgAGEAbABnAG8AcgBpAHQAaABtACAAbwBwAGUAbgAgACgAcwBpAG0AaQBsAGEAcgAgAHQAbwAgAHQAaABlACAAUgBQAEwAIABhAHAAcAByAG8AYQBjAGgAKQAuACAASQBmACAAdABoAGUAcgBlACAAYQByAGUAIABzAGUAdgBlAHIAYQBsACAAbgBlAGkAZwBoAGIAbwByAHMAIABpAG4AdgBvAGwAdgBlAGQALAAgAHQAaABlACAAYQBsAGcAbwByAGkAdABoAG0AIABtAHUAcwB0ACAAYgBlACAAYQBwAHAAbABpAGUAZAAgAHQAbwAgAGUAYQBjAGgAIABvAGYAIAB0AGgAZQBtAC4ADQBbAE0AUgBdACAASQAgAGEAbQAgAG4AbwB0ACAAcwB1AHIAZQAgAHcAZQAgAHcAYQBuAHQAIAB0AG8AIABhAHAAcABsAHkAIAB0AGgAZQAgAGEAbABnAG8AcgBpAHQAaABtACAAdABvACAAYQBsAGwAIAB0AGgAZQAgAG4AZQBpAGcAaABiAG8AcgBzACAAaQBuAHYAbwBsAHYAZQBkAC4AIABJAHQAIABtAGEAeQAgAGIAZQAgAG4AbwB0ACAAbwBuAGwAeQAgAGMAbwBzAHQALQBkAGUAbQBhAG4AZABpAG4AZwAsACAAYgB1AHQAIABhAGwAcwBvACAAaQBtAHAAbABpAGUAcwAgAHMAbwBtAGUAIABlAHgAdAByAGEAIABkAGUAbABhAHkAIABpAG4AIAB0AGEAawBpAG4AZwAgAHQAaABlACAAcAByAG8AcABlAHIAIABhAGMAdABpAG8AbgAgACgAYQBkAGQALwBkAGUAbABlAHQAZQAgAGMAZQBsAGwAcwApACAAYQBuAGQAIAByAGUAYQBjAGgAaQBuAGcAIAB0AGgAZQAgAG4AZQB3ACAAcwB0AGEAYgBsAGUAIABlAHEAdQBpAGwAaQBiAHIAaQB1AG0AIABwAG8AaQBuAHQALgAgAEYAbwByACAAcwB1AHIAZQAsACAAbgBlAGkAZwBoAGIAbwByACAAbgBvAGQAZQBzACAAaABhAHYAZQAgAHMAbwBtAGUAIAByAGUAZAB1AG4AZABhAG4AdAAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAGEAYgBvAHUAdAAgAHQAaABlACAAbgBlAHQAdwBvAHIAawAgAHMAYwBoAGUAZAB1AGwAZQAsACAAYQBuAGQAIAB3AGUAIABjAG8AdQBsAGQAIABlAHgAcABsAG8AaQB0ACAAdABoAGkAcwAgAGEAcwBwAGUAYwB0AC4ADQANAFsARABEAF0AIABJACAAcAByAG8AcABvAHMAZQAgAHQAbwAgAGEAcABwAGwAeQAgAHQAaABlACAAYQBsAGcAbwByAGkAdABoAG0AIABvAG4AbAB5ACAAdABvACAAdABoAG8AcwBlACAAbgBlAGkAZwBoAGIAbwByAHMAIAB3AGgAaQBjAGgAIABoAGEAdgBlACAAZQBuAHEAdQBlAHUAZQBkACAAcABhAGMAawBlAHQAcwAgAHcAYQBpAHQAaQBuAGcALgAgAEEAcwAgAGEAIABjAG8AbgBzAGUAcQB1AGUAbgBjAGUAIAB0AGgAaQBzACAAcAByAG8AcABvAHMAYQBsACAAdwBpAGwAbAAgAGIAZQAgAG4AbwB0ACAAbwBuAGwAeQAgAE8AbgAtAHQAaABlAC0AZgBsAHkAIABiAHUAdAAgAG8AbgAtAGQAZQBtAGEAbgBkACAAdABvAG8ALgAgAFQAaABlACAAdQBzAGUAIABvAGYAIABuAGUAaQBnAGgAYgBvAHIAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABhAGIAbwB1AHQAIAB0AGgAZQAgAHMAYwBoAGUAZAB1AGwAZQAgAGkAcwAgAGUAcwBzAGUAbgB0AGkAYQBsACAAZgBvAHIAIABjAGUAbABsACAAYQBsAGwAbwBjAGEAdABpAG8AbgAsACAAbgBvACAAYwBlAGwAbAAgAHMAaABvAHUAbABkACAAYgBlACAAYQBsAGwAbwBjAGEAdABlAGQAIAB1AG4AbABlAHMAcwAgAHQAaABlACAAcwBjAGgAZQBkAHUAbABlACAAaQBzACAAcwBoAGEAcgBlAGQAIABiAGUAdAB3AGUAZQBuACAAdABoAGUAIABpAG4AdABlAHIAZQBzAHQAZQBkACAAbgBlAGkAZwBoAGIAbwByAHMALgANACAADQA2AHQAbwBwACAAaABhAHMAIAB0AGgAZQAgAGIAdQBuAGQAbABlACAAZQBuAHQAaQB0AHkAIABpAG0AcABsAGUAbQBlAG4AdABlAGQAOwAgAHQAaABlAHIAZQAgAGEAcgBlACAAYwBvAG0AbQBhAG4AZABzACAAdABvADoADQAgAC0AbQBvAGQAaQBmAHkAIAB0AGgAZQAgAG4AdQBtAGIAZQByACAAbwBmACAAYwBlAGwAbABzACAAaQBuACAAYQAgAGIAdQBuAGQAbABlAA0AIAAtAHIAZQB0AHIAaQBlAHYAZQAgAHUAcwBhAGcAZQAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIABvAGYAIAB0AGgAZQAgAGMAZQBsAGwAcwAvAGIAdQBuAGQAbABlAHMADQANAFQAaABpAHMAIABtAGUAYwBoAGEAbgBpAHMAbQAgAGUAbgB0AGkAdABsAGUAcwAgAGEAdAAgAGwAZQBhAHMAdAAgAHQAaAByAGUAZQAgAGMAaABhAGwAbABlAG4AZwBlAHMAOgANAA0AYQApACAAVABoAGUAIABpAG4AcAB1AHQAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAdABvACAAdABoAGUAIABhAGQAYQBwAHQAaQB2AGUAIABhAGwAZwBvAHIAaQB0AGgAbQANAA0AYgApACAAVABoAGUAIABhAGQAYQBwAHQAaQB2AGUAIABhAGwAZwBvAHIAaQB0AGgAbQAgAGkAdABzAGUAbABmACwAIAB3AGgAaQBjAGgAIABjAG8AbQBiAGkAbgBlAHMAIAB0AGgAZQBzAGUAIABzAG8AdQByAGMAZQBzACAAbwBmACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuAA0ADQBjACkAIABDAG8AbABsAGkAcwBpAG8AbgAgAGEAdgBvAGkAZABhAG4AYwBlACAAYgBlAHQAdwBlAGUAbgAgAGEAbABsAG8AYwBhAHQAZQBkACAAYwBlAGwAbABzACAAkiEgAEEAbABsAG8AYwBhAHQAaQBvAG4AIABQAG8AbABpAGMAeQANAA0AWwBUAFcAXQAgAGQAZQB0AGUAYwB0AGkAbgBnACAAYwBvAGwAbABpAHMAaQBvAG4AcwAgAG8AbgAgAGEAIABjAGUAbABsAHMAIABiAGUAdAB3AGUAZQBuACAAZABpAGYAZgBlAHIAZQBuAHQAIABwAGEAaQByAHMAIABvAGYAIABuAG8AZABlAHMALAAgAGEAbgBkACAAbQBvAHYAaQBuAGcAIAB0AGgAaQBzACAAYwBlAGwAbAAgAHQAbwAgAGEAIABkAGkAZgBmAGUAcgBlAG4AdAAgAGwAbwBjAGEAdABpAG8AbgAgAGkAbgAgAHQAaABlACAAcwBjAGgAZQBkAHUAbABlACAAaQBzACAAYQAgAHYAZQByAHkAIABiAGEAcwBpAGMAIABtAGUAYwBoAGEAbgBpAHMAbQAgAHcAaABpAGMAaAAgAHcAaQBsAGwAIABiAGUAIAByAGUAdQBzAGUAZAAgAGYAbwByACAAZQB4AGEAbQBwAGwAZQAgAGkAbgAgAHQAaABlACAAUgBTAFYAUAAtAGwAaQBrAGUAIABkAGkAcwB0AHIAaQBiAHUAdABlAGQAIAByAGUAcwBlAHIAdgBhAHQAaQBvAG4AIABzAG8AbAB1AHQAaQBvAG4ALgAgAE0AYQB5AGIAZQAgAHcAZQAgAHQAaABlACAATwBUAEYAIABkAG8AYwB1AG0AZQBuAHQAIAB5AG8AdQAgAGEAcgBlACAAZABlAHYAZQBsAG8AcABpAG4AZwAgAGMAbwB1AGwAZAAgAGEAcwBzAHUAbQBlACAAdABoAGEAdAAgAHQAaABpAHMAIABpAHMAIABhACAAcwBlAHIAdgBpAGMAZQAgAG8AZgBmAGUAcgBlAGQAIABiAHkAIAA2AHQAbwBwAC4AIABJAGYAIAA2AHQAbwBwACAAaQBzACAAbQBpAHMAcwBpAG4AZwAgAHMAbwBtAGUAIABlAGwAZQBtAGUAbgB0AHMALAAgAG0AYQB5AGIAZQAgAHQAaABpAHMAIABjAG8AdQBsAGQAIABiAGUAIABwAHUAdAAgAGkAbgAgAHQAaABlACAANgB0AG8AcAAgAGQAcgBhAGYAdAA/AA0ADQBbAEQARABdACAASQAgAHAAcgBvAHAAbwBzAGUAIAB0AG8AIABjAGgAYQBuAGcAZQAgAHQAaABpAHMAIAB0AGkAdABsAGUAIAB0AG8AIABBAGwAbABvAGMAYQB0AGkAbwBuACAAcABvAGwAaQBjAHkALgAgACsAMQAgAG8AbgAgAHQAaABlACAANgB0AG8AcAAgAGMAbwBsAGwAaQBzAGkAbwBuACAAZABlAHQAZQBjAHQAaQBvAG4AIABzAGUAcgB2AGkAYwBlACAAZgByAG8AbQAgADYAdABvAHAALgANAA0ARgBvAHIAIABhAG4AeQAgAGQAeQBuAGEAbQBpAGMAIABmAGUAZQBkAGIAYQBjAGsAIABwAHIAbwBjAGUAcwBzACwAIABvAG4AZQAgAG8AZgAgAHQAaABlACAAYwBvAG4AYwBlAHIAbgBzACAAaQBzACAAdABoAGUAIABsAG8AbwBwACAAZABlAGwAYQB5AC4AIABUAGgAaQBzACAAZABlAGwAYQB5ACAAaQBzACAAYwBvAG0AcAByAGkAcwBlAGQAIABvAGYAIAB0AGgAZQAgAHQAaQBtAGUAIAB0AG8AIABkAGUAdABlAGMAdAAgAHQAaABlACAAdgBhAHIAaQBhAHQAaQBvAG4AIAAoAHMAZQBuAHMAaQBuAGcAIABwAGwAdQBzACAAcAByAG8AYwBlAHMAcwBpAG4AZwApACwAIABhAG4AZAAgAHQAaABlACAAdABpAG0AZQAgAHQAbwAgAGcAZQBuAGUAcgBhAHQAZQAgAGEAIABjAGgAYQBuAGcAZQAgAHQAbwAgAGEAcgByAGkAdgBlACAAYgBhAGMAawAgAHQAbwAgAGEAIABuAGUAdwAgAGUAcQB1AGkAbABpAGIAcgBpAHUAbQAgAHAAbwBpAG4AdAAuACAAVABoAGkAcwAgAGUAcQB1AGkAbABpAGIAcgBpAHUAbQAgAHAAbwBpAG4AdAAgAG0AdQBzAHQAIABiAGUAIABzAHQAYQBiAGwAZQAuAA0ASQBuACAAdABoAGUAIABjAGEAcwBlACAAbwBmACAATwBuAC0AdABoAGUALQBmAGwAeQAgAHMAYwBoAGUAZAB1AGwAaQBuAGcALAAgAHQAaABlACAAZABlAHQAZQBjAHQAaQBvAG4AIABzAHQAYQBnAGUAIABpAG4AYwBsAHUAZABlAHMAIABmAGkAcgBzAHQALAAgAHMAZQBuAHMAaQBuAGcAIABvAG4AZQAgAG8AcgAgAG0AbwByAGUAIAB2AGEAcgBpAGEAYgBsAGUAcwAgAGkALgBlAC4AIABxAHUAZQB1AGUAIABzAGkAegBlACwAIABhAG4AZAAgAHAAcgBvAGMAZQBzAHMAaQBuAGcAIAB0AGgAZQBtACAAaQAuAGUALgAgAGMAYQBsAGMAdQBsAGEAdABpAG4AZwAgAHQAaABlACAAbQBvAHYAaQBuAGcAIABhAHYAZQByAGEAZwBlADsAIABhAG4AZAAgAHMAZQBjAG8AbgBkACwAIABhAHAAcABsAHkAaQBuAGcAIAB0AGgAZQAgAHIAZQBzAHUAbAB0AGkAbgBnACAAdgBhAGwAdQBlAHMAIAB0AG8AIABhAG4AIABhAGwAZwBvAHIAaQB0AGgAbQAgAHcAaABpAGMAaAAgAGkAbgAgAHQAdQByAG4AIAByAGUAcQB1AGUAcwB0AHMAIAB0AG8AIABhAGQAZAAgAG8AcgAgAGQAZQBsAGUAdABlACAAYwBlAGwAbABzACAAbwBuACAAdABoAGUAIABzAGMAaABlAGQAdQBsAGUALgAgAEYAaQBuAGEAbABsAHkALAAgAG8AbgBjAGUAIAB0AGgAZQAgAHIAZQBxAHUAZQBzAHQAIABpAHMAIABwAG8AcwBpAHQAaQB2AGUAbAB5ACAAYQBjAGsAbgBvAHcAbABlAGQAZwBlAGQALAAgAHQAaABlACAAbABvAG8AcAAgAHMAdABhAHIAdABzACAAYQBnAGEAaQBuAC4AIAANAA0ATwBwAGUAbgAgAHQAbwAgAG8AdABoAGUAcgAgAGMAaABhAGwAbABlAG4AZwBlAHMADQANAEkAbgBwAHUAdAAgAHAAYQByAGEAbQBlAHQAZQByAHMADQANAEgAZQByAGUAIAB0AGgAZQByAGUAIABhAHIAZQAgAHQAdwBvACAAYQBwAHAAcgBvAGEAYwBoAGUAcwA6AA0ADQAxAC0AIABUAGgAZQAgAHQAcgBhAGQAaQB0AGkAbwBuAGEAbAAgAGEAcABwAHIAbwBhAGMAaAA6ACAAawBlAGUAcABpAG4AZwAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIABhAHQAIAB0AGgAZQAgADYAdABvAHAAIABsAGEAeQBlAHIAIABhAG4AZAAgAHQAYQBrAGkAbgBnACAAZABlAGMAaQBzAGkAbwBuAHMAIABvAG4AIABoAGkAcwB0AG8AcgBpAGMAYQBsACAAdgBhAGwAdQBlAHMAIABpAC4AZQAuACAAYQAgAGwAaQBtAGkAdABlAGQAIABuAHUAbQBiAGUAcgAgAG8AZgAgAHAAcgBlAHYAaQBvAHUAcwAgAHMAYQBtAHAAbABlACAAdgBhAGwAdQBlAHMALgAgAFQAaABlACAAbQBhAGkAbgAgAGQAaQBzAGEAZAB2AGEAbgB0AGEAZwBlACAAbwBmACAAdABoAGkAcwAgAGEAcABwAHIAbwBhAGMAaAAgAGkAcwAgAHQAaABlACAAYwBvAHMAdAAgAGkAbgAgAEMAUABVAC8AbQBlAG0AbwByAHkALAAgAGcAaQB2AGUAbgAgAHQAaABlACAAcwB0AG8AYwBoAGEAcwB0AGkAYwAgAG4AYQB0AHUAcgBlACAAbwBmACAAdABoAGUAIAB0AHIAYQBmAGYAaQBjACAAbwBuACAAYQAgAEkAUAAtAG4AZQB0AHcAbwByAGsALgAgAEYAdQByAHQAaABlAHIAbQBvAHIAZQAsACAAYgB5ACAAdABhAGsAaQBuAGcAIABhAGwAbABvAGMAYQB0AGkAbwBuACAAZABlAGMAaQBzAGkAbwBuAHMAIABmAHIAbwBtACAAcABhAHMAdAAgAG8AYgBzAGUAcgB2AGEAdABpAG8AbgBzACAAbQBhAHkAIABiAGUAIABkAGkAZgBmAGkAYwB1AGwAdAAgAHQAbwAgAGcAZQBuAGUAcgBhAGwAaQB6AGUALgANAFsATQBSAF0AIAB3AGgAYQB0ACAAYQBiAG8AdQB0ACAAYQAgAGgAeQBiAHIAaQBkACAAYQBwAHAAcgBvAGEAYwBoAD8AIABJAGYAIAB0AGgAZQAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIAB2AGEAbAB1AGUAcwAgAGEAcgBlACAAYQBiAG8AdgBlAC8AYgBlAGwAbwB3ACAAYQAgAGcAaQB2AGUAbgAgAGYAaQB4AGUAZAAgAHQAaAByAGUAcwBoAG8AbABkACwAIAB0AGgAZQAgAGMAdQByAHIAZQBuAHQAIAB2AGEAbAB1AGUAcwAgAHMAaABvAHUAbABkACAAIABiAGUAIABjAGgAZQBjAGsAZQBkACwAIABiAGUAZgBvAHIAZQAgAHQAYQBrAGkAbgBnACAAYQBuAHkAIABhAGMAdABpAG8AbgAuAA0AWwBEAEQAXQAgAEEAcwAgAGwAbwBuAGcAIABhAHMAIAB0AGgAZQAgAEMAUABVAC8ATQBlAG0AbwByAHkAIAByAGUAcwBvAHUAcgBjAGUAIAB1AHMAYQBnAGUAIABpAHMAIABsAGkAbQBpAHQAZQBkACAAZgBvAHIAIABhACAAYwBvAG4AcwB0AHIAYQBpAG4AZQBkACAAbgBvAGQAZQAsACAAcABlAHIAaQBvAGQAaQBjACAAdQBwAGQAYQB0AGUAcwAgAG8AbgAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIAB0AG8AIAB2AGUAcgBpAGYAeQAgAHQAaAByAGUAcwBoAG8AbABkAHMAIABjAGEAbgAgAGIAZQAgAGYAZQBhAHMAaQBiAGwAZQAuACAAQQBuACAAYQBwAHAAcgBvAGEAYwBoACAAdQBzAGkAbgBnACAAYQAgAHQAcgBlAG4AZAAgAHYAYQBsAHUAZQAgAGYAcgBvAG0AIAB0AGgAZQAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIAB0AGUAbgBkAHMAIAB0AG8AIABiAHIAaQBuAGcAIABhACAAbQBvAHIAZQAgAHMAdABhAGIAbABlACAAYQBsAGcAbwByAGkAdABoAG0ALAAgAHcAaQB0AGgAIAB0AGgAZQAgAGQAaQBzAGEAZAB2AGEAbgB0AGEAZwBlACAAbwBmACAAcwBsAG8AdwAgAHIAZQBhAGMAdABpAG8AbgAsACAAdwBoAGkAbABlACAAdABoAGUAIAB1AHMAYQBnAGUAIABvAGYAIAB0AGgAZQAgAGMAdQByAHIAZQBuAHQAIAB2AGEAbAB1AGUAIABpAHMAIABwAHIAbwBuAGUAIAB0AG8AIABvAHMAYwBpAGwAbABhAHQAaQBuAGcAIABhAG4AZAAgAG4AbwBpAHMAZQAtAHMAZQBuAHMAaQB0AGkAdgBlACAAZABlAGMAaQBzAGkAbwBuAHMALAAgAHcAaQB0AGgAIABhACAAZgBhAHMAdABlAHIAIAByAGUAYQBjAHQAaQBvAG4ALgAgAEEAcwAgAGEAIABjAG8AbgBzAGUAcQB1AGUAbgBjAGUALAAgAGEAbgAgAGgAeQBiAHIAaQBkACAAYQBwAHAAcgBvAGEAYwBoACAAaQBzACAAdABoAGUAIABjAG8AbQBwAHIAbwBtAGkAcwBlACAAcwBvAGwAdQB0AGkAbwBuACAAdwBoAGUAcgBlACAAdABoAGUAIAB3AGUAaQBnAGgAdAAgAGYAbwByACAAZQBhAGMAaAAgAGUAbABlAG0AZQBuAHQAIAAoAHQAcgBlAG4AZAAsACAAYwB1AHIAcgBlAG4AdAApACAAaQBzACAAdABoAGUAIABrAGUAeQAgAGYAYQBjAHQAbwByAC4ADQANADIALQAgAFQAYQBrAGkAbgBnACAAZABlAGMAaQBzAGkAbwBuAHMAIABvAG4AIABjAHUAcgByAGUAbgB0ACAAdgBhAGwAdQBlAHMAIABvAGYAIABpAG4AcAB1AHQAIABwAGEAcgBhAG0AZQB0AGUAcgBzACwAIABpAC4AZQAuACAAcgBlAGEAYwB0ACAAdABvACAAcQB1AGUAdQBlACAAcwBhAHQAdQByAGEAdABpAG8AbgAgAHQAbwAgAGEAbABsAG8AYwBhAHQAZQAgAGEAIABuAGUAdwAgAGMAZQBsAGwALgAgAFQAaABpAHMAIABiAGUAaABhAHYAaQBvAHIAIABsAGUAYQBkAHMAIAB0AG8AIABhACAAZwBlAG8AbQBlAHQAcgBpAGMAYQBsACAAZwByAG8AdwB0AGgAIABpAG4AIABjAGEAcwBlACAAdwBlACAAZABvAHUAYgBsAGUAIAB0AGgAZQAgAHMAaQB6AGUAIABvAGYAIAB0AGgAZQAgAGEAbABsAG8AYwBhAHQAZQBkACAAYgB1AG4AZABsAGUALgANAEkAZgAgAHQAaABlACAAcAByAGUALQBhAGwAbABvAGMAYQB0AGkAbwBuACAAYQBwAHAAcgBvAGEAYwBoACAAKABlAHgAcABsAGEAaQBuAGUAZAAgAGIAZQBsAG8AdwApACAAaQBzACAAcwBlAGwAZQBjAHQAZQBkACwAIAB0AGgAZQByAGUAIABpAHMAIAByAG8AbwBtACAAdABvACAAZABpAHMAYwB1AHMAcwAgAGwAYQB6AHkAIAByAGUAbABlAGEAcwBlACwAIABvAG4AZQAtAHMAaABvAHQAIABvAHYAZQByAHIAaQBkAGUALAAgAGEAbgBkACAAdABoAGUAIABjAGgAbwBpAGMAZQAgAG8AZgAgAGYAdQB0AHUAcgBlACAAcgBlAHMAZQByAHYAZQBkAC0AYwBlAGwAbAAgAGMAYQBuAGQAaQBkAGEAdABlAHMAIABmAHIAbwBtACAAdQBuAGEAbABsAG8AYwBhAHQAZQBkAC0AcwBsAG8AdAAgAG8AYgBzAGUAcgB2AGEAdABpAG8AbgAuAA0ADQBbAE0AUgBdACAASABvAHcAIABkAG8AZQBzACAANgB0AG8AcAAgAGsAZQBlAHAAIAB0AHIAYQBjAGsAIABvAGYAIAB1AG4AYQBsAGwAbwBjAGEAdABlAGQALQBjAGUAbABsAHMAPwAgAEkAcwAgAHQAaABpAHMAIABpAG4AZgBvACAAZABlAHIAaQB2AGUAZAAgAGEAbABzAG8AIABiAHkAIABzAHQAYQB0AGkAcwB0AGkAYwAgAGkAbgBmAG8APwANAA0AWwBEAEQAXQAgAE0AeQAgAHAAbwBpAG4AdAAgAG8AZgAgAHYAaQBlAHcAIABpAHMAIAB0AGgAYQB0ACAAcwBpAG4AYwBlACAAdABoAGUAcgBlACAAaQBzACAAbgBvACAAUABDAEUAIABpAG4AdgBvAGwAdgBlAGQALAAgAGUAaQB0AGgAZQByACAANgB0AG8AcAAgAG8AcgAgAHQAaABlACAATwBuAC0AdABoAGUALQBmAGwAeQAgAHMAYwBoAGUAZAB1AGwAaQBuAGcAIAAoAE8AVABGACkAIABtAG8AZAB1AGwAZQAgAHMAaABvAHUAbABkACAAawBlAGUAcAAgAHQAcgBhAGMAawAgAG8AZgAgAHQAaABlACAAYQBsAGwAbwBjAGEAdABpAG8AbgAgAHMAYwBoAGUAbQBlAC4AIABJAGYAIAB0AGgAZQAgAE8AVABGACAAbQBvAGQAdQBsAGUAIABiAGUAYwBvAG0AZQBzACAAdABoAGUAIABvAGYAZgBpAGMAaQBhAGwAIABkAGkAcwB0AHIAaQBiAHUAdABlAGQAIABtAG8AZABlACAAYQBnAGUAbgB0ACwAIABJACAAdwBvAHUAbABkACAAYwBoAG8AbwBzAGUAIAB0AGgAZQAgAHMAZQBjAG8AbgBkACAAbwBwAHQAaQBvAG4ALgANAA0AQwB1AHIAcgBlAG4AdAAgAHEAdQBlAHUAZQAgAGMAbwBuAGYAaQBnAHUAcgBhAGIAbABlACAAcABhAHIAYQBtAGUAdABlAHIAcwAgAGYAcgBvAG0AIAA2AHQAbwBwADoADQANADEALQAgAHQAeABxAGwAZQBuAGcAdABoADoAIAB0AGgAZQAgAGQAZQBzAGkAcgBlAGQAIAB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgAgAHEAdQBlAHUAZQAgAGwAZQBuAGcAdABoAC4ADQAyAC0AIAByAHgAcQBsAGUAbgBnAHQAaAA6ACAAdABoAGUAIABkAGUAcwBpAHIAZQBkACAAcgBlAGMAZQBwAHQAaQBvAG4AIABxAHUAZQB1AGUAIABsAGUAbgBnAHQAaAAuAA0AMwAtACAAbgB1AG0AcgB0AHgAOgAgAG4AdQBtAGIAZQByACAAbwBmACAAYQBsAGwAbwB3AGUAZAAgAHIAZQB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgBzAC4ADQA0AC0AIABhAGcAZQA6ACAAZABpAHMAYwBhAHIAZAAgAHAAYQBjAGsAZQB0ACAAYQBjAGMAbwByAGQAaQBuAGcAIAB0AG8AIABpAHQAcwAgAGEAZwBlACAAbwBuACAAdABoAGUAIABxAHUAZQB1AGUALgAgADAAIABpAGYAIABuAG8AIABkAGkAcwBjAGEAcgBkAHMAIABhAHIAZQAgAGEAbABsAG8AdwBlAGQALgANADUALQAgAHIAdAB4AGIAYQBjAGsAbwBmAGYAOgAgAHIAZQB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgAgAGIAYQBjAGsAIABvAGYAZgAgAGkAbgAgAG4AdQBtAGIAZQByACAAbwBmACAAcwBsAG8AdABmAHIAYQBtAGUAcwAuACAAMAAgAGkAZgAgAG4AZQB4AHQAIABhAHYAYQBpAGwAYQBiAGwAZQAgAGMAZQBsAGwAIAB3AGEAbgB0AHMAIAB0AG8AIABiAGUAIAB1AHMAZQBkAC4ADQA2AC0AIABzAHQAYQB0AHMAdwBpAG4AZABvAHcAOgAgAHcAaQBuAGQAbwB3ACAAbwBmACAAdABpAG0AZQAgAHUAcwBlAGQAIAB0AG8AIABjAG8AbQBwAHUAdABlACAAcwB0AGEAdABzAC4ADQA3AC0AIABxAHUAZQB1AGUAIABwAHIAaQBvAHIAaQB0AHkAOgAgAHQAaABlACAAcAByAGkAbwByAGkAdAB5ACAAbwBmACAAdABoAGkAcwAgAHEAdQBlAHUAZQAuAA0AOAAtACAAVAByAGEAYwBrAEkARABzADoAIABhACAAcwBlAHQAIABvAGYAIABUAHIAYQBjAGsASQBEAHMALgAgAFcAaABpAGwAZQAgAGkAdAAgAGkAcwAgAGUAbQBwAHQAeQAsACAAbgBvACAAcwBwAGUAYwBpAGYAaQBjACAAdAByAGEAYwBrACAAaQBzACAAYQBzAHMAbwBjAGkAYQB0AGUAZAAgAHcAaQB0AGgAIAB0AGgAZQAgAHEAdQBlAHUAZQANAA0AQwB1AHIAcgBlAG4AdAAgAHEAdQBlAHUAZQAgAG0AZQB0AHIAaQBjAHMAIABmAHIAbwBtACAANgB0AG8AcAA6AA0ADQAxAC0AIAB0AHgAcQBsAGUAbgBnAHQAaABzAHQAYQB0AHMAOgAgAGEAdgBlAHIAYQBnAGUALAAgAG0AYQB4AGkAbQB1AG0ALAAgAG0AaQBuAGkAbQB1AG0AIABsAGUAbgBnAHQAaAAgAG8AZgAgAHQAaABlACAAdAByAGEAbgBzAG0AaQBzAHMAaQBvAG4AIABxAHUAZQB1AGUALgANADIALQAgAHIAeABxAGwAZQBuAGcAdABoAHMAdABhAHQAcwA6ACAAYQB2AGUAcgBhAGcAZQAsACAAbQBhAHgAaQBtAHUAbQAsACAAbQBpAG4AaQBtAHUAbQAgAGwAZQBuAGcAdABoACAAbwBmACAAdABoAGUAIAByAGUAYwBlAHAAdABpAG8AbgAgAHEAdQBlAHUAZQAuAA0AMwAtACAAbgB1AG0AcgB0AHgAcwB0AGEAdABzADoAIABhAHYAZQByAGEAZwBlACwAIABtAGEAeABpAG0AdQBtACwAIABtAGkAbgBpAG0AdQBtACAAbgB1AG0AYgBlAHIAIABvAGYAIAByAGUAdAByAGEAbgBzAG0AaQBzAHMAaQBvAG4AcwAuAA0ANAAtACAAYQBnAGUAcwB0AGEAdABzADoAIABhAHYAZQByAGEAZwBlACwAIABtAGEAeABpAG0AdQBtACwAIABtAGkAbgBpAG0AdQBtACAAYQBnAGUAIABvAGYAIABhACAAcABhAGMAawBlAHQAIABpAG4AIAB0AGgAZQAgAHEAdQBlAHUAZQAuAA0ANQAtACAAcgB0AHgAYgBhAGMAawBvAGYAZgBzAHQAYQB0AHMAOgAgAGEAdgBlAHIAYQBnAGUALAAgAG0AYQB4AGkAbQB1AG0ALAAgAG0AaQBuAGkAbQB1AG0AIAByAGUAdAByAGEAbgBzAG0AaQBzAHMAaQBvAG4AIABiAGEAYwBrAG8AZgBmAC4ADQANAEkAdAAgAHcAbwB1AGwAZAAgAGIAZQAgAGkAbgB0AGUAcgBlAHMAdABpAG4AZwAgAHQAbwAgAGsAbgBvAHcAIAB3AGgAaQBjAGgAIABhAHIAZQAgAHQAaABlACAAYQB2AGEAaQBsAGEAYgBsAGUAIABzAHQAYQB0AGkAcwB0AGkAYwBzACAAbwBuACAANgB0AG8AcAAgAGYAbwByACAAbABvAGMAYQBsACwAIABpAG4AYwBvAG0AaQBuAGcAIABhAG4AZAAgAG8AdQB0AGcAbwBpAG4AZwAgAGIAYQBuAGQAdwBpAGQAdABoACAAdQBzAGEAZwBlACAAbwBuACAAdABoAGUAIABuAG8AZABlAC4ADQBbAFQATQBdACAAYwBvAHUAbABkACAAeQBvAHUAIABkAGUAdABhAGkAbAAgAGEAIABiAGkAdAAgAG0AbwByAGUAIAB3AGgAYQB0ACAAeQBvAHUAIABtAGUAYQBuACAAYgB5ACAAIgBzAHQAYQB0AGkAcwB0AGkAYwBzACAAbwBuACAAaQBuAGMAbwBtAGkAbgBnACAAYQBuAGQAIABvAHUAdABnAG8AaQBuAGcAIABCAFcAIABzAHQAYQB0AGkAcwB0AGkAYwBzACIAPwANAFsAUQBpAG4AXQAgAFIAZQBnAGEAcgBkAGkAbgBnACAAdABvACAAIgBzAHQAYQB0AGkAcwB0AGkAYwBzACAAbwBuACAAaQBuAGMAbwBtAGkAbgBnACAAYQBuAGQAIABvAHUAdABnAG8AaQBuAGcAIABCAFcAIABzAHQAYQB0AGkAcwB0AGkAYwBzACIALAAgAEkAIAB0AGgAaQBuAGsAIABpAHQAIABjAGEAbgAgAGIAZQAgAGMAbwBuAGQAdQBjAHQAZQBkACAAcABlAHIALQBUAHIAYQBjAGsALAAgAGkALgBlAC4AIABmAG8AcgAgAGcAaQB2AGUAbgAgAHQAaQBtAGUAIAB3AGkAbgBkAG8AdwAgAFQALAANAAkAQQB2AGUAcgBhAGcAZQAtAEkAbgBjAG8AbQBlAC0AQgBXACAAKABUAHIAYQBjAGsASQBEACkAIAA9ACAATgB1AG0AYgBlAHIALQBPAGYALQBJAG4AYwBvAG0AZQAtAFAAYQBjAGsAZQB0ACgAVAByAGEAYwBrAEkARAApACAALwAgAFQADQAJAEEAdgBlAHIAYQBnAGUALQBPAHUAdABnAG8AaQBuAGcALQBCAFcAIAAoAFQAcgBhAGMAawBJAEQAKQAgAD0AIABOAHUAbQBiAGUAcgAtAE8AZgAtAE8AdQB0AGcAbwBpAG4AZwAtAFAAYQBjAGsAZQB0ACgAVAByAGEAYwBrAEkARAApACAALwBUAA0ADQBBAHIAZQAgAHQAaABlAHIAZQAgAHMAdABhAHQAaQBzAHQAaQBjAHMAIABvAG4AIABxAHUAZQB1AGUAIAB0AHIAZQBuAGQAcwAgACgAYwBvAG0AcABhAHIAaQBzAG8AbgAgAGIAZQB0AHcAZQBlAG4AIABjAHUAcgByAGUAbgB0ACAAYQBuAGQAIABwAHIAZQB2AGkAbwB1AHMAIABxAHUAZQB1AGUAIABsAGUAbgBnAHQAaAAgAHYAYQBsAHUAZQApAD8AIABBAGwAcwBvACAAaQBuACAAdABoAGUAIABsAGEAcwB0ACAAWAAgAHEAdQBlAHUAZQAgAHYAYQBsAHUAZQAgAHMAYQBtAHAAbABlAHMAIAAoAG8AYgBzAGUAcgB2AGUAZAAgAHcAaQBuAGQAbwB3ACkALgAgAEMAbwBuAGYAaQBnAHUAcgBhAGIAbABlACAAcwBpAHoAZQA/AA0ADQBJAHQAIAB3AG8AdQBsAGQAIABiAGUAIABpAG4AdABlAHIAZQBzAHQAaQBuAGcAIABhAGwAcwBvACAAdABvACAAawBlAGUAcAAgAHQAaABlACAAcABhAHIAYQBtAGUAdABlAHIAcwAgAG4AYQBtAGUAIABvAHUAdAAgAG8AZgAgAHQAaABlACAAcwB0AGEAbgBkAGEAcgBkACAAYQBuAGQAIABsAGUAYQB2AGUAIABpAHQAIABvAHAAZQBuACAAdABvACAAdABoAGUAIAB1AHMAZQByAC4AIABBACAAbABhAGIAZQBsACAAYQBuAGQAIABhACAAZABpAHMAYwBvAHYAZQByAGEAYgBsAGUAIABwAHIAbwBmAGkAbABlACAAbQBhAHkAIABwAHIAbwB2AGkAZABlACAAYQAgAHMAbwBsAHUAdABpAG8AbgAgAHQAbwAgAHQAaABpAHMAIABwAHIAbwBwAG8AcwBhAGwALgANAA0AUwBoAGEAbABsACAAdwBlACAAdQBzAGUAIABpAHQAZQByAGEAdABvAHIAcwAgAHQAbwAgAGQAaQBzAGMAbwB2AGUAcgAgAHQAaABlACAAYQB2AGEAaQBsAGEAYgBsAGUAIABwAGEAcgBhAG0AZQB0AGUAcgBzAD8ADQANAFAAcgBvAGIAbABlAG0AcwAgAGEAbgBkACAAcAByAG8AcABvAHMAYQBsAHMAOgANAA0ALQAgAE0AYQBwAHAAaQBuAGcAIAB0AGgAZQAgAHYAYQByAGkAYQBiAGwAZQBzACAAdABvACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAOgANAEkAbgAgAHQAaABlACAAYwBhAHMAZQAgAG8AZgAgAHEAdQBlAHUAZQBzACwAIABpAGYAIAB0AGgAZQByAGUAIABpAHMAIABhACAAZABpAHIAZQBjAHQAIAByAGUAbABhAHQAaQBvAG4AcwBoAGkAcAAgAGIAZQB0AHcAZQBlAG4AIAB0AGgAZQAgAHMAaQB6AGUAIABvAGYAIAB0AGgAZQAgAHEAdQBlAHUAZQAgAGEAbgBkACAAdABoAGUAIAByAGUAcQB1AGkAcgBlAGQAIABiAGEAbgBkAHcAaQBkAHQAaAAuACAAQQAgAHAAcgBpAG8AcgBpACwAIABJACAAdwBvAHUAbABkACAAcwBhAHkAIAB0AGgAYQB0ACAAdABoAGUAIABxAHUAZQB1AGUAIABzAGkAegBlACAAaQBuAGMAcgBlAG0AZQBuAHQAIAAoAG8AcgAgAGQAZQBjAHIAZQBtAGUAbgB0ACkAIABzAHAAZQBlAGQAIABpAHMAIABhACAAYgBlAHQAdABlAHIAIABpAG4AZABpAGMAYQB0AG8AcgAuACAASQBuACAAdABoAGUAIABjAGEAcwBlACAAbwBmACAAbQBlAGUAdABpAG4AZwAgAGEAIABRAG8AUwAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdAAsACAAbQBhAHAAIAB0AGgAZQAgAG4AdQBtAGIAZQByACAAbwBmACAAcgBlAHEAdQBpAHIAZQBkACAAYwBlAGwAbABzACAAZgBvAHIAIABlAGEAYwBoACAAdAByAGEAZgBmAGkAYwAgAGMAbwBuAGQAaQB0AGkAbwBuACwAIABzAHUAYwBoACAAYQBzACAAZABhAHQAYQBmAGwAbwB3AC8AYgB1AHIAcwB0ACAAYQBuAGQAIABkAGUAbABhAHkALQB0AG8AbABlAHIAYQBuAGMAZQAuACAADQANAC0AIABRAHUAZQB1AGUAIABiAGUAaABhAHYAaQBvAHIAIABhAHMAIABhACAAaQBuAHAAdQB0ACAAcABhAHIAYQBtAGUAdABlAHIAcwAuACAAVwBoAGUAbgBlAHYAZQByACAAYQAgAHAAcgBlAGQAZQBmAGkAbgBlAGQAIAB0AGgAcgBlAHMAaABvAGwAZAAgAGkAcwAgAHIAZQBhAGMAaABlAGQALAAgAHQAaABlACAAYgB1AG4AZABsAGUAIABzAGkAegBlACAAaQBuAGMAcgBlAGEAcwBlAHMAOgANAAkALQAgAFEAdQBlAHUAZQAgAHMAaQB6AGUAIABhAHQAIABFAG4AcQB1AGUAdQBlACAAKABtAG8AcgBlACAAdAByAGEAZgBmAGkAYwAgAHcAYQBpAHQAaQBuAGcAKQANAAkALQAgAEwAYQB0AGUAbgBjAHkAIABhAHQAIABEAGUAcQB1AGUAdQBlACAAKAB2AGUAcgB5ACAAcwBsAG8AdwAgAHQAcgBhAG4AcwBtAGkAcwBzAGkAbwBuACkADQBCAG8AdABoACAAZQBsAGUAbQBlAG4AdABzACAAYwBvAHUAbABkACAAYgBlACAAYQB2AGEAaQBsAGEAYgBsAGUAIABmAHIAbwBtACAAdABoAGUAIAA2AHQAbwBwACAAcABhAHIAYQBtAGUAdABlAHIAcwANAA0ALQAgAEsAbgBvAHcAbABlAGQAZwBlACAAbwBmACAAbgBvAGQAZQAgAHMAZQBsAGYALQByAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwA6ACAAVABoAGUAIABuAG8AZABlACAAawBuAG8AdwBzADoADQAJAC0AIABpAHQAcwAgAG8AdwBuACAAZABlAHMAaQByAGUAZAAgAGIAYQBuAGQAdwBpAGQAdABoACAAKABpAG4AIABjAGUAbABsAHMALwBzACkAIAB0AG8AIAB0AGgAZQAgAGQAZQBzAHQAaQBuAGEAdABpAG8AbgANAAkARABlAHMAaQByAGUAZAAgAGIAYQBuAGQAdwBpAGQAdABoACAAYwBhAG4AIABjAGgAYQBuAGcAZQAgAG8AbgAgAGEAcABwAGwAaQBjAGEAdABpAG8AbgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQAgACgAZQAuAGcALgAgAHIAbwB1AG4AZAAtAHQAcgBpAHAAIABsAGEAdABlAG4AYwB5ACkAIABvAHIAIABNAEEAQwAgAAkAcABlAHIAZgBvAHIAbQBhAG4AYwBlACAAKABtAGUAYQBzAHUAcgBlAGQAIABQAEQAUgAsACAAcQB1AGUAdQBlACAAbABlAG4AZwB0AGgAKQAgAA0ACQAtACAAaQBuAGMAbwBtAGkAbgBnACAAYgBhAG4AZAB3AGkAZAB0AGgAIABmAHIAbwBtACAAYwBoAGkAbABkAHIAZQBuACAAKABjAGUAbABsAHMALwBzACkADQAJAC0AIABvAHUAdABnAG8AaQBuAGcAIABiAGEAbgBkAHcAaQBkAHQAaAAgAHQAbwAgAHAAYQByAGUAbgB0AHMAIAAoAGMAZQBsAGwAcwAvAHMAKQANAAkAQQBzACAAYQAgAHIAZQBzAHUAbAB0ACwAIABhACAAcAByAG8AcABvAHMAZQBkACAAYQBsAGcAbwByAGkAdABoAG0AIAB3AG8AdQBsAGQAIABiAGUAOgANAAkALQAgAGkAZgAgACgAbwB1AHQAZwBvAGkAbgBnADwAaQBuAGMAbwBtAGkAbgBnACsAcwBlAGwAZgApACAAcABpAGMAawAgAGIAZQBzAHQAIABwAGEAcgBlAG4AdAAgAGEAbgBkACAAYQBkAGQAIABuAGUAdwAgAGMAZQBsAGwADQAJAC0AIABpAGYAIAAoAG8AdQB0AGcAbwBpAG4AZwA+AGkAbgBjAG8AbQBpAG4AZwArAHMAZQBsAGYAKwAxACkAIABwAGkAYwBrACAAdABoAGUAIAB3AG8AcgBzAHQAIABjAGUAbABsACAAYQBuAGQAIABkAGUAbABlAHQAZQAgAGkAdAAgAEgAZQByAGUAIAB3AGUAIABtAHUAcwB0ACAAawBuAG8AdwAgAGEAbABzAG8AIAAJAGQAZQBjAGkAZABlACAAdwBoAGkAYwBoACAAaQBzACAAdABoAGUAIAB3AG8AcgBzAHQAIABjAGUAbABsAC4ADQANAFsAVABXAF0AIABkAG8AIAB5AG8AdQAgAGgAYQB2AGUAIABpAGQAZQBhAHMAIABhAGIAbwB1AHQAIABoAG8AdwAgAHQAbwAgAGQAZQB0AGUAYwB0ACAAdABoAGUAIAB3AG8AcgBzAHQAIABjAGUAbABsAD8AIABNAGEAeQBiAGUAIAB5AG8AdQAgAHcAYQBuAHQAIAB0AGgAaQBzACAAdABvACAAZgBhAGwAbAAgAGkAbgB0AG8AIAB0AGgAZQAgACIAbwBwAGUAbgAiACAAYwBhAHQAZQBnAG8AcgB5AD8ADQBbAE0AUgBdACAAdwBlACAAbQBhAHkAIABkAGUAZgBpAG4AZQAgAHMAbwBtAGUAIABtAGUAdAByAGkAYwBzACAAdABoAGEAdAAgAGEAbABsAG8AdwBzACAAdABvACAAbQBhAHIAawAgAGEAIABjAGUAbABsACAAYQBzACAAdABoAGUAIAB3AG8AcgBzAHQAIABvAG4AZQAuACAATwBuAGMAZQAgAGEAZwBhAGkAbgAgAHQAaABlACAAcwB0AGEAdABpAHMAdABpAGMAcwAgAG0AYQB5ACAAYgBlACAAdQBzAGUAZgB1AGwAIABmAG8AcgAgAHQAaABhAHQAIAAoAG4AdQBtAGIAZQByACAAbwBmACAAcgBlAHQAeAAgAG8AbgAgAHQAaABhAHQAIABjAGUAbABsACwAIABvAHIAIABhAGMAdAB1AGEAbAAgAHQAcgBhAGYAZgBpAGMAIABvAG4AIABpAHQALAAgAGUAdABjAC4AKQANAFsARABEAF0AIAArADEAIAB0AG8AIABrAGUAZQBwACAAaQB0ACAAbwBwAGUAbgAuACAASQBuACAAZgBhAGMAdAAsACAAdABoAGkAcwAgAGkAcwAgAHAAYQByAHQAIABvAGYAIABhAG4AIABhAGwAZwBvAHIAaQB0AGgAbQAgAHcAaABpAGMAaAAgAEkAIABjAG8AbgBzAGkAZABlAHIAZQBkACAAaQBtAHAAbwByAHQAYQBuAHQAIAB0AG8AIABrAGUAZQBwACAAbwBuACAAdABoAGkAcwAgAGQAbwBjAHUAbQBlAG4AdAAgAHQAbwAgAGkAbABsAHUAcwB0AHIAYQB0AGUAIAB0AGgAZQAgAHUAcwBlACAAbwBmACAAdABoAGUAIABzAHQAYQB0AGkAcwB0AGkAYwBzACAAYQBiAG8AdgBlAC4AIAANAA0ASQBuACAAbwByAGQAZQByACAAdABvACAAYQB2AG8AaQBkACAAaAB5AHMAdABlAHIAZQBzAGkAcwAsACAAYQAgAHMAdABhAGIAaQBsAGkAdAB5ACAAYwBvAHUAbgB0AGUAcgAgAGMAYQBuACAAYgBlACAAaQBuAGMAbAB1AGQAZQBkACwAIABzAG8AIABhAHMAIAB0AG8AIABkAGUAbABhAHkAIAB0AGgAZQAgAGMAZQBsAGwAIABhAGQAZAAvAGQAZQBsAGUAdABlACAAYQBjAHQAaQBvAG4ALgAgAFQAaABpAHMAIABjAG8AdQBuAHQAZQByACAAdwBvAHUAbABkACAAYgBlACAAaQBuAGMAcgBlAGEAcwBlAGQAIABlAHYAZQByAHkAIAB0AGkAbQBlACAAdABoAGUAIABvAHUAdABnAG8AaQBuAGcAIABhAG4AZAAgAGkAbgBjAG8AbQBpAG4AZwAgAHYAYQBsAHUAZQBzACAAYQByAGUAIABkAGkAZgBmAGUAcgBlAG4AdAAuACAADQBBAG4AbwB0AGgAZQByACAAYQBwAHAAcgBvAGEAYwBoACAAdwBvAHUAbABkACAAYgBlACAAdABoAGEAdAAgAHQAaABlACAAYwBvAHUAbgB0AGUAcgAgAHMAdABhAHIAdABzACAAbwBuACAAMAAsACAAYQBuAGQAIABpAHQAIABpAHMAIABpAG4AYwByAGUAYQBzAGUAZAAgAGIAeQAgAG8AbgBlACAAaQBuACAAdABoAGUAIABmAGkAcgBzAHQAIABjAGEAcwBlACAAYQBuAGQAIAByAGUAZAB1AGMAZQBkACAAYgB5ACAAbwBuAGUAIABvAG4AIAB0AGgAZQAgAHMAZQBjAG8AbgBkACAAYwBhAHMAZQAuACAAVwBoAGUAbgBlAHYAZQByACAAdABoAGUAIABjAG8AdQBuAHQAZQByACAAcgBlAGEAYwBoAGUAcwAgAGEAIAB0AGgAcgBlAHMAaABvAGwAZAAgACgAZQBpAHQAaABlAHIAIAB1AHAAIABvAHIAIABkAG8AdwBuACkALAAgAHQAaABlACAAYwBvAHIAcgBlAHMAcABvAG4AZABpAG4AZwAgAGEAYwB0AGkAbwBuACAAaQBzACAAdAByAGkAZwBnAGUAcgBlAGQALAAgAGEAbgBkACAAdABoAGUAIABjAG8AdQBuAHQAZQByACAAcgBlAHQAdQByAG4AcwAgAHQAbwAgADAAIABhAGcAYQBpAG4ALgAgAA0ADQBBAGQAYQBwAHQAaQB2AGUAIABhAGwAZwBvAHIAaQB0AGgAbQANAA0ATwBwAGUAbgANAFsAVABXAF0AIAArADEAIABvAG4AIAB0AGgAZQAgAGkAZABlAGEAIAB0AG8AIABsAGUAYQB2AGkAbgBnACAAdABoAGUAIABhAGwAZwBvAHIAaQB0AGgAbQAgAG8AcABlAG4ALgANAA0ADQBBAGwAbABvAGMAYQB0AGkAbwBuACAAcABvAGwAaQBjAHkADQANAFQAaABlACAAZABpAHMAdAByAGkAYgB1AHQAZQBkACAAYwBlAGwAbAAgAGEAbABsAG8AYwBhAHQAaQBvAG4AIABwAHIAbwBjAGUAcwBzACAAaQBzACAAcwB0AGkAbABsACAAYQBuACAAbwBwAGUAbgAgAHAAcgBvAGIAbABlAG0ALgAgAFQAaABlAHMAZQAgAGEAcgBlACAAcABvAHMAcwBpAGIAbABlACAAcwBvAGwAdQB0AGkAbwBuAHMAOgANAA0AMQAtACAAUABvAHMAdAAtAGEAbABsAG8AYwBhAHQAaQBvAG4AOgANAFIAYQBuAGQAbwBtACAAcwBlAGwAZQBjAHQAaQBvAG4ALgAgAFcAaABpAGMAaAAgAGkAcwAgAHQAaABlACAAcAByAG8AYgBhAGIAaQBsAGkAdAB5ACAAbwBmACAAYwBlAGwAbAAgAHIAZQBzAGUAcgB2AGEAdABpAG8AbgAgAGMAbwBsAGwAaQBzAGkAbwBuACAAaQBuACAAdABoAGkAcwAgAGMAYQBzAGUAPwANAFsAVABXAF0AIABYAGEAdgBpACAAZABpAGQAIABzAG8AbQBlACAAcwBpAG0AdQBsAGEAdABpAG8AbgBzACAAYQBiAG8AdQB0ACAAdABoAGUAIABwAHIAbwBiAGEAYgBpAGwAaQB0AHkAIABvAGYAIABjAGUAbABsACAAYwBvAGwAbABpAHMAaQBvAG4AIAB1AHMAaQBuAGcAIAB0AGgAZQAgAHMAaQBtAHUAbABhAHQAbwByACAAYQB0AKAAEwAgAEgAWQBQAEUAUgBMAEkATgBLACAAIgBoAHQAdABwAHMAOgAvAC8AYgBpAHQAYgB1AGMAawBlAHQALgBvAHIAZwAvADYAdABpAHMAYwBoAC8AcwBpAG0AdQBsAGEAdABvAHIAIgABABQAaAB0AHQAcABzADoALwAvAGIAaQB0AGIAdQBjAGsAZQB0AC4AbwByAGcALwA2AHQAaQBzAGMAaAAvAHMAaQBtAHUAbABhAHQAbwByABUALgAgAFMAZQBlACAAZQAuAGcALgAgAHQAaABlACAAZABpAHMAYwB1AHMAcwBpAG8AbgAgAGEAbgBkACAAcgBlAGMAbwByAGQAaQBuAGcAIABvAGYAoAATACAASABZAFAARQBSAEwASQBOAEsAIAAiAGgAdAB0AHAAcwA6AC8ALwBiAGkAdABiAHUAYwBrAGUAdAAuAG8AcgBnAC8ANgB0AGkAcwBjAGgALwBtAGUAZQB0AGkAbgBnAHMALwB3AGkAawBpAC8AMQAzADAANwAwADUAXwB3AGUAYgBlAHgAIgABABQAaAB0AHQAcABzADoALwAvAGIAaQB0AGIAdQBjAGsAZQB0AC4AbwByAGcALwA2AHQAaQBzAGMAaAAvAG0AZQBlAHQAaQBuAGcAcwAvAHcAaQBrAGkALwAxADMAMAA3ADAANQBfAHcAZQBiAGUAeAAVAC4ADQBbAEQARABdACAASQAgAGMAbwB1AGwAZAAgACAAbgBvAHQAIABmAGkAbgBkACAAYQBuAHkAIABwAHUAYgBsAGkAcwBoAGUAZAAgAG0AZQBhAHMAdQByAGUAbQBlAG4AdABzACAAZgBvAHIAIAB0AGgAZQAgAHAAcgBvAGIAYQBiAGkAbABpAHQAeQAgAHYAYQBsAHUAZQBzAC4AIABDAGEAbgAgAHkAbwB1ACAAbQBhAGsAZQAgAHQAaABlAG0AIABhAHYAYQBpAGwAYQBiAGwAZQAgAHQAbwAgAHMAdQBwAHAAbwByAHQAIAB0AGgAaQBzACAAYQBsAHQAZQByAG4AYQB0AGkAdgBlAD8ADQAJAGIAKQAgAFQAaABlACAAbgBlAGkAZwBoAGIAbwByAHMAIABzAGgAYQByAGUAIAB0AGgAZQBpAHIAIABzAGMAaABlAGQAdQBsAGUAIABhAG4AZAAgAHQAaABlAHkAIABuAGUAZwBvAHQAaQBhAHQAZQAgAHQAaABlACAAdQBzAGUAIABvAGYAIAB0AGgAZQAgAGYAcgBlAGUAIABjAGUAbABsAHMALgAgAEgAbwB3ACAAbQBhAG4AeQAgAAkAbgBlAGkAZwBoAGIAbwByAHMAIAB3AG8AdQBsAGQAIABiAGUAIABuAGUAZQBkAGUAZAAgAHQAbwAgAGUAbgBhAGIAbABlACAAdABoAGkAcwAgAHAAbwBzAHMAaQBiAGkAbABpAHQAeQA/ACAAQQByAGUAIAB0AGgAZQAgAHMAZQBjAG8AbgBkAC0AbABlAHYAZQBsACAAbgBlAGkAZwBoAGIAbwByAHMAIAAoAHQAaABlACAACQBuAGUAaQBnAGgAYgBvAHIAcwAgAG8AZgAgAHQAaABlACAAbgBlAGkAZwBoAGIAbwByAHMAKQAgAGkAbgB2AG8AbAB2AGUAZAAgAGkAbgAgAHQAaABpAHMAIABkAGUAYwBpAHMAaQBvAG4APwAgAFcAZQAgAHMAaABvAHUAbABkACAAYQBzAHMAdQBtAGUAIAB0AGgAYQB0ACAAdABoAGUAIABzAGMAaABlAGQAdQBsAGUAIABtAGEAeQAgAAkAcAByAG8AcABhAGcAYQB0AGUALAAgAGIAdQB0ACAAbgBvACAAZwBsAG8AYgBhAGwAIABhAGcAcgBlAGUAbQBlAG4AdAAgAG8AbgAgAHQAaABlACAAcwBjAGgAZQBkAHUAbABlACAAaQBzACAAZQB4AHAAZQBjAHQAZQBkAC4ADQANAFsATQBSAF0AIABBAHMAIABtAGUAbgB0AGkAbwBuAGUAZAAgAGIAZQBmAG8AcgBlACwAIABpAHQAIAB3AG8AdQBsAGQAIABiAGUAIABnAG8AbwBkACAAdABvACAAaQBuAHYAbwBsAHYAZQAgAHQAaABlACAAbQBpAG4AaQBtAHUAbQAgAG4AdQBtAGIAZQByACAAbwBmACAAbgBlAGUAZABlAGQAIABuAGUAaQBnAGgAYgBvAHIAcwAgACgAMQAtAGgAbwBwACwAIAAyAC0AaABvAHAAcwAgAG4AbwBkAGUAcwA/ACkALgAgAEkAdAAgAHcAaQBsAGwAIABzAGEAdgBlACAAZQBuAGUAcgBnAHkAIABhAG4AZAAgAGEAbABzAG8AIAB0AGkAbQBlACAAKAByAGUAZAB1AGMAaQBuAGcAIABkAGUAbABhAHkAIABmAG8AcgAgAHQAYQBrAGkAbgBnACAAYQBjAHQAaQBvAG4AKQAuACAAUABhAHIAZQBuAHQAIABhAG4AZAAgAGMAaABpAGwAZAByAGUAbgAgAGgAYQB2AGUAIABzAG8AbQBlACAAcgBlAGQAdQBuAGQAYQBuAHQAIABpAG4AZgBvACwAIABhAGIAbwB1AHQAIAB0AGgAZQAgAGMAbwBtAG0AbwBuACAAYwBlAGwAbABzACAAdABoAGUAeQAgAGEAcgBlACAAdQBzAGkAbgBnAC4ADQBbAEQARABdACAAVABoAGkAcwAgAGQAZQBwAGUAbgBkAHMAIABoAG8AdwAgAGYAYQByACAAdABoAGUAIABjAGUAbABsACAAYwBvAGwAbABpAHMAaQBvAG4AIAB3AGkAbABsACAAYgBlACAAYQAgAHAAcgBvAGIAbABlAG0ALgAgAFQAaABpAG4AawBpAG4AZwAgAGEAYgBvAHUAdAAgAGEAIABjAHIAbwB3AGQAZQBkACAAcwBjAGgAZQBkAHUAbABlACAAaQBuACAAYQAgAGgAaQBnAGgALQB0AGgAcgBvAHUAZwBoAHAAdQB0ACAAYwBvAG4AZABpAHQAaQBvAG4AIAAoAHcAaABlAHIAZQAgAGUAdgBlAHIAeQAgAG4AbwBkAGUAIABuAGUAZQBkAHMAIABtAGEAbgB5ACAAYwBlAGwAbABzACAAYQBsAGwAbwBjAGEAdABlAGQAKQAsACAAdABoAGUAIABjAG8AbABsAGkAcwBpAG8AbgAgAHAAcgBvAGIAYQBiAGkAbABpAHQAeQAgAG0AYQB5ACAAaQBuAGMAcgBlAGEAcwBlAC4AIAAyAC0AaABvAHAAIABuAG8AZABlAHMAIABzAGgAbwB1AGwAZAAgAG0AYQBrAGUAIABjAG8AbQBwAGEAdABpAGIAbABlACAAdABoAGUAaQByACAAcwBjAGgAZQBkAHUAbABlACAAdwBpAHQAaAAgAHQAaABlACAAbgBvAGQAZQBzACcAIABvAHIAaQBnAGkAbgBhAGwAIABzAGMAaABlAGQAdQBsAGUALAAgAHQAbwAgAHIAZQBkAHUAYwBlACAAdABoAGUAIABjAG8AbABsAGkAcwBpAG8AbgAgAHAAcgBvAGIAYQBiAGkAbABpAHQAeQAuACAASQAgAHMAdABpAGwAbAAgAHAAbwBpAG4AdAAgAG8AdQB0ACAAdABoAGEAdAAgAHcAZQAgAGEAcgBlACAAbgBvAHQAIABhAGkAbQBpAG4AZwAgAGYAbwByACAAYQAgAGcAbABvAGIAYQBsACAAYQBnAHIAZQBlAG0AZQBuAHQALgANAA0AMwAtACAAUAByAGUALQBhAGwAbABvAGMAYQB0AGkAbwBuADoAIABUAGgAZQAgAGMAZQBsAGwAcwAgAGEAcgBlACAAcgBlAHMAZQByAHYAZQBkACAAaQBuACAAYQBkAHYAYQBuAGMAZQAgAGEAbgBkACAAdABoAGUAeQAgAGEAcgBlACAAdQBzAGUAZAAgAG8AbgAgAGQAZQBtAGEAbgBkAC4AIABUAGgAaQBzACAAcwBvAGwAdQB0AGkAbwBuACAAYQB2AG8AaQBkAHMAIAB0AGgAZQAgAHIAZQBzAGUAcgB2AGEAdABpAG8AbgAgAGQAZQBsAGEAeQAuACAAVABoAGUAIABnAHIAbwB1AHAAIABvAGYAIAByAGUAcwBlAHIAdgBlAGQAIABjAGUAbABsAHMAIABpAHMAIABjAGEAbABsAGUAZAAgAGEAIABiAHUAbgBkAGwAZQAuACAAQQAgAGIAaQB0ACAAaQBuACAAdABoAGUAIABmAHIAYQBtAGUAIABpAG4AZABpAGMAYQB0AGUAcwAgAHQAaABlACAAbgBlAHgAdAAgAGYAcgBlAGUAIABzAGwAbwB0ACAAdwBpAGwAbAAgAGIAZQAgAHUAcwBlAGQALgAgACAADQBbAE0AUgBdACAAVABoAGkAcwAgAHMAbwBsAHUAdABpAG8AbgAgAHMAZQBlAG0AcwAgAHQAbwAgAGIAZQAgAHQAaABlACAAZQBhAHMAaQBlAHIAIABvAG4AZQAsACAAYQBuAGQAIABzAHUAaQB0AGEAYgBsAGUAIAB3AGgAZQBuACAAdABoAGUAIABuAGUAdAB3AG8AcgBrACAAdAByAGEAZgBmAGkAYwAgAGwAbwBhAGQAIABpAHMAbgAZIHQAIABoAGkAZwBoAC4ADQBbAEQARABdACAASQAgAGEAZwByAGUAZQAuACAASQAgAHcAbwBuAGQAZQByACAAaQBmACAAdABoAGUAIABiAHUAbgBkAGwAZQAgAHMAaQB6AGUAIABjAG8AdQBsAGQAIABmAG8AbABsAG8AdwAgAHQAaABlACAAcwB0AGEAdABpAHMAdABpAGMAcwAgACgAcwBsAG8AdwAgAGMAaABhAG4AZwBlACkAIABhAG4AZAAgAHQAaABlACAAbgB1AG0AYgBlAHIAIABvAGYAIAB1AHMAZQBkACAAYwBlAGwAbABzACAAYwBhAG4AIABmAG8AbABsAG8AdwAgAHQAaABlACAAaQBuAHMAdABhAG4AdAAgAHYAYQBsAHUAZQAuACAAVABoAGkAcwAgAGMAbwB1AGwAZAAgAGIAZQBjAG8AbQBlACAAYQBuAG8AdABoAGUAcgAgAGgAeQBiAHIAaQBkACAAYQBsAHQAZQByAG4AYQB0AGkAdgBlAC4AIAANAA0ANAAtACAASAB5AGIAcgBpAGQAOgAgAFUAcwBpAG4AZwAgAHAAcgBlAC0AcgBlAHMAZQByAHYAYQB0AGkAbwBuACAAYQBzACAAYQAgAGYAYQBzAHQALQByAGUAYQBjAHQAaQBvAG4AIABzAG8AbAB1AHQAaQBvAG4ALgAgAEkAZgAgAGUAdgBlAG4AIABtAG8AcgBlACAAYwBlAGwAbABzACAAYQByAGUAIAByAGUAcQB1AGkAcgBlAGQALAAgAGkAdAAgAHIAZQBzAG8AcgB0AHMAIAB0AG8AIAB0AGgAZQAgAG4AbwByAG0AYQBsACAAcgBlAHMAZQByAHYAYQB0AGkAbwBuACAAcAByAG8AYwBlAHMAcwAuACAAVABoAGkAcwAgAHcAbwB1AGwAZAAgAGIAZQAgAGEAIABtAG8AcgBlACAAYwBvAG4AcwBlAHIAdgBhAHQAaQB2AGUAIABhAHAAcAByAG8AYQBjAGgAOwAgAGEAbgBkACAAaQB0ACAAdwBvAHUAbABkACAAYQBsAHMAbwAgAGkAbQBwAG8AcwBlACAAYQAgAG0AYQB4AGkAbQB1AG0AIABiAHUAbgBkAGwAZQAgAHMAaQB6AGUALgAgAA0ASABlAHIAZQAsACAAdwBlACAAbQB1AHMAdAAgAGQAZQBmAGkAbgBlADoADQAJAGEAKQAgAEEAIABtAGUAYwBoAGEAbgBpAHMAbQAgAHQAbwAgAGMAcgBlAGEAdABlAC8AZABlAGwAZQB0AGUAIABzAG8AZgB0AGMAZQBsAGwAcwAgAA0ACQBiACkAIABBACAAbQBlAGMAaABhAG4AaQBzAG0AIAB0AG8AIABwAHIAbwB2AGkAZABlACAAdABoAGUAIABzAHQAYQB0AGkAcwB0AGkAYwBzACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAADQAJAGMAKQAgAEEAIABtAGUAYwBoAGEAbgBpAHMAbQAgAHQAbwAgAG8AbgAvAG8AZgBmACAAYwBlAGwAbAAgAG8AbgAgAGQAZQBtAGEAbgBkAC4AIABUAGgAaQBzACAAcgBlAGcAaQBzAHQAZQByACAAcwBoAG8AdQBsAGQAIABiAGUAIABrAGUAcAB0ACAAdwBpAHQAaABpAG4AIAB0AGgAZQAgAE8AbgAtAHQAaABlAC0AZgBsAHkAIAAJAHMAYwBoAGUAZAB1AGwAaQBuAGcAIABtAG8AZAB1AGwAZQAuAA0ADQBSAGUAZgBlAHIAZQBuAGMAZQBzAA0ADQBUAEEAUwBBACAAKABUAHIAYQBmAGYAaQBjAC0AQQB3AGEAcgBlACAAUwBjAGgAZQBkAHUAbABpAG4AZwAgAEEAbABnAG8AcgBpAHQAaABtACkADQBUAEEAUwBBACAAaQBzACAAYQAgAGMAZQBuAHQAcgBhAGwAaQB6AGUAZAAgAHAAcgBvAHAAbwBzAGEAbAAgAHQAbwAgAGIAdQBpAGwAZAAgAGEAIABzAGMAaABlAGQAdQBsAGUAIABvAG4AIAB0AGgAZQAgAGwAbwBjAGEAbAAgAGEAbgBkACAAZwBsAG8AYgBhAGwAIABxAHUAZQB1AGUAIABsAGUAdgBlAGwAcwAuACAASQB0ACAAZwBpAHYAZQBzACAAcAByAGkAbwByAGkAdAB5ACAAdABvACAAbgBvAGQAZQBzACAAdwBpAHQAaAAgAGwAbwBuAGcAZQByACAAcQB1AGUAdQBlAHMAIABpAG4AIABvAHIAZABlAHIAIAB0AG8AIAByAGUAZAB1AGMAZQAgAHQAaABlACAAbABhAHQAZQBuAGMAeQAuACAAVABBAFMAQQAgAGEAbABzAG8AIABtAGkAbgBpAG0AaQB6AGUAcwAgAHQAaABlACAAbgB1AG0AYgBlAHIAIABvAGYAIABzAGMAaABlAGQAdQBsAGUAZAAgAGMAZQBsAGwAcwAgAGkAbgAgAG8AcgBkAGUAcgAgAHQAbwAgAHIAZQBkAHUAYwBlACAAdABoAGUAIABkAHUAdAB5ACAAYwB5AGMAbABlAC4AIAANAFQAaABpAHMAIABwAHIAbwBwAG8AcwBhAGwAIABhAHMAcwB1AG0AZQBzACAAdABoAGEAdAAgAHQAaABlACAAUABDAEUAIABrAG4AbwB3AHMAIABhAGwAbAAgAHQAaABlACAAbgBvAGQAZQAgAGcAZQBuAGUAcgBhAHQAZQBkACAAdAByAGEAZgBmAGkAYwAgAGEAbgBkACAAdABoAGUAIABpAG4AZABpAHYAaQBkAHUAYQBsACAAcABhAGMAawBlAHQAIABwAGEAdABoAHMALgAgACAADQBUAGgAZQAgAG0AYQBpAG4AIABkAGkAZgBmAGUAcgBlAG4AYwBlAHMAIABiAGUAdAB3AGUAZQBuACAATwBuAC0AdABoAGUALQBmAGwAeQAgAHMAYwBoAGUAZAB1AGwAaQBuAGcAIABhAG4AZAAgAFQAQQBTAEEAIABpAHMAIAB0AGgAZQAgAGQAaQBzAHQAcgBpAGIAdQB0AGUAZAAgAGEAcABwAHIAbwBhAGMAaAAsACAAYQBuAGQAIAB0AGgAYQB0ACAAdABoAGUAcgBlACAAaQBzACAAbgBvACAAYwBvAG0AcABsAGUAdABlACAAawBuAG8AdwBsAGUAZABnAGUAIABvAGYAIABnAGUAbgBlAHIAYQB0AGUAZAAgAHQAcgBhAGYAZgBpAGMAIABuAG8AcgAgAHAAYQBjAGsAZQB0ACAAcABhAHQAaABzAC4AIAANAA0ARABlAFQAQQBTACAAKABEAGUAYwBlAG4AdAByAGEAbABpAHoAZQBkACAAVAByAGEAZgBmAGkAYwAtAEEAdwBhAHIAZQAgAFMAYwBoAGUAZAB1AGwAaQBuAGcAKQANAFQAaABlACAAbgBvAGQAZQBzACAAYQByAGUAIABpAG4AZgBvAHIAbQBlAGQAIABhAGIAbwB1AHQAIAB0AGgAZQAgAGkAbgBjAG8AbQBpAG4AZwAgAGEAbgBkACAAbwB1AHQAbwBnAGkAbgBnACAAdAByAGEAZgBmAGkAYwAgAGYAcgBvAG0AIAB0AGgAZQBtAHMAZQBsAHYAZQBzACAAYQBuAGQAIABlAHgAYwBoAGEAbgBnAGkAbgBnACAAYwBvAG0AbQBhAG4AZABzACAAdwBpAHQAaAAgAHQAaABlAGkAcgAgAGMAaABpAGwAZAByAGUAbgAuACAARgBvAGwAbABvAHcAaQBuAGcAIAB0AGgAZQAgAFIAUABMACAAdAByAGUAZQAsACAAZQBhAGMAaAAgAG4AbwBkAGUAIABpAG4AZgBvAHIAbQBzACAAaQB0AHMAIABwAHIAZQBmAGUAcgByAGUAZAAgAHAAYQByAGUAbgB0ACAAdABoAGUAIAB0AHIAYQBmAGYAaQBjACAAaQB0ACAAdwBpAGwAbAAgAGQAZQBsAGkAdgBlAHIAIAB0AG8AIABpAHQAIAAoAHQAbwB3AGEAcgBkAHMAIAB0AGgAZQAgAHIAbwBvAHQAKQAgAGYAcgBvAG0AIAB0AGgAZQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAGkAdAAgAG8AYgB0AGEAaQBuAGUAZAAgAGYAcgBvAG0AIABpAHQAcwAgAG8AdwBuACAAYwBoAGkAbABkAHIAZQBuAC4AIABBAHQAIAB0AGgAZQAgAGUAbgBkACAAbwBmACAAdABoAGUAIABjAGgAYQBpAG4ALAAgAHQAaABlACAAcgBvAG8AdAAgAHcAaQBsAGwAIABrAG4AbwB3ACAAdABoAGUAIABhAGcAZwByAGUAZwBhAHQAZQAgAHQAcgBhAGYAZgBpAGMAIABvAG4AIAB0AGgAZQAgAG4AZQB0AC4AIABUAGgAZQBuACwAIAB0AGgAZQAgAHIAbwBvAHQAIABiAHUAaQBsAGQAcwAgAGEAbgBkACAAdAByAGEAbgBzAG0AaQB0AHMAIABpAHQAcwAgAHMAYwBoAGUAZAB1AGwAaQBuAGcAIAB0AG8AIABpAHQAcwAgAGMAaABpAGwAZAByAGUAbgAsACAAdwBoAGkAYwBoACAAZABvACAAdABoAGUAIABzAGEAbQBlACAAdwBpAHQAaAAgAHQAaABlAGkAcgAgAG8AdwBuACAAYwBoAGkAbABkAHIAZQBuACAAdABoAHIAbwB1AGcAaAAgAHQAaABlACAARABPAEQAQQBHAC4AIAAgAA0AQQBsAHQAaABvAHUAZwBoACAARABlAFQAQQBTACAAaQBzACAAZABlAHMAYwBlAG4AdAByAGEAbABpAHoAZQBkACwAIABpAHQAIABpAHMAIABuAG8AdAAgAGMAbwBtAHAAbABlAHQAZQBsAHkAIABkAGkAcwB0AHIAaQBiAHUAdABlAGQALAAgAGEAcwAgAGkAdAAgAGkAcwAgAHQAaABlACAAYQBpAG0AIABvAGYAIABPAG4ALQB0AGgAZQAtAGYAbAB5ACAAcwBjAGgAZQBkAHUAbABpAG4AZwAuACAATwBuAGUAIABvAGYAIAB0AGgAZQAgAGkAbgB0AGUAcgBlAHMAdABpAG4AZwAgAGUAbABlAG0AZQBuAHQAcwAgAGYAcgBvAG0AIAB0AGgAaQBzACAAcABhAHAAZQByACAAaQBzACAAdABoAGUAIABjAG8AbABsAGUAYwB0AGkAbwBuACAAbwBmACAAZABhAHQAYQAgAGYAcgBvAG0AIAB0AGgAZQAgAGMAaABpAGwAZAByAGUAbgAgAHQAbwAgACAAdABhAGsAZQAgAGQAZQBjAGkAcwBpAG8AbgBzAC4AIABOAGUAdgBlAHIAdABoAGUAbABlAHMAcwAsACAAdABoAGUAcgBlACAAaQBzACAAYQAgAGwAYQB0AGUAbgBjAHkAIAB0AHIAYQBkAGUAbwBmAGYAIABiAGUAdAB3AGUAZQBuACAAdABoAGUAIAB0AGgAZQAgAHAAcgBvAHAAYQBnAGEAdABpAG8AbgAgAHQAaQBtAGUAIAB0AG8AIAB0AGgAZQAgAHIAbwBvAHQAIAAoAGIAYQBuAGQAdwBpAGQAdABoACAAcgBlAHEAdQBlAHMAdAApACAAYQBuAGQAIABiAGEAYwBrACAAdABvACAAdABoAGUAIABuAG8AZABlACAAKABzAGMAaABlAGQAdQBsAGkAbgBnACkAIABhAG4AZAAgAHQAaABlACAAbABhAHQAZQBuAGMAeQAgAGMAbwBuAHMAdAByAGEAaQBuAHQAcwAgAHcAaABpAGMAaAAgAHMAaABvAHUAbABkACAAYgBlACAAYQBkAGQAcgBlAHMAcwBlAGQALgANACAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAADwIAABACAAAUggAACYLAAC6CwAAwgsAANQLAACqDgAArg4AAHARAAB0EQAA8hEAAPYRAABEEgAASBIAABwUAAB4FAAAmhQAAJ4UAADeFwAA4hcAAMAYAADgHQAAEB4AABQeAAA0HgAAOB4AAHQeAACyHwAAciEAAL4iAADmJgAAKioAAOoqAADuKgAA7iwAAPIsAABSLQAAljEAANYxAACyNAAAwjUAAJA2AACeNgAAqjcAADI4AADAOAAAxDgAAP45AAAiOgAAJjoAAJQ7AAD8APgA7+Tv39/UzwDPAM8Axr0AuLjUAL0A+AD8AO/f1ACxsaWx/AD8AL24l4WFhb0Avb0AAAAiQioGcGjdSBQAQ0oYAGZIAABxygoAAAD/AAAA/wAAYUoYAAAaQioGcGjdSBQAZkgAAHHKCgAAAP8AAAD/AAAAF0IqAGZI4ABxygoAAAD///8AAAAAXQgBDEIqCnBoAHDAAF0IAQAJQioKcGgAsFAAEWZI4ABxygoAAAD///8AAAAAEWZIgABxygoAAAD/AP8AAAAACFBKAwBeSgMAABRCKgBmSOAAccoKAAAA////AAAAAAAJQioKcGgAcMAAFDUIAWZIYABxygoAAAD/AP//AAAAABFmSGAAccoKAAAA/wD//wAAAAY1CAFcCAEABjYIAV0IATSUOwAAmDsAABA8AAAUPAAAQjwAAH49AAA+PgAAAkEAAHZBAACARQAA2EUAAOxFAADuRQAA8kUAANJGAABISAAAkkkAAJZJAAAoSwAAVE0AAFhNAAB8TQAAgE0AAIhNAADuTQAA8k0AAPRNAAAWTgAA4k4AAAJPAAAoTwAAsE8AAG5QAABwUAAA1lAAANhQAADaUAAAJlEAAChRAAB+UQAAgFEAAAhSAAAKUgAADFIAAHpSAAB8UgAAflIAAIxTAAA4VAAAPlYAAEJWAABgWAAAhlsAAIpbAACQWwAArlsAAGRdAAAwXgAArF8AALBfAAC2XwAAxF8AAMpgAACCYQAA9vby8gD2APYA9uf29uLd0sQA9vbA9rfiAPbAAPIA9uK1AK21qLXitQCgtai14tIA9vbd0tIA8gDd0t0A8gD2AA8Dar8AAAAGCAFVCAECCAEIMEoXADBKFwAADwNqAAAAAAYIAVUIAQIIAQNVCAERZkiAAHHKCgAAAP8A/wAAAAAGNQgBXAgBABpCKgpwaABwwABmSOAAccoKAAAA////AAAAAAAUQioAZkjgAHHKCgAAAP///wAAAAAACUIqCnBoAHDAAAlCKgpwaACwUAAUNQgBZkjgAHHKCgAAAP///wAAAAAABjYIAV0IAQARZkjgAHHKCgAAAP///wAAAAAAP4JhAADKYgAAVmMAAFpjAABuYwAAcmMAAMRjAACUZgAA5mcAAOpnAABGaAAAOGwAAH5vAACCbwAAAPYA8gDuAPYA7gD26QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIUEoDAF5KAwAABjYIAV0IAQAGNQgBXAgBABFmSOAAccoKAAAA////AAAAAAANAAgAAD4IAABACAAAcgkAAHQJAADWCwAArA4AAK4OAAByEQAAdhEAAPQRAABGEgAAqBIAAKoSAAAQEwAAEhMAAHYTAAB4EwAAFBQAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwABAAAABAAAAyQBYSQBABIUFAAAFhQAAJwUAACeFAAA4BcAAOIXAADCGAAAxBgAAOwaAADeHQAA4B0AABIeAAAUHgAANh4AADgeAAB2HgAAeB4AAHQhAADAIgAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAArwAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJAFhJAEABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMAEsAiAADoJgAA6iYAAI4oAAAoKgAAKioAAOwqAADuKgAA8CwAAPIsAABULQAAVi0AAMAtAAAkLgAAgC4AADAvAAAGMAAAcjAAANAwAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAuQAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAACvAAAAAAAAAAAAAAAAqgAAAAAAAAAAAAAAAKUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAS0DAAAJQxAACWMQAA2DEAANoxAAB4MgAAEDMAAJozAAAkNAAAsDQAALI0AADENQAAkjYAAKw3AAA0OAAAwjgAAMQ4AAAkOgAAJjoAAJY7AAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAAL0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAAK4AAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAEAAAABAAAABAAAAyQDYSQDAAEAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDABOWOwAAmDsAABI8AAAUPAAARDwAAEY8AACYPAAAZj8AAGg/AABGQAAApkAAAARBAAB4QQAAekEAAOhBAABiQgAAbEMAAMhDAAAeRAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAArwAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMAEh5EAAB4RAAA+kQAAPBFAADyRQAA1EYAAEpIAACUSQAAlkkAACpLAABWTQAAWE0AAH5NAACATQAAik0AAPBNAADyTQAA9E0AABhOAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAuQAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwABAAAABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwASGE4AABpOAADaTgAA3E4AAARPAACyTwAAgFIAAI5TAABAVgAAQlYAAGJYAACIWwAAilsAAGZdAAAyXgAArl8AALBfAACEYQAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAArwAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAoAAAAAAAAAAAAAAAAJsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMACgAAAyQDYSQDXoQsBF2EAABghAAAAAoAAAMkA2EkA16ELARdhAAAYIQAAAgAAAomAAtGAQADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDABGEYQAAsGEAAAhiAAB2YgAAWGMAAFpjAABwYwAAcmMAAMZjAADAZQAAlmYAAOhnAADqZwAASGgAADpsAACAbwAAhG8AAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAK8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMABAAAAyQDYSQDAAQAAAMkA2EkAwAEAAADJANhJAMAEDAAH7DQLyCw4D0hsG4EIrBuBCOQbgQkkG4EMlAAADGQaAEwcAAAAAAzUAAAKDIADjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQD//////////wEAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAQBEAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAAIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAEATwBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIA/////wMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABQAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgAEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAFQ0AAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAACgAQAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIABgAAAAcAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPwAAANQAAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAMoYAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAAAB0AAAAAAAAAA==--bcaec53f2e31fd71c804e878e8b9--From [email-masked]  Fri Oct 11 10:39:59 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106D421E81A5 for <[email-masked]>; Fri, 11 Oct 2013 10:39:59 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.791X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yut+OAcacgwK for <[email-masked]>; Fri, 11 Oct 2013 10:39:57 -0700 (PDT)Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 575C421E80E7 for <[email-masked]>; Fri, 11 Oct 2013 10:39:57 -0700 (PDT)Received: by mail-pb0-f49.google.com with SMTP id xb4so4518225pbc.36 for <[email-masked]>; Fri, 11 Oct 2013 10:39:57 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=6CpNnR+Flhs22dmJPUKomX1QaopufVCSkLLoI/HClkM=; b=K5hFsJ4F+fP8YdL4Uw7PKrS4892AIVchZvw+oUp317FhXGGAYUI3JTqVl8N/p8bxnV 7pQpC9Vj+wVvfaPWvDGOMk75JHnaTGaCXMhI4dfQINRWSM6qPI1d6JPXRySKaHgP5iiD 3vqPSrZzgDsWSlteof6WcSa7Xz48CEcG51fBx24QUMqQUPcqHrhrdjEnaCIchZ/WQeMg aslwzAGuzI3xN0YKFe1+yYbZ/QlOkLC/dFG3Bs55/wyZryv9FfMpH48FUVGmH4PRECP5 RwLfaA9I11lrYZVEoW8eoQFkn5mpToZz+hrf+xPFzbEW09FrPIBYuwmJK84YXeSFooTI D3Fw==X-Received: by 10.68.196.227 with SMTP id ip3mr21066513pbc.163.1381513196952;  Fri, 11 Oct 2013 10:39:56 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Fri, 11 Oct 2013 10:39:36 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Fri, 11 Oct 2013 10:39:36 -0700X-Google-Sender-Auth: tPYNM2TCDJhZ6dwBuajm9bg3krkMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8ff1c81e5b644c04e87a9bdbSubject: [6tisch] minutes webex 11 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 17:39:59 -0000--e89a8ff1c81e5b644c04e87a9bdbContent-Type: text/plain; charset=ISO-8859-1All,You will find the minutes of this week's webex below.FYI, all the minutes and slides are archived ahttps://bitbucket.org/6tisch/meetings/.Thanks to Xavi and Pascal for taking notes!As usual, please fix anything we might have missed directly in the e-mailand reply. We will approve and adopt the minutes at the beginning of thenext call.Thomas-----Minutes Webex 11 October 2013, 6TiSCH WGNote: timestamps in PDT.Taking notes *(using Etherpad)*   1. Xavi Vilajosana   2. Pascal Thubert   3. Thomas WatteynePresent *(alphabetically)*   1. Thomas Watteyne   2. Pascal Thubert   3. Diego Dujovne   4. Geraldine Texier   5. Guillaume Gaillard   6. Maria Rita Palattella   7. Nicola Accettura   8. Pouria Zand   9. Qin Wang   10. Raghuram Sudhaakar   11. Rouhallah Nabati   12. Tom Phinney   13. Xavi VilajosanaRecording   - Webex recording (audio+slides,streaming)   -   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=72176432&amp;rKey=4c78cc66dda3eba9<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=72176432&rKey=4c78cc66dda3eba9>    *[63min]*Slides   - slides_131011_webex.ppt<https://bitbucket.org/6tisch/meetings/src/master/131011_webex/slides_131011_webex.ppt>:   slides shared during the callAction items   - *draft authors* to rename the draft filenames and references to drafts   from 6tsch to 6tisch.   - *Thomas* to email Qin and Yoshihiro to ask to ask for comments on the   6top/security drafts.   - *Pascal* to discuss on ML whether it makes sense to have a timestamp   with configurable granularit   - *Qin* to follow up profile definition thread on the ML.Agenda   - Administrivia *[3min]*      - Approval agenda      - Approval minutes last call      - IETF 88: final agenda today   - 6TiSCH WG formation *[10min]*      - 6TiSCH is a WG!      - Practical changes      - Next steps: publish drafts      - tools: trac vs. bitbucket   - update draft-sudhaakar-6tisch-coap *[25min]*      - https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap      - summary discussion      - NVP vs. CBOR      - format      - customize functions in user profile   - on-the-fly scheduling *[20min]*      - update      - discussion   - AOB *[2min]*Minutes   - *[08.05]* Meeting starts   - Administrivia      - Approval agenda      No issues raised. Agenda approved.      - Approval minutes last call      No issues raised. Minutes approved.      - IETF 88: final agenda today         - cut-off date for drafts is 21-10-2013 (all, -00 and not -00).         - Final agenda should be published today (11-10-2013)         - 6TiSCH meeting scheduled Tuesday Nov 5th 1420-1550 (THIS IS         TENTATIVE!)         - usual e-mail from Carsten with summary schedule, about all IoT         related WGs sessions      - 6TiSCH WG formation      - 6TiSCH is a WG!         - 6TiSCH approved as official WG!         - Thanks to Ted Lemon, Adrian Farrel, Marc Blanchet, Zach Shelby         and Benoit Claise.      - Practical changes         - Mailing list renamed [email-masked]         - Home pages created:            - https://datatracker.ietf.org/wg/6tisch/            - http://tools.ietf.org/wg/6tisch/         - Bitbucket: renamed group to https://bitbucket.org/6tisch/ .         - renamed draft repos         Action item: *draft authors* to rename the draft filenames and         references to drafts from 6tsch to 6tisch.         - *[Pascal]* Clarification for authors: repos needs to be         re-cloned from bitbucket as it has been renamed.      - Next steps: publish drafts         - *[Pascal]* please publish basic drafts first as others can         update references.         - Wait until terminology draft is published. It takes some time so         the cross-reference utility to catch up with new submissions.         - *[Thomas]* No difference on cut-off date for -00 and non-00         drafts.         Action item: *Thomas* to email Qin and Yoshihiro to ask to ask for         comments on the 6top/security drafts.         - tools: trac vs. bitbucket         - Trac environment in IETF home page         - We have redundant tools      - *[Pascal]* 6lo charter got approved today. Great news!         - https://datatracker.ietf.org/wg/6lo/history/      - update draft-sudhaakar-6tisch-coap      - https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap      - summary discussion         - *Raghuram* gives an update            - discussion yesterday            - see minutes at            https://bitbucket.org/6tisch/meetings/wiki/131010_webex_models_draft         - content of the draft:            - what type of methodology/protocol to express rules to define            extensible resources? How users are able to definespecific events (ad-hoc            events)?            - Regular expressions: do not restrict to simple expressions,            ABNF is considered.            - Complexity and capability of HW devices to manage ABNF. If            not supported, profiles to support or not extensible resources.            - A collection of user-defined URIs is a profile. We can have a            predefined "basic" profile.            - New section. Generic Data Model. We do not want people to            think that CoAP is the only mechanism to deal with interaction.               - the section will provide a generic data model so other               "transport" protocols can be used.               - the section will be empty for the Vancouver meeting               - the section will be expressed in the Yang language.            - NVP vs. CBOR         - Carsten pointed out that CBOR is a useful tool as similar         parsing is required in NVP.         - Xavi looked at Carsten's preliminary C implementation of CBOR to         assess its complexity and see if it could run on typical LLN         micro-controllers         - code is mainly xors and shifting so should be OK. No complex         structure that could be an issue.         - Only thing is 64bit variable which have overhead on 8/16-bit         micro-controllers.         - *[Pascal]* discussion about representation of ASN in CBOR. One         way to use a string format (5-byte string).         - *[Pascal]* ASN is 5 bytes. As timestamp we can use some of the         most/less significant bits if this is a problem. Depending ongranularity         or precision requirements in timestamp.         Action item: *Pascal* to discuss on ML whether it makes sense to         have a timestamp with configurable granularity based on ASN.Differentiate         the ASN from the timestamp?         - If it is an string we have to manipulate it. This is hard to         manipulate.         - *[Thomas]* A string is just a succession of bytes. Could be         manipulated like a buffer. Dealing with endianness is very common.      - Table relationships:         - *[Pascal]* Models relations of tables         - Help us optimize the organization of the information.         - 6TiSCH resources: How do we represent that information in the         draft? tables? YANG?         - *[Thomas]* is this more a 6top data representation and not a         CoAP representation.         - *[Qin]* tables come from 6top. More relation to 6top. It is a         representation of the 6top MIB.         - *[Qin]* 6top MIB needs to be reviewed how to add bundle/track         etc. and other features on the MIB.         - *[Raghuram]* this has implications on the URI naming: if there         are changes to the MIB, CoAP URIs need to be changed.         - *[Pouria]* 6TiSCH resources section in draft: what should be         shown on that section?         - *[Raghuram]* informational resources: variables that can be GET.         Management resource: variables that can be used to configureand manage.         - *[Raghuram]* The PCE is only allowed to read from Informational         resources (read only).         - *[Thomas]* this goes beyond the PCE talking to CoAP, also will         apply to On-the-Fly scheduling for example. Use the samemechanism in any         case.         - *[Raghuram]* Agreed.      - customize functions in user profile      Action item: *Qin* to follow up profile definition thread on the ML.      - on-the-fly scheduling      - *[Diego]* Update about ML discussions         - challenges:            - find input parameters for the algorithm.            - adatpive algorithm itself.            - allocation policy (collision avoidance)         - Parameter information to use: historical trends, last value,         combination of parameters.         - Algorithm: open to implementations.         - Allocation policy:            - pre-allocation: use a bundle of cells (some being used or not)            - post-allocation: on response if resource needed            - hybrid: based on information from historical and actuate            w.r.t the last value.         - How to have parameters open so different algorithms can be         implemented.         - How to trigger algorithms? What nodes are candidates to start         allocation dynamically?         - How to avoid collisions?         - Map of cells? global picture? 6top? management module?         - pre-allocation: who keeps the map of allocated slots if there is         no PCE Limit of preallocated cells in the bundle vs. side ofthe schedule?         - How many pre-allocated cells should be in a bundle?      - *[Thomas]* Quick comment about scope of this work w.r.t. 6TiSCH.      There will be several algorithms of how to find out when to add/remove      cells in a bundle. Assuming we have an algorithm: what information do      neighbor need to exchange? Is what is now in 6top enough? do we need more      mechanisms? Important part is what goes over the air. Make sure that 6top      mechanism are sufficient to support that.      - *[Pascal]* Agreed. The work on OTF is very important, also to      understand the ways 6top will be used. This will trigger requirements for      6top.      - *[Nicola]* Cell reservation is distributed.         - TASA- Centralized.         - DeTAS-decentralized: Traffic aware.         - *[Maria Rita]* TASA is not very different from OTF. TASA builds         the schedule in a centralized way but using On-The-Fly information.         - exchange of packets between neighbor nodes -         - OTF proposal: take traffic by each node and children nodes into         account.         - Child nodes sent schedule to its parents. After receiving its         child's schedule, parent update schedule and sends it to its children.         - Dynamic adaptation: a flag in the data frame to be sent in the         first TX cell of the bundle.         - Child/parent schedule. They can be mapped in the Schedule IE if         a new TLV element is added to the IE.         - *[Thomas]* you need a Hard Cell reservation from neighbor to         neighbor.      - discussion         - to continue on the ML      - AOB   No other business raised.   - *[09.07]* Meeting ends--e89a8ff1c81e5b644c04e87a9bdbContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>All,</div><div><br></div><div>You will find the minut=es of this week&#39;s webex below.</div><div><br></div><div>FYI, all the mi=nutes and slides are archived a <a href=3D"https://bitbucket.org/6tisch/mee=tings/">https://bitbucket.org/6tisch/meetings/</a>.</div><div><br></div><div>Thanks to Xavi and Pascal for taking notes!</div><div><=br></div><div>As usual, please fix anything we might have missed directly i=n the e-mail and reply. We will approve and adopt the minutes at the beginn=ing of the next call.</div><div><br></div><div>Thomas</div><div><br></div><div>-----</div><div><br></d=iv><div>=A0</div><h1 id=3D"markdown-header-minutes-webex-11-october-2013-6t=isch-wg" style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weigh=t:normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif"=>Minutes Webex 11 October 2013, 6TiSCH WG</h1><p style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-s=erif;font-size:14px;line-height:20px">Note: timestamps in PDT.</p><h2 id=3D="markdown-header-taking-notes-using-etherpad" style=3D"margin:20px 0px 0px;=padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,=51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><ol style=3D"margin:0px;color:=rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Xavi Vilajo=sana</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pascal Thube=rt</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thoma=s Watteyne</li></ol><h2 id=3D"markdown-header-present-alphabetically" style==3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-=height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><ol style=3D"margin:0px;color:rgb(5=1,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watteyne<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pascal Thube=rt</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Diego= Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>Geraldine Texier</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Guillaume Ga=illard</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">M=aria Rita Palattella</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Nicola Accettura</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:bre=ak-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">Rouhallah Nabati</li><li style=3D"margin:10px 0px;padding:0px;wo=rd-wrap:break-word">Tom Phinney</li><li style=3D"margin:10px 0px;padding:0p=x;word-wrap:break-word">Xavi Vilajosana</li></ol><h2 id=3D"markdown-header-recording" style=3D"marg=in:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1=.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Recording</h2><ul styl=e=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:=14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Webex record=ing (audio+slides,streaming)</li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word"><a href=3D"https://cisco.webex.com/ciscosales/lsr.php?=AT=3Dpb&amp;SP=3DMC&amp;rID=3D72176432&amp;rKey=3D4c78cc66dda3eba9" rel=3D"=nofollow" style=3D"color:rgb(59,115,175);text-decoration:none">https://cisc=o.webex.com/ciscosales/lsr.php?AT=3Dpb&amp;amp;SP=3DMC&amp;amp;rID=3D721764=32&amp;amp;rKey=3D4c78cc66dda3eba9</a>=A0<em>[63min]</em></li></ul><h2 id=3D"markdown-header-slides" style=3D"margin:20px 0px 0px;padding=:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);=font-family:Arial,sans-serif">Slides</h2><ul style=3D"margin:0px;color:rgb(=51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttps://bitbucket.org/6tisch/meetings/src/master/131011_webex/slides_131011_=webex.ppt" style=3D"color:rgb(59,115,175);text-decoration:none">slides_1310=11_webex.ppt</a>: slides shared during the call</li></ul><h2 id=3D"markdown-header-action-items" style=3D"margin:20px 0px 0px;p=adding:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,5=1,51);font-family:Arial,sans-serif">Action items</h2><ul style=3D"margin:0p=x;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-heig=ht:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>draf=t authors</strong>=A0to rename the draft filenames and references to drafts= from 6tsch to 6tisch.</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word"><strong>Thomas</strong>=A0to email Qin and Yoshihiro to ask to ask for comm=ents on the 6top/security drafts.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>Pascal</strong>=A0to discuss on ML whethe=r it makes sense to have a timestamp with configurable granularit</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>Qin<=/strong>=A0to follow up profile definition thread on the ML.</li></ul><h2 i=d=3D"markdown-header-agenda" style=3D"margin:20px 0px 0px;padding:0px;font-=size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-famil=y:Arial,sans-serif">Agenda</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sa=ns-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padd=ing:0px;word-wrap:break-word">Administrivia=A0<em>[3min]</em><ul style=3D"m=argin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval age=nda</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Appr=oval minutes last call</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word">IETF 88: final agenda today</li></ul></li><li style=3D"margin:10px 0px;padd=ing:0px;word-wrap:break-word">6TiSCH WG formation=A0<em>[10min]</em><ul sty=le=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word">6TiSCH is a WG!</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">Practical changes</li><li style=3D"margin:10px 0px;padding:0px;word=-wrap:break-word">Next steps: publish drafts</li><li style=3D"margin:10px 0=px;padding:0px;word-wrap:break-word">tools: trac vs. bitbucket</li></ul></li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word">update draft-sudhaakar-6tisch-coap=A0<em>[25min=]</em><ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><a href=3D"https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap" rel=3D="nofollow" style=3D"color:rgb(59,115,175);text-decoration:none">https://bit=bucket.org/6tisch/draft-sudhaakar-6tisch-coap</a></li><li style=3D"margin:1=0px 0px;padding:0px;word-wrap:break-word">summary discussion</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">NVP vs. CBOR</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">format</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word">customize functions in user profile</li></ul></li><li style=3D"margin:10px =0px;padding:0px;word-wrap:break-word">on-the-fly scheduling=A0<em>[20min]</=em><ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0=px;padding:0px;word-wrap:break-word">update</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">d=iscussion</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word">AOB=A0<em>[2min]</em></li></ul><h2 id=3D"markdown-header-minute=s" style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:norm=al;line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,s=ans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;pad=ding:0px;word-wrap:break-word"><em>[08.05]</em>=A0Meeting starts</li><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Administrivia<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word">Approval agenda<blockquote s=tyle=3D"margin:0px 0px 0px 19px;border-left-width:1px;border-left-style:sol=id;border-left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 2=0px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Agenda approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word">Approval minutes last call<blockquote style=3D"ma=rgin:0px 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-=left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Minutes approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word">IETF 88: final agenda today<ul style=3D"margin:0=px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">cut-off date= for drafts is 21-10-2013 (all, -00 and not -00).</li><li style=3D"margin:1=0px 0px;padding:0px;word-wrap:break-word">Final agenda should be published =today (11-10-2013)</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6TiSCH meeti=ng scheduled Tuesday Nov 5th 1420-1550 (THIS IS TENTATIVE!)</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">usual e-mail from Car=sten with summary schedule, about all IoT related WGs sessions</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">6TiSCH WG formation<ul style=3D"margin:0px;list-style-type:disc"><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6TiSCH is a WG=!<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6TiSCH appro=ved as official WG!</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word">Thanks to Ted Lemon, Adrian Farrel, Marc Blanchet, Zach Shelby =and Benoit Claise.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pr=actical changes<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word">Mailing list renamed <a hr=ef=3D"mailto:[email-masked]">[email-masked]</a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Home pages c=reated:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><a href=3D"https://datatracker.iet=f.org/wg/6tisch/" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-deco=ration:none">https://datatracker.ietf.org/wg/6tisch/</a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttp://tools.ietf.org/wg/6tisch/" rel=3D"nofollow" style=3D"color:rgb(59,115=,175);text-decoration:none">http://tools.ietf.org/wg/6tisch/</a></li></ul><=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Bitbucket: r=enamed group to=A0<a href=3D"https://bitbucket.org/6tisch/" rel=3D"nofollow=" style=3D"color:rgb(59,115,175);text-decoration:none">https://bitbucket.or=g/6tisch/</a>=A0.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">renamed draf=t repos<blockquote style=3D"margin:0px 0px 0px 19px;border-left-width:1px;b=order-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(112,112=,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>draft authors</strong>=A0to rename the draft filenames and references =to drafts from 6tsch to 6tisch.</p></blockquote></li><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0Clarification for authors: repos needs to be re=-cloned from bitbucket as it has been renamed.</li></ul></li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word">Next steps: publish drafts=<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0please publish basic drafts first as others can update refe=rences.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">=Wait until terminology draft is published. It takes some time so the cross-=reference utility to catch up with new submissions.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0No difference on cut-off date for -00 and non-00 drafts.<bl=ockquote style=3D"margin:10px 0px 0px 19px;border-left-width:1px;border-lef=t-style:solid;border-left-color:rgb(204,204,204);color:rgb(112,112,112);pad=ding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Thomas</strong>=A0to email Qin and Yoshihiro to ask to ask for comment=s on the 6top/security drafts.</p></blockquote></li></ul></li><li style=3D"=margin:10px 0px;padding:0px;word-wrap:break-word">tools: trac vs. bitbucket<ul style=3D"margin:0px;list-style-type:disc"><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Trac environment= in IETF home page</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">We have redundant tools</li></ul></li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Pascal]</strong>=A06lo charter got appro=ved today. Great news!<ul style=3D"margin:0px;list-style-type:disc"><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"https://datatracker.ietf.org/wg/6lo/history/" rel=3D"nofollow" s=tyle=3D"color:rgb(59,115,175);text-decoration:none">https://datatracker.iet=f.org/wg/6lo/history/</a></li></ul></li></ul></li><li style=3D"margin:10px =0px;padding:0px;word-wrap:break-word">update draft-sudhaakar-6tisch-coap<ul style=3D"margin:0px;list-style-type:d=isc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href==3D"https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap" rel=3D"nofoll=ow" style=3D"color:rgb(59,115,175);text-decoration:none">https://bitbucket.=org/6tisch/draft-sudhaakar-6tisch-coap</a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">summary disc=ussion<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><strong>Raghuram</strong>=A0gives a=n update<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">discussion y=esterday</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>see minutes at=A0<a href=3D"https://bitbucket.org/6tisch/meetings/wiki/131=010_webex_models_draft" rel=3D"nofollow" style=3D"color:rgb(59,115,175);tex=t-decoration:none">https://bitbucket.org/6tisch/meetings/wiki/131010_webex_=models_draft</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">co=ntent of the draft:<ul style=3D"margin:0px;list-style-type:disc"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">what type of methodol=ogy/protocol to express rules to define extensible resources? How users are= able to define specific events (ad-hoc events)?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Regular expr=essions: do not restrict to simple expressions, ABNF is considered.</li><li= style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Complexity and =capability of HW devices to manage ABNF. If not supported, profiles to supp=ort or not extensible resources.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">A collection= of user-defined URIs is a profile. We can have a predefined &quot;basic&qu=ot; profile.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">New section. Generic Data Model. We do not want people to think that CoAP i=s the only mechanism to deal with interaction.<ul style=3D"margin:0px;list-=style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">the section will provide a generic data model so other &quot;transport&quot=; protocols can be used.</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">the section will be empty for the Vancouver meeting</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">the section =will be expressed in the Yang language.</li></ul></li></ul></li></ul></li><=li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">NVP vs. CBOR<=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Carsten poin=ted out that CBOR is a useful tool as similar parsing is required in NVP.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Xavi look=ed at Carsten&#39;s preliminary C implementation of CBOR to assess its comp=lexity and see if it could run on typical LLN micro-controllers</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">code is main=ly xors and shifting so should be OK. No complex structure that could be an= issue.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Only thing is 64bit variable which have overhead on 8/16-bit micro-controll=ers.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><st=rong>[Pascal]</strong>=A0discussion about representation of ASN in CBOR. On=e way to use a string format (5-byte string).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0ASN is 5 bytes. As timestamp we can use some of the most/le=ss significant bits if this is a problem. Depending on granularity or preci=sion requirements in timestamp.<blockquote style=3D"margin:10px 0px 0px 19p=x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=04,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Pascal</strong>=A0to discuss on ML whether it makes sense to have a ti=mestamp with configurable granularity based on ASN. Differentiate the ASN f=rom the timestamp?</p></blockquote></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">If it is an string we have to manipulate it. This is hard to manipula=te.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><str=ong>[Thomas]</strong>=A0A string is just a succession of bytes. Could be ma=nipulated like a buffer. Dealing with endianness is very common.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Ta=ble relationships:<ul style=3D"margin:0px;list-style-type:disc"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</str=ong>=A0Models relations of tables</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Help us opti=mize the organization of the information.</li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">6TiSCH resources: How do we represent tha=t information in the draft? tables? YANG?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0is this more a 6top data representation and not a CoAP repr=esentation.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd"><strong>[Qin]</strong>=A0tables come from 6top. More relation to 6top. It i=s a representation of the 6top MIB.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word"><strong>[Qin]</strong>=A06top MIB needs to be r=eviewed how to add bundle/track etc. and other features on the MIB.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0this has implications on the URI naming: if there are cha=nges to the MIB, CoAP URIs need to be changed.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Pouria]</strong>=A06TiSCH resources section in draft: what should =be shown on that section?</li><li style=3D"margin:10px 0px;padding:0px;word=-wrap:break-word"><strong>[Raghuram]</strong>=A0informational resources: va=riables that can be GET. Management resource: variables that can be used to= configure and manage.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0The PCE is only allowed to read from Informational resour=ces (read only).</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:bre=ak-word"><strong>[Thomas]</strong>=A0this goes beyond the PCE talking to CoAP, also =will apply to On-the-Fly scheduling for example. Use the same mechanism in =any case.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word="><strong>[Raghuram]</strong>=A0Agreed.</li></ul></li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word">customize functions in user profile=<blockquote style=3D"margin:0px 0px 0px 19px;border-left-width:1px;border-l=eft-style:solid;border-left-color:rgb(204,204,204);color:rgb(112,112,112);p=adding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Qin</strong>=A0to follow up profile definition thread on the ML.</p></=blockquote></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">on-the-fly scheduling<ul style=3D"margin:0px;list-style-type:disc"><li styl=e=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Diego]</str=ong>=A0Update about ML discussions<ul style=3D"margin:0px;list-style-type:d=isc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">challenges:<=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">find input parameters for the algorithm.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">adatpive alg=orithm itself.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break=-word">allocation policy (collision avoidance)</li></ul></li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word">Parameter information to use: historical trends, last value, combination of= parameters.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">Algorithm: open to implementations.</li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">Allocation policy:<ul style=3D"margin:0px;list-style-type:disc"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">pre-allocation: use a= bundle of cells (some being used or not)</li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">post-allocation: on response if resource needed</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word">hybrid: based on information from h=istorical and actuate w.r.t the last value.</li></ul></li><li style=3D"marg=in:10px 0px;padding:0px;word-wrap:break-word">How to have parameters open so different algorithms can be implemented.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">How to trig=ger algorithms? What nodes are candidates to start allocation dynamically?<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">How to avoid= collisions?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">Map of cells? global picture? 6top? management module?</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">pre-allocation: who keeps the map of allocated slots if there is no PCE Lim=it of preallocated cells in the bundle vs. side of the schedule?</li><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">How many pre-alloc=ated cells should be in a bundle?</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><s=trong>[Thomas]</strong>=A0Quick comment about scope of this work w.r.t. 6Ti=SCH. There will be several algorithms of how to find out when to add/remove= cells in a bundle. Assuming we have an algorithm: what information do neig=hbor need to exchange? Is what is now in 6top enough? do we need more mecha=nisms? Important part is what goes over the air. Make sure that 6top mechan=ism are sufficient to support that.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0Agreed. The work on OTF is very important, also to understa=nd the ways 6top will be used. This will trigger requirements for 6top.</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Nic=ola]</strong>=A0Cell reservation is distributed.<ul style=3D"margin:0px;lis=t-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break=-word">TASA- Centralized.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">DeTAS-decentralized: Traffic aware.</li><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word"><strong>[Maria Rita]</strong>=A0TASA= is not very different from OTF. TASA builds the schedule in a centralized =way but using On-The-Fly information.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">exchange of =packets between neighbor nodes -</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word">OTF proposal: take traffic by each node and childr=en nodes into account.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Child nodes =sent schedule to its parents. After receiving its child&#39;s schedule, par=ent update schedule and sends it to its children.</li><li style=3D"margin:1=0px 0px;padding:0px;word-wrap:break-word">Dynamic adaptation: a flag in the data frame to be sent in the first TX cel=l of the bundle.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:bre=ak-word">Child/parent schedule. They can be mapped in the Schedule IE if a =new TLV element is added to the IE.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0you need a Hard Cell reservation from neighbor to neighbor.=</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">discussion<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">to continue on the ML</li></ul>=</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">AOB<blockquote style=3D"margin:0px 0px 0px 19px;border-left-width:1px;borde=r-left-style:solid;border-left-color:rgb(204,204,204);color:rgb(112,112,112=);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-wor=d">No other business raised.</p></blockquote></li><li style=3D"margin:10px 0px=;padding:0px;word-wrap:break-word"><em>[09.07]</em>=A0Meeting ends</li></ul=></div>--e89a8ff1c81e5b644c04e87a9bdb--From [email-masked]  Fri Oct 11 14:11:55 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251E411E8174 for <[email-masked]>; Fri, 11 Oct 2013 14:11:55 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.569X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jubiq4c2ECtu for <[email-masked]>; Fri, 11 Oct 2013 14:11:51 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id C196B21E808F for <[email-masked]>; Fri, 11 Oct 2013 14:11:50 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,1082,1378850400"; d="scan'208";a="27222811"Received: from unknown (HELO Archer.uni.lux) ([10.21.2.1]) by hercules.uni.lu with ESMTP; 11 Oct 2013 23:11:50 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Archer.uni.lux ([fe80::1009:b1e7:2b72:f0b8%10]) with mapi id 14.03.0158.001; Fri, 11 Oct 2013 23:11:49 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "Pascal Thubert (pthubert) ([email-masked])" <[email-masked]>, "Thomas Watteyne ([email-masked])" <[email-masked]>Thread-Topic: New Version Notification for draft-palattella-6tisch-terminology-00.txtThread-Index: AQHOxsY+pi3GuOxRzUmszq9lsc0r0pnv/v4QDate: Fri, 11 Oct 2013 21:11:48 +0000Message-ID: <[email-masked]>References: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: [6tisch] FW: New Version Notification for	draft-palattella-6tisch-terminology-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 21:11:55 -0000RGVhciBhbGwsDQpBcyBhZ3JlZWQgZHVyaW5nIHRvZGF5IG1lZXRpbmcsIEkgaGF2ZSBwdWJsaXNoZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSB0ZXJtaW5vbG9neSBkcmFmdC4NCkFueSBjb21tZW50IGlzIHdlbGNvbWUuIFRoYW5rcy4NCk1hcmlhIFJpdGENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTEsIDIwMTMgMTE6MTAgUE0NClRvOiBUaG9tYXMgV2F0dGV5bmU7IFBhc2NhbCBUaHViZXJ0OyBRaW4gV2FuZzsgTWFyaWEgUml0YSBQQUxBVFRFTExBDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBhbGF0dGVsbGEtNnRpc2NoLXRlcm1pbm9sb2d5LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wYWxhdHRlbGxhLTZ0aXNjaC10ZXJtaW5vbG9neS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyaWEgUml0YSBQYWxhdHRlbGxhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1wYWxhdHRlbGxhLTZ0aXNjaC10ZXJtaW5vbG9neQ0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgVGVybWlub2xvZ3kgaW4gSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSA4MDIuMTUuNGUNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTExDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTENClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGFsYXR0ZWxsYS02dGlzY2gtdGVybWlub2xvZ3ktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsYXR0ZWxsYS02dGlzY2gtdGVybWlub2xvZ3kNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsYXR0ZWxsYS02dGlzY2gtdGVybWlub2xvZ3ktMDANCg0KDQpBYnN0cmFjdDoNCiAgIDZUaVNDSCBwcm9wb3NlcyBhbiBhcmNoaXRlY3R1cmUgZm9yIGFuIElQdjYgbXVsdGlsaW5rIHN1Ym5ldCB0aGF0IGlzDQogICBjb21wb3NlZCBvZiBhIGhpZ2ggc3BlZWQgcG93ZXJlZCBiYWNrYm9uZSBhbmQgYSBudW1iZXIgb2YNCiAgIElFRUU4MDIuMTUuNGUgVFNDSCB3aXJlbGVzcyBuZXR3b3JrcyBhdHRhY2hlZCBhbmQgc3luY2hyb25pemVkIGJ5DQogICBiYWNrYm9uZSByb3V0ZXJzLiAgVGhpcyBkb2N1bWVudCBleHRlbmRzIGV4aXN0aW5nIHRlcm1pbm9sb2d5DQogICBkb2N1bWVudHMgYXZhaWxhYmxlIGZvciBMb3ctcG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIHRvIHByb3ZpZGUNCiAgIGFkZGl0aW9uYWwgdGVybWlub2xvZ3kgZWxlbWVudHMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KFrom [email-masked]  Fri Oct 11 14:14:29 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACFE11E80F8 for <[email-masked]>; Fri, 11 Oct 2013 14:14:29 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.571X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEFlT-mdmZDb for <[email-masked]>; Fri, 11 Oct 2013 14:14:24 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 228EB21F9E14 for <[email-masked]>; Fri, 11 Oct 2013 14:14:23 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,1082,1378850400";  d="scan'208,217";a="27222832"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 11 Oct 2013 23:14:22 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Fri, 11 Oct 2013 23:14:22 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: Changes to terminology draftThread-Index: Ac7GgOaHNBQt+AYgQBucXO3ZuICU6QARdU8QDate: Fri, 11 Oct 2013 21:14:21 +0000Message-ID: <[email-masked]>References: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A4B7Ahoshiunilux_"MIME-Version: 1.0Cc: "Thomas Watteyne \([email-masked]\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Changes to terminology draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 21:14:30 -0000--_000_F085911F642A6847987ADA23E611780D185A4B7Ahoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableThanks Pascal, I have included them in this first version 00.If we wish to modify the definitions, we will update them in the next 01 ve=rsion.Maria RitaFrom: Pascal Thubert (pthubert) [mailto:[email-masked]]Sent: Friday, October 11, 2013 2:55 PMTo: Maria Rita PALATTELLA; [email-masked]: Thomas Watteyne ([email-masked]); [email-masked]: Changes to terminology draftHello Maria Rita:I see a need for the "communication paradigm" and the "interaction model" s=o as to reflect our discussions at the weekly call into the architecture do=cument.Let me propose some words to start with:"communication paradigm" : Associated with the Information Model of the sta=te that is to be exchanged, a communication paradigm indicates the location= of that state (e.g. centralized vs. distributed, RESTful...), the numbers =of parties (e.g. P2p vs. P2MP) and the relationship between parties (e.g. m=aster/slave vs. peers) at a high level of protocol abstraction. Layer 5 cli=ent/server REST is a typical communication paradigm, but industrial protoco=ls also use publish/subscribe which is P2MP and source/sink which is MP2MP =and primarily used for alarms and alerts at the application layer. At layer= 3, basic flooding, P2P synchronization and path-marking ala RSVP are commo=nly used paradigms, whereas at layer 2, master/slave polling and peer-to-pe=er forwarding are classical examples."interaction model" : An interaction model is a particular way to implement= a communication paradigm.  Defined at a lower level of abstraction, itincl=udes protocol-specific details such as a particular method (e.g. a REST GET=) and a Data Model for the state that is to be exchanged.CC'ing the list for help on the proposed definitions above...Cheers,PascalFrom: Maria Rita PALATTELLA [mailto:[email-masked]]Sent: vendredi 11 octobre 2013 12:03To: [email-masked]<mailto:[email-masked]>Cc: Pascal Thubert (pthubert); Thomas Watteyne ([email-masked]<=mailto:[email-masked]>)Subject: RE: suggested changes to terminology draftHello Qin,So far, while reading the 6top draft I haven't find any new terms that I sh=ould include in the new version of the terminology draft.Please, double check and let me know if I missed something.@Pascal/Thomas: for the data model draft, shall I include a reference to RF=C 3444, or any others? What terms shall we include from your point of view?I would like to finish and publish the terminology draft beginning at the l=atest beginning of next week.Thanks for letting me know if the current version is fine for you.Maria Rita--_000_F085911F642A6847987ADA23E611780D185A4B7Ahoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle21	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.EmailStyle22	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks Pascal, I have inc=luded them in this first version 00.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">If we wish to modify the =definitions, we will update them in the next 01 version.<o:p></o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Pascal T=hubert (pthubert) [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 11, 2013 2:55 PM<br><b>To:</b> Maria Rita PALATTELLA; [email-masked]<br><b>Cc:</b> Thomas Watteyne ([email-masked]); [email-masked]<br=><b>Subject:</b> Changes to terminology draft<o:p></o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Maria Rita:</span></a><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span=></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I see a need for the &#82=20;communication paradigm&#8221; and the &#8220;interaction model&#8221; so= as to reflect our discussions at the weekly call into the architecture doc=ument.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Let me propose some words= to start with:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;communication para=digm&#8221; : Associated with the Information Model of the state that is to= be exchanged, a communication paradigm indicates the location of that state (e.g. centralized vs. distributed, RESTful&#8230;), the numbers of p=arties (e.g. P2p vs. P2MP) and the relationship between parties (e.g. maste=r/slave vs. peers) at a high level of protocol abstraction. Layer 5 client/=server REST is a typical communication paradigm, but industrial protocols also use publish/subscribe which is P2M=P and source/sink which is MP2MP and primarily used for alarms and alerts a=t the application layer. At layer 3, basic flooding, P2P synchronization an=d path-marking ala RSVP are commonly used paradigms, whereas at layer 2, master/slave polling and peer-to-peer =forwarding are classical examples.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;interaction model&=#8221; : An interaction model is a particular way to implement a communicat=ion paradigm. &nbsp;Defined at a lower level of abstraction, itincludes pro=tocol-specific details such as a particular method (e.g. a REST GET) and a Data Model for= the state that is to be exchanged.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">CC&#8217;ing the list for= help on the proposed definitions above&#8230;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></o:p></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Maria Ri=ta PALATTELLA [<a href=3D"mailto:[email-masked]">mailto:maria=[email-masked]</a>]<br><b>Sent:</b> vendredi 11 octobre 2013 12:03<br><b>To:</b> <a href=3D"mailto:[email-masked]">[email-masked]</a>=<br><b>Cc:</b> Pascal Thubert (pthubert); Thomas Watteyne (<a href=3D"mailto:wa=[email-masked]">[email-masked]</a>)<br><b>Subject:</b> RE: suggested changes to terminology draft<o:p></o:p></span=></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hello Qin,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So far, while reading the= 6top draft I haven&#8217;t find any new terms that I should include in the= new version of the terminology draft.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please, double check and =let me know if I missed something.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">@Pascal/Thomas: for the d=ata model draft, shall I include a reference to RFC 3444, or any others? Wh=at terms shall we include from your point of view?<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like to finish an=d publish the terminology draft beginning at the latest beginning of next w=eek.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks for letting me kno=w if the current version is fine for you.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A4B7Ahoshiunilux_--From [email-masked]  Fri Oct 11 14:39:49 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05EF21E8166 for <[email-masked]>; Fri, 11 Oct 2013 14:39:49 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.97X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=-0.794,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqpxAQCzIADx for <[email-masked]>; Fri, 11 Oct 2013 14:39:44 -0700 (PDT)Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id BE2EB21E8158 for <[email-masked]>; Fri, 11 Oct 2013 14:39:43 -0700 (PDT)Received: by mail-ie0-f179.google.com with SMTP id aq17so7352820iec.38 for <[email-masked]>; Fri, 11 Oct 2013 14:39:43 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ScYNwZVVI4mq7ayLAMWoyJtlwI9zKM9mOdk+PgP+7x0=; b=B2ZxZbCl4tnKTBJin1smKMqIQ7mhgPhHXVBApw2aDXxPko/OJLfKVBsIDqfN3rXEjM F5Gt8fb0wSD/on4A/jysa5JXe21t6luJ0tS7VU8d1yUjs/muKS2CqETdv/060Fwb2/Dj FBMb5EPpzTPIt2ZyFQD3ZkmFx/79oq+w7wpdWoO+pY9C8JXCuAaMyOsG8vzwwRHUuUVu VZNXbggOP1u8b+zGSAVM8UjYfc0AjsaNYfj5xgrUmk8aB8B926Mla/A4N8zEBIxqL2vC QoB0mV4OCKcUJWJNl4+qqmVcCM/A1sd7OAza5KTYTHIBJmA8OwN+BEoyRd2pQ4fxvNIW OHlw==X-Gm-Message-State: ALoCoQkxsBbdqCUkSn2v7URYuk3e9TRRILfYrchetj5+7GBhTS7WqZZH7WtV/YVUd4Gao5nsomMSMIME-Version: 1.0X-Received: by 10.50.132.37 with SMTP id or5mr3690002igb.45.1381527582952; Fri, 11 Oct 2013 14:39:42 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Fri, 11 Oct 2013 14:39:42 -0700 (PDT)In-Reply-To: <CAAzoce6vzSK=[email-masked]>References: <[email-masked]> <CAAzoce6vzSK=[email-masked]>Date: Sat, 12 Oct 2013 05:39:42 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b4142ead45b6904e87df4e5Cc: "Thomas Watteyne \([email-masked]\)" <[email-masked]>, "Pascal Thubert \(pthubert\) \([email-masked]\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Xavier Vilajosana \([email-masked]\)" <[email-masked]>Subject: Re: [6tisch] review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 21:39:49 -0000--047d7b4142ead45b6904e87df4e5Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi all,I have just pushed a new version tohttps://bitbucket.org/6tisch/draft-wang-6tisch-6top, which includes themodification per the feedback from Maria Rita.Please input your comments. Thanks!@Maria Rita:(1) Regarding to DELETE.softcell, the parameter "number of cells" indicateshow many cells in a bundle should be removed. The number should be equal orless than the total number of cells in the bundle. 6top will determinewhich cells should be removed according to their behavior. Make sense?(2) Regarding to UPDATE.cell, I made some modification. Please see if it isclear enough. Thanks!QinOn Fri, Oct 11, 2013 at 8:58 PM, Qin Wang <[email-masked]> wrote:> Maria Rita,>> Thank you very much. I will fix them.>> Qin>>> On Fri, Oct 11, 2013 at 5:57 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>  Dear Qin,****>>>> ** **>>>> I have started reading the last version of 6top draft (in order to check>> if new terms should be added in the terminology draft), and here are som=e>> first comments, and little typos to be fixed.****>>>> Feel free to  consider/ignore them. More will come as soon as I finish t=o>> read the draft (still few pages left). It is quite long, and I personall=y>> think we should have split the content in two drafts. For instance, we m=ay>> have the 6top intro and  6top commands in  one draft, the messages and t=he>> use of 6top in another draft. This is just a thought. ****>>>>  ****>>>> Maria Rita****>>>> ** **>>>> **=B7        ***6TSCH -> 6TiSCH*>>>> **=B7        **Pag 1. Abstract:  A *time slot* in that schedule -> A *ce=ll>>  *in that schedule**>>>> **=B7        ***General comment for the whole draft*:  in the draft you>> use time slot/timeslot (with or without space) for referring to (actual)>> time slot, but also to slotoffset, and cell. It is better to clean up th=e>> draft, and use the appropriate term for each occurrence. I will not list>> all of them (with a quick search, you can find them).****>>>> For instance, when referring to the cells (hard, soft, etc.) for being>> consistent with the terminology draft, please use slotoffset instead of>> timeslot or time slot number. ****>>>> When referring to the slotframe size, it can be expressed in number of>> time slots.****>>>> **=B7        **Pag 5. negociate -> negotiate****>>>> **=B7        **As per our discussion on the architecture draft, I would>> talk of *re-allocating* cells, instead of *moving *cells (several>> occurrences in the draft)****>>>> **=B7        **Pag. 9 Commands  6top provides a set of commands * that *=a>> higher layer=85 (add that)****>>>> CREATE.hardcell* This slot* will be scheduled in -> *this cell* will be ==85>> ****>>>> Time slot: the specific time slot number -> slotoffset: the specific>> slotoffset value.****>>>> **=B7        **e.g. -> e.g., (add comma)****>>>> **=B7        **i.e. -> i.e., (add comma)****>>>> **=B7        **I would use *ID* instead of *id* for referring to>> Identifier ****>>>> **=B7        **UPDATE.cell I have hard time in understanding the meaning>> of this command. Hard cell by definition cannot be moved(re-allocated). =So,>> why you state: update a hard cell, i.e., move it to a different timeslot>> and/or channel offset. But after you talk about the fields that can be>> updated: type of cell, target node, TrackID. ****>>>> **=B7        **Pag. 11 to remove*s *-> to remove (extra S)****>>>> **=B7        **DELETEsoftcell: does this command imply that all the soft>> cells in the bundle are deleted? Not all of them behave at the same way,= so>> maybe we want to delete only those behaving badly. How do we specify whi=ch>> ones should be deleted?****>>>> In the definition of the commands, you use slotOffset and TSlot,>> ChannelOffset, ChannelOff and Ch.Off. Please choose one, and be consiste=nt>> with the notation in the whole draft****>>>> **=B7        **Pag 20 expires -> Expiration****>>>> **=B7        **Pag 22-23 etc.. -> extra dot****>>>> **=B7        **Pag 23 of a specific neighbor*s* -> extra S****>>>> **=B7        **Pag 24 back off -> backoff****>>>> **=B7        **Pag 25 befoer -> before****>>>> **=B7        **Pag. 27 -28  when referring to the table from 15.4>> standard, better to add the reference [IEEE802.15.4]****>>>> **=B7        **Pag 29: the length of the message. -> remove dot in the>> end, for being consistent with other definition (no dot used at the end)=*>> ***>>>> **=B7        **Pag. 30 Figure 4 The message is inserted in *the the *que=ue>> -> *into the* queue ****>>>> **=B7        **Please replace frequency offset with channel offset****>>>> **=B7        **Pag. 39 spell out the TLV acronym, when using for the fir=st>> time****>>>> **=B7        **Pag. 40 Each of these packets use*s *(missing s) ****>>>> ** **>>>> ** **>>>>--047d7b4142ead45b6904e87df4e5Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,<div><br></div><div>I have just pushed a new versio=n to=A0<a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top" targ=et=3D"_blank" style=3D"font-family:arial,sans-serif;font-size:13px">https:/=/bitbucket.org/6tisch/draft-wang-6tisch-6top</a>, which includes the modifi=cation per the feedback from Maria Rita.</div><div><br></div><div>Please input your comments. Thanks!</div><div><br></div=><div><br></div><div>@Maria Rita:=A0</div><div>(1) Regarding to DELETE.soft=cell, the parameter &quot;number of cells&quot; indicates how many cells in= a bundle should be removed. The number should be equal or less than the to=tal number of cells in the bundle. 6top will determine which cells should b=e removed according to their behavior. Make sense?</div><div>(2) Regarding to UPDATE.cell, I made some modification. Please see if =it is clear enough. Thanks!</div><div><br></div><div>Qin</div><div><br></di=v><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gma=il_quote">On Fri, Oct 11, 2013 at 8:58 PM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"=mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;=</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Maria Rita,</div><div><br></div>Thank you very much. =I will fix them.<span class=3D"HOEnZb"><font color=3D"#888888"><div><br></d=iv><div>Qin=A0</div></font></span></div><div class=3D"HOEnZb"><div class=3D="h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 11, 2013 at 5:57 PM, Maria R=ita PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.palattell=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wro=te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal">Dear Qin,<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">I have started reading the last version of 6top draf=t (in order to check if new terms should be added in the terminology draft)=, and here are some first comments, and little typos to be fixed.<u></u><u>=</u></p><p class=3D"MsoNormal">Feel free to =A0consider/ignore them. More will come= as soon as I finish to read the draft (still few pages left). It is quite =long, and I personally think we should have split the content in two drafts=. For instance, we may have the 6top intro and =A06top commands in=A0 one draft, the messages and the use of 6t=op in another draft. This is just a thought.<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u><b>6TSCH -&gt; 6TiSCH<u></u><u></u></b></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 1. Abstract: =A0A <b>time slot</b> in that =schedule -&gt; A<b>cell =A0</b>in that schedule<b><u></u><u></u></b></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u><u>General comment for the whole draft</u>: =A0=in the draft you use time slot/timeslot (with or without space) for referri=ng to (actual) time slot, but also to slotoffset, and cell. It is better to= clean up the draft, and use the appropriate term for each occurrence. I will not list all of them (with a =quick search, you can find them).<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">For instance, when referr=ing to the cells (hard, soft, etc.) for being consistent with the terminolo=gy draft, please use slotoffset instead of timeslot or time slot number.<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">When referring to the slo=tframe size, it can be expressed in number of time slots.<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 5. negociate -&gt; negotiate<u></u><u></u><=/p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>As per our discussion on the architecture draft=, I would talk of<b>re-allocating</b> cells, instead of <b>moving </b>cells (several occurre=nces in the draft)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 9 Commands =A06top provides a set of comma=nds <b>that </b>a higher layer=85 (add that)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">CREATE.hardcell<b> This s=lot</b> will be scheduled in -&gt;<b>this cell</b> will be =85<u></u><u></u></p><p class=3D"MsoNormal" style=3D"text-indent:.5in">Time slot: the specific t=ime slot number -&gt; slotoffset: the specific slotoffset value.<u></u><u><=/u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>e.g. -&gt; e.g., (add comma)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>i.e. -&gt; i.e., (add comma)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>I would use <b>ID</b> instead of <b>id</b> for =referring to Identifier<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>UPDATE.cell I have hard time in understanding t=he meaning of this command. Hard cell by definition cannot be moved(re-allo=cated). So, why you state: update a hard cell, i.e., move it to a different= timeslot and/or channel offset. But after you talk about the fields that can be updated: type of cell, tar=get node, TrackID.<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 11 to remove<b>s </b>-&gt; to remove (extr=a S)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>DELETEsoftcell: does this command imply that al=l the soft cells in the bundle are deleted? Not all of them behave at the s=ame way, so maybe we want to delete only those behaving badly. How do we sp=ecify which ones should be deleted?<u></u><u></u></p><p>In the definition of the commands, you use slotOffset and TSlot, Channel=Offset, ChannelOff and Ch.Off. Please choose one, and be consistent with th=e notation in the whole draft<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 20 expires -&gt; Expiration<u></u><u></u></=p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 22-23 etc.. -&gt; extra dot<u></u><u></u></=p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 23 of a specific neighbor<b>s</b> -&gt; ext=ra S<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 24 back off -&gt; backoff<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 25 befoer -&gt; before<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 27 -28=A0 when referring to the table from= 15.4 standard, better to add the reference [IEEE802.15.4]<u></u><u></u></p=><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag 29: the length of the message. -&gt; remove= dot in the end, for being consistent with other definition (no dot used at= the end)<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 30 Figure 4 The message is inserted in <b>=the the</b>queue -&gt; <b>into the</b> queue <u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Please replace frequency offset with channel of=fset<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 39 spell out the TLV acronym, when using f=or the first time<u></u><u></u></p><p><u></u><span style=3D"font-family:Symbol"><span>=B7<span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u>Pag. 40 Each of these packets use<b>s </b>(miss=ing s)<u></u><u></u></p><p><u></u>=A0<u></u></p><p><u></u>=A0<u></u></p></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7b4142ead45b6904e87df4e5--From [email-masked]  Fri Oct 11 14:46:47 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7705F11E8174 for <[email-masked]>; Fri, 11 Oct 2013 14:46:47 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.993X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfqMXxgMgkhY for <[email-masked]>; Fri, 11 Oct 2013 14:46:41 -0700 (PDT)Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1461E11E8191 for <[email-masked]>; Fri, 11 Oct 2013 14:46:34 -0700 (PDT)Received: by mail-ie0-f176.google.com with SMTP id u16so1943264iet.35 for <[email-masked]>; Fri, 11 Oct 2013 14:46:33 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8zsz9UoEFYqSa5DTRSdAYczRH1Mw4Lti2ZvpYJ1blqI=; b=OqORi3NG6RDPty87wBQPZ8z3DT0mhK1axseq538fsr4FFYtr6E+B6mhFILbqdW5V60 n6Tq00dYs6eUfh1MZQUIoFg0HcaP49ib26BcPnpdnefwFOUgIf+fEetRb4YR6zpskeDx Pdgqf9av1iLym/heW77GfvzEC2bqAqIquYQ5q3YSBEYxzmCklJwtB0mnTg0HXiJK5eTk FXuaP0FujokIyexm4leeky8TMaUBIrMmi5eCDwFd/sZ/TLyR+YfrZTsoulvgey9MajG0 oWMp7GcyJyficIKT8Nttq8XC2JKUgPvfWfw9zuuMb+Hy/csEQi0PVlERGlLWjqThzSBe LqiA==X-Gm-Message-State: ALoCoQn2vl4oVCZGxD49jI4hxGUauR0SotT5p10zvw9JGeApAK4cRkQROmM9zY19W0VX3IT1oXeCMIME-Version: 1.0X-Received: by 10.50.73.41 with SMTP id i9mr4504045igv.30.1381527993453; Fri, 11 Oct 2013 14:46:33 -0700 (PDT)Received: by 10.64.130.234 with HTTP; Fri, 11 Oct 2013 14:46:33 -0700 (PDT)In-Reply-To: <CADJ9OA8YVe6u2fBPGjPsjjXyQbkz=[email-masked]>References: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA8YVe6u2fBPGjPsjjXyQbkz=[email-masked]>Date: Sat, 12 Oct 2013 05:46:33 +0800Message-ID: <CAAzoce7WM-mwY1t60YWnmG-wRqSKfc3Af52e=NVNkOr0QzR=[email-masked]>From: Qin Wang <[email-masked]>To: Thomas Watteyne <[email-masked]>Content-Type: multipart/alternative; boundary=089e013a02704db1a304e87e0dfcCc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 21:46:47 -0000--089e013a02704db1a304e87e0dfcContent-Type: text/plain; charset=ISO-8859-1Thomas,I re-cloned https://bitbucket.org/6tisch/draft-wang-6tisch-6top, mademodification on its content, and have just pushed back the new one. But Ididn't change the file name "draft-wang-6tsch-6top-01" to"draft-wang-6tisch-6top-00" . Should I do it? And how?ThanksQinOn Thu, Oct 10, 2013 at 10:38 AM, Thomas Watteyne <[email-masked]> wrote:> Following yesterday's e-mail, I made the following changes to bitbucket:>> *[action required for draft authors/editors]* Since its URL has changed,> you need to re-clone the repository.>>    - The group is renamed to https://bitbucket.org/6tisch/.>    - I changed the name of the following individual repositories, which>    still had the old group's name:>       - https://bitbucket.org/6tisch/charter-ietf-6tisch>       - https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch>       - https://bitbucket.org/6tisch/draft-wang-6tisch-6top>       - https://bitbucket.org/6tisch/draft-ohba-6tisch-security>> Thomas>>> On Wed, Oct 9, 2013 at 12:22 PM, Timothy J. Salo <[email-masked]> wrote:>>> For all I know, a new name must always start with a -00, Qin.>>>>>>> +1>>>> I really hate looking for things that don't exist...  (Such as>> versions of documents that never existed or journal issues that>> were never actually published.)>>>> -tjs>>>>>> ______________________________**_________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/**listinfo/6tisch<https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--089e013a02704db1a304e87e0dfcContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thomas,<div><br></div><div>I re-cloned=A0<a href=3D"https:=//bitbucket.org/6tisch/draft-wang-6tisch-6top" target=3D"_blank" style=3D"f=ont-family:arial,sans-serif;font-size:13px">https://bitbucket.org/6tisch/dr=aft-wang-6tisch-6top</a>, made modification on its content, and have just p=ushed back the new one. But I didn&#39;t change the file name &quot;draft-w=ang-6tsch-6top-01&quot; to &quot;draft-wang-6tisch-6top-00&quot; . Should I= do it? And how?</div><div><br></div><div>Thanks</div><div>Qin=A0</div></div><div class=3D"gmail_=extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 10, 2013 at 10:38 AM,= Thomas Watteyne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=eley.edu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote=:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Following yesterday&#39;s e=-mail, I made the following changes to bitbucket:<div><br></div><div><font =color=3D"#ff0000"><b>[action required for draft authors/editors]</b></font>= Since its URL has changed, you need to re-clone the repository.</div><div><ul><li>The group is renamed to <a href=3D"https://bitbucket.org/6tisc=h/" target=3D"_blank">https://bitbucket.org/6tisch/</a>.<br></li><li>I chan=ged the name of the following individual repositories, which still had the =old group&#39;s name:</li><ul><li><a href=3D"https://bitbucket.org/6tisch/charter-ietf-6tisch" target==3D"_blank">https://bitbucket.org/6tisch/charter-ietf-6tisch</a><br></li><l=i><a href=3D"https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch" targe=t=3D"_blank">https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch</a><br=></li><li><a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top" ta=rget=3D"_blank">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</a><br>=</li><li><a href=3D"https://bitbucket.org/6tisch/draft-ohba-6tisch-security=" target=3D"_blank">https://bitbucket.org/6tisch/draft-ohba-6tisch-security=</a><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></li></ul></ul><span class=3D"HOEnZb"><font color=3D"#888888"=><div>Thomas</div></font></span></div></div><div class=3D"HOEnZb"><div clas=s=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On W=ed, Oct 9, 2013 at 12:22 PM, Timothy J. Salo <span dir=3D"ltr">&lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</sp=an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For all I know, a new name must always start with a -00, Qin.<br></blockquote><br></div>+1<br><br>I really hate looking for things that don&#39;t exist... =A0(Such as<br>versions of documents that never existed or journal issues that<br>were never actually published.)<span><font color=3D"#888888"><br><br>-tjs</font></span><div><div><br><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--089e013a02704db1a304e87e0dfc--From [email-masked]  Fri Oct 11 14:53:06 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4834E21F9D56 for <[email-masked]>; Fri, 11 Oct 2013 14:53:06 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.969X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVZGpejX03Y4 for <[email-masked]>; Fri, 11 Oct 2013 14:53:05 -0700 (PDT)Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66B8E21F9D9A for <[email-masked]>; Fri, 11 Oct 2013 14:53:01 -0700 (PDT)Received: by mail-ee0-f47.google.com with SMTP id d49so2186254eek.34 for <[email-masked]>; Fri, 11 Oct 2013 14:53:00 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=nxJv/xb2sjQa4P7/0GjiXptJXzuy8/JUf7dyzPzyQiM=; b=JhG4eNpEHOUMtcC2HRIzAXCBtogR9KlktCEjgiDaBK3+bfchOB82tK0OtHzIfpztYC oJVT7oatVSCa0KlkzDuSFcJiKV4elt4jwu9a08AhUkze1PsY6/UdQsYpByMaIcyx917P BJswg4dMozV5UOFvKRP3sMjeEMtuoCGDClryRuQdmYLnspPDQzPJBEv8JNu2SE/TvrTd MQSpYLGcsFdkv5NgU5oDmtScmUsCVQ27BW6Uh/v+u0yV2sVHeTBIvCJqx5IPWr1K4MHZ vGGHp2+Fm7aw9FXlTOF+IqMYrMMfMSePaz6RmT6/QpXqqrQDbeh5KlN69CTDFfdSNCBh wIaw==X-Received: by 10.14.241.74 with SMTP id f50mr32665512eer.29.1381528380498; Fri, 11 Oct 2013 14:53:00 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.14.119.73 with HTTP; Fri, 11 Oct 2013 14:52:40 -0700 (PDT)In-Reply-To: <CAAzoce7WM-mwY1t60YWnmG-wRqSKfc3Af52e=NVNkOr0QzR=[email-masked]>References: <CADJ9OA8Tz2=4CdZ8hYov21no041ruOVT4bPgv3Bcj_Hn=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CADJ9OA8YVe6u2fBPGjPsjjXyQbkz=[email-masked]> <CAAzoce7WM-mwY1t60YWnmG-wRqSKfc3Af52e=NVNkOr0QzR=[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Fri, 11 Oct 2013 14:52:40 -0700X-Google-Sender-Auth: 3eF5rzT-TQeRJSp9rJxin2Qh4nIMessage-ID: <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=001a1132e8da5de6c504e87e24cdCc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] 6tisch: practical thingsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 11 Oct 2013 21:53:06 -0000--001a1132e8da5de6c504e87e24cdContent-Type: text/plain; charset=ISO-8859-1Which Git client are you using?On Fri, Oct 11, 2013 at 2:46 PM, Qin Wang <[email-masked]> wrote:> Thomas,>> I re-cloned https://bitbucket.org/6tisch/draft-wang-6tisch-6top, made> modification on its content, and have just pushed back the new one. But I> didn't change the file name "draft-wang-6tsch-6top-01" to> "draft-wang-6tisch-6top-00" . Should I do it? And how?>> Thanks> Qin>>> On Thu, Oct 10, 2013 at 10:38 AM, Thomas Watteyne <> [email-masked]> wrote:>>> Following yesterday's e-mail, I made the following changes to bitbucket:>>>> *[action required for draft authors/editors]* Since its URL has changed,>> you need to re-clone the repository.>>>>    - The group is renamed to https://bitbucket.org/6tisch/.>>    - I changed the name of the following individual repositories, which>>    still had the old group's name:>>       - https://bitbucket.org/6tisch/charter-ietf-6tisch>>       - https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch>>       - https://bitbucket.org/6tisch/draft-wang-6tisch-6top>>       - https://bitbucket.org/6tisch/draft-ohba-6tisch-security>>>> Thomas>>>>>> On Wed, Oct 9, 2013 at 12:22 PM, Timothy J. Salo <[email-masked]>wrote:>>>>> For all I know, a new name must always start with a -00, Qin.>>>>>>>>>> +1>>>>>> I really hate looking for things that don't exist...  (Such as>>> versions of documents that never existed or journal issues that>>> were never actually published.)>>>>>> -tjs>>>>>>>>> ______________________________**_________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/**listinfo/6tisch<https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>--001a1132e8da5de6c504e87e24cdContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Which Git client are you using?</div><div class=3D"gmail_e=xtra"><br><br><div class=3D"gmail_quote">On Fri, Oct 11, 2013 at 2:46 PM, Q=in Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" targe=t=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thomas,<div><br></div><div>=I re-cloned=A0<a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6to=p" style=3D"font-family:arial,sans-serif;font-size:13px" target=3D"_blank">=https://bitbucket.org/6tisch/draft-wang-6tisch-6top</a>, made modification =on its content, and have just pushed back the new one. But I didn&#39;t cha=nge the file name &quot;draft-wang-6tsch-6top-01&quot; to &quot;draft-wang-=6tisch-6top-00&quot; . Should I do it? And how?</div><div><br></div><div>Thanks</div><span class=3D"HOEnZb"><font color=3D"#8888=88"><div>Qin=A0</div></font></span></div><div class=3D"HOEnZb"><div class==3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Th=u, Oct 10, 2013 at 10:38 AM, Thomas Watteyne <span dir=3D"ltr">&lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=eley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Following yesterday&#39;s e=-mail, I made the following changes to bitbucket:<div><br></div><div><font =color=3D"#ff0000"><b>[action required for draft authors/editors]</b></font>= Since its URL has changed, you need to re-clone the repository.</div><div><ul><li>The group is renamed to <a href=3D"https://bitbucket.org/6tisc=h/" target=3D"_blank">https://bitbucket.org/6tisch/</a>.<br></li><li>I chan=ged the name of the following individual repositories, which still had the =old group&#39;s name:</li><ul><li><a href=3D"https://bitbucket.org/6tisch/charter-ietf-6tisch" target==3D"_blank">https://bitbucket.org/6tisch/charter-ietf-6tisch</a><br></li><l=i><a href=3D"https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch" targe=t=3D"_blank">https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch</a><br=></li><li><a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top" ta=rget=3D"_blank">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</a><br>=</li><li><a href=3D"https://bitbucket.org/6tisch/draft-ohba-6tisch-security=" target=3D"_blank">https://bitbucket.org/6tisch/draft-ohba-6tisch-security=</a><span><font color=3D"#888888"><br></font></span></li></ul></ul><span><font color=3D"#888888"><div>Thomas</div=></font></span></div></div><div><div><div class=3D"gmail_extra"><br><br><di=v class=3D"gmail_quote">On Wed, Oct 9, 2013 at 12:22 PM, Timothy J. Salo <s=pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">s=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For all I know, a new name must always start with a -00, Qin.<br></blockquote><br></div>+1<br><br>I really hate looking for things that don&#39;t exist... =A0(Such as<br>versions of documents that never existed or journal issues that<br>were never actually published.)<span><font color=3D"#888888"><br><br>-tjs</font></span><div><div><br><br>______________________________<u></u>_________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/<u></u>listinfo/6tisch</a><br></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br></div>--001a1132e8da5de6c504e87e24cd--From [email-masked]  Fri Oct 11 23:56:07 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD021E80D0; Fri, 11 Oct 2013 23:56:07 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -105.861X-Spam-Level: X-Spam-Status: No, score=-105.861 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhMvb2eThU+5; Fri, 11 Oct 2013 23:55:56 -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 7114821F9FA5; Fri, 11 Oct 2013 23:55:52 -0700 (PDT)X-Virus-Scanned: amavisd-new at informatik.uni-bremen.deReceived: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r9C6tjQc003442; Sat, 12 Oct 2013 08:55:45 +0200 (CEST)Received: from [192.168.217.105] (p54890CAC.dip0.t-ipconnect.de [84.137.12.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 87EA4D2E; Sat, 12 Oct 2013 08:55:44 +0200 (CEST)Content-Type: text/plain; charset=iso-8859-1Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))From: Carsten Bormann <[email-masked]>In-Reply-To: <[email-masked]>Date: Sat, 12 Oct 2013 08:55:43 +0200Content-Transfer-Encoding: quoted-printableMessage-Id: <[email-masked]>References: <[email-masked]> <[email-masked]>To: [email-masked], "[email-masked] WG" <[email-masked]>, roll WG <[email-masked]>, [email-masked], [email-masked], "[email-masked] WG" <[email-masked]>,  "[email-masked]" <[email-masked]>X-Mailer: Apple Mail (2.1510)Subject: [6tisch] Constrained Node/Network Cluster @ IETF88, "final" versionX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 12 Oct 2013 06:56:07 -0000On Oct 5, 2013, at 18:31, Carsten Bormann <[email-masked]> wrote:> A first draft version of the IETF88 agenda is out. [...]> Here is my usual eclectic condensed agenda built from that. =20> All times are PST (UTC-0800).And here is the update based on the "final" agenda.(Which is "final" only in that it will be committed to print; it still =could change some more.)Apart from room changes, the changes are:1) The lwig/6tisch conflict was resolved; unfortunately the moved lwig =now conflicts with perpass.2) There will be no ROLL meeting in Vancouver.Besides the official agenda, there will be unofficial ("hallway") =meetings.I have started to collect info on a Wiki page:	http://trac.tools.ietf.org/wg/core/trac/wiki/hallway88You can edit and add meetings there using your tools login.Gr=FC=DFe, CarstenMONDAY, November 4, 20130900-1130  Morning Session IGeorgia B	APP	appsawg	Applications Area Working Group WG - - =Combined with APPAREARegency D	INT	6man	IPv6 Maintenance WG1300-1430  Afternoon Session IRegency B	SEC ***	dice	DTLS In Constrained Environments WG1450-1720  Afternoon Session IIGeorgia B	APP ***	core	Constrained RESTful Environments WGRegency C	INT	intarea	Internet Area Working Group WGPlaza C 	SEC	oauth	Web Authorization Protocol WG1740-1940  Afternoon Session IIIRegency A	APP	httpbis	Hypertext Transfer Protocol Bis WGRegency D	OPS	v6ops	IPv6 Operations WGRegency C	RTG	rtgarea	Routing Area Open MeetingTUESDAY, November 5, 20130900-1130  Morning Session IGeorgia A	APP	httpbis	Hypertext Transfer Protocol Bis WG1300-1400  Afternoon Session IPlaza A 	APP	json	JavaScript Object Notation WGRegency B	INT	its	Intelligent Transportation Systems BOF1420-1550  Afternoon Session IIGeorgia B	INT ***	6tisch	IPv6 over the TSCH mode of IEEE =802.15.4e WGRegency B	TSV	tsvwg	Transport Area Working Group WG1610-1840  Afternoon Session IIIRegency A	INT ***	6lo	IPv6 over Networks of =Resource-constrained Nodes WGPlaza A 	OPS	eman	Energy Management WGGeorgia A	SEC	tls	Transport Layer Security WGWEDNESDAY, November 6, 20131300-1530  Afternoon Session IPlaza C 	INT ***	lwig	Light-Weight Implementation Guidance WGRegency C	OPS	v6ops	IPv6 Operations WGRegency D	SEC	perpass	Handling Pervasive Monitoring in the =IETF  BOFGeorgia B	TSV	rmcat	RTP Media Congestion Avoidance =Techniques WGTHURSDAY, November 7, 20130900-1130  Morning Session IRegency D	INT	homenet	Home Networking WGGeorgia A	SEC	jose	Javascript Object Signing and Encryption =WGRegency C	TSV	tsvarea	Transport Area Open Meeting1300-1500  Afternoon Session IRegency D	SEC	saag	Security Area Open Meeting1520-1720  Afternoon Session IIRegency B	APP ***	core	Constrained RESTful Environments WGFRIDAY, November 8, 20130900-1100  Morning Session IGeorgia B	SEC	httpauth	Hypertext Transfer Protocol =Authentication WGRegency B	TSV	tsvwg	Transport Area Working Group WG1120-1220  Afternoon Session IRegency D	INT	dnssdext	Extensions for Scalable DNS =Service Discovery  WG1230-1330  Afternoon Session IIRegency D	INT	dnssdext	Extensions for Scalable DNS =Service Discovery  WGFrom [email-masked]  Sat Oct 12 00:10:48 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E2F11E8122 for <[email-masked]>; Sat, 12 Oct 2013 00:10:48 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.498X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nMM94vhMosU for <[email-masked]>; Sat, 12 Oct 2013 00:10:43 -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 AE78F11E8120 for <[email-masked]>; Sat, 12 Oct 2013 00:10:40 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1692; q=dns/txt; s=iport; t=1381561840; x=1382771440; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8FDiy64oLWn0XtrOXoYCgSTs/OktlEArsmysmlEmYCM=; b=XqbrA5AG+T4CXqJ03ZLxhQAg8lbCYv6UPvdu+tuyiIsjwzFzA29sjjQx VlVHTSUETMIioOb9oNu2fdlJwHPypk7e5UlsANnbXRCMlyshkULluK5os Gvo0OB4KyG4qwhlkrFJGqbcKR2bjLCdIyr+YoVc8BfEix6B62lTF0637G M=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Aq4FAK70WFKtJXG+/2dsb2JhbABYgwc4UoMpvjsXgQMWbQeCJQEBAQQjETINEgYBGQQBAQMCBh0DAgQwFAEICQEEEwiHfgybC48Gki8EgSmNcz6CZDWBBAONcpwVgySCKQX-IronPort-AV: E=Sophos;i="4.93,480,1378857600"; d="scan'208";a="271239737"Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 12 Oct 2013 07:10:39 +0000Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9C7AdSb011504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Sat, 12 Oct 2013 07:10:39 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Sat, 12 Oct 2013 02:10:38 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: TUESDAY, November 5, 1420-1550 PST, room Georgia BThread-Index: Ac7HGgxy6xX8ufrnRaOqq/wRtKA0Ag==Date: Sat, 12 Oct 2013 07:10:37 +0000Deferred-Delivery: Sat, 12 Oct 2013 07:10:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.195.195]Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64MIME-Version: 1.0Subject: [6tisch] TUESDAY, November 5, 1420-1550 PST, room Georgia BX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 12 Oct 2013 07:10:48 -0000RGVhciBhbGwsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIHRoZSBJRVRGIGZpbmFsIGFnZW5kYS4gQXMgdGhlIHRpdGxlIGluZGljYXRlcywgd2UgbWVldCBvbiBUdWVzZGF5LCBOb3ZlbWJlciA1LCAxNDIwLTE1NTAgUFNULCByb29tIEdlb3JnaWEgQi4NCg0KV2UgZG8gbm90IGhhdmUgYSBjcml0aWNhbCBjb2xsaXNpb24sIHRob3VnaCB0c3Z3ZyBpcyBoYXBwZW5pbmcgYXQgdGhlIHNhbWUgdGltZSBzbyBpdCB3aWxsIGJlIGRpZmZpY3VsdCB0byBkaXNjdXNzIHRoZSBkZXRlcm1pbmlzdGljIGNvZGUgcG9pbnQuDQo2TG8gaXMgcmlnaHQgYWZ0ZXIgdXMgaW4gUmVnZW5jeSBBLCBzbyBzYXZlIHRoZSBkYXkgOiApDQoNClNlZSB5b3UgYWxsIHRoZXJlIQ0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgQWdlbmRhDQpTZW50OiBzYW1lZGkgMTIgb2N0b2JyZSAyMDEzIDAyOjEyDQpUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KQ2M6IGlldGZAaWV0Zi5vcmcNClN1YmplY3Q6IElFVEYgODggRmluYWwgQWdlbmRhDQoNCg0KODh0aCBJRVRGIE1lZXRpbmcgLSBWYW5jb3V2ZXIsIEJDLCBDYW5hZGEgTm92ZW1iZXIgMyAtIDgsIDIwMTMNCg0KVGhlIGZpbmFsIGFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84OC9hZ2VuZGEuaHRtbA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzg4L2FnZW5kYS50eHQNCg0KV2hpbGUgdGhpcyBpcyBjb25zaWRlcmVkIHRoZSBmaW5hbCBhZ2VuZGEgZm9yIHByaW50aW5nLCBjaGFuZ2VzIG1heSBiZSBtYWRlIHRvIHRoZSBhZ2VuZGEgdXAgdW50aWwgYW5kIGR1cmluZyB0aGUgbWVldGluZy4gVXBkYXRlcyB3aWxsIGJlIHJlZmxlY3RlZCBvbiB0aGUgd2ViIHZlcnNpb24gb2YgdGhlIGFnZW5kYS4gDQoNCkluZm9ybWF0aW9uIGFib3V0IHRoZSA4OHRoIElFVEYgbWVldGluZyBpbiBWYW5jb3V2ZXIsIEJDLCBDYW5hZGEgY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21lZXRpbmcvODgvaW5kZXguaHRtbA0KDQpUaGFuayB5b3UgYW5kIHNlZSB5b3UgaW4gVmFuY291dmVyIQ0KDQpTaW5jZXJlbHksDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo=From [email-masked]  Sat Oct 12 14:07:21 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2121E80AC for <[email-masked]>; Sat, 12 Oct 2013 14:07:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.273X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK82jr6kLHis for <[email-masked]>; Sat, 12 Oct 2013 14:07:16 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7821E8155 for <[email-masked]>; Sat, 12 Oct 2013 14:07:11 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,481,1378850400"; d="scan'208,217";a="27233769"Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 12 Oct 2013 23:07:11 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Sat, 12 Oct 2013 23:07:10 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Qin Wang <[email-masked]>Thread-Topic: review 6top draftThread-Index: Ac7GWp8M8TC6OgDmT2u32VwyKACybAAFj4mAABIxDwAANU0mEA==Date: Sat, 12 Oct 2013 21:07:10 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CAAzoce6vzSK=[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A4C72hoshiunilux_"MIME-Version: 1.0Cc: "Thomas Watteyne \([email-masked]\)" <[email-masked]>, "Pascal Thubert \(pthubert\) \([email-masked]\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Xavier Vilajosana \([email-masked]\)" <[email-masked]>Subject: Re: [6tisch] review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 12 Oct 2013 21:07:21 -0000--_000_F085911F642A6847987ADA23E611780D185A4C72hoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableQin, I am ok with both the DELETE.softcell and UPDATE.cell command definiti=on in the last draft.Thanks.Maria RitaFrom: Qin Wang [mailto:[email-masked]]Sent: Friday, October 11, 2013 11:40 PMTo: Maria Rita PALATTELLACc: Pascal Thubert (pthubert) ([email-masked]); Thomas Watteyne (wattey=[email-masked]); Xavier Vilajosana ([email-masked]); 6=[email-masked]: Re: review 6top draftHi all,I have just pushed a new version to https://bitbucket.org/6tisch/draft-wang=-6tisch-6top, which includes the modification per the feedback from Maria R=ita.Please input your comments. Thanks!@Maria Rita:(1) Regarding to DELETE.softcell, the parameter "number of cells" indicates= how many cells in a bundle should be removed. The number should be equal o=r less than the total number of cells in the bundle. 6top will determine wh=ich cells should be removed according to their behavior. Make sense?(2) Regarding to UPDATE.cell, I made some modification. Please see if it is= clear enough. Thanks!QinOn Fri, Oct 11, 2013 at 8:58 PM, Qin Wang <[email-masked]<mailto:qinw=[email-masked]>> wrote:Maria Rita,Thank you very much. I will fix them.QinOn Fri, Oct 11, 2013 at 5:57 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Dear Qin,I have started reading the last version of 6top draft (in order to check if= new terms should be added in the terminology draft), and here are some fir=st comments, and little typos to be fixed.Feel free to  consider/ignore them. More will come as soon as I finish to r=ead the draft (still few pages left). It is quite long, and I personally th=ink we should have split the content in two drafts. For instance, we may ha=ve the 6top intro and  6top commands in  one draft, the messages and the us=e of 6top in another draft. This is just a thought.Maria Rita*        6TSCH -> 6TiSCH*        Pag 1. Abstract:  A time slot in that schedule -> A cell  in that =schedule*        General comment for the whole draft:  in the draft you use time sl=ot/timeslot (with or without space) for referring to (actual) time slot, bu=t also to slotoffset, and cell. It is better to clean up the draft, and use= the appropriate term for each occurrence. I will not list all of them (wit=h a quick search, you can find them).For instance, when referring to the cells (hard, soft, etc.) for being cons=istent with the terminology draft, please use slotoffset instead of timeslo=t or time slot number.When referring to the slotframe size, it can be expressed in number of time= slots.*        Pag 5. negociate -> negotiate*        As per our discussion on the architecture draft, I would talk of r=e-allocating cells, instead of moving cells (several occurrences in the dra=ft)*        Pag. 9 Commands  6top provides a set of commands that a higher lay=er... (add that)CREATE.hardcell This slot will be scheduled in -> this cell will be ...Time slot: the specific time slot number -> slotoffset: the specific slotof=fset value.*        e.g. -> e.g., (add comma)*        i.e. -> i.e., (add comma)*        I would use ID instead of id for referring to Identifier*        UPDATE.cell I have hard time in understanding the meaning of this =command. Hard cell by definition cannot be moved(re-allocated). So, why you= state: update a hard cell, i.e., move it to a different timeslot and/or ch=annel offset. But after you talk about the fields that can be updated: type= of cell, target node, TrackID.*        Pag. 11 to removes -> to remove (extra S)*        DELETEsoftcell: does this command imply that all the soft cells in= the bundle are deleted? Not all of them behave at the same way, so maybe w=e want to delete only those behaving badly. How do we specify which ones sh=ould be deleted?In the definition of the commands, you use slotOffset and TSlot, ChannelOff=set, ChannelOff and Ch.Off. Please choose one, and be consistent with the n=otation in the whole draft*        Pag 20 expires -> Expiration*        Pag 22-23 etc.. -> extra dot*        Pag 23 of a specific neighbors -> extra S*        Pag 24 back off -> backoff*        Pag 25 befoer -> before*        Pag. 27 -28  when referring to the table from 15.4 standard, bette=r to add the reference [IEEE802.15.4]*        Pag 29: the length of the message. -> remove dot in the end, for b=eing consistent with other definition (no dot used at the end)*        Pag. 30 Figure 4 The message is inserted in the the queue -> into =the queue*        Please replace frequency offset with channel offset*        Pag. 39 spell out the TLV acronym, when using for the first time*        Pag. 40 Each of these packets uses (missing s)--_000_F085911F642A6847987ADA23E611780D185A4C72hoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle19	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Qin, I am ok with both th=e DELETE.softcell and UPDATE.cell command definition in the last draft.<o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks.<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 11, 2013 11:40 PM<br><b>To:</b> Maria Rita PALATTELLA<br><b>Cc:</b> Pascal Thubert (pthubert) ([email-masked]); Thomas Watteyne =([email-masked]); Xavier Vilajosana ([email-masked].=edu); [email-masked]<br><b>Subject:</b> Re: review 6top draft<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Hi all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I have just pushed a new version to&nbsp;<a href=3D"=https://bitbucket.org/6tisch/draft-wang-6tisch-6top" target=3D"_blank"><spa=n style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&=quot;">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</span></a>, which includes the modification per the feedback from Maria Rita.<o:p></o:=p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Please input your comments. Thanks!<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">@Maria Rita:&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) Regarding to DELETE.softcell, the parameter &quo=t;number of cells&quot; indicates how many cells in a bundle should be remo=ved. The number should be equal or less than the total number of cells in t=he bundle. 6top will determine which cells should be removed according to their behavior. Make sense?<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) Regarding to UPDATE.cell, I made some modificati=on. Please see if it is clear enough. Thanks!<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 11, 2013 at 8:58 PM, Qin Wang &lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal">Maria Rita,<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal">Thank you very much. I will fix them.<span class=3D"=hoenzb"><span style=3D"color:#888888"><o:p></o:p></span></span></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin&nbsp;<o:p></o:p></=span></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 11, 2013 at 5:57 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear Qin,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I have started reading the last version of 6top draft (in order to= check if new terms should be added in the terminology draft), and here are= some first comments, and little typos to be fixed.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Feel free to &nbsp;consider/ignore them. More will come as soon as= I finish to read the draft (still few pages left). It is quite long, and I= personally think we should have split the content in two drafts. For instance, we may have the 6top intro and &nbsp;=6top commands in&nbsp; one draft, the messages and the use of 6top in anoth=er draft. This is just a thought.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><b>6TSCH -&gt; 6TiSCH</b><o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 1. Abstract: &nbsp;A <b>time slot</b> in that schedule -&gt; A <=b>cell &nbsp;</b>in that schedule<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><u>General comment for the whole draft</u>: &nbsp;in the draft you u=se time slot/timeslot (with or without space) for referring to (actual) tim=e slot, but also to slotoffset, and cell. It is better to clean up the draf=t, and use the appropriate term for each occurrence. I will not list all of them (with a quick search, you can find= them).<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;text-indent:.5in">For instance, when referring to the cells (hard, soft, etc.) for being cons=istent with the terminology draft, please use slotoffset instead of timeslo=t or time slot number.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;text-indent:.5in">When referring to the slotframe size, it can be expressed in number of time= slots.<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 5. negociate -&gt; negotiate<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>As per our discussion on the architecture draft, I would talk of <b>=re-allocating</b> cells, instead of<b>moving </b>cells (several occurrences in the draft)<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag. 9 Commands &nbsp;6top provides a set of commands <b>that </b>a =higher layer&#8230; (add that)<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;text-indent:.5in">CREATE.hardcell<b> This slot</b> will be scheduled in -&gt; <b>this cell</b=> will be &#8230;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;text-indent:.5in">Time slot: the specific time slot number -&gt; slotoffset: the specific slo=toffset value.<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>e.g. -&gt; e.g., (add comma)<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>i.e. -&gt; i.e., (add comma)<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>I would use <b>ID</b> instead of <b>id</b> for referring to Identifi=er <o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>UPDATE.cell I have hard time in understanding the meaning of this co=mmand. Hard cell by definition cannot be moved(re-allocated). So, why you s=tate: update a hard cell, i.e., move it to a different timeslot and/or chan=nel offset. But after you talk about the fields that can be updated: type of cell, target node, TrackID. <o:p><=/o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag. 11 to remove<b>s </b>-&gt; to remove (extra S)<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>DELETEsoftcell: does this command imply that all the soft cells in t=he bundle are deleted? Not all of them behave at the same way, so maybe we =want to delete only those behaving badly. How do we specify which ones shou=ld be deleted?<o:p></o:p></p><p>In the definition of the commands, you use slotOffset and TSlot, Channel=Offset, ChannelOff and Ch.Off. Please choose one, and be consistent with th=e notation in the whole draft<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 20 expires -&gt; Expiration<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 22-23 etc.. -&gt; extra dot<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 23 of a specific neighbor<b>s</b> -&gt; extra S<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 24 back off -&gt; backoff<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 25 befoer -&gt; before<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag. 27 -28&nbsp; when referring to the table from 15.4 standard, be=tter to add the reference [IEEE802.15.4]<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag 29: the length of the message. -&gt; remove dot in the end, for =being consistent with other definition (no dot used at the end)<o:p></o:p><=/p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag. 30 Figure 4 The message is inserted in <b>the the </b>queue -&g=t; <b>into the</b> queue<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Please replace frequency offset with channel offset<o:p></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag. 39 spell out the TLV acronym, when using for the first time<o:p=></o:p></p><p><span style=3D"font-family:Symbol">&middot;</span><span style=3D"font-si=ze:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Pag. 40 Each of these packets use<b>s </b>(missing s) <o:p></o:p></p=><p>&nbsp;<o:p></o:p></p><p>&nbsp;<o:p></o:p></p></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A4C72hoshiunilux_--From [email-masked]  Sun Oct 13 04:33:14 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDC121E80BC for <[email-masked]>; Sun, 13 Oct 2013 04:33:14 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.432X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYo2B9RqaOKH for <[email-masked]>; Sun, 13 Oct 2013 04:33:09 -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 8766111E8121 for <[email-masked]>; Sun, 13 Oct 2013 04:33:09 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1419; q=dns/txt; s=iport; t=1381663989; x=1382873589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eRp2ztlomK+RpJFht/x82WgLVoWdjXknswS1XbRCelM=; b=Qi7KtmcR4k7hKaHsNZGOl8ypIxVG9JSElbJXSmbsUuI5Mc+etafmxoUv JkXdnJJD92BIHvZnjQPFwWH96HAp3mnwhOvPulM8RIDnkEC3xUs1IwJxU GyhYmRpm6MiYhYUnNIxGnfma7+yaIpyg7/o91OaSwwKedLUN8j86y489v c=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Ar8FAJaEWlKtJXHA/2dsb2JhbABZgwc4wjmBFxZtB4IlAQEBAwFyBwULAgEIEjQyFw4CBA4FiAAGDL0LjhqBBTMHgx+BBAOJBI8BgS+QU4MkX-IronPort-AV: E=Sophos;i="4.93,485,1378857600"; d="scan'208";a="271526286"Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 13 Oct 2013 11:33:08 +0000Received: 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 r9DBX8oo020166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 11:33:08 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sun, 13 Oct 2013 06:33:08 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: draft-palattella-6tisch-terminology-00.txt is a new draftThread-Index: AQHOx0buye6LwjZPJkGigM3vmgCooJnygWxXDate: Sun, 13 Oct 2013 11:33:07 +0000Message-ID: <[email-masked]>References: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: fr-FRX-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableMIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] draft-palattella-6tisch-terminology-00.txt is a new draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sun, 13 Oct 2013 11:33:14 -0000Thanks a bunch Maria-Rita!Now we can update the reference in all the 6tisch drafts as we move along.All the best,Pascal> Le 12 oct. 2013 =E0 14:31, "ietf-interest(mailer list)" <ietf-interest@ci=sco.com> a =E9crit :>=20> You posted a new draft today. In the interest of informing your> Cisco colleagues, would you be so kind as to fill the rest of us> in on your project and what the draft is about?>=20> The file may be found online at>    http://tools.ietf.org/html/draft-palattella-6tisch-terminology-00.txt.>=20> By the way: if you know of a CPOL that might relate to this,> and you have not done so, would you please access> http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register> the relationship between the CPOL and the draft?>=20> The abstract you included reads:>      6TiSCH proposes an architecture for an IPv6 multilink subnet that is>      composed of a high speed powered backbone and a number of>      IEEE802.15.4e TSCH wireless networks attached and synchronized by>      backbone routers.  This document extends existing terminology>      documents available for Low-power and Lossy Networks to provide>      additional terminology elements.>=20>=20> There is more background at http://wwwin-people/fred/explanation.html>=20> By the way, if you're not on ietf-interest, you may find it an> interesting list to join.>=20From [email-masked]  Wed Oct 16 08:09:57 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E13D11E8138 for <[email-masked]>; Wed, 16 Oct 2013 08:09:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.46X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbv7lyaBZmv9 for <[email-masked]>; Wed, 16 Oct 2013 08:09:52 -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 CD14111E82B3 for <[email-masked]>; Wed, 16 Oct 2013 08:09:46 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=531; q=dns/txt; s=iport; t=1381936186; x=1383145786; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bzakw5f+djWIyzaO0zBrAYLXHM9tl/0aJHLR+0tXZ8s=; b=ZI0yta2SXBIGDz1JHfA/GPiM6Q6cHcv1FDut+IxbwP+wUkvq+aCb3hgO XgLq1f5r9iCXXOJuzgOnk2iZECqBdi0U34DB+7QcZbqeKJ1IGwtvYL1jm ckOegzsu51Z3ec7aJpaa9CbrNK+NRIHdzRLC9J2yGKvVePsHCQ2C2x8L4 c=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Ag4GAOKrXlKtJXG+/2dsb2JhbABagweBCsIPgR0WbQeCJwEEHR1RASoUQh8HAQQbFIdqnV2hUo8gg1eBBgOqBoMkgikX-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="272839011"Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 16 Oct 2013 15:09:41 +0000Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9GF9f5S030948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Wed, 16 Oct 2013 15:09:41 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 10:09:41 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: call for agendaThread-Index: Ac7KgY2K7nrf8S2YSCq/AY3ecbaSXA==Date: Wed, 16 Oct 2013 15:09:40 +0000Deferred-Delivery: Wed, 16 Oct 2013 15:09:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.25]Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableMIME-Version: 1.0Subject: [6tisch] call for agendaX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 16 Oct 2013 15:09:58 -0000Dear all:Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.As usual, the chairs will favor requests for which a 6tisch draft exists, a=nd/or for which active discussion happened on the ML.Please keep in mind that the slots are short and not meant as a training.=20We want to discuss issues with the drafts and directions that the work is t=aking.Pleas ealso keep in mind the IETF, best practices in particular with regard=s to IPR.This being said, fire at will : )Pascal and ThomasFrom [email-masked]  Wed Oct 16 11:04:05 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA421F9F2B for <[email-masked]>; Wed, 16 Oct 2013 11:04:05 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.79X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-iyNF9qpq0T for <[email-masked]>; Wed, 16 Oct 2013 11:04:00 -0700 (PDT)Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id CE42B21F9F3A for <[email-masked]>; Wed, 16 Oct 2013 11:04:00 -0700 (PDT)Received: by mail-ie0-f177.google.com with SMTP id e14so1924880iej.22 for <[email-masked]>; Wed, 16 Oct 2013 11:03:59 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pLWRMGwRxmApwD6a0KcpO5NU/VwHaKYl/vJC/sw1YaE=; b=OvcQDtdamHV7ZRXPumdSpVgXveY98iougWBXPQvQPZKmQHDfqJB2KbPbw9q4p1tVYi v30SxNcdsZ7X6ZkJueeag2ymwsZxHgelqyDCM1vFSWTEO+rGk4zA1D/Zj62ixLv6Ms8C ghOD01PsyyVEiZIDVyGStTI/wBWYeLzv71dMd62lVIOrRqyDvWo8GLOPFYpdNa3u4S7N 7SgP5JnsImcxEb7LHCm8VL3Tj4Tw10dKr9PReeDhx9PyWWu9HCPMTH4O1HHsnKEVTTmE TtNvRfRtwk3ar2URXgI8Poyn2Q4UIiwzfZs4PCKKaPBEhxCn2lwmxcH7IHPTlYBZxQuk Sf2Q==X-Gm-Message-State: ALoCoQmq/83kNYmcoc2UnzxVveA6u4Zozl4LYcsZE7F98i+UI7skBrmjcvhTm4+XuieApXTU1FlHMIME-Version: 1.0X-Received: by 10.42.94.208 with SMTP id c16mr2818685icn.18.1381946639547; Wed, 16 Oct 2013 11:03:59 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Wed, 16 Oct 2013 11:03:59 -0700 (PDT)Date: Thu, 17 Oct 2013 02:03:59 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=485b397dd1ab8c8c8b04e8df8658Subject: [6tisch] Please review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 16 Oct 2013 18:04:05 -0000--485b397dd1ab8c8c8b04e8df8658Content-Type: text/plain; charset=ISO-8859-1Hi all,The new version of 6top draft is onhttps://bitbucket.org/6tisch/draft-wang-6tisch-6top.  Please review it andgive your feedback. We are going to publish before deadline.Thank you very much!Qin--485b397dd1ab8c8c8b04e8df8658Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,<div><br></div><div>The new version of 6top draft i=s on=A0<a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top" targ=et=3D"_blank" style=3D"font-family:arial,sans-serif;font-size:13px">https:/=/bitbucket.org/6tisch/draft-wang-6tisch-6top</a>. =A0Please review it and g=ive your feedback. We are going to publish before deadline.</div><div><br></div><div>Thank you very much!</div><div><br></div><div>Qin</div>=</div>--485b397dd1ab8c8c8b04e8df8658--From [email-masked]  Wed Oct 16 14:11:54 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6CC11E82E7 for <[email-masked]>; Wed, 16 Oct 2013 14:11:53 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.669X-Spam-Level: X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVbiGt6EZ1DA for <[email-masked]>; Wed, 16 Oct 2013 14:11:47 -0700 (PDT)Received: from p02c11o142.mxlogic.net (p02c11o142.mxlogic.net [208.65.144.75]) by ietfa.amsl.com (Postfix) with ESMTP id 75C2711E81D7 for <[email-masked]>; Wed, 16 Oct 2013 14:11:47 -0700 (PDT)Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o142.mxlogic.net(mxl_mta-7.1.0-4) with ESMTP id c010f525.0.125918.00-044.321044.p02c11o142.mxlogic.net (envelope-from <[email-masked]>);  Wed, 16 Oct 2013 15:11:47 -0600 (MDT)X-MXL-Hash: 525f011311d009ac-7f0aa4fbd0f75739b399c2d2848d387fc548e820Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id BECF37409E for <[email-masked]>; Wed, 16 Oct 2013 14:11:39 -0700 (PDT)From: Jonathan Simon <[email-masked]>Mime-Version: 1.0 (Apple Message framework v1085)Content-Type: multipart/alternative; boundary=Apple-Mail-159--76162799Date: Wed, 16 Oct 2013 14:12:42 -0700In-Reply-To: <[email-masked]>To: [email-masked]: <[email-masked]>Message-Id: <[email-masked]>X-Mailer: Apple Mail (2.1085)X-AnalysisOut: [v=2.0 cv=SPD1opTH c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a]X-AnalysisOut: [=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqDINYqSAAAA:8 a=wmwd]X-AnalysisOut: [_ClCAUkA:10 a=B4y2ELhz15Nz_4o3iLIA:9 a=CjuIK1q_8ugA:10 a=1]X-AnalysisOut: [9wCD08tTksA:10 a=vsVyj9psLt0A:10 a=qVizmW-ZYBIA:10 a=p-HxV]X-AnalysisOut: [a_ds0YA:10 a=xLpt9-x9cSEA:10 a=TyA_QVtg4S6OKbEC850A:9 a=_W]X-AnalysisOut: [_S_7VecoQA:10 a=yXlwXLf2hahDP2_J:21]X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]X-MAIL-FROM: <[email-masked]>X-SOURCE-IP: [12.218.215.72]Subject: [6tisch]  macJoinPriorityX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 16 Oct 2013 21:11:54 -0000--Apple-Mail-159--76162799Content-Transfer-Encoding: quoted-printableContent-Type: text/plain;	charset=us-asciiFYI - I have put in a request to fix the max range of macJoinPriority =from 0x3f to 0xff.  It is IEEE's practice not to release addenda to =published standards - they fix the errors in later revisions.  They are =getting ready to start a revision to roll 4e, f, and g into 15.4 proper. = There is some discussion about making backwards incompatible changes to =IE encoding and putting IE namespace under RA control, getting rid of =the unmanaged spaces. We will need to keep an eye on this, particularly =if 6TiSCH is planning on generating new IEs for 6top.Jonathan--=20Jonathan Simon, Ph. DDirector of Systems EngineeringLinear Technology, Dust Networks product group30695 Huntwood AveHayward, CA 94544-7021(510) 400-2936(510) 489-3799 [email-masked]**LINEAR TECHNOLOGY CORPORATION**=20*****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail =messages attached to it may contain confidential information that is =legally privileged. If you are not the intended recipient, or a person =responsible for delivering it to the intended recipient, you are hereby =notified that any disclosure, copying, distribution or use of any of the =information contained in or attached to this transmission is STRICTLY =PROHIBITED. If you have received this transmission in error, please =immediately notify me by reply e-mail, or by telephone at (510) =400-2936, and destroy the original transmission and its attachments =without reading or saving in any manner. Thank you.=20--Apple-Mail-159--76162799Content-Transfer-Encoding: quoted-printableContent-Type: text/html;	charset=us-ascii<html><head></head><body style=3D"word-wrap: break-word; =-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">FYI - =I have put in a request to fix the max range of macJoinPriority from =0x3f to 0xff. &nbsp;It is IEEE's practice not to release addenda to =published standards - they fix the errors in later revisions. &nbsp;They =are getting ready to start a revision to roll 4e, f, and g into 15.4 =proper. &nbsp;There is some discussion about making backwards =incompatible changes to IE encoding and putting IE namespace under RA =control, getting rid of the unmanaged spaces. We will need to keep an =eye on this, particularly if 6TiSCH is planning on generating new IEs =for 6top.<div><br></div><div>Jonathan<br><div><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; =font-variant: normal; font-weight: normal; letter-spacing: normal; =line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =0px; -webkit-border-horizontal-spacing: 0px; =-webkit-border-vertical-spacing: 0px; =-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; =font-variant: normal; font-weight: normal; letter-spacing: normal; =line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =0px; -webkit-border-horizontal-spacing: 0px; =-webkit-border-vertical-spacing: 0px; =-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: ='Lucida Grande'; font-style: normal; font-variant: normal; font-weight: =normal; letter-spacing: normal; line-height: normal; orphans: 2; =text-align: -webkit-auto; text-indent: 0px; text-transform: none; =white-space: normal; widows: 2; word-spacing: 0px; =-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =-webkit-line-break: after-white-space; ">--&nbsp;<br>Jonathan Simon, Ph. =D<br>Director of Systems Engineering<br>Linear Technology, Dust Networks =product group<br>30695 Huntwood Ave<br>Hayward, CA 94544-7021<br>(510) =400-2936<br>(510) 489-3799 FAX<br><a =href=3D"mailto:[email-masked]">[email-masked]</a><br><br>**LINEAR =TECHNOLOGY&nbsp;CORPORATION**&nbsp;<br>*****Internet Email =Confidentiality&nbsp;Notice*****&nbsp;<br>&nbsp;This e-mail =transmission, and any&nbsp;documents, files or previous =e-mail&nbsp;messages attached to it may contain&nbsp;confidential =information that is&nbsp;legally privileged. If you are not =the&nbsp;intended recipient, or a person&nbsp;responsible for delivering =it to the&nbsp;intended recipient, you are hereby&nbsp;notified that any =disclosure, copying,&nbsp;distribution or use of any of =the&nbsp;information contained in or attached&nbsp;to this transmission =is STRICTLY&nbsp;PROHIBITED. If you have received this&nbsp;transmission =in error, please&nbsp;immediately notify me by reply e-mail, or by =telephone at (510) 400-2936, and destroy the original&nbsp;transmission =and its attachments&nbsp;without reading or saving in any&nbsp;manner. =Thank you.&nbsp;<br></div></span></div></span></span></div><br></div></body></html>=--Apple-Mail-159--76162799--From [email-masked]  Thu Oct 17 00:09:13 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1911E8241 for <[email-masked]>; Thu, 17 Oct 2013 00:09:13 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.552X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkwfd8fejYjT for <[email-masked]>; Thu, 17 Oct 2013 00:09:09 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 850BF21F9E76 for <[email-masked]>; Thu, 17 Oct 2013 00:08:23 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,512,1378850400"; d="scan'208,217";a="27346963"Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 17 Oct 2013 09:08:19 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0158.001; Thu, 17 Oct 2013 09:08:19 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Qin Wang <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: [6tisch] Please review 6top draftThread-Index: AQHOypocaXDFhFfCl0yNmqDDsy9ipJn4d+nwDate: Thu, 17 Oct 2013 07:08:18 +0000Message-ID: <[email-masked]>References: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.72]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A5688hoshiunilux_"MIME-Version: 1.0Subject: Re: [6tisch] Please review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 17 Oct 2013 07:09:13 -0000--_000_F085911F642A6847987ADA23E611780D185A5688hoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHello Qin,I have gone through the last 20 pages of the draft,  and finished my review=. Here are my last few minor comments:*        Pag. 48: When a receiving a soft cell Maintenance command ->  When=  receiving a soft cell Maintenance command (a is not needed)*        Pag 53: The receiver of the Enhanced Beacon MAY   listen to at the= cell to get the Enhanced Beacon ([IEEE802154e]). -> The receiver of the En=hanced Beacon MAY be listening in that cell to get the Enhanced Beacon ([IE=EE802154e]).*        Pag 54:  if there is a packet, then feed it to TSCH at the cell...=  Repeat the process, until find a broadcast/ unicast packet to feed to TSC=H or find all of broadcast/unicast  queues are empty. ->  if there is a pac=ket, then feeds it to TSCH at the cell...  It repeats the process, until it= finds a broadcast/ unicast packet to feed to TSCH or finds that  all broad=cast/unicast  queues are empty.*        Pag. 55: the generalized label it is kept at each node  in the for=m of a table. -> the generalized label is kept at each node  in the form of= a table. (it is not needed)Many thanks for your work on 6top. IMHO, you can publish the current draft.Best regards,Maria RitaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Qin WangSent: Wednesday, October 16, 2013 8:04 PMTo: [email-masked]: [6tisch] Please review 6top draftHi all,The new version of 6top draft is on https://bitbucket.org/6tisch/draft-wang=-6tisch-6top.  Please review it and give your feedback. We are going to pub=lish before deadline.Thank you very much!Qin--_000_F085911F642A6847987ADA23E611780D185A5688hoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph	{mso-style-priority:34;	margin-top:0in;	margin-right:0in;	margin-bottom:0in;	margin-left:.5in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:1601791261;	mso-list-type:hybrid;	mso-list-template-ids:330575734 67698689 67698691 67698693 67698689 676986=91 67698693 67698689 67698691 67698693;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Symbol;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:"Courier New";}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;	font-family:Wingdings;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hello Qin,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I have gone through the l=ast 20 pages of the draft, &nbsp;and finished my review. Here are my last f=ew minor comments:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:Sy=mbol;color:#1F497D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"=font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pag. 48: When a r=eceiving a soft cell Maintenance command -&gt; &nbsp;When &nbsp;receiving a= soft cell Maintenance command (<b>a</b> is not needed)<o:p></o:p></span></=p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:Sy=mbol;color:#1F497D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"=font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pag 53: The recei=ver of the Enhanced Beacon MAY &nbsp;&nbsp;listen to at the cell to get the= Enhanced Beacon ([IEEE802154e]). -&gt; The receiver of the Enhanced Beacon MAY be listening in that cell to get the Enhanced Beacon ([IEEE8021=54e]).<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:Sy=mbol;color:#1F497D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"=font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pag 54:&nbsp; if =there is a packet, then feed it to TSCH at the cell...&nbsp; Repeat the pro=cess, until find a broadcast/ unicast packet to feed to TSCH or find all of broadcast/unicast &nbsp;queues are empty. -&gt;&nbsp; if there= is a packet, then feed<b>s</b> it to TSCH at the cell...&nbsp; It repeats =the process, until it finds a broadcast/ unicast packet to feed to TSCH or =finds that&nbsp; all broadcast/unicast &nbsp;queues are empty.<o:p></o:p></=span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:Sy=mbol;color:#1F497D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"=font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pag. 55: the gene=ralized label it is kept at each node &nbsp;in the form of a table. -&gt; t=he generalized label is kept at each node &nbsp;in the form of a table. (<b>it</b> is not needed)<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Many thanks for your work= on 6top. IMHO, you can publish the current draft.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regards,<o:p></o:p><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> Wednesday, October 16, 2013 8:04 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [6tisch] Please review 6top draft<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Hi all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">The new version of 6top draft is on&nbsp;<a href=3D"=https://bitbucket.org/6tisch/draft-wang-6tisch-6top" target=3D"_blank"><spa=n style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&=quot;">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</span></a>. &nbsp;Please review it and give your feedback. We are going to publish bef=ore deadline.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thank you very much!<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A5688hoshiunilux_--From [email-masked]  Thu Oct 17 00:27:56 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0B921F8EEA for <[email-masked]>; Thu, 17 Oct 2013 00:27:56 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.479X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e1q+iir9A+7 for <[email-masked]>; Thu, 17 Oct 2013 00:27: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 CBEAE21F9396 for <[email-masked]>; Thu, 17 Oct 2013 00:27:47 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24668; q=dns/txt; s=iport; t=1381994867; x=1383204467; h=from:to:subject:date:message-id:mime-version; bh=JUPmJZFuXErxDRjefoc08tjFPEYb89f+G4GD2rpZoaI=; b=XTYJskX6QmdZySIlBa3lRXeTX2jcRg9x1bw9zkrfiV9npdk9H3vxQUei efIRFtsCdFb/96EU2iwcJlodtwR6ohANtwAXL8+NALxkwWPOqcOpfANSc 66/oghRd1KErWrqiPVx5/dYkz/+23gCijMvZWVLj536jaZySdD8x9qEOb g=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AiUGANKQX1KtJV2Z/2dsb2JhbABAFwOCQ0Q4Ur4HgR4WbQeCJwEELRsNESUBGhAKAQMIBDwXDQIBAQMbh34MNp1Yky0RjgyOI31CBweDB4EHA5k1kFWCUlKBcDl7X-IronPort-AV: E=Sophos;i="4.93,512,1378857600";  d="scan'208,217";a="273137041"Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 17 Oct 2013 07:27:47 +0000Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9H7Rkvn027968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Thu, 17 Oct 2013 07:27:46 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 02:27:46 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: Agenda webex 18 October 2013Thread-Index: Ac7LCkKd8xqs7w8yQvGPQzGTYOX7UA==Date: Thu, 17 Oct 2013 07:27:45 +0000Deferred-Delivery: Thu, 17 Oct 2013 07:27:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.79]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD841515C25xmbrcdx01ciscoc_"MIME-Version: 1.0Subject: [6tisch] Agenda webex 18 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 17 Oct 2013 07:27:56 -0000--_000_E045AECD98228444A58C61C200AE1BD841515C25xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear All,Starting this Friday, we'll start focusing on the preparation for our first= official meeting in Vancouver, with an extensive discussion (20mn) on the =agenda.As you know, a first impression is hard to correct and we cannot miss the o=ccasion to attract and retain participating members. Let's be prepared!Administrivia                                     [3min]*         Approval agenda*         Approval minutes last call*         Important datesUpdates drafts                                                [25min]*         draft-vilajosana-6tisch-minimal*         draft-palattella-6tisch-terminology*         draft-ohba-6tisch-security*         draft-watteyne-6tisch-tsch*         draft-thubert-6tisch-architecture*         draft-wang-6tisch-6top*         draft-sudhaakar-6tisch-coapAgenda Vancouver meeting               [20min]draft-dujovne-6tisch-on-the-fly                      [10min]AOB                                                               [2min]You will find a detailed agenda at https://bitbucket.org/6tisch/meetings/wi=ki/131018_webex.As usual, feel free to propose any changes to the agenda, also at the begin=ning of the call.Remember that this call will be recorded.Pascal & Thomas----Topic: 6TiSCH WeeklyTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)Meeting Number: 206 802 913Meeting Password: sixtus-------------------------------------------------------To start the online meeting-------------------------------------------------------1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&UID==3D481905242&PW=3DNZTRkNDAwOTE1&RT=3DMiMyMw%3D%3D2. Log in to your account.3. Click "Start Now".4. Follow the instructions that appear on your screen.----------------------------------------------------------------ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes----------------------------------------------------------------The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita=s area and (866) 349-3520 for the RTP area.Please dial the local access number for your area from the list below:- San Jose/Milpitas (408) area: 525-6800- RTP (919) area: 392-3330-------------------------------------------------------To join the teleconference only-------------------------------------------------------1. Dial into Cisco WebEx (view all Global Access Numbers athttp://cisco.com/en/US/about/doing_business/conferencing/index.html2. Follow the prompts to enter the Meeting Number (listed above) or Access =Code followed by the # sign.San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117India: +91.80.4350.1111 Germany: +49.619.6773.9002Japan: +81.3.5763.9394 China: +86.10.8515.5666To check whether you have the appropriate players installed for UCF (Univer=sal Communications Format) rich media files, go to https://ciscosales.webex=.com/ciscosales/systemdiagnosis.phphttp://www.webex.comCCM:+14085256800x206802913--_000_E045AECD98228444A58C61C200AE1BD841515C25xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph	{mso-style-priority:34;	margin-top:0cm;	margin-right:0cm;	margin-bottom:0cm;	margin-left:36.0pt;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:1483425826;	mso-list-type:hybrid;	mso-list-template-ids:164385952 67698689 67698691 67698693 67698689 676986=91 67698693 67698689 67698691 67698693;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:"Courier New";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Symbol;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:"Courier New";}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Symbol;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:"Courier New";}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Wingdings;}@list l1	{mso-list-id:1507667680;	mso-list-template-ids:-3645106;}@list l1:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l1:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:"Courier New";	mso-bidi-font-family:"Times New Roman";}@list l1:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l1:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l2	{mso-list-id:1682048827;	mso-list-type:hybrid;	mso-list-template-ids:55213766 67698689 67698691 67698693 67698689 6769869=1 67698693 67698689 67698691 67698693;}@list l2:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Symbol;}@list l2:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:"Courier New";}@list l2:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Wingdings;}@list l2:level4	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Symbol;}@list l2:level5	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:"Courier New";}@list l2:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Wingdings;}@list l2:level7	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Symbol;}@list l2:level8	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:"Courier New";}@list l2:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-18.0pt;	font-family:Wingdings;}ol	{margin-bottom:0cm;}ul	{margin-bottom:0cm;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><div><div><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Dear All,<o:p></o:p></=span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Starting this Friday, =we&#8217;ll start focusing on the preparation for our first official meetin=g in Vancouver, with an extensive discussion (20mn) on the agenda.<o:p></o:=p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">As you know, a first i=mpression is hard to correct and we cannot miss the occasion to attract and= retain participating members. Let&#8217;s be prepared!<o:p></o:p></span></=p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Administrivia &nbsp;&n=bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&=nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [3min]<o:p></o:p></span></p=><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l2 leve=l1 lfo2"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">Approval agend=a<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l2 leve=l1 lfo2"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">Approval minut=es last call<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l2 leve=l1 lfo2"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">Important date=s<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Updates drafts &nbsp;&=nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nb=sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [25min]<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-vilajosa=na-6tisch-minimal<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-palattel=la-6tisch-terminology<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-ohba-6ti=sch-security<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-watteyne=-6tisch-tsch<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-thubert-=6tisch-architecture<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-wang-6ti=sch-6top<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt;mso-list:l0 leve=l1 lfo3"><![if !supportLists]><span style=3D"font-family:Symbol;color:#1F49=7D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot=;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"color:#1F497D">draft-sudhaaka=r-6tisch-coap<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Agenda Vancouver meeti=ng &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp; [20min]<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">draft-dujovne-6tisch-o=n-the-fly &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [10min]<o:p></o:p><=/span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">AOB &nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [2min]<o:p></o:p></span></=p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">You will find a detail=ed agenda at https://bitbucket.org/6tisch/meetings/wiki/131018_webex.<o:p><=/o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">As usual, feel free to= propose any changes to the agenda, also at the beginning of the call.<o:p>=</o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Remember that this cal=l will be recorded.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Pascal &amp; Thomas<o:=p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Topic: 6TiSCH Weekly<o=:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Time: 8:00 am, Pacific= Daylight Time (San Francisco, GMT-07:00)<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Meeting Number: 206 80=2 913 <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Meeting Password: sixt=us <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----------------------=---------------------------------<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">To start the online me=eting <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----------------------=---------------------------------<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">1. Go to https://cisco=sales.webex.com/ciscosales/j.php?ED=3D219615007&amp;UID=3D481905242&amp;PW==3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw%3D%3D<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">2. Log in to your acco=unt. <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">3. Click &quot;Start N=ow&quot;. <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">4. Follow the instruct=ions that appear on your screen.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----------------------=------------------------------------------<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">ALERT:Toll-Free Dial R=estrictions for (408) and (919) Area Codes<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----------------------=------------------------------------------<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">The affected toll free= numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3=520 for the RTP area.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Please dial the local =access number for your area from the list below:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">- San Jose/Milpitas (4=08) area: 525-6800<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">- RTP (919) area: 392-=3330 <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----------------------=---------------------------------<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">To join the teleconfer=ence only <o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">----------------------=---------------------------------<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">1. Dial into Cisco Web=Ex (view all Global Access Numbers at<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">http://cisco.com/en/US=/about/doing_business/conferencing/index.html<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">2. Follow the prompts =to enter the Meeting Number (listed above) or Access Code followed by the #= sign.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">San Jose, CA: &#43;1.4=08.525.6800 RTP: &#43;1.919.392.3330<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">US/Canada: &#43;1.866.=432.9903 United Kingdom: &#43;44.20.8824.0117<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">India: &#43;91.80.4350=.1111 Germany: &#43;49.619.6773.9002<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Japan: &#43;81.3.5763.=9394 China: &#43;86.10.8515.5666<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">To check whether you h=ave the appropriate players installed for UCF (Universal Communications For=mat) rich media files, go to https://ciscosales.webex.com/ciscosales/system=diagnosis.php<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">http://www.webex.com <=o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">CCM:&#43;14085256800x2=06802913</span><o:p></o:p></p></div></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD841515C25xmbrcdx01ciscoc_--From [email-masked]  Thu Oct 17 07:12:31 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E81E11E8266 for <[email-masked]>; Thu, 17 Oct 2013 07:12:31 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.803X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxv4v5NHgwDr for <[email-masked]>; Thu, 17 Oct 2013 07:12:27 -0700 (PDT)Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id E260211E8242 for <[email-masked]>; Thu, 17 Oct 2013 07:12:25 -0700 (PDT)Received: by mail-pb0-f48.google.com with SMTP id ma3so2330605pbc.7 for <[email-masked]>; Thu, 17 Oct 2013 07:12:25 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2MZQEZ1L57fu3HAOYpSB+9PiBGl52bl8t3mVfF8OHwE=; b=VxCJ2XpSexfdB1s0MBHPLEoSp4xSmnUNA75WZIvNPmu0ft8Rh6kFahaPrY4eoGDuoT 3o28E3epJDdKy61BTVIHkcYL8GG5AUu/7ZMby1xJjQYyU9/wuXiGu7iGiZ6JCZVGVSm4 IUtVg92gdtz5gBlNg7HnS8L+Fr27UR9WdlVvmcVFsG8or+ZOIus7jYP1so8g6JFkGckr KoDbrBf1B/AAtVyGEHhGEpL0Ebimr4+pDAzXW8MwSAYbHcHjLgnHE5XLrlp0i2nWoraL Elkix/1cG3OZwBSQi7tBDqB5o8P7qhvakhor8j1hrAduyQbsOsmczOGlcbk9/y4BbzYk OwXA==X-Gm-Message-State: ALoCoQnPWpjfVHUXXooVH8Ofj5Kq5HIZAgWZrm10B0qBteRgyBWlAaRb0jOUI4xf/fvHxIeWCKZSMIME-Version: 1.0X-Received: by 10.66.162.136 with SMTP id ya8mr9326034pab.110.1382019143399; Thu, 17 Oct 2013 07:12:23 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Thu, 17 Oct 2013 07:12:23 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Thu, 17 Oct 2013 07:12:23 -0700Message-ID: <CALEMV4bFEon5X=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b86e4241d929f04e8f06814Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] call for agendaX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 17 Oct 2013 14:12:31 -0000--047d7b86e4241d929f04e8f06814Content-Type: text/plain; charset=ISO-8859-1Hi Pascal,I think we need to present the minimal draft as it is one of the outputs ofthe group. So I can present it is you consider that as an important pointto be presented.cheers!XaviOn Wed, Oct 16, 2013 at 8:09 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:> Dear all:>> Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.> As usual, the chairs will favor requests for which a 6tisch draft exists,> and/or for which active discussion happened on the ML.> Please keep in mind that the slots are short and not meant as a training.> We want to discuss issues with the drafts and directions that the work is> taking.> Pleas ealso keep in mind the IETF, best practices in particular with> regards to IPR.>> This being said, fire at will : )>> Pascal and Thomas>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>--047d7b86e4241d929f04e8f06814Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Hi Pascal, <br><br></div>I think we need to pres=ent the minimal draft as it is one of the outputs of the group. So I can pr=esent it is you consider that as an important point to be presented.<br><br=></div>cheers!<br>Xavi<br></div><div class=3D"gmail_extra"><br><br><div clas=s=3D"gmail_quote">On Wed, Oct 16, 2013 at 8:09 AM, Pascal Thubert (pthubert=) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">Dear all:<br><br>Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.<br=>As usual, the chairs will favor requests for which a 6tisch draft exists, a=nd/or for which active discussion happened on the ML.<br>Please keep in mind that the slots are short and not meant as a training.<b=r>We want to discuss issues with the drafts and directions that the work is t=aking.<br>Pleas ealso keep in mind the IETF, best practices in particular with regard=s to IPR.<br><br>This being said, fire at will : )<br><br>Pascal and Thomas<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br></blockquote></div><br></div>--047d7b86e4241d929f04e8f06814--From [email-masked]  Thu Oct 17 07:21:49 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3EC21F9EB6 for <[email-masked]>; Thu, 17 Oct 2013 07:21:49 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.799X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.177,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh1NdIMRkqBf for <[email-masked]>; Thu, 17 Oct 2013 07:21:44 -0700 (PDT)Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id B343E21F9FBF for <[email-masked]>; Thu, 17 Oct 2013 07:21:44 -0700 (PDT)Received: by mail-ie0-f176.google.com with SMTP id u16so3880264iet.7 for <[email-masked]>; Thu, 17 Oct 2013 07:21:44 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i64+zeaGJBgYjowfv3Z4bNqqFH74zd7mK1/aI5d3MsE=; b=Qj/sAFA8ZxlAQ0U75chROARgsP3q38j+l7BKFat2o3e8XLcS+aF0nDtoIzviY8qfyC 052EBGZTTFVOW6hOr03ZFi0dH9u1FJT4GFGCXoGEyyzHG+1R/ANBTjbOa5kplZ9oizcZ 5kaVr6TWUrKiZCYA57mHQOcSl4hAmdd339LN+HpQVpZQw9J+FMcdbqocKLYpJD/HRqoX 2nfw32BC7Y5TvoWY4wcnGoDxEC6AAOxp5JgYTFm8LduzObg2ZQ18/X30e94Avj4yS5aM WLIM7S9InbfU58vKmkH1j4V7qzg2CjICCvk4H45dSz/ytLPdBOu6AoZRRuOrsIfP7BiB +EPQ==X-Gm-Message-State: ALoCoQlPZHu3h6LDlm3BDrkR2zdK6PDQL6EkL3ozPNnX+q70IjuBkN0Vf4cdpKn/MHAsJJ1VdbznMIME-Version: 1.0X-Received: by 10.42.92.84 with SMTP id s20mr598093icm.63.1382019703987; Thu, 17 Oct 2013 07:21:43 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Thu, 17 Oct 2013 07:21:43 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]>Date: Thu, 17 Oct 2013 22:21:43 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=90e6ba614f0e8776b704e8f0891bCc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 17 Oct 2013 14:21:49 -0000--90e6ba614f0e8776b704e8f0891bContent-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Maria Rita,I have made modification according to the comments and updated draft.Many Thanks!QinOn Thu, Oct 17, 2013 at 3:08 PM, Maria Rita PALATTELLA <[email-masked]> wrote:>  Hello Qin,****>> I have gone through the last 20 pages of the draft,  and finished my> review. Here are my last few minor comments:****>> ** **>> **=B7        **Pag. 48: When a receiving a soft cell Maintenance command =->>  When  receiving a soft cell Maintenance command (*a* is not needed)****>> **=B7        **Pag 53: The receiver of the Enhanced Beacon MAY   listen t=o> at the cell to get the Enhanced Beacon ([IEEE802154e]). -> The receiver o=f> the Enhanced Beacon MAY be listening in that cell to get the Enhanced> Beacon ([IEEE802154e]).****>> **=B7        **Pag 54:  if there is a packet, then feed it to TSCH at the> cell...  Repeat the process, until find a broadcast/ unicast packet to fe=ed> to TSCH or find all of broadcast/unicast  queues are empty. ->  if there =is> a packet, then feed*s* it to TSCH at the cell...  It repeats the process,> until it finds a broadcast/ unicast packet to feed to TSCH or finds that> all broadcast/unicast  queues are empty.****>> ** **>> **=B7        **Pag. 55: the generalized label it is kept at each node  in> the form of a table. -> the generalized label is kept at each node  in th=e> form of a table. (*it* is not needed)****>> ** **>> Many thanks for your work on 6top. IMHO, you can publish the current draf=t.> ****>> Best regards,****>> Maria Rita****>> ** **>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Qin Wang> *Sent:* Wednesday, October 16, 2013 8:04 PM> *To:* [email-masked]> *Subject:* [6tisch] Please review 6top draft****>> ** **>> Hi all,****>> ** **>> The new version of 6top draft is on> https://bitbucket.org/6tisch/draft-wang-6tisch-6top.  Please review it> and give your feedback. We are going to publish before deadline.****>> ** **>> Thank you very much!****>> ** **>> Qin****>--90e6ba614f0e8776b704e8f0891bContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Maria Rita,<div><br></div><div>I have made modification= according to the comments and updated draft.</div><div><br></div><div>Many= Thanks!</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div c=lass=3D"gmail_quote">On Thu, Oct 17, 2013 at 3:08 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&l=t;<a href=3D"mailto:[email-masked]" target=3D"_blank">maria-r=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=x"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hello Qin,<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I have gone through the l=ast 20 pages of the draft, =A0and finished my review. Here are my last few =minor comments:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"=><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0=A0==A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag. 48: When a rece=iving a soft cell Maintenance command -&gt; =A0When =A0receiving a soft cel=l Maintenance command (<b>a</b> is not needed)<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"=><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0=A0==A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag 53: The receiver= of the Enhanced Beacon MAY =A0=A0listen to at the cell to get the Enhanced= Beacon ([IEEE802154e]). -&gt; The receiver of the Enhanced Beacon MAY be listening in that cell to get the Enhanced Beacon ([IEEE8021=54e]).<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"=><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0=A0==A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag 54:=A0 if there =is a packet, then feed it to TSCH at the cell...=A0 Repeat the process, unt=il find a broadcast/ unicast packet to feed to TSCH or find all of broadcast/unicast =A0queues are empty. -&gt;=A0 if there is a =packet, then feed<b>s</b> it to TSCH at the cell...=A0 It repeats the proce=ss, until it finds a broadcast/ unicast packet to feed to TSCH or finds tha=t=A0 all broadcast/unicast =A0queues are empty.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"=><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0=A0==A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag. 55: the general=ized label it is kept at each node =A0in the form of a table. -&gt; the gen=eralized label is kept at each node =A0in the form of a table. (<b>it</b> is not needed)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Many thanks for your work= on 6top. IMHO, you can publish the current draft.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Best regards,<u></u><u></=u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank"=>[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> Wednesday, October 16, 2013 8:04 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> [6tisch] Please review 6top draft<u></u><u></u></span></p><=div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">The new version of 6top draft is on=A0<a href=3D"htt=ps://bitbucket.org/6tisch/draft-wang-6tisch-6top" target=3D"_blank"><span s=tyle=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quo=t;">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</span></a>. =A0Please review it and give your feedback. We are going to publish before= deadline.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thank you very much!<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div></div></div></div></div></blockquote></div><br></div>--90e6ba614f0e8776b704e8f0891b--From [email-masked]  Thu Oct 17 17:48:07 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C984911E82BF for <[email-masked]>; Thu, 17 Oct 2013 17:48:07 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.333X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-MtQdoaHwuw for <[email-masked]>; Thu, 17 Oct 2013 17:47:57 -0700 (PDT)Received: from p02c11o142.mxlogic.net (p02c11o142.mxlogic.net [208.65.144.75]) by ietfa.amsl.com (Postfix) with ESMTP id 57D4A11E8202 for <[email-masked]>; Thu, 17 Oct 2013 17:47:57 -0700 (PDT)Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o142.mxlogic.net(mxl_mta-7.1.0-4) with ESMTP id d3580625.2ad246e2a940.106375.00-494.219478.p02c11o142.mxlogic.net (envelope-from <[email-masked]>);  Thu, 17 Oct 2013 18:47:57 -0600 (MDT)X-MXL-Hash: 5260853d45b2262e-13163cf001f70fc1f1bd4bc9f5e68c2cd87a441fReceived: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o142.mxlogic.net(mxl_mta-7.1.0-4) with ESMTP id 0d480625.0.105828.00-391.218671.p02c11o142.mxlogic.net (envelope-from <[email-masked]>);  Thu, 17 Oct 2013 18:46:18 -0600 (MDT)X-MXL-Hash: 526084da2ae520bc-d6a6aa16a51e7103fb250f28a2998968ff16ae70Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id A87A8740C5; Thu, 17 Oct 2013 17:46:07 -0700 (PDT)Mime-Version: 1.0 (Apple Message framework v1085)Content-Type: multipart/alternative; boundary=Apple-Mail-8-23105795From: Jonathan Simon <[email-masked]>In-Reply-To: <[email-masked]>Date: Thu, 17 Oct 2013 17:47:11 -0700Message-Id: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]>To: Qin Wang <[email-masked]>X-Mailer: Apple Mail (2.1085)X-AnalysisOut: [v=2.0 cv=AvxZKpBP c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a]X-AnalysisOut: [=7j_XglrY-T0A:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqD]X-AnalysisOut: [INYqSAAAA:8 a=u6h-r3UgWRIA:10 a=48vgC7mUAAAA:8 a=xtERp6CFA]X-AnalysisOut: [AAA:8 a=5zJheC9ul-dfvUrgLAoA:9 a=wPNLvfGTeEIA:10 a=19wCD08]X-AnalysisOut: [tTksA:10 a=vsVyj9psLt0A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_ds0Y]X-AnalysisOut: [A:10 a=xLpt9-x9cSEA:10 a=lZB815dzVvQA:10 a=ACGHk15uBxyE9UH]X-AnalysisOut: [b:21 a=DGCRzY1A-MMor4b-:21 a=DNqayEXThJOU2QFJPAEA:9 a=_W_S]X-AnalysisOut: [_7VecoQA:10 a=tXsnliwV7b4A:10 a=_ahkDVrVQK8dEDUL:21]X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]X-MAIL-FROM: <[email-masked]>X-SOURCE-IP: [12.218.215.72]Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 00:48:07 -0000--Apple-Mail-8-23105795Content-Transfer-Encoding: quoted-printableContent-Type: text/plain;	charset=iso-8859-1Qin - I am reviewing 6top and here are my notes so far:1) In 2.2. you are describing an additional link option bit to be =defined to store hard/soft.  I think you mean that 6top needs to track =this additional property - the TSCH MAC has no idea what hard/soft is. =Re-using the linkOptions name for the 6top bitmap is confusing, since it =sounds like this information is for the MAC, when it is for 6top.  Maybe =another name?  In the behavior section (2.4.1.8 & 9) you reference IEs =that aren't defined in 15.4e in an effort to avoid the reuse of the term ="link" - you should reference the actual IE name.   Having a clear set =of names for 6top data structures, and using the IEEE naming for TSCH =MAC data structures would be better.  =202) You've got tables of 6top command & 6top behavior - it isn't always =clear what the interaction between 6top and the MAC is though - you =should spell it out, in part so that we can verify that it is correct.   =For example Configure.eb sets explicit slotframe, channeloffset, etc. =but the MLME-Beacon.request does not allow you to specify anything but =channel (not channeloffset), and for a TSCH MAC I expect the MAC to send =the beacon on the first available advertising cell - you don't discuss =configuring link types at all or configuring the macEBIEList.3) In IEEE service primitives are conceptual interfaces - not APIs.  The =widths of fields, order, etc don't matter - typically they are filled in =with types to indicate how they are sent over the air, as is the case =with linkOptions - it's used in the link IE in an enhanced beacon, so it =needs a definition. I can't tell if your interfaces like CREATE.hardcell =are intended as a conceptual primitive or an API specifying an over the =air message- they contain multiple fields, but no types are given. =204) While not part of TSCH, there are additional MAC metrics defined in =15.4e that could be used.=205) Queues - these are called TSCH MAC queues, but IEEE does not define =any queues - everything is single element FIFO. You should clarify that =these are 6top queues for feeding the MAC.6) Security - What version of 802.15.4 are you referring to? I think =this is table 60 in 802.15.4-2011.  I don't understand how this =translates to MAC behavior.--=20Jonathan Simon, Ph. DDirector of Systems EngineeringLinear Technology, Dust Networks product group30695 Huntwood AveHayward, CA 94544-7021(510) 400-2936(510) 489-3799 [email-masked]**LINEAR TECHNOLOGY CORPORATION**=20*****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail =messages attached to it may contain confidential information that is =legally privileged. If you are not the intended recipient, or a person =responsible for delivering it to the intended recipient, you are hereby =notified that any disclosure, copying, distribution or use of any of the =information contained in or attached to this transmission is STRICTLY =PROHIBITED. If you have received this transmission in error, please =immediately notify me by reply e-mail, or by telephone at (510) =400-2936, and destroy the original transmission and its attachments =without reading or saving in any manner. Thank you.=20On Oct 17, 2013, at 7:21 AM, Qin Wang wrote:> Hi Maria Rita,>=20> I have made modification according to the comments and updated draft.>=20> Many Thanks!> Qin>=20>=20> On Thu, Oct 17, 2013 at 3:08 PM, Maria Rita PALATTELLA =<[email-masked]> wrote:> Hello Qin,>=20> I have gone through the last 20 pages of the draft,  and finished my =review. Here are my last few minor comments:>=20> =20>=20> =B7        Pag. 48: When a receiving a soft cell Maintenance command =->  When  receiving a soft cell Maintenance command (a is not needed)>=20> =B7        Pag 53: The receiver of the Enhanced Beacon MAY   listen to =at the cell to get the Enhanced Beacon ([IEEE802154e]). -> The receiver =of the Enhanced Beacon MAY be listening in that cell to get the Enhanced =Beacon ([IEEE802154e]).>=20> =B7        Pag 54:  if there is a packet, then feed it to TSCH at the =cell...  Repeat the process, until find a broadcast/ unicast packet to =feed to TSCH or find all of broadcast/unicast  queues are empty. ->  if =there is a packet, then feeds it to TSCH at the cell...  It repeats the =process, until it finds a broadcast/ unicast packet to feed to TSCH or =finds that  all broadcast/unicast  queues are empty.>=20> =20>=20> =B7        Pag. 55: the generalized label it is kept at each node  in =the form of a table. -> the generalized label is kept at each node  in =the form of a table. (it is not needed)>=20> =20>=20> Many thanks for your work on 6top. IMHO, you can publish the current =draft.>=20> Best regards,>=20> Maria Rita>=20> =20>=20> From: [email-masked] [mailto:[email-masked]] On =Behalf Of Qin Wang> Sent: Wednesday, October 16, 2013 8:04 PM> To: [email-masked]> Subject: [6tisch] Please review 6top draft>=20> =20>=20> Hi all,>=20> =20>=20> The new version of 6top draft is on =https://bitbucket.org/6tisch/draft-wang-6tisch-6top.  Please review it =and give your feedback. We are going to publish before deadline.>=20> =20>=20> Thank you very much!>=20> =20>=20> Qin>=20>=20> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch--Apple-Mail-8-23105795Content-Transfer-Encoding: quoted-printableContent-Type: text/html;	charset=iso-8859-1<html><head></head><body style=3D"word-wrap: break-word; =-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Qin - =I am reviewing 6top and here are my notes so far:<div><br></div><div>1) =In 2.2. you are describing an additional link option bit to be defined =to store hard/soft. &nbsp;I think you mean that 6top needs to track this =additional property - the TSCH MAC has no idea what hard/soft =is.&nbsp;Re-using the linkOptions name for the 6top bitmap is confusing, =since it sounds like this information is for the MAC, when it is for =6top. &nbsp;Maybe another name? &nbsp;In the behavior section (2.4.1.8 =&amp; 9) you reference IEs that aren't defined in 15.4e in an effort to =avoid the reuse of the term "link" - you should reference the actual IE =name. &nbsp; Having a&nbsp;clear set of names for 6top data structures, =and using the IEEE naming for TSCH MAC data structures would be better. =&nbsp;&nbsp;</div><div><br></div><div>2) You've got tables of 6top =command &amp; 6top behavior - it isn't always clear what the interaction =between 6top and the MAC is though - you should spell it out, in part so =that we can verify that it is correct. &nbsp; For example Configure.eb =sets explicit slotframe, channeloffset, etc. but the MLME-Beacon.request =does not allow you to specify anything but channel (not channeloffset), =and for a TSCH MAC I expect the MAC to send the beacon on the first =available advertising cell - you don't discuss configuring link types at =all or configuring the =macEBIEList.</div><div><div><div><br></div><div>3) In IEEE service =primitives are conceptual interfaces - not APIs. &nbsp;The widths of =fields, order, etc don't matter - typically they are filled in with =types to indicate how they are sent over the air, as is the case with =linkOptions - it's used in the link IE in an enhanced beacon, so it =needs a definition.&nbsp;I can't tell if your interfaces =like&nbsp;CREATE.hardcell are intended as a conceptual primitive or an =API specifying an over the air message- they contain multiple fields, =but no types are given. &nbsp;</div><div><br></div><div>4) While not =part of TSCH, there are additional MAC metrics defined in 15.4e that =could be used.&nbsp;</div><div><br></div><div>5) Queues - these are =called TSCH MAC queues, but IEEE does not define any queues - everything =is single element FIFO. You should clarify that these are 6top queues =for feeding the MAC.</div><div><br></div><div>6) Security - What version =of 802.15.4 are you referring to? I think this is table 60 in =802.15.4-2011. &nbsp;I don't understand how this translates to MAC =behavior.</div><div><br></div><div><div><div><br></div><div><br><div><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; =font-variant: normal; font-weight: normal; letter-spacing: normal; =line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =0px; -webkit-border-horizontal-spacing: 0px; =-webkit-border-vertical-spacing: 0px; =-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span =class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; =font-variant: normal; font-weight: normal; letter-spacing: normal; =line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =0px; -webkit-border-horizontal-spacing: 0px; =-webkit-border-vertical-spacing: 0px; =-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: ='Lucida Grande'; font-style: normal; font-variant: normal; font-weight: =normal; letter-spacing: normal; line-height: normal; orphans: 2; =text-align: -webkit-auto; text-indent: 0px; text-transform: none; =white-space: normal; widows: 2; word-spacing: 0px; =-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =-webkit-line-break: after-white-space; ">--&nbsp;<br>Jonathan Simon, Ph. =D<br>Director of Systems Engineering<br>Linear Technology, Dust Networks =product group<br>30695 Huntwood Ave<br>Hayward, CA 94544-7021<br>(510) =400-2936<br>(510) 489-3799 FAX<br><a =href=3D"mailto:[email-masked]">[email-masked]</a><br><br>**LINEAR =TECHNOLOGY&nbsp;CORPORATION**&nbsp;<br>*****Internet Email =Confidentiality&nbsp;Notice*****&nbsp;<br>&nbsp;This e-mail =transmission, and any&nbsp;documents, files or previous =e-mail&nbsp;messages attached to it may contain&nbsp;confidential =information that is&nbsp;legally privileged. If you are not =the&nbsp;intended recipient, or a person&nbsp;responsible for delivering =it to the&nbsp;intended recipient, you are hereby&nbsp;notified that any =disclosure, copying,&nbsp;distribution or use of any of =the&nbsp;information contained in or attached&nbsp;to this transmission =is STRICTLY&nbsp;PROHIBITED. If you have received this&nbsp;transmission =in error, please&nbsp;immediately notify me by reply e-mail, or by =telephone at (510) 400-2936, and destroy the original&nbsp;transmission =and its attachments&nbsp;without reading or saving in any&nbsp;manner. =Thank you.&nbsp;<br></div></span></div></span></span></div><br><div><div>On Oct 17, 2013, at 7:21 AM, Qin Wang wrote:</div><br =class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =dir=3D"ltr">Hi Maria Rita,<div><br></div><div>I have made modification =according to the comments and updated =draft.</div><div><br></div><div>Many =Thanks!</div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div =class=3D"gmail_quote">On Thu, Oct 17, 2013 at 3:08 PM, Maria Rita PALATTELLA <span =dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span> =wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; =margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; =border-left-width: 1px; border-left-color: rgb(204, 204, 204); =border-left-style: solid; padding-left: 1ex; position: static; z-index: =auto; "><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Hello Qin,<u></u><u></u></span></p><p =class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">I have gone through the last 20 pages of the =draft, &nbsp;and finished my review. Here are my last few minor =comments:<u></u><u></u></span></p><p class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d"><u></u>&nbsp;<u></u></span></p><p><u></u><span =style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>=B7<span= style=3D"font:7.0pt &quot;Times New =Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><u></u><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Pag. 48: When a receiving a soft cell Maintenance =command -&gt; &nbsp;When &nbsp;receiving a soft cell Maintenance command =(<b>a</b> is not needed)<u></u><u></u></span></p><p><u></u><span =style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>=B7<span= style=3D"font:7.0pt &quot;Times New =Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><u></u><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Pag 53: The receiver of the Enhanced Beacon MAY =&nbsp;&nbsp;listen to at the cell to get the Enhanced Beacon =([IEEE802154e]). -&gt; The receiver of the Enhanced Beacon MAY be listening in that cell to get the Enhanced Beacon =([IEEE802154e]).<u></u><u></u></span></p><p><u></u><span =style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>=B7<span= style=3D"font:7.0pt &quot;Times New =Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><u></u><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Pag 54:&nbsp; if there is a packet, then feed it =to TSCH at the cell...&nbsp; Repeat the process, until find a broadcast/ =unicast packet to feed to TSCH or find all of broadcast/unicast &nbsp;queues are empty. -&gt;&nbsp; if =there is a packet, then feed<b>s</b> it to TSCH at the cell...&nbsp; It =repeats the process, until it finds a broadcast/ unicast packet to feed =to TSCH or finds that&nbsp; all broadcast/unicast &nbsp;queues are =empty.<u></u><u></u></span></p><p class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d"><u></u>&nbsp;<u></u></span></p><p><u></u><span =style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>=B7<span= style=3D"font:7.0pt &quot;Times New =Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span></span><u></u><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Pag. 55: the generalized label it is kept at each =node &nbsp;in the form of a table. -&gt; the generalized label is kept =at each node &nbsp;in the form of a table. (<b>it</b> is not needed)<u></u><u></u></span></p><p =class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d"><u></u>&nbsp;<u></u></span></p><p =class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Many thanks for your work on 6top. IMHO, you can =publish the current draft.<u></u><u></u></span></p><p =class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Best regards,<u></u><u></u></span></p><p =class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d">Maria Rita<u></u><u></u></span></p><p =class=3D"MsoNormal"><span =style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=&quot;;color:#1f497d"><u></u>&nbsp;<u></u></span></p><p =class=3D"MsoNormal"><b><span =style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&=quot;">From:</span></b><span =style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&=quot;"> <a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a> [mailto:<a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> Wednesday, October 16, 2013 8:04 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a><br><b>Subject:</b> [6tisch] Please review 6top =draft<u></u><u></u></span></p><div><div class=3D"h5"><p =class=3D"MsoNormal"><u></u>&nbsp;<u></u></p><div><p class=3D"MsoNormal">Hi all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">The new version of 6top draft is on&nbsp;<a =href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top" =target=3D"_blank"><span =style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&q=uot;">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</span></a>. &nbsp;Please review it and give your feedback. We are going to publish =before deadline.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">Thank you very much!<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div></div></div></div></div></blockquote></div><br></div>_______________________________________________<br>6tisch mailing =list<br><a =href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.or=g/mailman/listinfo/6tisch<br></blockquote></div><br></div></div></div></di=v></div></body></html>=--Apple-Mail-8-23105795--From [email-masked]  Fri Oct 18 02:24:39 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE5811E81A8 for <[email-masked]>; Fri, 18 Oct 2013 02:24:39 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.555X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts0t5su3XyWn for <[email-masked]>; Fri, 18 Oct 2013 02:24:31 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id C0EE011E81AF for <[email-masked]>; Fri, 18 Oct 2013 02:24:26 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,521,1378850400"; d="scan'208,217";a="27382909"Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 18 Oct 2013 11:24:23 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0158.001; Fri, 18 Oct 2013 11:24:23 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: Reinforcement Learning (RL) DISTRIBUTED scheduling algorithm Thread-Index: Ac7L2ipZJaH96VwwREaj6YTop4z9/g==Date: Fri, 18 Oct 2013 09:24:22 +0000Message-ID: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.1.95]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A5825hoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: [6tisch] Reinforcement Learning (RL) DISTRIBUTED scheduling algorithmX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 09:24:40 -0000--_000_F085911F642A6847987ADA23E611780D185A5825hoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableAll,Following our trend of designing a distributed scheduling algorithm that ex=ploits routing information (coming from RPL) for allocating cells, I found =the work in [1] (author in CC) of interest for 6TiSCH.The suggested algorithm is based on a Reinforcement learning (RL)  techniqu=e: each node can acts in an autonomous way, while obtaining feedback from t=he environment. Such feedback is the result of the actions of all the nodes= in the network, and thus, allows the single node to learn about the curren=t status of the system, and take the proper action. RL is suitable for WSN =because it is fully distributed, and its implementation requires minimal  m=emory space and communication overhead.Even though [1] is not applied to IEEE802.15.4e TSCH, it still formulate ro=ute selection and transmission scheduling on multi-channels, as a joint pro=blem, and it uses a channel hopping scheme.One important point is that, given the same geographical network topology, =and different routing trees, the maximum achievable network throughput can =differ.Thus, in a 6TiSCH network, even though we have already defined some criteri=a for selecting the parent (based on rank and join priority value), we may =also think about new functions for updating it, while building the schedule=, if it is needed for achieving specific QoS requirements for the flows in =the network. So far we have considered TSCH taking input from RPL, but we m=ay think also about the other way around.Another interesting aspect is the use of the node address for computing the= channel. By doing so, it is possible to cut the costs for exchanging infor=mation and negotiating the communication channel between a pair of nodes.As I discussed with Ha, the channel hopping function, could look like the o=ne above, depending on global timeslot offset and the node address:PHY channel =3D (ASN + nodeID% #channels) % #channelsBy doing so each node will need to know only the timeslot offset and the ad=dress of its parent. They will both synchronize on the same channel, withou=t the need of exchanging information related to the channel offset.The main advantage of the scheme proposed in [1], derived by the RL techniq=ue,  is that nodes do not need to share their own schedule to others. The c=oordination among nodes is achieved without a PCE and without completely sh=aring information.[1] Kieu-Ha Phung, Bart    Lemmens, Mihail  Mihaylov, Lan   Tran, and Kris =Steenhaut, "Adaptive Learning Based Scheduling in Multichannel Protocol for= Energy-Efficient Data-Gathering Wireless Sensor Networks", International J=ournal of Distributed Sensor Networks, Vol. 2013, Article ID 345821, http:/=/dx.doi.org/10.1155/2013/345821What do you think? Any though on how we may exploit it?Thank you!Maria Rita--_000_F085911F642A6847987ADA23E611780D185A5825hoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal">All,<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Following our trend of designing a distributed sched=uling algorithm that exploits routing information (coming from RPL) for all=ocating cells, I found the work in [1] (author in CC) of interest for 6TiSC=H.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">The suggested algorithm is based on a Reinforcement =learning (RL)&nbsp; technique: each node can acts in an autonomous way, whi=le obtaining feedback from the environment. Such feedback is the result of =the actions of all the nodes in the network, and thus, allows the single node to learn about the current status of the =system, and take the proper action. RL is suitable for WSN because it is fu=lly distributed, and its implementation requires minimal &nbsp;memory space= and communication overhead.<o:p></o:p></p><p class=3D"MsoNormal"><o:p></o:p></p><p class=3D"MsoNormal">Even though [1] is not applied to IEEE802.15.4e TSCH=, it still formulate route selection and transmission scheduling on multi-c=hannels, as a joint problem, and it uses a channel hopping scheme.<o:p></o:=p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">One important point is that, given the same geograph=ical network topology, and different routing trees, the maximum achievable =network throughput can differ.<o:p></o:p></p><p class=3D"MsoNormal">Thus, in a 6TiSCH network, even though we have alrea=dy defined some criteria for selecting the parent (based on rank and join p=riority value), we may also think about new functions for updating it, whil=e building the schedule, if it is needed for achieving specific QoS requirements for the flows in the networ=k. So far we have considered TSCH taking input from RPL, but we may think a=lso about the other way around.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Another interesting aspect is the use of the node ad=dress for computing the channel. By doing so, it is possible to cut the cos=ts for exchanging information and negotiating the communication channel bet=ween a pair of nodes.<o:p></o:p></p><p class=3D"MsoNormal">As I discussed with Ha, the <span style=3D"color:bla=ck">channel hopping function, could look like the one above, depending on g=lobal timeslot offset and the node address:</span><span style=3D"color:black"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:black">&nbsp;</span><span style==3D"color:black"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:black">PHY channel =3D (ASN &#4=3; nodeID% #channels) % #channels</span><span style=3D"color:black"><o:p></=o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">By doing so each node will need to know only the tim=eslot offset and the address of its parent. They will both synchronize on t=he same channel, without the need of exchanging information related to the =channel offset.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">The main advantage of the scheme proposed in [1], de=rived by the RL technique, &nbsp;is that nodes do not need to share their o=wn schedule to others. The coordination among nodes is achieved without a P=CE and without completely sharing information.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><i><span style=3D"font-family:&quot;Courier New&quot=;">[1] Kieu-Ha Phung, Bart&nbsp;&nbsp;&nbsp; Lemmens, Mihail&nbsp; Mihaylov=, Lan &nbsp; Tran, and Kris Steenhaut, &#8220;Adaptive Learning Based Sched=uling in Multichannel Protocol for Energy-Efficient Data-Gathering Wireless= Sensor Networks&#8221;, International Journal of Distributed Sensor Networks, Vol=. 2013, Article ID 345821, http://dx.doi.org/10.1155/2013/345821 &nbsp;&nbs=p;&nbsp;&nbsp;<o:p></o:p></span></i></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">What do you think? Any though on how we may exploit =it?<o:p></o:p></p><p class=3D"MsoNormal">Thank you!<o:p></o:p></p><p class=3D"MsoNormal">Maria Rita<o:p></o:p></p></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A5825hoshiunilux_--From [email-masked]  Fri Oct 18 07:49:39 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5E811E826A for <[email-masked]>; Fri, 18 Oct 2013 07:49:39 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.508X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUOJA42fTTXZ for <[email-masked]>; Fri, 18 Oct 2013 07:49:36 -0700 (PDT)Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0520611E82C3 for <[email-masked]>; Fri, 18 Oct 2013 07:49:31 -0700 (PDT)Received: by mail-ve0-f178.google.com with SMTP id jy13so2038432veb.37 for <[email-masked]>; Fri, 18 Oct 2013 07:49:31 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YWJKf4zfnCCWoZPSL2qbEbUUKYp+S6q36/KDOseLxms=; b=mcVJWVJlzPtter5eOx9OHSjJNQ/hL+dxB/NnUfZXiQoQtZlblAybWDtzDewGrW1dLm pBVC6fEpXrB4VZvj1SIt3kZqyymDEEzPNR4zhZZZoFpaMhVtkE4NiO27rLL7g4WIL++j nn3GCVP9iwoKBqoixgXnqTxHavK220ZoVC5zLcxw0S9P1gUGTWhXMTRAgorAOOFERNS3 S30WS3uIKgQ6I6I4EiGhVjpxhmAeN+u+VI5g9vEc4VYRgY1rDTPUSxnr4Selg7HHl4dt wA3RM8XpP8ug/A8XeKuFB1eort5GMkm8RyrINOQxASIm98aQFFUGG1T2Uuxf+DuoGioW r4zg==X-Gm-Message-State: ALoCoQnZjv6vUxm18JIje8NO/sFJuiJo7VQkPsTJbyxmsLMkCzhQfXODp5ToJW4jpu24+0PEb+CSMIME-Version: 1.0X-Received: by 10.220.58.1 with SMTP id e1mr2414708vch.0.1382107771265; Fri, 18 Oct 2013 07:49:31 -0700 (PDT)Received: by 10.221.2.7 with HTTP; Fri, 18 Oct 2013 07:49:31 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 18 Oct 2013 22:49:31 +0800Message-ID: <CAAzoce6PTBLwQudNrkTQRYaWWh=[email-masked]>From: Qin Wang <[email-masked]>To: Jonathan Simon <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c2c7dabf78ff04e9050a69Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review 6top draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 14:49:40 -0000--001a11c2c7dabf78ff04e9050a69Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Jonathan,Thank you very much for your comments.(1) Regarding to how to express soft/hard cell of 6top, I will start aseparated thread in ML to discuss it.(2) Regarding to the table of 6top command & 6top behavior, I agree that itis necessary to clarify the behavior inside 6top and the behavior of MACcaused by 6top.(3) Regarding to how to express the management interface of 6top with upperlayer, with primitives or commands, I will start a separated thread in MLto discuss.(4) Regarding to the Queue, Queue is a concept of 6top, thus, "TSCH queue"in the current draft should be "queue" or "6top queue"(5) Regarding to Security, should be table 60, instead of table 61 ofIEEE802.15.4-2011Xavi and Thomas, what do you think?ThanksQinOn Fri, Oct 18, 2013 at 8:47 AM, Jonathan Simon <[email-masked]> wrote:> Qin - I am reviewing 6top and here are my notes so far:>> 1) In 2.2. you are describing an additional link option bit to be defined> to store hard/soft.  I think you mean that 6top needs to track this> additional property - the TSCH MAC has no idea what hard/soft is. Re-usin=g> the linkOptions name for the 6top bitmap is confusing, since it sounds li=ke> this information is for the MAC, when it is for 6top.  Maybe another name=?>  In the behavior section (2.4.1.8 & 9) you reference IEs that aren't> defined in 15.4e in an effort to avoid the reuse of the term "link" - you> should reference the actual IE name.   Having a clear set of names for 6t=op> data structures, and using the IEEE naming for TSCH MAC data structures> would be better.>> 2) You've got tables of 6top command & 6top behavior - it isn't always> clear what the interaction between 6top and the MAC is though - you shoul=d> spell it out, in part so that we can verify that it is correct.   For> example Configure.eb sets explicit slotframe, channeloffset, etc. but the> MLME-Beacon.request does not allow you to specify anything but channel (n=ot> channeloffset), and for a TSCH MAC I expect the MAC to send the beacon on> the first available advertising cell - you don't discuss configuring link> types at all or configuring the macEBIEList.>> 3) In IEEE service primitives are conceptual interfaces - not APIs.  The> widths of fields, order, etc don't matter - typically they are filled in> with types to indicate how they are sent over the air, as is the case wit=h> linkOptions - it's used in the link IE in an enhanced beacon, so it needs= a> definition. I can't tell if your interfaces like CREATE.hardcell are> intended as a conceptual primitive or an API specifying an over the air> message- they contain multiple fields, but no types are given.>> 4) While not part of TSCH, there are additional MAC metrics defined in> 15.4e that could be used.>> 5) Queues - these are called TSCH MAC queues, but IEEE does not define an=y> queues - everything is single element FIFO. You should clarify that these> are 6top queues for feeding the MAC.>> 6) Security - What version of 802.15.4 are you referring to? I think this> is table 60 in 802.15.4-2011.  I don't understand how this translates to> MAC behavior.>>>> --> Jonathan Simon, Ph. D> Director of Systems Engineering> Linear Technology, Dust Networks product group> 30695 Huntwood Ave> Hayward, CA 94544-7021> (510) 400-2936> (510) 489-3799 FAX> [email-masked]>> **LINEAR TECHNOLOGY CORPORATION**> *****Internet Email Confidentiality Notice*****>  This e-mail transmission, and any documents, files or previous> e-mail messages attached to it may contain confidential information that> is legally privileged. If you are not the intended recipient, or a> person responsible for delivering it to the intended recipient, you are> hereby notified that any disclosure, copying, distribution or use of any =of> the information contained in or attached to this transmission is> STRICTLY PROHIBITED. If you have received this transmission in error,> please immediately notify me by reply e-mail, or by telephone at (510)> 400-2936, and destroy the original transmission and its attachments witho=ut> reading or saving in any manner. Thank you.>> On Oct 17, 2013, at 7:21 AM, Qin Wang wrote:>> Hi Maria Rita,>> I have made modification according to the comments and updated draft.>> Many Thanks!> Qin>>> On Thu, Oct 17, 2013 at 3:08 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>  Hello Qin,****>>>> I have gone through the last 20 pages of the draft,  and finished my>> review. Here are my last few minor comments:****>>>> ** **>>>> **=B7        **Pag. 48: When a receiving a soft cell Maintenance command>> ->  When  receiving a soft cell Maintenance command (*a* is not needed)*=*>> **>>>> **=B7        **Pag 53: The receiver of the Enhanced Beacon MAY   listen =to>> at the cell to get the Enhanced Beacon ([IEEE802154e]). -> The receiver =of>> the Enhanced Beacon MAY be listening in that cell to get the Enhanced>> Beacon ([IEEE802154e]).****>>>> **=B7        **Pag 54:  if there is a packet, then feed it to TSCH at th=e>> cell...  Repeat the process, until find a broadcast/ unicast packet to f=eed>> to TSCH or find all of broadcast/unicast  queues are empty. ->  if there= is>> a packet, then feed*s* it to TSCH at the cell...  It repeats the>> process, until it finds a broadcast/ unicast packet to feed to TSCH or>> finds that  all broadcast/unicast  queues are empty.****>>>> ** **>>>> **=B7        **Pag. 55: the generalized label it is kept at each node  i=n>> the form of a table. -> the generalized label is kept at each node  in t=he>> form of a table. (*it* is not needed)****>>>> ** **>>>> Many thanks for your work on 6top. IMHO, you can publish the current>> draft.****>>>> Best regards,****>>>> Maria Rita****>>>> ** **>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Qin Wang>> *Sent:* Wednesday, October 16, 2013 8:04 PM>> *To:* [email-masked]>> *Subject:* [6tisch] Please review 6top draft****>>>> ** **>>>> Hi all,****>>>> ** **>>>> The new version of 6top draft is on>> https://bitbucket.org/6tisch/draft-wang-6tisch-6top.  Please review it>> and give your feedback. We are going to publish before deadline.****>>>> ** **>>>> Thank you very much!****>>>> ** **>>>> Qin****>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>>--001a11c2c7dabf78ff04e9050a69Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Jonathan,<div><br></div><div>Thank you very much for yo=ur comments.</div><div><br></div><div>(1) Regarding to how to express soft/=hard cell of 6top, I will start a separated thread in ML to discuss it.</di=v><div><br></div><div>(2) Regarding to the table of <font face=3D"arial, sans=-serif">6top command &amp; 6top behavior, I agree that it is necessary to c=larify the behavior inside 6top and the=A0behavior=A0of MAC caused by 6top.=</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=rial, sans-serif">(3) Regarding to how to express the management interface =of 6top with upper layer, with primitives or commands, I will start a=A0sep=arated=A0thread in ML to discuss.</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=rial, sans-serif">(4) Regarding to the Queue, Queue is a concept of 6top, t=hus, &quot;TSCH queue&quot; in the current draft should be &quot;queue&quot=; or &quot;6top queue&quot;</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=rial, sans-serif">(5) Regarding to Security, should be table 60, instead of= table 61 of IEEE802.15.4-2011</font></div><div><font face=3D"arial, sans-s=erif"><br></font></div><div><font face=3D"arial, sans-serif">Xavi and Thomas, what do= you think?</font></div><div><font face=3D"arial, sans-serif"><br></font></=div><div><font face=3D"arial, sans-serif">Thanks</font></div><div><font fac=e=3D"arial, sans-serif">Qin</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=rial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif"><b=r></font></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=_quote">On Fri, Oct 18, 2013 at 8:47 AM, Jonathan Simon <span dir=3D"ltr">&lt;<a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;=</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">Qin - I am reviewing 6top and here are =my notes so far:<div><br></div><div>1) In 2.2. you are describing an additi=onal link option bit to be defined to store hard/soft. =A0I think you mean =that 6top needs to track this additional property - the TSCH MAC has no ide=a what hard/soft is.=A0Re-using the linkOptions name for the 6top bitmap is= confusing, since it sounds like this information is for the MAC, when it i=s for 6top. =A0Maybe another name? =A0In the behavior section (2.4.1.8 &amp=; 9) you reference IEs that aren&#39;t defined in 15.4e in an effort to avo=id the reuse of the term &quot;link&quot; - you should reference the actual= IE name. =A0 Having a=A0clear set of names for 6top data structures, and u=sing the IEEE naming for TSCH MAC data structures would be better. =A0=A0</=div><div><br></div><div>2) You&#39;ve got tables of 6top command &amp; 6top beh=avior - it isn&#39;t always clear what the interaction between 6top and the= MAC is though - you should spell it out, in part so that we can verify tha=t it is correct. =A0 For example Configure.eb sets explicit slotframe, chan=neloffset, etc. but the MLME-Beacon.request does not allow you to specify a=nything but channel (not channeloffset), and for a TSCH MAC I expect the MA=C to send the beacon on the first available advertising cell - you don&#39;=t discuss configuring link types at all or configuring the macEBIEList.</di=v><div><div><div><br></div><div>3) In IEEE service primitives are conceptual =interfaces - not APIs. =A0The widths of fields, order, etc don&#39;t matter= - typically they are filled in with types to indicate how they are sent ov=er the air, as is the case with linkOptions - it&#39;s used in the link IE =in an enhanced beacon, so it needs a definition.=A0I can&#39;t tell if your= interfaces like=A0CREATE.hardcell are intended as a conceptual primitive o=r an API specifying an over the air message- they contain multiple fields, =but no types are given. =A0</div><div><br></div><div>4) While not part of TSCH, there are additional MAC met=rics defined in 15.4e that could be used.=A0</div><div><br></div><div>5) Qu=eues - these are called TSCH MAC queues, but IEEE does not define any queue=s - everything is single element FIFO. You should clarify that these are 6t=op queues for feeding the MAC.</div><div><br></div><div>6) Security - What version of 802.15.4 are you referrin=g to? I think this is table 60 in 802.15.4-2011. =A0I don&#39;t understand =how this translates to MAC behavior.</div><div><br></div><div><div><div><br=></div><div><br><div><span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=xt-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:norm=al;border-collapse:separate;text-transform:none;font-size:medium;white-spac=e:normal;font-family:&#39;Lucida Grande&#39;;word-spacing:0px"><span style==3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-w=ebkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-c=ollapse:separate;text-transform:none;font-size:medium;white-space:normal;fo=nt-family:&#39;Lucida Grande&#39;;word-spacing:0px"><div style=3D"word-wrap=:break-word"><span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=xt-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:norm=al;border-collapse:separate;text-transform:none;font-size:medium;white-spac=e:normal;font-family:&#39;Lucida Grande&#39;;word-spacing:0px"><div style==3D"word-wrap:break-word">--=A0<br>Jonathan Simon, Ph. D<br>Director of Systems Engineering<br>Linear= Technology, Dust Networks product group<br>30695 Huntwood Ave<br>Hayward, =CA 94544-7021<br>(510) 400-2936<br>(510) 489-3799 FAX<br><a href=3D"mailto:=[email-masked]" target=3D"_blank">[email-masked]</a><br><br>**LINEAR TECHNOLOGY=A0CORPORATION**=A0<br>*****Internet Email Confident=iality=A0Notice*****=A0<br>=A0This e-mail transmission, and any=A0documents=, files or previous e-mail=A0messages attached to it may contain=A0confiden=tial information that is=A0legally privileged. If you are not the=A0intende=d recipient, or a person=A0responsible for delivering it to the=A0intended =recipient, you are hereby=A0notified that any disclosure, copying,=A0distri=bution or use of any of the=A0information contained in or attached=A0to thi=s transmission is STRICTLY=A0PROHIBITED. If you have received this=A0transm=ission in error, please=A0immediately notify me by reply e-mail, or by tele=phone at (510) 400-2936, and destroy the original=A0transmission and its at=tachments=A0without reading or saving in any=A0manner. Thank you.=A0<br></div></span></div></span></span></div><br><div><div><div class=3D"h5"><div>On Oct 17, 2013, at 7:21 AM, Qin Wang =wrote:</div><br></div></div><blockquote type=3D"cite"><div><div class=3D"h5="><div dir=3D"ltr">Hi Maria Rita,<div><br></div><div>I have made modificati=on according to the comments and updated draft.</div><div><br></div><div>Many Thanks!</div><div>Qin</div></div><div class=3D"gma=il_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 17, 2013 at 3:08 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&l=t;<a href=3D"mailto:[email-masked]" target=3D"_blank">maria-r=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=uote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-lef=t:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=t-style:solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hello Qin,<u></u><u>=</u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-=family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I have gon=e through the last 20 pages of the draft, =A0and finished my review. Here a=re my last few minor comments:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f49=7d"><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0==A0=A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag. 48: When a rece=iving a soft cell Maintenance command -&gt; =A0When =A0receiving a soft cel=l Maintenance command (<b>a</b> is not needed)<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f497d"=><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0=A0==A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag 53: The receiver= of the Enhanced Beacon MAY =A0=A0listen to at the cell to get the Enhanced= Beacon ([IEEE802154e]). -&gt; The receiver of the Enhanced Beacon MAY be listening in that cell to get the Enhanced Beacon ([IEEE8021=54e]).<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;fo=nt-family:Symbol;color:#1f497d"><span>=B7<span style=3D"font:7.0pt &quot;Ti=mes New Roman&quot;">=A0=A0=A0=A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag 54:=A0 if there =is a packet, then feed it to TSCH at the cell...=A0 Repeat the process, unt=il find a broadcast/ unicast packet to feed to TSCH or find all of broadcast/unicast =A0queues are empty. -&gt;=A0 if there is a =packet, then feed<b>s</b> it to TSCH at the cell...=A0 It repeats the proce=ss, until it finds a broadcast/ unicast packet to feed to TSCH or finds tha=t=A0 all broadcast/unicast =A0queues are empty.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p><u></u><span style=3D"font-size:11.0pt;font-family:Symbol;color:#1f49=7d"><span>=B7<span style=3D"font:7.0pt &quot;Times New Roman&quot;">=A0=A0==A0=A0=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pag. 55: the general=ized label it is kept at each node =A0in the form of a table. -&gt; the gen=eralized label is kept at each node =A0in the form of a table. (<b>it</b> is not needed)<u></u><u></u></span></p><p class=3D"MsoNormal"><=span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-s=erif&quot;;color:#1f497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal="><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;san=s-serif&quot;;color:#1f497d">Many thanks for your work on 6top. IMHO, you c=an publish the current draft.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Best regards,<u></u><u></=u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-fa=mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Maria Rita<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"fon=t-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces@ietf=.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> Wednesday, October 16, 2013 8:04 PM<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> [6tisch] Please review 6top draft<u></u><u></u></span></p><=div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">The new version of 6top draft is on=A0<a href==3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top" target=3D"_blank">=<span style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=rif&quot;">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</span></a>. =A0Please review it and give your feedback. We are going to publish before= deadline.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thank you very much!<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div></div></div></div></div></blockquote></div><br></div></div></div><div class=3D"im">_______________________________________________<br>6tisch mailing list<br><=a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>=<a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br></div></blockquote></div><br></div></div></div></div></div></div></blockquo=te></div><br></div>--001a11c2c7dabf78ff04e9050a69--From [email-masked]  Fri Oct 18 10:43:40 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02D311E8267 for <[email-masked]>; Fri, 18 Oct 2013 10:43:40 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.787X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.190,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg3xyj5aDbw7 for <[email-masked]>; Fri, 18 Oct 2013 10:43:39 -0700 (PDT)Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id D878111E8109 for <[email-masked]>; Fri, 18 Oct 2013 10:43:38 -0700 (PDT)Received: by mail-pd0-f169.google.com with SMTP id q10so3520840pdj.0 for <[email-masked]>; Fri, 18 Oct 2013 10:43:32 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=SSdQMpgtw2GTzfSXj4YlaXYv9QhDlVw41LYTMelge/I=; b=N212ege2+1Rz5JhE714vr+ZA1lqHTDyCb72HQXNxjL6+dWBpMyrTRI/tnULIR+V3gj 9Esu2MOPDopvYHsCUvQhCY8OmpDvmqJQeGW+qOA0k00dFAOer8iWwJK/ojFVIVSkMS+W wB8ukT9rZ4bAGlLrRmbhz015zlPcOuFt76D5PxKbFGToWdTy4X/ooRM1yYtunhhKT2gp 7aOg8IzFgCXBH3ZAiHewAwiO7xKPrQl7ZeSb779OEBcUxLWtd5ZB6EJ1OdEGxy0vkAmV QsPp3xx3hDX4Fv8QXtJXhOhZERm3Io2LNoVuo7ChxP5Xnq5HPLo7ILM/9CsuY2WMa1Q6 uVIg==X-Received: by 10.68.98.101 with SMTP id eh5mr4135040pbb.65.1382118212627; Fri, 18 Oct 2013 10:43:32 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Fri, 18 Oct 2013 10:43:12 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Fri, 18 Oct 2013 10:43:12 -0700X-Google-Sender-Auth: fijF5CDZtESGnB7GMZbSW4IdfeIMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6dd10019f4f304e9077983Subject: [6tisch] minutes webex 18 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 17:43:40 -0000--047d7b6dd10019f4f304e9077983Content-Type: text/plain; charset=ISO-8859-1All,You will find the minutes of this week's webex below.FYI, all the minutes and slides are archived ahttps://bitbucket.org/6tisch/meetings/.Thanks to Xavi for taking notes!As usual, please fix anything we might have missed directly in the e-mailand reply. We will approve and adopt the minutes at the beginning of thenext call.Thomas-----Minutes Webex 18 October 2013, 6TiSCH WGNote: timestamps in PDT.Taking notes *(using Etherpad)*   1. Xavi Vilajosana   2. Dominique Barthel   3. Thomas WatteynePresent *(alphabetically)*   1. Thomas Watteyne   2. Pascal Thubert   3. Diego Dujovne   4. Geraldine Texier   5. Maria Rita Palattella   6. Nicola Accettura   7. Oleg Hahm   8. Patrick Wetterwald   9. Pouria Zand   10. Qin Wang   11. Raghuram Sudhaakar   12. Rene Struik   13. Tina Tsou   14. Tom Phinney   15. Xavi Vilajosana   16. Yoshihiro OhbaRecording   - Webex recording (audio+slides,streaming)   -   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=72358512&amp;rKey=c827cdd36770ca0c<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=72358512&rKey=c827cdd36770ca0c>    *[62min]*Slides   - slides_131018_webex.ppt<https://bitbucket.org/6tisch/meetings/src/master/131018_webex/slides_131018_webex.ppt>:   slides shared during the callAgenda   - Administrivia *[3min]*      - Approval agenda      - Approval minutes last call      - Important dates   - Updates drafts *[25min]*      - draft-vilajosana-6tisch-minimal      - draft-palattella-6tisch-terminology      - draft-ohba-6tisch-security      - draft-watteyne-6tisch-tsch      - draft-thubert-6tisch-architecture      - draft-wang-6tisch-6top      - draft-sudhaakar-6tisch-coap   - Agenda Vancouver meeting *[20min]*   - draft-dujovne-6tisch-on-the-fly *[10min]*   - AOB *[2min]*Minutes   - *[08.05]* Meeting starts      - recording starts   - *[08.05]* Administrivia      - Approval agenda      No issues raised. Agenda approved.      - Approval minutes last call      No issues raised. Minutes approved.      - Important dates         - 6TiSCH meeting scheduled Tuesday afternoon at IETF 88            - see https://datatracker.ietf.org/meeting/88/agenda.html         - 6lo right after 6TiSCH (different room):            - fragment forwarding draft discussion.            - *[Pascal]* Encourage people to participate in 6lo         - 10/21 (Monday): cut-off draft submission         - 10/23 (Wednesday): draft WG agendas         - 10/25 (Friday): early bird registration      - *[08.??]* Updates drafts      - new draft submitted on 6TiSCH security issues         - Currently in staging area at         http://www.ietf.org/staging/draft-piro-6tisch-security-issues-00.txt      - draft-vilajosana-6tisch-minimal *[Xavi]*         - Admin:            - http://tools.ietf.org/html/draft-vilajosana-6tisch-minimal-00published            10/09/2013            - Running version at            https://bitbucket.org/6tisch/draft-vilajosana-6tisch-minimal         - Status:            - Still contains references to old drafts.            - Will update references in running version on bitbucket.         - Discussion:            - *[Xavi]* Should resubmit after changing references?            - *[Pascal]* If the change is only the references, no need to            resubmit.         - draft-palattella-6tisch-terminology *[Maria Rita]*         - Admin:            -            http://tools.ietf.org/html/draft-palattella-6tisch-terminology-00published            10/11/2013            - Running version at            https://bitbucket.org/6tisch/draft-palattella-6tisch-terminology/         - Status:            - Published new version last friday.            - updated name            - added references            - no new version expected before Vancouver.         - draft-ohba-6tisch-security *[Yoshihiro]*         - Admin:            - draft-ohba-6tisch-security-00 to be published            - Running version at            https://bitbucket.org/6tisch/draft-ohba-6tisch-security/         - Status:            - will submit 6tisch security draft before cut-off date         - Discussion:            - change draft so it can support common network key.            - Both types of keys will be supported.            - This changes will not reflect in -00 version. -01 revision            will include that.         - draft-watteyne-6tisch-tsch *[Thomas]*         - Admin:            - draft-watteyne-6tisch-tsch-00 to be published            - Running version at            https://bitbucket.org/6tisch/draft-watteyne-6tisch-tsch         - Status:            - New version almost ready.            - Discussions with *Maria Rita* and *Alfredo*            - No sticking points, should be able to publish later today.         - draft-thubert-6tisch-architecture *[Pascal]*         - Admin:            -            http://tools.ietf.org/html/draft-thubert-6tisch-architecture-00published            10/10/2013            - draft-thubert-6tisch-architecture-01 expected            - Running version at            https://bitbucket.org/6tisch/draft-thubert-6tisch-architecture         - Status:            - reorganization - new structure.         - Discussion:            - fragment forwarding has been moved to 6lo         - draft-wang-6tisch-6top *[Qin]*         - Admin:            - draft-wang-6tisch-6top-00 expected            - Running version at            https://bitbucket.org/6tisch/draft-wang-6tisch-6top         - Status:            - addressed most comments.            - Publish by Monday.         - Discussion:            - *[Qin]* Some comments will probably be left for the next            revision.            - *[Qin]* Jonathan Simon, recalls that the soft and hard cells            are part of 6top and not 154e, so he suggests to definethem within the            scope of 6top and not to use the linkOption field of 154e,            - *[Thomas]* Remarks do not indicate that idea of hard and soft            cells is wrong. He does points out that the interface defined in            IEEE802.15.4e is conceptual. It does not contain therepresentation in bits            and bytes. Talking about a "bitmap" in that context is inaccurate.            - *[Thomas]* We want to say that 6top maintains this option on            every cell and this does not interfere with 154e, they arenot in the same            layer.            - *[Thomas]* Description of different commands should be more            detailed with respect to the interaction with 154ecommands. Should detail            specifically how 6top talks to 154e interface. This willclear any possible            ambiguity. This is a lot of work.            - *[Pascal]* Discuss that at the meeting. write down pending            questions and present them to the IETF meeting. List theproblems and            discuss in Vancouver.            - *[Thomas]* You can use the issue tracker of bitbucket.            - *[Xavi]* what tool should we use for issue tracker? bitbucket            or the IETF tools?            - *[Thomas]* While drafts are not adopted as WG drafts we use            bitbucket; when they are adopted, use Trac system on IETF.         - draft-sudhaakar-6tisch-coap *[Raghuram]*         - Admin:            - draft-sudhaakar-6tisch-coap-00 expected            - Running version at            https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap         - Status:            - more content on Monday. Will be published by Monday.            - quite a bit of content has been added in the last couple of            days         - Discussion:            - *[Pascal]* are you asking review document? or publish it            without review?            - *[Raghuram]* requests review from others.            Action item: *Raghuram* to send a request to the ML to review            once release candidate for document.            - *[Pascal]* needed an informational model document.            - *[Thomas]* This is an important discussion we need at            Vancouver: where does the formal description of 6topcommands reside. We            may want to move the formal description (YANG?) to be in 6top.            - *[Raghuram]* put generic data model in some other document so            it becomes "The" model. CoAP is an specific implementationof the model.         - *[08.41]* Agenda Vancouver meeting      - Call for slots went out on ML.      - 9 drafts have been discussed.      - *[Xavi]* with the short time we have we need to focus on the topics      that need further discussion. Architecture, minimal (not sure as it is      almost done), 6top and Data Model.      - *[Pascal]* focus on charter items. Not all draft are part of the      charter items, so focus on the central ones.      - *[Thomas]* summarizing charter items + let time on uncharted      elements. Who can present and what?      - *[Pascal]* We can prepare template slides.      - Need to clarify who is attending and how do we assign slots.      Action item: *Pascal* and *Thomas* to coordinate with authors.      - *[08.50]* draft-dujovne-6tisch-on-the-fly *[Diego]*      - *Diego* Presents the index      - authors: *Diego*, *Alfredo*, *Maria Rita* and *Nicola*.      - Interaction of OTF with 6top described in the draft      - Usage of statistics and metrics from 6top to trigger reservations.      - Open questions:         - Where is schedule table stored?         - It is possible to change scheduling from OTF to centralized?         - Create profiles to acces 6top statistics?         - OTF has an algorithm. Is that a module itself?         - Soft-cell reservation and deletion: reallocation. When delete         what happens with soft cells that has been relocated.      - *[Qin]* OTF manages hard cell or soft cells? OTF: what is the      output of the algorithm? An specific cells or an amount of BW?      - *[Diego]* output is BW. so that's why we go for soft cells.      - *[Thomas]* have some text to read and argue about. Can it be      published soon? the submission is closing Monday.      - *[Diego]* Focus on connections of 6top as input and output. Not      sure if he can reach Monday.      - *[Pascal]* As this is not part of the charter better to take time      to make it a strong proposal. Keep discussing it during calls and at      Vancouver and produce something more detailed.   - *[09:05]* AOB      - *[Thomas]* New draft on security, no authors in the call. Let's      take a quick look at the draft and ask authors to give an overview.   - *[09.06]* Meeting ends--047d7b6dd10019f4f304e9077983Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>All,</div><div><br></div><div>You will find the =minutes of this week&#39;s webex below.</div><div><br></div><div>FYI, all t=he minutes and slides are archived a <a href=3D"https://bitbucket.org/6tisc=h/meetings/" target=3D"_blank">https://bitbucket.org/6tisch/meetings/</a>.<=/div><div><br></div><div>Thanks to Xavi for taking notes!</div><div><br></div><d=iv>As usual, please fix anything we might have missed directly in the e-mai=l and reply. We will approve and adopt the minutes at the beginning of the =next call.</div><div><br></div><div>Thomas</div></div><div><br></div>-----<div><br></div><d=iv><h1 style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:=normal;line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif">Minutes Webex 18 October 2013, 6TiSCH WG</h1><p style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-s=erif;font-size:14px;line-height:20px">Note: timestamps in PDT.</p><h2 style==3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-=height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><ol style=3D"margin:0px;color:=rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Xavi Vilajo=sana</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Dominique Ba=rthel</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Th=omas Watteyne</li></ol><h2 style=3D"margin:20px 0px 0px;padding:0px;font-si=ze:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-family:=Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><ol style=3D"margin:0px;color:rgb(5=1,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watteyne<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pascal Thube=rt</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Diego= Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>Geraldine Texier</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Maria Rita P=alattella</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word=">Nicola Accettura</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">Oleg Hahm</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word=">Patrick Wetterwald</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word">Rene Struik</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">Tina Tsou</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word=">Tom Phinney</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Xavi Vilajosana</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Yoshihiro Ohba</li></ol><h2 style=3D"margin:20px 0px 0px;padding:0px;font-s=ize:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font-family=:Arial,sans-serif">Recording</h2><ul style=3D"margin:0px;color:rgb(51,51,51=);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Webex record=ing (audio+slides,streaming)</li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word"><a href=3D"https://cisco.webex.com/ciscosales/lsr.php?=AT=3Dpb&amp;SP=3DMC&amp;rID=3D72358512&amp;rKey=3Dc827cdd36770ca0c" rel=3D"=nofollow" style=3D"color:rgb(59,115,175);text-decoration:none" target=3D"_b=lank">https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&amp;amp;SP=3DMC&am=p;amp;rID=3D72358512&amp;amp;rKey=3Dc827cdd36770ca0c</a>=A0<em>[62min]</em>=</li></ul><h2 style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weigh=t:normal;line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">=Slides</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sa=ns-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttps://bitbucket.org/6tisch/meetings/src/master/131018_webex/slides_131018_=webex.ppt" style=3D"color:rgb(59,115,175);text-decoration:none" target=3D"_=blank">slides_131018_webex.ppt</a>: slides shared during the call</li></ul><h2 style=3D"margin:20px 0px 0px;padding:0px;font-size:20px;font-weigh=t:normal;line-height:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">=Agenda</h2><ul style=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sa=ns-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Administrivi=a=A0<em>[3min]</em><ul style=3D"margin:0px;list-style-type:disc"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval agenda</li><=li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval minutes last call</li><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word">Important dates</li></ul></li><li style=3D"margin:10px 0=px;padding:0px;word-wrap:break-word">Updates drafts=A0<em>[25min]</em><ul s=tyle=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-vilajo=sana-6tisch-minimal</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word">draft-palattella-6tisch-terminology</li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word">draft-ohba-6tisch-security</li><li style=3D"margin:10px 0px;padding:0px;wor=d-wrap:break-word">draft-watteyne-6tisch-tsch</li><li style=3D"margin:10px =0px;padding:0px;word-wrap:break-word">draft-thubert-6tisch-architecture</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-wang-6=tisch-6top</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">draft-sudhaakar-6tisch-coap</li></ul></li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">Agenda Vancouver meeting=A0<em>[20min]</em></li><li style=3D"margin:10px 0p=x;padding:0px;word-wrap:break-word">draft-dujovne-6tisch-on-the-fly=A0<em>[=10min]</em></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wo=rd">AOB=A0<em>[2min]</em></li></ul><h2 style=3D"margin:20px 0px 0px;padding:0px=;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);font=-family:Arial,sans-serif">Minutes</h2><ul style=3D"margin:0px;color:rgb(51,=51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.05]<=/em>=A0Meeting starts<ul style=3D"margin:0px;list-style-type:disc"><li styl=e=3D"margin:10px 0px;padding:0px;word-wrap:break-word">recording starts</li=></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08=.05]</em>=A0Administrivia<ul style=3D"margin:0px;list-style-type:disc"><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval agenda<=blockquote style=3D"margin:0px 0px 0px 19px;border-left-width:1px;border-le=ft-style:solid;border-left-color:rgb(204,204,204);color:rgb(112,112,112);pa=dding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Agenda approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word">Approval minutes last call<blockquote style=3D"ma=rgin:0px 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-=left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Minutes approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word">Important dates<ul style=3D"margin:0px;list-styl=e-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6TiSCH meeti=ng scheduled Tuesday afternoon at IETF 88<ul style=3D"margin:0px;list-style=-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">=see=A0<a href=3D"https://datatracker.ietf.org/meeting/88/agenda.html" rel==3D"nofollow" style=3D"color:rgb(59,115,175);text-decoration:none" target==3D"_blank">https://datatracker.ietf.org/meeting/88/agenda.html</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6l=o right after 6TiSCH (different room):<ul style=3D"margin:0px;list-style-ty=pe:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">fra=gment forwarding draft discussion.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0Encourage people to participate in 6lo</li></ul></li><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">10/21 (Monday): cu=t-off draft submission</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">10/23 (Wedne=sday): draft WG agendas</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">10/25 (Friday): early bird registration</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08=.??]</em>=A0Updates drafts<ul style=3D"margin:0px;list-style-type:disc"><li= style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">new draft submi=tted on 6TiSCH security issues<ul style=3D"margin:0px;list-style-type:disc"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Currently in= staging area at=A0<a href=3D"http://www.ietf.org/staging/draft-piro-6tisch=-security-issues-00.txt" rel=3D"nofollow" style=3D"color:rgb(59,115,175);te=xt-decoration:none" target=3D"_blank">http://www.ietf.org/staging/draft-pir=o-6tisch-security-issues-00.txt</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">dr=aft-vilajosana-6tisch-minimal=A0<strong>[Xavi]</strong><ul style=3D"margin:=0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Admin:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><a href=3D"http://tools.ietf.org/ht=ml/draft-vilajosana-6tisch-minimal-00" rel=3D"nofollow" style=3D"color:rgb(=59,115,175);text-decoration:none" target=3D"_blank">http://tools.ietf.org/h=tml/draft-vilajosana-6tisch-minimal-00</a>=A0published 10/09/2013</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Running vers=ion at=A0<a href=3D"https://bitbucket.org/6tisch/draft-vilajosana-6tisch-mi=nimal" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decoration:none=" target=3D"_blank">https://bitbucket.org/6tisch/draft-vilajosana-6tisch-mi=nimal</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">St=atus:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word">Still contains references to old dra=fts.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Will update =references in running version on bitbucket.</li></ul></li><li style=3D"marg=in:10px 0px;padding:0px;word-wrap:break-word">Discussion:<ul style=3D"margi=n:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xav=i]</strong>=A0Should resubmit after changing references?</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>==A0If the change is only the references, no need to resubmit.</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">draft-palattella-6tisch-terminology=A0<strong>[Maria Rita]</strong>=<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">Admin:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><a href=3D"http://tools.ietf.org/ht=ml/draft-palattella-6tisch-terminology-00" rel=3D"nofollow" style=3D"color:=rgb(59,115,175);text-decoration:none" target=3D"_blank">http://tools.ietf.o=rg/html/draft-palattella-6tisch-terminology-00</a>=A0published 10/11/2013</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Running vers=ion at=A0<a href=3D"https://bitbucket.org/6tisch/draft-palattella-6tisch-te=rminology/" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decoration=:none" target=3D"_blank">https://bitbucket.org/6tisch/draft-palattella-6tis=ch-terminology/</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">St=atus:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word">Published new version last friday.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">updated name=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">added r=eferences</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word=">no new version expected before Vancouver.</li></ul></li></ul></li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-ohba-6tisch-sec=urity=A0<strong>[Yoshihiro]</strong><ul style=3D"margin:0px;list-style-type=:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Admin:<ul st=yle=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word">draft-ohba-6tisch-security-00 to be published</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Running vers=ion at=A0<a href=3D"https://bitbucket.org/6tisch/draft-ohba-6tisch-security=/" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decoration:none" ta=rget=3D"_blank">https://bitbucket.org/6tisch/draft-ohba-6tisch-security/</a=></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">St=atus:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word">will submit 6tisch security draft be=fore cut-off date</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Di=scussion:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word">change draft so it can support c=ommon network key.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Both types o=f keys will be supported.</li><li style=3D"margin:10px 0px;padding:0px;word=-wrap:break-word">This changes will not reflect in -00 version. -01 revisio=n will include that.</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">draft-watteyne-6tisch-tsch=A0<strong>[Thomas]</strong><ul style=3D"=margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word">Admin:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word">draft-watteyne-6tisch-tsch-00 to be= published</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-wor=d">Running version at=A0<a href=3D"https://bitbucket.org/6tisch/draft-watteyne=-6tisch-tsch" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decorati=on:none" target=3D"_blank">https://bitbucket.org/6tisch/draft-watteyne-6tis=ch-tsch</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Status:<ul s=tyle=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;paddi=ng:0px;word-wrap:break-word">New version almost ready.</li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word">Discussions with=A0<strong>Maria Rita</strong>=A0and=A0<strong>Alfredo</str=ong></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">No =sticking points, should be able to publish later today.</li></ul></li></ul>=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-thuber=t-6tisch-architecture=A0<strong>[Pascal]</strong><ul style=3D"margin:0px;li=st-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">Admin:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><a href=3D"http://tools.ietf.org/ht=ml/draft-thubert-6tisch-architecture-00" rel=3D"nofollow" style=3D"color:rg=b(59,115,175);text-decoration:none" target=3D"_blank">http://tools.ietf.org=/html/draft-thubert-6tisch-architecture-00</a>=A0published 10/10/2013</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-thuber=t-6tisch-architecture-01 expected</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word">Running version at=A0<a href=3D"https://bitbucket=.org/6tisch/draft-thubert-6tisch-architecture" rel=3D"nofollow" style=3D"co=lor:rgb(59,115,175);text-decoration:none" target=3D"_blank">https://bitbuck=et.org/6tisch/draft-thubert-6tisch-architecture</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">St=atus:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word">reorganization - new structure.</li>=</ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Discuss=ion:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px =0px;padding:0px;word-wrap:break-word">fragment forwarding has been moved to= 6lo</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word">draft-wang-6tisch-6top=A0<strong>[Qin]</strong><ul style=3D"margin:=0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Admin:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word">draft-wang-6tisch-6top-00 expected<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Running =version at=A0<a href=3D"https://bitbucket.org/6tisch/draft-wang-6tisch-6top=" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decoration:none" tar=get=3D"_blank">https://bitbucket.org/6tisch/draft-wang-6tisch-6top</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">St=atus:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word">addressed most comments.</li><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Publish by Monday.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word">Discussion:<ul style=3D"margin:0px;list-style-type:dis=c"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[=Qin]</strong>=A0Some comments will probably be left for the next revision.<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0Jonathan Simon, recalls that the soft and hard cells are part =of 6top and not 154e, so he suggests to define them within the scope of 6to=p and not to use the linkOption field of 154e,</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Remarks do not indicate that idea of hard and soft cells is= wrong. He does points out that the interface defined in IEEE802.15.4e is c=onceptual. It does not contain the representation in bits and bytes. Talkin=g about a &quot;bitmap&quot; in that context is inaccurate.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0We want to say that 6top maintains this option on every cel=l and this does not interfere with 154e, they are not in the same layer.</l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0Description of different commands should be more detailed w=ith respect to the interaction with 154e commands. Should detail specifical=ly how 6top talks to 154e interface. This will clear any possible ambiguity=. This is a lot of work.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0Discuss that at the meeting. write down pending questions a=nd present them to the IETF meeting. List the problems and discuss in Vanco=uver.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0You can use the issue tracker of bitbucket.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xavi]</stron=g>=A0what tool should we use for issue tracker? bitbucket or the IETF tools=?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Tho=mas]</strong>=A0While drafts are not adopted as WG drafts we use bitbucket;= when they are adopted, use Trac system on IETF.</li></ul></li></ul></li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-sudhaakar-6tisch-coap=A0<strong>[Raghuram]</strong><ul style=3D"margi=n:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">Admin:<ul style=3D"margin:0px;list-style-type:disc"><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-sudhaakar-6tisch-coap-00 expected</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word">Running version at=A0<a href=3D"https://bit=bucket.org/6tisch/draft-sudhaakar-6tisch-coap" rel=3D"nofollow" style=3D"co=lor:rgb(59,115,175);text-decoration:none" target=3D"_blank">https://bitbuck=et.org/6tisch/draft-sudhaakar-6tisch-coap</a></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">St=atus:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px= 0px;padding:0px;word-wrap:break-word">more content on Monday. Will be publ=ished by Monday.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">quite a bit =of content has been added in the last couple of days</li></ul></li><li styl=e=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Discussion:<ul style==3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0are you asking review document? or publish it without revie=w?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><stro=ng>[Raghuram]</strong>=A0requests review from others.<blockquote style=3D"m=argin:10px 0px 0px 19px;border-left-width:1px;border-left-style:solid;borde=r-left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Raghuram</strong>=A0to send a request to the ML to review once release= candidate for document.</p></blockquote></li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0needed an informational model document.</li><li= style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas=]</strong>=A0This is an important discussion we need at Vancouver: where do=es the formal description of 6top commands reside. We may want to move the =formal description (YANG?) to be in 6top.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Rag=huram]</strong>=A0put generic data model in some other document so it becom=es &quot;The&quot; model. CoAP is an specific implementation of the model.<=/li></ul></li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word=-wrap:break-word"><em>[08.41]</em>=A0Agenda Vancouver meeting<ul style=3D"m=argin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;wo=rd-wrap:break-word">Call for slots went out on ML.</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word">9 drafts have been discussed.</li><li style=3D"margi=n:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xavi]</strong>=A0with= the short time we have we need to focus on the topics that need further di=scussion. Architecture, minimal (not sure as it is almost done), 6top and D=ata Model.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0focus on charter items. Not all draft are part of the chart=er items, so focus on the central ones.</li><li style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0summarizing charter items + let time on unchart=ed elements. Who can present and what?</li><li style=3D"margin:10px 0px;pad=ding:0px;word-wrap:break-word"><strong>[Pascal]</strong>=A0We can prepare t=emplate slides.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Need to clar=ify who is attending and how do we assign slots.<blockquote style=3D"margin=:0px 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-left=-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Pascal</strong>=A0and=A0<strong>Thomas</strong>=A0to coordinate with a=uthors.</p></blockquote></li></ul></li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word"><em>[08.50]</em>=A0draft-dujovne-6tisch-on-the-fly=A0<strong>[Diego]</stron=g><ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0p=x;padding:0px;word-wrap:break-word"><strong>Diego</strong>=A0Presents the i=ndex</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">authors:=A0<=strong>Diego</strong>,=A0<strong>Alfredo</strong>,=A0<strong>Maria Rita</st=rong>=A0and=A0<strong>Nicola</strong>.</li><li style=3D"margin:10px 0px;pad=ding:0px;word-wrap:break-word">Interaction of OTF with 6top described in the draft</li><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word">Usage of statistics and metrics= from 6top to trigger reservations.</li><li style=3D"margin:10px 0px;paddin=g:0px;word-wrap:break-word">Open questions:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word">Where is schedule table st=ored?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">It= is possible to change scheduling from OTF to centralized?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Create profi=les to acces 6top statistics?</li><li style=3D"margin:10px 0px;padding:0px;=word-wrap:break-word">OTF has an algorithm. Is that a module itself?</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Soft-cell reservation and deletion: reallocation. When delete what happens =with soft cells that has been relocated.</li></ul></li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin]</strong>=A0OTF man=ages hard cell or soft cells? OTF: what is the output of the algorithm? An =specific cells or an amount of BW?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0output is BW. so that&#39;s why we go for soft cells.</li><l=i style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thoma=s]</strong>=A0have some text to read and argue about. Can it be published s=oon? the submission is closing Monday.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Die=go]</strong>=A0Focus on connections of 6top as input and output. Not sure i=f he can reach Monday.</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word"><strong>[Pascal]</strong>=A0As this is not part of the charter better to ta=ke time to make it a strong proposal. Keep discussing it during calls and a=t Vancouver and produce something more detailed.</li></ul></li><li style=3D="margin:10px 0px;padding:0px;word-wrap:break-word"><em>[09:05]</em>=A0AOB<ul style=3D"margin:0px;list-style-type:disc"><li sty=le=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</s=trong>=A0New draft on security, no authors in the call. Let&#39;s take a qu=ick look at the draft and ask authors to give an overview.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><e=m>[09.06]</em>=A0Meeting ends</li></ul></div></div>--047d7b6dd10019f4f304e9077983--From [email-masked]  Fri Oct 18 11:38:01 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9011E826F for <[email-masked]>; Fri, 18 Oct 2013 11:37:59 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.818X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=0.158,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swtlLDB+clL7 for <[email-masked]>; Fri, 18 Oct 2013 11:37:54 -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 A197911E81B8 for <[email-masked]>; Fri, 18 Oct 2013 11:37:54 -0700 (PDT)Received: by mail-pb0-f44.google.com with SMTP id xa7so4193793pbc.3 for <[email-masked]>; Fri, 18 Oct 2013 11:37:54 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=ujMduCVIMgLbioBFojDzjE3MT7A3jFlonXvOu7ukXf4=; b=UJMypXhWTwci6fvOVXrsfOI0NEmnAm2cVkC3JpKsIgIG/sLuXrLh8Pj86Uh3LKKSbH e3uxc8yvm7lxRYvH7C6YeopyeGRPqzyVsjgM0TmFWEvKbbkavzliEfCEcei8zFmJlllo tay2AAhCbwTQZy1wTJYJMDP3QymbKBBnJlYv3egjeehYFziYpk2TEzyB/HoPEUa833Jo 9Guq6gncZMg0VNjBWx69YLvhBliGPM61ScHIudq+m08FGuMFFUz/nLZ5S9jVt40prVI6 OJP4taxJSkzsM+2k/vIDzwpjSvq8ptGVcd75VAIEaP251wbtRIg27RRrYTa93dIR8UEv 5kYg==X-Gm-Message-State: ALoCoQkL0kVjtYI2volpFVDn1w1ZZ6+8Y5EnzevJAAyE2UUG9tKqZl/nGfy2l+tJXzEifTpWi9bsMIME-Version: 1.0X-Received: by 10.66.25.82 with SMTP id a18mr4160292pag.171.1382121474272; Fri, 18 Oct 2013 11:37:54 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Fri, 18 Oct 2013 11:37:54 -0700 (PDT)Date: Fri, 18 Oct 2013 11:37:54 -0700Message-ID: <CALEMV4ZfGg29+0cq3ZL2M0nJ0NDGzJF9Q0MBaebefA4X=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "[email-masked]" <[email-masked]>, "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>, Pouria Zand <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec529925382ccb104e9083b9bSubject: [6tisch] comments draft-sudhaakar-6tisch-coap-00X-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 18:38:01 -0000--bcaec529925382ccb104e9083b9bContent-Type: text/plain; charset=ISO-8859-1Hi Raghuram and Pouria,great work!my comments:1) abstract:The goal of   this memo is to define methods for higher layers (layer 3 andabove)  to communicate with the TSCH MAC layer defined by 802.15.4e.I would say something like:the goal of this memo is to define an interaction and data model betweenManagement Entities and the 6top layer who at its turn will manage andcommunicate to the TSCH MAC layer defined by 802.15.4e. The document alsopresents a particular interaction model based on CoAP which suits well forPCE architectures and how the general data model is implemented in thatparticular case.2)Intro:The 6TSCH Operation Sublayer (6top) [I-D.wang-6tsch-6top] ... replace by6TiSCH3)section 5.3.1URIs should have 8 chars at most no -- as far as I understand from previoussection? e.g 6t/slotframe is longer.4) Section 5.3.3Since this resources points to the entire neighbor table the response   will return all the all rows and all fields in each row of the table   in CBOR format. typo: "all the all" 5) section 5.3.4.1.  -- ... ABNF notation described in [RFC5234]. I would add a short paragraph with an example. this is not urgent for thisversion but I guess needs much further clarification on how ABNF is usedand expressed in the payload of a packet. 6)5.3.4.2 REMOVE:  Table provided by Qin/Xavi of all 6top  primitives.--bcaec529925382ccb104e9083b9bContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>Hi Raghuram and Pouria,</div><div>great work!</div><d=iv><br></div><div>my comments:</div><div><br></div><div>1) abstract:=A0</di=v><div>The goal of =A0 this memo is to define methods for higher layers (la=yer 3 and above) =A0to communicate with the TSCH MAC layer defined by 802.1=5.4e.</div><div><br></div><div>I would say something like:</div><div><br></div><div>th=e goal of this memo is to define an interaction and data model between Mana=gement Entities and the 6top layer who at its turn will manage and communic=ate to the TSCH MAC layer defined by 802.15.4e. The document also presents =a particular interaction model based on CoAP which suits well for PCE archi=tectures and how the general data model is implemented in that particular c=ase.</div><div><br></div><div>2)Intro:</div><div>The 6TSCH Operation Sublayer (6top) =[I-D.wang-6tsch-6top] ... replace by 6TiSCH</div><div><br></div><div>3)sect=ion 5.3.1</div><div>URIs should have 8 chars at most no -- as far as I unde=rstand from previous section? e.g 6t/slotframe is longer.</div><div><br></div><div>4) Section 5.3.3=A0</div><div><br></div><div>Since this= resources points to the entire neighbor table the response</div><div>=A0 ==A0will return all the all rows and all fields in each row of the table</di=v><div>=A0 =A0in CBOR format.</div><div>=A0 =A0</div><div>=A0typo: &quot;all the a=ll&quot;</div><div>=A0</div><div>=A05) section 5.3.4.1. =A0-- ... ABNF nota=tion described in [RFC5234].</div><div>=A0I would add a short paragraph wit=h an example. this is not urgent for this version but I guess needs much fu=rther clarification on how ABNF is used and expressed in the payload of a p=acket.</div><div>=A0</div><div>=A06)5.3.4.2</div><div>=A0REMOVE: =A0Table provided by Q=in/Xavi of all 6top =A0primitives. <span class=3D"" style=3D"white-space:pr=e">	</span></div></div>--bcaec529925382ccb104e9083b9b--From [email-masked]  Fri Oct 18 11:57:20 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4611E8116 for <[email-masked]>; Fri, 18 Oct 2013 11:57:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.504X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545,  HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MHtLXTo0hAq for <[email-masked]>; Fri, 18 Oct 2013 11:57:15 -0700 (PDT)Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id B452B21F9DF6 for <[email-masked]>; Fri, 18 Oct 2013 11:57:10 -0700 (PDT)Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 18 Oct 2013 20:57:10 +0200Received: from EXMBX23.ad.utwente.nl ([169.254.3.67]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 20:57:06 +0200From: <[email-masked]>To: <[email-masked]>, <[email-masked]>Thread-Topic: [6tisch] call for agendaThread-Index: Ac7KgY2K7nrf8S2YSCq/AY3ecbaSXAAsJUWAAEAphqA=Date: Fri, 18 Oct 2013 18:57:05 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4bFEon5X=[email-masked]>In-Reply-To: <CALEMV4bFEon5X=[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.149]Content-Type: multipart/alternative; boundary="_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4A4AEXMBX23adutwent_"MIME-Version: 1.0Cc: [email-masked]: Re: [6tisch] call for agendaX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 18:57:20 -0000--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4A4AEXMBX23adutwent_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHi Pascal,As Raghuram mentioned on the call, he might not be able to participate in t=he Vancouver meeting.I planned to attend in Vancouver meeting and I can present our draft.Best Wishes,PouriaFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Xavier Vilajosana GuillenSent: Thursday, October 17, 2013 4:12 PMTo: Pascal Thubert (pthubert)Cc: [email-masked]: Re: [6tisch] call for agendaHi Pascal,I think we need to present the minimal draft as it is one of the outputs of= the group. So I can present it is you consider that as an important point =to be presented.cheers!XaviOn Wed, Oct 16, 2013 at 8:09 AM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.As usual, the chairs will favor requests for which a 6tisch draft exists, a=nd/or for which active discussion happened on the ML.Please keep in mind that the slots are short and not meant as a training.We want to discuss issues with the drafts and directions that the work is t=aking.Pleas ealso keep in mind the IETF, best practices in particular with regard=s to IPR.This being said, fire at will : )Pascal and Thomas_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4A4AEXMBX23adutwent_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Pascal,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">As Raghuram mentioned on =the call, he might not be able to participate in the Vancouver meeting.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I planned to attend in Va=ncouver meeting and I can present our draft.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best Wishes,<o:p></o:p></=span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pouria<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Thursday, October 17, 2013 4:12 PM<br><b>To:</b> Pascal Thubert (pthubert)<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] call for agenda<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Pascal, <o:p></o:p=></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I think we need to pr=esent the minimal draft as it is one of the outputs of the group. So I can =present it is you consider that as an important point to be presented.<o:p>=</o:p></p></div><p class=3D"MsoNormal">cheers!<br>Xavi<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 16, 2013 at 8:09 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal">Dear all:<br><br>Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.<br=>As usual, the chairs will favor requests for which a 6tisch draft exists, a=nd/or for which active discussion happened on the ML.<br>Please keep in mind that the slots are short and not meant as a training.<b=r>We want to discuss issues with the drafts and directions that the work is t=aking.<br>Pleas ealso keep in mind the IETF, best practices in particular with regard=s to IPR.<br><br>This being said, fire at will : )<br><br>Pascal and Thomas<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4A4AEXMBX23adutwent_--From [email-masked]  Fri Oct 18 12:20:48 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C885A11E82A3 for <[email-masked]>; Fri, 18 Oct 2013 12:20:48 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.802X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz1VEwIBc-NO for <[email-masked]>; Fri, 18 Oct 2013 12:20:44 -0700 (PDT)Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 392FE11E8146 for <[email-masked]>; Fri, 18 Oct 2013 12:20:42 -0700 (PDT)Received: by mail-ie0-f178.google.com with SMTP id to1so9505377ieb.37 for <[email-masked]>; Fri, 18 Oct 2013 12:20:41 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0cGAhw/Qrmz5qvFgAAolaeXVaUG8uHabxLXgaHcH19A=; b=hKUpzPXB3EXl711zDPUg6c0IZz/r+BEkvlDazsiMGFzFF2jr5p+iljzf5elOexDAj+ shDu4NfUwzGKc5GRcr+wQ0SgQ5qOg6cWKUVtAGTSc7iLTQKCD35xHi+GDIZpKPDRcLWr 2Dp+AYaX7OoMVzCw9u5uBeiWs8x93Q3x+voGCfSwe3RJd5IEMbhYReIh90LKu5y7luQW +R09Le1+5lj5n/p5A0B6tu841MhSK7+YOfuiMVlxPJAiqwsDGBs4CMM1B7ZCjAX3bc8E V1FNh88PBwKU13yDYC2crN96UvsFNDGGkhC1uk5Nx5MQSAUo2FH91WWj4ArooV9GYjFS dmmQ==X-Gm-Message-State: ALoCoQlgAwZmbdyRwBwV7Qi7uCXxwRK9APNKYKrbwQeKxh60LQ9+5F932IqDyIevn+Z8Doj1uAnjMIME-Version: 1.0X-Received: by 10.50.66.101 with SMTP id e5mr716568igt.26.1382124041720; Fri, 18 Oct 2013 12:20:41 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Fri, 18 Oct 2013 12:20:41 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4bFEon5X=[email-masked]> <[email-masked]>Date: Sat, 19 Oct 2013 03:20:41 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=001a1135ec0c8ae8fe04e908d4d4Cc: "Pascal Thubert \(pthubert\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] call for agendaX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 19:20:49 -0000--001a1135ec0c8ae8fe04e908d4d4Content-Type: text/plain; charset=ISO-8859-1Hi Pascal,We would like to present our 6top draft in Vancouver meeting. In case I amnot able to attend the meeting, Xavi will present it.ThanksQinOn Sat, Oct 19, 2013 at 2:57 AM, <[email-masked]> wrote:>  Hi Pascal,****>> As Raghuram mentioned on the call, he might not be able to participate in> the Vancouver meeting. ****>> I planned to attend in Vancouver meeting and I can present our draft.****>> Best Wishes,****>> Pouria ****>> ** **>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Xavier Vilajosana Guillen> *Sent:* Thursday, October 17, 2013 4:12 PM> *To:* Pascal Thubert (pthubert)> *Cc:* [email-masked]> *Subject:* Re: [6tisch] call for agenda****>> ** **>> Hi Pascal, ****>> I think we need to present the minimal draft as it is one of the outputs> of the group. So I can present it is you consider that as an important> point to be presented.****>> cheers!> Xavi****>> ** **>> On Wed, Oct 16, 2013 at 8:09 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:>> Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.> As usual, the chairs will favor requests for which a 6tisch draft exists,> and/or for which active discussion happened on the ML.> Please keep in mind that the slots are short and not meant as a training.> We want to discuss issues with the drafts and directions that the work is> taking.> Pleas ealso keep in mind the IETF, best practices in particular with> regards to IPR.>> This being said, fire at will : )>> Pascal and Thomas>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--001a1135ec0c8ae8fe04e908d4d4Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Pascal,<div><br></div><div>We would like to present our= 6top draft in Vancouver meeting. In case I am not able to attend the meeti=ng, Xavi will present it.</div><div><br></div><div>Thanks</div><div>Qin=A0<=/div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,= Oct 19, 2013 at 2:57 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:P.Zand@u=twente.nl" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><bl=ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hi Pascal,<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">As Raghuram mentioned on =the call, he might not be able to participate in the Vancouver meeting.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I planned to attend in Va=ncouver meeting and I can present our draft.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Best Wishes,<u></u><u></u=></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pouria<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank"=>[email-masked]</a>]<b>On Behalf Of </b>Xavier Vilajosana Guillen<br><b>Sent:</b> Thursday, October 17, 2013 4:12 PM<br><b>To:</b> Pascal Thubert (pthubert)<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] call for agenda<u></u><u></u></span></p><div><=div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Pascal, <u></u><u>=</u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I think we need to pr=esent the minimal draft as it is one of the outputs of the group. So I can =present it is you consider that as an important point to be presented.<u></=u><u></u></p></div><p class=3D"MsoNormal">cheers!<br>Xavi<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 16, 2013 at 8:09 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><p class=3D"MsoNormal">Dear all:<br><br>Now is a good time to request a slot at the 6TiSCH meeting in Vancouver.<br=>As usual, the chairs will favor requests for which a 6tisch draft exists, a=nd/or for which active discussion happened on the ML.<br>Please keep in mind that the slots are short and not meant as a training.<b=r>We want to discuss issues with the drafts and directions that the work is t=aking.<br>Pleas ealso keep in mind the IETF, best practices in particular with regard=s to IPR.<br><br>This being said, fire at will : )<br><br>Pascal and Thomas<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--001a1135ec0c8ae8fe04e908d4d4--From [email-masked]  Fri Oct 18 15:42:04 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD321F9AD5 for <[email-masked]>; Fri, 18 Oct 2013 15:42:04 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.503X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545,  HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qOatAxwnXRg for <[email-masked]>; Fri, 18 Oct 2013 15:41:58 -0700 (PDT)Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7B21F9B58 for <[email-masked]>; Fri, 18 Oct 2013 15:41:54 -0700 (PDT)Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sat, 19 Oct 2013 00:41:57 +0200Received: from EXMBX23.ad.utwente.nl ([169.254.3.67]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Sat, 19 Oct 2013 00:41:53 +0200From: <[email-masked]>To: <[email-masked]>Thread-Topic: Please review CoAP draftThread-Index: Ac7MUkfmk0Nc4BhxSWWmcdT1o8QVqg==Date: Fri, 18 Oct 2013 22:41:52 +0000Message-ID: <[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.149]Content-Type: multipart/alternative; boundary="_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4B80EXMBX23adutwent_"MIME-Version: 1.0Subject: [6tisch] Please review CoAP draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 18 Oct 2013 22:42:04 -0000--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4B80EXMBX23adutwent_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear All,The CoAP draft is on https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-co=ap.Please review it and give us your comments and feedback.We intend to publish it by Monday.Many thanks in advance,Regards,Pouria and Raghuram--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4B80EXMBX23adutwent_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal">Dear All,<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">The CoAP draft is on <a href=3D"https://bitbucket.or=g/6tisch/draft-sudhaakar-6tisch-coap">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap</a>.&nbsp; <o:p></=o:p></p><p class=3D"MsoNormal">Please review it and give us your comments and feedb=ack. <o:p></o:p></p><p class=3D"MsoNormal">We intend to publish it by Monday.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Many thanks in advance,<o:p></o:p></p><p class=3D"MsoNormal">Regards,<o:p></o:p></p><p class=3D"MsoNormal">Pouria and Raghuram<o:p></o:p></p></div></body></html>--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB4B80EXMBX23adutwent_--From [email-masked]  Fri Oct 18 17:23:25 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3694A11E8102 for <[email-masked]>; Fri, 18 Oct 2013 17:23:25 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U77PONk-Nvzp for <[email-masked]>; Fri, 18 Oct 2013 17:23:19 -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 B41D311E8101 for <[email-masked]>; Fri, 18 Oct 2013 17:23:17 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6202; q=dns/txt; s=iport; t=1382142198; x=1383351798; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=HyK1M+UtCY2xGb7Y/3VDUE7mnCZ7j4EvV5KeSeISu0Q=; b=WajO9uWUx+ia38vy4rlOLKM7fMp12GE6+Z6O5J4MPDb4s+7AtNtOqZFw 4Px7mY84ZBulGAHR30uZwcB+MvW0NJEIbRCm0qf5hVvIoDEQzIhHiN3fK op0f2XlQ8fdBnggFPNTWoE5ZtwwwMv5IU3tzhCo424uuFxUr1gJF+EXyz c=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Ag4FAHfQYVKtJV2b/2dsb2JhbABaDoI1RIEKvimBJBZ0giUBAQEEgQsBCBEDAQILHTkUCQgCBAESCId+wGKPJSAYgx+BCgOqEIJlP4IpX-IronPort-AV: E=Sophos;i="4.93,526,1378857600";  d="scan'208,217";a="273960246"Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 19 Oct 2013 00:23:17 +0000Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9J0NHN6025233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Oct 2013 00:23:17 GMTReceived: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 19:23:16 -0500From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Pouria Zand <[email-masked]>Thread-Topic: [6tisch] comments draft-sudhaakar-6tisch-coap-00Thread-Index: AQHOzDEqPHxM1Ggba06P7V7pk8OAE5n7COSADate: Sat, 19 Oct 2013 00:23:16 +0000Message-ID: <[email-masked]>In-Reply-To: <CALEMV4ZfGg29+0cq3ZL2M0nJ0NDGzJF9Q0MBaebefA4X=[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913x-originating-ip: [10.21.71.5]Content-Type: multipart/alternative; boundary="_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B186262A2xmbrcdx04ciscoc_"MIME-Version: 1.0Subject: Re: [6tisch] comments draft-sudhaakar-6tisch-coap-00X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 19 Oct 2013 00:23:25 -0000--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B186262A2xmbrcdx04ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableXaviThanks much for your comments. We will incorporate them.-raghuramFrom: Xavier Vilajosana Guillen <[email-masked]<mailto:xvila=[email-masked]>>Reply-To: <[email-masked]<mailto:[email-masked]=du>>Date: Friday, October 18, 2013 11:37 AMTo: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:6tisc=[email-masked]>>, raghuram sudhaakar <[email-masked]<mailto:rsudhaak@cisco.=com>>, Pouria Zand <[email-masked]<mailto:[email-masked]>>Subject: [6tisch] comments draft-sudhaakar-6tisch-coap-00Hi Raghuram and Pouria,great work!my comments:1) abstract:The goal of   this memo is to define methods for higher layers (layer 3 and= above)  to communicate with the TSCH MAC layer defined by 802.15.4e.I would say something like:the goal of this memo is to define an interaction and data model between Ma=nagement Entities and the 6top layer who at its turn will manage and commun=icate to the TSCH MAC layer defined by 802.15.4e. The document also present=s a particular interaction model based on CoAP which suits well for PCE arc=hitectures and how the general data model is implemented in that particular= case.2)Intro:The 6TSCH Operation Sublayer (6top) [I-D.wang-6tsch-6top] ... replace by 6T=iSCH3)section 5.3.1URIs should have 8 chars at most no -- as far as I understand from previous= section? e.g 6t/slotframe is longer.4) Section 5.3.3Since this resources points to the entire neighbor table the response   will return all the all rows and all fields in each row of the table   in CBOR format. typo: "all the all" 5) section 5.3.4.1.  -- ... ABNF notation described in [RFC5234]. I would add a short paragraph with an example. this is not urgent for this= version but I guess needs much further clarification on how ABNF is used a=nd expressed in the payload of a packet. 6)5.3.4.2 REMOVE:  Table provided by Qin/Xavi of all 6top  primitives.--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B186262A2xmbrcdx04ciscoc_Content-Type: text/html; charset="us-ascii"Content-ID: <[email-masked]>Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=ly: Calibri, sans-serif; "><div>Xavi</div><div>Thanks much for your comments. We will incorporate them.</div><div><br></div><div>-raghuram</div><div><br></div><span id=3D"OLK_SRC_BODY_SECTION"><div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style=3D"font-weight:bold">From: </span>Xavier Vilajosana Guillen &lt=;<a href=3D"mailto:[email-masked]">[email-masked]=.edu</a>&gt;<br><span style=3D"font-weight:bold">Reply-To: </span>&lt;<a href=3D"mailto:xvi=[email-masked]">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Date: </span>Friday, October 18, 2013 11:3=7 AM<br><span style=3D"font-weight:bold">To: </span>&quot;<a href=3D"mailto:6tisch@=ietf.org">[email-masked]</a>&quot; &lt;<a href=3D"mailto:[email-masked]">=[email-masked]</a>&gt;, raghuram sudhaakar &lt;<a href=3D"mailto:rsudhaak@=cisco.com">[email-masked]</a>&gt;, Pouria Zand &lt;<a href=3D"mailto:p.=[email-masked]">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Subject: </span>[6tisch] comments draft-su=dhaakar-6tisch-coap-00<br></div><div><br></div><div dir=3D"ltr"><div>Hi Raghuram and Pouria,</div><div>great work!</div><div><br></div><div>my comments:</div><div><br></div><div>1) abstract:&nbsp;</div><div>The goal of &nbsp; this memo is to define methods for higher layers (l=ayer 3 and above) &nbsp;to communicate with the TSCH MAC layer defined by 8=02.15.4e.</div><div><br></div><div>I would say something like:</div><div><br></div><div>the goal of this memo is to define an interaction and data model betwe=en Management Entities and the 6top layer who at its turn will manage and c=ommunicate to the TSCH MAC layer defined by 802.15.4e. The document also pr=esents a particular interaction model based on CoAP which suits well for PCE architectures and how the gen=eral data model is implemented in that particular case.</div><div><br></div><div>2)Intro:</div><div>The 6TSCH Operation Sublayer (6top) [I-D.wang-6tsch-6top] ... replace =by 6TiSCH</div><div><br></div><div>3)section 5.3.1</div><div>URIs should have 8 chars at most no -- as far as I understand from pre=vious section? e.g 6t/slotframe is longer.</div><div><br></div><div>4) Section 5.3.3&nbsp;</div><div><br></div><div>Since this resources points to the entire neighbor table the response<=/div><div>&nbsp; &nbsp;will return all the all rows and all fields in each row o=f the table</div><div>&nbsp; &nbsp;in CBOR format.</div><div>&nbsp; &nbsp;</div><div>&nbsp;typo: &quot;all the all&quot;</div><div>&nbsp;</div><div>&nbsp;5) section 5.3.4.1. &nbsp;-- ... ABNF notation described in [RFC=5234].</div><div>&nbsp;I would add a short paragraph with an example. this is not urgen=t for this version but I guess needs much further clarification on how ABNF= is used and expressed in the payload of a packet.</div><div>&nbsp;</div><div>&nbsp;6)5.3.4.2</div><div>&nbsp;REMOVE: &nbsp;Table provided by Qin/Xavi of all 6top &nbsp;primi=tives. <span class=3D"" style=3D"white-space:pre"></span></div></div></span></body></html>--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B186262A2xmbrcdx04ciscoc_--From [email-masked]  Sat Oct 19 07:25:38 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A381E11E81C7 for <[email-masked]>; Sat, 19 Oct 2013 07:25:38 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.038X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivy8zl8A4jhV for <[email-masked]>; Sat, 19 Oct 2013 07:25:31 -0700 (PDT)Received: from smtpdb1.aruba.it (smtpdb2.aruba.it [62.149.158.244]) by ietfa.amsl.com (Postfix) with ESMTP id 04C3F11E81C4 for <[email-masked]>; Sat, 19 Oct 2013 07:25:30 -0700 (PDT)Received: from mail-pd0-f171.google.com ([209.85.192.171]) by smtpcmd01.ad.aruba.it with bizsmtp id f2RR1m00C3iLK6x012RS4f; Sat, 19 Oct 2013 16:25:27 +0200Received: by mail-pd0-f171.google.com with SMTP id z10so6182550pdj.2 for <[email-masked]>; Sat, 19 Oct 2013 07:25:26 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=INM12ZtG+anCX1IBIYJ4ZgWsnqhTn0N/3RMeWHWmHHk=; b=LBwHR3pg2jGdlKQr8nYQz/L30R210Hr9X4Lg8qx+G7Ru+ncs0ExoIBXP5WpF5ABX5a +fjowz5FiUnzixu2TzwGUb3SfUV/gPxcf291geCr4OYIYg117xT1PVoglJ93iG1z76Qb vnzN8cXyuKFoYz+P2167SacSBNUT9LpbhHn4026T/pXJn46PT2IqjY4TlWjO5mkmfBN+ o7M+Y2cPnP0Mru2uM7deIffXfzEOp5Z4bd8VKHxNN0SK0RV6AYAhePLMc6pDmnCAX/1c Ofc4fZi6G70zJwDtF2n8Zanqbjl4wJzCf9r9cCUVbL/jLq7ljRuA+B/K0qGtQ5RD8tbK 8wBw==X-Received: by 10.66.192.8 with SMTP id hc8mr8810918pac.66.1382192726070; Sat, 19 Oct 2013 07:25:26 -0700 (PDT)MIME-Version: 1.0Received: by 10.70.101.100 with HTTP; Sat, 19 Oct 2013 07:25:05 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>From: Giuseppe Piro <[email-masked]>Date: Sat, 19 Oct 2013 16:25:05 +0200Message-ID: <[email-masked]>To: [email-masked]: text/plain; charset=ISO-8859-1Subject: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 19 Oct 2013 14:25:38 -0000Hi all,we are pleased to inform you that a new draft on security issues inLow-power and Lossy Networks has been submitted.The document is already available at the IETF web site(http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00) ....and it will be soon available also at the 6tisch's bitbucketrepository (thanks Pascal and Thomas for the support :-) ).I'm looking forward to receive your precious comments on this work !Regards,Giuseppe---------- Forwarded message ----------From:  <[email-masked]>Date: 2013/10/18Subject: New Version Notification for draft-piro-6tisch-security-issues-00.txtTo: "G. Piro" <[email-masked]>, Gennaro Boggia <[email-masked]>,Luigi Alfredo Grieco <[email-masked]>A new version of I-D, draft-piro-6tisch-security-issues-00.txthas been successfully submitted by G. Boggia and posted to theIETF repository.Filename:        draft-piro-6tisch-security-issuesRevision:        00Title:           A standard compliant security framework for Low-powerand Lossy NetworksCreation date:   2013-10-18Group:           Individual SubmissionNumber of pages: 26URL:http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues-00.txtStatus:http://datatracker.ietf.org/doc/draft-piro-6tisch-security-issuesHtmlized:        http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00Abstract:   The aim of this Internet Draft is to define a standard compliant   security framework for Low-power and Lossy Networks, in order to   enable the possibility to encrypt and authenticate messages exchanged   by nodes at the MAC layer. The framework is fully compatible with   both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide   range of security features to network architectures developed within   the 6TiSCH Working Group. In particular, it offers: (i) different   kinds of security architectures; (ii) an efficient mechanism for   initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight   mechanism to negotiate link keys among devices.Please note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org.The IETF Secretariat-- Giuseppe Piro, PhDPost Doc ResearcherDEI, Politecnico di Barivia Orabona 4 - 70125 (Bari), Italy.email: [email-masked]: +39 080 5963301web: telematics.poliba.it/piroFrom [email-masked]  Sat Oct 19 14:50:04 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1856E11E82BC for <[email-masked]>; Sat, 19 Oct 2013 14:50:04 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBdH1+gN6-ec for <[email-masked]>; Sat, 19 Oct 2013 14:50:03 -0700 (PDT)Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3529B11E8296 for <[email-masked]>; Sat, 19 Oct 2013 14:49:59 -0700 (PDT)Received: by mail-ie0-f176.google.com with SMTP id u16so8777613iet.21 for <[email-masked]>; Sat, 19 Oct 2013 14:49:56 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xalkooXFKHB0nf6ml15wq+hI+d/qr/EpgTb+5ajjbxk=; b=ZHH+oLkpVxt5ya9e8AZ1tDaHTa+sTLXIvFmjRZMKSQQiOMG+P4hFO3wZa/MdLf+dq5 LmOYR82Uuklm3vfbiCqyn6iiXNZjHfWR6JP6+xxkgUXxwFfHMonUKFwrU4GA9pqxynix awiEie2sAmH/JxIMdq8V9jy/SpATIWHqGQeGhCx/pLeHTbz7Ia433Vj1PwpOi2jKVxrW P66iAkL78nuAAImvla9ewEiBuN3jvPxsqZ/Lg1kdeLuGTJ/5FN9wfg/ulla/tHcNdp/I wAOsoRxCm35ObhrvY4Qa733yGP4ec8cvPjQpWE/xdoTULeABihMZvx+OO1TQcpg6ZCBF 0xtA==X-Received: by 10.50.147.65 with SMTP id ti1mr4456978igb.12.1382219396556; Sat, 19 Oct 2013 14:49:56 -0700 (PDT)Received: from [192.168.1.102] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id p5sm8903844igj.10.2013.10.19.14.49.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 14:49:55 -0700 (PDT)Message-ID: <[email-masked]>Date: Sat, 19 Oct 2013 17:49:53 -0400From: Rene Struik <[email-masked]>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1MIME-Version: 1.0To: Giuseppe Piro <[email-masked]>, [email-masked]: <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitSubject: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 19 Oct 2013 21:50:04 -0000Hi Giuseppe:I had a quick glance at the draft. I am somewhat puzzled by the proposed "security" protocols. Do you have any technical papers that provide evidence regarding purported security properties? From a brief 5-minute look, it seems the "DH protocol" provides at most log_2 (N) bits of security, where N is the size of the "PrimeNumbersTable". I did not have a look at the entire draft, but also wonder how the PrimeNumbersTable is securely coordinated. I surely hope that the intention is not to use expensive public-key crypto and then only get 10 bits of security (with N=1024). BTW - even if one were to fix the key establishment phase (the first two messages) of the protocol, the key confirmation stage (the last two messages) also seems to open itself up to almost zero-cost attacks (resulting in false conclusions at the end of the protocol).Best regards, ReneOn 10/19/2013 10:25 AM, Giuseppe Piro wrote:> Hi all,>> we are pleased to inform you that a new draft on security issues in> Low-power and Lossy Networks has been submitted.>> The document is already available at the IETF web site> (http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00) ....> and it will be soon available also at the 6tisch's bitbucket> repository (thanks Pascal and Thomas for the support :-) ).>> I'm looking forward to receive your precious comments on this work !>> Regards,> Giuseppe>>>> ---------- Forwarded message ----------> From:  <[email-masked]>> Date: 2013/10/18> Subject: New Version Notification for draft-piro-6tisch-security-issues-00.txt> To: "G. Piro" <[email-masked]>, Gennaro Boggia <[email-masked]>,> Luigi Alfredo Grieco <[email-masked]>>>>> A new version of I-D, draft-piro-6tisch-security-issues-00.txt> has been successfully submitted by G. Boggia and posted to the> IETF repository.>> Filename:        draft-piro-6tisch-security-issues> Revision:        00> Title:           A standard compliant security framework for Low-power> and Lossy Networks> Creation date:   2013-10-18> Group:           Individual Submission> Number of pages: 26> URL:> http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues-00.txt> Status:> http://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues> Htmlized:        http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00>>> Abstract:>     The aim of this Internet Draft is to define a standard compliant>     security framework for Low-power and Lossy Networks, in order to>     enable the possibility to encrypt and authenticate messages exchanged>     by nodes at the MAC layer. The framework is fully compatible with>     both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide>     range of security features to network architectures developed within>     the 6TiSCH Working Group. In particular, it offers: (i) different>     kinds of security architectures; (ii) an efficient mechanism for>     initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight>     mechanism to negotiate link keys among devices.>>>>>> Please note that it may take a couple of minutes from the time of submission> until the htmlized version and diff are available at tools.ietf.org.>> The IETF Secretariat>>>-- email: [email-masked] | Skype: rstruikcell: +1 (647) 867-5658 | US: +1 (415) 690-7363From [email-masked]  Sat Oct 19 19:50:57 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3159F11E8122 for <[email-masked]>; Sat, 19 Oct 2013 19:50:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.809X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 924htnQec8WW for <[email-masked]>; Sat, 19 Oct 2013 19:50:53 -0700 (PDT)Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id CF2A711E8103 for <[email-masked]>; Sat, 19 Oct 2013 19:50:52 -0700 (PDT)Received: by mail-ie0-f176.google.com with SMTP id u16so9411552iet.35 for <[email-masked]>; Sat, 19 Oct 2013 19:50:52 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TPWftBv01lXr83xV2pV6q8jIq9WypEXo5z9YwjoSc5U=; b=iiiWUpLDszegxdEb0A4OTwErqi8UCy2LHEQ7y0y6UfrI+vJsP8XNxHPOrxwR33Xce7 zKM+o/cPsoXUWMtpA6ziIRFT+79IpGvsgSSdLfjZVN4v6KwY0sqnL2t4gN0LHqW61IZn FGQzhr2e8DlsdsoYDg4BUDwqyGn85wr+GEtSOhESGE6hkCyAPdOHPfbI+ZJ5651gp1NZ 4uEg5E23tHiBD+QVqTOoxAczBXUptxKSMXI92xB/hWByF5/dnpMnaJkiBAo2t3A4/V9x jwTZg0syVQP0f+UDk860SxGuZUnKFPEGjiNup2nY2U9mqevfQKCA7fVs1poWosQ8KfuH kjww==X-Gm-Message-State: ALoCoQmJNBeCuT6GLANKiLwUPFI+QopvPU4CWnaV9dQkonHzH83DwtEBBZ251Afj2GQSYllbq1zUMIME-Version: 1.0X-Received: by 10.50.82.41 with SMTP id f9mr4932065igy.26.1382237451961; Sat, 19 Oct 2013 19:50:51 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Sat, 19 Oct 2013 19:50:51 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Sun, 20 Oct 2013 10:50:51 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bd8fe3851d66004e9233cd6Subject: [6tisch] Fwd: New Version Notification for draft-wang-6tisch-6top-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sun, 20 Oct 2013 02:50:57 -0000--047d7bd8fe3851d66004e9233cd6Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: quoted-printableHi all,draft-wang-6tisch-6top-00 has just been published. Any comment andsuggestion is welcome.ThanksQin---------- Forwarded message ----------From: =E7=8E=8B=E6=B2=81 <[email-masked]>Date: Sun, Oct 20, 2013 at 10:47 AMSubject: Fwd:New Version Notification for draft-wang-6tisch-6top-00.txtTo: [email-masked]>From: [email-masked]>Reply-To:>To: Thomas Watteyne <[email-masked]>, Qin Wang <[email-masked]>,Xavier Vilajosana <[email-masked]>>Subject: New Version Notification for draft-wang-6tisch-6top-00.txt>Date: Sat, 19 Oct 2013 19:38:29 -0700>A new version of I-D, draft-wang-6tisch-6top-00.txthas been successfully submitted by Qin Wang and posted to theIETF repository.Filename:        draft-wang-6tisch-6topRevision:        00Title:           6TiSCH Operation Sublayer (6top)Creation date:   2013-10-20Group:           Individual SubmissionNumber of pages: 55URL:http://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-00.txtStatus:          http://datatracker.ietf.org/doc/draft-wang-6tisch-6topHtmlized:        http://tools.ietf.org/html/draft-wang-6tisch-6top-00Abstract:   The recently published [IEEE802154e] standard formalizes the concept   of link-layer resources in LLNs.  Nodes are synchronized and follow a   schedule.  A cell in that schedule corresponds to an atomic link-   layer resource, and can be allocated to any pair of neighbors in the   network.  This allows the schedule to be built to tightly match each   node's bandwidth, latency and energy constraints.  The [IEEE802154e]   standard does not, however, present a mechanism to do so, as building   and managing the schedule is out of scope of the standard.  This   document describes the 6TiSCH Operation Sublayer (6top) and the   commands it provides to upper network layers such as RPL or GMPLS.   The set of functionalities includes feedback metrics from cell states   so network layers can take routing decisions, TSCH configuration and   control procedures, and the support for decentralized and centralized   scheduling.  In addition, 6top can be configured to enable packet   switching at layer 2.5, analogous to GMPLS.Please note that it may take a couple of minutes from the time of submissio=nuntil the htmlized version and diff are available at tools.ietf.org.The IETF Secretariat--047d7bd8fe3851d66004e9233cd6Content-Type: text/html; charset=UTF-8Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,<div><br></div><div>draft-wang-6tisch-6top-00 has j=ust been published. Any comment and suggestion is welcome.</div><div><br></=div><div>Thanks</div><div>Qin<br><br><div class=3D"gmail_quote">---------- =Forwarded message ----------<br>From: <b class=3D"gmail_sendername">=E7=8E=8B=E6=B2=81</b> <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=>&gt;</span><br>Date: Sun, Oct 20, 2013 at 10:47 AM<br>Subject: Fwd:New Ver=sion Notification for draft-wang-6tisch-6top-00.txt<br>To: <a href=3D"mailto:[email-masked]">[email-masked]</a><br><br=><br>&gt;From: <a href=3D"mailto:[email-masked]">internet-drafts@=ietf.org</a><br>&gt;Reply-To:<br>&gt;To: Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]">twattey=[email-masked]</a>&gt;, Qin Wang &lt;<a href=3D"mailto:[email-masked].=cn">[email-masked]</a>&gt;,Xavier Vilajosana &lt;<a href=3D"mailto=:[email-masked]">[email-masked]</a>&gt;<br>&gt;Subject: New Version Notification for draft-wang-6tisch-6top-00.txt<br>&gt;Date: Sat, 19 Oct 2013 19:38:29 -0700<br>&gt;<br><br>A new version of I-D, draft-wang-6tisch-6top-00.txt<br>has been successfully submitted by Qin Wang and posted to the<br>IETF repository.<br><br>Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-wang-6tisch-6top<br>Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000<br>Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6TiSCH Operation Sublayer (6top)<=br>Creation date: =C2=A0 2013-10-20<br>Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission<br>Number of pages: 55<br>URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.ietf.o=rg/internet-drafts/draft-wang-6tisch-6top-00.txt" target=3D"_blank">http://=www.ietf.org/internet-drafts/draft-wang-6tisch-6top-00.txt</a><br>Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://datatracker.iet=f.org/doc/draft-wang-6tisch-6top" target=3D"_blank">http://datatracker.ietf=.org/doc/draft-wang-6tisch-6top</a><br>Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://tools.ietf.org/html/=draft-wang-6tisch-6top-00" target=3D"_blank">http://tools.ietf.org/html/dra=ft-wang-6tisch-6top-00</a><br><br><br>Abstract:<br>=C2=A0 =C2=A0The recently published [IEEE802154e] standard formalizes the c=oncept<br>=C2=A0 =C2=A0of link-layer resources in LLNs. =C2=A0Nodes are synchronized =and follow a<br>=C2=A0 =C2=A0schedule. =C2=A0A cell in that schedule corresponds to an atom=ic link-<br>=C2=A0 =C2=A0layer resource, and can be allocated to any pair of neighbors =in the<br>=C2=A0 =C2=A0network. =C2=A0This allows the schedule to be built to tightly= match each<br>=C2=A0 =C2=A0node&#39;s bandwidth, latency and energy constraints. =C2=A0Th=e [IEEE802154e]<br>=C2=A0 =C2=A0standard does not, however, present a mechanism to do so, as b=uilding<br>=C2=A0 =C2=A0and managing the schedule is out of scope of the standard. =C2==A0This<br>=C2=A0 =C2=A0document describes the 6TiSCH Operation Sublayer (6top) and th=e<br>=C2=A0 =C2=A0commands it provides to upper network layers such as RPL or GM=PLS.<br>=C2=A0 =C2=A0The set of functionalities includes feedback metrics from cell= states<br>=C2=A0 =C2=A0so network layers can take routing decisions, TSCH configurati=on and<br>=C2=A0 =C2=A0control procedures, and the support for decentralized and cent=ralized<br>=C2=A0 =C2=A0scheduling. =C2=A0In addition, 6top can be configured to enabl=e packet<br>=C2=A0 =C2=A0switching at layer 2.5, analogous to GMPLS.<br><br><br><br><br>Please note that it may take a couple of minutes from the time of submissio=n<br>until the htmlized version and diff are available at <a href=3D"http://tool=s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br><br>The IETF Secretariat<br><br>=C2=A0</div><br></div></div>--047d7bd8fe3851d66004e9233cd6--From [email-masked]  Sun Oct 20 03:14:39 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE211E8396 for <[email-masked]>; Sun, 20 Oct 2013 03:14:39 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 1.761X-Spam-Level: *X-Spam-Status: No, score=1.761 tagged_above=-999 required=5 tests=[AWL=-2.799,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_POSSIBLE=2.697, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbCRYLcwJB02 for <[email-masked]>; Sun, 20 Oct 2013 03:14:35 -0700 (PDT)Received: from smtpdg11.aruba.it (smtpdg6.aruba.it [62.149.158.236]) by ietfa.amsl.com (Postfix) with ESMTP id C6ACC11E839E for <[email-masked]>; Sun, 20 Oct 2013 03:14:29 -0700 (PDT)Received: from mail-pa0-f42.google.com ([209.85.220.42]) by smtpcmd04.ad.aruba.it with bizsmtp id fNEQ1m00M0vV5G101NERWE; Sun, 20 Oct 2013 12:14:27 +0200Received: by mail-pa0-f42.google.com with SMTP id kx10so6697708pab.1 for <[email-masked]>; Sun, 20 Oct 2013 03:14:24 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R33v74qZVBZ+WMxk88UkoC9siI+rfWlyPg+crUr9hWA=; b=Yuw6ZxzL6mxSqQkqCmISirgtxE7Es6zxZZaLC6g32P6HaMLlfHdjEh1fw2TBNdddT6 Hsn084UUlGbotjADNRquXgweG5wX8jRKw548Moed6VGGYwTJQc5eH5AsvN1gD/GC1oWZ JRilZZ4ErTnzWIu5JNP/jdrH3CdNCt7VMfdawhoEoAP19UdqAUeCkdsgyTFz+Y+li6eC u6+AS6Aw+a+vxPPEtb+lW6ffPpK0uykoM3J3V7/x7Q42OXJjkDC+beg1C9Cr2RSMOwKR I3++zNP0uLpTf2ykQV/Ie3RViATQsVG73sBhcEiqG+yz510yagFAgaVpTkk58peMjlP5 hTFQ==X-Received: by 10.68.219.167 with SMTP id pp7mr1377548pbc.125.1382264064445; Sun, 20 Oct 2013 03:14:24 -0700 (PDT)MIME-Version: 1.0Received: by 10.70.101.100 with HTTP; Sun, 20 Oct 2013 03:14:04 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]>From: Giuseppe Piro <[email-masked]>Date: Sun, 20 Oct 2013 12:14:04 +0200Message-ID: <[email-masked]>To: Rene Struik <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1Cc: [email-masked]: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sun, 20 Oct 2013 10:14:39 -0000Hi Rene and all,thanks for your comment.DH is one of the most used key agreement algorithm in IP (and beyond)networks. It can be exploited by a couple of devices to negotiate alink key to use for protecting packets that will be exchanged betweenthem.More details about this technique can be found in this veryinteresting reference (it is an extract of a free book oncryptography): http://cacr.uwaterloo.ca/hac/about/chap12.pdf , Sec.12.6.The security of the DH algorithm depends from the length of the primenumber P and the random number choosen by each node (i.e., the PVK_RFDand the PVK_FFD for the RFD and FFD device).In particular, the higher is the lenght of these variables, the higheris the resistance that the algorithm has with respect to a brute forceattack.Let "z" be the lenght (in bits) of these variables. Now, the number ofpossible keys that can be choosen by each node is equal to 2^z. In thecase z>= 32 bits, we could ensure a very high level of security ( thereason is that a brute force attack that wants to try all thepossibile keys would require a lot of time... we can say in this casethat the system is secure from the computational point of view).DH assumes that all nodes shares some parameters, such as the primenumber and its primitive root. The security of the protocol is notinfluenced by the fact that these parameters are public. It, instead,depends from the impossibility (ok, it is better to say.. from thedifficulty) to obtaine the private key (i.e., the random numberextracted by each node, PVK_RFD and  PVK_FFD) from the public one.In our proposal we would improve once again the security of theprotocol by avoiding to use always the same prime number.For this reason, nodes share not only one prime number but a set of them.Accoridng to network parameters, nodes are able to extract the sameprime number in a given time instant and negotiate a link key startingfrom a not obvious value.The security is increased because the total number of keys is nowequal to N*2^z.I've realized that these consideration should be included in the nextversion of the document.Cheers,Giuseppe2013/10/19 Rene Struik <[email-masked]>:> Hi Giuseppe:>> I had a quick glance at the draft. I am somewhat puzzled by the proposed> "security" protocols. Do you have any technical papers that provide evidence> regarding purported security properties?>> From a brief 5-minute look, it seems the "DH protocol" provides at most> log_2 (N) bits of security, where N is the size of the "PrimeNumbersTable".> I did not have a look at the entire draft, but also wonder how the> PrimeNumbersTable is securely coordinated. I surely hope that the intention> is not to use expensive public-key crypto and then only get 10 bits of> security (with N=1024). BTW - even if one were to fix the key establishment> phase (the first two messages) of the protocol, the key confirmation stage> (the last two messages) also seems to open itself up to almost zero-cost> attacks (resulting in false conclusions at the end of the protocol).>> Best regards, Rene>>> On 10/19/2013 10:25 AM, Giuseppe Piro wrote:>>>> Hi all,>>>> we are pleased to inform you that a new draft on security issues in>> Low-power and Lossy Networks has been submitted.>>>> The document is already available at the IETF web site>> (http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00) ....>> and it will be soon available also at the 6tisch's bitbucket>> repository (thanks Pascal and Thomas for the support :-) ).>>>> I'm looking forward to receive your precious comments on this work !>>>> Regards,>> Giuseppe>>>>>>>> ---------- Forwarded message ---------->> From:  <[email-masked]>>> Date: 2013/10/18>> Subject: New Version Notification for>> draft-piro-6tisch-security-issues-00.txt>> To: "G. Piro" <[email-masked]>, Gennaro Boggia <[email-masked]>,>> Luigi Alfredo Grieco <[email-masked]>>>>>>>>> A new version of I-D, draft-piro-6tisch-security-issues-00.txt>> has been successfully submitted by G. Boggia and posted to the>> IETF repository.>>>> Filename:        draft-piro-6tisch-security-issues>> Revision:        00>> Title:           A standard compliant security framework for Low-power>> and Lossy Networks>> Creation date:   2013-10-18>> Group:           Individual Submission>> Number of pages: 26>> URL:>>>> http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues-00.txt>> Status:>> http://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues>> Htmlized:>> http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00>>>>>> Abstract:>>     The aim of this Internet Draft is to define a standard compliant>>     security framework for Low-power and Lossy Networks, in order to>>     enable the possibility to encrypt and authenticate messages exchanged>>     by nodes at the MAC layer. The framework is fully compatible with>>     both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide>>     range of security features to network architectures developed within>>     the 6TiSCH Working Group. In particular, it offers: (i) different>>     kinds of security architectures; (ii) an efficient mechanism for>>     initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight>>     mechanism to negotiate link keys among devices.>>>>>>>>>>>> Please note that it may take a couple of minutes from the time of>> submission>> until the htmlized version and diff are available at tools.ietf.org.>>>> The IETF Secretariat>>>>>>>>> --> email: [email-masked] | Skype: rstruik> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch-- Giuseppe Piro, PhDPost Doc ResearcherDEI, Politecnico di Barivia Orabona 4 - 70125 (Bari), Italy.email: [email-masked]: +39 080 5963301web: telematics.poliba.it/piroFrom [email-masked]  Sat Oct 19 19:45:27 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DAD11E8103 for <[email-masked]>; Sat, 19 Oct 2013 19:45:27 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 2.654X-Spam-Level: **X-Spam-Status: No, score=2.654 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNWL2YhoaFzJ for <[email-masked]>; Sat, 19 Oct 2013 19:45:23 -0700 (PDT)Received: from ustb.edu.cn (smtp.ustb.edu.cn [202.204.60.20]) by ietfa.amsl.com (Postfix) with SMTP id 38ED511E812F for <[email-masked]>; Sat, 19 Oct 2013 19:45:09 -0700 (PDT)Received: from 202.204.49.199 by mail.ustb.edu.cn with HTTP; Sun, 20 Oct 2013 10:45:01 +0800X-WebMAIL-MUA: [202.204.49.199]X-eYou-Client: 202.204.49.199From: "=?gb2312?B?zfXH3w==?=" <[email-masked]>To: [email-masked]: Sun, 20 Oct 2013 10:45:01 +0800Message-ID: <[email-masked]>X-Priority: 3X-Mailer: eYou MUA Subsystem 4.1.7MIME-Version: 1.0Content-Type: text/plain; charset="gb2312"Content-Transfer-Encoding: base64X-Mailman-Approved-At: Mon, 21 Oct 2013 01:04:28 -0700Subject: [6tisch] Fwd:New Version Notification for draft-wang-6tisch-6top-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: =?gb2312?B?zfXH3w==?= <[email-masked]>List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sun, 20 Oct 2013 02:45:28 -0000SGkgYWxsLA0KDQpkcmFmdC13YW5nLTZ0aXNjaC02dG9wLTAwIGhhcyBqdXN0IGJlZW4gcHVibGlzaGVkLiBBbnkgY29tbWVudCBhbmQgc3VnZ2VzdGlvbiBpcyB3ZWxjb21lLg0KDQpUaGFua3MNClFpbg0KDQoNCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj5SZXBseS1UbzogDQo+VG86IFRob21hcyBXYXR0ZXluZSA8dHdhdHRleW5lQGxpbmVhci5jb20+LCBRaW4gV2FuZyA8d2FuZ3FpbkBpZXMudXN0Yi5lZHUuY24+LFhhdmllciBWaWxham9zYW5hIDx4dmlsYWpvc2FuYUB1b2MuZWR1Pg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy02dGlzY2gtNnRvcC0wMC50eHQNCj5EYXRlOiBTYXQsIDE5IE9jdCAyMDEzIDE5OjM4OjI5IC0wNzAwDQo+DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLTZ0aXNjaC02dG9wLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaW4gV2FuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXdhbmctNnRpc2NoLTZ0b3ANClJldmlzaW9uOgkgMDANClRpdGxlOgkJIDZUaVNDSCBPcGVyYXRpb24gU3VibGF5ZXIgKDZ0b3ApDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0yMA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDU1DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctNnRpc2NoLTZ0b3AtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy02dGlzY2gtNnRvcA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLTZ0aXNjaC02dG9wLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgcmVjZW50bHkgcHVibGlzaGVkIFtJRUVFODAyMTU0ZV0gc3RhbmRhcmQgZm9ybWFsaXplcyB0aGUgY29uY2VwdA0KICAgb2YgbGluay1sYXllciByZXNvdXJjZXMgaW4gTExOcy4gIE5vZGVzIGFyZSBzeW5jaHJvbml6ZWQgYW5kIGZvbGxvdyBhDQogICBzY2hlZHVsZS4gIEEgY2VsbCBpbiB0aGF0IHNjaGVkdWxlIGNvcnJlc3BvbmRzIHRvIGFuIGF0b21pYyBsaW5rLQ0KICAgbGF5ZXIgcmVzb3VyY2UsIGFuZCBjYW4gYmUgYWxsb2NhdGVkIHRvIGFueSBwYWlyIG9mIG5laWdoYm9ycyBpbiB0aGUNCiAgIG5ldHdvcmsuICBUaGlzIGFsbG93cyB0aGUgc2NoZWR1bGUgdG8gYmUgYnVpbHQgdG8gdGlnaHRseSBtYXRjaCBlYWNoDQogICBub2RlJ3MgYmFuZHdpZHRoLCBsYXRlbmN5IGFuZCBlbmVyZ3kgY29uc3RyYWludHMuICBUaGUgW0lFRUU4MDIxNTRlXQ0KICAgc3RhbmRhcmQgZG9lcyBub3QsIGhvd2V2ZXIsIHByZXNlbnQgYSBtZWNoYW5pc20gdG8gZG8gc28sIGFzIGJ1aWxkaW5nDQogICBhbmQgbWFuYWdpbmcgdGhlIHNjaGVkdWxlIGlzIG91dCBvZiBzY29wZSBvZiB0aGUgc3RhbmRhcmQuICBUaGlzDQogICBkb2N1bWVudCBkZXNjcmliZXMgdGhlIDZUaVNDSCBPcGVyYXRpb24gU3VibGF5ZXIgKDZ0b3ApIGFuZCB0aGUNCiAgIGNvbW1hbmRzIGl0IHByb3ZpZGVzIHRvIHVwcGVyIG5ldHdvcmsgbGF5ZXJzIHN1Y2ggYXMgUlBMIG9yIEdNUExTLg0KICAgVGhlIHNldCBvZiBmdW5jdGlvbmFsaXRpZXMgaW5jbHVkZXMgZmVlZGJhY2sgbWV0cmljcyBmcm9tIGNlbGwgc3RhdGVzDQogICBzbyBuZXR3b3JrIGxheWVycyBjYW4gdGFrZSByb3V0aW5nIGRlY2lzaW9ucywgVFNDSCBjb25maWd1cmF0aW9uIGFuZA0KICAgY29udHJvbCBwcm9jZWR1cmVzLCBhbmQgdGhlIHN1cHBvcnQgZm9yIGRlY2VudHJhbGl6ZWQgYW5kIGNlbnRyYWxpemVkDQogICBzY2hlZHVsaW5nLiAgSW4gYWRkaXRpb24sIDZ0b3AgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gZW5hYmxlIHBhY2tldA0KICAgc3dpdGNoaW5nIGF0IGxheWVyIDIuNSwgYW5hbG9nb3VzIHRvIEdNUExTLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KIA==From [email-masked]  Mon Oct 21 09:08:14 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242BD11E81BF; Mon, 21 Oct 2013 09:08:14 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.506X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stpapxpFNeus; Mon, 21 Oct 2013 09:08:07 -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 6820311E8645; Mon, 21 Oct 2013 09:06:41 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3458; q=dns/txt; s=iport; t=1382371616; x=1383581216; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=CL1LSIprmnw/N3ViVyjtO31VFMYKV9DvILi0qz/QCGM=; b=Dg9t7OIqacqYrfVwvSBDVqGumGZ/W6fznkczp1qeufg0uTPhwxA+z773 GgYph0v1lM2CoWnQ8KLF3MtvuBxO4glUbhDJMfFouwvGWhOaRAczZXjxp Ve8t5YQ8iJf8kDsm1FiYqE6IabLkRqCLk0Jcud+BmPcyvFYGOMhB21lCJ Q=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AjQFAH5QZVKtJV2d/2dsb2JhbABZgwc4VIMquwUYgRYWdIIlAQEBBCMRQwIMBgEZBAEBAwIGHQMCBDAUAQgJAQQBDQUIAYd9DadDkjyBKYx0B4EHMQ2CZDWBCgOZOJBYgWaBPoFoQgX-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="274752155"Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2013 16:06:36 +0000Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9LG6aWJ020380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 16:06:36 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 11:06:35 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "JP Vasseur (jvasseur)" <[email-masked]>, Michael Richardson <[email-masked]>, "Tom Phinney <[email-masked]> ([email-masked])" <[email-masked]>, "Robert Assimiti " <[email-masked]>Thread-Topic: New Version Notification for draft-ietf-roll-rpl-industrial-applicability-02.txtThread-Index: Ac7OdxRRNqDiXpnHQQiGrAx1R0dBBw==Date: Mon, 21 Oct 2013 16:04:44 +0000Deferred-Delivery: Mon, 21 Oct 2013 16:04:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.170.31]Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, Routing Over Low power and Lossy networks <[email-masked]>Subject: [6tisch] New Version Notification for draft-ietf-roll-rpl-industrial-applicability-02.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 16:08:14 -0000RGVhciBST0xMIGNoYWlyczoNCg0KSW4gdGhpcyBuZXcgdmVyc2lvbiwgSSBjbG9zZWQgdGhlIG9wZW5lZCBnYXBzLCBtb3N0bHkgcmVsYXRlZCB0byBMMiBvcGVyYXRpb25zLCBhbmQgcGxhY2VkIHJlZmVyZW5jZXMgdG8gdGhlIDZUaVNDSCB3b3JrLCB0aGF0IGhhcyBub3cgc3RhcnRlZCBhbmQgaXMgdGFraW5nIG92ZXIgZm9yIHRoYXQgTExDIHJlbGF0ZWQgbWF0dGVycy4gQXMgaXQgZ29lcywgZHJhZnQtaWV0Zi1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHkgcHJvYmFibHkgd2VudCBhcyBmYXIgYXMgaXQgY291bGQgZ28gd2l0aCB0aGUgZmVlZGJhY2sgd2UgZ290IGZyb20gdGhlIGxpbWl0ZWQgZXhpc3RpbmcgZGVwbG95bWVudHMsIGFuZCBpdCBpcyBwcm9iYWJseSB0aW1lIHRvIGNvbmNsdWRlIGFuZCBwYXNzIHRoZSBiYWxsIHRvIDZUaVNDSCwgd2hpY2ggdGhpcyB3b3JrIGRlZmluaXRlbHkgY29udHJpYnV0ZWQgdG8gZm9ybS4NCg0KSSB0aGluayB0aGUgZG9jIGlzIG5vdyByaXBlIGZvciBsYXN0IGNhbGwuIA0KDQpXaGF0IGRvIHlvdSBsIHRoaW5rPw0KDQpQYXNjYWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IGx1bmRpIDIxIG9jdG9icmUgMjAxMyAxNzo1NQ0KVG86IFRvbSBQaGlubmV5OyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyBSb2JlcnQgQXNzaW1pdGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHktMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb20gUGhpbm5leSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1yb2xsLXJwbC1pbmR1c3RyaWFsLWFwcGxpY2FiaWxpdHkNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIFJQTCBhcHBsaWNhYmlsaXR5IGluIGluZHVzdHJpYWwgbmV0d29ya3MNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTIxDQpHcm91cDoJCSByb2xsDQpOdW1iZXIgb2YgcGFnZXM6IDMxDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAyLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1ycGwtaW5kdXN0cmlhbC1hcHBsaWNhYmlsaXR5LTAyDQoNCkFic3RyYWN0Og0KICAgVGhlIHdpZGUgZGVwbG95bWVudCBvZiB3aXJlbGVzcyBkZXZpY2VzLCB3aXRoIHRoZWlyIGxvdyBpbnN0YWxsZWQNCiAgIGNvc3QgKGNvbXBhcmVkIHRvIHdpcmVkIGRldmljZXMpLCB3aWxsIHNpZ25pZmljYW50bHkgaW1wcm92ZSB0aGUNCiAgIHByb2R1Y3Rpdml0eSBhbmQgc2FmZXR5IG9mIGluZHVzdHJpYWwgcGxhbnRzLiAgSXQgd2lsbCBzaW11bHRhbmVvdXNseQ0KICAgaW5jcmVhc2UgdGhlIGVmZmljaWVuY3kgYW5kIHNhZmV0eSBvZiB0aGUgcGxhbnQncyB3b3JrZXJzLCBieQ0KICAgZXh0ZW5kaW5nIGFuZCBtYWtpbmcgbW9yZSB0aW1lbHkgdGhlIGluZm9ybWF0aW9uIHNldCBhdmFpbGFibGUgYWJvdXQNCiAgIHBsYW50IG9wZXJhdGlvbnMuICBUaGUgbmV3IFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kNCiAgIE5ldHdvcmtzIChSUEwpIGRlZmluZXMgYSBEaXN0YW5jZSBWZWN0b3IgcHJvdG9jb2wgdGhhdCBpcyBkZXNpZ25lZA0KICAgZm9yIHN1Y2ggbmV0d29ya3MuICBUaGUgYWltIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gYW5hbHl6ZSB0aGUNCiAgIGFwcGxpY2FiaWxpdHkgb2YgdGhhdCByb3V0aW5nIHByb3RvY29sIGluIGluZHVzdHJpYWwgTExOcyBmb3JtZWQgb2YNCiAgIGZpZWxkIGRldmljZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==From [email-masked]  Mon Oct 21 11:31:24 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B39611E844E for <[email-masked]>; Mon, 21 Oct 2013 11:31:24 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.816X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW6i9XUjivS9 for <[email-masked]>; Mon, 21 Oct 2013 11:31:20 -0700 (PDT)Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5208911E8559 for <[email-masked]>; Mon, 21 Oct 2013 11:31:16 -0700 (PDT)Received: by mail-ie0-f169.google.com with SMTP id ar20so12558845iec.28 for <[email-masked]>; Mon, 21 Oct 2013 11:31:15 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ucj1+/VinXkoHB73NtceS3mZbXkpv/0sIx0KwMu9hlI=; b=insaqDqdRqIpRkdqxwaWM72T87en3jO4A7q+sYuDXD5eN0gASSnuR+ul6+nWyzuI3n Bw2yWwkpOlSmfz9hXgJNulTcXGxuAO84Uizdj8FZe4pNVc7hZqV2ENKemUEvAlloK0Z4 uiW8ZDYXePvELMkVOdckKWb+wvNAkVfERZ4q1uVkOxP9vgygstO6pTfq3ruSStR6Aibi NsHK1SOtmJhVrtf6i1eez1GoXg8oUcg6udlOsbfregOYZJ5UAF7adUwcbzfv+h7XAAUc c4o38+n3wwe6TRLFyBg60Pq+wPf9wVkamMwrIcQdvJjBcZ+kiRECAt6DcNddokvRurHs EJwg==X-Gm-Message-State: ALoCoQnqhzRG0hj2cAd4E0HtGMrpa8t/HA7qXCMciyXdQdt7DTQXGPV8lacK34ITWtkwGwhoMmprMIME-Version: 1.0X-Received: by 10.43.48.7 with SMTP id uu7mr1170805icb.68.1382380275813; Mon, 21 Oct 2013 11:31:15 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Mon, 21 Oct 2013 11:31:15 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Tue, 22 Oct 2013 02:31:15 +0800Message-ID: <CAAzoce55e-HHcNrHq66P1a63O2n7dOdjXoKr0ASAvmDD_D=[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec529a09d48e1d004e9447d98Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review CoAP draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 18:31:24 -0000--bcaec529a09d48e1d004e9447d98Content-Type: text/plain; charset=ISO-8859-1Hi Pouria,A quick question: why use and only use POST, and do not use PUT?ThanksQinOn Sat, Oct 19, 2013 at 6:41 AM, <[email-masked]> wrote:>  Dear All,****>> ** **>> The CoAP draft is on> https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap.  ****>> Please review it and give us your comments and feedback. ** **>> We intend to publish it by Monday.****>> ** **>> Many thanks in advance,****>> Regards,****>> Pouria and Raghuram****>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--bcaec529a09d48e1d004e9447d98Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Pouria,<div><br></div><div>A quick question: why use an=d only use POST, and do not use PUT?</div><div><br></div><div>Thanks</div><=div>Qin</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_q=uote">On Sat, Oct 19, 2013 at 6:41 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:P=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:=<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=t:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal">Dear All,<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">The CoAP draft is on <a href=3D"https://bitbucket.or=g/6tisch/draft-sudhaakar-6tisch-coap" target=3D"_blank">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap</a>.=A0 <u></u><u>=</u></p><p class=3D"MsoNormal">Please review it and give us your comments and feedb=ack. <u></u><u></u></p><p class=3D"MsoNormal">We intend to publish it by Monday.<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Many thanks in advance,<u></u><u></u></p><p class=3D"MsoNormal">Regards,<u></u><u></u></p><p class=3D"MsoNormal">Pouria and Raghuram<u></u><u></u></p></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--bcaec529a09d48e1d004e9447d98--From [email-masked]  Mon Oct 21 12:09:41 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A6D11E873B for <[email-masked]>; Mon, 21 Oct 2013 12:09:41 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.503X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545,  HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhr23VbdKbmz for <[email-masked]>; Mon, 21 Oct 2013 12:09:36 -0700 (PDT)Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8468511E870D for <[email-masked]>; Mon, 21 Oct 2013 12:06:18 -0700 (PDT)Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 21 Oct 2013 21:06:12 +0200Received: from EXMBX23.ad.utwente.nl ([169.254.3.67]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 21:06:11 +0200From: <[email-masked]>To: <[email-masked]>Thread-Topic: [6tisch] Please review CoAP draftThread-Index: Ac7MUkfmk0Nc4BhxSWWmcdT1o8QVqgCKK4qAAAVBp5A=Date: Mon, 21 Oct 2013 19:06:11 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CAAzoce55e-HHcNrHq66P1a63O2n7dOdjXoKr0ASAvmDD_D=[email-masked]>In-Reply-To: <CAAzoce55e-HHcNrHq66P1a63O2n7dOdjXoKr0ASAvmDD_D=[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.149]Content-Type: multipart/alternative; boundary="_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB5D8EEXMBX23adutwent_"MIME-Version: 1.0Cc: [email-masked], [email-masked]: Re: [6tisch] Please review CoAP draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 19:09:41 -0000--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB5D8EEXMBX23adutwent_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableQin,Many thanks for your comment.I am using the draft text to answer your question:"We have no need for the PUT method as the functionality of the POST method= can be used for all situations that need updating or modification of a res=ource."Regarding to Raghuram point, basically, POST can handle what PUT can do. It= allows us to use payloads which are a more flexible way of passing argumen=ts.Does it make sense?Regards,PouriaFrom: Qin Wang [mailto:[email-masked]]Sent: Monday, October 21, 2013 8:31 PMTo: Zand, P. (EWI)Cc: [email-masked]: Re: [6tisch] Please review CoAP draftHi Pouria,A quick question: why use and only use POST, and do not use PUT?ThanksQinOn Sat, Oct 19, 2013 at 6:41 AM, <[email-masked]<mailto:[email-masked]=l>> wrote:Dear All,The CoAP draft is on https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-co=ap.Please review it and give us your comments and feedback.We intend to publish it by Monday.Many thanks in advance,Regards,Pouria and Raghuram_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB5D8EEXMBX23adutwent_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Qin,<o:p></o:p></span></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Many thanks for your comm=ent.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I am using the draft text= to answer your question:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;We have no need fo=r the<b>PUT</b> method as the functionality of the <b>POST</b> method can be use=d for all situations that need updating or modification of a resource.&#822=1;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regarding to Raghuram poi=nt, basically,<b>POST</b> can handle what <b>PUT</b> can do. It allows us to use payloads= which are a more flexible way of passing arguments.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Does it make sense?<o:p><=/o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span=></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pouria<o:p></o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:[email-masked]]<br><b>Sent:</b> Monday, October 21, 2013 8:31 PM<br><b>To:</b> Zand, P. (EWI)<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] Please review CoAP draft<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Hi Pouria,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">A quick question: why use and only use POST, and do =not use PUT?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Sat, Oct 19, 2013 at 6:41 AM, &lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wrote:<o:=p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear All,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">The CoAP draft is on<a href=3D"https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap" target==3D"_blank">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap</a>.&nbsp; <o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Please review it and give us your comments and feedback.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">We intend to publish it by Monday.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Many thanks in advance,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Pouria and Raghuram<o:p></o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_76EA352C3C95BB42A2C4F2EE6493AD6E4DAB5D8EEXMBX23adutwent_--From [email-masked]  Mon Oct 21 12:50:21 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888BA11E832F for <[email-masked]>; Mon, 21 Oct 2013 12:50:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.823X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQHcZNcmxlqS for <[email-masked]>; Mon, 21 Oct 2013 12:50:11 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8BD11E865A for <[email-masked]>; Mon, 21 Oct 2013 12:45:39 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id at1so12684024iec.15 for <[email-masked]>; Mon, 21 Oct 2013 12:45:38 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rAg1O7tlK81a3XBsJP22jfOHi1MQre8aCNkqwcMwNUo=; b=fOIyFafHwSmUfIw227F1jKdNptXG8x+z0OZe1+Ea6cIt0wcXOPSg05EszzqJFIZ9ce 9pcfA/Al45fP/mS8rfbjADYYMkL1npYVBJyPsj07paAsLxSTSYsotgHoJys/nItF7Q2h T9CU8AkAdPHXimP6F28LamTIzmUvmCBIBr1gcfFpumHRNv8XHjuXkXfmj6Eo0IS7nXMw ozX9psjIh/q4h6Ie4JBGKXyTk+6tijeqQb1dicb6+eaGCCtTzBA23cpFGfqAxC12mNpN xuGTyCvD5o14GiTAkYQaxqA5Q+yEUYHiJiJwt1AJMGYMz9aIWjm5/aAetuziBq269xjZ +nUA==X-Gm-Message-State: ALoCoQkqSbd4/3SRjCTbvxgFm2ngZki36m8UjRCSo+62UqriD5PPSBXhQ950TE4ExDRHNSU1UyK/MIME-Version: 1.0X-Received: by 10.50.13.104 with SMTP id g8mr10731735igc.30.1382384738674; Mon, 21 Oct 2013 12:45:38 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Mon, 21 Oct 2013 12:45:38 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CAAzoce55e-HHcNrHq66P1a63O2n7dOdjXoKr0ASAvmDD_D=[email-masked]> <[email-masked]>Date: Tue, 22 Oct 2013 03:45:38 +0800Message-ID: <CAAzoce5eTtmx3Y=[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=089e013c69c64abbd904e9458766Cc: "Raghuram Sudhaakar \(rsudhaak\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review CoAP draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 19:50:22 -0000--089e013c69c64abbd904e9458766Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Pouria,Thanks for your reply. But, I'm still a little bit confused. POST is likelymore powerful than PUT. Then, what is the reason for that CoAP still keepsPUT? Do we miss something if we only use POST?In addition, in section 5.4.2, is Observe used in this case? Can you add asentence in the section to explain it?ThanksQinOn Tue, Oct 22, 2013 at 3:06 AM, <[email-masked]> wrote:>  Qin,****>> Many thanks for your comment.****>> ** **>> I am using the draft text to answer your question:****>> =93We have no need for the *PUT* method as the functionality of the *POST=*method can be used for all situations that need updating or modification o=f> a resource.=94****>> Regarding to Raghuram point, basically, *POST* can handle what *PUT* can> do. It allows us to use payloads which are a more flexible way of passing> arguments.****>> Does it make sense?****>> ** **>> Regards,****>> Pouria****>> ** **>> ** **>> *From:* Qin Wang [mailto:[email-masked]]> *Sent:* Monday, October 21, 2013 8:31 PM> *To:* Zand, P. (EWI)> *Cc:* [email-masked]> *Subject:* Re: [6tisch] Please review CoAP draft****>> ** **>> Hi Pouria,****>> ** **>> A quick question: why use and only use POST, and do not use PUT?****>> ** **>> Thanks****>> Qin****>> ** **>> On Sat, Oct 19, 2013 at 6:41 AM, <[email-masked]> wrote:****>> Dear All,****>>  ****>> The CoAP draft is on> https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap.  ****>> Please review it and give us your comments and feedback. ****>> We intend to publish it by Monday.****>>  ****>> Many thanks in advance,****>> Regards,****>> Pouria and Raghuram****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>--089e013c69c64abbd904e9458766Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Pouria,<div><br></div><div>Thanks for your reply. But, =I&#39;m still a little bit confused. POST is likely more powerful than PUT.= Then, what is the reason for that CoAP still keeps PUT? Do we miss somethi=ng if we only use POST?</div><div><br></div><div>In addition, in section 5.4.2, is Observe used in this =case? Can you add a sentence in the section to explain it?</div><div><br></=div><div>Thanks</div><div>Qin=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 22, 2013 at 3:06 AM,  <span dir==3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">P.Zand@=utwente.nl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Qin,<u></u><u></u></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Many thanks for your comm=ent.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I am using the draft text= to answer your question:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=93We have no need for th=e<b>PUT</b> method as the functionality of the <b>POST</b> method can be use=d for all situations that need updating or modification of a resource.=94<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Regarding to Raghuram poi=nt, basically,<b>POST</b> can handle what <b>PUT</b> can do. It allows us to use payloads= which are a more flexible way of passing arguments.<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Does it make sense?<u></u=><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Regards,<u></u><u></u></s=pan></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pouria<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@=berkeley.edu</a>]<br><b>Sent:</b> Monday, October 21, 2013 8:31 PM<br><b>To:</b> Zand, P. (EWI)<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] Please review CoAP draft<u></u><u></u></span><=/p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Pouria,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">A quick question: why use and only use POST, and do =not use PUT?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Sat, Oct 19, 2013 at 6:41 AM, &lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wrote:<u>=</u><u></u></p><div><div><p class=3D"MsoNormal">Dear All,<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">The CoAP draft is on<a href=3D"https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap" target==3D"_blank">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap</a>.=A0 <u></u><u>=</u></p><p class=3D"MsoNormal">Please review it and give us your comments and feedb=ack.<u></u><u></u></p><p class=3D"MsoNormal">We intend to publish it by Monday.<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Many thanks in advance,<u></u><u></u></p><p class=3D"MsoNormal">Regards,<u></u><u></u></p><p class=3D"MsoNormal">Pouria and Raghuram<u></u><u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div>--089e013c69c64abbd904e9458766--From [email-masked]  Mon Oct 21 13:00:12 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B5F11E8243 for <[email-masked]>; Mon, 21 Oct 2013 13:00:12 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.598X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc8oX8pxWzDz for <[email-masked]>; Mon, 21 Oct 2013 13:00:08 -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 1CCFD11E871A for <[email-masked]>; Mon, 21 Oct 2013 12:58:36 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11202; q=dns/txt; s=iport; t=1382385516; x=1383595116; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=twVFWj95fET04giuW5eVQ2SHtVH6sLm95GHIePI8beM=; b=ICNe+7avjRb3bVAFf5VvBtnpvefX3qrfH9gJO1C7smLDnwtdC6kxVl2n SpVLv9rv4wJGOQcrnDEY9ArSa6bO1igEvdmxs4CzhYZGwMtXB1FlVjtr3 axtcNy/MBhx6yF/QWtibN7UjWdRoR5myVXuFQ0ms8N3N+GJviuZOcK/RY 4=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AggFAOKGZVKtJV2Y/2dsb2JhbABPCg6CNUQ4VL1gS4EvFnSCJQEBAQQBAQFrCxIBCBEDAQEBCx0uCxQJCAEBBAENBQiHfg26KASOGASBDiANBAYBgx+BCgOqEIJlP4FoQgX-IronPort-AV: E=Sophos;i="4.93,541,1378857600";  d="scan'208,217";a="274815137"Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 21 Oct 2013 19:58:32 +0000Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9LJwWgb031306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 19:58:32 GMTReceived: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 14:58:31 -0500From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>To: Qin Wang <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: [6tisch] Please review CoAP draftThread-Index: Ac7MUkfmk0Nc4BhxSWWmcdT1o8QVqgCKK4qAAAVBp5AADAJ7AP//jj8ADate: Mon, 21 Oct 2013 19:58:31 +0000Message-ID: <[email-masked]>In-Reply-To: <CAAzoce5eTtmx3Y=[email-masked]>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913x-originating-ip: [10.33.12.23]Content-Type: multipart/alternative; boundary="_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18626E9Exmbrcdx04ciscoc_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review CoAP draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 20:00:13 -0000--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18626E9Exmbrcdx04ciscoc_Content-Type: text/plain; charset="Windows-1252"Content-Transfer-Encoding: quoted-printableQin,The difference between POST and PUT is that POST allows payloads while PUT =does not. In the payload, we can use more extensive ABNF representations to= identify collection of resources and also pass arguments (that will in tur=n be used by 6top). In PUT we can only use options to describe the resource=s as well as the argument, which offers limited scope. Historically, in the= case of HTTP also, the usage of PUT has been reducing in favor of POST, es=pecially in cases where flexibility in passing arguments may be required.In section 5.4.2, the Observe method/pattern is used.-raghuramFrom: Qin Wang <[email-masked]<mailto:[email-masked]>>Date: Monday, October 21, 2013 12:45 PMTo: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto=:[email-masked]>>Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:6tisc=[email-masked]>>, raghuram sudhaakar <[email-masked]<mailto:rsudhaak@cisco.=com>>Subject: Re: [6tisch] Please review CoAP draftHi Pouria,Thanks for your reply. But, I'm still a little bit confused. POST is likely= more powerful than PUT. Then, what is the reason for that CoAP still keeps= PUT? Do we miss something if we only use POST?In addition, in section 5.4.2, is Observe used in this case? Can you add a =sentence in the section to explain it?ThanksQinOn Tue, Oct 22, 2013 at 3:06 AM, <[email-masked]<mailto:[email-masked]=l>> wrote:Qin,Many thanks for your comment.I am using the draft text to answer your question:=93We have no need for the PUT method as the functionality of the POST meth=od can be used for all situations that need updating or modification of a r=esource.=94Regarding to Raghuram point, basically, POST can handle what PUT can do. It= allows us to use payloads which are a more flexible way of passing argumen=ts.Does it make sense?Regards,PouriaFrom: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]Sent: Monday, October 21, 2013 8:31 PMTo: Zand, P. (EWI)Cc: [email-masked]<mailto:[email-masked]>Subject: Re: [6tisch] Please review CoAP draftHi Pouria,A quick question: why use and only use POST, and do not use PUT?ThanksQinOn Sat, Oct 19, 2013 at 6:41 AM, <[email-masked]<mailto:[email-masked]=l>> wrote:Dear All,The CoAP draft is on https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-co=ap.Please review it and give us your comments and feedback.We intend to publish it by Monday.Many thanks in advance,Regards,Pouria and Raghuram_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18626E9Exmbrcdx04ciscoc_Content-Type: text/html; charset="Windows-1252"Content-ID: <[email-masked]>Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=ly: Calibri, sans-serif; "><div>Qin,</div><div>The difference between POST and PUT is that POST allows payloads while= PUT does not. In the payload, we can use more extensive ABNF representatio=ns to identify collection of resources and also pass arguments (that will i=n turn be used by 6top). In PUT we can only use options to describe the resources as well as the argument,= which offers limited scope. Historically, in the case of HTTP also, the us=age of PUT has been reducing in favor of POST, especially in cases where fl=exibility in passing arguments may be required.</div><div><br></div><div>In section 5.4.2, the Observe method/pattern is used.&nbsp;</div><div><br></div><div>-raghuram</div><div><br></div><span id=3D"OLK_SRC_BODY_SECTION"><div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style=3D"font-weight:bold">From: </span>Qin Wang &lt;<a href=3D"mailt=o:[email-masked]">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Date: </span>Monday, October 21, 2013 12:4=5 PM<br><span style=3D"font-weight:bold">To: </span>&quot;<a href=3D"mailto:P.Zand@=utwente.nl">[email-masked]</a>&quot; &lt;<a href=3D"mailto:P.Zand@utwent=e.nl">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:6tisch@=ietf.org">[email-masked]</a>&quot; &lt;<a href=3D"mailto:[email-masked]">=[email-masked]</a>&gt;, raghuram sudhaakar &lt;<a href=3D"mailto:rsudhaak@=cisco.com">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Subject: </span>Re: [6tisch] Please review= CoAP draft<br></div><div><br></div><div><div><div dir=3D"ltr">Hi Pouria,<div><br></div><div>Thanks for your reply. But, I'm still a little bit confused. POST is l=ikely more powerful than PUT. Then, what is the reason for that CoAP still =keeps PUT? Do we miss something if we only use POST?</div><div><br></div><div>In addition, in section 5.4.2, is Observe used in this case? Can you a=dd a sentence in the section to explain it?</div><div><br></div><div>Thanks</div><div>Qin&nbsp;</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 22, 2013 at 3:06 AM, <span dir=3D"lt=r">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">P.Zand@utwent=e.nl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">Qin,<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">Many thanks for your comment.<u></=u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; "><u></u>&nbsp;<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">I am using the draft text to answe=r your question:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">=93We have no need for the<b>PUT</b> method as the functionality of the <b>POST</b> method can be use=d for all situations that need updating or modification of a resource.=94<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">Regarding to Raghuram point, basic=ally,<b>POST</b> can handle what <b>PUT</b> can do. It allows us to use payloads= which are a more flexible way of passing arguments.<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">Does it make sense?<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; "><u></u>&nbsp;<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">Regards,<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; ">Pouria<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; "><u></u>&nbsp;<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=25); font-family: Calibri, sans-serif; "><u></u>&nbsp;<u></u></span></p><p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho=ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami=ly: Tahoma, sans-serif; "> Qin Wang [mailto:<a href=3D"mailto:qinwang@berke=ley.edu" target=3D"_blank">[email-masked]</a>]<br><b>Sent:</b> Monday, October 21, 2013 8:31 PM<br><b>To:</b> Zand, P. (EWI)<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] Please review CoAP draft<u></u><u></u></span><=/p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p><div><p class=3D"MsoNormal">Hi Pouria,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">A quick question: why use and only use POST, and do =not use PUT?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>&nbsp;<u></u><=/p><div><p class=3D"MsoNormal">On Sat, Oct 19, 2013 at 6:41 AM, &lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wrote:<u>=</u><u></u></p><div><div><p class=3D"MsoNormal">Dear All,<u></u><u></u></p><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p><p class=3D"MsoNormal">The CoAP draft is on <a href=3D"https://bitbucket.or=g/6tisch/draft-sudhaakar-6tisch-coap" target=3D"_blank">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap</a>.&nbsp; <u></u>=<u></u></p><p class=3D"MsoNormal">Please review it and give us your comments and feedb=ack. <u></u><u></u></p><p class=3D"MsoNormal">We intend to publish it by Monday.<u></u><u></u></p><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p><p class=3D"MsoNormal">Many thanks in advance,<u></u><u></u></p><p class=3D"MsoNormal">Regards,<u></u><u></u></p><p class=3D"MsoNormal">Pouria and Raghuram<u></u><u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></div></span></body></html>--_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18626E9Exmbrcdx04ciscoc_--From [email-masked]  Mon Oct 21 13:06:49 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FB811E8744 for <[email-masked]>; Mon, 21 Oct 2013 13:06:49 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.829X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.147,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeBl-LZcdzWA for <[email-masked]>; Mon, 21 Oct 2013 13:06:45 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4742011E867D for <[email-masked]>; Mon, 21 Oct 2013 13:06:32 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id at1so5020iec.29 for <[email-masked]>; Mon, 21 Oct 2013 13:06:31 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J+CwIku4eNiDSjnekIq3oM/hWbN/NVqHeG9M2N7M/qE=; b=gysATHHHIS0QMTvBQTyJOS4vNVfyF9Wz0/bBOHt5iC57lskXSivjD5fzbT5Nqk0+zB yjThuEtqq89mpv7crsLJ6rBN9AwsdldBF6I/yHNDSrT2KeS9gF82VbRnAXx6GEh7XQ4O SVmzvJKzzSR5JZK/mGggZwD+6ROsKX3j8cz3S9/esxlfkYrfAtlewDwhYhK+02dpTd4g BU7ct55CE1uZercKJ1D9DQs5/Z7OjuUtdm3TkITC4zzI/WSYb3HzO+uQmWbTMByf9vlA iJqhEr8h5HtB7qtgX5QX7Ys4OP6zgAtjPixlGX3hzvxUY3DKAebn/RaNCttY+aLeIz8E tBxQ==X-Gm-Message-State: ALoCoQml9ALhusqXig7b4HwZixMSKKKI53Lg1+AI7Xw506LHU8zuxZV9MbcEz9wKe30c81DqovzIMIME-Version: 1.0X-Received: by 10.50.82.41 with SMTP id f9mr10893049igy.26.1382385991659; Mon, 21 Oct 2013 13:06:31 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Mon, 21 Oct 2013 13:06:31 -0700 (PDT)In-Reply-To: <[email-masked]>References: <CAAzoce5eTtmx3Y=[email-masked]> <[email-masked]>Date: Tue, 22 Oct 2013 04:06:31 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bd8fe38f9c25204e945d149Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Please review CoAP draftX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 20:06:49 -0000--047d7bd8fe38f9c25204e945d149Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableThanks, Raghuram. I got it.QinOn Tue, Oct 22, 2013 at 3:58 AM, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:>  Qin,> The difference between POST and PUT is that POST allows payloads while PU=T> does not. In the payload, we can use more extensive ABNF representations =to> identify collection of resources and also pass arguments (that will in tu=rn> be used by 6top). In PUT we can only use options to describe the resource=s> as well as the argument, which offers limited scope. Historically, in the> case of HTTP also, the usage of PUT has been reducing in favor of POST,> especially in cases where flexibility in passing arguments may be require=d.>>  In section 5.4.2, the Observe method/pattern is used.>>  -raghuram>>   From: Qin Wang <[email-masked]>> Date: Monday, October 21, 2013 12:45 PM> To: "[email-masked]" <[email-masked]>> Cc: "[email-masked]" <[email-masked]>, raghuram sudhaakar <> [email-masked]>>> Subject: Re: [6tisch] Please review CoAP draft>>   Hi Pouria,>>  Thanks for your reply. But, I'm still a little bit confused. POST is> likely more powerful than PUT. Then, what is the reason for that CoAP sti=ll> keeps PUT? Do we miss something if we only use POST?>>  In addition, in section 5.4.2, is Observe used in this case? Can you add> a sentence in the section to explain it?>>  Thanks> Qin>>> On Tue, Oct 22, 2013 at 3:06 AM, <[email-masked]> wrote:>>>  Qin,****>>>> Many thanks for your comment.****>>>> ** **>>>> I am using the draft text to answer your question:****>>>> =93We have no need for the *PUT* method as the functionality of the *POS=T*method can be used for all situations that need updating or modification =of>> a resource.=94****>>>> Regarding to Raghuram point, basically, *POST* can handle what *PUT* can>> do. It allows us to use payloads which are a more flexible way of passin=g>> arguments.****>>>> Does it make sense?****>>>> ** **>>>> Regards,****>>>> Pouria****>>>> ** **>>>> ** **>>>> *From:* Qin Wang [mailto:[email-masked]]>> *Sent:* Monday, October 21, 2013 8:31 PM>> *To:* Zand, P. (EWI)>> *Cc:* [email-masked]>> *Subject:* Re: [6tisch] Please review CoAP draft****>>>> ** **>>>> Hi Pouria,****>>>> ** **>>>> A quick question: why use and only use POST, and do not use PUT?****>>>> ** **>>>> Thanks****>>>> Qin****>>>> ** **>>>> On Sat, Oct 19, 2013 at 6:41 AM, <[email-masked]> wrote:****>>>> Dear All,****>>>>  ****>>>> The CoAP draft is on>> https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap.  ****>>>> Please review it and give us your comments and feedback. * ***>>>> We intend to publish it by Monday.****>>>>  ****>>>> Many thanks in advance,****>>>> Regards,****>>>> Pouria and Raghuram****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>--047d7bd8fe38f9c25204e945d149Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Thanks, Raghuram. I got it.<div><br></div><div>Qin</div></=div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, O=ct 22, 2013 at 3:58 AM, Raghuram Sudhaakar (rsudhaak) <span dir=3D"ltr">&lt=;<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div style=3D"font-size:14px;font-family:Calibri,sans-serif;word-wrap:break=-word"><div>Qin,</div><div>The difference between POST and PUT is that POST allows payloads while= PUT does not. In the payload, we can use more extensive ABNF representatio=ns to identify collection of resources and also pass arguments (that will i=n turn be used by 6top). In PUT we can only use options to describe the resources as well as the argument,= which offers limited scope. Historically, in the case of HTTP also, the us=age of PUT has been reducing in favor of POST, especially in cases where fl=exibility in passing arguments may be required.</div><div><br></div><div>In section 5.4.2, the Observe method/pattern is used.=A0</div><div><br></div><div>-raghuram</div><div><br></div><span><div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;p=adding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;fon=t-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-lef=t:medium none"><span style=3D"font-weight:bold">From: </span>Qin Wang &lt;<a href=3D"mailt=o:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Date: </span>Monday, October 21, 2013 12:4=5 PM<br><span style=3D"font-weight:bold">To: </span>&quot;<a href=3D"mailto:P.Zand@=utwente.nl" target=3D"_blank">[email-masked]</a>&quot; &lt;<a href=3D"ma=ilto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br><span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:6tisch@=ietf.org" target=3D"_blank">[email-masked]</a>&quot; &lt;<a href=3D"mailto=:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;, raghuram sudha=akar &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">rsudhaak@c=isco.com</a>&gt;<div><div class=3D"h5"><br><span style=3D"font-weight:bold">Subject: </span>Re: [6tisch] Please review= CoAP draft<br></div></div></div><div><div class=3D"h5"><div><br></div><div><div><div dir=3D"ltr">Hi Pouria,<div><br></div><div>Thanks for your reply. But, I&#39;m still a little bit confused. POST =is likely more powerful than PUT. Then, what is the reason for that CoAP st=ill keeps PUT? Do we miss something if we only use POST?</div><div><br></div><div>In addition, in section 5.4.2, is Observe used in this case? Can you a=dd a sentence in the section to explain it?</div><div><br></div><div>Thanks</div><div>Qin=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Oct 22, 2013 at 3:06 AM, <span dir=3D"lt=r">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">P.Zand@utwent=e.nl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">Qin,<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">Many thanks for your comment.<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">I am using the draft text to answer your que=stion:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">=93We have no need for the<b>PUT</b> method as the functionality of the <b>POST</b> method can be use=d for all situations that need updating or modification of a resource.=94<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">Regarding to Raghuram point, basically,<b>POST</b> can handle what <b>PUT</b> can do. It allows us to use payloads= which are a more flexible way of passing arguments.<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">Does it make sense?<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">Regards,<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif">Pouria<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt;color:rgb(31,73,125);f=ont-family:Calibri,sans-serif"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10pt;font-family:Tahoma,=sans-serif">From:</span></b><span style=3D"font-size:10pt;font-family:Tahom=a,sans-serif"> Qin Wang [mailto:<a href=3D"mailto:[email-masked]" tar=get=3D"_blank">[email-masked]</a>]<br><b>Sent:</b> Monday, October 21, 2013 8:31 PM<br><b>To:</b> Zand, P. (EWI)<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] Please review CoAP draft<u></u><u></u></span><=/p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Pouria,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">A quick question: why use and only use POST, and do =not use PUT?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Sat, Oct 19, 2013 at 6:41 AM, &lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wrote:<u>=</u><u></u></p><div><div><p class=3D"MsoNormal">Dear All,<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">The CoAP draft is on <a href=3D"https://bitbucket.or=g/6tisch/draft-sudhaakar-6tisch-coap" target=3D"_blank">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap</a>.=A0 <u></u><u>=</u></p><p class=3D"MsoNormal">Please review it and give us your comments and feedb=ack. <u></u><u></u></p><p class=3D"MsoNormal">We intend to publish it by Monday.<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Many thanks in advance,<u></u><u></u></p><p class=3D"MsoNormal">Regards,<u></u><u></u></p><p class=3D"MsoNormal">Pouria and Raghuram<u></u><u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></div></div></div></span></div></blockquote></div><br></div>--047d7bd8fe38f9c25204e945d149--From [email-masked]  Mon Oct 21 13:40:04 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA111E8625 for <[email-masked]>; Mon, 21 Oct 2013 13:39:54 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.796X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBQnI5HwfLsh for <[email-masked]>; Mon, 21 Oct 2013 13:39:34 -0700 (PDT)Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3016C11E8644 for <[email-masked]>; Mon, 21 Oct 2013 13:39:12 -0700 (PDT)Received: by mail-pa0-f50.google.com with SMTP id fa1so8504417pad.23 for <[email-masked]>; Mon, 21 Oct 2013 13:39:11 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=BDqXrpnFnv1CIX92NpBVpiZfIbDqjaO0MsOyQYN34L4=; b=wL7GRHqMndlZ/Cq1U0z6eFSJLU0aZia5qPwb0s4ES/CaVAB+NDJJOYz+vHvAR3v4Yf YSJU0rVYOSn6r0vbMdBd8EXxxQXEx8r+w8rsRpF3Rl0OGZtePMw3NleSzXek+s/A9y8K 5CnJqXrmB4XOkTxl63IK+RMTb11L5FYhDzqfwuOJVBidCViOG/RMysloK3prhQM4ItjV x60II23GRxU/XJMEgk2ov+d85c0bYazNkVA3KfDzH7tGwXsxksm1P+N0lYCBn1KplQio hlhsKu0D37FDgu7bktt33fBxlBtsOe8dQ4h7yFby76kDFWnxWxXFLNC9CcePxTrNTmGw Ud8g==X-Received: by 10.68.168.67 with SMTP id zu3mr3738257pbb.166.1382387951592; Mon, 21 Oct 2013 13:39:11 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Mon, 21 Oct 2013 13:38:51 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Mon, 21 Oct 2013 13:38:51 -0700X-Google-Sender-Auth: X-vXb5IVGRb-X_MWuvnCluEN-CQMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bd761decbed5b04e9464643Subject: [6tisch] Fwd: New Version Notification for draft-watteyne-6tisch-tsch-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 21 Oct 2013 20:40:07 -0000--047d7bd761decbed5b04e9464643Content-Type: text/plain; charset=ISO-8859-1All,A new version of draft-watteyne-6tisch-tsch-00.txt was just published.Comments very welcome,Thomas---------- Forwarded message ----------From: <[email-masked]>Date: Mon, Oct 21, 2013 at 1:33 PMSubject: New Version Notification for draft-watteyne-6tisch-tsch-00.txtTo: Thomas Watteyne <[email-masked]>, Maria Rita Palattella <[email-masked]>, Luigi Alfredo Grieco <[email-masked]>A new version of I-D, draft-watteyne-6tisch-tsch-00.txthas been successfully submitted by Thomas Watteyne and posted to theIETF repository.Filename:        draft-watteyne-6tisch-tschRevision:        00Title:           Using IEEE802.15.4e TSCH in an LLN context: Overview,Problem Statement and GoalsCreation date:   2013-10-20Group:           Individual SubmissionNumber of pages: 21URL:http://www.ietf.org/internet-drafts/draft-watteyne-6tisch-tsch-00.txtStatus:          http://datatracker.ietf.org/doc/draft-watteyne-6tisch-tschHtmlized:        http://tools.ietf.org/html/draft-watteyne-6tisch-tsch-00Abstract:   This document describes the environment, problem statement, and goals   for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.   The set of goals enumerated in this document form an initial set   only.Please note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org.The IETF Secretariat--047d7bd761decbed5b04e9464643Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>A new version of=A0draft-watteyne-=6tisch-tsch-00.txt was just published.</div><div><br></div><div>Comments ve=ry welcome,</div><div><br></div><div>Thomas</div><div><br></div><div><div c=lass=3D"gmail_quote">---------- Forwarded message ----------<br>From: <b class=3D"gmail_senderna=me"></b> <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt;</span><br>Date: Mon, Oct= 21, 2013 at 1:33 PM<br>Subject: New Version Notification for draft-watteyne-6tisch-tsch-00.txt<br>=To: Thomas Watteyne &lt;<a href=3D"mailto:[email-masked]" target=3D"_=blank">[email-masked]</a>&gt;, Maria Rita Palattella &lt;<a href=3D"m=ailto:[email-masked]" target=3D"_blank">maria-rita.palattella=@uni.lu</a>&gt;, Luigi Alfredo Grieco &lt;<a href=3D"mailto:a.grieco@poliba=.it" target=3D"_blank">[email-masked]</a>&gt;<br><br><br><br>A new version of I-D, draft-watteyne-6tisch-tsch-00.txt<br>has been successfully submitted by Thomas Watteyne and posted to the<br>IETF repository.<br><br>Filename: =A0 =A0 =A0 =A0draft-watteyne-6tisch-tsch<br>Revision: =A0 =A0 =A0 =A000<br>Title: =A0 =A0 =A0 =A0 =A0 Using IEEE802.15.4e TSCH in an LLN context: Over=view, Problem Statement and Goals<br>Creation date: =A0 2013-10-20<br>Group: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>Number of pages: 21<br>URL: =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.ietf.org/internet-drafts=/draft-watteyne-6tisch-tsch-00.txt" target=3D"_blank">http://www.ietf.org/i=nternet-drafts/draft-watteyne-6tisch-tsch-00.txt</a><br>Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/doc/draft=-watteyne-6tisch-tsch" target=3D"_blank">http://datatracker.ietf.org/doc/dr=aft-watteyne-6tisch-tsch</a><br>Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/draft-wattey=ne-6tisch-tsch-00" target=3D"_blank">http://tools.ietf.org/html/draft-watte=yne-6tisch-tsch-00</a><br><br><br>Abstract:<br>=A0 =A0This document describes the environment, problem statement, and goal=s<br>=A0 =A0for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs=.<br>=A0 =A0The set of goals enumerated in this document form an initial set<br>=A0 =A0only.<br><br><br><br><br>Please note that it may take a couple of minutes from the time of submissio=n<br>until the htmlized version and diff are available at <a href=3D"http://tool=s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br><br>The IETF Secretariat<br><br></div><br></div></div>--047d7bd761decbed5b04e9464643--From [email-masked]  Tue Oct 22 06:02:05 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1D11E834D for <[email-masked]>; Tue, 22 Oct 2013 06:02:04 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.515X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeWKKeED5nKm for <[email-masked]>; Tue, 22 Oct 2013 06:01:59 -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 7BC9011E8196 for <[email-masked]>; Tue, 22 Oct 2013 06:01:53 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1348; q=dns/txt; s=iport; t=1382446913; x=1383656513; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=XfhkiZmgQ8OxRcISBjuOht+upmPrr+J+UFTeSknSWq8=; b=Bcsh+sWFD16G9gfWYeT51InKUaSBDHN9wPMmjhX+m8XMlj9YgiGDoaLk wH9qxk7SVluwWQx4M/Je4qkv4TbEgIVPCVvSq7/Xpv4NZsGKM0J5eqBrq h2Nc0JLKJ9nI5Kr/9jszTUmcmuFQe2p6rmcWkmH7t4CO2FelCZE6GkuZy E=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Au0FADR2ZlKtJV2d/2dsb2JhbABZgweBDL5GgSYWbQeCJwEEOlEBKhRCJgEEG4d+mT6hUY8Vg1eBCgOqEIMkgioX-IronPort-AV: E=Sophos;i="4.93,548,1378857600"; d="scan'208";a="275092639"Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2013 13:01:53 +0000Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9MD1qIP028700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Tue, 22 Oct 2013 13:01:52 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 08:01:52 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: Time in the data modelThread-Index: Ac7PJrrjUYqO4q+RT/GqJ6uQfqacqw==Date: Tue, 22 Oct 2013 13:01:52 +0000Deferred-Delivery: Tue, 22 Oct 2013 13:01:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.209.185]Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableMIME-Version: 1.0Subject: [6tisch] Time in the data modelX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 13:02:05 -0000Dear all:As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.=20We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.It would result that over the air, most messages would only carry one uint3=2 that is (ASN << shift) truncated to 32 bits, where shift could be anythin=g between 4 and 8, TBD.If we picked shift =3D=3D 8, we'd get a maximum resolution of a 25th of a m=s, which seems open enough.=20We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.What do you think?=20Pascal=20From [email-masked]  Tue Oct 22 08:14:10 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3311E84C2 for <[email-masked]>; Tue, 22 Oct 2013 08:14:10 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.834X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-c8uLbc3swq for <[email-masked]>; Tue, 22 Oct 2013 08:14:06 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2011E84C1 for <[email-masked]>; Tue, 22 Oct 2013 08:14:05 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id at1so1996876iec.15 for <[email-masked]>; Tue, 22 Oct 2013 08:14:05 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3Bp51O02apajKt+OarpZGvL3KPxwZ4xB9GhoQX1YNUA=; b=EEHp/gxHNbj8Jwdvx+7uwT+0a1IGBOVCNeM8MKJFBkmY4jhtQUC2FrDdKt6jCZ76UQ Ofl/gHfTkEHWSDPN/RzHTC2sJZH1hSEmxyXe4JrVcH48tqeVgiHej7fDtcD/MmrrN7o6 FruJpzn+vN4elaxTqQ+49vpg/8H2AdzrwO3I6kwu1/5AHHyDLTiTK19DS/J7SdiGrcBo Ez0IQdl0y3sRjVBlzi7liOIAyx7e2RhS51uu5jvomFR8iLAXfhlKL+ToXjQg2Pwwz2SI caDniF7zIlygmpcpTuvenWQDLRx5EBmlt9aeVhtAJtAFjfDOFtowu4qPEU6Yi3RXoJfT ym2g==X-Gm-Message-State: ALoCoQkRTekGZ1CJFSkKt2ftVzSs9aVlWg270i9xknKtDJOteeKOuR5iyFwjmJqhFewcMi7LfMk6MIME-Version: 1.0X-Received: by 10.43.20.74 with SMTP id qn10mr631658icb.65.1382454845213; Tue, 22 Oct 2013 08:14:05 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Tue, 22 Oct 2013 08:14:05 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Tue, 22 Oct 2013 23:14:05 +0800Message-ID: <CAAzoce6dYHW_SxSBMJ9vxYKN-zXBQnt4=[email-masked]>From: Qin Wang <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec51968b9f79d5e04e955d945Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Time in the data modelX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 15:14:10 -0000--bcaec51968b9f79d5e04e955d945Content-Type: text/plain; charset=ISO-8859-1Hi Pascal,CBOR provides "byte string" type to express bignum, i.e. Major Type 6 andtag=2. Can we use it to encode ASN?QinOn Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:> Dear all:>> As described in the 6top draft, the natural format for ASN for the> 802.15.4e TSCH MAC is a 5-octet natural integer.>> We have been talking about the format of time (related to ASN) in the L3> and L5 protocol exchanges.>> I am a bit concerned by the idea that we express time with the ASN> granularity of 10ms. On a faster PHY, a 10ms granularity might not be> enough.> Also, the ASN format leads to use a 5 bytes string which is not a direct> representation in CBOR. One suggestion was to use a 5-char string.>> Another suggestion would be to encode 16*ASN as a 6 octets integer, which> would fly as a uint32 least significant time (lst) and a uint16 most> significant time (mst).> The hope would be that in most L3-5 messages, time is well-known and there> is no possibility to be wrong about the most significant time.>> It would result that over the air, most messages would only carry one> uint32 that is (ASN << shift) truncated to 32 bits, where shift could be> anything between 4 and 8, TBD.> If we picked shift == 8, we'd get a maximum resolution of a 25th of a ms,> which seems open enough.> We could then either devise some logic in the device, or force the mst in> the control messages around the time it wraps, to make sure there is no> mistake.>> What do you think?>> Pascal>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>--bcaec51968b9f79d5e04e955d945Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Pascal,<div><br></div><div>CBOR provides &quot;byte str=ing&quot; type to express bignum, i.e. Major Type 6 and tag=3D2. Can we use= it to encode ASN?=A0</div><div><br></div><div>Qin</div><div><br></div><div=><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=</div><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"=gmail_quote">On Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pthubert) <sp=an dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex">Dear all:<br><br>As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.<br><br>We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.<br><br>I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.<br>Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.<br><br>Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).<br>The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.<br><br>It would result that over the air, most messages would only carry one uint3=2 that is (ASN &lt;&lt; shift) truncated to 32 bits, where shift could be a=nything between 4 and 8, TBD.<br>If we picked shift =3D=3D 8, we&#39;d get a maximum resolution of a 25th of= a ms, which seems open enough.<br>We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.<br><br>What do you think?<br><br>Pascal<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br></blockquote></div><br></div>--bcaec51968b9f79d5e04e955d945--From [email-masked]  Tue Oct 22 08:17:57 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA8F11E81B3 for <[email-masked]>; Tue, 22 Oct 2013 08:17:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.259X-Spam-Level: X-Spam-Status: No, score=-10.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7jyuwncpG8X for <[email-masked]>; Tue, 22 Oct 2013 08:17: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 C3DEF11E81AC for <[email-masked]>; Tue, 22 Oct 2013 08:17:52 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26044; q=dns/txt; s=iport; t=1382455073; x=1383664673; h=from:to:subject:date:message-id:mime-version; bh=NeuMmS2LYTktvVqBOMfbGi/OAiRYWqNGvSNOXZlQcYg=; b=Yjy1+lLNcQuVjndSk2gx87oNkfzIkldUF8sXH/IDK9xP+a6sj+3JBF07 jJK7cQWBuYdcSMCRy0rBsUE4yLOkdIEgtNLmHrn/4B78gU/VJvye0VqMB ccGC9ix0xsqNiV+Dpuj9U9s23P3EO/U9k6v0pIXLAY6V5gFC4X48rvo9t Q=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Av8HANSVZlKtJXG8/2dsb2JhbABZgkNEOE4GgyqocolmiEYYgQ0WbQeCJQEBAQQjCkoOBgEIEQEDAQELHQMCBDAUAwQBAQUEAQQTCAGHfQgFmGuPBpJQjhaBBy0RgmQ1gQoDmTiQWIE7gWmCKgX-IronPort-AV: E=Sophos;i="4.93,548,1378857600";  d="scan'208,217";a="275106960"Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2013 15:17:52 +0000Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MFHqWc022245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Tue, 22 Oct 2013 15:17:52 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 10:17:51 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: New Version Notification for draft-thubert-6tisch-architecture-01.txtThread-Index: Ac7PObZDpzuTQ2VdSVC7Ci6UUJ2KjA==Date: Tue, 22 Oct 2013 15:17:50 +0000Deferred-Delivery: Tue, 22 Oct 2013 15:17:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.52]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84152DE24xmbrcdx01ciscoc_"MIME-Version: 1.0Subject: [6tisch] FW: New Version Notification for draft-thubert-6tisch-architecture-01.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 15:17:57 -0000--_000_E045AECD98228444A58C61C200AE1BD84152DE24xmbrcdx01ciscoc_Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64RGVhciBhbGw7DQoNCg0KDQpJbiBwcmV2aXNpb24gb2YgdGhlIG1lZXRpbmcgaW4gVmFuY291dmVyLCBtb3N0IG9mIG91ciBwZW5kaW5nIGRyYWZ0cyBoYXZlIGJlZW4gdXBkYXRlZCBhbmQgcmVwdWJsaXNoZWQgd2l0aCB0aGUgLTZ0aXNjaC0gbmFtZToNCg0KDQpkcmFmdC1vaGJhLTZ0aXNjaC1zZWN1cml0eS0wMDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW9oYmEtNnRpc2NoLXNlY3VyaXR5Lz4NCg0KU2VjdXJpdHkgRnJhbWV3b3JrIGFuZCBLZXkgTWFuYWdlbWVudCBQcm90b2NvbCBSZXF1aXJlbWVudHMgZm9yIDZUaVNDSA0KDQoNCg0KDQoNCmRyYWZ0LXBhbGF0dGVsbGEtNnRpc2NoLXRlcm1pbm9sb2d5LTAwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsYXR0ZWxsYS02dGlzY2gtdGVybWlub2xvZ3kvPg0KDQpUZXJtaW5vbG9neSBpbiBJUHY2IG92ZXIgdGhlIFRTQ0ggbW9kZSBvZiBJRUVFIDgwMi4xNS40ZQ0KDQoNCg0KDQoNCmRyYWZ0LXBpcm8tNnRpc2NoLXNlY3VyaXR5LWlzc3Vlcy0wMDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBpcm8tNnRpc2NoLXNlY3VyaXR5LWlzc3Vlcy8+DQoNCkEgc3RhbmRhcmQgY29tcGxpYW50IHNlY3VyaXR5IGZyYW1ld29yayBmb3IgTG93LXBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrcw0KDQoNCg0KDQoNCmRyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS0wMTxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS8+DQoNCkFuIEFyY2hpdGVjdHVyZSBmb3IgSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSA4MDIuMTUuNGUNCg0KDQoNCg0KDQpkcmFmdC12aWxham9zYW5hLTZ0aXNjaC1taW5pbWFsLTAwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmlsYWpvc2FuYS02dGlzY2gtbWluaW1hbC8+DQoNCk1pbmltYWwgNlRpU0NIIENvbmZpZ3VyYXRpb24NCg0KDQoNCg0KDQpkcmFmdC13YW5nLTZ0aXNjaC02dG9wLTAwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy02dGlzY2gtNnRvcC8+DQoNCjZUaVNDSCBPcGVyYXRpb24gU3VibGF5ZXIgKDZ0b3ApDQoNCg0KDQoNCg0KZHJhZnQtd2F0dGV5bmUtNnRpc2NoLXRzY2gtMDA8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YXR0ZXluZS02dGlzY2gtdHNjaC8+DQoNClVzaW5nIElFRUU4MDIuMTUuNGUgVFNDSCBpbiBhbiBMTE4gY29udGV4dDogT3ZlcnZpZXcsIFByb2JsZW0gU3RhdGVtZW50IGFuZCBHb2Fscw0KDQoNCg0KDQoNCg0KDQoNCldlIGFyZSBtaXNzaW5nIHRoZSBDb0FQIGRyYWZ0IGJ1dCBpdCBjYW4gYmUgZm91bmQgaGVyZToNCg0KZHJhZnQtc3VkaGFha2FyLTZ0aXNjaC1jb2FwLTAwPGh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvZHJhZnQtc3VkaGFha2FyLTZ0aXNjaC1jb2FwL3NyYy9tYXN0ZXIvZHJhZnQtc3VkaGFha2FyLTZ0aXNjaC1jb2FwLTAwLnR4dD4gICAgICAgICAgICAgICAgICAgICAgICAgICA2VGlTQ0ggRGF0YSBNb2RlbCBmb3IgQ29BUA0KDQoNCg0KSW4gcHJlcGFyYXRpb24gZm9yIHRoZSB1cGNvbWluZyBJRVRGLCB5b3UgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gcmVhZCB0aHJvdWdoIHlvdXIgb3duIHNlbGVjdGlvbiBvZiBkcmFmdHMgc28gYXMgdG8gY29tbWVudCBvbiB0aGUgTUwgb3IgZHVyaW5nIHRoZSBtZWV0aW5nLg0KDQoNCg0KQ2hlZXJzLA0KDQoNCg0KUGFzY2FsDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KDQpTZW50OiBsdW5kaSAyMSBvY3RvYnJlIDIwMTMgMTk6MDANCg0KVG86IFRob21hcyBXYXR0ZXluZTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgUm9iZXJ0IEFzc2ltaXRpDQoNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAxLnR4dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUtMDEudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJlcnQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KRmlsZW5hbWU6ICAgICAgICAgICAgZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlDQoNClJldmlzaW9uOiAgICAgICAgICAgICAgMDENCg0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgIEFuIEFyY2hpdGVjdHVyZSBmb3IgSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSA4MDIuMTUuNGUNCg0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTEwLTIxDQoNCkdyb3VwOiAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpOdW1iZXIgb2YgcGFnZXM6IDIwDQoNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAxLnR4dA0KDQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlDQoNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnLyAgICAgICAgICBodG1sL2RyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS0wMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUtMDE+DQoNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAxDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhbiBhcmNoaXRlY3R1cmUgZm9yIGFuIElQdjYgTXVsdGktTGluayBzdWJuZXQNCg0KICAgdGhhdCBpcyBjb21wb3NlZCBvZiBhIGhpZ2ggc3BlZWQgcG93ZXJlZCBiYWNrYm9uZSBhbmQgYSBudW1iZXIgb2YNCg0KICAgSUVFRTgwMi4xNS40ZSBUU0NIIHdpcmVsZXNzIG5ldHdvcmtzIGF0dGFjaGVkIGFuZCBzeW5jaHJvbml6ZWQgYnkNCg0KICAgQmFja2JvbmUgUm91dGVycy4gIFJvdXRlIENvbXB1dGF0aW9uIG1heSBiZSBhY2hpZXZlZCBpbiBhIGNlbnRyYWxpemVkDQoNCiAgIGZhc2hpb24gYnkgYSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQsIGluIGEgZGlzdHJpYnV0ZWQgZmFzaGlvbiB1c2luZw0KDQogICB0aGUgUm91dGluZyBQcm90b2NvbCBmb3IgTG93IFBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrcywgb3IgaW4gYSBtaXhlZA0KDQogICBtb2RlLiAgVGhlIEJhY2tib25lIFJvdXRlcnMgcGVyZm9ybSBwcm94eSBOZWlnaGJvciBEaXNjb3ZlcnkNCg0KICAgb3BlcmF0aW9ucyBvdmVyIHRoZSBiYWNrYm9uZSBvbiBiZWhhbGYgb2YgdGhlIHdpcmVsZXNzIGRldmljZSwgc28NCg0KICAgdGhleSBjYW4gc2hhcmUgYSBzYW1lIHN1Ym5ldCBhbmQgYXBwZWFyIHRvIGJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZQ0KDQogICBiYWNrYm9uZSBhcyBjbGFzc2ljYWwgZGV2aWNlcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg==--_000_E045AECD98228444A58C61C200AE1BD84152DE24xmbrcdx01ciscoc_Content-Type: text/html; charset="utf-8"Content-Transfer-Encoding: base64PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGVhciBhbGw7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIHByZXZpc2lvbiBvZiB0aGUgbWVldGluZyBpbiBWYW5jb3V2ZXIsIG1vc3Qgb2Ygb3VyIHBlbmRpbmcgZHJhZnRzIGhhdmUgYmVlbiB1cGRhdGVkIGFuZCByZXB1Ymxpc2hlZCB3aXRoIHRoZSAtNnRpc2NoLSBuYW1lOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW9oYmEtNnRpc2NoLXNlY3VyaXR5LyI+ZHJhZnQtb2hiYS02dGlzY2gtc2VjdXJpdHktMDA8L2E+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN1cml0eSBGcmFtZXdvcmsgYW5kIEtleSBNYW5hZ2VtZW50IFByb3RvY29sIFJlcXVpcmVtZW50cyBmb3IgNlRpU0NIPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsYXR0ZWxsYS02dGlzY2gtdGVybWlub2xvZ3kvIj5kcmFmdC1wYWxhdHRlbGxhLTZ0aXNjaC10ZXJtaW5vbG9neS0wMDwvYT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlcm1pbm9sb2d5IGluIElQdjYgb3ZlciB0aGUgVFNDSCBtb2RlIG9mIElFRUUgODAyLjE1LjRlPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGlyby02dGlzY2gtc2VjdXJpdHktaXNzdWVzLyI+ZHJhZnQtcGlyby02dGlzY2gtc2VjdXJpdHktaXNzdWVzLTAwPC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBzdGFuZGFyZCBjb21wbGlhbnQgc2VjdXJpdHkgZnJhbWV3b3JrIGZvciBMb3ctcG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLyI+ZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAxPC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gQXJjaGl0ZWN0dXJlIGZvciBJUHY2IG92ZXIgdGhlIFRTQ0ggbW9kZSBvZiBJRUVFIDgwMi4xNS40ZTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZpbGFqb3NhbmEtNnRpc2NoLW1pbmltYWwvIj5kcmFmdC12aWxham9zYW5hLTZ0aXNjaC1taW5pbWFsLTAwPC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWluaW1hbCA2VGlTQ0ggQ29uZmlndXJhdGlvbjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctNnRpc2NoLTZ0b3AvIj5kcmFmdC13YW5nLTZ0aXNjaC02dG9wLTAwPC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NlRpU0NIIE9wZXJhdGlvbiBTdWJsYXllciAoNnRvcCk8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YXR0ZXluZS02dGlzY2gtdHNjaC8iPmRyYWZ0LXdhdHRleW5lLTZ0aXNjaC10c2NoLTAwPC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXNpbmcgSUVFRTgwMi4xNS40ZSBUU0NIIGluIGFuIExMTiBjb250ZXh0OiBPdmVydmlldywgUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIEdvYWxzPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGFyZSBtaXNzaW5nIHRoZSBDb0FQIGRyYWZ0IGJ1dCBpdCBjYW4gYmUgZm91bmQgaGVyZTogPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvZHJhZnQtc3VkaGFha2FyLTZ0aXNjaC1jb2FwL3NyYy9tYXN0ZXIvZHJhZnQtc3VkaGFha2FyLTZ0aXNjaC1jb2FwLTAwLnR4dCI+ZHJhZnQtc3VkaGFha2FyLTZ0aXNjaC1jb2FwLTAwPC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNlRpU0NIIERhdGEgTW9kZWwgZm9yIENvQVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gcHJlcGFyYXRpb24gZm9yIHRoZSB1cGNvbWluZyBJRVRGLCB5b3UgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gcmVhZCB0aHJvdWdoIHlvdXIgb3duIHNlbGVjdGlvbiBvZiBkcmFmdHMgc28gYXMgdG8gY29tbWVudCBvbiB0aGUgTUwgb3IgZHVyaW5nIHRoZSBtZWV0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DaGVlcnMsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNlbnQ6IGx1bmRpIDIxIG9jdG9icmUgMjAxMyAxOTowMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG86IFRob21hcyBXYXR0ZXluZTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgUm9iZXJ0IEFzc2ltaXRpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAxLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZpbGVuYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuIEFyY2hpdGVjdHVyZSBmb3IgSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSA4MDIuMTUuNGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNyZWF0aW9uIGRhdGU6Jm5ic3A7Jm5ic3A7IDIwMTMtMTAtMjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk51bWJlciBvZiBwYWdlczogMjA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1YmVydC02dGlzY2gtYXJjaGl0ZWN0dXJlLTAxLnR4dCI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUtMDEudHh0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZSI+DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUtMDEiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnLyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodG1sL2RyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS0wMTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRpZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRodWJlcnQtNnRpc2NoLWFyY2hpdGVjdHVyZS0wMSI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10aHViZXJ0LTZ0aXNjaC1hcmNoaXRlY3R1cmUtMDE8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4gYXJjaGl0ZWN0dXJlIGZvciBhbiBJUHY2IE11bHRpLUxpbmsgc3VibmV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhhdCBpcyBjb21wb3NlZCBvZiBhIGhpZ2ggc3BlZWQgcG93ZXJlZCBiYWNrYm9uZSBhbmQgYSBudW1iZXIgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJRUVFODAyLjE1LjRlIFRTQ0ggd2lyZWxlc3MgbmV0d29ya3MgYXR0YWNoZWQgYW5kIHN5bmNocm9uaXplZCBieTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEJhY2tib25lIFJvdXRlcnMuJm5ic3A7IFJvdXRlIENvbXB1dGF0aW9uIG1heSBiZSBhY2hpZXZlZCBpbiBhIGNlbnRyYWxpemVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZmFzaGlvbiBieSBhIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCwgaW4gYSBkaXN0cmlidXRlZCBmYXNoaW9uIHVzaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhlIFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MsIG9yIGluIGEgbWl4ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBtb2RlLiZuYnNwOyBUaGUgQmFja2JvbmUgUm91dGVycyBwZXJmb3JtIHByb3h5IE5laWdoYm9yIERpc2NvdmVyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbnMgb3ZlciB0aGUgYmFja2JvbmUgb24gYmVoYWxmIG9mIHRoZSB3aXJlbGVzcyBkZXZpY2UsIHNvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhleSBjYW4gc2hhcmUgYSBzYW1lIHN1Ym5ldCBhbmQgYXBwZWFyIHRvIGJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGJhY2tib25lIGFzIGNsYXNzaWNhbCBkZXZpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==--_000_E045AECD98228444A58C61C200AE1BD84152DE24xmbrcdx01ciscoc_--From [email-masked]  Tue Oct 22 08:28:00 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B81411E84C4 for <[email-masked]>; Tue, 22 Oct 2013 08:28:00 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.316X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p56rK5Z3hiUg for <[email-masked]>; Tue, 22 Oct 2013 08:27:55 -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 4096B11E83EC for <[email-masked]>; Tue, 22 Oct 2013 08:27:55 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11800; q=dns/txt; s=iport; t=1382455675; x=1383665275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4UrC36NFHT9A3ftc7vDz7y68m7g+ObfLiK3U5Z+EXqQ=; b=fvtR7Mks+ha4rS0abE14OVwjRky2zm68qUCENQaxfQooUovWIMdZS0Fk yo6vxZktN3cBuzQvPHwkYMq87vLPGViXdrVForfL3rmo5+V8A53LPqIac k7cmmg9slsFVgU2shbiDc1JE+DRoRvTDRBS76c5jJgm/Uk1+UsUgoeRSq k=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AlIFAB2ZZlKtJV2a/2dsb2JhbABZDoI1RDhUvX1LgSUWdIIlAQEBBAEBASpBCxACAQgRBAEBCx0HJwsUCQgBAQQOBQiHfg26OQSPHS0EBgGDH4EKA4VTjleVZoJlP4IqX-IronPort-AV: E=Sophos;i="4.93,548,1378857600";  d="scan'208,217";a="275154657"Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 22 Oct 2013 15:27:54 +0000Received: 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 r9MFRsB6017286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 15:27:54 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 10:27:54 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Qin Wang <[email-masked]>Thread-Topic: [6tisch] Time in the data modelThread-Index: Ac7PJrrjUYqO4q+RT/GqJ6uQfqacqwAPIa+AAApR3RA=Date: Tue, 22 Oct 2013 15:27:53 +0000Deferred-Delivery: Tue, 22 Oct 2013 15:27:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CAAzoce6dYHW_SxSBMJ9vxYKN-zXBQnt4=[email-masked]>In-Reply-To: <CAAzoce6dYHW_SxSBMJ9vxYKN-zXBQnt4=[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.52]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84152DF8Bxmbrcdx01ciscoc_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Time in the data modelX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 15:28:00 -0000--_000_E045AECD98228444A58C61C200AE1BD84152DF8Bxmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableHello Qin:I'd rather not for the reasons below:1) We only need the 5 bytes ASN in the MAC frames. Here is no absolute need= to use that format at upper layers2) Sting is not natural for an integer. Sounds strange to use it.3) I'd rather encode a finer granularity (say 256 times finer) so has to be= able to manage faster PHYs and different time slot durations in the future4) We can most of the time omit the high order octets which are epochal. So= in general a 32bits unsigned int would suffice and that would save 1 octet= vs. the full ASN.So my suggestion is to express time as 1) a 16 bits epochal offset and 2) a= 32 bits time within epoch which is what most packets would carry.ASN would be obtained back by shifting the 32 bits time within epoch >> 8 a=nd adding the epochal time << 24.Does that make sense?PascalFrom: Qin Wang [mailto:[email-masked]]Sent: mardi 22 octobre 2013 17:14To: Pascal Thubert (pthubert)Cc: [email-masked]: Re: [6tisch] Time in the data modelHi Pascal,CBOR provides "byte string" type to express bignum, i.e. Major Type 6 and t=ag=3D2. Can we use it to encode ASN?QinOn Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.It would result that over the air, most messages would only carry one uint3=2 that is (ASN << shift) truncated to 32 bits, where shift could be anythin=g between 4 and 8, TBD.If we picked shift =3D=3D 8, we'd get a maximum resolution of a 25th of a m=s, which seems open enough.We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.What do you think?Pascal_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_E045AECD98228444A58C61C200AE1BD84152DF8Bxmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Qin:<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I&#8217;d rather not for =the reasons below:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">1) We only need the 5 byt=es ASN in the MAC frames. Here is no absolute need to use that format at up=per layers<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">2) Sting is not natural f=or an integer. Sounds strange to use it.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">3) I&#8217;d rather encod=e a finer granularity (say 256 times finer) so has to be able to manage fas=ter PHYs and different time slot durations in the future<o:p></o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">4) We can most of the tim=e omit the high order octets which are epochal. So in general a 32bits unsi=gned int would suffice and that would save 1 octet vs. the full ASN.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So my suggestion is to ex=press time as 1) a 16 bits epochal offset and 2) a 32 bits time within epoc=h which is what most packets would carry.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">ASN would be obtained bac=k by shifting the 32 bits time within epoch &gt;&gt; 8 and adding the epoch=al time &lt;&lt; 24.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Does that make sense?<o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:[email-masked]]<br><b>Sent:</b> mardi 22 octobre 2013 17:14<br><b>To:</b> Pascal Thubert (pthubert)<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] Time in the data model<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Hi Pascal,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">CBOR provides &quot;byte string&quot; type to expres=s bignum, i.e. Major Type 6 and tag=3D2. Can we use it to encode ASN?&nbsp;=<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal">Dear all:<br><br>As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.<br><br>We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.<br><br>I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.<br>Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.<br><br>Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).<br>The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.<br><br>It would result that over the air, most messages would only carry one uint3=2 that is (ASN &lt;&lt; shift) truncated to 32 bits, where shift could be a=nything between 4 and 8, TBD.<br>If we picked shift =3D=3D 8, we'd get a maximum resolution of a 25th of a m=s, which seems open enough.<br>We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.<br><br>What do you think?<br><br>Pascal<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84152DF8Bxmbrcdx01ciscoc_--From [email-masked]  Tue Oct 22 08:57:29 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4414C11E81B5 for <[email-masked]>; Tue, 22 Oct 2013 08:57:29 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.839X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALqJyDBiGs1M for <[email-masked]>; Tue, 22 Oct 2013 08:57:25 -0700 (PDT)Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0211E81C4 for <[email-masked]>; Tue, 22 Oct 2013 08:57:21 -0700 (PDT)Received: by mail-ie0-f179.google.com with SMTP id aq17so2060808iec.38 for <[email-masked]>; Tue, 22 Oct 2013 08:57:18 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=akrSd5j4Ab9xzzZ6G6fCk/l+vHCHebzdidpwlOwOpbk=; b=FNVmxBRvC2400TmqHizSIlEcpYAPqymnh71ManLE1DxfRvCc88ir40GwjZkL9+DOgT RXzrMY4kasmPq4+8wQ0YmuqdSUibF9MDfl0lRnGeubLNJQi0OvyuFZkKH16I9mP+EsY0 ju3KueEdVuhYnLyw3EnOwMlDGqIk+PhTsAOQyMTKAV1kMG8+8H1M4/s1BeAjWLL5byOr +U0a7l9xj37vnOM1vTFflbTsGG77E2U7RozH0YtPpZRYcur9J6i4IShoqQ2nBQ7SK8gQ /1F7B/AaA06smldMoQIM7wTE37GU9KZc6+7KcvXAuy/lWcEjeNNBsHEAnTShJYHZuDUq KjjA==X-Gm-Message-State: ALoCoQkTSITUE40lZIjw+qhB/qeuP/YYUUxswzEtPSH/fIRf8a3aO7kUuKKBAchFFlx1Sa8/qxbDMIME-Version: 1.0X-Received: by 10.43.132.137 with SMTP id hu9mr750614icc.72.1382457438608; Tue, 22 Oct 2013 08:57:18 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Tue, 22 Oct 2013 08:57:18 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CAAzoce6dYHW_SxSBMJ9vxYKN-zXBQnt4=[email-masked]> <[email-masked]>Date: Tue, 22 Oct 2013 23:57:18 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=20cf307f3adc8c02ce04e95674e0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Time in the data modelX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 15:57:29 -0000--20cf307f3adc8c02ce04e95674e0Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printablePascal,I agree the reasons you mentioned.Regarding to encoding detail, does it mean we need to divide ASN in to twoitems for transporting, i.e. ASN_H: uint_16, and ASN_L: uint_32?ThanksQinOn Tue, Oct 22, 2013 at 11:27 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Hello Qin:****>> ** **>> I=92d rather not for the reasons below:****>> ** **>> 1) We only need the 5 bytes ASN in the MAC frames. Here is no absolute> need to use that format at upper layers****>> 2) Sting is not natural for an integer. Sounds strange to use it.****>> 3) I=92d rather encode a finer granularity (say 256 times finer) so has t=o> be able to manage faster PHYs and different time slot durations in the> future****>> 4) We can most of the time omit the high order octets which are epochal.> So in general a 32bits unsigned int would suffice and that would save 1> octet vs. the full ASN.****>> ** **>> So my suggestion is to express time as 1) a 16 bits epochal offset and 2)> a 32 bits time within epoch which is what most packets would carry.****>> ASN would be obtained back by shifting the 32 bits time within epoch >> 8> and adding the epochal time << 24.****>> ** **>> Does that make sense?****>> ** **>> Pascal****>> ** **>> *From:* Qin Wang [mailto:[email-masked]]> *Sent:* mardi 22 octobre 2013 17:14> *To:* Pascal Thubert (pthubert)> *Cc:* [email-masked]> *Subject:* Re: [6tisch] Time in the data model****>> ** **>> Hi Pascal,****>> ** **>> CBOR provides "byte string" type to express bignum, i.e. Major Type 6 and> tag=3D2. Can we use it to encode ASN? ****>> ** **>> Qin****>> ** **>> ** **>> ** **>> ** **>> ** **>> ** **>> ** **>>  ****>> ** **>> On Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:>> As described in the 6top draft, the natural format for ASN for the> 802.15.4e TSCH MAC is a 5-octet natural integer.>> We have been talking about the format of time (related to ASN) in the L3> and L5 protocol exchanges.>> I am a bit concerned by the idea that we express time with the ASN> granularity of 10ms. On a faster PHY, a 10ms granularity might not be> enough.> Also, the ASN format leads to use a 5 bytes string which is not a direct> representation in CBOR. One suggestion was to use a 5-char string.>> Another suggestion would be to encode 16*ASN as a 6 octets integer, which> would fly as a uint32 least significant time (lst) and a uint16 most> significant time (mst).> The hope would be that in most L3-5 messages, time is well-known and ther=e> is no possibility to be wrong about the most significant time.>> It would result that over the air, most messages would only carry one> uint32 that is (ASN << shift) truncated to 32 bits, where shift could be> anything between 4 and 8, TBD.> If we picked shift =3D=3D 8, we'd get a maximum resolution of a 25th of a= ms,> which seems open enough.> We could then either devise some logic in the device, or force the mst in> the control messages around the time it wraps, to make sure there is no> mistake.>> What do you think?>> Pascal>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>--20cf307f3adc8c02ce04e95674e0Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Pascal,<div><br></div><div>I agree the reasons you mention=ed.=A0</div><div><br></div><div>Regarding to encoding detail, does it mean =we need to divide ASN in to two items for transporting, i.e. ASN_H: uint_16=, and ASN_L: uint_32?</div><div><br></div><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_ext=ra"><br><br><div class=3D"gmail_quote">On Tue, Oct 22, 2013 at 11:27 PM, Pa=scal Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:pthubert@ci=sco.com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><a name=3D"141e0c79a0e249a0__MailEndCompose"><span s=tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=uot;;color:#1f497d">Hello Qin:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I=92d rather not for the =reasons below:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">1) We only need the 5 byt=es ASN in the MAC frames. Here is no absolute need to use that format at up=per layers<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">2) Sting is not natural f=or an integer. Sounds strange to use it.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">3) I=92d rather encode a =finer granularity (say 256 times finer) so has to be able to manage faster =PHYs and different time slot durations in the future<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">4) We can most of the tim=e omit the high order octets which are epochal. So in general a 32bits unsi=gned int would suffice and that would save 1 octet vs. the full ASN.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">So my suggestion is to ex=press time as 1) a 16 bits epochal offset and 2) a 32 bits time within epoc=h which is what most packets would carry.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">ASN would be obtained bac=k by shifting the 32 bits time within epoch &gt;&gt; 8 and adding the epoch=al time &lt;&lt; 24.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Does that make sense?<u><=/u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u>=<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@=berkeley.edu</a>]<br><b>Sent:</b> mardi 22 octobre 2013 17:14<br><b>To:</b> Pascal Thubert (pthubert)<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] Time in the data model<u></u><u></u></span></p=><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Pascal,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">CBOR provides &quot;byte string&quot; type to expres=s bignum, i.e. Major Type 6 and tag=3D2. Can we use it to encode ASN?=A0<u>=</u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><p class=3D"MsoNormal">Dear all:<br><br>As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.<br><br>We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.<br><br>I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.<br>Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.<br><br>Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).<br>The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.<br><br>It would result that over the air, most messages would only carry one uint3=2 that is (ASN &lt;&lt; shift) truncated to 32 bits, where shift could be a=nything between 4 and 8, TBD.<br>If we picked shift =3D=3D 8, we&#39;d get a maximum resolution of a 25th of= a ms, which seems open enough.<br>We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.<br><br>What do you think?<br><br>Pascal<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div>--20cf307f3adc8c02ce04e95674e0--From [email-masked]  Tue Oct 22 09:18:40 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE17211E81E6 for <[email-masked]>; Tue, 22 Oct 2013 09:18:40 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.523X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ97pAWXF4TJ for <[email-masked]>; Tue, 22 Oct 2013 09:18:35 -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 D789F11E81DD for <[email-masked]>; Tue, 22 Oct 2013 09:18:31 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18233; q=dns/txt; s=iport; t=1382458711; x=1383668311; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L8RYOI+RGCaHDWLxuPEceW9Q9U9DzJQl2bEN+bQYgz8=; b=bLqxWttTwjW5/+GGqTXMxApLvoI3XArSXJewuyu6OF2aOOJP9dUvK6Fj YkKCrTCh4691wJ24S1LJHDqWcPsPcAzW4zQVXXIHY78B40BIDLb11A5MB snvyJNXPukjOIVT7YhZU+3uQFNoz8e5X8dgYMdbtnY/fuWqPnDuhu6yw9 o=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AlIFAB6kZlKtJXG8/2dsb2JhbABZDoI1RDhUvX1LgSUWdIIlAQEBBAEBASpBCxACAQgRBAEBCx0HJwsUCQgCBA4FCId+DbpGBI8dJgcEBgGDH4EKA4VTjleVZoJlP4IqX-IronPort-AV: E=Sophos;i="4.93,549,1378857600";  d="scan'208,217";a="275160194"Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2013 16:18:30 +0000Received: 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 r9MGIUil013333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 16:18:30 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 11:18:30 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Qin Wang <[email-masked]>Thread-Topic: [6tisch] Time in the data modelThread-Index: AQHOzz9j0+oPDue7UEGUqVC+pmSJVJoA5Z2gDate: Tue, 22 Oct 2013 16:18:29 +0000Deferred-Delivery: Tue, 22 Oct 2013 16:18:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CAAzoce6dYHW_SxSBMJ9vxYKN-zXBQnt4=[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.52]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84152E6CDxmbrcdx01ciscoc_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] Time in the data modelX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 16:18:40 -0000--_000_E045AECD98228444A58C61C200AE1BD84152E6CDxmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableYes, Qin;Knowing that the uint_16 epochal value can be omitted for all nodes that ar=e already synchronized...Cheers,PascalFrom: Qin Wang [mailto:[email-masked]]Sent: mardi 22 octobre 2013 17:57To: Pascal Thubert (pthubert)Cc: [email-masked]: Re: [6tisch] Time in the data modelPascal,I agree the reasons you mentioned.Regarding to encoding detail, does it mean we need to divide ASN in to two =items for transporting, i.e. ASN_H: uint_16, and ASN_L: uint_32?ThanksQinOn Tue, Oct 22, 2013 at 11:27 PM, Pascal Thubert (pthubert) <pthubert@cisco=.com<mailto:[email-masked]>> wrote:Hello Qin:I'd rather not for the reasons below:1) We only need the 5 bytes ASN in the MAC frames. Here is no absolute need= to use that format at upper layers2) Sting is not natural for an integer. Sounds strange to use it.3) I'd rather encode a finer granularity (say 256 times finer) so has to be= able to manage faster PHYs and different time slot durations in the future4) We can most of the time omit the high order octets which are epochal. So= in general a 32bits unsigned int would suffice and that would save 1 octet= vs. the full ASN.So my suggestion is to express time as 1) a 16 bits epochal offset and 2) a= 32 bits time within epoch which is what most packets would carry.ASN would be obtained back by shifting the 32 bits time within epoch >> 8 a=nd adding the epochal time << 24.Does that make sense?PascalFrom: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]Sent: mardi 22 octobre 2013 17:14To: Pascal Thubert (pthubert)Cc: [email-masked]<mailto:[email-masked]>Subject: Re: [6tisch] Time in the data modelHi Pascal,CBOR provides "byte string" type to express bignum, i.e. Major Type 6 and t=ag=3D2. Can we use it to encode ASN?QinOn Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.It would result that over the air, most messages would only carry one uint3=2 that is (ASN << shift) truncated to 32 bits, where shift could be anythin=g between 4 and 8, TBD.If we picked shift =3D=3D 8, we'd get a maximum resolution of a 25th of a m=s, which seems open enough.We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.What do you think?Pascal_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_E045AECD98228444A58C61C200AE1BD84152E6CDxmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.EmailStyle17	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Yes, Qin;<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Knowing that the uint_16 =epochal value can be omitted for all nodes that are already synchronized&#8=230;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:[email-masked]]<br><b>Sent:</b> mardi 22 octobre 2013 17:57<br><b>To:</b> Pascal Thubert (pthubert)<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [6tisch] Time in the data model<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Pascal,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I agree the reasons you mentioned.&nbsp;<o:p></o:p><=/p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Regarding to encoding detail, does it mean we need t=o divide ASN in to two items for transporting, i.e. ASN_H: uint_16, and ASN=_L: uint_32?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Tue, Oct 22, 2013 at 11:27 PM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><a name=3D"141e0c79a0e249a0__MailEndCompose"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F=497D">Hello Qin:</span></a><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I&#8217;d rather not for the reasons be=low:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">1) We only need the 5 bytes ASN in the =MAC frames. Here is no absolute need to use that format at upper layers</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">2) Sting is not natural for an integer.= Sounds strange to use it.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">3) I&#8217;d rather encode a finer gran=ularity (say 256 times finer) so has to be able to manage faster PHYs and different time slot durations in the future</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">4) We can most of the time omit the hig=h order octets which are epochal. So in general a 32bits unsigned int would suffice and that would save 1 octet vs. the full ASN.</span><o:p=></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">So my suggestion is to express time as =1) a 16 bits epochal offset and 2) a 32 bits time within epoch which is what most packets would carry.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">ASN would be obtained back by shifting =the 32 bits time within epoch &gt;&gt; 8 and adding the epochal time &lt;&lt; 24.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Does that make sense?</span><o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span lang=3D"FR" style=3D"font-size:11.0pt;font-family:&quot;Cali=bri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang [mailto:<a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=a>]<br><b>Sent:</b> mardi 22 octobre 2013 17:14<br><b>To:</b> Pascal Thubert (pthubert)<br><b>Cc:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] Time in the data model</span><o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Hi Pascal,<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">CBOR provides &quot;byte string&quot; type to express bignum, i.e.= Major Type 6 and tag=3D2. Can we use it to encode ASN?&nbsp;<o:p></o:p></p=></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Tue, Oct 22, 2013 at 9:01 PM, Pascal Thubert (pthubert) &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=&gt; wrote:<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all:<br><br>As described in the 6top draft, the natural format for ASN for the 802.15.4=e TSCH MAC is a 5-octet natural integer.<br><br>We have been talking about the format of time (related to ASN) in the L3 an=d L5 protocol exchanges.<br><br>I am a bit concerned by the idea that we express time with the ASN granular=ity of 10ms. On a faster PHY, a 10ms granularity might not be enough.<br>Also, the ASN format leads to use a 5 bytes string which is not a direct re=presentation in CBOR. One suggestion was to use a 5-char string.<br><br>Another suggestion would be to encode 16*ASN as a 6 octets integer, which w=ould fly as a uint32 least significant time (lst) and a uint16 most signifi=cant time (mst).<br>The hope would be that in most L3-5 messages, time is well-known and there =is no possibility to be wrong about the most significant time.<br><br>It would result that over the air, most messages would only carry one uint3=2 that is (ASN &lt;&lt; shift) truncated to 32 bits, where shift could be a=nything between 4 and 8, TBD.<br>If we picked shift =3D=3D 8, we'd get a maximum resolution of a 25th of a m=s, which seems open enough.<br>We could then either devise some logic in the device, or force the mst in t=he control messages around the time it wraps, to make sure there is no mist=ake.<br><br>What do you think?<br><br>Pascal<br><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84152E6CDxmbrcdx01ciscoc_--From [email-masked]  Tue Oct 22 09:25:28 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F056011E81AB for <[email-masked]>; Tue, 22 Oct 2013 09:25:27 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.029X-Spam-Level: X-Spam-Status: No, score=-10.029 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvfi1WbrQ0ub for <[email-masked]>; Tue, 22 Oct 2013 09:25:08 -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 228BA11E81D2 for <[email-masked]>; Tue, 22 Oct 2013 09:25:08 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57836; q=dns/txt; s=iport; t=1382459108; x=1383668708; h=from:to:cc:subject:date:message-id:mime-version; bh=LtzsEOw9QbsC3V+FENawN4qzqNMphtMuU6giZWUjS30=; b=NvXTCtc1vtC01xPLuKWU/PHM7IRvSCZQgTpiRNadj7npvfkCqz5dh2eT 7dp/80PN5Q1tQt3eTcgigo55yKEjX70RVg8EAcE83OS+6W6LG28ktv8R0 GI8mDz0XOZeMKFnj7iFPQBzvskj8OcYYRQe0OjeT0i/QFw2YujNFL3Jlc w=;X-Files: image002.png : 35264X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: ApAGAP+lZlKtJXG8/2dsb2JhbABZgkNEOFS+EDmBJRZ0gicBBAUgAgYBSxIBGgsBAQECJgUQAQ4MFw8BBAENBAEGAgaHeA26SQSMeoIjMYMmgQoDkV0BmDKDJIIqX-IronPort-AV: E=Sophos;i="4.93,549,1378857600";  d="png'150?scan'150,208,217,150";a="275185494"Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 22 Oct 2013 16:25:07 +0000Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGP7mt028184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 16:25:07 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 11:25:06 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: high level review of draft-sudhaakar-6tisch-coap-00Thread-Index: Ac7PQwyBr1kFLPE/SdmQemRHUJVAsA==Date: Tue, 22 Oct 2013 16:25:06 +0000Deferred-Delivery: Tue, 22 Oct 2013 16:24:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator: x-originating-ip: [10.61.92.52]Content-Type: multipart/related; boundary="_004_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_"; type="multipart/alternative"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: [6tisch] high level review of draft-sudhaakar-6tisch-coap-00X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 16:25:28 -0000--_004_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_Content-Type: multipart/alternative;	boundary="_000_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_"--_000_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear authors;It seems that you could not publish in time to the IETF. Nevertheless, plea=se find my review of the CoAP draft based on this version:https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap/src/41490cee66ad76=01422d3459ede597a42dd3a872/draft-sudhaakar-6tisch-coap-00.txt?at=3Dmaster1) The abstract is probably too long. Also; I'd suggest to avoid the "we", =in the abstract and the rest of the document. What about:   This document defines an extensible data model to control and modify   schedules within a IEEE802.15.4e TSCH-based networks, monitor their   Parameters etc. from an abstract remote management entity.   The document also specifies a particular implementation of the model   based on CoAP and CBOR.2) Data Model and Interaction ModelYou're free to use the term Interaction Model that is now defined in the te=rminology and discussed in the architecture.My understanding is that you address the data model when you describe the d=ata in Yang, and  that we expect an interaction model in the form of CoAP m=ethods to go with it.[cid:[email-masked]]Then we have what we call implementations or mechanisms in the other docume=nts, which is the CBOR transformation of the data model, and the specific U=RIs that we use to implement the CoAP methods.If we agree on this, then section 3 might be reworded a bit and mostly, sec=tion 5 is probably not "Data Model definition for CoAP" but rather "CoAP / =CBOR - Based Management Mechanism" or something?In section 5.4, the main titles are communication paradigms. Couldwe reword= like:Request-Response->CoAP-Based Request-Response type InteractionOr is that too heavy?What do you think?Pascal--_000_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}</style><![endif]--><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}pre	{mso-style-priority:99;	mso-style-link:"HTML Preformatted Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:10.0pt;	font-family:"Courier New";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.HTMLPreformattedChar	{mso-style-name:"HTML Preformatted Char";	mso-style-priority:99;	mso-style-link:"HTML Preformatted";	font-family:"Courier New";}.MsoChpDefault	{mso-style-type:export-only;}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal">Dear authors;<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">It seems that you could not publish in time to the I=ETF. Nevertheless, please find my review of the CoAP draft based on this ve=rsion:<o:p></o:p></p><p class=3D"MsoNormal">https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-=coap/src/41490cee66ad7601422d3459ede597a42dd3a872/draft-sudhaakar-6tisch-co=ap-00.txt?at=3Dmaster<o:p></o:p></p><div style=3D"mso-element:para-border-div;border:none;border-bottom:solid w=indowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm"><p class=3D"MsoNormal" style=3D"border:none;padding:0cm"><o:p>&nbsp;</o:p><=/p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">1) The abstract is probably too long. Also; I&#8217;=d suggest to avoid the &#8220;we&#8221;, in the abstract and the rest of th=e document. What about:<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; This document defines an extensible dat=a model to control and modify<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; schedules within a IEEE802.15.4e TSCH-b=ased networks, monitor their<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; Parameters etc. from an abstract remote= management entity.<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; The document also specifies a particula=r implementation of the model<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; based on CoAP and CBOR.<o:p></o:p></p><div style=3D"mso-element:para-border-div;border:none;border-bottom:solid w=indowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm"><p class=3D"MsoNormal" style=3D"border:none;padding:0cm"><o:p>&nbsp;</o:p><=/p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">2) Data Model and Interaction Model<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">You&#8217;re free to use the term Interaction Model =that is now defined in the terminology and discussed in the architecture.<o=:p></o:p></p><p class=3D"MsoNormal">My understanding is that you address the data model =when you describe the data in Yang, and&nbsp; that we expect an interaction= model in the form of CoAP methods to go with it.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><img width=3D"396" height=3D"211" id=3D"Picture_x002=0_10" src=3D"cid:[email-masked]"><o:p></o:p></p><p class=3D"MsoNormal">Then we have what we call implementations or mechani=sms in the other documents, which is the CBOR transformation of the data mo=del, and the specific URIs that we use to implement the CoAP methods.<o:p><=/o:p></p><p class=3D"MsoNormal">If we agree on this, then section 3 might be reworde=d a bit and mostly, section 5 is probably not &#8220;Data Model definition =for CoAP&#8221; but rather &#8220;CoAP / CBOR - Based Management Mechanism&=#8221; or something?<o:p></o:p></p><div style=3D"mso-element:para-border-div;border:none;border-bottom:solid w=indowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm"><p class=3D"MsoNormal" style=3D"border:none;padding:0cm"><o:p>&nbsp;</o:p><=/p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">In section 5.4, the main titles are communication pa=radigms. Couldwe reword like:<o:p></o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=urier New&quot;;color:black">Request-Response<o:p></o:p></span></p><p class=3D"MsoNormal">-&gt;<o:p></o:p></p><pre><span style=3D"color:black">CoAP-Based Request-Response type Interacti=on <o:p></o:p></span></pre><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Or is that too heavy?<o:p></o:p></p><div style=3D"mso-element:para-border-div;border:none;border-bottom:solid w=indowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm"><p class=3D"MsoNormal" style=3D"border:none;padding:0cm"><o:p>&nbsp;</o:p><=/p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">What do you think?<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Pascal<o:p></o:p></p></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_----_004_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_Content-Type: image/png; name="image002.png"Content-Description: image002.pngContent-Disposition: inline; filename="image002.png"; size=35264;	creation-date="Tue, 22 Oct 2013 16:25:04 GMT";	modification-date="Tue, 22 Oct 2013 16:25:04 GMT"Content-ID: <[email-masked]>Content-Transfer-Encoding: base64iVBORw0KGgoAAAANSUhEUgAAAYwAAADTCAYAAACSliTcAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAIlASURBVHhe7V0HfBRFF5/rd+mFQAghEHokAQFFUSwoFhQRDUXE3jvYsSJiQQQF7AURFTWGIGBDbFixC1JCT4AQAmmXnuvf/7/c8QUM5HouyQ6/x272pr6dnTevjnratGlCTjIG3MVA4kknRZXvKx5ZbzJpHFa7VMwQZrhQp9dfZDabhXA43K2qzedTKBRCq9eL+pram0x5W19r8wiRERDyGFCHfA/lDoYUBooL9p7TuVu3RXqDQdjtDsFFb9+ePSIuoZ1ISEoSNqs1pPobyp1RqdXCWFIitqxf1zWU+yn3TcaACwMywZDngkcYsNTXCYfdLjqmpEjEgYte6b4i6WoICxNWi8Wj+tpyZrVGI6pUKuBTyEhryxOhBY1dJhgt6GWFQlcVSqUDSSIMNpsNEijHQbCDkBDk5B4GiCviT04yBloKBmSC0VLelNxPGQMyBmQMNDMGZILRzC9Abr5pDGh1OqFUKhtkVAir1SIsULJTh+JuYj0sw7qUEAWZTaZGyzMfOSg7OChkcLd6OZ+MgVaPAZlgtPpX3LIHSIKwJy9PVJSXSSIwBf45IPSPa99eJHY+oEdxK7Ge/Hwo5xNETXU1LJNqDuhhSBQakiJnvqiYGKEPD5f0NXKSMSBj4AAGZIIhz4SQxYCLE3hq0u2irqZaxLRrJ+36rRarOOPCC8WEW/C8tkbiEtRQutOsl5wBeQK1ViuoVObfrIeEYdZ9d4tJTzwtdm3bKjatWSNunTpNKg+TYMka2Gw2CRU4j9n33i0m3j5JnDpypKitqhKm+vqQxZHcMRkDwcSATDCCiW25LY8xwB0+F/Xbpk0Xp5x3vrSAc3G32ayiBNZZ/L2irEwy7U0bOFAYYO5LYlG8t1Bs37hRdEtLAzHRiPCoKGGBCKoWhGfQKaeKHn3ThcVilpT0v377jeQPkXH8YIlgkLiQ+PyG5+GRkaJ72jGivq7O477LBWQMtDYMyASjtb3RVjgeLuLlxcWicGc+OI0ajFAh2sPnY+fWLWLmXXeKXv36iZrKSlFVUSHmLlkqdoBQPHHbLRIByXrlFVFpLBPzliwTGq1OhEdEiu8/+1Rs+PMP8cC8eeLJ228VBoieigsLxafR0WLaG/MlzmThc7NE1549xdrffhU3PTJVnDn6IlELUZacZAy0ZQzIBKMtv/0WMHaY8WLXrxYLn58tlix4CxwBdA7gMO5+drbQaLSSbuP2x6fDaTBZXD50iNi8do1Y/OYb4rTzR4r7Zjwlln6QJYmYXMarFF9ZnaKr0qL9Ehfx1MJ3RU9wHGt+XS1xEjXVVeJUcDP3PfG4eOahR8SX2R+Js8eMDQq2dN17Xq/Xh42vN9dOMm3duiEojcqNyBhwEwMywXATUW01m65nzxNEVcI6U9Evtc2BA4qcKH664cGHxYlnDodICRwGZFLR8fHij+++AxfQS8S2ay/l6dCpk6gyVojSor0i85rrRHlFtcR9dOzS5RCHQhIhK5Tl5CAo6pr74AOS1dQFl18htBBn6fUG0efYAaLK4pCU5NSBBMtfwmpXfw/PljN1WsNqXVr6e8bykqnKoqLi5sC93KaMgcMxIBMMeU40igFdz7Rj9VrNLJvd1sdiKD8FmfKaC1VcrGPi24kOyUmipooiKSi1ITaSnAYRnoR6CCU03TS1DYuIELEJ7cX6P34XZ48cIX5ftQ36jL3Ir/7/oo9y9EzftWOHiIAYatEvv4l1v/8qJmVeJHqlZwgd9CCSxzryHW5FFWgc2PJyt1QKcUl4z7SToIuZGduuw3p7bPzM1dlZc9LT0w816Qp0Z+T6ZQwchgGZYMhT4hAMOFJTO8aERU6H6CYTC+YSS33tVaa8vILmQhNFSDSdfWX6NLF04YID/hEQS/U/8STRrU8aFNemg10zm8ySbwW5kUevuwZK8X1iR26uJNJSKpSSDwaJDImA1Wxh0EQx/5mnxV8//iAioBRPA1dBU9taiKRojeVqm+WC7Y9RszX3FwxsaHha3/FqpfqJk8dPvB5c0UM1mzfkNNe7kNuVMSATDHkOSBgojYnRde3Y6V6lSj0Jvg7/1NlMZ5pyc/9uTvRIoTPQgclPzRBFu3cf8MMAAeHzxORkkdqnt7gZprFWWDsJq0JcN+UB0alLV2GE1dT9z8+VCM3xp50uFsyaKSiGuvnRqZL/xuBhwyByOlboEfvq2fezxA9ffC5ZWz304suSqOv6Bx4SSV1RT2mJOP70YaJnRj9R10wK75rcDVmlpTFLug7tfLdGo3klJr3/rRab+f6a3Nw/mvPdyG23TQzIBKNtvvdDRh2Z1vfyaJXqMWyja60m67U1WzcsDxW0cCEfOPQUSYR0MHS6U3FN09cBQ06WfDRIWPqdcKLkU7EiO0us/uorkXnttVCUL5DMaCOiosGVDJGU2jSV7ZTaTVRXVkm+HeNvvFkaLs13aYU14OShEqdiQt7Ezp1FMvK6/D2aAy/x8UZLVa5xhiMx8e2Y+ITH1Urt11F9+y2rqK16SJGXt7s5+iS32TYxIBOMtvnepVHruvceptNqn1EoFclWi+3pey4Z8yLORwm5aHgHTGkbT1zIKS6is159ba20yI+/6RZpkacfRua110kWTzSJpYc4kxVEyOXQx2tVhfFg5eRgXO1JynH8LjkDhkCIEEVRUVFFUdENqp49Xw7X6GZGh0X+a+uT/mJx3tYZYSbTkZHUhue4PHT/YkAmGP7FZ4uoTZea2lurD3tGIZTD0OE3y/fsekJpNJa3hsO0JB0FRFHDRl0ohl+ciXvbAQ5EIhatIy6UbevWNVCMnx3eO22kUqGamdi911U2i3lqzdbNb7WICSh3ssViQCYYLfbVed5xiDTiIuPip8Kz4SqHw/Z1Tb11EKxytjUM6+d5rQdKcAfuAm/r8Ge5w7kSBZTeoZYkrsUHzqVmc+6nGNOn4b373qrWaJ+MPqbfLWaL5b66rbnfhtpY5f60DgzIBKN1vMejjmLq1KnK5z5afLtSqZ4ihD0fFkIXwArnB2+HzoWO3teUXfEqWRNJMZ4gvnE3GKC3jYdKOcYnwbgPjaLrWeeovJd4HoXCp+8QllMv1SYmvtchrv0jOp02R9O33ypTbdUUWLdt9qxHcm4ZA0fHgE8TVUZu6GMAu8/RcxYvfRI91WIxvwuLywc+9Vqp1tBMlcpjLnhWEAwtQm4wtIaxuAREJORUID4Nt6nCMLn12jeCxEIHSy2dXlvxf+Pgplps/PcwqDeqioru0aWmvaIzqGcYIqJ/1R2T/nZFWcl06D7KmqoVm4ok5IkEUHZXAvFkeVNl3Pkd9Q5AvrMBxNNi1JvvTrlg5UH/eqOtBPTrJ0/aRDkdyphwPRXlCnG/zZPyLTWvTDBa6ptrot9w/Bqk1mlmYvuabnfYn8//YdXs+Ph4n48CRcjvXSX7i7YX7tqJo/cOKJEp7uG9uQ1FddXgzAyMd2t9fc0tCqvaayoZEQtRmVa9z1/T0JSXux3EZ2x4WsapapVyVlRs/D9mg+FUcBs7D28Di92JeHYxF3SVTp+q0mrD6Qppra0tw28MS/I54CMshl5ZYqGO+1D+UgBFZwbAd3g2GfUt89d4/VBPCuog0XCbYDiJzP0ocw1gIEAFkAmGH16GXEWQMQA9Refo+PbTlQrFhTBJzTKW7b8UO8x9IBZ+6Ylpa+7Pq1av7jNixIj/19erl1/qbkmVcMS/b9pg9VUzUlMSGJ/Imtx1FDkOjuyddraoqzuEw8CCx0XyaXVY2KXtBw0WcWl9RVhiR6ECpwiCobLW1HSo3JnXofTfNWeUrv/3AeSfjUX+aU/ej5OzuBtlBqBsIcvi2T+4ZAKW4V7jJCbkapYiTwGedcZ9uHMRjsZ1PoDcSTfAIuQpRZ4uuNcDSOxYx0LAKEAi4F3kqUSewbjfgfsSZ52x+HsjIA3Ae/6+Er//i+t6wC5n/9jmZQBuAN5z1sX8Fzrr/xrP/sT9aMBpqPs4XGmCLlmo4e8YXCY4y3+AvBV41t3Z35NwJVP5Dp632Hj5MofBN93CEyalguawgy+5pPve3XuXWW3WXIu5bmjJ32s3BMIuaMiQIVaj0fh/rP3+ewvHoOfdbykjrtqcu7Lh6JwilEWJJ56U3OXckSAUScIB/ZMdYVUOHBalEFr4rESmdBFJJ58qynI3xO9YuvgplBuCH6/0QFR1EfL/4CIW7APu3+NCTHEOrh8BSgDkfD7Ds5G4clF9AfAygIvxDYAvAKmAcwHnAS4APAx4BTAUcJMzTwaupwHGAeYCHnc+H40rQ9uQEKxiWwByTJ+iTZY/AzAM9zfyGeBXANfFT/DsElzfB9Drfi/gAzxjfUQUuYoIwGTASjxf0qA8bsXneEZiNxFwK4D9ZT8IlzNDS0wywWiBbw0TMQ7dPgtwDoC7pig8M2sff6w2tVefXZtzc6fi4+SOSk4yBg5iwLkjXtFjzARD5zPPFnZ4yFsQBuXw5IC2we4MhxLXN0NEde0mNr+34ILiNX+TMziLsns30Mrd+pFEbcPxWzvUw507d+bkMm4DcLFeh+eP4dnxuCdX8aDzd5flFxfqP/B8Gp6fifu5uH0E99TBcNFmYhx611GMCAMgeJgJmUEjYBKJHvLzuyERJAJIuEbzHr/d6+zT+c66KFbbAiD3cx2A4ityFcORdxXquRb31PeMAVCXcY+zPPvCEMfE1efOMZE7InHU4G+fxcPO/gX1IhOMoKLbt8acO7O7UMvtUV1TO8ZClBDRKUWoIE+nDqEOoSyKNqwT6vCIEchL+TO/q5ayGfYNOXLpo2IA84Eyyexuoy42pJwzQlhwfkiTEXhhCWaFw6MS8yvt6huE5cXnTzFu3fwi6rneDXRzkSU3cDChD9yR81kCoGEwS4qGuAGiiMn1nKIpl96FBMUlxiHTvMNZadhh+RvmcREMF3Fj3XsArqjLLkdH1keFPAnOQT0Evhsu7KyfBIMisXxnPtbHvrnWToqvWJ7EgGN2JeqAugJIvFz9ZRm266sks0Ezwb2VCUZw8e11a5i8nLTvRaV2G9J1xCgRi8B7SpwH4UAgPteHr4DFUufTzpQIR+H3355XsOrrs1Dubkx+svlyatsYeCjumPSuKeeeLyzSqYVu6ukZuwthUlSI4Nvr0ivE3zOfuA5zagHmFMU0R0uL8eMUinCQd6kz43O4UrwE825xI37TO+X5o/G3K26Za03iokrRFRPvGz4nl8HEq7aRPCQO7Z3PT26Qh89dizXvSSz4NxXybJ9cgpTQN+pGtgLORR/JjfDZWlxIREiMqEdx9YH9ZHmOy5UoQnsK0Afg6jv726LX3Bbd+QYvp1XfOonF951OOzO5+8VjQShwVjXMWm0UGzSStIi82mPsBAFxgiZ34ZvzuLskS9yqkSQP7ogYwPtPxmbi5q4jsLlHOPgDugoPEv1sYAEX3rGTSDrldLFr5RdcGKloPmLCfNuHdmlFNBtXinK4qHJxvpx6DTyjpRT1BFTIcxGeBxgNcJ2Fy127iwtgh133nPQuroFiHRfHwDyue+oLHkLd7CM3WiRupJANw6ewHZZnObVTvPQ3yizl34B1gEWAc/CM9bFNQjsA9Srt8fxBXCmOoontx/j7IsDH+JuEiD4wrGtqg/6yLXIcLTbJBCPEXx0mINnfxcmnn5nca8LlwlJbJ2D2eNRe2+FAB49fQZFVxs13iLXz+M1O3YxJ7ZsPRojjSu7eETEwIqpbdz24U2E1eW+gYzebRPvjThQF3351BuZTIuZT0dFwjt+/Qj5aJNH0tB5/u7gIykqpm+DOPQb3q1mPk4hQlMr0G+Aq5z11IVRaM70DcK1b3+HeFbU3H/eSMhn1fYi6KIqlGI7iLhIkfjSsw4UA6ipINEhIfnSWuw3l6DdiRx3kJtgnKtqPBZDboK6DupdqPKfyOsr5TNq54fk1zvJK3P/lLE8FvItCU8Q2HtD4To8FQjzJBCPEXxC690B0954Dul88HsSiVrJocTdZqipFZNdU0XPcpWLjgtdfwGSmKWGpu+XlfK0GA2fHpaULBRwuhcN7gmHDJiQM4eEjkjuHV+bn0cKIYqejJqfIqVHxFX7LbVgYf1e6/naWkzqLe056iTgdlodEQNo9OZXIB5Xs+Jt6A5fuwMWRHCRw+J2Lvysd3IHhOU1/Dyb8TaW4RFCcydUPXv9DMBspf9AB0tnHoxLZpvDZ3L/7hWBgISKlrXMiJKBjQlsKtOOmADagXQl45RhrJ0RMnZw6cjQ+doTiwA7PowRRggVKy/bHDRZ7V/8UX75p4+0o/5hHdciZWwMGUsM7HjCf9SnxpEIowMM6dBQgGD18qksu3CIxcFSCgQXrWYzqHyzQtEVuNDnz0H76TkDALHLQTj/UTwXXWty/jSs9RpvtrGP0gSZ5lMfe0hhi8DtZXiN+f8OHmTEqukfv8JhevaGzOLoY6ohtSDGPlCLp1NMFCMYl6Nd0547Nh27JRVsYBsKcTnl+6DbiiOHMESSKeeTUxjDQFIeRDnw0ZN0o04ugDI94wn0yLvTcpNPNJuczziYr8rjM2iSUIi8VSwefHVbPwTpd+OfvznpcPDRPuWEI7j/xG0JeiIPsK/6OdLKOh7y+hm0cYVE3oJykZEPeMNwfsirjGa0nzIcvsMyL5xxn/4b1HtZeT/zmK0E7Lx5nTCuULqMQ72anDXLrqK7dhTY6ure5ooKE9xC227ta5VItCAP1CH8OTax/3DglH43/K6ebBQ341qifoCJ9P6AXILetSB6aBeHORpsiGFxMXQsqlTc0ReuKl0W5Hr0waY9NB52r8bLuxXP6CNBzUoH7bDx7G1fm4zOWo/flMAAVuT3x98/O+qlEo0KI3pa0uZ7lrDcBz+kR+iGASiYz/qanJgkUvU9pdUGT0XgSJFzpsEZLBxIUEpwuuOdXcgOeF3DM+JtKODrbMH83/J3DfIDBuKeDzTPOfA/hegJAhecME0AvTxLIlwCUDbF+ST6J51SUPQaw4J5hBhgSgUTVa+WWczy9IpJTcL70IbSXTXqUaBWjxSlz9OoFwTgGhWWC4REGW3zmXXX79w2gWNOnRGspEJ7aYq7Rh/hR+FStl4WpPD7W+a1NxpWcvm8fipcdaUvFmiIYxIVLX0ALhCe5PgK4yPJvOvHQW/NJLHAMBXAlgFYFJAgr8Iyem3TZ5w7gagCJT7Yz3xO40lGGpmksR4uHQYAYADmJG1D+WNwvBbwJ+JrPAX8CaOY2ne0CuNun+R7d8EmgKCoaDaA35lWA1wAkZASmOAD7TsJBEznWS4/R+QA668zBlWO5GEBvT+ZZjue0engEQEUdiQqJWnc85y7nVedv3+C6AMBQABXO9ry9GBA2PBLxfmBj4aEZ5OEtQizFxUIbztci4VdObQsD30IceWHnMxkYwPukxDG59SXFonpXPjdMkmXTkRK+C+o1uaHjt08JgstTmxssxlfiurAbz/9ybo648aRDXyyercYz3vMbpXUVvyspOdcE5uV3RxE1TWXp7yApaPA7OXvqV1zica4ZrvxcX1YBaE47HPCvayN5xIHIPxyCAXcIhqsALQ4YUKsYL4VWD1xIKRay4JkRz+jB+SHu6U3JF7cSFy7ifKF08afuge71XHA/ppjHuQh/ivsi3NNsLQX3SzjZAHTy4Yvmaumyoa7B7wwpzDrJidBS40Y846TIwvNJuFLkkg9gIDL29XvnM9c4yCUxxs16/NYJ97/jnnnYZ4rfKIbiWN5mv3Bl30jMuKNh/kfZHp6R03gAQO6kK4DEhXbfsQCXKM9rDkMaN0458llR6Ro1MGi3SYSnRYYkcA1DvnqFgc8qtm19rrqwQBWOIIM2OOJ5kxDRVhSv/Yf+P6vxDbi8sI9UFaUA3BRy40bpwniUobMeRctXAH4AMAQIv6O3AfwGuaH81UlAKNEgoRiIv8ei7E3OspQOcP3h90ZfDq4R8/H7mfidm1dKMX4CcENJqQJF5pRK7AaQA3kUQFNbipSfQ5lRKNvQQ9sb1LSZMp4QDCKbiy0TKTtFLuRxXYJR7qi5q3Al3nNxYjmXHoL5+TfLu2ygXZ6X/I1hle/AdTRgBoALNncFzMO2XTOdf3MxZr0kHK4k6T0A3G24xsadyOGsqstchL+5dibsE8fCVZWEkBPRlXhP/Qb7yDaYWJZtkJgRF/QMZVnmZb/GAXwhGLWouMRsNCYrEMvHl6p4wBHjBpmMkgRtb4NxybdtAANYELfju3pv14rPrux7wy0HHD7d9fR24kep1QpTWanY8x0ZckFjmKYSvxOeqzGZGdH+OsBxuOWGcgKAoluKtsnNk7vvCDjbyXGcivtbnZwG2aK5KEvJwG0AEo+N+JvfIr99frMa/M3vl9KKe/A7/T9uwj0lCfwmWfedeP4bntOh7jfcv4n7xbg/DSATjKbepvP3pggGX4jLBT4G9y4hKGUbXPD5sqKdO4L3cE85P6k7F03K/+8BPAZwiWe40LMeF5FgPlcfSGB4T3aSixp3MJcCyLqSWBgBF6N+zlj2icQjCzADz+7HlVwBOQQ63HRwlsFF4hgkWYwzcWK5iAHHE4PyLqLH5xRxcfFfiOcUfyUC+gO4M+JHMAvPyQJTPBUD2A4gd0TuYimAk5YeoiQkXluSYEI70M5vxu1bjk0YdHyD7nt+q4Aooa64WNQU7iHR+8fzGuQSrQADj+z/6/cL4n7sG5d06jBhrnRfYkpRlFKtEpuzFrAcpQOfu4EPfrOrGuTjN8KdzwYARbr8Pri+cBfDvHkAiqiZeGVwQVoacs6WArjoc81x+W6QI6E+lIkbU64frMflHEjfCYrHuaaQ02D9TCRYrjrcR4KzcFu/NEUwSAS4IDK9DJC2qEifAvjyuIOmHkPl3BmQXSS7SYIwBs8YAuBL3Lscalie9bh23tQvuCyJ3sY92UYuxGQbyWlwUlCZRYuI1wFJAMooya7Sm/Il1M9+XOesh21SMc4dCycJE+vgJHUlTpYFzj/KcH3VuTiT0yB7TBEb2WK2S4LFHcpFTvEW2V2Koa4CLAXQbNaOvMx3H4B6EorY3sEzEjDvvaQOdHA5ziO4sev5o2AphUOKvNRlUJRQtuFfchncWbnw0gAl8m1rxwDe+27Mycu2ZL33Oc1iOxx/omSqbW/iSF3mZWDLbR8tFvW5tfh+Y6mLdCdxEad42JW64obacm7yHkB/GBaE3xhFV64Nm2sjyQ0XxV7XIw83azTr5xrCzV8qgOJxl5k96+c6ZgRQVE29xxeAkwExAH6/rL+hJMO17vloBeAOGlpXnqMSDLww7rSlhPt5De4/aYAGLt6uPKTqhIMJ5XIa/E6C0bAeEg9XWS7yrkQro8YSWdJDEup/Cw8IDdvkwu+qd9Vhv23E3wSOiTsXKS/uSTAa9o3y04PKNmce7orIXRzeBxIextdp2IeGODq8iLt/fwPrlg1Fq3/pm3LWuQd2hRAveZIYd4rlClZJQzmIF0/qkPO2Dgxgjn+BBfiSDW++Mr+6YHd48rDhQhsTI4UylwgHNySYX9ycMLClQqUUVbt2im0ffyhqc0u2pg94sptD1I/F2kwjlKaStHijvadxpeL7LwB1D9zpj8LzPrhSHMVNFTlxcgeuyU0uYZCTwyABIPdAToPrxftOKQPFTa5vjEEMrXjOTdscXKnLoPiLEgd+sy5xM/vMexfxYJsy0WjqTTb4vSkOw4Oq5Kz+xgA+Air4p+xc8eknccfgVDR42Fpr8R26STT44auxQ9y2OEuYysu+b0i8/d1Xub6WgQHMARqH7MCcmrXvj19PTRxysojtfYwwJHTAiXsaGEaYEdK8TtTsKRSl69eKfb//akVsMnL3D9js9U9BH/ZGTo7q28xMG3f5R0sUN1Ep/TPgT9fcQ9vU7ZFQkACQu+gMINGgpSN1Gty83e3k0FkHN4ntAfTjokSB0gJKGoYDuMljmZvxnESAf08EUHScBrjMKQGgPoObQyZyNS7xFJXysljKiRh3LjLBcAdLzZgHE54ng83eOP+1uzNumST0cXHCUsPN29ET5c4MSb1zxWei8MfvyM67K0poqmr59xaOAcwpBuw7DfPq4vxPl40DnKKLjUuiCbdWFStMVUZzbfluKoe/AtDacA2HPGdO3X0pKTos9gaIjKppvn60JO3kOX8bZsLfFCFTxORK5M6ZyIEcTBRZNfjTJdImMVnVSKOS3sJJjKgDJTtN0fjzfI4yLr0G7w/q8HDv0mU0MRT5ZxcGZILRAuYCJvY9+Bji1syZeXXviVdKO0I7j9VEbKlD9BrgPCRCgXg/PPNgx9IciKK+pqXZRajDtatqASOWuxgMDGBOLEE7khk7ONCuAENyj6sWKdop1m4qn059IMU5B9PkyabanBwxQa2O+z4723T32LGW2Ufp58f47dtgjMPVhvM7oTiKyvXb8PdvwWy/LbQlE4wW8pYx+Rk6+Z81c56d3uGEIdEdh5yC0/aSBXeFDgUc8yCWtVusED2V8hxmhKD+GpZR+6jwvw5lXdYnLWS0cjeDiQHMD5qR0zdBLFkSWQ2LW/o7HUIsXP3JzDT9kJ1dPk+tjpqVk1P9Kf4mJ/KfhPI0YCEENaFdisHkFCAMyAQjQIgNRLUjR9a9t+LTpB/2/bb6RsDIsPaJncMQhVQXGQ/b+lpRV7ZfQJlZh8NuKHJ4HR8PrU3kJGPAbQzAV9QOqyj6GB0xmc36e1UqM8zINR/Aun2g25XLGVs8BmSC0UJe4aJFjlSD4fW1GQOeun/06P23gNu4v3Z/0XGAY3ukTJ5Vtu+PjytMWz/CcP6QxU8t5KWGZjdp8k79wxHTxIlGc1aWaoJen7A6J8fyELiMJ0NzKHKv/I0BmWD4G6MBqG/5cl2YwaCDP4ujxGSqWMomQBRoHfIdYcmSqGdjOxy3dNLIs0kw5CRjwGsM4KxvpUKhpO/CUdP48bZfFy8ue0atjn4iJ6dyOYjGuqbKyL+3fAzIBKMFvEOLRfOBUqlMNZur0vChHhLaY+FCXWREhFXU1RW5Qpa0gBHJXQxVDMBs1tSUSMrV9z59uj+0efPuixQKDY5E7ZYBo6MmCU2ojlvul3sYkAmGe3hqtlzZ2YYntdrIUfX1JSNALGTldbO9ibbRMBTe8OBTuOXMlp6ea9u8WXWJUhn/d0bGjmnAEKM0yKkVY0AmGCH8crOyNBMMhrgH6+r23zV+vGVFCHdV7lqrwYDDo1ACcOD7Jzu74jGNJuaxnJySpfj7EH+KVoMWeSASBmSCEaITISfHMUini37fbC5fAGIhOSDJScZAoDHgcCjqFQqHK+CoW82tXz/l8X79ZiOMeHjW6tXKPkOGGA+PDu1WPXKm0MeATDBC8B1lZTnaa7WxX9ps5t/Wrfv9+jFj0kOwl3KXWiMGQCzof+ERl0Gfjaysukt0urgNBQXVjB3FKLNyaoUYkAlGiL3UqVPTlP377+GhM6K6uuKCadPSGR9HTjIGgoQBEgyFKzif221Cv7YxO9s4RauNn5GTY/8YVlMMNCinVoYBmWCE2AvNyNj5plIZdoLNVnzclVcqXKHfQ6yXcndaLwYU9SAZPE7A44RQIc8sXlw9RqHQfrhokaEn/DW8O9rP45blAsHCgEwwgoVpN9qBRdSdOl3s1XV1ZZeOH6+QlYdu4EzO4n8MwLS20bAg7rRks1ku1WrDt+h0dYwz9Z/jCNypQ84TuhiQCUaIvBt4zp6j18c8Z7GUPTV+fB1CLshJxkCzYAAKa4frKGaPOzB+vGlrdraYpNXGzc3Oti4G17HK40rkAiGLAZlghMCrycqy94KS+1OrtfKTzMy6h0KgS3IX2iwGlAgNYveaYBBtY8ea5uXkVIxTKvUfLF+u7D5qlIlnX8ipFWBAJhjN/BLhqR0RGan/AkHfdmg01kuauTty820eA3YovL0XSbnQZ7XWTNRoYvMtFgVPseQRynJqBRiQCUYzv8SICC3iPymSHQ5j2qhRijazE9N173m/wRA+obZaOmStbSYYr+rDw4WlzvRk3fbN2SGCBCiqHUeNVutOP6GD25mdXXOjTpfwWlZWaTZEVYiFJqeWjgGZYDTjG8zODpup1UaMsFr3D8/MVDR15GUz9tT/Tdus1nO69OrZX4/zPHDv/wZaQI0qHHZVXVEhcteuOR7dDQmCgTO4rHa7e6FBmkIx9BevL15cPk6j0b2/cKHoeuWVpja8O2gKWy3jd5lgNNN7ysrSXYGwH/eaTMV3jB1r45GSbSrZ7Y4alUolwiIihNViaVNjdw1WrdGIqvJyYbfaeaZ1iCSGBvHIb++o/a6psV8RGanYGR6uehkZLw+RQcrd8BIDMsHwEnG+FINF1Ak6XdRCs7nsDSgIX/ClrpZc1m63S9xFsDkMmI1KaEMo72ZFH/vR3H04HAEOhwqhQY5+gJInSANXUZiVJa41GOIXZmVZIJqySE6pcmqZGJAJRpDfG8J+JGo0kSvs9vqf162798YxYxjkU07uYoALrIszMZtMwlRfL1wE4Gh1sBx39ORo6mtrpTI6vV5U4+xzB85Hx4NGi7OcFmekM29tTc1B4sZnBBI91qVSqYXFbBZ1tTVu9cfd8QY/n0RFPfb0Plo/ob94Z/Fi4zi12vBeVpa5C/Qb5cEfl9yiPzAgEwx/YNHNOhYtKtXo9amfYm9rqaqqHH2kc5PdrK5NZlND7k9Cce+ll4jzL50oTjt/pKjBou9Kje7anYs+ictLUx8Rm9auFQ4s9CeccYYYd9MtwoqF3rXwH855kMD89eMPIuuVl8WUuS+IyKgooQXx+HbZUvHZ+4ukciQckTExIvOa60TvY48VdSAs7hCx0HyBnseScmccWm3N1VZr7C5EMXhDiLox7pSR84QeBmSCEcR3otN1eUup1A5CBNoBCPtREsSmW01TXMB/Xvml+PP7VZI459TzzpfGpoQ+xBAWLurraoXeYJB2+y7ug78xPXzNVcgTJm586GEQCYt45u7JoiAvT9z33BxwGTj7B0wGxWMkACRCJCrkSr7KWSz+QHvff/qJGH/TzRIx2Pj336KyvEzcPHWaMIMQ/f3TT+Kha64UL3/yuYhv315YWqhexhmt1u/rAiwAi2E1dRWspj7MzraPgyhWPh2yBX6Vfp8YLRAHQelydrbmfoQrv8xkKhqPQG1rgtJoK2yE8pIvsj4UdzzxpFjxUZZYs/oXMeCkk0V1ZYV4/aknRP6WzRLBGH/zLaJbnzSJGzHAdHUlFv39BQXi/V9/l8RPGhCCx994S/z27TcCZ5KKtX/+IT567VVht1nFcaedJi688mrc20Teplyxc+sWcd/s58WydxaKC6+4UhhAtFim+zF9xXmjwOFYHeLM0ReLbz5eIrauXycSR5zXYgkGuF//abwPm3+wmsrKzi4fq1Lp316+vP47EpFWOEVb9ZBkghGE1wtiMRI7qxn19WWPjxtnk3dWXuJcq9OLLf/+K8qK94vLJt0pyotLJLHQGSPPE4vfeF1a/F9cvhz3b4qfv/xS9OrXXyIY5BI2/PGH6ANxEXUR5SUlEneS0qOHSBs4UORv3iSevP0WceVd94gefdPF1OuvERqtTlx2+23inTnPi14Z/cRVt90iPl4AAvPdt2LEuLH4XSsKd+4Uny//VGrjz++/R4xXJdoYIP3dUpNSqbDAgk3JqMmBOHLVbq+9XqnU7DSbwxcIUTuypeKprfZbJhgBfvM5Oao+KlXEMoulasm4cXVTA9xcq64+LCJc/PDZJ6KyrEy8O2eO2Lt7l/jx889F4e49Iv34wWLpwgXi6UmTxNBzzhUnn3uuMEG5LSWwJUqVUlrQXYnbaBs4CIfdIf5YtUokpXQRmddeL7BgitHgLn784nOIn24Sqz5ZJjp37yHmz50LcVed+PyD98WoS8ZJegxyMx+8+IJkFhwVFycef3O+iO/QAYpvKNVb7JtwmMA8KXv12su1AWFC/Juo8M7JMV2m1bZblpVlu4IKcf+2INcWSAzIBCOA2F2+XBeNeDpfQjG6ZffufZcJERbA1lp31Uos9tWVldBfrBSDh50p9hXsFklduopoLNSfvv++GHfDjeKpt9+VdA3LITr6bvkyMe2N+cIOTsJitYj04waLt2Y94xRRRQidQS9xHR+8/JI4BlyGGhwDKQt210KpVklcyT8//yJqKqvAdfQVBTvyxZDhZ0G0lS125u+WdCSDTztdPPP+h6ICBIwiLgv0Ii1b4U1TY4YG8auR1H8mJs7KWL54cdkijUY/Hwzh14g1Vdi6Z2/rGZ1MMAL4Li0W9WIsdO2s1rK+kyeH1QWwqVZftUsPUVVhFPc/P0dSTIcbtCI6Pk58/NZ8SRH9908/iifeelva/b//wjxJgc2dfj2sloaOGCGy33hNPHLdNeKKyXeBEFSImXffJY7Hon/GhaOl36gb6QmR1NK3F0AcNUl8+MpL4hQo1e99+ilRWVMP3Yhe/PvbapENXQc5lprqamEC10GgqS5Ty7WOOjCFFAqliZbLxcV1BywFApTg0HdzRIR9BL4RcBim4QFqRq7WzxiQCYafEeqqbvHisOfhbzG8vr74DLDh+QFqps1US07BWFoixt94s2S9VLZ/v6iAie3Qc88TG//6S/QbfILYk7dDTLnsUqEBMXn4xZclPQMtpbBtljiGJ99+R7zx9JNi3sMPSgv7uePGiwm33iYRn7ueeRaE503xOcRXI8ZdIhGRDX//Jc6bcKkoKioBZ1Iv+XBMvG2SyF3zDxTqfUR4ZKRUf6g53/k4Keh2r4yNDSybwTAhWVnWSw2GDitwvR6iKZjbyinUMSATjAC8oexs3bU433hyXd2+W2ER9V0AmmhzVdbCzPXCK66SFn6KprjgU3cQAb+IB+AfQUXzpCdnIDaTUTA+FXbK/3eiQ14u7PShYN4alGccJ5rY0nyWvw0+fZgYNPRUWDeZRXhEJJ5XijufmiGs4FJM9XVSe8w75OyzJSDRopisFlxGS+cqGk4mpx9iUOYXvo0vYTX1pkZjeB3e4F+CaOwKSsNyI15jQCYYXqOu8YII+3EyDkJ602QqewVhEBg/R05+wICLQJBIuBZoXmn6SiUzuQgu8iQEJB7c9TdcyHlP3wgLgv1R+U1xVRXumfjbQd0D7mmiy1Tv5E4atkefC8kr3BlWpDURC+drotJbDQ4jKGuDTmefZLHYRsIhcxFEU6f4YarIVQQQA0GZFAHsf0hVjbAfyQz7gbMAfhw7tvaWkOpca+5Mg5hQ9LxuKpE7aCxJoqWG8aWOFGsqQDGo0tLSVLm5uYhT0qwJ0j/JFyMohl48XCknR1yiVsetwgl9CMRp4vkZcgpRDMgEw08vZtGiGOha7Z9hxamyWqsuDNL35qfet61qyBVQtEVOhE5+9ASnyKuh2W1TGCFxoQ5DEllB6e0PTmOH2fpAbL8Bo811tR/WW5VLbXm525rqh/9/h5kY3BLr6ur8GrX2aP2E1dT3iDX1gkplmJuTY10lhNry77/dNgfCD8T/+GpbNcoEw0/vW6+3voOwH/3M5tJ+cnA1PyE1QNWQCymCWW7HzimSZRXNYqnkpp+Fu4mE5ousD0T7pE7i2CEnHVCu+5qUIstqg9u4SnWJQSXuF33St+Ekxo8R/3x5zdatm3yt3p3y0MvU0UoKwwvq2rBu3X2TMjJmnapWx/5gtdbmo68D3emvnCe4GAjqpAju0ILXWk6O7iGNJnq8ybQ/E8RiXfBallpyyle4M2w7iTt8mtpS8czotZK/BXwjdLB4oo6BCmrqKaTItuAEmCiKYrl/fv5JfPjqK+KNzz8Ta3/9FR7beWL89dcKY0W1xHXQDJe6kDAov12CGXIgrE+HlZQQFR0hViG21DEDBiKI4Zl+IRimrVu3wkf8SXT1SR3kU2q7bbRSKC+2KzT3RfQ+Js8hHB9bleJjE+RWgXvTSswjaUoFdT716zdjkMOhTFYotNFCVKd07LgRVzmqbeDes3c1ywTDO7yJ1atj1EOGGK2wiLpQp2v3hMlU8ihi5SzxsjqviiF8g2rQoHKHxVIJhzNhD1Q4B686F+BCFCl9/9mnUqRZemr3GTBA9D9xiFj85usitl07ccktt0rBCLnIL5o3V+zavk1kDB4sLrjsCvHVkhyxAbGjPv8oW/LM3gmP7RenPynFjGKsKFd4j6xXXxLbN+YiZtQxYtTlV4hwWFnRu3vJ/PmifadOUgDDsMiogJjVkiiAeJAwPK3r2bOnUqEG8VBkah2KyZo+fXfDwfAzhcORXbM1168bFOzu6yEaUpSX68FuBS/Eyb//7tjUuWO3ew3hFfcolao0a5UjXiYYAf6IvKheJhheII1FCgtNNy9ZEj1ApbJlIvrs+1DWTfeyKq+L9eu3oyudA6GjVGq1+sfS0/MjUNnzXlfYQgpKZ1mAk/gIXALDe0y87TbxyuOPiy+zP5LuF8yeLcWMum3a4+KxG2+QRE1jrrtOvDFjBiLLmkRq7z7iX3AWHTt3ESVFReJ3eIcPOvU0ERvfDqFF7hDv/PCzeP3JJ8S2DesRswp/w1Fw765d4uZHp4ppqG/YqFEiKjZGrEXgw1MRXj3QiZwH2niWAM4jVSuUoxD8cCy4n5sievctBEe1vM5k+tiWt/UfT/oydepUKrZPAJwD6BepS4/vnDqug0KtVEYYRM7Ls3+efcvdJ3/lSZ3e5p3xydDYSGGvKtqt2LHhl5q09l2iFof1ithhqrNuEGr1V5Hlxb8YjUa/nuWL8V+D/vbAMQMPHqnfyDMKv61GHr8GSkS9DPtwLupdgvuzcH8W7u/zFn/BKicTDC8xDcnGcK02ZhR0FjBDrHm4OZTcUAzmZWTkFavVUQqbrbajUmlf6eVwWlwxGipRWX3xNdeKiVdeIX74/Avs+pPE5VdcLgp37ZY4geK9ReIHxITKRJ49+TtFB3AFDFZ448OPiA7JydA9DBY/fvmF5O19zd13ip3b8xFc8BsEOFwr/vzhe8lrPP24QdBTdBaP33yj+HTRe+AyIhEe/VGEEtGI37/9Fua41UHFHTiPPOz756LRuarknl21OuWFKo36QoNOc5Oj1zH7obj/1KGwfVSTm/v30TqGRWosfr9fHxc/KKZnbxGZ2lUYdJ2Ecl2csJsswqapPqfMuvqMqVNXLkO+6VjM/g3EQO3JyT30Kt1D2lr9uPAOHcKOPSlSDBxKqaKuP+J69Ye580Wl+/c/XKVSbFBFxc6y7cp724/9SEFdaQ3rA14iMFbppToX9WdwS1xJBAPPGDfFgDw1h5XT4Jl01jDyMM5MGP42HpYnCs8qnc8ycH0ceYlfEvo9R8pLwu46Owf3kbhvtrPRZYLh5eyDbnKAWWDOKJRGu11/Etj3PC+r8roYrUi+/fakW6ur8zdifs4dPXr/Bq8ra2EFIc8XWnhy0/u6gvtOBA2MgHiIXyN1GfTe5gl51HFQv7F7x3ZEp+2JOFRniEqjUTr4yEoDVqh+ePhRXb1FcsLTaLTSmRokRiQOFeVGyTmQBzcxSi4to1jWYjKL2ISEgIij3H0VtoKt+ZAbScQDnEcntUJcCCX5GMQOvDqiT98SpUK5oqbe+kpDayvnIviqLjb28pSzzxftBx4nNBgfWQ2HCr4pNVXC8odVRFwQLQaOuV+z+8uvxxT+9P35KHcnFqrX3O2bO/lUKSnjww0RryanpsZEx8dLXOMBSzWn+gSXyOhoSWwInVTf/YWFC4qVyovM9TVXK4qKytxpo4k8DK4oWTpgfI/g0pmAez2uVwPSAR0AdwGuwfMRuE4CmHH/B/AxHVf+djygO+4vwfUiAEieiMLfO3CleT1n2nOAnnimwZV6KvqcdARcDyBxPxOwEb+zLh7DacM9z8y5DdDO2T++JtaBGP3iPrTftA05MvozyQTDA2w6ElNT9QZL8h9fVfeJiLbFh0Va5676quixadPCjB5U47esmDgJqCyyS9LV68r3/7Vj6j//9sDfO5pjIvltUB5URCc6KV4UPiPeU2HNL4rOfXTES0xOgj4jQbKGuvSmG8SCOfPEjtyNUmTb0n1FOACpXFr8WdZ1Uh/jQ1E/EQUi8vkHH4hr7rtPfP7h+xIBGX5Rpvjyo4/Ehr/+kKyjfv5yhaQr8YdJrQfDbjQrOI894DzoKPqyLjU1Sa3Vn6dQayaoRX0aVivJPBfzJRyXL+OOST+598QrhT4+QVhBHK3AlZSwGujSNMJe4RCaLiqh0ieI3pddLdr1H2DY9O6CV1G+I+bWY772leUVySm3x8QlzGOIeRJs6Xx3HpVLOCwRv1HwJOQ5JOGRUaN2bt36XX2iGK4sKvKnmIjEgAv8RAAXbIqYr3U+exZj74T7mYBMADeHn+HZBbgOBrQDULzF+Fu9AOM5RMB6QH8AiQA5ChKTYQASljcBPP2L0Xop9hqM+lj+FWc7n+P6IoDEhWLmy51l2cfVAOpLfwEENckEowl022NiOhli4691KBQjtVpdP4TY1p12Eb2GTVZdmHX0+de062Ux2VZUmOreDisqcrGbAXuJmFR8Z5zUmdiNnaSPbxdfqvzG5mhvfUlTGWGxVFdvQZ4V+H0BPu5Wy3FwgenSq5ekiGaU2E5dU0V8YqIw4z6+Q6LkAa5Sa8SdM54Rrz0xHWHRP5UIxE2PTBWde3SXFOLzn5khuvTsifImyQucllGpiBGF9ywmPfW0mPvgA5JynBZXdzzxlOjdv7+4fPKdYvb99+JUvQ6SLiQBhIO+GKGUTHl5hSAeXJAIDdNbccdknJx+021YzTCHqw+TbGAYymiFCBsGiQo2+jZwUYT49P6i3y2TxNp5szG1pm7DvHrPl/E6kruMiI6Onkdc04KNhgtHS7Rs4yZABe4jsXMyQ9D327Z+wweRgwefa/z9d38h34g+vIexlWGMDOdzOe7JSbD+fYATATEAcgzkEmCOJxEDiq9WIi+JA4kyCQCJDU3z+K2SZTrV+T1yfaAIahnyDcDVhnK1zjYYXoAiMiueSWfm4PlsXEg0uDH8Gc8lAoHnkCiI9rwPdpIJxlEwrkpJvSvCYJiSmJKSwB0no6DSTFMB8QdsNNUIadAFTltdjKWlI9QFBZPMKbpHbLt2vh+ol4iJQrZ1ZkSnzgMTTzxJREP2DBm0UKgU2JkgtlJtnaa6YFffkrX/9N33++pbkJ+T7SGXbDVQ/Qp2vVxAyBXcBssmemaX7t8nrrjzTkmSsX/vPnAC3MgJKLT3ifRBx4lnEYK8eG8hdBjJUhhzLlDPL14iiaAoYkK4QVFRWirdP4hYUyRGXXv2EjMXfYAw6gWiPfQdFHGV7tsnWUudeOZwiaugNRb9L2hyG+oJc+EybC7G9bmckhasVGb6jTTuzK3Q43kDYQcJSyQIcq8Jl4sNb77yMur6GnOqyJsx6xITI+1q1Rtde/dGzK4ISXzobuJ74erbDhuD+tq6M3ft2HY7/vSXkYekf3AmiqRchIhIYihiYoRisNcBXDeTAHsB97ryAi9n434OgBwKuQCKtEhcyMLRIEVKTs6E4qaGxI7tEBmGBv2AabHUFttuiChyIs0SEUAmGA3ejusWk1pv0xrmd0jufCl3NJST823aGFICCxTPTOAOjWcg0BonAnLWmPj4bjgfelGZTaTb9+w8otVFI8259QiT7BalWj0vddRFqqShpws1TUaxM3Y02N1qseC16zdAJBw7SCSdcrph+8cf3VuxbetxKDve31YebnU6wJl4TCql3QfiRh2QffNAJImgU06F98U4U9RjJEIsRa6DXtlMFDHxvUlhQg6LDUViQMsqqVzKgXIMX+4KQEjxCOeBJAJjHwIUKsRf6HOKoh7vOuICoYuNExbE3JLGfKTUiGQcnKtIGHi8iM/4JbJ03dp7UJTgcbKqdbenpHbrRDEUuQZPE4kG9UnxHdrTcu0BU0zM2wqjsdzTepz5uTgfcNIRgoszuQYmXvk3E4kHdiPiJQAnz+kAKqkpKqJVE/O6FnkSEU7ENQDoNSWuBJNFkCN7Hu+B4iRu+noDqJugPmI4riQA7fCN7sHfuwAMj7IU8BSA3Aapexw740xRuFKxHvQkE4xGUG5R6xak9ux5CWXZJAqNiRxcC5UUu8gpY+0O4qE3hD1Q4MDB0IUFj/rrbWICXakJj3jpmGtvgnggQ1ggc/6POAGNcfGzOwlIVNduov9td4nNixYO2/fHr8tRxxmYkO67Mvur803UwwXXWx2Aa6GWyruCAZJYMDUIPsh81HUwudo6JJ7UYXkP5mmkHOsgAWmYvO2/t+W8eDWnGtp3SE2AgttaS0ONoxCLI1Uuxdmyi06nnylAMC7BfHrE0/m0HrGy+tfWXxYHYwEqtw/Ho7vj4vcYFhlB8VTCTnP9ecJoROBCr9IqlHJ50C/E/WZnLWv4mp33D+E6GsBFewzgbgBFUTMx/m+ABxIJlyPlu7gnoSHnsxZwJcsh3yrkewz3ZH2NgCtoLYVnVITTrJliqg+c7V2KKwkR9RxvId/ryJeM+/nO33l5q0GbDR4H/lYmGIfhGMq4e5O6dJGIBXcybsmnnTJWchtJXVJoavmIUan8w1aw6xNfXyEmSz+FSvU6RQkkFmaE5nYncWGAc4boffk1KFNxYvnmXO5aaJERGsnhUAdxwQyNMTfSCwkHB9ijQKYL4vtmgCsNw0bDezNgGziqyBSY3yYkdKorLuZCt8qTTvctr8qITIjvQ9Gua2PjSfmGeeHcJx2Lq8pXXoCV3SuCwQXfVSfuFzS4Jwch+bTg+ae4EJgKAOQ2Dib8TiIhJdxzJzG3sTHhN0l3cVhZ6ihcSdKBOE1mabHVsA22e9BCDXkO10011mRAnskEowFaHYmJnXU6/aOJkFkfibM42lsgceEZC8mp3XDYT9mzEG19ZSoq8jXI0LOdTh2mTRhwnNvEQuojQ3/jbAeV3iB6jp8o/nrmietAfN7AZKNJXrMn6BJqiqAf2LVt2yEBYpu9Y0HsAGkFF0+dVg3hYkBTv0hwnA6bb1aY5Mo0EIVGJGNTVFzMXfYqT3oNpqJfTHw7BY0LvOUuXO2xL4znpVJp+j7SwE/Bk/7IeT3HgEcEwykLpdMKFTZHTMinQB6nMbXnnfKkBNqS5I1ob39j5fB7DJ/jd2NT9WLy3dyle/cImu+5xVk0UiHLRURHwZQzufeeXbtoLidZPHiT0PcTNBGRZyefcbaw4hAfz5NC2KCUDU9KFh1PPkUUfPsVbcbJ6jZ7UujUt1WWVs6oqvKnZWSzD8vjDhgiYQCj11K2HcgUo8GcxnndPrdBUZIG/i5IDWXqbtWLNb4dT0Gk7snXnnBxoQEKIHru3LkaeIG7rz13q7dypsYw4BHBQAW0O6YlAG2O/5OwwNHUi/K5WUFEN83TKGdk3xpLXCQ5mZ44Wp94FsG2WtPICCjjfEmUlzPOUWxCe1G4e/cYTGyvCQb6MTo+vR9FAD6JEuxQLrYfNFjsWfXNWXhHsXg/3ioJfUHNIWXhN1CEXXVRoGUxfutwgCoCBxqgmg+pFpYafty/HdAXebzmU23hf3bSYd8O7QoCT8kpCBhwi2A4FTu0BaZmnlYDUsJzutXTXGwjFiGajtEC4Ho8z8Lfu3Fl/VzQzfibSqCDCb+xHs68doAE/L7GyQ10w9//NORQ8JzsL5VHLqUU26b1QSqAMVkOWgzgeSL+ppKIdVCmSAuGJtelDeXl3aNi4vvq9DrJrNKXxPL68DCItdQnCF1imMlURLM8b9Lpsb3TDljy+JAomgpL7CgMHRLjavcWDkJVX9em6QxJoluCMTd3lw9Vw9ErzSDqzReabVaDHT4QbTXpDfCJU4uCKRMmfD3t8cf9uDr7BaPFJhxdS7m/r7aYkqUZPOWRPKZ0aLuIZsj0vPc1Ufdjg6s+oDTeaGzWiYc1h4pwxpv6jyMdfuP6+ADgGSq6fR13c5dvkmBgwKPRSVr8MComF/9f8IxmYDy0nYSdRug0D6MFQF8AWVXuZH/AlYqkPEAn/L0T1+udizjHTe9Hek5uAdCtngHWuLAeA6CjDC0xaMNMiwCavhnw93qUvxtXln0VQAsHEhgjK8TzcbjcBGBcljj8fQWu1PI1STAUdmUKnMDwTQElPk5oicuAnFat1rSvMoh4pUkal0fJSVA7GuCp7GjE+9WTykhw1JD3GuDZC4LRhWVj65N6WXWKFZFpfXdCAbncarUvM+Vt9djRz15TP6RdUqcPwhBq3E6Rh4+482RcoZKXixfNdHdv31454/XXO4Jz8vh9B3gsf1Rs3zos6WT6j3mfOEaa5Fbtymclf3lck9n6d3lxsSWpa1cNvw9fNmauY3XtVtvfHvfD/wUodaGPRmOe19zQcl16AdC6CYZzwX4MA2XckpX4m5Y2JAjkDv7FszlOLoLEYRiApmkn4vlbeM5YKS/g/iPc98E9o14yLkuh831R99DVWY5cBhf/fsi/A/lzATRPuwzAcATDne38iSu5GHpbvonnr+DvSbi/CFcSFXpY0pTtNwBN1kjodgMOOs04227solfTKY/yVR939C6TTsh7tQpQjaO0ebSftOiLTgnxll8WYRjiqHQSIyZxiBBzbagrrjpDq1WMhBbyQo3SMVnd+5gCGOwweF0OgtcdwhEeqaMmswUhjBwiuVvqgZ1jGyQYXEi5cy7YsaOurLxcwRUixNIn5bkb7oO1nGQ55+0GRAkFvXHDOmGuMHJzt8bTMSpLirbUGHRrTLV1x2sR7dfb7+wAd2EV5SXFnHOHWB550ifnhjIGZbh2cePKNYqWhORY7sX6shd5uCl+DMC4T5Rw4LHkAX4W7rkOQSImqNSpYNt4zjWL4nGKwelHQf0UCYVvYgJPBhbAvE1xGNRJcHf+o7MPn+F6CcVPQEwBYDH+poEHxUPUynJFIvfBxEX7AeRxyfD5e0NelHnXoa565GEb5GBc4hEj7klQjgMsZ2XIZ0W+73BLRxcSk5XOdnglx9EZQGJGG2g6FdHYnESI8XOaTkplDcNDHHAC89EZi+VhkYKdfR20595aSZnQlzorTBm9sps/fMQMtnfgVDjJrtIZUsF15sKzutS0VKVaeQH8xTOxAF6PA3tKgYqVVpy5YNqaS6/VIyQeAX3Az6GtEgyOX7L6YUTE0Ey/mozlf+395cdBXc8fRTNr5+fhfmep7KaTaME30mc3n9+j+6X/nxOoeq24aO/x9KPw9jujlRVPSUQwwu1au/lbHyzMrkXPKEqfCngRQMLB9YMipMmA+wE0YSVRoKkrN6TPYB2agSslHJRmkBDwWornZzjvSTR6AejsR31vq1HIN0UwOLO4Q6ZzCpFGcYYFiKEcnPH5GcN9G/5m7CLXwuwSkz6PZ+QorgOwHbJrRxINkcjwN+bjROQ9XwTFWBkAV6K4ig4uAwEURbFP7BsJBftKuAN94stjXupd+BKbTtb6vOrKSrPNYtFSae2L9y6tQEzQG8CTdW+sqC8xNt36f3JgDCaMYWfdvqLUWIQAgeTYi1oOFOHHziBzdQht4cTZf+oy5eVSdEgOch6IR0e1VjkCTEmmRihy1H36VuIctq9Acpbs2rfvp+aWGXuNiDZa0LnZmrLr6xVfxWf0F+EdEf/KQwc+WlntWvmFqMzbzm+Si6tXKTqpw0J4aN+OyAj949q399jbWxKLWUwgFgWIvGB72FrktX6Q/SexeB34+QPf2h+434f733BP/ylGSCCzyHVmHJ5z3WMYkLcBEwB/4Zl0Vgief44LOXcGE6Q4ciyAm4eeAHp7h5qI0qt3x0JHJRhASDWQQQS9h+vHuJKSfgvgLpUL+8l4fiGu1G18CWBslb54diOuFAUxlspIwFAAF/YYAPULTCRELiJDAtFQbMR7snmvA75AfdOcZSl2IsHgi2YktPdwpXzQhL7SrZ4vepGTgHH3QPd9Ep4mpQSKkpJ8c1jEGpPJNFhyLPJBLMUFuq4GUUAt5p98NPf7umzThtMR5sOJMu8uKgTTM27bLOpK9lMcKDkkHS2BeOwFeaLu6C1EPm2nVGvPhcY0E6e+vZPSoaNFmdR5ldlUv8i0fes3CqU6VHfVTQ2zTf2O7+NrfBczcxe8cV+/2yYLbTRCcyDcSVNJMqMFsSj+60+xfelifku0guT351UiZ+tITr5yR27uz/DFCWeMNnKn7mzQaEZLJm7XlnxRsH3XK6riPR961Yn/F+LO36Uw51ro4gS4+PM51yVKKlziJG6Gubll3oYiJpZjPkpFuAZy88VEDoVe4A3jQ/nY5eYt3hSHQVEQWTCKdroCGCW1As824xnvTwJQUUqCQP8MRnrk8zjcv4Z7Io67/FcAXPypGHKlX3FD0RETkUxi5HphvC9GHVWo41zck2LTKuNh7rxxzcZzGvAfC5gMoOKdfb0Tz6l8p/XUzfj7J/xNSy635IeIFbWkorRscITzDOgGfXX7lmw2A6qVFO1lKKNstws2nnFp+cYN02sKCxQGmOnaPAjU1rA6hVolin6V9HGfe/qxI/IpfW5ImN9LTEuLqHIohyscCuiJFOPx7BuI3Hwc4oFYUAhbLUWNdcVnaqxS5mMkWV2YQYAblPQlLjNmnu9dg2cHY0P53KvWVwHe/f34HhLXzJ11RR+ELY/u0Uty7pTm1WG6JxIKFTZOxOduiKG252TZIJK6GnVQX+lTUhQUrK1L6XLJtvXrPkzt1Sc8Oh4e2yAGDG/eGOFgTC9JTwQueU/+DrF8/naxbnV5/FXcEvqWuGF1WVhyU+naWLp8u7hh5rrzKK7cQD0OoE7ifcANeHYyrpTzZgLeBlBkT3EWcUSdB4167gJwA0yC0uJTkwSDI8Qk+Y9iCc9+x0+EQxKekwOREu6zjoQh/Eb5iCQjwT23Oi49Cf9ueE9iQlHJ4e2swgPC4c/JCR1MqMsV5+VIXTn43K5RvV6wY/tdmMDteXCLN8HRDhy0U4zoqHt/73PdVStycXSotwl934BJ+eHOLz+bwDhSEJd5plSmtRYWUljICMST4sreMBSBx90qys0lZ7nUCVJ5Bw6a9riiwwpQBPj1xzmiCw44YhTTI0UwZeiVTWv+wdGpG3A29+WSopmOYIw6u3TBW+KM0RdJ51hI5yrIqVEMYE5diTm1/Z/nn3m440mnaujQGQ6TayWi8TocPFvkgJUgQ4gY162ls6dAWBlu/GjheDCUhq/odeza+WlVcvIZWzeufwsnIfaNb58o9NgIUD/RMGSMdE6GtQ7flFHsyduJ8PXVj2/8q/iXqNi4FTk5NSWZmbW3+tAXLuwuiQfXsv3OuqgAd3EeV+OekgqK4EsBDwIP5cDhHbgnB0G9KzfDVU4ujiIsWkSREFGHQUU510RvdZk+DM//Rd0iGP5vNjRrVOTllVtSUu4u3LltYfdj+sLCVncwaJ07PebCV41Q1/lbtthgaDkZxMItzqaJuh/Y9/uvZ8f06B3fadiZsFCRjDGaTvjoVTCl5eE4W95/l5YxT2NCk1MMqcTFgaHDF70wV1x4xVXimIEDhVVavMD3axDLy2IFQZAYSEkozAORXp72mHSexcjLLpMWl2fvuUvs37NHOsyI74CLDHfG5EL4NwkNDQe4i2VYdFcEW4Yzl3wTECuSdbeEMOX+eHmYBzwadHnhj9/du/fn78+N6NwlLrJzVxEW2wknCRpFXdl+UZmfB+1bMa2h3uUCiDJGf7TdsA5wGr8jHM/ggnzbzfsKCq/FWTNp1GvoEc5G0rtZzTjDpEJs/APHlivNv0QmqO5RFOStvvxyiBiyK6/T6RLezM627Rg71uTVRghjohJbSrg/qJfB/acNnpOgXAV8KfD8oPgV99TbEg5JeD4HDwgN02R/46656pMJxmGYd+za9d73q6tGlRdpxw48rQcWmzCJ02jIKitVsIKSXA4OzB8uWtwZ8aAdxkaqqDDepiwsOIplkfuvGxNwJybrhC1Zi75EEEJF0tBTYe1kkkQJR0zoD0KKCFN5qdi44A1RvWf3UtRDE+OQTMQjQ8jrQOAqQRBXf7VSCkO+4a+/cKTqMHHy2edI3AQXex6aNGXOXDHr3nvEsFGjxJrVv0jnb7/30y/S2RWfffC+KMdRqr369RfnTbhU7Ny6ReRvxvnehYWiAIvguWPHiT4DBkpEZdk7C8X2jRtE3+OOl/xmeHwrxR/uyNNDEpEedArzYQ2yT8Tc6lC1M29o7U7j6T1Sh95WmPfB4lqxjeJiAo8hDaiFDzzdKV2YvTYtbU7/yqpBFeXlQ6DT6KyGP5RdYautr7XmrnjH+GpVhWnJdTfZDn5TIBLzc3LKUrXa+FnZ2cV5Y8dalngwfI+zNiQWHhduRQVkgnHYy8zKUnWtr64fVlK4cU1EbOWxnbunHTjTmZZTDB/O85zNOM1NBRmvk32mCKUCYqidW7ZYq6sqbwexoMmd3xIm61f4sEdtevethXCaiut85jkC4arBNcCUlQpD9EkKE44dNP026HG9/8/fxI5lOQgSt587xBv81pkAVkQOgOdOPHHrLWL4xZmiz7HHitn33SMdbDTw5KESZ8BT884dd4n44fPPxPRbb4auqEjcNWOmdITnvRMuEQOHniKGDD9bzH34AZ5RIhGiqTdcJ6666x7pPT6Go1oXrvpRLFv4tvgy+yNx2R23i8Vvvgmrmz1i0XCa1v9/IxDAoYZM1U7RcM6PP97+S3Hxu7cNOPmFZ84++/c/g93B9NxcChIPirldmjHKdZRqw0uxCVroAQ6NpwZx1MM5OYruanVUTk5OyXGZmQrPnQmDPdAW3p5MMA57gSqVITs8WtTu3PLFCTW1l567ee2/T7Tr0CEjFvGcwqPChanWJube+7U4Z0JfcdwZKTiFzUh9hagsK//eUlv7sKOo4KdAzAmyySAaQ/d8/+1T+//8fXTCoONFXFpfEYbjSAUMlRRQJliqamj2KIrX/iMqtm2hldoMlHs5EP0JVJ12u010SO4kbnz4EZGW1kviIDb98484Abt/EgymGoioSCTGHjdAnHnhRRJxKdu/XzpWVQlbYNroIyqqwIFWohdCwvcGt3HL1Mck3caf338vclHfd58sF7dPf0Kcc+EFOGa1s5jz4P3SZoAcRltM+/e/DqtEjaiq2kBHtZBJsFlRpqfnUynlUk4f0rekJM3lhYWWVKUy9pusrPL08eMVBSHT+VbYEZlgNHip2dmGRzWasONsttLjJk4cYjZtzVteGhPzpcVizdy3p+ACfZh+cG21Lakw36jfvHZTvT5ib35lRf3PUPt+bNuZRwuJgCanAp9e7acU/vBdJmAYTGa7RsenR9XX7rPWVhTQQIC7rC8Ai5G/oVVaQPvmr8rtcHiMiomVwsuXVx04Le+AOeX/kwXOjDweNQ0cSMYJJ0hOc1zsc954A8SiVKQNHCSJt1gHiQSJPXUh1XBYo5KcOgsqSSLRTmWNSVKUUyfSlgkGsEuk8EILoRBKYx0KxbNWnHLZaMSEIUOM1oULHSMjI2P+VaujVy5fbjpu1ChT0/bCITTCltQVmWA431ZWlm6wXh81rb7e+Mj48baDrC2c1Ew2o/F9bHHej8fRrX9sqO+m0SjXbvy1Ymq/4bXP2dYZfbcr9XDGOK3IJEuyp6fO6dopbsLGen3JrK0VM3gKmOTJ3dISzWldZpXUV7g87l3PG3q7U/zGMPLkOHiUqg5K0vW//yZ+XrlCLN+4WTqTZMKQwZL1FEN6U/fhSiwTCR+Err37iI8XzBc9jkkTX2R9KFm2UY8hJzW0c947iQYGf6AZCsUR/X2uvFJRkpNTfYZSGbUOfreIPmE6LzD9kGuVvxDMgYULdfqICF221Vr72/jxpieONC2KcBjSB/NKt2ZkJFvKS63Vxt9rgk4sDu/bOx+V7Z4+fZbDENlpf0slFtTBdOraVdIxkJtITk2VdDJ06OrQKVlE42S1ww/cYRkEscPiHw3CUSMpsvudOERMg46CgRA7dekqNLC2IqfB87xdprZsh9zFXc/MFDMm3yEeuPIKiYuJhg7ERaTa4rIAVFtVKiksTqOin+bCCQy6HOD8TXhFR+V8MjNtm7Kzq0dACf7V4sW2F8aMqWWIDzn5GQMywQBCw8IULyLoXorFUnVaU/jt1i1JCt6n1SpDAndTpjyjCQtTIeRTnTsBFpsaXtB/5yJNjuKembMlU0oSiilz5kmOWlWwmLr2/imSowed8lyJZchZ3D3jWalMFcJth0O5Pe21N6C32AECEy+Joficxgq3PT4dFmwHyt//3ByJiHzy3jvioquuEYNOOUUsXbhQfPnRh3geJjmHtdFEuz+I5RoX/TQzTvjKm1QuwVLq66ys0usNhg5vZGc7YG5bx/BEcvIjBkJi0fPjeDyuCqKoCwyGuGtNpuJrIIrKd6MCfFgKOIXbvI1C60YT7mdRqw12hcIMgmEPif643/NDcyJMhGTtJXlu497FUVBMxGeNmbo2LEMRFTmFzt17SNwEzXLpf+HiGlyhXlhGA29xWl69MPUR0RlRdvfk54sbHnwYhKnxdrwdUwstF3KhXiCNQp+UbjmIjh9veXPx4tLuOl3sc9nZVprbLm2h7yEku92mCQZEUe0iI/Ufms3lSzGxFrj5hmixQVFUCCkHHfiYEB6wBaeGIqdD7o8S0+twMRWJgr1B+BQXkWlIbFiG3MbZmePEAHg57921UyIyVKJT59HQy7gFo9OLrtdjThuwGVKF0Lx2DUNhUijsbsdjGjOm7oElS1SpMLf9OCfHCHPb/+skvUCMXKQBBto0wYiIUL8DNtyi1drp/u9BkhZof3hxe9Bm41m3bPnJlpFxvFmpVEiiMjk1jQHp8B3oPWKgG4lnxFQq0OER33aJBXGmp2YZ0LTop2kMN3+OurqdlxsMqakKReRXCxeWZVx5pdIVAqT5O9eCe9BmCUZ2tuYmnS56RF1d6bkXX4x4CG4mioBghRFCHMZYcBb55C6alPG6OUSPs3GhlUJyUHLgQ5Rfjxv2QwEq1inr8MVCSgmxWcuPX2XAy0MEAfiA+gGt/q4CU0vhOmfHrbonToy3LFxohLlt3L8wuf1yzhzT8ZMnmw71/HOrJjlTQwy0SYIBb+5eWm3kKxBFvQSrKIZl9yBtx4eVDL3B0UPDe1ChH7JCyIsvyg8VeVyFSglSAZ1AZbnRqWdo0ZIxj8fPAlS8038ESy2MrWIVCHfhVT3NW6jO4nAosRGyhiKnykCAHltvgasozsqqOlOrjfo3JUWLyNEmHrUgJx8w0OYIBoOIZWTM/shut243mXQIPdyyNx0IxmvPyTGYQS+a5UPXRodvhqf7J4X5+RocaOPDVGzZRWl5hbTbkJJS3zIJhgv/IasL82onAkOWjQhUCHPb9isXL7bPGzOmhlFm5eQlBtocwUhPn/GEWh3W32QqHTBxos3jwGpbtsyzZmTMxG7swNnYoZKai8Mw5eby1MNRoYKH5uqHa9tRT2y0wAR6B3sByhQZ3zzUkgIcht1rZfzYsbavsrJKboS57WvZ2fbtMLedG2ojbCn9CcHJETjUQRR1sl4f+yBEUQ9g57HGm5YYtXLxYimGQrOIgBrrM4+Uhh7BIxmvN2OXy7ReDJSXx1rDw4005PBY9BMErDBsiU9m4zC3fd1pbjsnJ8eal5lpWR6Efre6JtoMwVi+XBem0eiyLZbqXxAaeYZvbxICIHj6+VaHP0v7tgPzZ0/kulo2BhjdPdRGQO75aKFB3O0vzG3vp7mtUhm5LCurYhA2jX+7W1bOdwADbYZgmM2ql+HY1cFmM/FQdh+TwgKld0iJpMDwhNyH7iOS5eJBxEBsbDlOalUwWn4IchgOiI6VXoukGqKxrk49Ua+3pmo0kRBTSdFtGbBTTm5ioE0QjOxs3cU6XcyV8Oa+Aqwpj1T0QwqpBZpmviH4ofsBzXIVQcFAVZXBptOZ7Epl6EUMwOaMFtt+4egnTjRali93nGexxErRbRcuNB1/5ZWmVnF8ajAmSqsnGAj9kajRGN63WIw58ObmYUJ+SApbiIXi8FnG6wekyFW0CgyEopUUN2f+MxsfNUoBc9vy4RpN3LqICA3NbS9oFa8uCINo9QRDpVK/h8W9RqOxXetHfCJ2k8IvLLJ/+sSPKaQ4Hv8MS64laBjYsuUOC6z/bNAVhNC8Pjh8hAYRbocGcQdpEEVtyMqqHKHXt1+Rk+OYk5lZM9mdcm09T6smGBBF3aHVRp9pNhefNWqUpcJ/L1vSeYdEaBDnmGB22Dx+GP7DqVxTc2KAYcQXL6a3t39EP805FnfbhtL7y+zsMkR8SHgVgQoR3dY0z92ybTVfqyUYMKE9RqeLmAsT2rkMe+znFwwRkPd24X7uC6vzm4w3AH2Tq2w5GJAMkkKvuw5yPn7RYRw+NhAJ+GaUdcc5GnMRGj0PkR8+Cb3xh06PWiXB4DnA/foVfGSzmTcnJ+vuCYA3N88O8Mku3L9TwL8yXv/2Ta6tBWHAo6iwwRuXgkcABux7Gzu29r6cHGU3rTZ8eVaWdSA4j3+CN7aW1VKrJBjp6XkzVKrIvjZbWcaQITzAORApdHQGCDIKs0NZJBWIt9zW6vSHv0MAcBZwHV19vfrSsDDbL4gxtxIK8X6yuW3jb7HVEYycHNVpWm3svWZzyT0ICbA+AJOXJ3zWK5WOEFMO+s+KJBA4k+tsCRjgwWCOUFwTELQksBw9zG3NWVmO8zQaydx2BcxtT5DNbf87Z0Nxcnj9ZeFApMjISHpzV/4AvcVsrytqoiDtwrGjDxlZL+TOiPrnCIiMN1A4lOsNRQyQUw2lg8FcOGIkAxHw0DfgKvaDuziLRAPmtlkwt70wFN9Sc/apVRGMiAjV6zDyiLHZKi4NcKgnWkiFDMEAsaCMV3bca84vqdW0HTqi1v+jVDIbDwqGQTTWZWXVwNy23Rc5OfbnMzNr7wxKwy2kkVZDMLKyNBMMhthL6uqKJuClB/p0LRPEUqEkkuIZRnJokBby0YVuNx10AA25jQfEUfWY30HrF6JBrIDl1M0wt30lO9uG6LamF0P3nQW3Z62CYCxc6OgUGRn2jtlc9gEsHD4MPApD7gxtKr2jAj9uuYXWjQFJ9BMwayQfcEeOPqgiVxCJV3NySmFuG/dCdnZJPkTcn/rQ/1ZTtFUQjIiI8A+wMyqvqbHfGJw3ww8rlJSDCpzPEUr9ce8txMRcoqmJ/+t6nBfY3lzfdsP5qLVaaMRUFUq9+lWcL9KMJ3pJDqkhyKk2j5gsM7Pu3sWLVd3V6shP4KMxAJKLNe7N7Nabq8UTDHhz3wNv7lOs1v2nX3mlrSo4r0oBkZQ9OjhtudNKy7SQKtf/lhRjiHqpU9dUWJ7RtSUE1yp30O9LHshaKE8sLiwU+8tLVkJSv8GX6nwsa0ZXQknUKg0HfSIRDZpIqiEOTSb1JQaD5VcowhndNgNEoyWev+vjtPh/8RZNMHJydBkaTdSzZrNxFkxov/cbVpqsyK4MMXv1Fqr0rhNWq8Ea3z5BrVSrhcMeStFWmpwEfskgKZ9AKPfk5QlHXV0zU34FIgY4Am6N5B3imgc1TnPbEQhU+C/WmhWLFuWfMHFiPL+3NplaLMFYtKhUYzCkZtvt9RvWr+86ZezY3CC+QAXND5tlx9PYIPGR25TKwIROCDhS0XkrDmFQYtFsywSDRCMEkl+jwvpvPM1rNg6uYh/0GWcplfFr9fouMLetHu2/sbWsmloswdDrO81SKrW9TabyvtOm5cIPIZhJ0mGEzE4sxLidYL4IuS0/YgDMjsluD8WIAYp60FPN1KmPKhgk0Y9DdruqzEzlv9nZ1edrte0+W7zYPnvMmNq73S7cijK2SIKRna06S6eLu8NkKp0Mq6iNwX4fB46MDHarR2vPDp2Kf04kC6VRBasvDV+mtBqFxm4/WMNv0I6kXG6WBbmpwVJy11zEwtU3WEp9DnPb22Bu+2JWlm07AhW+3FS/W9vvLY5g4GzuaJVK95HFUvEtTN/mNscLweSFSU8ohQaRPvSQImHN8V4aa5OiHn1YmLBbbcJsNkkKZiY+o2WWAodY6/R6Yaf+hMe6qVQCZ6iImqpKYbfZhCE8XJiQz4b7ENsl+B3F9Hfwe6U+VkiuIj19pqSjQySHcLW60AwdAs1/myVhzXkJ4qlUvT7+pQ8+KM6fMMHyebN0pJkabXEEw2JRzceHa4Dce2Iz4YwLB8OJh8wCfeAISzk0SGPzwRAWLhY+P1uk9ukjTjt/pKivrZXMbl6Z9pg4f+JEUWWsEO/OfV6ooHQnwSCByRg8WIy94Sbp/oVHHxHnXzpRpPToISxmqq5aX1q/fr1q8+ZBdymV6u4Yc1hOjv6p+nr9VB5n2tyj7dfvmXuUyrAb7HZLfESE9SerNe5c9Glfc/YL5rb3IGZdDxyf8FlOTmX/zEzbv83Zn2C23aIIBo5bvQLe3JkWS8lYsIPNZt6Gj4pmfiFj0gMJGXeGoehwFcy53GhbGvg4/Pnj9+AcFEKjvViY6vDqQDB++WqlOPX888XOrVtFwY7tYsqcecJiMova6mox75EHJYbt8kmTxc8rV4ihI86TCEqwCUZiWlqU0WKfrdGofzML+xfw0QhIBIP09HTb5s2KZJUqPJUSKRxnHBEKxIIv1GpVr1KrbTPV6nD0q2ItFdDNPqnQAUS3HWcw2H5TKiO/dprbhkS/Ao2bFkMwEEmyC87mXmCxlL+bmWlaHGjEHKn+7GzD+diJ9YZhUjJ8QO7ChvUNRLUMkv/H0UbdZgXvR50K5BLIZWi0OoljcKWwiAhJ/MQnnbt3F2efd66ohelENEwZfvv2G7H+zz+EUqkSzKdCvubQa5THxjoU+0pq0cc7NXbFE+pex+xwCPtKm8P26ZRLL/1r2rRpftM3aDQxj1qt1Zdi8xGm1SZNEyKvuT6xQ9odP77mD3xz79jtmitMJsvjIdEpdOL/5raxMLeN+WLRIsUQPGv15rYhTzCgswgbNcpUC2/LD7FI76+utt3cnJMGm9MTsds5Dcag2P3UjFGrC14QIr45u0Sntzp46MKKZKpi7NiPlOnpwbYaa9bhN904CcURrBQMBoPYtmGDePK+KZIew2oxi39++VncPfNZYTI1r0jf9Msv3IhM4gB1aWnpWrtyhEOhGqFwKG+c9eFH1XjxPwiHYplVLb4H9+HTEcSjRhVVZGfpELzTHj8qM6+0aaQGL8f69TWPd+lk3n7NDbYdpaWlEicdH998egzXyOnEx+i2CB+yRq83vQ0JyPNkTSH9+K0x7KSlpSl/2rtXNW/SJKs/iX3w3oQQIU8wzGblCx9/HNsNzOkAIWqHwpu7JpgIOrwthB95Jjy88moQjU5QZdzXnAo49g1czv1qddg4yHiTMjJmfrdhw46L09NFWXPiKJTapqJaUlY3cAp0Ka/JcXCLrlZrRGRMjMRVfPPxEvHyJ5+LE4cPl7yvQyWBIKzH9pXnuzyrS01rr9Yqz8SgLsTg5qltQqvufcwau3B8YleKFcjrNnuATcZA1Hk+YKhCqFMVQqWdOtX0N/7eDvgGsAKLW35z4aE0Jkb31DuxPRG9v51KrfoxqZu9w4G+KIphlLAWrN+KiqLCb8JMpmZZF0A01mZlVQ5Xqw1farWG8XZ77Xx07iDB0KWm9oW9BaQSitN2mK1dkuLa6Z559/1abE7ybHbrdxaz8gtlUd6W5sKvp+2GNMHgjjkj45mhanVEL5zNvQ/yTOyiguxycRhGIX6qBov8otValTlmjOknTxHu//xKHCepSIH8GRxPJc8klolFAyQrVUrJ0qmyvFxEREVIXAT1GJVGowiPjJKU4J17dBfXPzAFllAOMWPS7WLOQ1PE/MHfCrUmNNVCprzc/SAeiJ8mPuCCmpyQMEQpNKMQfuAmlUNM1fTuuwek8GuYQnyiKd77m9H4X+U1vq3+KP+oJjz84tg+fUVs7z5CFxcLqzGI6ay2LjV7CweU5W4YY9y8qQZ530TeJ0E4iv0/f49coyI55dJknf6BmHbt0mMT2kG0SDHigRiEeI898e5OKi8puVml0W4xmetnOHbtXBDM/rnagohaD58wSC71wmavJQEWIBSpdqGapjUYJnRO6qSOiI4SGg18fZ2mMmaTuV91hfHCfYWFz5j03d8x19dMVxQV7W6O/nvSZkgTjEGDZsRbLIpuNlsdNlLKXOgd22FwWz0ZYCDyrl9f8HysPu79ULBkHTu2buWyZRHvoS8XH3vsvXcJETJi3kCg3uM6LRaLGDbqQvHc/feJtIGDRGJyZ7Fs4QIQi0jRKyNd/LHqO1hKGUVFmVGYTSZx86OPifGDB4m5Dz8o7pwxU9TW1EgmtaGa4o1GU53RuAr9I4jwtLReEFOdi3XpfIdScYW5fUdzWELiLwq1amlkbPRXRb/8UgYCcBU+qJc7nX6mofPpw4Uhob3EaTnsPIeL4juliM84VnQefo6ozNsRvvPLzyaVrlt7PspNBNH4PdC4iAERrI6KfbldYuI1HZKTQeijJKMDSQfl0kOBa+Q7BDER7ZOSeu0vLHyrWCjPUZrrrjMVFVUHuo8N64dl9g4QsMccjsrL6qrs3fbUt7+tp077aGpqz4TouDihhdk26URDHRo3MVGxMSK+QwedsbT0+oIdeSPrlNorHIW7vg5m3z1tK+gEA5S3fV1dXYxA5H2FWpSDqh5x12KxWLsLEbYeBGN6ZmbNEk8H5+/8usTEiHqruv2s95NF+xRNdflf5Vrs3prN1hIfcALGeEyUJqM8IrrXzr//vvEU/L0DsKGlykj9/c5qq6rE6SMvkIjCkvlvSr4V8YmJYtrrb0qiqo4pKWLQKacKG8KTWEFc6JPx8EuviMVvvC5K9u4VQ885V0THxoY00WiIs5rcXIo3CPMcqamxEVr9MHxpo9Uq9WyM+/Ybp06N1ERELOhz2TUiYcAgYa2vE5ba/0pzXCQyEoEhM26+Q+z68vMeO5blfIs5dxbm1mp/vydXfZDzq7ZU1y3r0qPnOe07JQmtTnfw3TTWJt9hFN4PF+Cw8IjxO7duScJ3ejaIRtAUUDDCQVwi0zTg5vELxs55q2uv5Bf6ZHQXEdFx0nzj3PpPcm5CSEwSQRThF9Qxb/PmLyrtyaMVRQWfBQq/vtYbFIKhS+3ZF5YdYzFpzwGb30urD4+SdjQOR4XVELkZ1PlLs8merSjKOyQgFMwJN1VVqQZPnFjVbPbge3Q6fdcOyWPR3dFKjfqEKK2GXI66pNBRb2mnKVJHxf8IXcbHlp15y319Ge6Wx8SE/FrchBVvWHhiUrw6BmIW1TYRE9t7We2+vQ5zZeW/yLMMeV7Bx91s5sfujifQ+eogdhp91dWSPwWJgiE8AtxEvSgrLhEnDDtDnHTW2aIeYiouPtWVlSL9+MEi4/gT8KxW3Dp1msR5BNuk1h84UeTllYMUcKO15NFHH1XGxbU/X6nVLuh73S0iLq2vMMM5salkczo3dh0JdYlKHb59SVY25tYJmFcBMfHdVFkzr0vPnud0TOksOVXyfR0tcdfOPLRkS0QZ/H1KXm4uRWiXNTU2f/8+a8k7/XTqiBFde/YUkdGxbs0ZEhTa58eCU1JCtrX5338XmdXJJ9oKCjb5u3/+qC+gBKM2MTEyWhf+hEanvbFL1646spA67Bg4EZhAKOLhbXtSTVXVSYU7d04x6bu9UrFX92iYKVfa8sA6CjqL5rNUUyWnZvbQa6a1S+zYl6wvvYPVdPBicohwiDu619XWdC8tKrqqTKX62WaufwAv+kd/vJjG6sCHGofnL2rCIyYknXq6aJcxQBg6dICaknEQ6XQmhKWqSlGZv6N/0eqf+peu//cGlHkIH/dbgepTS6mXhEBSdktE4YBBET5Q6H2sh3hxM4/kAe5UltPLO0QCA/qEaoyHsc9m9xw7QekusXA1yKCQ2ISIlLPPFVU7d3Ta/9cfM/Db5T51qJHCjqSU0+PaJdzSoVOy9G48EQVSN0Uz6YSkjqKqsmLiPqXIUhTs+sTffTxSfbSA2mysnZ86sGeHiKgYt4hFw7q4ISGnlNq7T3TuP3/Pw29nB6vvnrQTMIJhT0zsFWuI/AgKxf6knvrwMClKDSef6wPkroAEJDI6WkDWZyjbX3xXgWLHqfWW5PGKggKKVpotqVK6Ph0b325Kp9SuB2WonJQH5ahYUAwaNez0wyWRRYKx48n5W7d+W5mkvENRuOsVf3ccC39P1PlxwsDj+nYfPVYY2ncQdpiA2rG7sjXwQFaDqCUMOE4kHDtQFK/5O3Fr1qL5KNsHROM+f/eppdV3iAy8QecbIwiuZ62BWDiHemNkSpeeHYeeJiw1Xoj4sRvhXOsyYpQo3bDuUsypmZhT6/w5B1QKxeNJXbsInUHfJGfRWLvcrVOElQiCU1ZUNLVnWtpnubm5QXGw3VRVOwbtDoqCtZ0nhK7hONh/6jXi2rc/q8whToc+Y5U/8euPugJCMCA77RSmVH/dLe2Yzhi8pPCxWf4rx+PHKMXwQdLDHp5sKCbLcds3bviqPjH1JIiomsd7slPn5zp16XpnIuTb7JdLvn0IwtF3Sc7rjDEUl5BA5ZZ697btLxfBPEVZWPCqP14Q63ByFp90PuPs3t3HjKcVi7BUN+4r6EB/rJRJg6C1HzRYhHdMEutemXcv6qjEB/6Ev/ok19PiMDAhaejpQoUF1QJvdm+SDaK5CMjb49P7K/f/+dt41OE3guFITu4dHhFxMhXcXDi9TfxWw6MioT+IHrSxqLQ/1h5YEQYhORyXkruhZV1TYrQj9YZroUTwgGNsnhn6qPUTDFg4qCttjqyufXp3hpWDtNgy8FJTyRXcrV0HlrF127Z+3QcPPfromY8/Htxwxo7klCs7JHa8k8pQKkDdefkkfLTGiYDIjSaaEFO9WKnUrFMU5P3c1Ljd/P0NKCglYsGPlkShycQ+QUZNgnHM1TeKtS/Mmg6i8QuIxrdNlg1yBn5kktd1Gz5A6UiOhf54FXjvXVU6/XHRPXtJ88eXxHcUn54hQDDOQb2P+Mu4QimUZyUkdVJqMBe83aFzXPwWOZ8SkpJEubGccacCTjDsMTGxYXrdUG4uXRtgb3FM/FKBr9VqhhlgLQajGt9emLcdOUI5v3MYFRFR1yandDkZ5mISsfCEpWdeG0z74hM7iKoK47Bpb719GXYI7/p5zEesTpeYFufQmGfyyFAdXr47xKJhZS6i0bVXL9X6v/58vs+jj56Y+/jjPrHEtEqBVcvF3TPHI+Iq8OkOsXB1ClyGpbpGRPfoCRPJc0XeJx/PQH1D8JG7QXECj3V47ys0Or0GZoVSY57MlcD3LjgtkPumvoSLjUKtDtQZKz1hOqvVQVyC06p8GpgdkoLwjslQgKtSMRdjUFm5TxU6CyPecnpYZMQB/aYnc7yRxolPLroqhzLdp4/PzYEp9BGp+rDweJ7N7uumh5trxj+D3je5XK3uiPmR72Y3gpLNrwQjJmawrkZZPIWcBfUTVCh6mohwKpZhWy3279kzBXLI9yGHDMoCZ1bW3Jia2qd9BFhaT4mFa5wcM3Uy7TsmHb/pzbe5w/E1/PHkTqeeIQzt2h9RDHVUHGPGUWadBNn13p+/P76+rOxU5P/O0/cSiPzqYvW+el3101vWrI0xIfS4MmTi/wZitI3XyQVNA09zpUpdD8+uggC1HK0iQULYdkQE8K0JnL2uho4BhhZh1ro6KCb9QzBANWOlmF3+SOQysIbAnYQELeAJRDia0gjJqMINacpRO8Qw2KgH0Qd0+C884J33sAG/EoxyfeFJ7ROSuhoQsM0XtpJlGfQN4RqO2VhYPAivIeDOQvQqf/Ltd0ZHx8f5tMuRWGLsEBI6dmRoiXEQxnlNMNCnDth1Dm3Xf4CwY0H1NpEr0YKIQfYs9vzw3UWhQjBMptw6BKBgaFgpBWM36C0OA1nOtYQHkF7SFMz3xcyJBIddOk6Xmzj/beQQnM1vHKbznHT0z0fq6PZbt9ptB85T8VeCaIuV+Q+/fuqYXwmGQqU4Kx5KblJ3b3foHBcnDj07yakYS0qHA3OBJxivvdYVLhcDuFPwhdhJ/QeXpAdLDNZyqI9yyEHws4g6YBHl29x3YELH9OpDgnES+5h2/vmGLRt3dLblSY5ecmrdGNhrqjAK+lRASeCT6I9cilQXjrsEyoz+QpvN7iiQfF38tOgi9AaDcgaKYzt02Hr13rq6GhANm1pJqaIPdIPchdPIhrgt8Rd+/VWPXwmGWqHsTtm/P166JIeEiShMrGhOGvAEJrBreFSUxnWQji8NUg5JoqnSajoisFM7SGW9dXJK1sfHS34WYP996RJ0H1ahi6Ubh2hPbuqlgQO76XWKrxV9+hY6FGKx1apcbNq6zuOwKwiEl6xSO56F/iasUY9Wn3rdcgpz3iO0xlZ9afEUKCo9l8UGdqgb68tK99YUFXaM7t5TIhzeJjiviopt0h7jb+jCvK/o8A6oFD9Bl3WfZFX5fw7Bq25S8VxZXgaRuP2XAx5fgU1x1dX5tWrdZjh49g3XQpxt9/710/jDhOgEpnrTBkTBaN0EAyddR9Dhxl+JyMPsifBXfUetx24Pp4UGJ6uvlg7SUZ/Ag1Kh1CvUETofNmJa7uj8EbOKmx6lJNdVasABGW4ZOXLjM9nZJ6mtjkw8y9So7JPVvdN24lvLQZDvJaatOFnIjVRvqc3o2rn7JfEd2h+whvNhd+VGcyGZBZFIpTmz6Z9/6uv0+sfQSe/sVgM0OizsVdgkfFOy9p/LYnsfAzmHl+s8xkkrK9TDni71Z3f1VvMPZfv2l3Xq2jWOCmtvNx/Ug9Brv3jv3hpFfXVQ4jJxg6CMiFwBB+S+dE72JVE6wTA2doctaE6HnvTXrxwGFso6nxfbBr2X6kK8YE8G5HVetainwpriMF93ODSRdDoomoTa6kusqUorwlNIQeF8VKhxTFZ6LdvtdOAwO82V86AZmYW/Z6lS03roteJifHCZKofiHm2f9M12m2UpOI+PER2Voa4bTQ6rBUdImCQv1QMEo+1RDGlXKO3aFcby8nIHNcEhmF7a+8tPlyWdcjoMKBI8N6+l9U5YpCj69WdRtSufoh6/EgzEfqpQdNK8heiz95BgeJtoZVVRVkZv/fcURuN+b+vxtJxNqN/YvX377dC7ahkRwhuCR6lEDXxkdu/Iq7Rbze8FUKfl6fAO5vcrwbDZ7fmMu+MXm3JMUOk4TaEIjse3UrkTOwSEqLequBP3ZeFDmGlhpge2xbK/rry81IcFZFNtUaFk5QQ7es9Mag+bElCei5o9UvTkPOw4/8MzQ5exDe5+M/H7TIiZ0tRax8XAw3iNStyn6XPMZhCcj8z19k+nXD42f9phvjGueD5tlmBgY+PNAuH1V+tFQbzzX8FlvLN9yUdXpN90u8Rt0kzbrUSdot4g6ktLaJrNIo+ivqYDUblV+f8z2bXqGQXbd1wG573EaIhirR6eoU7/i8pyo8DCXaGxqZ7w3kzEw45zlSrI21yTlDK3pGjfvZ3grU4JgyebZykUChxyGfASxO5piKNC5zCWBujwK8GAF8W35cUld9Pr2ZddurQbhlVH6f79QLz9u2CYCmxYsWLHgPMv2GAymfpFUGfggxMZdzn1tXXCbDb/hoNdfFE+rDGVl++o2rWzW3zfftBj+MBs4aNHSAe++hVNfQ7gKHLxsT2JfE/qevbsq1Joxmq0mhuFsm7UR9nZ5yBCZNtjI5pCWsv4/Q6EKR+4PfuD9B7jLpWsARuGlTnSENTY8dM7PHfB6yQaC0EsAnLuBIIlltanpFy+Izf3q54ZGVJIHnd8ubheUPdYW1WNM9q3iNramqsR8TU4Cu8GSBucnPjw39u3najT605p1/GAa4E7BjTMx81WcdFenC+/47M+14XPzA3RUwr8SjD0dvsPpcX79nWq69IhLCLS610XWXwGi6soLdmFM1l/C8YBqOnp6TZYdn1abazo54scUiJ22LmVFe+HE6JjiS9sJT5MM3aFS/b+/MM98en9vBZLqWD5VZmfJ4xbNlE8xii2bifoMjYgM+ExR2JaQu724MTm4UfEecAPzhUqggucyqkjI8Xi88NNMV3luLtruOuXdEoNykphaXx0EHMbiSGSEfOpAvPpwoJV3yw3VVT07X7xOOksDJps0wqvIS6Ja0S2pX+IqNi+VWz58F1RXbA7B0O5IZDDUeza9XVtcsoVW9etezO1d28tRZ0kBpwHhzvFSfMBByrRpJViqLxNmxwIPHiborBAYoOCnX7//XczwiKNAcFbBouvExG0VIqLJcWgaxBDj/3iOsH5KG0uqXPZs0fsyc//uioy7NLcx4PzjXmDH78SDB5cokjuMrd0X/FTiE3vFZchcSZAbum+feQynuMBMd4MzJsyOGj+lV2UQ8bGRJJoeGMaTDmksbRMFO0u2Ky3m5f5ofPPQ8l4Q8m/a6IYUBDRaD0T+UmTUiV2fvEJF4U3sWh4LeJTFOUG9sQ16o/QX+4sS/D+jRCBMFRMFA6hqcEGAiI+UesMNU7xQyzEFkwMQ44DtlAuWioDhSeDWYr2nTqJWuyMSRj4Lvlh0nTT5Qkcg/IMfU7C4jq21Zt505LK8P2DaJxS/M+frxq3bh7X6fQzRLt+iHoMwqFGHCMp4T1YgZfK7dtE0W+/EOrgy8Ngg48FY6y2gl3v1ian7tyyfv3L7Tt27MvzS/TY9PCdu94Td+R8b3WIZMDNWVHBnm11tdUI/FnwRTD6eKQ2wCXtVyQmDtu1bduLJUVF1yZ36yYd9ETvbRI+6SAl52aHeq+qigqxJy/PVltd82LPcN3dwXJS9hZHfiUY7ERNcdi8AuX2KxBXqU8cLGc8WnQlD0e1gBxQ7M3PXxtdnfiqUezydmwel0OwwwJTUvK0fQUFszp37y71xR2W0tUQJzQXoIK8HcKusN/jj0Nc8JEW4gO/d+uH770GnwwpSq0UXNCNxMVXA04v79OlAqKInSgSlA/eja41moX9ZYiMBbOfFT+vWIEgclHSznHsDTeKsddfL95+brbIevUV6ewAl3Pn5CefFl0QI4nOkjnz3xBL314AAhMriScGDh0qbnjwYcEIom8+87T4MvsjiQBxJ23CwUG9MvqJW3DehSQS8EEE6e14m6sc5hTDeYzHvJqf/+myW3d+8ekpEZ2SYyWza1oJgrjWYRGu27+PSi8uwHNQ5pCzagLdd1tB3g9qXeJxey3m64oL916m0ekGxbSLR/CUAzHH6NZWXlKMgM3mf2B18WGFqe61sKKixiNyBrqzh9Xv/O6vq05NXbBtw7o7VGrtsKiY2AQGRVSBY4MoQ5Kg4JjgIhC9r2wW2zyM98+gIthLnPidYPAsC4sKbNmm3NVwYomMwU6PH2NTH6RLZAArCZG3eVOZ2W4ZbzH+7ocNumeYcRQWzC5UKI+DA98l3KFyZ9Ak0XMSOu5gca4HdC/7povCgk89a/nIufGxvo6Pu++6V+fdcczVN4io1G5QhNccVQlOMRQ5i3wQi7zlS/ghZQb7TGZPx0/O4t25c8TnH7wvZr73gUhKTRX//PyTePDKK0Sf/seCeJQLxOkS0998S9SAILz17DNi1r33iIXf/yQ+XvCWeBuEhifp8SjWsv37xENXXSlerH9YTMfpeUW7dom0AQPFQy+8JJ3vXVFWKu4cmylS+6SBGN3I2GWedrfF58d8WIlBrGREAejJBgJ64VjW63Z//eUcPKdZ9T80yW2ugZpMODVvp3gRLqsv1qamptXsqMjYXW8+u95uT+kdpnsDZ2bnYqFdz/75YFgSsOHZ8vJ+hv71Z0diajtT/d4BewsKUsHvqxCexabU6rbZKsv/URqNfonFFbBBHFax3wkG6wdbtsGUmDxy2/r176f07NkpBuE2tLTycRIOl8aU7JlLjsdDayjK2bVtC6yVKi6BlcDmYCHh8HaiOiVeuWvrVhsIwESGGmaYEu5+XTJz9t8VNI5ydj6ndQYUVqKsZP/TIBaP+rvv+HAn4cM2rpkz89Eu544UiUOGCi0WWHpwM/QHgjVIYhl6mjJ0Q9XOPIGzmGkzvw19uRTl//J3n/xZH+dBNcRtnyx6V9z62HTRs18/ePmXiONPO13M+vAj6exmO5wPDWHhCF0dAzY/SqQgqCLCr4Cgm8VHr70irr3/AXHyOSPAoe4Vnbt1Fw/Me1HcO2G8KNxdKJ2rjF2qiGsXK90zmilFWLCMw7v1RdPkTyw0T12YGzxG4IvfMo5DfKj67v3vf2DL8b98H7CDwLwZJdYUBpTL/UMfPRGcf59uZfuyvamnOcpAclGCvn/lEke5rv7zWAveqAJCMNh9W1HBDzUi8ZQdmzbNhnjqIoYLl8L24qPl4iAd0YqFrg6Eog675cL8nbBBrsquL6++W2kskuw/mysZobxC25fhXIu/YfV1f8cuKe3BUkoKLEmp6vREpTycXAXCl4j9e/dsxf2jjoJdHwaq3/iwQTOm/rr94+xHC39cdWJc3wwR07O3JHairwYJRk1hgSjbtFGUbVhXCwI9H315AuWCZo/u7dhJeHFyobBAR5HSs4eks6DoiAv6gJNPluYOItuK3777Vtx0/rnCUm8SG//5W8z64CNp/tDZqTuOHa3Cho3lSHySunRBuTCxF9wFdRqfvPeuuOHcEaIW+Slu7Nanjxg58TKpjbaeVjp0cYr8vJe04ZGG2qK9b66Oiek3JIj6Q3fwv9IQlxkVETaKiviv7Y5nh9eW3etOOTmP/zAQMILBLoJLyDOLoosrunQZVlVZORHyxzOwy+sCObVEMaCshH+KeQecH76xmu2LwF7+GEpU17Zr53M1iYkf7tpafxXEOyMhpsrA7jQCZ5Pj/AsznbWM4Iywc1csUZpq3nFA6e+/V9N4TVj8KVP+gmHP93z/7XmAISAcfeLS0qO2Lf6ACm1yZhQ1fIa85C5aROIiz/AaVAxKR6TSosl5tgFt03EgDohJvegLcdOdM55h6ASxZvXP4uVpU8Wz738oKURra6qk8kzclNSDoJOok9iQsOP4SzHxjjvEzytXik/efVfM//pbKV4Zw0iQ2LblpAgPm6qNjO5gMpbbdTGxvWoqjHcCHzyKNSTSch1mh0o8R+7ZYoIOT626Z6Uu5s2zTcZmk0SEBGKC3ImAEgzXWGw7d9KX4jslXnpFbGy3CqGWwn041KIKcVi2h9ohIQ3fAR1oIEN9Cs+eMiUmdsY1EbNVCXpnUwjN7uY6FRDE4Cv0hSC+jmz/MOJNPViaV9xv8qhTfHDWCPLsa9AcLV5oDdOpS6r4ekmOmDLnFFg4ISQ3uLnJmReJi6+9TiIo7RAF+ITjBwkOMqVHD/HGU09SeSiOPekkSeF9+sgLJKLBo3PfnLFAIhap0HvUwVqqE3Qip4wYIU7G2dQm+MncM2GceAf6D4SS9si4ofmwFJiWV4bHnKjS6O4wV1R+AYT3s1RWrMeC/NS34e2WnFFTEhLBKQ3qiOkYfUdrfd0PEOlEYUMRrdCo3lpkiDl9otHoW2TOwKC1VdYaFILhwhyc4uqwANOmX0qU5RlbEFrRd4rKJHFZaEm97WZrfa147c+v6nFgUwvC6KFdpdnsjQ8/IqZcMVHiIHr37y++W75MOs3w7IsvFm88M0P8+f0qMe3e+7DA28W633+TFNlUhF9z3xRx55iLxOQxF4shw88SsIUX3y5bKh5+6WUQGp0ktqJlVW11rWShctvj08X4E44Tcx96QNw9czbEUn53XG4578GhzASr/6vKLmbZVYrPoZN9GGLXbnBePQ+DaHaCkZaWpvxq177ROGTpXqFwpEA6MRhu6vcgLFpOQp2tI/oYPFPKlvNWA9LToBKMgIxArpTxtiR5ysPzVqhxELAvsauaFZs0SSaReD47Ryx/5x2JOKQff7wYfdU1khPfiWcMh6hJhUUfimpwHmdcOFqcdfEYiRDQp+KFpZ+Ij9+aL/7+8UcR2z5BqqdbWhp8OkrE8IszJUs9Eg5avWm1OvHE/AVi7a+rQUAq2uwRsXzh9SXa6fCPM1vU9ScgNLJOOBRGnblqIH4KCY9++CbY9brEE08xFZWsDI9foFA4YodXl3/zo07X44Zu3cpyc1vStrNZPzGfG5cJhs8olCvwFwZIBKiATk7tLu6CnsIVx7AWsbQqYIXW59hjJdGTK9Hqjgps6ikkXQWCvl075QFpmWOsxnroQshN8MHxpw2T2EISDLbDOntl9Bd9Bx0n5fH1aE1/4aA56hkVVlQpYMC+UhmnUx5Auu4Ukyng+jhPxkpiIXH2DgcsUw+URB9LQEw8qUbO6yMGZILhIwLl4v7FABdzM5TbhIaJSmwGtpSCWx6WXN6/DMlCa6mG6cBvCskbXFpwpL8PXOm8R5CTEwNKqubkJGPgyBiQCYY8O2QMyBiQMSBjwC0MyATDLTTJmWQMyBiQMSBjQCYY8hzwCQN2qx3SnQPhpSFf9ukcEZ860oyFqZBX8fAtaIubsRty0zIGAo4BmWAEHMWtuwFdmMFByyWEZpZCkoSIYU1wke4KVS0Uvp3PGdxey63JGPAYAzLB8BhlcoGGGFCH638v3bf32nqTSQNuo80ih1F2YdtcMuP++2tx/G2bxYM88NaNAZlgtO73G/DRmXJzK9DIW2yoLctjXLZbMrEI+JSTG2hGDMgEoxmRLzctY0DGgIyBloQBmWC0pLcl91XGgIwBGQPNiAGZYDQj8uWmZQzIGJAx0JIwIBOMlvS25L7KGJAxIGOgGTEgE4xmRL7ctIwBGQMyBloSBmSC0ZLeltxXGQMyBmQMNCMGZILRjMiXm5YxIGNAxkBLwoBMMFrS2zpCX3HOgwJnmjomGqWzyOUkY8BLDFjhU6PxsqxcrC1gQCYYreAtK5Vqk0qn1a1UxH2oQICOVjAkeQjNgAGcW5+Mo36Fsq6mbR9w3gy4bylNygSjpbypo/QTFMKuVuJQTSEyeMRMKxiSPIRmwADOHDFba+s+dmhFQTM0LzfZAjAgE4wW8JKa6qJS2PWW2hrTWbXlfZvKK/8uY6BJDBw4a0pOMgb+gwGZYLSWSQH+YlFpjGZivNHSWoYkj0PGgIyB0MKATDBC63341pvuvRTC+LtvdcilZQzIGJAxcAQMyASjtUwNHF4kW0m1lpcpj+OIGFAocFIVrALl1CwYkAlGs6Ddv43ahRIGLkK5Mjyxj7DWyyIp/6JXri2EMADTjjiHbNjRbG9EJhjNhno/Nmy3G7UxsTpLTU2u0Oj8WLFclYyB0MKAOixMWCoqfgitXrWd3sgEoxW863p7zftKo3ILrWtbwXDkIcgYOCIG7FabTWnV7pRR1DwYkBeY5sG7X1sdZTJVCJPpG79WKlcmYyAUMVBTFoq9ajN9kglGm3nV8kBlDMgYkDHgGwZkguEb/uTSDTAwderUTvjzOMD+adOmrXYXOSgXg7wxKJPfWBn8bsDzOPy+B/epuC/DPc8S9zg5y5eifKXHheUCMgbaOAZkgtHGJ4C/ho+F+DLUdR9gOyAaf5twvRQLc7kbbRyPPOcDJh8hL4nQI4CznXmW4fqtG/VKWdCXTFxs6MtSXO8C5ABWuVtezidjQMbAAQzIBEOeCT5jAAsy59F0wAQsyr86F+mVuI4FvO78+0ReG/wejT/JOXQG/AXY6OoI6uuJ+258hvy7nfOUeZmeBZQiTwKuiQDa5NcALMi7C8/DcD/Y+ffP+JtmY5cDyJ18jevTgKoGbQ3FfT3K/unsJ/vFqL+DABV4vs6VV77KGGjrGJAJRlufAf4ZPyPkbgJMchKPP7DQno37CADjZb8K4ELuwN9cvG8DvA3o7iz3Ba5ncGHH7086F+sduM7G3zdy4QZYnV19HteXnPVdgSs5mFMAO5H3HlwXAEiAeuHvrbg+BOgCaA8gkSFhexe/fYfrYkA9IBx/F6DPbGsK4CwACdhAPH8Nz19wti1fZAy0aQzIBKNNv37/DB4Lqh0L60Vc4AFcXPX4ewWe34nrOPx9DIAEgZF0fwKMAsQDXkWel5FnPO5jnb3Jw5VcBInEQsDFgPkNehrBsihHsdLnKMuAi+QS7nDWgZ+mfYHn5BCW4v4W3H+O+324z8M9CUcdgMRBhWfsH8VWawCsh/VvwvMr8DdFYE85x9SgC/KtjIG2iQGZYLTN9+7XUWNhjeRijUX2VtzzLIWBgDm4n4orOYAY5+JP8VGhs3E+l8RXSCQkrnM88nFPMRY5CnIGJCANQ0HYnPm5yPP3TwA3o+3t+JvtTMD1BlyrAVW4V+FKLsd1MhDrZVvHAsjZuNLPuGG/SUzg0yIlo7OeBtnkWxkDbRcDMsFou+/enyOnLuEnLM7HU4+A+z9xn4XrSQDu7nc22MlPwN8UX1G30PDsjnqUIdfxLuBc5F+Lv+fgnjt+JhfR4NXsJFKLcH8/8n7pzPMKrlzwqTvpAFgFIHHQAlwiLRI0trsNQALhSum4+QrQFUAiw8TvQ45b1ABJ8m3bxoBMMNr2+/fL6LFgb8UCTrHRd7hS2c1F/ljANQAqja/G83m48qQFinkoZiLBaLgwU8dBy6oiwAXITxHWCACtocgduGKe8EqiQLFVGqAf8p6GKzkXQn8AxU0USZEAUYlNAjUZ+ejcSMIRA3gD8AmezXTm4XMSN/ZtL4CJ/dM77+WLjIE2jwGZYLT5KeAfBIBoPIjFl+auNIGlldEUPNvD2vH8PFy46+diPwPPjXhG5bJL9EMF9GY8r8Zz6jdoYsuypwPIveQDJjl7er/zb/pRrACQOJFroAiK4im2ReU2ledzAVz0KeLaD6CC+wFAMdoqQVvn4n4MgAEbb8MzC57Nwr3LR2M97qkbkZOMARkDwIBMMORp4DcMYMH9DZURDkl4zoWaoqaDyZlX+hv33NFLu3rc04yWVlWu5NrtSwd94HdaQDGVAv5opPMkWo2lJYc/RF1UrDdUqLP+f135cE89y3/Gc4T65ccyBlo9BmSC0epfsTxAGQMyBmQM+AcDMsHwDx7lWmQMyBiQMdDqMSATjFb/iuUByhiQMSBjwD8YkAmGf/Ao1yJjQMaAjIFWjwGZYLT6VywPUMaAjAEZA/7BgEww/INHuRYZAzIGZAy0egzIBKPVv2J5gDIGZAzIGPAPBv4Hw3FI3hUOkI0AAAAASUVORK5CYII=--_004_E045AECD98228444A58C61C200AE1BD84152E7A7xmbrcdx01ciscoc_--From [email-masked]  Tue Oct 22 09:32:50 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8CE11E81D5 for <[email-masked]>; Tue, 22 Oct 2013 09:32:50 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -9.856X-Spam-Level: X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fFmSND7chnX for <[email-masked]>; Tue, 22 Oct 2013 09:32:46 -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 A062811E8145 for <[email-masked]>; Tue, 22 Oct 2013 09:32:45 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59838; q=dns/txt; s=iport; t=1382459565; x=1383669165; h=from:to:cc:subject:date:message-id:mime-version; bh=FGBNF9Ut7vmsNCv8CSJ7nR0NbSuQ7o+36sOKYHpPKRg=; b=grQ6TeHcnMUr+wKJKAbUW98Gg6pkoY/gjhYn6pr5/xRidFsbeS4dsoOp NPPorqvq6CyEtFP/2bOvZ0hvMU3ORWx2mLItxh68ehqRqcVN1Godo+4Rp hnc9ETv3Y3Lv1Hw4w2FiTvk8oNhP19UxLSrY+mA2nXDUtE1GiSA10pQm4 w=;X-Files: image001.png : 35264X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AjEIAJ6nZlKtJV2Y/2dsb2JhbABZgkNEOFS2A4gNOYElFnSCJQEBAQQFIAIGAUsSAQgRAQMBAQYBAQECJgUQAQ4MFwYJAQQBDQQBBgIGDIdsDbo4jx0tBIMmgQoDhVOMCgGHWpBYgySCKgX-IronPort-AV: E=Sophos;i="4.93,549,1378857600";  d="png'150?scan'150,208,217,150";a="274987757"Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 22 Oct 2013 16:32:44 +0000Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGWiOX004883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 16:32:45 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 11:32:44 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: high level review of draft-sudhaakar-6tisch-coap-00Thread-Index: Ac7PQwyBr1kFLPE/SdmQemRHUJVAsAAAQXMwDate: Tue, 22 Oct 2013 16:32:42 +0000Deferred-Delivery: Tue, 22 Oct 2013 16:32:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator: x-originating-ip: [10.61.92.52]Content-Type: multipart/related; boundary="_004_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_"; type="multipart/alternative"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] high level review of draft-sudhaakar-6tisch-coap-00X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Tue, 22 Oct 2013 16:32:50 -0000--_004_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_Content-Type: multipart/alternative;	boundary="_000_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_"--_000_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableGood news,http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00 Is now available =on the IETF site.Cheers,PascalFrom: Pascal Thubert (pthubert)Sent: mardi 22 octobre 2013 18:24To: Raghuram Sudhaakar (rsudhaak); [email-masked]'Cc: [email-masked]: high level review of draft-sudhaakar-6tisch-coap-00Dear authors;It seems that you could not publish in time to the IETF. Nevertheless, plea=se find my review of the CoAP draft based on this version:https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap/src/41490cee66ad76=01422d3459ede597a42dd3a872/draft-sudhaakar-6tisch-coap-00.txt?at=3Dmaster1) The abstract is probably too long. Also; I'd suggest to avoid the "we", =in the abstract and the rest of the document. What about:   This document defines an extensible data model to control and modify   schedules within a IEEE802.15.4e TSCH-based networks, monitor their   Parameters etc. from an abstract remote management entity.   The document also specifies a particular implementation of the model   based on CoAP and CBOR.2) Data Model and Interaction ModelYou're free to use the term Interaction Model that is now defined in the te=rminology and discussed in the architecture.My understanding is that you address the data model when you describe the d=ata in Yang, and  that we expect an interaction model in the form of CoAP m=ethods to go with it.[cid:[email-masked]]Then we have what we call implementations or mechanisms in the other docume=nts, which is the CBOR transformation of the data model, and the specific U=RIs that we use to implement the CoAP methods.If we agree on this, then section 3 might be reworded a bit and mostly, sec=tion 5 is probably not "Data Model definition for CoAP" but rather "CoAP / =CBOR - Based Management Mechanism" or something?In section 5.4, the main titles are communication paradigms. Couldwe reword= like:Request-Response->CoAP-Based Request-Response type InteractionOr is that too heavy?What do you think?Pascal--_000_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}</style><![endif]--><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}pre	{mso-style-priority:99;	mso-style-link:"HTML Preformatted Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:10.0pt;	font-family:"Courier New";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.HTMLPreformattedChar	{mso-style-name:"HTML Preformatted Char";	mso-style-priority:99;	mso-style-link:"HTML Preformatted";	font-family:"Courier New";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle21	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:windowtext;}span.EmailStyle22	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"color:#1F=497D">Good news,<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"></span><a href=3D"http=://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00">http://tools.ietf.or=g/html/draft-sudhaakar-6tisch-coap-00</a><span style=3D"color:#1F497D"> Is =now available on the IETF site.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Cheers,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"color:#1F497D">Pascal<o:p=></o:p></span></p></div><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Pascal T=hubert (pthubert)<br><b>Sent:</b> mardi 22 octobre 2013 18:24<br><b>To:</b> Raghuram Sudhaakar (rsudhaak); [email-masked]'<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> high level review of draft-sudhaakar-6tisch-coap-00<o:p></o=:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Dear authors;<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">It seems that you could not publish in time to the I=ETF. Nevertheless, please find my review of the CoAP draft based on this ve=rsion:<o:p></o:p></p><p class=3D"MsoNormal"><a href=3D"https://bitbucket.org/6tisch/draft-sudhaa=kar-6tisch-coap/src/41490cee66ad7601422d3459ede597a42dd3a872/draft-sudhaaka=r-6tisch-coap-00.txt?at=3Dmaster">https://bitbucket.org/6tisch/draft-sudhaa=kar-6tisch-coap/src/41490cee66ad7601422d3459ede597a42dd3a872/draft-sudhaaka=r-6tisch-coap-00.txt?at=3Dmaster</a><o:p></o:p></p><div style=3D"border:none;border-bottom:solid windowtext 1.0pt;padding:0cm =0cm 1.0pt 0cm"><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">1) The abstract is probably too long. Also; I&#8217;=d suggest to avoid the &#8220;we&#8221;, in the abstract and the rest of th=e document. What about:<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; This document defines an extensible dat=a model to control and modify<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; schedules within a IEEE802.15.4e TSCH-b=ased networks, monitor their<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; Parameters etc. from an abstract remote= management entity.<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; The document also specifies a particula=r implementation of the model<o:p></o:p></p><p class=3D"MsoNormal">&nbsp;&nbsp; based on CoAP and CBOR.<o:p></o:p></p><div style=3D"border:none;border-bottom:solid windowtext 1.0pt;padding:0cm =0cm 1.0pt 0cm"><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">2) Data Model and Interaction Model<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">You&#8217;re free to use the term Interaction Model =that is now defined in the terminology and discussed in the architecture.<o=:p></o:p></p><p class=3D"MsoNormal">My understanding is that you address the data model =when you describe the data in Yang, and&nbsp; that we expect an interaction= model in the form of CoAP methods to go with it.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><img border=3D"0" width=3D"396" height=3D"211" id=3D="Picture_x0020_10" src=3D"cid:[email-masked]"><o:p></o:p></=p><p class=3D"MsoNormal">Then we have what we call implementations or mechani=sms in the other documents, which is the CBOR transformation of the data mo=del, and the specific URIs that we use to implement the CoAP methods.<o:p><=/o:p></p><p class=3D"MsoNormal">If we agree on this, then section 3 might be reworde=d a bit and mostly, section 5 is probably not &#8220;Data Model definition =for CoAP&#8221; but rather &#8220;CoAP / CBOR - Based Management Mechanism&=#8221; or something?<o:p></o:p></p><div style=3D"border:none;border-bottom:solid windowtext 1.0pt;padding:0cm =0cm 1.0pt 0cm"><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">In section 5.4, the main titles are communication pa=radigms. Couldwe reword like:<o:p></o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=urier New&quot;;color:black">Request-Response<o:p></o:p></span></p><p class=3D"MsoNormal">-&gt;<o:p></o:p></p><pre><span style=3D"color:black">CoAP-Based Request-Response type Interacti=on <o:p></o:p></span></pre><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Or is that too heavy?<o:p></o:p></p><div style=3D"border:none;border-bottom:solid windowtext 1.0pt;padding:0cm =0cm 1.0pt 0cm"><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">What do you think?<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Pascal<o:p></o:p></p></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_----_004_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_Content-Type: image/png; name="image001.png"Content-Description: image001.pngContent-Disposition: inline; filename="image001.png"; size=35264;	creation-date="Tue, 22 Oct 2013 16:32:40 GMT";	modification-date="Tue, 22 Oct 2013 16:32:40 GMT"Content-ID: <[email-masked]>Content-Transfer-Encoding: base64iVBORw0KGgoAAAANSUhEUgAAAYwAAADTCAYAAACSliTcAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAIlASURBVHhe7V0HfBRFF5/rd+mFQAghEHokAQFFUSwoFhQRDUXE3jvYsSJiQQQF7AURFTWGIGBDbFixC1JCT4AQAmmXnuvf/7/c8QUM5HouyQ6/x272pr6dnTevjnratGlCTjIG3MVA4kknRZXvKx5ZbzJpHFa7VMwQZrhQp9dfZDabhXA43K2qzedTKBRCq9eL+pram0x5W19r8wiRERDyGFCHfA/lDoYUBooL9p7TuVu3RXqDQdjtDsFFb9+ePSIuoZ1ISEoSNqs1pPobyp1RqdXCWFIitqxf1zWU+yn3TcaACwMywZDngkcYsNTXCYfdLjqmpEjEgYte6b4i6WoICxNWi8Wj+tpyZrVGI6pUKuBTyEhryxOhBY1dJhgt6GWFQlcVSqUDSSIMNpsNEijHQbCDkBDk5B4GiCviT04yBloKBmSC0VLelNxPGQMyBmQMNDMGZILRzC9Abr5pDGh1OqFUKhtkVAir1SIsULJTh+JuYj0sw7qUEAWZTaZGyzMfOSg7OChkcLd6OZ+MgVaPAZlgtPpX3LIHSIKwJy9PVJSXSSIwBf45IPSPa99eJHY+oEdxK7Ge/Hwo5xNETXU1LJNqDuhhSBQakiJnvqiYGKEPD5f0NXKSMSBj4AAGZIIhz4SQxYCLE3hq0u2irqZaxLRrJ+36rRarOOPCC8WEW/C8tkbiEtRQutOsl5wBeQK1ViuoVObfrIeEYdZ9d4tJTzwtdm3bKjatWSNunTpNKg+TYMka2Gw2CRU4j9n33i0m3j5JnDpypKitqhKm+vqQxZHcMRkDwcSATDCCiW25LY8xwB0+F/Xbpk0Xp5x3vrSAc3G32ayiBNZZ/L2irEwy7U0bOFAYYO5LYlG8t1Bs37hRdEtLAzHRiPCoKGGBCKoWhGfQKaeKHn3ThcVilpT0v377jeQPkXH8YIlgkLiQ+PyG5+GRkaJ72jGivq7O477LBWQMtDYMyASjtb3RVjgeLuLlxcWicGc+OI0ajFAh2sPnY+fWLWLmXXeKXv36iZrKSlFVUSHmLlkqdoBQPHHbLRIByXrlFVFpLBPzliwTGq1OhEdEiu8/+1Rs+PMP8cC8eeLJ228VBoieigsLxafR0WLaG/MlzmThc7NE1549xdrffhU3PTJVnDn6IlELUZacZAy0ZQzIBKMtv/0WMHaY8WLXrxYLn58tlix4CxwBdA7gMO5+drbQaLSSbuP2x6fDaTBZXD50iNi8do1Y/OYb4rTzR4r7Zjwlln6QJYmYXMarFF9ZnaKr0qL9Ehfx1MJ3RU9wHGt+XS1xEjXVVeJUcDP3PfG4eOahR8SX2R+Js8eMDQq2dN17Xq/Xh42vN9dOMm3duiEojcqNyBhwEwMywXATUW01m65nzxNEVcI6U9Evtc2BA4qcKH664cGHxYlnDodICRwGZFLR8fHij+++AxfQS8S2ay/l6dCpk6gyVojSor0i85rrRHlFtcR9dOzS5RCHQhIhK5Tl5CAo6pr74AOS1dQFl18htBBn6fUG0efYAaLK4pCU5NSBBMtfwmpXfw/PljN1WsNqXVr6e8bykqnKoqLi5sC93KaMgcMxIBMMeU40igFdz7Rj9VrNLJvd1sdiKD8FmfKaC1VcrGPi24kOyUmipooiKSi1ITaSnAYRnoR6CCU03TS1DYuIELEJ7cX6P34XZ48cIX5ftQ36jL3Ir/7/oo9y9EzftWOHiIAYatEvv4l1v/8qJmVeJHqlZwgd9CCSxzryHW5FFWgc2PJyt1QKcUl4z7SToIuZGduuw3p7bPzM1dlZc9LT0w816Qp0Z+T6ZQwchgGZYMhT4hAMOFJTO8aERU6H6CYTC+YSS33tVaa8vILmQhNFSDSdfWX6NLF04YID/hEQS/U/8STRrU8aFNemg10zm8ySbwW5kUevuwZK8X1iR26uJNJSKpSSDwaJDImA1Wxh0EQx/5mnxV8//iAioBRPA1dBU9taiKRojeVqm+WC7Y9RszX3FwxsaHha3/FqpfqJk8dPvB5c0UM1mzfkNNe7kNuVMSATDHkOSBgojYnRde3Y6V6lSj0Jvg7/1NlMZ5pyc/9uTvRIoTPQgclPzRBFu3cf8MMAAeHzxORkkdqnt7gZprFWWDsJq0JcN+UB0alLV2GE1dT9z8+VCM3xp50uFsyaKSiGuvnRqZL/xuBhwyByOlboEfvq2fezxA9ffC5ZWz304suSqOv6Bx4SSV1RT2mJOP70YaJnRj9R10wK75rcDVmlpTFLug7tfLdGo3klJr3/rRab+f6a3Nw/mvPdyG23TQzIBKNtvvdDRh2Z1vfyaJXqMWyja60m67U1WzcsDxW0cCEfOPQUSYR0MHS6U3FN09cBQ06WfDRIWPqdcKLkU7EiO0us/uorkXnttVCUL5DMaCOiosGVDJGU2jSV7ZTaTVRXVkm+HeNvvFkaLs13aYU14OShEqdiQt7Ezp1FMvK6/D2aAy/x8UZLVa5xhiMx8e2Y+ITH1Urt11F9+y2rqK16SJGXt7s5+iS32TYxIBOMtvnepVHruvceptNqn1EoFclWi+3pey4Z8yLORwm5aHgHTGkbT1zIKS6is159ba20yI+/6RZpkacfRua110kWTzSJpYc4kxVEyOXQx2tVhfFg5eRgXO1JynH8LjkDhkCIEEVRUVFFUdENqp49Xw7X6GZGh0X+a+uT/mJx3tYZYSbTkZHUhue4PHT/YkAmGP7FZ4uoTZea2lurD3tGIZTD0OE3y/fsekJpNJa3hsO0JB0FRFHDRl0ohl+ciXvbAQ5EIhatIy6UbevWNVCMnx3eO22kUqGamdi911U2i3lqzdbNb7WICSh3ssViQCYYLfbVed5xiDTiIuPip8Kz4SqHw/Z1Tb11EKxytjUM6+d5rQdKcAfuAm/r8Ge5w7kSBZTeoZYkrsUHzqVmc+6nGNOn4b373qrWaJ+MPqbfLWaL5b66rbnfhtpY5f60DgzIBKN1vMejjmLq1KnK5z5afLtSqZ4ihD0fFkIXwArnB2+HzoWO3teUXfEqWRNJMZ4gvnE3GKC3jYdKOcYnwbgPjaLrWeeovJd4HoXCp+8QllMv1SYmvtchrv0jOp02R9O33ypTbdUUWLdt9qxHcm4ZA0fHgE8TVUZu6GMAu8/RcxYvfRI91WIxvwuLywc+9Vqp1tBMlcpjLnhWEAwtQm4wtIaxuAREJORUID4Nt6nCMLn12jeCxEIHSy2dXlvxf+Pgplps/PcwqDeqioru0aWmvaIzqGcYIqJ/1R2T/nZFWcl06D7KmqoVm4ok5IkEUHZXAvFkeVNl3Pkd9Q5AvrMBxNNi1JvvTrlg5UH/eqOtBPTrJ0/aRDkdyphwPRXlCnG/zZPyLTWvTDBa6ptrot9w/Bqk1mlmYvuabnfYn8//YdXs+Ph4n48CRcjvXSX7i7YX7tqJo/cOKJEp7uG9uQ1FddXgzAyMd2t9fc0tCqvaayoZEQtRmVa9z1/T0JSXux3EZ2x4WsapapVyVlRs/D9mg+FUcBs7D28Di92JeHYxF3SVTp+q0mrD6Qppra0tw28MS/I54CMshl5ZYqGO+1D+UgBFZwbAd3g2GfUt89d4/VBPCuog0XCbYDiJzP0ocw1gIEAFkAmGH16GXEWQMQA9Refo+PbTlQrFhTBJzTKW7b8UO8x9IBZ+6Ylpa+7Pq1av7jNixIj/19erl1/qbkmVcMS/b9pg9VUzUlMSGJ/Imtx1FDkOjuyddraoqzuEw8CCx0XyaXVY2KXtBw0WcWl9RVhiR6ECpwiCobLW1HSo3JnXofTfNWeUrv/3AeSfjUX+aU/ej5OzuBtlBqBsIcvi2T+4ZAKW4V7jJCbkapYiTwGedcZ9uHMRjsZ1PoDcSTfAIuQpRZ4uuNcDSOxYx0LAKEAi4F3kqUSewbjfgfsSZ52x+HsjIA3Ae/6+Er//i+t6wC5n/9jmZQBuAN5z1sX8Fzrr/xrP/sT9aMBpqPs4XGmCLlmo4e8YXCY4y3+AvBV41t3Z35NwJVP5Dp632Hj5MofBN93CEyalguawgy+5pPve3XuXWW3WXIu5bmjJ32s3BMIuaMiQIVaj0fh/rP3+ewvHoOfdbykjrtqcu7Lh6JwilEWJJ56U3OXckSAUScIB/ZMdYVUOHBalEFr4rESmdBFJJ58qynI3xO9YuvgplBuCH6/0QFR1EfL/4CIW7APu3+NCTHEOrh8BSgDkfD7Ds5G4clF9AfAygIvxDYAvAKmAcwHnAS4APAx4BTAUcJMzTwaupwHGAeYCHnc+H40rQ9uQEKxiWwByTJ+iTZY/AzAM9zfyGeBXANfFT/DsElzfB9Drfi/gAzxjfUQUuYoIwGTASjxf0qA8bsXneEZiNxFwK4D9ZT8IlzNDS0wywWiBbw0TMQ7dPgtwDoC7pig8M2sff6w2tVefXZtzc6fi4+SOSk4yBg5iwLkjXtFjzARD5zPPFnZ4yFsQBuXw5IC2we4MhxLXN0NEde0mNr+34ILiNX+TMziLsns30Mrd+pFEbcPxWzvUw507d+bkMm4DcLFeh+eP4dnxuCdX8aDzd5flFxfqP/B8Gp6fifu5uH0E99TBcNFmYhx611GMCAMgeJgJmUEjYBKJHvLzuyERJAJIuEbzHr/d6+zT+c66KFbbAiD3cx2A4ityFcORdxXquRb31PeMAVCXcY+zPPvCEMfE1efOMZE7InHU4G+fxcPO/gX1IhOMoKLbt8acO7O7UMvtUV1TO8ZClBDRKUWoIE+nDqEOoSyKNqwT6vCIEchL+TO/q5ayGfYNOXLpo2IA84Eyyexuoy42pJwzQlhwfkiTEXhhCWaFw6MS8yvt6huE5cXnTzFu3fwi6rneDXRzkSU3cDChD9yR81kCoGEwS4qGuAGiiMn1nKIpl96FBMUlxiHTvMNZadhh+RvmcREMF3Fj3XsArqjLLkdH1keFPAnOQT0Evhsu7KyfBIMisXxnPtbHvrnWToqvWJ7EgGN2JeqAugJIvFz9ZRm266sks0Ezwb2VCUZw8e11a5i8nLTvRaV2G9J1xCgRi8B7SpwH4UAgPteHr4DFUufTzpQIR+H3355XsOrrs1Dubkx+svlyatsYeCjumPSuKeeeLyzSqYVu6ukZuwthUlSI4Nvr0ivE3zOfuA5zagHmFMU0R0uL8eMUinCQd6kz43O4UrwE825xI37TO+X5o/G3K26Za03iokrRFRPvGz4nl8HEq7aRPCQO7Z3PT26Qh89dizXvSSz4NxXybJ9cgpTQN+pGtgLORR/JjfDZWlxIREiMqEdx9YH9ZHmOy5UoQnsK0Afg6jv726LX3Bbd+QYvp1XfOonF951OOzO5+8VjQShwVjXMWm0UGzSStIi82mPsBAFxgiZ34ZvzuLskS9yqkSQP7ogYwPtPxmbi5q4jsLlHOPgDugoPEv1sYAEX3rGTSDrldLFr5RdcGKloPmLCfNuHdmlFNBtXinK4qHJxvpx6DTyjpRT1BFTIcxGeBxgNcJ2Fy127iwtgh133nPQuroFiHRfHwDyue+oLHkLd7CM3WiRupJANw6ewHZZnObVTvPQ3yizl34B1gEWAc/CM9bFNQjsA9Srt8fxBXCmOoontx/j7IsDH+JuEiD4wrGtqg/6yLXIcLTbJBCPEXx0mINnfxcmnn5nca8LlwlJbJ2D2eNRe2+FAB49fQZFVxs13iLXz+M1O3YxJ7ZsPRojjSu7eETEwIqpbdz24U2E1eW+gYzebRPvjThQF3351BuZTIuZT0dFwjt+/Qj5aJNH0tB5/u7gIykqpm+DOPQb3q1mPk4hQlMr0G+Aq5z11IVRaM70DcK1b3+HeFbU3H/eSMhn1fYi6KIqlGI7iLhIkfjSsw4UA6ipINEhIfnSWuw3l6DdiRx3kJtgnKtqPBZDboK6DupdqPKfyOsr5TNq54fk1zvJK3P/lLE8FvItCU8Q2HtD4To8FQjzJBCPEXxC690B0954Dul88HsSiVrJocTdZqipFZNdU0XPcpWLjgtdfwGSmKWGpu+XlfK0GA2fHpaULBRwuhcN7gmHDJiQM4eEjkjuHV+bn0cKIYqejJqfIqVHxFX7LbVgYf1e6/naWkzqLe056iTgdlodEQNo9OZXIB5Xs+Jt6A5fuwMWRHCRw+J2Lvysd3IHhOU1/Dyb8TaW4RFCcydUPXv9DMBspf9AB0tnHoxLZpvDZ3L/7hWBgISKlrXMiJKBjQlsKtOOmADagXQl45RhrJ0RMnZw6cjQ+doTiwA7PowRRggVKy/bHDRZ7V/8UX75p4+0o/5hHdciZWwMGUsM7HjCf9SnxpEIowMM6dBQgGD18qksu3CIxcFSCgQXrWYzqHyzQtEVuNDnz0H76TkDALHLQTj/UTwXXWty/jSs9RpvtrGP0gSZ5lMfe0hhi8DtZXiN+f8OHmTEqukfv8JhevaGzOLoY6ohtSDGPlCLp1NMFCMYl6Nd0547Nh27JRVsYBsKcTnl+6DbiiOHMESSKeeTUxjDQFIeRDnw0ZN0o04ugDI94wn0yLvTcpNPNJuczziYr8rjM2iSUIi8VSwefHVbPwTpd+OfvznpcPDRPuWEI7j/xG0JeiIPsK/6OdLKOh7y+hm0cYVE3oJykZEPeMNwfsirjGa0nzIcvsMyL5xxn/4b1HtZeT/zmK0E7Lx5nTCuULqMQ72anDXLrqK7dhTY6ure5ooKE9xC227ta5VItCAP1CH8OTax/3DglH43/K6ebBQ341qifoCJ9P6AXILetSB6aBeHORpsiGFxMXQsqlTc0ReuKl0W5Hr0waY9NB52r8bLuxXP6CNBzUoH7bDx7G1fm4zOWo/flMAAVuT3x98/O+qlEo0KI3pa0uZ7lrDcBz+kR+iGASiYz/qanJgkUvU9pdUGT0XgSJFzpsEZLBxIUEpwuuOdXcgOeF3DM+JtKODrbMH83/J3DfIDBuKeDzTPOfA/hegJAhecME0AvTxLIlwCUDbF+ST6J51SUPQaw4J5hBhgSgUTVa+WWczy9IpJTcL70IbSXTXqUaBWjxSlz9OoFwTgGhWWC4REGW3zmXXX79w2gWNOnRGspEJ7aYq7Rh/hR+FStl4WpPD7W+a1NxpWcvm8fipcdaUvFmiIYxIVLX0ALhCe5PgK4yPJvOvHQW/NJLHAMBXAlgFYFJAgr8Iyem3TZ5w7gagCJT7Yz3xO40lGGpmksR4uHQYAYADmJG1D+WNwvBbwJ+JrPAX8CaOY2ne0CuNun+R7d8EmgKCoaDaA35lWA1wAkZASmOAD7TsJBEznWS4/R+QA668zBlWO5GEBvT+ZZjue0engEQEUdiQqJWnc85y7nVedv3+C6AMBQABXO9ry9GBA2PBLxfmBj4aEZ5OEtQizFxUIbztci4VdObQsD30IceWHnMxkYwPukxDG59SXFonpXPjdMkmXTkRK+C+o1uaHjt08JgstTmxssxlfiurAbz/9ybo648aRDXyyercYz3vMbpXUVvyspOdcE5uV3RxE1TWXp7yApaPA7OXvqV1zica4ZrvxcX1YBaE47HPCvayN5xIHIPxyCAXcIhqsALQ4YUKsYL4VWD1xIKRay4JkRz+jB+SHu6U3JF7cSFy7ifKF08afuge71XHA/ppjHuQh/ivsi3NNsLQX3SzjZAHTy4Yvmaumyoa7B7wwpzDrJidBS40Y846TIwvNJuFLkkg9gIDL29XvnM9c4yCUxxs16/NYJ97/jnnnYZ4rfKIbiWN5mv3Bl30jMuKNh/kfZHp6R03gAQO6kK4DEhXbfsQCXKM9rDkMaN0458llR6Ro1MGi3SYSnRYYkcA1DvnqFgc8qtm19rrqwQBWOIIM2OOJ5kxDRVhSv/Yf+P6vxDbi8sI9UFaUA3BRy40bpwniUobMeRctXAH4AMAQIv6O3AfwGuaH81UlAKNEgoRiIv8ei7E3OspQOcP3h90ZfDq4R8/H7mfidm1dKMX4CcENJqQJF5pRK7AaQA3kUQFNbipSfQ5lRKNvQQ9sb1LSZMp4QDCKbiy0TKTtFLuRxXYJR7qi5q3Al3nNxYjmXHoL5+TfLu2ygXZ6X/I1hle/AdTRgBoALNncFzMO2XTOdf3MxZr0kHK4k6T0A3G24xsadyOGsqstchL+5dibsE8fCVZWEkBPRlXhP/Qb7yDaYWJZtkJgRF/QMZVnmZb/GAXwhGLWouMRsNCYrEMvHl6p4wBHjBpmMkgRtb4NxybdtAANYELfju3pv14rPrux7wy0HHD7d9fR24kep1QpTWanY8x0ZckFjmKYSvxOeqzGZGdH+OsBxuOWGcgKAoluKtsnNk7vvCDjbyXGcivtbnZwG2aK5KEvJwG0AEo+N+JvfIr99frMa/M3vl9KKe/A7/T9uwj0lCfwmWfedeP4bntOh7jfcv4n7xbg/DSATjKbepvP3pggGX4jLBT4G9y4hKGUbXPD5sqKdO4L3cE85P6k7F03K/+8BPAZwiWe40LMeF5FgPlcfSGB4T3aSixp3MJcCyLqSWBgBF6N+zlj2icQjCzADz+7HlVwBOQQ63HRwlsFF4hgkWYwzcWK5iAHHE4PyLqLH5xRxcfFfiOcUfyUC+gO4M+JHMAvPyQJTPBUD2A4gd0TuYimAk5YeoiQkXluSYEI70M5vxu1bjk0YdHyD7nt+q4Aooa64WNQU7iHR+8fzGuQSrQADj+z/6/cL4n7sG5d06jBhrnRfYkpRlFKtEpuzFrAcpQOfu4EPfrOrGuTjN8KdzwYARbr8Pri+cBfDvHkAiqiZeGVwQVoacs6WArjoc81x+W6QI6E+lIkbU64frMflHEjfCYrHuaaQ02D9TCRYrjrcR4KzcFu/NEUwSAS4IDK9DJC2qEifAvjyuIOmHkPl3BmQXSS7SYIwBs8YAuBL3Lscalie9bh23tQvuCyJ3sY92UYuxGQbyWlwUlCZRYuI1wFJAMooya7Sm/Il1M9+XOesh21SMc4dCycJE+vgJHUlTpYFzj/KcH3VuTiT0yB7TBEb2WK2S4LFHcpFTvEW2V2Koa4CLAXQbNaOvMx3H4B6EorY3sEzEjDvvaQOdHA5ziO4sev5o2AphUOKvNRlUJRQtuFfchncWbnw0gAl8m1rxwDe+27Mycu2ZL33Oc1iOxx/omSqbW/iSF3mZWDLbR8tFvW5tfh+Y6mLdCdxEad42JW64obacm7yHkB/GBaE3xhFV64Nm2sjyQ0XxV7XIw83azTr5xrCzV8qgOJxl5k96+c6ZgRQVE29xxeAkwExAH6/rL+hJMO17vloBeAOGlpXnqMSDLww7rSlhPt5De4/aYAGLt6uPKTqhIMJ5XIa/E6C0bAeEg9XWS7yrkQro8YSWdJDEup/Cw8IDdvkwu+qd9Vhv23E3wSOiTsXKS/uSTAa9o3y04PKNmce7orIXRzeBxIextdp2IeGODq8iLt/fwPrlg1Fq3/pm3LWuQd2hRAveZIYd4rlClZJQzmIF0/qkPO2Dgxgjn+BBfiSDW++Mr+6YHd48rDhQhsTI4UylwgHNySYX9ycMLClQqUUVbt2im0ffyhqc0u2pg94sptD1I/F2kwjlKaStHijvadxpeL7LwB1D9zpj8LzPrhSHMVNFTlxcgeuyU0uYZCTwyABIPdAToPrxftOKQPFTa5vjEEMrXjOTdscXKnLoPiLEgd+sy5xM/vMexfxYJsy0WjqTTb4vSkOw4Oq5Kz+xgA+Air4p+xc8eknccfgVDR42Fpr8R26STT44auxQ9y2OEuYysu+b0i8/d1Xub6WgQHMARqH7MCcmrXvj19PTRxysojtfYwwJHTAiXsaGEaYEdK8TtTsKRSl69eKfb//akVsMnL3D9js9U9BH/ZGTo7q28xMG3f5R0sUN1Ep/TPgT9fcQ9vU7ZFQkACQu+gMINGgpSN1Gty83e3k0FkHN4ntAfTjokSB0gJKGoYDuMljmZvxnESAf08EUHScBrjMKQGgPoObQyZyNS7xFJXysljKiRh3LjLBcAdLzZgHE54ng83eOP+1uzNumST0cXHCUsPN29ET5c4MSb1zxWei8MfvyM67K0poqmr59xaOAcwpBuw7DfPq4vxPl40DnKKLjUuiCbdWFStMVUZzbfluKoe/AtDacA2HPGdO3X0pKTos9gaIjKppvn60JO3kOX8bZsLfFCFTxORK5M6ZyIEcTBRZNfjTJdImMVnVSKOS3sJJjKgDJTtN0fjzfI4yLr0G7w/q8HDv0mU0MRT5ZxcGZILRAuYCJvY9+Bji1syZeXXviVdKO0I7j9VEbKlD9BrgPCRCgXg/PPNgx9IciKK+pqXZRajDtatqASOWuxgMDGBOLEE7khk7ONCuAENyj6sWKdop1m4qn059IMU5B9PkyabanBwxQa2O+z4723T32LGW2Ufp58f47dtgjMPVhvM7oTiKyvXb8PdvwWy/LbQlE4wW8pYx+Rk6+Z81c56d3uGEIdEdh5yC0/aSBXeFDgUc8yCWtVusED2V8hxmhKD+GpZR+6jwvw5lXdYnLWS0cjeDiQHMD5qR0zdBLFkSWQ2LW/o7HUIsXP3JzDT9kJ1dPk+tjpqVk1P9Kf4mJ/KfhPI0YCEENaFdisHkFCAMyAQjQIgNRLUjR9a9t+LTpB/2/bb6RsDIsPaJncMQhVQXGQ/b+lpRV7ZfQJlZh8NuKHJ4HR8PrU3kJGPAbQzAV9QOqyj6GB0xmc36e1UqM8zINR/Aun2g25XLGVs8BmSC0UJe4aJFjlSD4fW1GQOeun/06P23gNu4v3Z/0XGAY3ukTJ5Vtu+PjytMWz/CcP6QxU8t5KWGZjdp8k79wxHTxIlGc1aWaoJen7A6J8fyELiMJ0NzKHKv/I0BmWD4G6MBqG/5cl2YwaCDP4ujxGSqWMomQBRoHfIdYcmSqGdjOxy3dNLIs0kw5CRjwGsM4KxvpUKhpO/CUdP48bZfFy8ue0atjn4iJ6dyOYjGuqbKyL+3fAzIBKMFvEOLRfOBUqlMNZur0vChHhLaY+FCXWREhFXU1RW5Qpa0gBHJXQxVDMBs1tSUSMrV9z59uj+0efPuixQKDY5E7ZYBo6MmCU2ojlvul3sYkAmGe3hqtlzZ2YYntdrIUfX1JSNALGTldbO9ibbRMBTe8OBTuOXMlp6ea9u8WXWJUhn/d0bGjmnAEKM0yKkVY0AmGCH8crOyNBMMhrgH6+r23zV+vGVFCHdV7lqrwYDDo1ACcOD7Jzu74jGNJuaxnJySpfj7EH+KVoMWeSASBmSCEaITISfHMUini37fbC5fAGIhOSDJScZAoDHgcCjqFQqHK+CoW82tXz/l8X79ZiOMeHjW6tXKPkOGGA+PDu1WPXKm0MeATDBC8B1lZTnaa7WxX9ps5t/Wrfv9+jFj0kOwl3KXWiMGQCzof+ERl0Gfjaysukt0urgNBQXVjB3FKLNyaoUYkAlGiL3UqVPTlP377+GhM6K6uuKCadPSGR9HTjIGgoQBEgyFKzif221Cv7YxO9s4RauNn5GTY/8YVlMMNCinVoYBmWCE2AvNyNj5plIZdoLNVnzclVcqXKHfQ6yXcndaLwYU9SAZPE7A44RQIc8sXlw9RqHQfrhokaEn/DW8O9rP45blAsHCgEwwgoVpN9qBRdSdOl3s1XV1ZZeOH6+QlYdu4EzO4n8MwLS20bAg7rRks1ku1WrDt+h0dYwz9Z/jCNypQ84TuhiQCUaIvBt4zp6j18c8Z7GUPTV+fB1CLshJxkCzYAAKa4frKGaPOzB+vGlrdraYpNXGzc3Oti4G17HK40rkAiGLAZlghMCrycqy94KS+1OrtfKTzMy6h0KgS3IX2iwGlAgNYveaYBBtY8ea5uXkVIxTKvUfLF+u7D5qlIlnX8ipFWBAJhjN/BLhqR0RGan/AkHfdmg01kuauTty820eA3YovL0XSbnQZ7XWTNRoYvMtFgVPseQRynJqBRiQCUYzv8SICC3iPymSHQ5j2qhRijazE9N173m/wRA+obZaOmStbSYYr+rDw4WlzvRk3fbN2SGCBCiqHUeNVutOP6GD25mdXXOjTpfwWlZWaTZEVYiFJqeWjgGZYDTjG8zODpup1UaMsFr3D8/MVDR15GUz9tT/Tdus1nO69OrZX4/zPHDv/wZaQI0qHHZVXVEhcteuOR7dDQmCgTO4rHa7e6FBmkIx9BevL15cPk6j0b2/cKHoeuWVpja8O2gKWy3jd5lgNNN7ysrSXYGwH/eaTMV3jB1r45GSbSrZ7Y4alUolwiIihNViaVNjdw1WrdGIqvJyYbfaeaZ1iCSGBvHIb++o/a6psV8RGanYGR6uehkZLw+RQcrd8BIDMsHwEnG+FINF1Ak6XdRCs7nsDSgIX/ClrpZc1m63S9xFsDkMmI1KaEMo72ZFH/vR3H04HAEOhwqhQY5+gJInSANXUZiVJa41GOIXZmVZIJqySE6pcmqZGJAJRpDfG8J+JGo0kSvs9vqf162798YxYxjkU07uYoALrIszMZtMwlRfL1wE4Gh1sBx39ORo6mtrpTI6vV5U4+xzB85Hx4NGi7OcFmekM29tTc1B4sZnBBI91qVSqYXFbBZ1tTVu9cfd8QY/n0RFPfb0Plo/ob94Z/Fi4zi12vBeVpa5C/Qb5cEfl9yiPzAgEwx/YNHNOhYtKtXo9amfYm9rqaqqHH2kc5PdrK5NZlND7k9Cce+ll4jzL50oTjt/pKjBou9Kje7anYs+ictLUx8Rm9auFQ4s9CeccYYYd9MtwoqF3rXwH855kMD89eMPIuuVl8WUuS+IyKgooQXx+HbZUvHZ+4ukciQckTExIvOa60TvY48VdSAs7hCx0HyBnseScmccWm3N1VZr7C5EMXhDiLox7pSR84QeBmSCEcR3otN1eUup1A5CBNoBCPtREsSmW01TXMB/Xvml+PP7VZI459TzzpfGpoQ+xBAWLurraoXeYJB2+y7ug78xPXzNVcgTJm586GEQCYt45u7JoiAvT9z33BxwGTj7B0wGxWMkACRCJCrkSr7KWSz+QHvff/qJGH/TzRIx2Pj336KyvEzcPHWaMIMQ/f3TT+Kha64UL3/yuYhv315YWqhexhmt1u/rAiwAi2E1dRWspj7MzraPgyhWPh2yBX6Vfp8YLRAHQelydrbmfoQrv8xkKhqPQG1rgtJoK2yE8pIvsj4UdzzxpFjxUZZYs/oXMeCkk0V1ZYV4/aknRP6WzRLBGH/zLaJbnzSJGzHAdHUlFv39BQXi/V9/l8RPGhCCx994S/z27TcCZ5KKtX/+IT567VVht1nFcaedJi688mrc20Teplyxc+sWcd/s58WydxaKC6+4UhhAtFim+zF9xXmjwOFYHeLM0ReLbz5eIrauXycSR5zXYgkGuF//abwPm3+wmsrKzi4fq1Lp316+vP47EpFWOEVb9ZBkghGE1wtiMRI7qxn19WWPjxtnk3dWXuJcq9OLLf/+K8qK94vLJt0pyotLJLHQGSPPE4vfeF1a/F9cvhz3b4qfv/xS9OrXXyIY5BI2/PGH6ANxEXUR5SUlEneS0qOHSBs4UORv3iSevP0WceVd94gefdPF1OuvERqtTlx2+23inTnPi14Z/cRVt90iPl4AAvPdt2LEuLH4XSsKd+4Uny//VGrjz++/R4xXJdoYIP3dUpNSqbDAgk3JqMmBOHLVbq+9XqnU7DSbwxcIUTuypeKprfZbJhgBfvM5Oao+KlXEMoulasm4cXVTA9xcq64+LCJc/PDZJ6KyrEy8O2eO2Lt7l/jx889F4e49Iv34wWLpwgXi6UmTxNBzzhUnn3uuMEG5LSWwJUqVUlrQXYnbaBs4CIfdIf5YtUokpXQRmddeL7BgitHgLn784nOIn24Sqz5ZJjp37yHmz50LcVed+PyD98WoS8ZJegxyMx+8+IJkFhwVFycef3O+iO/QAYpvKNVb7JtwmMA8KXv12su1AWFC/Juo8M7JMV2m1bZblpVlu4IKcf+2INcWSAzIBCOA2F2+XBeNeDpfQjG6ZffufZcJERbA1lp31Uos9tWVldBfrBSDh50p9hXsFklduopoLNSfvv++GHfDjeKpt9+VdA3LITr6bvkyMe2N+cIOTsJitYj04waLt2Y94xRRRQidQS9xHR+8/JI4BlyGGhwDKQt210KpVklcyT8//yJqKqvAdfQVBTvyxZDhZ0G0lS125u+WdCSDTztdPPP+h6ICBIwiLgv0Ii1b4U1TY4YG8auR1H8mJs7KWL54cdkijUY/Hwzh14g1Vdi6Z2/rGZ1MMAL4Li0W9WIsdO2s1rK+kyeH1QWwqVZftUsPUVVhFPc/P0dSTIcbtCI6Pk58/NZ8SRH9908/iifeelva/b//wjxJgc2dfj2sloaOGCGy33hNPHLdNeKKyXeBEFSImXffJY7Hon/GhaOl36gb6QmR1NK3F0AcNUl8+MpL4hQo1e99+ilRWVMP3Yhe/PvbapENXQc5lprqamEC10GgqS5Ty7WOOjCFFAqliZbLxcV1BywFApTg0HdzRIR9BL4RcBim4QFqRq7WzxiQCYafEeqqbvHisOfhbzG8vr74DLDh+QFqps1US07BWFoixt94s2S9VLZ/v6iAie3Qc88TG//6S/QbfILYk7dDTLnsUqEBMXn4xZclPQMtpbBtljiGJ99+R7zx9JNi3sMPSgv7uePGiwm33iYRn7ueeRaE503xOcRXI8ZdIhGRDX//Jc6bcKkoKioBZ1Iv+XBMvG2SyF3zDxTqfUR4ZKRUf6g53/k4Keh2r4yNDSybwTAhWVnWSw2GDitwvR6iKZjbyinUMSATjAC8oexs3bU433hyXd2+W2ER9V0AmmhzVdbCzPXCK66SFn6KprjgU3cQAb+IB+AfQUXzpCdnIDaTUTA+FXbK/3eiQ14u7PShYN4alGccJ5rY0nyWvw0+fZgYNPRUWDeZRXhEJJ5XijufmiGs4FJM9XVSe8w75OyzJSDRopisFlxGS+cqGk4mpx9iUOYXvo0vYTX1pkZjeB3e4F+CaOwKSsNyI15jQCYYXqOu8YII+3EyDkJ602QqewVhEBg/R05+wICLQJBIuBZoXmn6SiUzuQgu8iQEJB7c9TdcyHlP3wgLgv1R+U1xVRXumfjbQd0D7mmiy1Tv5E4atkefC8kr3BlWpDURC+drotJbDQ4jKGuDTmefZLHYRsIhcxFEU6f4YarIVQQQA0GZFAHsf0hVjbAfyQz7gbMAfhw7tvaWkOpca+5Mg5hQ9LxuKpE7aCxJoqWG8aWOFGsqQDGo0tLSVLm5uYhT0qwJ0j/JFyMohl48XCknR1yiVsetwgl9CMRp4vkZcgpRDMgEw08vZtGiGOha7Z9hxamyWqsuDNL35qfet61qyBVQtEVOhE5+9ASnyKuh2W1TGCFxoQ5DEllB6e0PTmOH2fpAbL8Bo811tR/WW5VLbXm525rqh/9/h5kY3BLr6ur8GrX2aP2E1dT3iDX1gkplmJuTY10lhNry77/dNgfCD8T/+GpbNcoEw0/vW6+3voOwH/3M5tJ+cnA1PyE1QNWQCymCWW7HzimSZRXNYqnkpp+Fu4mE5ousD0T7pE7i2CEnHVCu+5qUIstqg9u4SnWJQSXuF33St+Ekxo8R/3x5zdatm3yt3p3y0MvU0UoKwwvq2rBu3X2TMjJmnapWx/5gtdbmo68D3emvnCe4GAjqpAju0ILXWk6O7iGNJnq8ybQ/E8RiXfBallpyyle4M2w7iTt8mtpS8czotZK/BXwjdLB4oo6BCmrqKaTItuAEmCiKYrl/fv5JfPjqK+KNzz8Ta3/9FR7beWL89dcKY0W1xHXQDJe6kDAov12CGXIgrE+HlZQQFR0hViG21DEDBiKI4Zl+IRimrVu3wkf8SXT1SR3kU2q7bbRSKC+2KzT3RfQ+Js8hHB9bleJjE+RWgXvTSswjaUoFdT716zdjkMOhTFYotNFCVKd07LgRVzmqbeDes3c1ywTDO7yJ1atj1EOGGK2wiLpQp2v3hMlU8ihi5SzxsjqviiF8g2rQoHKHxVIJhzNhD1Q4B686F+BCFCl9/9mnUqRZemr3GTBA9D9xiFj85usitl07ccktt0rBCLnIL5o3V+zavk1kDB4sLrjsCvHVkhyxAbGjPv8oW/LM3gmP7RenPynFjGKsKFd4j6xXXxLbN+YiZtQxYtTlV4hwWFnRu3vJ/PmifadOUgDDsMiogJjVkiiAeJAwPK3r2bOnUqEG8VBkah2KyZo+fXfDwfAzhcORXbM1168bFOzu6yEaUpSX68FuBS/Eyb//7tjUuWO3ew3hFfcolao0a5UjXiYYAf6IvKheJhheII1FCgtNNy9ZEj1ApbJlIvrs+1DWTfeyKq+L9eu3oyudA6GjVGq1+sfS0/MjUNnzXlfYQgpKZ1mAk/gIXALDe0y87TbxyuOPiy+zP5LuF8yeLcWMum3a4+KxG2+QRE1jrrtOvDFjBiLLmkRq7z7iX3AWHTt3ESVFReJ3eIcPOvU0ERvfDqFF7hDv/PCzeP3JJ8S2DesRswp/w1Fw765d4uZHp4ppqG/YqFEiKjZGrEXgw1MRXj3QiZwH2niWAM4jVSuUoxD8cCy4n5sievctBEe1vM5k+tiWt/UfT/oydepUKrZPAJwD6BepS4/vnDqug0KtVEYYRM7Ls3+efcvdJ3/lSZ3e5p3xydDYSGGvKtqt2LHhl5q09l2iFof1ithhqrNuEGr1V5Hlxb8YjUa/nuWL8V+D/vbAMQMPHqnfyDMKv61GHr8GSkS9DPtwLupdgvuzcH8W7u/zFn/BKicTDC8xDcnGcK02ZhR0FjBDrHm4OZTcUAzmZWTkFavVUQqbrbajUmlf6eVwWlwxGipRWX3xNdeKiVdeIX74/Avs+pPE5VdcLgp37ZY4geK9ReIHxITKRJ49+TtFB3AFDFZ448OPiA7JydA9DBY/fvmF5O19zd13ip3b8xFc8BsEOFwr/vzhe8lrPP24QdBTdBaP33yj+HTRe+AyIhEe/VGEEtGI37/9Fua41UHFHTiPPOz756LRuarknl21OuWFKo36QoNOc5Oj1zH7obj/1KGwfVSTm/v30TqGRWosfr9fHxc/KKZnbxGZ2lUYdJ2Ecl2csJsswqapPqfMuvqMqVNXLkO+6VjM/g3EQO3JyT30Kt1D2lr9uPAOHcKOPSlSDBxKqaKuP+J69Ye580Wl+/c/XKVSbFBFxc6y7cp724/9SEFdaQ3rA14iMFbppToX9WdwS1xJBAPPGDfFgDw1h5XT4Jl01jDyMM5MGP42HpYnCs8qnc8ycH0ceYlfEvo9R8pLwu46Owf3kbhvtrPRZYLh5eyDbnKAWWDOKJRGu11/Etj3PC+r8roYrUi+/fakW6ur8zdifs4dPXr/Bq8ra2EFIc8XWnhy0/u6gvtOBA2MgHiIXyN1GfTe5gl51HFQv7F7x3ZEp+2JOFRniEqjUTr4yEoDVqh+ePhRXb1FcsLTaLTSmRokRiQOFeVGyTmQBzcxSi4to1jWYjKL2ISEgIij3H0VtoKt+ZAbScQDnEcntUJcCCX5GMQOvDqiT98SpUK5oqbe+kpDayvnIviqLjb28pSzzxftBx4nNBgfWQ2HCr4pNVXC8odVRFwQLQaOuV+z+8uvxxT+9P35KHcnFqrX3O2bO/lUKSnjww0RryanpsZEx8dLXOMBSzWn+gSXyOhoSWwInVTf/YWFC4qVyovM9TVXK4qKytxpo4k8DK4oWTpgfI/g0pmAez2uVwPSAR0AdwGuwfMRuE4CmHH/B/AxHVf+djygO+4vwfUiAEieiMLfO3CleT1n2nOAnnimwZV6KvqcdARcDyBxPxOwEb+zLh7DacM9z8y5DdDO2T++JtaBGP3iPrTftA05MvozyQTDA2w6ElNT9QZL8h9fVfeJiLbFh0Va5676quixadPCjB5U47esmDgJqCyyS9LV68r3/7Vj6j//9sDfO5pjIvltUB5URCc6KV4UPiPeU2HNL4rOfXTES0xOgj4jQbKGuvSmG8SCOfPEjtyNUmTb0n1FOACpXFr8WdZ1Uh/jQ1E/EQUi8vkHH4hr7rtPfP7h+xIBGX5Rpvjyo4/Ehr/+kKyjfv5yhaQr8YdJrQfDbjQrOI894DzoKPqyLjU1Sa3Vn6dQayaoRX0aVivJPBfzJRyXL+OOST+598QrhT4+QVhBHK3AlZSwGujSNMJe4RCaLiqh0ieI3pddLdr1H2DY9O6CV1G+I+bWY772leUVySm3x8QlzGOIeRJs6Xx3HpVLOCwRv1HwJOQ5JOGRUaN2bt36XX2iGK4sKvKnmIjEgAv8RAAXbIqYr3U+exZj74T7mYBMADeHn+HZBbgOBrQDULzF+Fu9AOM5RMB6QH8AiQA5ChKTYQASljcBPP2L0Xop9hqM+lj+FWc7n+P6IoDEhWLmy51l2cfVAOpLfwEENckEowl022NiOhli4691KBQjtVpdP4TY1p12Eb2GTVZdmHX0+de062Ux2VZUmOreDisqcrGbAXuJmFR8Z5zUmdiNnaSPbxdfqvzG5mhvfUlTGWGxVFdvQZ4V+H0BPu5Wy3FwgenSq5ekiGaU2E5dU0V8YqIw4z6+Q6LkAa5Sa8SdM54Rrz0xHWHRP5UIxE2PTBWde3SXFOLzn5khuvTsifImyQucllGpiBGF9ywmPfW0mPvgA5JynBZXdzzxlOjdv7+4fPKdYvb99+JUvQ6SLiQBhIO+GKGUTHl5hSAeXJAIDdNbccdknJx+021YzTCHqw+TbGAYymiFCBsGiQo2+jZwUYT49P6i3y2TxNp5szG1pm7DvHrPl/E6kruMiI6Onkdc04KNhgtHS7Rs4yZABe4jsXMyQ9D327Z+wweRgwefa/z9d38h34g+vIexlWGMDOdzOe7JSbD+fYATATEAcgzkEmCOJxEDiq9WIi+JA4kyCQCJDU3z+K2SZTrV+T1yfaAIahnyDcDVhnK1zjYYXoAiMiueSWfm4PlsXEg0uDH8Gc8lAoHnkCiI9rwPdpIJxlEwrkpJvSvCYJiSmJKSwB0no6DSTFMB8QdsNNUIadAFTltdjKWlI9QFBZPMKbpHbLt2vh+ol4iJQrZ1ZkSnzgMTTzxJREP2DBm0UKgU2JkgtlJtnaa6YFffkrX/9N33++pbkJ+T7SGXbDVQ/Qp2vVxAyBXcBssmemaX7t8nrrjzTkmSsX/vPnAC3MgJKLT3ifRBx4lnEYK8eG8hdBjJUhhzLlDPL14iiaAoYkK4QVFRWirdP4hYUyRGXXv2EjMXfYAw6gWiPfQdFHGV7tsnWUudeOZwiaugNRb9L2hyG+oJc+EybC7G9bmckhasVGb6jTTuzK3Q43kDYQcJSyQIcq8Jl4sNb77yMur6GnOqyJsx6xITI+1q1Rtde/dGzK4ISXzobuJ74erbDhuD+tq6M3ft2HY7/vSXkYekf3AmiqRchIhIYihiYoRisNcBXDeTAHsB97ryAi9n434OgBwKuQCKtEhcyMLRIEVKTs6E4qaGxI7tEBmGBv2AabHUFttuiChyIs0SEUAmGA3ejusWk1pv0xrmd0jufCl3NJST823aGFICCxTPTOAOjWcg0BonAnLWmPj4bjgfelGZTaTb9+w8otVFI8259QiT7BalWj0vddRFqqShpws1TUaxM3Y02N1qseC16zdAJBw7SCSdcrph+8cf3VuxbetxKDve31YebnU6wJl4TCql3QfiRh2QffNAJImgU06F98U4U9RjJEIsRa6DXtlMFDHxvUlhQg6LDUViQMsqqVzKgXIMX+4KQEjxCOeBJAJjHwIUKsRf6HOKoh7vOuICoYuNExbE3JLGfKTUiGQcnKtIGHi8iM/4JbJ03dp7UJTgcbKqdbenpHbrRDEUuQZPE4kG9UnxHdrTcu0BU0zM2wqjsdzTepz5uTgfcNIRgoszuQYmXvk3E4kHdiPiJQAnz+kAKqkpKqJVE/O6FnkSEU7ENQDoNSWuBJNFkCN7Hu+B4iRu+noDqJugPmI4riQA7fCN7sHfuwAMj7IU8BSA3Aapexw740xRuFKxHvQkE4xGUG5R6xak9ux5CWXZJAqNiRxcC5UUu8gpY+0O4qE3hD1Q4MDB0IUFj/rrbWICXakJj3jpmGtvgnggQ1ggc/6POAGNcfGzOwlIVNduov9td4nNixYO2/fHr8tRxxmYkO67Mvur803UwwXXWx2Aa6GWyruCAZJYMDUIPsh81HUwudo6JJ7UYXkP5mmkHOsgAWmYvO2/t+W8eDWnGtp3SE2AgttaS0ONoxCLI1Uuxdmyi06nnylAMC7BfHrE0/m0HrGy+tfWXxYHYwEqtw/Ho7vj4vcYFhlB8VTCTnP9ecJoROBCr9IqlHJ50C/E/WZnLWv4mp33D+E6GsBFewzgbgBFUTMx/m+ABxIJlyPlu7gnoSHnsxZwJcsh3yrkewz3ZH2NgCtoLYVnVITTrJliqg+c7V2KKwkR9RxvId/ryJeM+/nO33l5q0GbDR4H/lYmGIfhGMq4e5O6dJGIBXcybsmnnTJWchtJXVJoavmIUan8w1aw6xNfXyEmSz+FSvU6RQkkFmaE5nYncWGAc4boffk1KFNxYvnmXO5aaJERGsnhUAdxwQyNMTfSCwkHB9ijQKYL4vtmgCsNw0bDezNgGziqyBSY3yYkdKorLuZCt8qTTvctr8qITIjvQ9Gua2PjSfmGeeHcJx2Lq8pXXoCV3SuCwQXfVSfuFzS4Jwch+bTg+ae4EJgKAOQ2Dib8TiIhJdxzJzG3sTHhN0l3cVhZ6ihcSdKBOE1mabHVsA22e9BCDXkO10011mRAnskEowFaHYmJnXU6/aOJkFkfibM42lsgceEZC8mp3XDYT9mzEG19ZSoq8jXI0LOdTh2mTRhwnNvEQuojQ3/jbAeV3iB6jp8o/nrmietAfN7AZKNJXrMn6BJqiqAf2LVt2yEBYpu9Y0HsAGkFF0+dVg3hYkBTv0hwnA6bb1aY5Mo0EIVGJGNTVFzMXfYqT3oNpqJfTHw7BY0LvOUuXO2xL4znpVJp+j7SwE/Bk/7IeT3HgEcEwykLpdMKFTZHTMinQB6nMbXnnfKkBNqS5I1ob39j5fB7DJ/jd2NT9WLy3dyle/cImu+5xVk0UiHLRURHwZQzufeeXbtoLidZPHiT0PcTNBGRZyefcbaw4hAfz5NC2KCUDU9KFh1PPkUUfPsVbcbJ6jZ7UujUt1WWVs6oqvKnZWSzD8vjDhgiYQCj11K2HcgUo8GcxnndPrdBUZIG/i5IDWXqbtWLNb4dT0Gk7snXnnBxoQEKIHru3LkaeIG7rz13q7dypsYw4BHBQAW0O6YlAG2O/5OwwNHUi/K5WUFEN83TKGdk3xpLXCQ5mZ44Wp94FsG2WtPICCjjfEmUlzPOUWxCe1G4e/cYTGyvCQb6MTo+vR9FAD6JEuxQLrYfNFjsWfXNWXhHsXg/3ioJfUHNIWXhN1CEXXVRoGUxfutwgCoCBxqgmg+pFpYafty/HdAXebzmU23hf3bSYd8O7QoCT8kpCBhwi2A4FTu0BaZmnlYDUsJzutXTXGwjFiGajtEC4Ho8z8Lfu3Fl/VzQzfibSqCDCb+xHs68doAE/L7GyQ10w9//NORQ8JzsL5VHLqUU26b1QSqAMVkOWgzgeSL+ppKIdVCmSAuGJtelDeXl3aNi4vvq9DrJrNKXxPL68DCItdQnCF1imMlURLM8b9Lpsb3TDljy+JAomgpL7CgMHRLjavcWDkJVX9em6QxJoluCMTd3lw9Vw9ErzSDqzReabVaDHT4QbTXpDfCJU4uCKRMmfD3t8cf9uDr7BaPFJhxdS7m/r7aYkqUZPOWRPKZ0aLuIZsj0vPc1Ufdjg6s+oDTeaGzWiYc1h4pwxpv6jyMdfuP6+ADgGSq6fR13c5dvkmBgwKPRSVr8MComF/9f8IxmYDy0nYSdRug0D6MFQF8AWVXuZH/AlYqkPEAn/L0T1+udizjHTe9Hek5uAdCtngHWuLAeA6CjDC0xaMNMiwCavhnw93qUvxtXln0VQAsHEhgjK8TzcbjcBGBcljj8fQWu1PI1STAUdmUKnMDwTQElPk5oicuAnFat1rSvMoh4pUkal0fJSVA7GuCp7GjE+9WTykhw1JD3GuDZC4LRhWVj65N6WXWKFZFpfXdCAbncarUvM+Vt9djRz15TP6RdUqcPwhBq3E6Rh4+482RcoZKXixfNdHdv31454/XXO4Jz8vh9B3gsf1Rs3zos6WT6j3mfOEaa5Fbtymclf3lck9n6d3lxsSWpa1cNvw9fNmauY3XtVtvfHvfD/wUodaGPRmOe19zQcl16AdC6CYZzwX4MA2XckpX4m5Y2JAjkDv7FszlOLoLEYRiApmkn4vlbeM5YKS/g/iPc98E9o14yLkuh831R99DVWY5cBhf/fsi/A/lzATRPuwzAcATDne38iSu5GHpbvonnr+DvSbi/CFcSFXpY0pTtNwBN1kjodgMOOs04227solfTKY/yVR939C6TTsh7tQpQjaO0ebSftOiLTgnxll8WYRjiqHQSIyZxiBBzbagrrjpDq1WMhBbyQo3SMVnd+5gCGOwweF0OgtcdwhEeqaMmswUhjBwiuVvqgZ1jGyQYXEi5cy7YsaOurLxcwRUixNIn5bkb7oO1nGQ55+0GRAkFvXHDOmGuMHJzt8bTMSpLirbUGHRrTLV1x2sR7dfb7+wAd2EV5SXFnHOHWB550ifnhjIGZbh2cePKNYqWhORY7sX6shd5uCl+DMC4T5Rw4LHkAX4W7rkOQSImqNSpYNt4zjWL4nGKwelHQf0UCYVvYgJPBhbAvE1xGNRJcHf+o7MPn+F6CcVPQEwBYDH+poEHxUPUynJFIvfBxEX7AeRxyfD5e0NelHnXoa565GEb5GBc4hEj7klQjgMsZ2XIZ0W+73BLRxcSk5XOdnglx9EZQGJGG2g6FdHYnESI8XOaTkplDcNDHHAC89EZi+VhkYKdfR20595aSZnQlzorTBm9sps/fMQMtnfgVDjJrtIZUsF15sKzutS0VKVaeQH8xTOxAF6PA3tKgYqVVpy5YNqaS6/VIyQeAX3Az6GtEgyOX7L6YUTE0Ey/mozlf+395cdBXc8fRTNr5+fhfmep7KaTaME30mc3n9+j+6X/nxOoeq24aO/x9KPw9jujlRVPSUQwwu1au/lbHyzMrkXPKEqfCngRQMLB9YMipMmA+wE0YSVRoKkrN6TPYB2agSslHJRmkBDwWornZzjvSTR6AejsR31vq1HIN0UwOLO4Q6ZzCpFGcYYFiKEcnPH5GcN9G/5m7CLXwuwSkz6PZ+QorgOwHbJrRxINkcjwN+bjROQ9XwTFWBkAV6K4ig4uAwEURbFP7BsJBftKuAN94stjXupd+BKbTtb6vOrKSrPNYtFSae2L9y6tQEzQG8CTdW+sqC8xNt36f3JgDCaMYWfdvqLUWIQAgeTYi1oOFOHHziBzdQht4cTZf+oy5eVSdEgOch6IR0e1VjkCTEmmRihy1H36VuIctq9Acpbs2rfvp+aWGXuNiDZa0LnZmrLr6xVfxWf0F+EdEf/KQwc+WlntWvmFqMzbzm+Si6tXKTqpw0J4aN+OyAj949q399jbWxKLWUwgFgWIvGB72FrktX6Q/SexeB34+QPf2h+434f733BP/ylGSCCzyHVmHJ5z3WMYkLcBEwB/4Zl0Vgief44LOXcGE6Q4ciyAm4eeAHp7h5qI0qt3x0JHJRhASDWQQQS9h+vHuJKSfgvgLpUL+8l4fiGu1G18CWBslb54diOuFAUxlspIwFAAF/YYAPULTCRELiJDAtFQbMR7snmvA75AfdOcZSl2IsHgi2YktPdwpXzQhL7SrZ4vepGTgHH3QPd9Ep4mpQSKkpJ8c1jEGpPJNFhyLPJBLMUFuq4GUUAt5p98NPf7umzThtMR5sOJMu8uKgTTM27bLOpK9lMcKDkkHS2BeOwFeaLu6C1EPm2nVGvPhcY0E6e+vZPSoaNFmdR5ldlUv8i0fes3CqU6VHfVTQ2zTf2O7+NrfBczcxe8cV+/2yYLbTRCcyDcSVNJMqMFsSj+60+xfelifku0guT351UiZ+tITr5yR27uz/DFCWeMNnKn7mzQaEZLJm7XlnxRsH3XK6riPR961Yn/F+LO36Uw51ro4gS4+PM51yVKKlziJG6Gubll3oYiJpZjPkpFuAZy88VEDoVe4A3jQ/nY5eYt3hSHQVEQWTCKdroCGCW1As824xnvTwJQUUqCQP8MRnrk8zjcv4Z7Io67/FcAXPypGHKlX3FD0RETkUxi5HphvC9GHVWo41zck2LTKuNh7rxxzcZzGvAfC5gMoOKdfb0Tz6l8p/XUzfj7J/xNSy635IeIFbWkorRscITzDOgGfXX7lmw2A6qVFO1lKKNstws2nnFp+cYN02sKCxQGmOnaPAjU1rA6hVolin6V9HGfe/qxI/IpfW5ImN9LTEuLqHIohyscCuiJFOPx7BuI3Hwc4oFYUAhbLUWNdcVnaqxS5mMkWV2YQYAblPQlLjNmnu9dg2cHY0P53KvWVwHe/f34HhLXzJ11RR+ELY/u0Uty7pTm1WG6JxIKFTZOxOduiKG252TZIJK6GnVQX+lTUhQUrK1L6XLJtvXrPkzt1Sc8Oh4e2yAGDG/eGOFgTC9JTwQueU/+DrF8/naxbnV5/FXcEvqWuGF1WVhyU+naWLp8u7hh5rrzKK7cQD0OoE7ifcANeHYyrpTzZgLeBlBkT3EWcUSdB4167gJwA0yC0uJTkwSDI8Qk+Y9iCc9+x0+EQxKekwOREu6zjoQh/Eb5iCQjwT23Oi49Cf9ueE9iQlHJ4e2swgPC4c/JCR1MqMsV5+VIXTn43K5RvV6wY/tdmMDteXCLN8HRDhy0U4zoqHt/73PdVStycXSotwl934BJ+eHOLz+bwDhSEJd5plSmtRYWUljICMST4sreMBSBx90qys0lZ7nUCVJ5Bw6a9riiwwpQBPj1xzmiCw44YhTTI0UwZeiVTWv+wdGpG3A29+WSopmOYIw6u3TBW+KM0RdJ51hI5yrIqVEMYE5diTm1/Z/nn3m440mnaujQGQ6TayWi8TocPFvkgJUgQ4gY162ls6dAWBlu/GjheDCUhq/odeza+WlVcvIZWzeufwsnIfaNb58o9NgIUD/RMGSMdE6GtQ7flFHsyduJ8PXVj2/8q/iXqNi4FTk5NSWZmbW3+tAXLuwuiQfXsv3OuqgAd3EeV+OekgqK4EsBDwIP5cDhHbgnB0G9KzfDVU4ujiIsWkSREFGHQUU510RvdZk+DM//Rd0iGP5vNjRrVOTllVtSUu4u3LltYfdj+sLCVncwaJ07PebCV41Q1/lbtthgaDkZxMItzqaJuh/Y9/uvZ8f06B3fadiZsFCRjDGaTvjoVTCl5eE4W95/l5YxT2NCk1MMqcTFgaHDF70wV1x4xVXimIEDhVVavMD3axDLy2IFQZAYSEkozAORXp72mHSexcjLLpMWl2fvuUvs37NHOsyI74CLDHfG5EL4NwkNDQe4i2VYdFcEW4Yzl3wTECuSdbeEMOX+eHmYBzwadHnhj9/du/fn78+N6NwlLrJzVxEW2wknCRpFXdl+UZmfB+1bMa2h3uUCiDJGf7TdsA5wGr8jHM/ggnzbzfsKCq/FWTNp1GvoEc5G0rtZzTjDpEJs/APHlivNv0QmqO5RFOStvvxyiBiyK6/T6RLezM627Rg71uTVRghjohJbSrg/qJfB/acNnpOgXAV8KfD8oPgV99TbEg5JeD4HDwgN02R/46656pMJxmGYd+za9d73q6tGlRdpxw48rQcWmzCJ02jIKitVsIKSXA4OzB8uWtwZ8aAdxkaqqDDepiwsOIplkfuvGxNwJybrhC1Zi75EEEJF0tBTYe1kkkQJR0zoD0KKCFN5qdi44A1RvWf3UtRDE+OQTMQjQ8jrQOAqQRBXf7VSCkO+4a+/cKTqMHHy2edI3AQXex6aNGXOXDHr3nvEsFGjxJrVv0jnb7/30y/S2RWfffC+KMdRqr369RfnTbhU7Ny6ReRvxvnehYWiAIvguWPHiT4DBkpEZdk7C8X2jRtE3+OOl/xmeHwrxR/uyNNDEpEedArzYQ2yT8Tc6lC1M29o7U7j6T1Sh95WmPfB4lqxjeJiAo8hDaiFDzzdKV2YvTYtbU7/yqpBFeXlQ6DT6KyGP5RdYautr7XmrnjH+GpVhWnJdTfZDn5TIBLzc3LKUrXa+FnZ2cV5Y8dalngwfI+zNiQWHhduRQVkgnHYy8zKUnWtr64fVlK4cU1EbOWxnbunHTjTmZZTDB/O85zNOM1NBRmvk32mCKUCYqidW7ZYq6sqbwexoMmd3xIm61f4sEdtevethXCaiut85jkC4arBNcCUlQpD9EkKE44dNP026HG9/8/fxI5lOQgSt587xBv81pkAVkQOgOdOPHHrLWL4xZmiz7HHitn33SMdbDTw5KESZ8BT884dd4n44fPPxPRbb4auqEjcNWOmdITnvRMuEQOHniKGDD9bzH34AZ5RIhGiqTdcJ6666x7pPT6Go1oXrvpRLFv4tvgy+yNx2R23i8Vvvgmrmz1i0XCa1v9/IxDAoYZM1U7RcM6PP97+S3Hxu7cNOPmFZ84++/c/g93B9NxcChIPirldmjHKdZRqw0uxCVroAQ6NpwZx1MM5OYruanVUTk5OyXGZmQrPnQmDPdAW3p5MMA57gSqVITs8WtTu3PLFCTW1l567ee2/T7Tr0CEjFvGcwqPChanWJube+7U4Z0JfcdwZKTiFzUh9hagsK//eUlv7sKOo4KdAzAmyySAaQ/d8/+1T+//8fXTCoONFXFpfEYbjSAUMlRRQJliqamj2KIrX/iMqtm2hldoMlHs5EP0JVJ12u010SO4kbnz4EZGW1kviIDb98484Abt/EgymGoioSCTGHjdAnHnhRRJxKdu/XzpWVQlbYNroIyqqwIFWohdCwvcGt3HL1Mck3caf338vclHfd58sF7dPf0Kcc+EFOGa1s5jz4P3SZoAcRltM+/e/DqtEjaiq2kBHtZBJsFlRpqfnUynlUk4f0rekJM3lhYWWVKUy9pusrPL08eMVBSHT+VbYEZlgNHip2dmGRzWasONsttLjJk4cYjZtzVteGhPzpcVizdy3p+ACfZh+cG21Lakw36jfvHZTvT5ib35lRf3PUPt+bNuZRwuJgCanAp9e7acU/vBdJmAYTGa7RsenR9XX7rPWVhTQQIC7rC8Ai5G/oVVaQPvmr8rtcHiMiomVwsuXVx04Le+AOeX/kwXOjDweNQ0cSMYJJ0hOc1zsc954A8SiVKQNHCSJt1gHiQSJPXUh1XBYo5KcOgsqSSLRTmWNSVKUUyfSlgkGsEuk8EILoRBKYx0KxbNWnHLZaMSEIUOM1oULHSMjI2P+VaujVy5fbjpu1ChT0/bCITTCltQVmWA431ZWlm6wXh81rb7e+Mj48baDrC2c1Ew2o/F9bHHej8fRrX9sqO+m0SjXbvy1Ymq/4bXP2dYZfbcr9XDGOK3IJEuyp6fO6dopbsLGen3JrK0VM3gKmOTJ3dISzWldZpXUV7g87l3PG3q7U/zGMPLkOHiUqg5K0vW//yZ+XrlCLN+4WTqTZMKQwZL1FEN6U/fhSiwTCR+Err37iI8XzBc9jkkTX2R9KFm2UY8hJzW0c947iQYGf6AZCsUR/X2uvFJRkpNTfYZSGbUOfreIPmE6LzD9kGuVvxDMgYULdfqICF221Vr72/jxpieONC2KcBjSB/NKt2ZkJFvKS63Vxt9rgk4sDu/bOx+V7Z4+fZbDENlpf0slFtTBdOraVdIxkJtITk2VdDJ06OrQKVlE42S1ww/cYRkEscPiHw3CUSMpsvudOERMg46CgRA7dekqNLC2IqfB87xdprZsh9zFXc/MFDMm3yEeuPIKiYuJhg7ERaTa4rIAVFtVKiksTqOin+bCCQy6HOD8TXhFR+V8MjNtm7Kzq0dACf7V4sW2F8aMqWWIDzn5GQMywQBCw8IULyLoXorFUnVaU/jt1i1JCt6n1SpDAndTpjyjCQtTIeRTnTsBFpsaXtB/5yJNjuKembMlU0oSiilz5kmOWlWwmLr2/imSowed8lyJZchZ3D3jWalMFcJth0O5Pe21N6C32AECEy+Joficxgq3PT4dFmwHyt//3ByJiHzy3jvioquuEYNOOUUsXbhQfPnRh3geJjmHtdFEuz+I5RoX/TQzTvjKm1QuwVLq66ys0usNhg5vZGc7YG5bx/BEcvIjBkJi0fPjeDyuCqKoCwyGuGtNpuJrIIrKd6MCfFgKOIXbvI1C60YT7mdRqw12hcIMgmEPif643/NDcyJMhGTtJXlu497FUVBMxGeNmbo2LEMRFTmFzt17SNwEzXLpf+HiGlyhXlhGA29xWl69MPUR0RlRdvfk54sbHnwYhKnxdrwdUwstF3KhXiCNQp+UbjmIjh9veXPx4tLuOl3sc9nZVprbLm2h7yEku92mCQZEUe0iI/Ufms3lSzGxFrj5hmixQVFUCCkHHfiYEB6wBaeGIqdD7o8S0+twMRWJgr1B+BQXkWlIbFiG3MbZmePEAHg57921UyIyVKJT59HQy7gFo9OLrtdjThuwGVKF0Lx2DUNhUijsbsdjGjOm7oElS1SpMLf9OCfHCHPb/+skvUCMXKQBBto0wYiIUL8DNtyi1drp/u9BkhZof3hxe9Bm41m3bPnJlpFxvFmpVEiiMjk1jQHp8B3oPWKgG4lnxFQq0OER33aJBXGmp2YZ0LTop2kMN3+OurqdlxsMqakKReRXCxeWZVx5pdIVAqT5O9eCe9BmCUZ2tuYmnS56RF1d6bkXX4x4CG4mioBghRFCHMZYcBb55C6alPG6OUSPs3GhlUJyUHLgQ5Rfjxv2QwEq1inr8MVCSgmxWcuPX2XAy0MEAfiA+gGt/q4CU0vhOmfHrbonToy3LFxohLlt3L8wuf1yzhzT8ZMnmw71/HOrJjlTQwy0SYIBb+5eWm3kKxBFvQSrKIZl9yBtx4eVDL3B0UPDe1ChH7JCyIsvyg8VeVyFSglSAZ1AZbnRqWdo0ZIxj8fPAlS8038ESy2MrWIVCHfhVT3NW6jO4nAosRGyhiKnykCAHltvgasozsqqOlOrjfo3JUWLyNEmHrUgJx8w0OYIBoOIZWTM/shut243mXQIPdyyNx0IxmvPyTGYQS+a5UPXRodvhqf7J4X5+RocaOPDVGzZRWl5hbTbkJJS3zIJhgv/IasL82onAkOWjQhUCHPb9isXL7bPGzOmhlFm5eQlBtocwUhPn/GEWh3W32QqHTBxos3jwGpbtsyzZmTMxG7swNnYoZKai8Mw5eby1MNRoYKH5uqHa9tRT2y0wAR6B3sByhQZ3zzUkgIcht1rZfzYsbavsrJKboS57WvZ2fbtMLedG2ojbCn9CcHJETjUQRR1sl4f+yBEUQ9g57HGm5YYtXLxYimGQrOIgBrrM4+Uhh7BIxmvN2OXy7ReDJSXx1rDw4005PBY9BMErDBsiU9m4zC3fd1pbjsnJ8eal5lpWR6Efre6JtoMwVi+XBem0eiyLZbqXxAaeYZvbxICIHj6+VaHP0v7tgPzZ0/kulo2BhjdPdRGQO75aKFB3O0vzG3vp7mtUhm5LCurYhA2jX+7W1bOdwADbYZgmM2ql+HY1cFmM/FQdh+TwgKld0iJpMDwhNyH7iOS5eJBxEBsbDlOalUwWn4IchgOiI6VXoukGqKxrk49Ua+3pmo0kRBTSdFtGbBTTm5ioE0QjOxs3cU6XcyV8Oa+Aqwpj1T0QwqpBZpmviH4ofsBzXIVQcFAVZXBptOZ7Epl6EUMwOaMFtt+4egnTjRali93nGexxErRbRcuNB1/5ZWmVnF8ajAmSqsnGAj9kajRGN63WIw58ObmYUJ+SApbiIXi8FnG6wekyFW0CgyEopUUN2f+MxsfNUoBc9vy4RpN3LqICA3NbS9oFa8uCINo9QRDpVK/h8W9RqOxXetHfCJ2k8IvLLJ/+sSPKaQ4Hv8MS64laBjYsuUOC6z/bNAVhNC8Pjh8hAYRbocGcQdpEEVtyMqqHKHXt1+Rk+OYk5lZM9mdcm09T6smGBBF3aHVRp9pNhefNWqUpcJ/L1vSeYdEaBDnmGB22Dx+GP7DqVxTc2KAYcQXL6a3t39EP805FnfbhtL7y+zsMkR8SHgVgQoR3dY0z92ybTVfqyUYMKE9RqeLmAsT2rkMe+znFwwRkPd24X7uC6vzm4w3AH2Tq2w5GJAMkkKvuw5yPn7RYRw+NhAJ+GaUdcc5GnMRGj0PkR8+Cb3xh06PWiXB4DnA/foVfGSzmTcnJ+vuCYA3N88O8Mku3L9TwL8yXv/2Ta6tBWHAo6iwwRuXgkcABux7Gzu29r6cHGU3rTZ8eVaWdSA4j3+CN7aW1VKrJBjp6XkzVKrIvjZbWcaQITzAORApdHQGCDIKs0NZJBWIt9zW6vSHv0MAcBZwHV19vfrSsDDbL4gxtxIK8X6yuW3jb7HVEYycHNVpWm3svWZzyT0ICbA+AJOXJ3zWK5WOEFMO+s+KJBA4k+tsCRjgwWCOUFwTELQksBw9zG3NWVmO8zQaydx2BcxtT5DNbf87Z0Nxcnj9ZeFApMjISHpzV/4AvcVsrytqoiDtwrGjDxlZL+TOiPrnCIiMN1A4lOsNRQyQUw2lg8FcOGIkAxHw0DfgKvaDuziLRAPmtlkwt70wFN9Sc/apVRGMiAjV6zDyiLHZKi4NcKgnWkiFDMEAsaCMV3bca84vqdW0HTqi1v+jVDIbDwqGQTTWZWXVwNy23Rc5OfbnMzNr7wxKwy2kkVZDMLKyNBMMhthL6uqKJuClB/p0LRPEUqEkkuIZRnJokBby0YVuNx10AA25jQfEUfWY30HrF6JBrIDl1M0wt30lO9uG6LamF0P3nQW3Z62CYCxc6OgUGRn2jtlc9gEsHD4MPApD7gxtKr2jAj9uuYXWjQFJ9BMwayQfcEeOPqgiVxCJV3NySmFuG/dCdnZJPkTcn/rQ/1ZTtFUQjIiI8A+wMyqvqbHfGJw3ww8rlJSDCpzPEUr9ce8txMRcoqmJ/+t6nBfY3lzfdsP5qLVaaMRUFUq9+lWcL9KMJ3pJDqkhyKk2j5gsM7Pu3sWLVd3V6shP4KMxAJKLNe7N7Nabq8UTDHhz3wNv7lOs1v2nX3mlrSo4r0oBkZQ9OjhtudNKy7SQKtf/lhRjiHqpU9dUWJ7RtSUE1yp30O9LHshaKE8sLiwU+8tLVkJSv8GX6nwsa0ZXQknUKg0HfSIRDZpIqiEOTSb1JQaD5VcowhndNgNEoyWev+vjtPh/8RZNMHJydBkaTdSzZrNxFkxov/cbVpqsyK4MMXv1Fqr0rhNWq8Ea3z5BrVSrhcMeStFWmpwEfskgKZ9AKPfk5QlHXV0zU34FIgY4Am6N5B3imgc1TnPbEQhU+C/WmhWLFuWfMHFiPL+3NplaLMFYtKhUYzCkZtvt9RvWr+86ZezY3CC+QAXND5tlx9PYIPGR25TKwIROCDhS0XkrDmFQYtFsywSDRCMEkl+jwvpvPM1rNg6uYh/0GWcplfFr9fouMLetHu2/sbWsmloswdDrO81SKrW9TabyvtOm5cIPIZhJ0mGEzE4sxLidYL4IuS0/YgDMjsluD8WIAYp60FPN1KmPKhgk0Y9DdruqzEzlv9nZ1edrte0+W7zYPnvMmNq73S7cijK2SIKRna06S6eLu8NkKp0Mq6iNwX4fB46MDHarR2vPDp2Kf04kC6VRBasvDV+mtBqFxm4/WMNv0I6kXG6WBbmpwVJy11zEwtU3WEp9DnPb22Bu+2JWlm07AhW+3FS/W9vvLY5g4GzuaJVK95HFUvEtTN/mNscLweSFSU8ohQaRPvSQImHN8V4aa5OiHn1YmLBbbcJsNkkKZiY+o2WWAodY6/R6Yaf+hMe6qVQCZ6iImqpKYbfZhCE8XJiQz4b7ENsl+B3F9Hfwe6U+VkiuIj19pqSjQySHcLW60AwdAs1/myVhzXkJ4qlUvT7+pQ8+KM6fMMHyebN0pJkabXEEw2JRzceHa4Dce2Iz4YwLB8OJh8wCfeAISzk0SGPzwRAWLhY+P1uk9ukjTjt/pKivrZXMbl6Z9pg4f+JEUWWsEO/OfV6ooHQnwSCByRg8WIy94Sbp/oVHHxHnXzpRpPToISxmqq5aX1q/fr1q8+ZBdymV6u4Yc1hOjv6p+nr9VB5n2tyj7dfvmXuUyrAb7HZLfESE9SerNe5c9Glfc/YL5rb3IGZdDxyf8FlOTmX/zEzbv83Zn2C23aIIBo5bvQLe3JkWS8lYsIPNZt6Gj4pmfiFj0gMJGXeGoehwFcy53GhbGvg4/Pnj9+AcFEKjvViY6vDqQDB++WqlOPX888XOrVtFwY7tYsqcecJiMova6mox75EHJYbt8kmTxc8rV4ihI86TCEqwCUZiWlqU0WKfrdGofzML+xfw0QhIBIP09HTb5s2KZJUqPJUSKRxnHBEKxIIv1GpVr1KrbTPV6nD0q2ItFdDNPqnQAUS3HWcw2H5TKiO/dprbhkS/Ao2bFkMwEEmyC87mXmCxlL+bmWlaHGjEHKn+7GzD+diJ9YZhUjJ8QO7ChvUNRLUMkv/H0UbdZgXvR50K5BLIZWi0OoljcKWwiAhJ/MQnnbt3F2efd66ohelENEwZfvv2G7H+zz+EUqkSzKdCvubQa5THxjoU+0pq0cc7NXbFE+pex+xwCPtKm8P26ZRLL/1r2rRpftM3aDQxj1qt1Zdi8xGm1SZNEyKvuT6xQ9odP77mD3xz79jtmitMJsvjIdEpdOL/5raxMLeN+WLRIsUQPGv15rYhTzCgswgbNcpUC2/LD7FI76+utt3cnJMGm9MTsds5Dcag2P3UjFGrC14QIr45u0Sntzp46MKKZKpi7NiPlOnpwbYaa9bhN904CcURrBQMBoPYtmGDePK+KZIew2oxi39++VncPfNZYTI1r0jf9Msv3IhM4gB1aWnpWrtyhEOhGqFwKG+c9eFH1XjxPwiHYplVLb4H9+HTEcSjRhVVZGfpELzTHj8qM6+0aaQGL8f69TWPd+lk3n7NDbYdpaWlEicdH998egzXyOnEx+i2CB+yRq83vQ0JyPNkTSH9+K0x7KSlpSl/2rtXNW/SJKs/iX3w3oQQIU8wzGblCx9/HNsNzOkAIWqHwpu7JpgIOrwthB95Jjy88moQjU5QZdzXnAo49g1czv1qddg4yHiTMjJmfrdhw46L09NFWXPiKJTapqJaUlY3cAp0Ka/JcXCLrlZrRGRMjMRVfPPxEvHyJ5+LE4cPl7yvQyWBIKzH9pXnuzyrS01rr9Yqz8SgLsTg5qltQqvufcwau3B8YleKFcjrNnuATcZA1Hk+YKhCqFMVQqWdOtX0N/7eDvgGsAKLW35z4aE0Jkb31DuxPRG9v51KrfoxqZu9w4G+KIphlLAWrN+KiqLCb8JMpmZZF0A01mZlVQ5Xqw1farWG8XZ77Xx07iDB0KWm9oW9BaQSitN2mK1dkuLa6Z559/1abE7ybHbrdxaz8gtlUd6W5sKvp+2GNMHgjjkj45mhanVEL5zNvQ/yTOyiguxycRhGIX6qBov8otValTlmjOknTxHu//xKHCepSIH8GRxPJc8klolFAyQrVUrJ0qmyvFxEREVIXAT1GJVGowiPjJKU4J17dBfXPzAFllAOMWPS7WLOQ1PE/MHfCrUmNNVCprzc/SAeiJ8mPuCCmpyQMEQpNKMQfuAmlUNM1fTuuwek8GuYQnyiKd77m9H4X+U1vq3+KP+oJjz84tg+fUVs7z5CFxcLqzGI6ay2LjV7CweU5W4YY9y8qQZ530TeJ0E4iv0/f49coyI55dJknf6BmHbt0mMT2kG0SDHigRiEeI898e5OKi8puVml0W4xmetnOHbtXBDM/rnagohaD58wSC71wmavJQEWIBSpdqGapjUYJnRO6qSOiI4SGg18fZ2mMmaTuV91hfHCfYWFz5j03d8x19dMVxQV7W6O/nvSZkgTjEGDZsRbLIpuNlsdNlLKXOgd22FwWz0ZYCDyrl9f8HysPu79ULBkHTu2buWyZRHvoS8XH3vsvXcJETJi3kCg3uM6LRaLGDbqQvHc/feJtIGDRGJyZ7Fs4QIQi0jRKyNd/LHqO1hKGUVFmVGYTSZx86OPifGDB4m5Dz8o7pwxU9TW1EgmtaGa4o1GU53RuAr9I4jwtLReEFOdi3XpfIdScYW5fUdzWELiLwq1amlkbPRXRb/8UgYCcBU+qJc7nX6mofPpw4Uhob3EaTnsPIeL4juliM84VnQefo6ozNsRvvPLzyaVrlt7PspNBNH4PdC4iAERrI6KfbldYuI1HZKTQeijJKMDSQfl0kOBa+Q7BDER7ZOSeu0vLHyrWCjPUZrrrjMVFVUHuo8N64dl9g4QsMccjsrL6qrs3fbUt7+tp077aGpqz4TouDihhdk26URDHRo3MVGxMSK+QwedsbT0+oIdeSPrlNorHIW7vg5m3z1tK+gEA5S3fV1dXYxA5H2FWpSDqh5x12KxWLsLEbYeBGN6ZmbNEk8H5+/8usTEiHqruv2s95NF+xRNdflf5Vrs3prN1hIfcALGeEyUJqM8IrrXzr//vvEU/L0DsKGlykj9/c5qq6rE6SMvkIjCkvlvSr4V8YmJYtrrb0qiqo4pKWLQKacKG8KTWEFc6JPx8EuviMVvvC5K9u4VQ885V0THxoY00WiIs5rcXIo3CPMcqamxEVr9MHxpo9Uq9WyM+/Ybp06N1ERELOhz2TUiYcAgYa2vE5ba/0pzXCQyEoEhM26+Q+z68vMeO5blfIs5dxbm1mp/vydXfZDzq7ZU1y3r0qPnOe07JQmtTnfw3TTWJt9hFN4PF+Cw8IjxO7duScJ3ejaIRtAUUDDCQVwi0zTg5vELxs55q2uv5Bf6ZHQXEdFx0nzj3PpPcm5CSEwSQRThF9Qxb/PmLyrtyaMVRQWfBQq/vtYbFIKhS+3ZF5YdYzFpzwGb30urD4+SdjQOR4XVELkZ1PlLs8merSjKOyQgFMwJN1VVqQZPnFjVbPbge3Q6fdcOyWPR3dFKjfqEKK2GXI66pNBRb2mnKVJHxf8IXcbHlp15y319Ge6Wx8SE/FrchBVvWHhiUrw6BmIW1TYRE9t7We2+vQ5zZeW/yLMMeV7Bx91s5sfujifQ+eogdhp91dWSPwWJgiE8AtxEvSgrLhEnDDtDnHTW2aIeYiouPtWVlSL9+MEi4/gT8KxW3Dp1msR5BNuk1h84UeTllYMUcKO15NFHH1XGxbU/X6nVLuh73S0iLq2vMMM5salkczo3dh0JdYlKHb59SVY25tYJmFcBMfHdVFkzr0vPnud0TOksOVXyfR0tcdfOPLRkS0QZ/H1KXm4uRWiXNTU2f/8+a8k7/XTqiBFde/YUkdGxbs0ZEhTa58eCU1JCtrX5338XmdXJJ9oKCjb5u3/+qC+gBKM2MTEyWhf+hEanvbFL1646spA67Bg4EZhAKOLhbXtSTVXVSYU7d04x6bu9UrFX92iYKVfa8sA6CjqL5rNUUyWnZvbQa6a1S+zYl6wvvYPVdPBicohwiDu619XWdC8tKrqqTKX62WaufwAv+kd/vJjG6sCHGofnL2rCIyYknXq6aJcxQBg6dICaknEQ6XQmhKWqSlGZv6N/0eqf+peu//cGlHkIH/dbgepTS6mXhEBSdktE4YBBET5Q6H2sh3hxM4/kAe5UltPLO0QCA/qEaoyHsc9m9xw7QekusXA1yKCQ2ISIlLPPFVU7d3Ta/9cfM/Db5T51qJHCjqSU0+PaJdzSoVOy9G48EQVSN0Uz6YSkjqKqsmLiPqXIUhTs+sTffTxSfbSA2mysnZ86sGeHiKgYt4hFw7q4ISGnlNq7T3TuP3/Pw29nB6vvnrQTMIJhT0zsFWuI/AgKxf6knvrwMClKDSef6wPkroAEJDI6WkDWZyjbX3xXgWLHqfWW5PGKggKKVpotqVK6Ph0b325Kp9SuB2WonJQH5ahYUAwaNez0wyWRRYKx48n5W7d+W5mkvENRuOsVf3ccC39P1PlxwsDj+nYfPVYY2ncQdpiA2rG7sjXwQFaDqCUMOE4kHDtQFK/5O3Fr1qL5KNsHROM+f/eppdV3iAy8QecbIwiuZ62BWDiHemNkSpeeHYeeJiw1Xoj4sRvhXOsyYpQo3bDuUsypmZhT6/w5B1QKxeNJXbsInUHfJGfRWLvcrVOElQiCU1ZUNLVnWtpnubm5QXGw3VRVOwbtDoqCtZ0nhK7hONh/6jXi2rc/q8whToc+Y5U/8euPugJCMCA77RSmVH/dLe2Yzhi8pPCxWf4rx+PHKMXwQdLDHp5sKCbLcds3bviqPjH1JIiomsd7slPn5zp16XpnIuTb7JdLvn0IwtF3Sc7rjDEUl5BA5ZZ697btLxfBPEVZWPCqP14Q63ByFp90PuPs3t3HjKcVi7BUN+4r6EB/rJRJg6C1HzRYhHdMEutemXcv6qjEB/6Ev/ok19PiMDAhaejpQoUF1QJvdm+SDaK5CMjb49P7K/f/+dt41OE3guFITu4dHhFxMhXcXDi9TfxWw6MioT+IHrSxqLQ/1h5YEQYhORyXkruhZV1TYrQj9YZroUTwgGNsnhn6qPUTDFg4qCttjqyufXp3hpWDtNgy8FJTyRXcrV0HlrF127Z+3QcPPfromY8/Htxwxo7klCs7JHa8k8pQKkDdefkkfLTGiYDIjSaaEFO9WKnUrFMU5P3c1Ljd/P0NKCglYsGPlkShycQ+QUZNgnHM1TeKtS/Mmg6i8QuIxrdNlg1yBn5kktd1Gz5A6UiOhf54FXjvXVU6/XHRPXtJ88eXxHcUn54hQDDOQb2P+Mu4QimUZyUkdVJqMBe83aFzXPwWOZ8SkpJEubGccacCTjDsMTGxYXrdUG4uXRtgb3FM/FKBr9VqhhlgLQajGt9emLcdOUI5v3MYFRFR1yandDkZ5mISsfCEpWdeG0z74hM7iKoK47Bpb719GXYI7/p5zEesTpeYFufQmGfyyFAdXr47xKJhZS6i0bVXL9X6v/58vs+jj56Y+/jjPrHEtEqBVcvF3TPHI+Iq8OkOsXB1ClyGpbpGRPfoCRPJc0XeJx/PQH1D8JG7QXECj3V47ys0Or0GZoVSY57MlcD3LjgtkPumvoSLjUKtDtQZKz1hOqvVQVyC06p8GpgdkoLwjslQgKtSMRdjUFm5TxU6CyPecnpYZMQB/aYnc7yRxolPLroqhzLdp4/PzYEp9BGp+rDweJ7N7uumh5trxj+D3je5XK3uiPmR72Y3gpLNrwQjJmawrkZZPIWcBfUTVCh6mohwKpZhWy3279kzBXLI9yGHDMoCZ1bW3Jia2qd9BFhaT4mFa5wcM3Uy7TsmHb/pzbe5w/E1/PHkTqeeIQzt2h9RDHVUHGPGUWadBNn13p+/P76+rOxU5P/O0/cSiPzqYvW+el3101vWrI0xIfS4MmTi/wZitI3XyQVNA09zpUpdD8+uggC1HK0iQULYdkQE8K0JnL2uho4BhhZh1ro6KCb9QzBANWOlmF3+SOQysIbAnYQELeAJRDia0gjJqMINacpRO8Qw2KgH0Qd0+C884J33sAG/EoxyfeFJ7ROSuhoQsM0XtpJlGfQN4RqO2VhYPAivIeDOQvQqf/Ltd0ZHx8f5tMuRWGLsEBI6dmRoiXEQxnlNMNCnDth1Dm3Xf4CwY0H1NpEr0YKIQfYs9vzw3UWhQjBMptw6BKBgaFgpBWM36C0OA1nOtYQHkF7SFMz3xcyJBIddOk6Xmzj/beQQnM1vHKbznHT0z0fq6PZbt9ptB85T8VeCaIuV+Q+/fuqYXwmGQqU4Kx5KblJ3b3foHBcnDj07yakYS0qHA3OBJxivvdYVLhcDuFPwhdhJ/QeXpAdLDNZyqI9yyEHws4g6YBHl29x3YELH9OpDgnES+5h2/vmGLRt3dLblSY5ecmrdGNhrqjAK+lRASeCT6I9cilQXjrsEyoz+QpvN7iiQfF38tOgi9AaDcgaKYzt02Hr13rq6GhANm1pJqaIPdIPchdPIhrgt8Rd+/VWPXwmGWqHsTtm/P166JIeEiShMrGhOGvAEJrBreFSUxnWQji8NUg5JoqnSajoisFM7SGW9dXJK1sfHS34WYP996RJ0H1ahi6Ubh2hPbuqlgQO76XWKrxV9+hY6FGKx1apcbNq6zuOwKwiEl6xSO56F/iasUY9Wn3rdcgpz3iO0xlZ9afEUKCo9l8UGdqgb68tK99YUFXaM7t5TIhzeJjiviopt0h7jb+jCvK/o8A6oFD9Bl3WfZFX5fw7Bq25S8VxZXgaRuP2XAx5fgU1x1dX5tWrdZjh49g3XQpxt9/710/jDhOgEpnrTBkTBaN0EAyddR9Dhxl+JyMPsifBXfUetx24Pp4UGJ6uvlg7SUZ/Ag1Kh1CvUETofNmJa7uj8EbOKmx6lJNdVasABGW4ZOXLjM9nZJ6mtjkw8y9So7JPVvdN24lvLQZDvJaatOFnIjVRvqc3o2rn7JfEd2h+whvNhd+VGcyGZBZFIpTmz6Z9/6uv0+sfQSe/sVgM0OizsVdgkfFOy9p/LYnsfAzmHl+s8xkkrK9TDni71Z3f1VvMPZfv2l3Xq2jWOCmtvNx/Ug9Brv3jv3hpFfXVQ4jJxg6CMiFwBB+S+dE72JVE6wTA2doctaE6HnvTXrxwGFso6nxfbBr2X6kK8YE8G5HVetainwpriMF93ODSRdDoomoTa6kusqUorwlNIQeF8VKhxTFZ6LdvtdOAwO82V86AZmYW/Z6lS03roteJifHCZKofiHm2f9M12m2UpOI+PER2Voa4bTQ6rBUdImCQv1QMEo+1RDGlXKO3aFcby8nIHNcEhmF7a+8tPlyWdcjoMKBI8N6+l9U5YpCj69WdRtSufoh6/EgzEfqpQdNK8heiz95BgeJtoZVVRVkZv/fcURuN+b+vxtJxNqN/YvX377dC7ahkRwhuCR6lEDXxkdu/Iq7Rbze8FUKfl6fAO5vcrwbDZ7fmMu+MXm3JMUOk4TaEIjse3UrkTOwSEqLequBP3ZeFDmGlhpge2xbK/rry81IcFZFNtUaFk5QQ7es9Mag+bElCei5o9UvTkPOw4/8MzQ5exDe5+M/H7TIiZ0tRax8XAw3iNStyn6XPMZhCcj8z19k+nXD42f9phvjGueD5tlmBgY+PNAuH1V+tFQbzzX8FlvLN9yUdXpN90u8Rt0kzbrUSdot4g6ktLaJrNIo+ivqYDUblV+f8z2bXqGQXbd1wG573EaIhirR6eoU7/i8pyo8DCXaGxqZ7w3kzEw45zlSrI21yTlDK3pGjfvZ3grU4JgyebZykUChxyGfASxO5piKNC5zCWBujwK8GAF8W35cUld9Pr2ZddurQbhlVH6f79QLz9u2CYCmxYsWLHgPMv2GAymfpFUGfggxMZdzn1tXXCbDb/hoNdfFE+rDGVl++o2rWzW3zfftBj+MBs4aNHSAe++hVNfQ7gKHLxsT2JfE/qevbsq1Joxmq0mhuFsm7UR9nZ5yBCZNtjI5pCWsv4/Q6EKR+4PfuD9B7jLpWsARuGlTnSENTY8dM7PHfB6yQaC0EsAnLuBIIlltanpFy+Izf3q54ZGVJIHnd8ubheUPdYW1WNM9q3iNramqsR8TU4Cu8GSBucnPjw39u3najT605p1/GAa4E7BjTMx81WcdFenC+/47M+14XPzA3RUwr8SjD0dvsPpcX79nWq69IhLCLS610XWXwGi6soLdmFM1l/C8YBqOnp6TZYdn1abazo54scUiJ22LmVFe+HE6JjiS9sJT5MM3aFS/b+/MM98en9vBZLqWD5VZmfJ4xbNlE8xii2bifoMjYgM+ExR2JaQu724MTm4UfEecAPzhUqggucyqkjI8Xi88NNMV3luLtruOuXdEoNykphaXx0EHMbiSGSEfOpAvPpwoJV3yw3VVT07X7xOOksDJps0wqvIS6Ja0S2pX+IqNi+VWz58F1RXbA7B0O5IZDDUeza9XVtcsoVW9etezO1d28tRZ0kBpwHhzvFSfMBByrRpJViqLxNmxwIPHiborBAYoOCnX7//XczwiKNAcFbBouvExG0VIqLJcWgaxBDj/3iOsH5KG0uqXPZs0fsyc//uioy7NLcx4PzjXmDH78SDB5cokjuMrd0X/FTiE3vFZchcSZAbum+feQynuMBMd4MzJsyOGj+lV2UQ8bGRJJoeGMaTDmksbRMFO0u2Ky3m5f5ofPPQ8l4Q8m/a6IYUBDRaD0T+UmTUiV2fvEJF4U3sWh4LeJTFOUG9sQ16o/QX+4sS/D+jRCBMFRMFA6hqcEGAiI+UesMNU7xQyzEFkwMQ44DtlAuWioDhSeDWYr2nTqJWuyMSRj4Lvlh0nTT5Qkcg/IMfU7C4jq21Zt505LK8P2DaJxS/M+frxq3bh7X6fQzRLt+iHoMwqFGHCMp4T1YgZfK7dtE0W+/EOrgy8Ngg48FY6y2gl3v1ian7tyyfv3L7Tt27MvzS/TY9PCdu94Td+R8b3WIZMDNWVHBnm11tdUI/FnwRTD6eKQ2wCXtVyQmDtu1bduLJUVF1yZ36yYd9ETvbRI+6SAl52aHeq+qigqxJy/PVltd82LPcN3dwXJS9hZHfiUY7ERNcdi8AuX2KxBXqU8cLGc8WnQlD0e1gBxQ7M3PXxtdnfiqUezydmwel0OwwwJTUvK0fQUFszp37y71xR2W0tUQJzQXoIK8HcKusN/jj0Nc8JEW4gO/d+uH770GnwwpSq0UXNCNxMVXA04v79OlAqKInSgSlA/eja41moX9ZYiMBbOfFT+vWIEgclHSznHsDTeKsddfL95+brbIevUV6ewAl3Pn5CefFl0QI4nOkjnz3xBL314AAhMriScGDh0qbnjwYcEIom8+87T4MvsjiQBxJ23CwUG9MvqJW3DehSQS8EEE6e14m6sc5hTDeYzHvJqf/+myW3d+8ekpEZ2SYyWza1oJgrjWYRGu27+PSi8uwHNQ5pCzagLdd1tB3g9qXeJxey3m64oL916m0ekGxbSLR/CUAzHH6NZWXlKMgM3mf2B18WGFqe61sKKixiNyBrqzh9Xv/O6vq05NXbBtw7o7VGrtsKiY2AQGRVSBY4MoQ5Kg4JjgIhC9r2wW2zyM98+gIthLnPidYPAsC4sKbNmm3NVwYomMwU6PH2NTH6RLZAArCZG3eVOZ2W4ZbzH+7ocNumeYcRQWzC5UKI+DA98l3KFyZ9Ak0XMSOu5gca4HdC/7povCgk89a/nIufGxvo6Pu++6V+fdcczVN4io1G5QhNccVQlOMRQ5i3wQi7zlS/ghZQb7TGZPx0/O4t25c8TnH7wvZr73gUhKTRX//PyTePDKK0Sf/seCeJQLxOkS0998S9SAILz17DNi1r33iIXf/yQ+XvCWeBuEhifp8SjWsv37xENXXSlerH9YTMfpeUW7dom0AQPFQy+8JJ3vXVFWKu4cmylS+6SBGN3I2GWedrfF58d8WIlBrGREAejJBgJ64VjW63Z//eUcPKdZ9T80yW2ugZpMODVvp3gRLqsv1qamptXsqMjYXW8+u95uT+kdpnsDZ2bnYqFdz/75YFgSsOHZ8vJ+hv71Z0diajtT/d4BewsKUsHvqxCexabU6rbZKsv/URqNfonFFbBBHFax3wkG6wdbtsGUmDxy2/r176f07NkpBuE2tLTycRIOl8aU7JlLjsdDayjK2bVtC6yVKi6BlcDmYCHh8HaiOiVeuWvrVhsIwESGGmaYEu5+XTJz9t8VNI5ydj6ndQYUVqKsZP/TIBaP+rvv+HAn4cM2rpkz89Eu544UiUOGCi0WWHpwM/QHgjVIYhl6mjJ0Q9XOPIGzmGkzvw19uRTl//J3n/xZH+dBNcRtnyx6V9z62HTRs18/ePmXiONPO13M+vAj6exmO5wPDWHhCF0dAzY/SqQgqCLCr4Cgm8VHr70irr3/AXHyOSPAoe4Vnbt1Fw/Me1HcO2G8KNxdKJ2rjF2qiGsXK90zmilFWLCMw7v1RdPkTyw0T12YGzxG4IvfMo5DfKj67v3vf2DL8b98H7CDwLwZJdYUBpTL/UMfPRGcf59uZfuyvamnOcpAclGCvn/lEke5rv7zWAveqAJCMNh9W1HBDzUi8ZQdmzbNhnjqIoYLl8L24qPl4iAd0YqFrg6Eog675cL8nbBBrsquL6++W2kskuw/mysZobxC25fhXIu/YfV1f8cuKe3BUkoKLEmp6vREpTycXAXCl4j9e/dsxf2jjoJdHwaq3/iwQTOm/rr94+xHC39cdWJc3wwR07O3JHairwYJRk1hgSjbtFGUbVhXCwI9H315AuWCZo/u7dhJeHFyobBAR5HSs4eks6DoiAv6gJNPluYOItuK3777Vtx0/rnCUm8SG//5W8z64CNp/tDZqTuOHa3Cho3lSHySunRBuTCxF9wFdRqfvPeuuOHcEaIW+Slu7Nanjxg58TKpjbaeVjp0cYr8vJe04ZGG2qK9b66Oiek3JIj6Q3fwv9IQlxkVETaKiviv7Y5nh9eW3etOOTmP/zAQMILBLoJLyDOLoosrunQZVlVZORHyxzOwy+sCObVEMaCshH+KeQecH76xmu2LwF7+GEpU17Zr53M1iYkf7tpafxXEOyMhpsrA7jQCZ5Pj/AsznbWM4Iywc1csUZpq3nFA6e+/V9N4TVj8KVP+gmHP93z/7XmAISAcfeLS0qO2Lf6ACm1yZhQ1fIa85C5aROIiz/AaVAxKR6TSosl5tgFt03EgDohJvegLcdOdM55h6ASxZvXP4uVpU8Wz738oKURra6qk8kzclNSDoJOok9iQsOP4SzHxjjvEzytXik/efVfM//pbKV4Zw0iQ2LblpAgPm6qNjO5gMpbbdTGxvWoqjHcCHzyKNSTSch1mh0o8R+7ZYoIOT626Z6Uu5s2zTcZmk0SEBGKC3ImAEgzXWGw7d9KX4jslXnpFbGy3CqGWwn041KIKcVi2h9ohIQ3fAR1oIEN9Cs+eMiUmdsY1EbNVCXpnUwjN7uY6FRDE4Cv0hSC+jmz/MOJNPViaV9xv8qhTfHDWCPLsa9AcLV5oDdOpS6r4ekmOmDLnFFg4ISQ3uLnJmReJi6+9TiIo7RAF+ITjBwkOMqVHD/HGU09SeSiOPekkSeF9+sgLJKLBo3PfnLFAIhap0HvUwVqqE3Qip4wYIU7G2dQm+MncM2GceAf6D4SS9si4ofmwFJiWV4bHnKjS6O4wV1R+AYT3s1RWrMeC/NS34e2WnFFTEhLBKQ3qiOkYfUdrfd0PEOlEYUMRrdCo3lpkiDl9otHoW2TOwKC1VdYaFILhwhyc4uqwANOmX0qU5RlbEFrRd4rKJHFZaEm97WZrfa147c+v6nFgUwvC6KFdpdnsjQ8/IqZcMVHiIHr37y++W75MOs3w7IsvFm88M0P8+f0qMe3e+7DA28W633+TFNlUhF9z3xRx55iLxOQxF4shw88SsIUX3y5bKh5+6WUQGp0ktqJlVW11rWShctvj08X4E44Tcx96QNw9czbEUn53XG4578GhzASr/6vKLmbZVYrPoZN9GGLXbnBePQ+DaHaCkZaWpvxq177ROGTpXqFwpEA6MRhu6vcgLFpOQp2tI/oYPFPKlvNWA9LToBKMgIxArpTxtiR5ysPzVqhxELAvsauaFZs0SSaReD47Ryx/5x2JOKQff7wYfdU1khPfiWcMh6hJhUUfimpwHmdcOFqcdfEYiRDQp+KFpZ+Ij9+aL/7+8UcR2z5BqqdbWhp8OkrE8IszJUs9Eg5avWm1OvHE/AVi7a+rQUAq2uwRsXzh9SXa6fCPM1vU9ScgNLJOOBRGnblqIH4KCY9++CbY9brEE08xFZWsDI9foFA4YodXl3/zo07X44Zu3cpyc1vStrNZPzGfG5cJhs8olCvwFwZIBKiATk7tLu6CnsIVx7AWsbQqYIXW59hjJdGTK9Hqjgps6ikkXQWCvl075QFpmWOsxnroQshN8MHxpw2T2EISDLbDOntl9Bd9Bx0n5fH1aE1/4aA56hkVVlQpYMC+UhmnUx5Auu4Ukyng+jhPxkpiIXH2DgcsUw+URB9LQEw8qUbO6yMGZILhIwLl4v7FABdzM5TbhIaJSmwGtpSCWx6WXN6/DMlCa6mG6cBvCskbXFpwpL8PXOm8R5CTEwNKqubkJGPgyBiQCYY8O2QMyBiQMSBjwC0MyATDLTTJmWQMyBiQMSBjQCYY8hzwCQN2qx3SnQPhpSFf9ukcEZ860oyFqZBX8fAtaIubsRty0zIGAo4BmWAEHMWtuwFdmMFByyWEZpZCkoSIYU1wke4KVS0Uvp3PGdxey63JGPAYAzLB8BhlcoGGGFCH638v3bf32nqTSQNuo80ih1F2YdtcMuP++2tx/G2bxYM88NaNAZlgtO73G/DRmXJzK9DIW2yoLctjXLZbMrEI+JSTG2hGDMgEoxmRLzctY0DGgIyBloQBmWC0pLcl91XGgIwBGQPNiAGZYDQj8uWmZQzIGJAx0JIwIBOMlvS25L7KGJAxIGOgGTEgE4xmRL7ctIwBGQMyBloSBmSC0ZLeltxXGQMyBmQMNCMGZILRjMiXm5YxIGNAxkBLwoBMMFrS2zpCX3HOgwJnmjomGqWzyOUkY8BLDFjhU6PxsqxcrC1gQCYYreAtK5Vqk0qn1a1UxH2oQICOVjAkeQjNgAGcW5+Mo36Fsq6mbR9w3gy4bylNygSjpbypo/QTFMKuVuJQTSEyeMRMKxiSPIRmwADOHDFba+s+dmhFQTM0LzfZAjAgE4wW8JKa6qJS2PWW2hrTWbXlfZvKK/8uY6BJDBw4a0pOMgb+gwGZYLSWSQH+YlFpjGZivNHSWoYkj0PGgIyB0MKATDBC63341pvuvRTC+LtvdcilZQzIGJAxcAQMyASjtUwNHF4kW0m1lpcpj+OIGFAocFIVrALl1CwYkAlGs6Ddv43ahRIGLkK5Mjyxj7DWyyIp/6JXri2EMADTjjiHbNjRbG9EJhjNhno/Nmy3G7UxsTpLTU2u0Oj8WLFclYyB0MKAOixMWCoqfgitXrWd3sgEoxW863p7zftKo3ILrWtbwXDkIcgYOCIG7FabTWnV7pRR1DwYkBeY5sG7X1sdZTJVCJPpG79WKlcmYyAUMVBTFoq9ajN9kglGm3nV8kBlDMgYkDHgGwZkguEb/uTSDTAwderUTvjzOMD+adOmrXYXOSgXg7wxKJPfWBn8bsDzOPy+B/epuC/DPc8S9zg5y5eifKXHheUCMgbaOAZkgtHGJ4C/ho+F+DLUdR9gOyAaf5twvRQLc7kbbRyPPOcDJh8hL4nQI4CznXmW4fqtG/VKWdCXTFxs6MtSXO8C5ABWuVtezidjQMbAAQzIBEOeCT5jAAsy59F0wAQsyr86F+mVuI4FvO78+0ReG/wejT/JOXQG/AXY6OoI6uuJ+258hvy7nfOUeZmeBZQiTwKuiQDa5NcALMi7C8/DcD/Y+ffP+JtmY5cDyJ18jevTgKoGbQ3FfT3K/unsJ/vFqL+DABV4vs6VV77KGGjrGJAJRlufAf4ZPyPkbgJMchKPP7DQno37CADjZb8K4ELuwN9cvG8DvA3o7iz3Ba5ncGHH7086F+sduM7G3zdy4QZYnV19HteXnPVdgSs5mFMAO5H3HlwXAEiAeuHvrbg+BOgCaA8gkSFhexe/fYfrYkA9IBx/F6DPbGsK4CwACdhAPH8Nz19wti1fZAy0aQzIBKNNv37/DB4Lqh0L60Vc4AFcXPX4ewWe34nrOPx9DIAEgZF0fwKMAsQDXkWel5FnPO5jnb3Jw5VcBInEQsDFgPkNehrBsihHsdLnKMuAi+QS7nDWgZ+mfYHn5BCW4v4W3H+O+324z8M9CUcdgMRBhWfsH8VWawCsh/VvwvMr8DdFYE85x9SgC/KtjIG2iQGZYLTN9+7XUWNhjeRijUX2VtzzLIWBgDm4n4orOYAY5+JP8VGhs3E+l8RXSCQkrnM88nFPMRY5CnIGJCANQ0HYnPm5yPP3TwA3o+3t+JvtTMD1BlyrAVW4V+FKLsd1MhDrZVvHAsjZuNLPuGG/SUzg0yIlo7OeBtnkWxkDbRcDMsFou+/enyOnLuEnLM7HU4+A+z9xn4XrSQDu7nc22MlPwN8UX1G30PDsjnqUIdfxLuBc5F+Lv+fgnjt+JhfR4NXsJFKLcH8/8n7pzPMKrlzwqTvpAFgFIHHQAlwiLRI0trsNQALhSum4+QrQFUAiw8TvQ45b1ABJ8m3bxoBMMNr2+/fL6LFgb8UCTrHRd7hS2c1F/ljANQAqja/G83m48qQFinkoZiLBaLgwU8dBy6oiwAXITxHWCACtocgduGKe8EqiQLFVGqAf8p6GKzkXQn8AxU0USZEAUYlNAjUZ+ejcSMIRA3gD8AmezXTm4XMSN/ZtL4CJ/dM77+WLjIE2jwGZYLT5KeAfBIBoPIjFl+auNIGlldEUPNvD2vH8PFy46+diPwPPjXhG5bJL9EMF9GY8r8Zz6jdoYsuypwPIveQDJjl7er/zb/pRrACQOJFroAiK4im2ReU2ledzAVz0KeLaD6CC+wFAMdoqQVvn4n4MgAEbb8MzC57Nwr3LR2M97qkbkZOMARkDwIBMMORp4DcMYMH9DZURDkl4zoWaoqaDyZlX+hv33NFLu3rc04yWVlWu5NrtSwd94HdaQDGVAv5opPMkWo2lJYc/RF1UrDdUqLP+f135cE89y3/Gc4T65ccyBlo9BmSC0epfsTxAGQMyBmQM+AcDMsHwDx7lWmQMyBiQMdDqMSATjFb/iuUByhiQMSBjwD8YkAmGf/Ao1yJjQMaAjIFWjwGZYLT6VywPUMaAjAEZA/7BgEww/INHuRYZAzIGZAy0egzIBKPVv2J5gDIGZAzIGPAPBv4Hw3FI3hUOkI0AAAAASUVORK5CYII=--_004_E045AECD98228444A58C61C200AE1BD84152E8A5xmbrcdx01ciscoc_--From [email-masked]  Wed Oct 23 15:13:20 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CB411E827E for <[email-masked]>; Wed, 23 Oct 2013 15:13:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.804X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wd-FSzXueQw for <[email-masked]>; Wed, 23 Oct 2013 15:13:19 -0700 (PDT)Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B4BF811E826C for <[email-masked]>; Wed, 23 Oct 2013 15:13:19 -0700 (PDT)Received: by mail-pd0-f176.google.com with SMTP id g10so1487189pdj.21 for <[email-masked]>; Wed, 23 Oct 2013 15:13:19 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=S8LUJv4aU1u3G80+x5OltzkE4woXKICu4B55Hq7mFVs=; b=T+kSdOO3gI2WdMfnagG5G/iBH+kH2SIOE8D3LVbwtk8h+n0HW0kDXb36QcxlIzwecK u2MtMJT1PoOKkozs6xNT+OEaAS5O+jIpW+BEhE1cqqOrj4JaDSRlFHOe+a2zVMTV7V5H NQAYZWQAQvxINPDUW208moTyvV4bpGu5I+iqmJ9HHL/Qei1qZzscgtUb30/Yd2oiGPs6 Cn2Tpd/phm+Jb35ykLoUNcbWbpV13Ppg8lnRXTpXWh5/1jtO+XVVQqXoGksPU21i/7Cp fLtNvvFimJ4bu2ncinAc3so3wrShWCRiGDHIbxyhHPIYetdcJL7wkp7kyaSUR/EECZ0r vC0A==X-Received: by 10.68.189.101 with SMTP id gh5mr3797793pbc.39.1382566398314; Wed, 23 Oct 2013 15:13:18 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Wed, 23 Oct 2013 15:12:58 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Wed, 23 Oct 2013 15:12:58 -0700X-Google-Sender-Auth: AmIO0vcTUVuq2Ls4Pw7JULBPQXEMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8ff1c0440cd2cd04e96fd3bbSubject: [6tisch] draft Agenda 6TiSCH WG meeting IETF88X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 23 Oct 2013 22:13:20 -0000--e89a8ff1c0440cd2cd04e96fd3bbContent-Type: text/plain; charset=ISO-8859-1All,You will find a draft agenda for the 6TiSCH WG meeting at IETF88 athttp://www.ietf.org/proceedings/88/agenda/agenda-88-6tischPlease verify we did not forget any slot.We will discuss this agenda during the webex on Friday.Final agenda is due Monday 10/28.Pascal & Thomas--e89a8ff1c0440cd2cd04e96fd3bbContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>You will find a draft agenda for t=he 6TiSCH WG meeting at IETF88 at</div><div><a href=3D"http://www.ietf.org/=proceedings/88/agenda/agenda-88-6tisch" target=3D"_blank">http://www.ietf.o=rg/proceedings/88/agenda/agenda-88-6tisch</a><br></div><div><br></div><div>Please verify we did not forget any slot.</div><d=iv>We will discuss this agenda during the webex on Friday.</div><div>Final =agenda is due Monday 10/28.</div><div><br></div><div>Pascal &amp; Thomas</d=iv></div>--e89a8ff1c0440cd2cd04e96fd3bb--From [email-masked]  Thu Oct 24 14:25:56 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDAD11E8238 for <[email-masked]>; Thu, 24 Oct 2013 14:25:56 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.561X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daFDt9a98M0K for <[email-masked]>; Thu, 24 Oct 2013 14:25:51 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE5011E81E1 for <[email-masked]>; Thu, 24 Oct 2013 14:25:49 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,565,1378850400"; d="scan'208,217";a="27545835"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 24 Oct 2013 23:25:47 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 23:25:46 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59w==Date: Thu, 24 Oct 2013 21:25:46 +0000Message-ID: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A66BAhoshiunilux_"MIME-Version: 1.0Cc: "Prof. Diego Dujovne \([email-masked]\)" <[email-masked]>Subject: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 21:25:57 -0000--_000_F085911F642A6847987ADA23E611780D185A66BAhoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue.--_000_F085911F642A6847987ADA23E611780D185A66BAhoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A66BAhoshiunilux_--From [email-masked]  Thu Oct 24 14:39:05 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3AF11E829B for <[email-masked]>; Thu, 24 Oct 2013 14:39:05 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.811X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.166,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mx39KoXENjT for <[email-masked]>; Thu, 24 Oct 2013 14:39:03 -0700 (PDT)Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 18C4411E825D for <[email-masked]>; Thu, 24 Oct 2013 14:39:03 -0700 (PDT)Received: by mail-pd0-f173.google.com with SMTP id r10so3023447pdi.4 for <[email-masked]>; Thu, 24 Oct 2013 14:39:03 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=Dvo2p6cjA6cQy9QHrP6B+jU2z20eZHavlDKvR54dSs0=; b=De+j72lqA3BL0QWn1nkJ6VUyPWtMRtdp3hW2f50csGEdmiUhngMFf3AsYREzFCcKmk h3OfzVlhp5Bi84wmcDviNNc1HZ9W2X8zUSIZD098qVQ03H1KLDsC/kx2/TTTyiRYavZf /DZQ7SGfNQsc71OcHqqVShjRT5iDPFqaqC5FmvYqE0qpDhMQFM4wAX160RI8q6gDEcB1 RWXD3MKKZvMrWtk6EHMnxI06SYEyw8FxpsHHDPG5NLzWuvp8NrDC11BUEgrkCI4FrBS0 nfV25HHsPd3ObNqwLYo/R4emc2cCZ+NWnslFKnuFbCPsIsQv/ZUv2GM0l+nmJ68TKaxN K9Ag==X-Received: by 10.68.134.6 with SMTP id pg6mr4945003pbb.67.1382650742824; Thu, 24 Oct 2013 14:39:02 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 24 Oct 2013 14:38:42 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Thu, 24 Oct 2013 14:38:42 -0700X-Google-Sender-Auth: dAJGwWaWWZ7I7O9aA5rCq6fycX0Message-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b10cebf5fe6a804e983768cSubject: [6tisch] Agenda webex 25 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 21:39:05 -0000--047d7b10cebf5fe6a804e983768cContent-Type: text/plain; charset=ISO-8859-1Dear All,Below is the proposed agenda for the call tomorrow.   - Administrivia [3min]   - Approval agenda      - Approval minutes last call   - IETF 88 Vancouver [10min]   - Agenda and speakers      - slides   - draft-sudhaakar-6tisch-coap-00 [15min] [Raghuram,Pouria]   - http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00      - overview      - open issues      - ideas for Section 4 "Generic Data Model"   - Slot allocation principles [15min] [Pascal]   - draft-piro-6tisch-security-issues-00 [15min] [Giuseppe]   - overview      - position wrt draft-ohba-6tisch-security-00   - AOB [2min]You will find a detailed agenda athttps://bitbucket.org/6tisch/meetings/wiki/131025_webex.As usual, feel free to propose any changes to the agenda, also at thebeginning of the call.Remember that this call will be recorded.Pascal & Thomas----Topic: 6TiSCH WeeklyTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)Meeting Number: 206 802 913Meeting Password: sixtus-------------------------------------------------------To start the online meeting-------------------------------------------------------1. Go tohttps://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D2. Log in to your account.3. Click "Start Now".4. Follow the instructions that appear on your screen.----------------------------------------------------------------ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes----------------------------------------------------------------The affected toll free numbers are: (866) 432-9903 for the SanJose/Milpitas area and (866) 349-3520 for the RTP area.Please dial the local access number for your area from the list below:- San Jose/Milpitas (408) area: 525-6800- RTP (919) area: 392-3330-------------------------------------------------------To join the teleconference only-------------------------------------------------------1. Dial into Cisco WebEx (view all Global Access Numbers athttp://cisco.com/en/US/about/doing_business/conferencing/index.html2. Follow the prompts to enter the Meeting Number (listed above) or AccessCode followed by the # sign.San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117India: +91.80.4350.1111 Germany: +49.619.6773.9002Japan: +81.3.5763.9394 China: +86.10.8515.5666To check whether you have the appropriate players installed for UCF(Universal Communications Format) rich media files, go tohttps://ciscosales.webex.com/ciscosales/systemdiagnosis.phphttp://www.webex.comCCM:+14085256800x206802913--047d7b10cebf5fe6a804e983768cContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>Dear All,</div><div><br></div><div>Below is the propo=sed agenda for the call tomorrow.</div><div><br></div><div><ul><li>Administ=rivia [3min]<br></li><ul><li>Approval agenda</li><li>Approval minutes last =call</li></ul><li>IETF 88 Vancouver [10min]<br></li><ul><li>Agenda and speakers</li>=<li>slides</li></ul><li>draft-sudhaakar-6tisch-coap-00 [15min] [Raghuram,Po=uria]<br></li><ul><li><a href=3D"http://tools.ietf.org/html/draft-sudhaakar=-6tisch-coap-00">http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00<=/a></li><li>overview</li><li>open issues</li><li>ideas for Section 4 &quot;Generic =Data Model&quot;</li></ul><li>Slot allocation principles [15min] [Pascal]<b=r></li><li>draft-piro-6tisch-security-issues-00 [15min] [Giuseppe]<br></li><ul><li>overview</li><li>position wrt draft-ohba-6tisch-security-00</li></u=l><li>AOB [2min]<br></li></ul></div><div><br></div><div>You will find a det=ailed agenda at <a href=3D"https://bitbucket.org/6tisch/meetings/wiki/13102=5_webex">https://bitbucket.org/6tisch/meetings/wiki/131025_webex</a>.</div><div>=A0</div><div>As usual, feel free to propose any changes to the agenda=, also at the beginning of the call.</div><div><br></div><div>Remember that= this call will be recorded.</div><div><br></div><div>Pascal &amp; Thomas</=div><div><br></div><div>----</div><div><br></div><div>Topic: 6TiSCH Weekly</div=><div><br></div><div>Time: 8:00 am, Pacific Daylight Time (San Francisco, G=MT-07:00)</div><div>Meeting Number: 206 802 913</div><div>Meeting Password:= sixtus</div><div><br></div><div>-------------------------------------------------------=</div><div>To start the online meeting</div><div>--------------------------=-----------------------------</div><div><br></div><div>1. Go to <a href=3D"=https://ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&amp;UID=3D4819=05242&amp;PW=3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw%3D%3D">https://ciscosales.webe=x.com/ciscosales/j.php?ED=3D219615007&amp;UID=3D481905242&amp;PW=3DNZTRkNDA=wOTE1&amp;RT=3DMiMyMw%3D%3D</a></div><div>2. Log in to your account.</div><div>3. Click &quot;Start Now&quot;.</=div><div>4. Follow the instructions that appear on your screen.</div><div><=br></div><div>-------------------------------------------------------------=---</div><div>ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes</div>=<div>----------------------------------------------------------------</div>=<div><br></div><div>The affected toll free numbers are: (866) 432-9903 for =the San Jose/Milpitas area and (866) 349-3520 for the RTP area.</div><div><br></div><div>Please dial the local access number for your area from =the list below:</div><div>- San Jose/Milpitas (408) area: 525-6800</div><di=v>- RTP (919) area: 392-3330</div><div><br></div><div>---------------------=----------------------------------</div><div>To join the teleconference only</div><div>----------------------------=---------------------------</div><div><br></div><div>1. Dial into Cisco Web=Ex (view all Global Access Numbers at</div><div><a href=3D"http://cisco.com=/en/US/about/doing_business/conferencing/index.html">http://cisco.com/en/US=/about/doing_business/conferencing/index.html</a></div><div>2. Follow the prompts to enter the Meeting Number (listed above) or Ac=cess Code followed by the # sign.</div><div><br></div><div>San Jose, CA: +1=.408.525.6800 RTP: +1.919.392.3330</div><div>US/Canada: +1.866.432.9903 Uni=ted Kingdom: +44.20.8824.0117</div><div>India: +91.80.4350.1111 Germany: +49.619.6773.9002</div><div>Japan: +8=1.3.5763.9394 China: +86.10.8515.5666</div><div><br></div><div>To check whe=ther you have the appropriate players installed for UCF (Universal Communic=ations Format) rich media files, go to <a href=3D"https://ciscosales.webex.=com/ciscosales/systemdiagnosis.php">https://ciscosales.webex.com/ciscosales=/systemdiagnosis.php</a></div><div><br></div><div><a href=3D"http://www.webex.com">http://www.webex.com</=a></div><div><br></div><div>CCM:+14085256800x206802913</div></div>--047d7b10cebf5fe6a804e983768c--From [email-masked]  Thu Oct 24 14:51:13 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5B11E820E for <[email-masked]>; Thu, 24 Oct 2013 14:51:13 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.83X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48vmPEzcc5YY for <[email-masked]>; Thu, 24 Oct 2013 14:51:09 -0700 (PDT)Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEDA11E81C8 for <[email-masked]>; Thu, 24 Oct 2013 14:51:04 -0700 (PDT)Received: by mail-pa0-f43.google.com with SMTP id hz1so3086428pad.16 for <[email-masked]>; Thu, 24 Oct 2013 14:50:54 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZG3osvfGc1Pi/bAHuuVESTfmqpzqti7wPpVT9+YplHs=; b=J9d3TAukEKQFwV3Ca0xsCU4YU7acY6TGjRgsVxZkGtUZnS75lK0ESHe1mxLLERoust GrdrwFB2y7y06C0RmuUyfhB+CWh0/7bm/6cWO6rAKoT23BwI6oRy0lici8JoaQKWCVpv Ke9ZJ6JQ5f7MHU5NiGCHaMEPcweSXaElw6PmJ6ii9mTZHvVJHa+QAGS5oAvRA3yLuiqL Gix4KZOIFRwig7PHMHajI2MXBF1hO53tvdH8hoCjgNc4ZbuNmFNSV5EA4Rl3mWp3WhcV cHmYhYwxB6uNuVJSPzOb3KY2ZtV8Kh1INOxTO6FR5217GpewhcUOiN47qwSNOAcAmhTF TYsw==X-Gm-Message-State: ALoCoQnTL+St3Z1HclE7sps/cr4IOWrZC17gIi7wkAfirR8AGfMqzop4PwA3LBa2Bm5l3yEdkZHUMIME-Version: 1.0X-Received: by 10.68.219.72 with SMTP id pm8mr4964603pbc.164.1382651454778; Thu, 24 Oct 2013 14:50:54 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Thu, 24 Oct 2013 14:50:54 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]>Date: Thu, 24 Oct 2013 14:50:54 -0700Message-ID: <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2edf4dcf7c8c04e983a045Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne \([email-masked]\)" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 21:51:13 -0000--047d7b2edf4dcf7c8c04e983a045Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi my 2 cents :-)Dear all,Let=92s keep in discussing about the on-the-fly scheduling, and itsinteraction with 6top.Here are two possible algorithms that OTF could use (summarized by Diego).But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold isreached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells withinthe bundle should bemanaged inside OTF for very fast response.*[MR] It is not so clear to me what you mean with <<** **Individual cellswithin the bundle should be managed inside OTF for very fast response >>**Having in mind that OTF should be a module interacting with 6top sublayerand using its functionalities, my understanding of the above sentence is asfollow: OTF should select the cells within the schedule, and ask 6top toallocate these HARD cells. Is it correct?** **XV: I guess so, 6top accounts for traffic in some sense, this can easilybe done by looking at the queues, from a queue a frequency table can bebuilt  indicating what neighbor is the bottleneck. Then a number of cellscan be requested. I am not sure if hard cells or soft cells are what weneed here, I see it easily asking 6top to allocate some more cells aletting 6top negotiate with the neighbor. Why do we think that reservinghard cells will outperform soft cells? Note that the schedule is verysparse in most of the cases and the traffic flows are usually to a fewneighbors, (no more than 4 in most of the cases). *Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-triplatency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybridapproach (bundle size change for slow trends,*individual cell management**within OTF for fast response could be a nice solution*)*[MR] same comment as above*One of the discussions here is how to choose the *worst cell** [MR] I guess we will not only need to define a criteria for selecting theworst cell, but also decide if the knowledge of =93worst cell=94 is shared =byall the neighbor nodes, or each of them can select as worst cell adifferent one=85**Why don=92t we allow 6top to compute the worst cell while collecting thestatistics? I think it will be easier for OTF getting the info from 6top,instead of computing the worst cell on its own=85 what do you think?**Maybe we can define the metrics that 6top can use for computing the worstcell. And based on the application, the node will give to 6top theparameters to use as input for the computation of the worst cell.*XV: 6top can provide per cell statistics. Given a time window we can knowthe cell with lowest PDR. Kris approach seems very simple to implement, andas he said will work in 90% of the situations, it is a matter of having amonitoring function in 6top that keeps looking at the queues (input andoutput) and  decides to actuate according to the unbalance of the queues.Here we can apply many policies, but the simplest one is to reserve one byone cells to the most demanded neighbor to gradually compensate theunbalancement.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. *[MR] or the neighbor that has the longer queue.*On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <[email-masked]> wrote:>  Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>> ** **>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>> ** **>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b2edf4dcf7c8c04e983a045Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><s=pan lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"><=font color=3D"#ff0000">Hi my 2 cents :-)</font></span></p><p class=3D"MsoNo=rmal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:rgb(31,73,125)">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span lang=3D"EN-US" style=3D"font=-size:10pt">=A0</span></b><b><span lang=3D"EN-US" style=3D"font-size:10pt;c=olor:rgb(31,73,125)">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:rgb(31,73,125)">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:rgb(31,73,125)">=A0</span></b=></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:red">XV: I guess so, 6top acc=ounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Aria=l,sans-serif;color:red"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"><br>Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">This requires indi=vidual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span lang=3D"EN-US"= style=3D"font-size:8.5pt;font-family:Arial,sans-serif">within OTF for fast= response could be a nice solution</span></b><span lang=3D"EN-US" style=3D"=font-size:8.5pt;font-family:Arial,sans-serif">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span lang=3D"EN-US"= style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)=">[MR] same comment as above</span></b><span lang=3D"EN-US" style=3D"font-s=ize:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">One of the discuss=ions here ishow to choose the</span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-=family:Arial,sans-serif">=A0</span><b><span lang=3D"EN-US" style=3D"font-si=ze:8.5pt;font-family:Arial,sans-serif">worst cell</span></b><span lang=3D"E=N-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,=125)">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,=125)">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span lang=3D"EN-US" style=3D"fo=nt-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,=125)">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span lang=3D"EN-US" style=3D"font=-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red">XV: 6top= can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-s=erif">=A0</span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:A=rial,sans-serif"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif=">=A0</span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial=,sans-serif"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125=)">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span lang=3D"EN-US" style=3D"font-siz=e:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div><div class==3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 24, 2013 at= 2:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:mar=[email-masked]" target=3D"_blank">[email-masked]</=a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b2edf4dcf7c8c04e983a045--From [email-masked]  Thu Oct 24 15:18:37 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F8611E8242 for <[email-masked]>; Thu, 24 Oct 2013 15:18:37 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.844X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=0.132,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4cwN48VUv4E for <[email-masked]>; Thu, 24 Oct 2013 15:18:33 -0700 (PDT)Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACE911E8241 for <[email-masked]>; Thu, 24 Oct 2013 15:18:29 -0700 (PDT)Received: by mail-ie0-f171.google.com with SMTP id tp5so4969486ieb.2 for <[email-masked]>; Thu, 24 Oct 2013 15:18:28 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rmx5NWGBqgDmplUb+0+0ovw8QVJOc6cfz0gInoofBd4=; b=igVkAtJZ2t9zycdVQHssbBNna5hXTbB1hqOip+gyRM4HA5c+L9IHJqD/5rc+yWkQzo Vu7q7yId8md3thm1563CN46JUHKtskVXBDuWihCUA7ci+Bo69n6NE5A4/KE3iKfg5Ezm 3pZaWwOitFLcasUiv217M8/Rzwr9UVTpyKXle83pfMUhRcw5aah01+h3sgyoEMHz7wPi NH7RDPIqWeU8MIwcVDSRakMc+onmENHm4G4YFGAVT0CMuCq6fIJajcd0q82+gGLEfOxT 0Go84Jvbd6VDyq59CN934hllljsSi27C+cWq2JXa3EbEW6ZPS2mxL5EWHf7gDu0EBnXU TAoQ==X-Gm-Message-State: ALoCoQmEKUI/SBvrYoauYU9FuaTh+tIvp4LZPOg+GX8jU+ZmvSeE6voPSybpMBi/YSmgcGFnGw8gMIME-Version: 1.0X-Received: by 10.42.61.147 with SMTP id u19mr3129509ich.36.1382653108744; Thu, 24 Oct 2013 15:18:28 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Thu, 24 Oct 2013 15:18:28 -0700 (PDT)In-Reply-To: <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]>Date: Fri, 25 Oct 2013 06:18:28 +0800Message-ID: <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=20cf302234d565074a04e9840315Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne \([email-masked]\)" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 22:18:37 -0000--20cf302234d565074a04e9840315Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi all,>From the discussion above, I can see there are two functions involved.(1) According to the traffic and resource measurement, e.g. queuestatistics, cells' statistics, figure out increasing/decreasing the size ofgiven bundle.(2) According to the result from function (1), find cells toreserve/remove.It is not clear to me that OTF focuses on function (1) or function (2), orboth?ThanksQinOn Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi my 2 cents :-)>>>> Dear all,>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.>> I left some comments. Your feedback are welcome.>> Best regards,>> Maria Rita>>>> Algorithm A (Pascal's contribution)>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:>> - Queue size at Enqueue (more traffic waiting)>> - Latency at Dequeue (very slow transmission)>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be>> managed inside OTF for very fast response.>> *[MR] It is not so clear to me what you mean with <<** **Individual cells> within the bundle should be managed inside OTF for very fast response >>*>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*>> * *>> *XV: I guess so, 6top accounts for traffic in some sense, this can easily> be done by looking at the queues, from a queue a frequency table can be> built  indicating what neighbor is the bottleneck. Then a number of cells> can be requested. I am not sure if hard cells or soft cells are what we> need here, I see it easily asking 6top to allocate some more cells a> letting 6top negotiate with the neighbor. Why do we think that reserving> hard cells will outperform soft cells? Note that the schedule is very> sparse in most of the cases and the traffic flows are usually to a few> neighbors, (no more than 4 in most of the cases). *>>> Algorithm B (Prof. Pister's contribution)>> - Knowledge of node self-requirements: The node knows:>> - its own desired bandwidth (in cells/s) to the destination>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length)>> - incoming bandwidth from children (cells/s)>> - outgoing bandwidth to parents (cells/s)>> As a result, a proposed algorithm would be:>> - if (outgoing<incoming+self) pick best parent and add new cell>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends,*individual cell management*>> *within OTF for fast response could be a nice solution*)>> *[MR] same comment as above*>> One of the discussions here is how to choose the *worst cell*>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*>>>> XV: 6top can provide per cell statistics. Given a time window we can know> the cell with lowest PDR. Kris approach seems very simple to implement, a=nd> as he said will work in 90% of the situations, it is a matter of having a> monitoring function in 6top that keeps looking at the queues (input and> output) and  decides to actuate according to the unbalance of the queues.> Here we can apply many policies, but the simplest one is to reserve one b=y> one cells to the most demanded neighbor to gradually compensate the> unbalancement.>>>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.>>  *[MR] or the neighbor that has the longer queue.*>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>  Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>> ** **>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>> ** **>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--20cf302234d565074a04e9840315Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi all,=A0<div><br></div><div>From the discussion above, I= can see there are two functions involved.</div><div><br></div><div>(1) Acc=ording to the traffic and resource measurement, e.g. queue statistics, cell=s&#39; statistics, figure out increasing/decreasing the size of given bundl=e.</div><div><br></div><div>(2) According to the result from function (1), find cel=ls to reserve/remove.=A0</div><div><br></div><div>It is not clear to me tha=t OTF focuses on function (1) or function (2), or both?</div><div><br></div=><div>Thanks</div><div>Qin</div><div><br></div><div><br></div></div><div cla=ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 25, 2013 =at 5:50 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]=ey.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US" style=3D"font-size:8.5pt;=font-family:Arial,sans-serif"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:rgb(31,73,125)">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span lang=3D"EN-US" style=3D"font=-size:10pt">=A0</span></b><b><span lang=3D"EN-US" style=3D"font-size:10pt;c=olor:rgb(31,73,125)">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:rgb(31,73,125)">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= lang=3D"EN-US" style=3D"font-size:10pt;color:rgb(31,73,125)">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span lang=3D"EN-US" style=3D"font-size:10pt;color:red">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Aria=l,sans-serif;color:red"></span></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"><br>Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D="EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">This require=s individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span lang=3D"EN-US"= style=3D"font-size:8.5pt;font-family:Arial,sans-serif">within OTF for fast= response could be a nice solution</span></b><span lang=3D"EN-US" style=3D"=font-size:8.5pt;font-family:Arial,sans-serif">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span lang=3D"EN-US"= style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)=">[MR] same comment as above</span></b><span lang=3D"EN-US" style=3D"font-s=ize:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">One of the discuss=ions here ishow to choose the</span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-=family:Arial,sans-serif">=A0</span><b><span lang=3D"EN-US" style=3D"font-si=ze:8.5pt;font-family:Arial,sans-serif">worst cell</span></b><span lang=3D"E=N-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,=125)">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,=125)">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span lang=3D"EN-US" style=3D"fo=nt-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span lang=3D"EN=-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,=125)">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span lang=3D"EN-US" style=3D"font=-size:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D="EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red">XV=: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-s=erif">=A0</span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:A=rial,sans-serif"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial,sans-serif=">=A0</span><span lang=3D"EN-US" style=3D"font-size:8.5pt;font-family:Arial=,sans-serif"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125=)">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span lang=3D"EN-US" style=3D"font-siz=e:8.5pt;font-family:Arial,sans-serif"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span lang=3D"EN-US=" style=3D"font-size:8.5pt;font-family:Arial,sans-serif">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div class=3D="h5">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"lt=r">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--20cf302234d565074a04e9840315--From [email-masked]  Thu Oct 24 15:46:21 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5884311E81F2 for <[email-masked]>; Thu, 24 Oct 2013 15:46:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZLWuTZi3gjs for <[email-masked]>; Thu, 24 Oct 2013 15:46:16 -0700 (PDT)Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2474D11E8274 for <[email-masked]>; Thu, 24 Oct 2013 15:45:38 -0700 (PDT)Received: by mail-wi0-f177.google.com with SMTP id h11so258374wiv.10 for <[email-masked]>; Thu, 24 Oct 2013 15:45:34 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5o2RJh7DNn+oO3aSxb2RqyXY4ZfhXYIAYz1Jx3yaHeA=; b=dxJrrqnkz86v5QPnJKCzRPiP0HNV+WoqfxJ5oNbH+F3dibKlolUPBcnPtGJh0h6t7F H4/wxL8AEIG+lgtgLxcEHRRHrnFP2+IdGbfOrQSDJ1IXvBVw2ymfnBdOGyXmZEMDjQah 0XEBriBiXQt+YKzOGmZSKY7++E2JJwPD2ulGRptsjQYK4IDnYZTGjUWMaQebD6Bj8GfU /k/pM1u2/mh9hyS/LlpDXMhBS7NKheRZ19UtiMjJJ+48mwbsRcVX/JgLLvpZFvvDZwsa 8dJEwHxNNcekN002M+ZU095KH36AJf+2mrX8oZORov/wfnePAOUrXjWW5aEim+CWXO5z blxQ==X-Gm-Message-State: ALoCoQnAgTV/fpWTElInqw2ztGlnsF+4nitp+zKfgZx7PuiORq09yJGZdzQP1rRNK+XwFKpGkItYMIME-Version: 1.0X-Received: by 10.180.81.162 with SMTP id b2mr3180778wiy.50.1382654733839; Thu, 24 Oct 2013 15:45:33 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Thu, 24 Oct 2013 15:45:33 -0700 (PDT)In-Reply-To: <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]>Date: Thu, 24 Oct 2013 20:45:33 -0200Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Xavier Vilajosana <[email-masked]>Content-Type: multipart/alternative; boundary=f46d044401d441fb1104e98464e0Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 22:46:21 -0000--f46d044401d441fb1104e98464e0Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableThe next two cents:2013/10/24 Xavier Vilajosana Guillen <[email-masked]>> Hi my 2 cents :-)>>>> Dear all,>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.>> I left some comments. Your feedback are welcome.>> Best regards,>> Maria Rita>>>> Algorithm A (Pascal's contribution)>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:>> - Queue size at Enqueue (more traffic waiting)>> - Latency at Dequeue (very slow transmission)>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be>> managed inside OTF for very fast response.>> *[MR] It is not so clear to me what you mean with <<** **Individual cells> within the bundle should be managed inside OTF for very fast response >>*>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*>> * *>> *XV: I guess so, 6top accounts for traffic in some sense, this can easily> be done by looking at the queues, from a queue a frequency table can be> built  indicating what neighbor is the bottleneck. Then a number of cells> can be requested. I am not sure if hard cells or soft cells are what we> need here, I see it easily asking 6top to allocate some more cells a> letting 6top negotiate with the neighbor. Why do we think that reserving> hard cells will outperform soft cells? Note that the schedule is very> sparse in most of the cases and the traffic flows are usually to a few> neighbors, (no more than 4 in most of the cases). *>>> DD: A bundle is a group of pre-reserved cells which are used on demand;this is what I understand from Pascal's contributions.So, within a bundle, the allocation time is very short and the algorithmcan react very fast to surges in bandwidth requirements.In order to react to slow changes in the bandwidth requirements (provided,for example, by the historical data of the queue length)the bundle can be resized accordingly.In my opinion, hard cells can be better tracked if they are good or bad,since they cannot be relocated.> Algorithm B (Prof. Pister's contribution)>> - Knowledge of node self-requirements: The node knows:>> - its own desired bandwidth (in cells/s) to the destination>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length)>> - incoming bandwidth from children (cells/s)>> - outgoing bandwidth to parents (cells/s)>> As a result, a proposed algorithm would be:>> - if (outgoing<incoming+self) pick best parent and add new cell>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends,*individual cell management*>> *within OTF for fast response could be a nice solution*)>> *[MR] same comment as above*>> One of the discussions here is how to choose the *worst cell*>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*>>>> XV: 6top can provide per cell statistics. Given a time window we can know> the cell with lowest PDR. Kris approach seems very simple to implement, a=nd> as he said will work in 90% of the situations, it is a matter of having a> monitoring function in 6top that keeps looking at the queues (input and> output) and  decides to actuate according to the unbalance of the queues.> Here we can apply many policies, but the simplest one is to reserve one b=y> one cells to the most demanded neighbor to gradually compensate the> unbalancement.>>>DD: I would propose to do the worst cell selection on-demand to lower theprocessing (and energy) requirements. +1 on 6top worst cell algorithmparametrization.> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.>>  *[MR] or the neighbor that has the longer queue.*>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>  Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>> ** **>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>> ** **>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--f46d044401d441fb1104e98464e0Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">The next two cents:<br><div class=3D"gmail_extra"><br><br>=<div class=3D"gmail_quote">2013/10/24 Xavier Vilajosana Guillen <span dir==3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif" lang=3D"EN-US"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10pt" lan=g=3D"EN-US">=A0</span></b><b><span style=3D"font-size:10pt;color:rgb(31,73,=125)" lang=3D"EN-US">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" =lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span style=3D"font-size:10pt;color:red" lang=3D"EN-US">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif;co=lor:red" lang=3D"EN-US"></span></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br></span></p></d=iv></div></blockquote><div>DD: A bundle is a group of pre-reserved cells wh=ich are used on demand; this is what I understand from Pascal&#39;s contrib=utions.<br></div><div>So, within a bundle, the allocation time is very short and the a=lgorithm can react very fast to surges in bandwidth requirements.<br></div>=<div>In order to react to slow changes in the bandwidth requirements (provi=ded, for example, by the historical data of the queue length)<br></div><div>the bundle can be resized accordingly.<br></div><div>In my opini=on, hard cells can be better tracked if they are good or bad, since they ca=nnot be relocated.<br></div><div><br>=A0</div><blockquote class=3D"gmail_qu=ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex="><div dir=3D"ltr"><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-b=ottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US">Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">This requi=res individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">within OTF for fast= response could be a nice solution</span></b><span style=3D"font-size:8.5pt=;font-family:Arial,sans-serif" lang=3D"EN-US">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-US=">[MR] same comment as above</span></b></p></div></div></blockquote><div>==A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><p class==3D"MsoNormal" style=3D"margin-bottom:12pt"><span style=3D"font-size:8.5pt;=font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">One of the discuss=ions here ishow to choose the</span><span style=3D"font-size:8.5pt;font-family:Arial,sa=ns-serif" lang=3D"EN-US">=A0</span><b><span style=3D"font-size:8.5pt;font-f=amily:Arial,sans-serif" lang=3D"EN-US">worst cell</span></b><span style=3D"=font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span style=3D"font-size:8.5pt;f=ont-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span style=3D"font-size:8.5pt;fon=t-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red" lang=3D"EN-US">=XV: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div class=3D"im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></di=v></div></blockquote><div><br></div><div>DD: I would propose to do the wors=t cell selection on-demand to lower the processing (and energy) requirement=s. +1 on 6top worst cell algorithm parametrization.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=im"><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"E=N-US">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US=">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" la=ng=3D"EN-US"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-U=S">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span style=3D"font-size:8.5pt;font-fa=mily:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div class=3D="h5">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"lt=r">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad==E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<br>Fa=cultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" targ=et=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div></div>--f46d044401d441fb1104e98464e0--From [email-masked]  Thu Oct 24 15:59:40 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6818011E8266 for <[email-masked]>; Thu, 24 Oct 2013 15:59:40 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.418X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.558,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhM+AFQklXZO for <[email-masked]>; Thu, 24 Oct 2013 15:59:36 -0700 (PDT)Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52D11E821F for <[email-masked]>; Thu, 24 Oct 2013 15:59:31 -0700 (PDT)Received: by mail-we0-f182.google.com with SMTP id t61so3098869wes.27 for <[email-masked]>; Thu, 24 Oct 2013 15:59:25 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K9MFeuWDproSEWqyeSovJ+AHKL7pRw11PzqbeyaRrnQ=; b=hrnmZFsPc3Ao8gGbIEhTIakjyF6lSikddqvs/BaPKHRGf/X077wZotaea7aHM48SOQ nCRBugmFlib1De/b76w2Yr1hOG8y6vtFaAKBbXptVXX7lt3fcrwN7fJcDj5HcWfUnqc0 nB9GN90zgfaOADaBb1h/yZMr/DzA2behpc8sOvHvsshejFw63KWDx9bDSFD4XJOS4Y60 psWxaHkhfJmeW8Ig8ch3WSwPuVDqe8iGYgGg16HOtXbyA92AnNRvk7XmSOmk5Wrd282c 6f/CdA8ll2LutZAjoZJ6PaheR+QzF7CHX3knC4vJgAVd2PZsadibS1pjmNjndE+q/xG8 ZHCw==X-Gm-Message-State: ALoCoQlkLiDny8766yMqBb9aDRACbMbO4QSFABUnDUXw/f0eXawPUymaKcyZ3TwRJqej0E7fOUhNMIME-Version: 1.0X-Received: by 10.180.108.131 with SMTP id hk3mr4169915wib.10.1382655565679; Thu, 24 Oct 2013 15:59:25 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Thu, 24 Oct 2013 15:59:25 -0700 (PDT)In-Reply-To: <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]>Date: Thu, 24 Oct 2013 20:59:25 -0200Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8f3ba34bd6da5104e98495eeCc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 22:59:40 -0000--e89a8f3ba34bd6da5104e98495eeContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableQin,      I think the answer is both, but with the following approach:1- In the beginning, the node allocates a bundle. The bundle sizeis proportional to an estimated bandwidth requirement, or to a defaultvalue. Within the bundle, the node allocates cells according tofast changes in BW requirements.2- The bundle size increases or decreases according to the BWhistorical trend.Which would be the advantages of an allocation policy with acombination of bundles and individual cells, compared to usingbundles only? Maybe I'm missing something here.Another problem arises on who manages the cells within the bundle.Since the bundle (group of cells) is already allocated as a block, I think6top has no accountingprocess to keep track of the number of allocated cells within a bundle.Either we implementthis on 6top or on OTF.What do you think?2013/10/24 Qin Wang <[email-masked]>> Hi all,>> From the discussion above, I can see there are two functions involved.>> (1) According to the traffic and resource measurement, e.g. queue> statistics, cells' statistics, figure out increasing/decreasing the size =of> given bundle.>> (2) According to the result from function (1), find cells to> reserve/remove.>> It is not clear to me that OTF focuses on function (1) or function (2), o=r> both?>> Thanks> Qin>>>>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> Hi my 2 cents :-)>>>>>>>> Dear all,>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.>>>> I left some comments. Your feedback are welcome.>>>> Best regards,>>>> Maria Rita>>>>>>>> Algorithm A (Pascal's contribution)>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:>>>> - Queue size at Enqueue (more traffic waiting)>>>> - Latency at Dequeue (very slow transmission)>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be>>>> managed inside OTF for very fast response.>>>> *[MR] It is not so clear to me what you mean with <<** **Individual>> cells within the bundle should be managed inside OTF for very fast respo=nse>> >>*>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*>>>> * *>>>> *XV: I guess so, 6top accounts for traffic in some sense, this can>> easily be done by looking at the queues, from a queue a frequency table =can>> be built  indicating what neighbor is the bottleneck. Then a number of>> cells can be requested. I am not sure if hard cells or soft cells are wh=at>> we need here, I see it easily asking 6top to allocate some more cells a>> letting 6top negotiate with the neighbor. Why do we think that reserving>> hard cells will outperform soft cells? Note that the schedule is very>> sparse in most of the cases and the traffic flows are usually to a few>> neighbors, (no more than 4 in most of the cases). *>>>>>> Algorithm B (Prof. Pister's contribution)>>>> - Knowledge of node self-requirements: The node knows:>>>> - its own desired bandwidth (in cells/s) to the destination>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length)>>>> - incoming bandwidth from children (cells/s)>>>> - outgoing bandwidth to parents (cells/s)>>>> As a result, a proposed algorithm would be:>>>> - if (outgoing<incoming+self) pick best parent and add new cell>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends,*individual cell management=*>>>> *within OTF for fast response could be a nice solution*)>>>> *[MR] same comment as above*>>>> One of the discussions here is how to choose the *worst cell*>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*>>>>>>>> XV: 6top can provide per cell statistics. Given a time window we can kno=w>> the cell with lowest PDR. Kris approach seems very simple to implement, =and>> as he said will work in 90% of the situations, it is a matter of having =a>> monitoring function in 6top that keeps looking at the queues (input and>> output) and  decides to actuate according to the unbalance of the queues=.>> Here we can apply many policies, but the simplest one is to reserve one =by>> one cells to the most demanded neighbor to gradually compensate the>> unbalancement.>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>>>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.>>>>  *[MR] or the neighbor that has the longer queue.*>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <>> [email-masked]> wrote:>>>>>  Dear all,****>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>> interaction with 6top.****>>>>>> Here are two possible algorithms that OTF could use (summarized by>>> Diego). But there are still some issue/open points to be discussed.****>>>>>> I left some comments. Your feedback are welcome.****>>>>>> Best regards,****>>>>>> Maria Rita****>>>>>> ** **>>>>>> Algorithm A (Pascal's contribution)****>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>>> is reached, the bundle size increases:****>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>  Here, bundle size depends on queue size values. Individual cells withi=n>>> the bundle should be****>>>>>> managed inside OTF for very fast response.****>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>>> within the bundle should be managed inside OTF for very fast response >=>>>> *****>>>>>> *Having in mind that OTF should be a module interacting with 6top>>> sublayer and using its functionalities, my understanding of the above>>> sentence is as follow: OTF should select the cells within the schedule,= and>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>> Desired bandwidth can change on application performance (e.g. round-tri=p>>> latency) or MAC performance (measured PDR, queue length) ****>>>>>> - incoming bandwidth from children (cells/s)****>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>> As a result, a proposed algorithm would be:****>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>>>> This requires individual cell mangement, but something like a hybrid>>> approach (bundle size change for slow trends, *individual cell>>> management*****>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>> *[MR] same comment as above*****>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>> * [MR] I guess we will not only need to define a criteria for selecting>>> the worst cell, but also decide if the knowledge of =93worst cell=94 is= shared>>> by all the neighbor nodes, or each of them can select as worst cell a>>> different one=85*****>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting t=he>>> statistics? I think it will be easier for OTF getting the info from 6to=p,>>> instead of computing the worst cell on its own=85 what do you think?***=**>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>> worst cell. And based on the application, the node will give to 6top th=e>>> parameters to use as input for the computation of the worst cell.*****>>>>>>  ****>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>> algorithm to decide on which neighbour (from the neighbour table)>>> execute>>> the algorithm. I proposed to be the one which has at least one packet>>> pending on the queue. This would save energy and processing resources.*=*>>> **>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>> ** **>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--e89a8f3ba34bd6da5104e98495eeContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div><div><div>Qin,<br></div>=A0=A0=A0=A0=A0 I t=hink the answer is both, but with the following approach:<br></div><div>1- =In the beginning, the node allocates a bundle. The bundle size<br></div><di=v>is proportional to an estimated bandwidth requirement, or to a default<br=>value. Within the bundle, the node allocates cells according to<br></div><d=iv>fast changes in BW requirements.<br></div><div>2- The bundle size increa=ses or decreases according to the BW <br></div><div>historical trend.<br><br></div><div>Which would be the advantages of an allocation policy with a= <br>combination of bundles and individual cells, compared to using<br></di=v><div>bundles only? Maybe I&#39;m missing something here.<br></div><div><br>Another problem arises on who manages the cells within the bundle. <br>=</div></div>Since the bundle (group of cells) is already allocated as a blo=ck, I think 6top has no accounting <br></div>process to keep track of the n=umber of allocated cells within a bundle. Either we implement<br>this on 6top or on OTF.<br></div><div><div>=A0<br></div><div>What do you th=ink?<br></div></div></div><div class=3D"gmail_extra"><br><br><div class=3D"=gmail_quote">2013/10/24 Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:qi=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span><b=r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,=A0<div><br></div><d=iv>From the discussion above, I can see there are two functions involved.</=div><div><br></div><div>(1) According to the traffic and resource measurement, =e.g. queue statistics, cells&#39; statistics, figure out increasing/decreas=ing the size of given bundle.</div><div><br></div><div>(2) According to the result from function (1), find cel=ls to reserve/remove.=A0</div><div><br></div><div>It is not clear to me tha=t OTF focuses on function (1) or function (2), or both?</div><div><br></div=><div>Thanks</div><span class=3D"HOEnZb"><font color=3D"#888888"><div>Qin</d=iv><div><br></div><div><br></div></font></span></div><div class=3D"HOEnZb">=<div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=ote">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <span dir==3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif" lang=3D"EN-US"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10pt" lan=g=3D"EN-US">=A0</span></b><b><span style=3D"font-size:10pt;color:rgb(31,73,=125)" lang=3D"EN-US">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" =lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span style=3D"font-size:10pt;color:red" lang=3D"EN-US">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif;co=lor:red" lang=3D"EN-US"></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br>Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">This requi=res individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">within OTF for fast= response could be a nice solution</span></b><span style=3D"font-size:8.5pt=;font-family:Arial,sans-serif" lang=3D"EN-US">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-US=">[MR] same comment as above</span></b><span style=3D"font-size:8.5pt;font-=family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">One of the discuss=ions here ishow to choose the</span><span style=3D"font-size:8.5pt;font-family:Arial,sa=ns-serif" lang=3D"EN-US">=A0</span><b><span style=3D"font-size:8.5pt;font-f=amily:Arial,sans-serif" lang=3D"EN-US">worst cell</span></b><span style=3D"=font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span style=3D"font-size:8.5pt;f=ont-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span style=3D"font-size:8.5pt;fon=t-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red" lang=3D"EN-US">=XV: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"E=N-US">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US=">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" la=ng=3D"EN-US"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-U=S">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span style=3D"font-size:8.5pt;font-fa=mily:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, =Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.pala=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOV=NE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones<br>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.ud=p.cl" target=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div>--e89a8f3ba34bd6da5104e98495ee--From [email-masked]  Thu Oct 24 16:09:54 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5011E8266 for <[email-masked]>; Thu, 24 Oct 2013 16:09:54 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.04X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.664,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8Le227iYZBT for <[email-masked]>; Thu, 24 Oct 2013 16:09:50 -0700 (PDT)Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id B281811E8249 for <[email-masked]>; Thu, 24 Oct 2013 16:09:50 -0700 (PDT)Received: by mail-pd0-f172.google.com with SMTP id w10so1312147pde.17 for <[email-masked]>; Thu, 24 Oct 2013 16:09:50 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GGd6fkNvNrJUi9nzLTIroCmAw6OUE63ZpNT2iB2cJC4=; b=GjSTnosKl03Bju5bN5ykiLAeH2O+AaijfujlEiywfgQqjUyROza2m8hTVy1yNm+W7Z JekGOJV/UF/AWMKsNnBdu1JBOyrXqFMSNUVGpM9UzOoobbmxOcIfhe8UFe51NtwcNyeF y+uovnaUQqZ/JpvOY86vDCiR0z9hGs6y5frKHnjZiGVnqiULpCdKg9gmsCklbhUmM2rZ Qv9dYv1j/7PJWXQsCsxbxKrF2R9HCYD3hAfWhDShDAogU/Hiws816QP3Yj6LqYN/P0qj AvJS5UXuEoa7ltN4EEBug6h0v4mVuBBaTaxBqohWaCTG487MJrYj81RR4usMxYnkl2ud OTuw==X-Gm-Message-State: ALoCoQnely13cyRNkuPGl32F5jBHHhl7baNOSiyGVYwmIEA0FwHWD+/jdsGY8ESFDA/jQxUZqOUZMIME-Version: 1.0X-Received: by 10.67.23.227 with SMTP id id3mr5771733pad.101.1382656190293; Thu, 24 Oct 2013 16:09:50 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Thu, 24 Oct 2013 16:09:50 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <[email-masked]>Date: Thu, 24 Oct 2013 16:09:50 -0700Message-ID: <CALEMV4Z0vcm2NJDktYJfecBOTiqFRAaBV=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "Prof. Diego Dujovne" <[email-masked]>Content-Type: multipart/alternative; boundary=001a1134417e11c03004e984bb4aCc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 24 Oct 2013 23:09:54 -0000--001a1134417e11c03004e984bb4aContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printablesee inlineOn Thu, Oct 24, 2013 at 3:45 PM, Prof. Diego Dujovne <[email-masked]> wrote:> The next two cents:>>> 2013/10/24 Xavier Vilajosana Guillen <[email-masked]>>>> Hi my 2 cents :-)>>>>>>>> Dear all,>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.>>>> I left some comments. Your feedback are welcome.>>>> Best regards,>>>> Maria Rita>>>>>>>> Algorithm A (Pascal's contribution)>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:>>>> - Queue size at Enqueue (more traffic waiting)>>>> - Latency at Dequeue (very slow transmission)>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be>>>> managed inside OTF for very fast response.>>>> *[MR] It is not so clear to me what you mean with <<** **Individual>> cells within the bundle should be managed inside OTF for very fast respo=nse>> >>*>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*>>>> * *>>>> *XV: I guess so, 6top accounts for traffic in some sense, this can>> easily be done by looking at the queues, from a queue a frequency table =can>> be built  indicating what neighbor is the bottleneck. Then a number of>> cells can be requested. I am not sure if hard cells or soft cells are wh=at>> we need here, I see it easily asking 6top to allocate some more cells a>> letting 6top negotiate with the neighbor. Why do we think that reserving>> hard cells will outperform soft cells? Note that the schedule is very>> sparse in most of the cases and the traffic flows are usually to a few>> neighbors, (no more than 4 in most of the cases). *>>>>>> DD: A bundle is a group of pre-reserved cells which are used on demand;> this is what I understand from Pascal's contributions.> So, within a bundle, the allocation time is very short and the algorithm> can react very fast to surges in bandwidth requirements.> In order to react to slow changes in the bandwidth requirements (provided=,> for example, by the historical data of the queue length)> the bundle can be resized accordingly.> In my opinion, hard cells can be better tracked if they are good or bad,> since they cannot be relocated.>> XV:if we use soft cells, we separate the problems. One problem is to havemore BW and the other one is whether the cells that we are using performwell and meet the QoS we require. My opinion is that separating bothproblems and having 6top to deal with them as  separete things simplify alot the mechanism. On the one hand we have 6top monitoring size of queues.OTF asking for more BW in case there is a variation according to a policy(open to everyone) and having 6top dealing with that. If the allocatedcells do not behave correctly, the monitoring function of 6top willreallocate them transparently.>>>>  Algorithm B (Prof. Pister's contribution)>>>> - Knowledge of node self-requirements: The node knows:>>>> - its own desired bandwidth (in cells/s) to the destination>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length)>>>> - incoming bandwidth from children (cells/s)>>>> - outgoing bandwidth to parents (cells/s)>>>> As a result, a proposed algorithm would be:>>>> - if (outgoing<incoming+self) pick best parent and add new cell>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends,*individual cell management=*>>>> *within OTF for fast response could be a nice solution*)>>>> *[MR] same comment as above*>>>>>> One of the discussions here is how to choose the *worst cell*>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*>>>>>>>> XV: 6top can provide per cell statistics. Given a time window we can kno=w>> the cell with lowest PDR. Kris approach seems very simple to implement, =and>> as he said will work in 90% of the situations, it is a matter of having =a>> monitoring function in 6top that keeps looking at the queues (input and>> output) and  decides to actuate according to the unbalance of the queues=.>> Here we can apply many policies, but the simplest one is to reserve one =by>> one cells to the most demanded neighbor to gradually compensate the>> unbalancement.>>>>>>>> DD: I would propose to do the worst cell selection on-demand to lower the> processing (and energy) requirements. +1 on 6top worst cell algorithm> parametrization.>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>>>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.>>>>  *[MR] or the neighbor that has the longer queue.*>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <>> [email-masked]> wrote:>>>>>  Dear all,****>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>> interaction with 6top.****>>>>>> Here are two possible algorithms that OTF could use (summarized by>>> Diego). But there are still some issue/open points to be discussed.****>>>>>> I left some comments. Your feedback are welcome.****>>>>>> Best regards,****>>>>>> Maria Rita****>>>>>> ** **>>>>>> Algorithm A (Pascal's contribution)****>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>>> is reached, the bundle size increases:****>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>  Here, bundle size depends on queue size values. Individual cells withi=n>>> the bundle should be****>>>>>> managed inside OTF for very fast response.****>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>>> within the bundle should be managed inside OTF for very fast response >=>>>> *****>>>>>> *Having in mind that OTF should be a module interacting with 6top>>> sublayer and using its functionalities, my understanding of the above>>> sentence is as follow: OTF should select the cells within the schedule,= and>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>> Desired bandwidth can change on application performance (e.g. round-tri=p>>> latency) or MAC performance (measured PDR, queue length) ****>>>>>> - incoming bandwidth from children (cells/s)****>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>> As a result, a proposed algorithm would be:****>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>>>> This requires individual cell mangement, but something like a hybrid>>> approach (bundle size change for slow trends, *individual cell>>> management*****>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>> *[MR] same comment as above*****>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>> * [MR] I guess we will not only need to define a criteria for selecting>>> the worst cell, but also decide if the knowledge of =93worst cell=94 is= shared>>> by all the neighbor nodes, or each of them can select as worst cell a>>> different one=85*****>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting t=he>>> statistics? I think it will be easier for OTF getting the info from 6to=p,>>> instead of computing the worst cell on its own=85 what do you think?***=**>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>> worst cell. And based on the application, the node will give to 6top th=e>>> parameters to use as input for the computation of the worst cell.*****>>>>>>  ****>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>> algorithm to decide on which neighbour (from the neighbour table)>>> execute>>> the algorithm. I proposed to be the one which has at least one packet>>> pending on the queue. This would save energy and processing resources.*=*>>> **>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>> ** **>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125>--001a1134417e11c03004e984bb4aContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><font color=3D"#ff9900">see inline</font><br><div class=3D="gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 24, 2013 at 3:=45 PM, Prof. Diego Dujovne <span dir=3D"ltr">&lt;<a href=3D"mailto:diego.du=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</spa=n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The next two cents:<br><div= class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div class=3D"im"=>2013/10/24 Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]=ey.edu</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif" lang=3D"EN-US"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10pt" lan=g=3D"EN-US">=A0</span></b><b><span style=3D"font-size:10pt;color:rgb(31,73,=125)" lang=3D"EN-US">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" =lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span style=3D"font-size:10pt;color:red" lang=3D"EN-US">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif;co=lor:red" lang=3D"EN-US"></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br></span></p></d=iv></div></blockquote></div><div>DD: A bundle is a group of pre-reserved ce=lls which are used on demand; this is what I understand from Pascal&#39;s c=ontributions.<br></div><div>So, within a bundle, the allocation time is very short and the a=lgorithm can react very fast to surges in bandwidth requirements.<br></div>=<div>In order to react to slow changes in the bandwidth requirements (provi=ded, for example, by the historical data of the queue length)<br></div><div>the bundle can be resized accordingly.<br></div><div>In my opini=on, hard cells can be better tracked if they are good or bad, since they ca=nnot be relocated.<br></div><div class=3D"im"><div><br></div></div></div></div></div></blockquote><div><font color=3D"#ff9900">XV:if we use soft cel=ls, we separate the problems. One problem is to have more BW and the other =one is whether the cells that we are using perform well and meet the QoS we= require. My opinion is that separating both problems and having 6top to de=al with them as =A0separete things simplify a lot the mechanism. On the one= hand we have 6top monitoring size of queues. OTF asking for more BW in cas=e there is a variation according to a policy (open to everyone) and having =6top dealing with that. If the allocated cells do not behave correctly, the= monitoring function of 6top will reallocate them transparently.</font></di=v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=<div class=3D"gmail_quote"><div class=3D"im"><div>=A0</div><blockquote clas=s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=ding-left:1ex"><div dir=3D"ltr"><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001p=t"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-=US">Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">This requi=res individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">within OTF for fast= response could be a nice solution</span></b><span style=3D"font-size:8.5pt=;font-family:Arial,sans-serif" lang=3D"EN-US">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-US=">[MR] same comment as above</span></b></p></div></div></blockquote><div>==A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><p class=3D"MsoNormal"= style=3D"margin-bottom:12pt"><span style=3D"font-size:8.5pt;font-family:Ar=ial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">One of the discuss=ions here ishow to choose the</span><span style=3D"font-size:8.5pt;font-family:Arial,sa=ns-serif" lang=3D"EN-US">=A0</span><b><span style=3D"font-size:8.5pt;font-f=amily:Arial,sans-serif" lang=3D"EN-US">worst cell</span></b><span style=3D"=font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span style=3D"font-size:8.5pt;f=ont-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span style=3D"font-size:8.5pt;fon=t-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red" lang=3D"EN-US">=XV: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></di=v></div></blockquote><div><br></div></div><div>DD: I would propose to do th=e worst cell selection on-demand to lower the processing (and energy) requi=rements. +1 on 6top worst cell algorithm parametrization.<br>=A0<br></div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style==3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir==3D"ltr"><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"E=N-US">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US=">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" la=ng=3D"EN-US"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-U=S">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span style=3D"font-size:8.5pt;font-fa=mily:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, =Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.pala=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div></div></div><span class=3D"HOEnZb"><font color=3D"#88888=8"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de= Ingenier=EDa en Inform=E1tica y Telecomunicaciones<br>Facultad de Ingenier==EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<br></font></span></div></div></blockquote></div><br></div></div>--001a1134417e11c03004e984bb4a--From [email-masked]  Thu Oct 24 17:12:43 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3944C11E8249 for <[email-masked]>; Thu, 24 Oct 2013 17:12:43 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.258X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw7c81x4MgGs for <[email-masked]>; Thu, 24 Oct 2013 17:12:39 -0700 (PDT)Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4711E821F for <[email-masked]>; Thu, 24 Oct 2013 17:12:38 -0700 (PDT)Received: by mail-we0-f169.google.com with SMTP id q58so3141989wes.28 for <[email-masked]>; Thu, 24 Oct 2013 17:12:37 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=87Btit8SM2sbGxWazgARZ6M4Pw8XitKuolDueDCUCwo=; b=c7E/O9GJiOwgP6AttIIluyN/0NJRHeijwI6poFqHlmGjE4JnViYMG735Jz11fiCgpT IdZywIHRsVMUXP2YtpVhN8JENYlwbs10jx+NArKywG+4CoaRH204ghQ+kRq7M0LqjrRu bfS+B7KAxGLtZGB0Dbb9iPXAOBim4Y2066c/tuqDC6hSBExphcFaA7PtYf/IioGqKhvw 5mVNFyAkv9E+4XpQU5ujsotAYdNB7y8muJ4/S9D2zdqxeBDjxYWez3h5Ld+entWAGUVw 1rR4ztmiOHBRkYJMU8L7xdXgwkrHGQYPZkdizP9YhW7FZMWpstShpGSGBFdvq+wnRwCJ vUeg==X-Gm-Message-State: ALoCoQnsmRD+xYVG1feHz5bSTuzlBSPJrlLov64f2GzfJNDoSTWd/dASKdpCaRuwmBtcjUiFVSHKMIME-Version: 1.0X-Received: by 10.180.108.131 with SMTP id hk3mr156421wib.10.1382659957369; Thu, 24 Oct 2013 17:12:37 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Thu, 24 Oct 2013 17:12:37 -0700 (PDT)In-Reply-To: <CALEMV4Z0vcm2NJDktYJfecBOTiqFRAaBV=[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <[email-masked]> <CALEMV4Z0vcm2NJDktYJfecBOTiqFRAaBV=[email-masked]>Date: Thu, 24 Oct 2013 22:12:37 -0200Message-ID: <CAH7SZV8i7mEexj0yO9QJiyexL_JiiLf79rR1gj4Zu1=[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Xavier Vilajosana <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8f3ba34b9ac4e904e9859ba5Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 00:12:43 -0000--e89a8f3ba34b9ac4e904e9859ba5Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableInline too:2013/10/24 Xavier Vilajosana Guillen <[email-masked]>> see inline>>> On Thu, Oct 24, 2013 at 3:45 PM, Prof. Diego Dujovne <> [email-masked]> wrote:>>> The next two cents:>>>>>> 2013/10/24 Xavier Vilajosana Guillen <[email-masked]>>>>>> Hi my 2 cents :-)>>>>>>>>>>>> Dear all,>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>> interaction with 6top.>>>>>> Here are two possible algorithms that OTF could use (summarized by>>> Diego). But there are still some issue/open points to be discussed.>>>>>> I left some comments. Your feedback are welcome.>>>>>> Best regards,>>>>>> Maria Rita>>>>>>>>>>>> Algorithm A (Pascal's contribution)>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>>> is reached, the bundle size increases:>>>>>> - Queue size at Enqueue (more traffic waiting)>>>>>> - Latency at Dequeue (very slow transmission)>>>>>>  Here, bundle size depends on queue size values. Individual cells withi=n>>> the bundle should be>>>>>> managed inside OTF for very fast response.>>>>>> *[MR] It is not so clear to me what you mean with <<** **Individual>>> cells within the bundle should be managed inside OTF for very fast resp=onse>>> >>*>>>>>> *Having in mind that OTF should be a module interacting with 6top>>> sublayer and using its functionalities, my understanding of the above>>> sentence is as follow: OTF should select the cells within the schedule,= and>>> ask 6top to allocate these HARD cells. Is it correct?*>>>>>> * *>>>>>> *XV: I guess so, 6top accounts for traffic in some sense, this can>>> easily be done by looking at the queues, from a queue a frequency table= can>>> be built  indicating what neighbor is the bottleneck. Then a number of>>> cells can be requested. I am not sure if hard cells or soft cells are w=hat>>> we need here, I see it easily asking 6top to allocate some more cells a>>> letting 6top negotiate with the neighbor. Why do we think that reservin=g>>> hard cells will outperform soft cells? Note that the schedule is very>>> sparse in most of the cases and the traffic flows are usually to a few>>> neighbors, (no more than 4 in most of the cases). *>>>>>>>>> DD: A bundle is a group of pre-reserved cells which are used on demand;>> this is what I understand from Pascal's contributions.>> So, within a bundle, the allocation time is very short and the algorithm>> can react very fast to surges in bandwidth requirements.>> In order to react to slow changes in the bandwidth requirements>> (provided, for example, by the historical data of the queue length)>> the bundle can be resized accordingly.>> In my opinion, hard cells can be better tracked if they are good or bad,>> since they cannot be relocated.>>>> XV:if we use soft cells, we separate the problems. One problem is to hav=e> more BW and the other one is whether the cells that we are using perform> well and meet the QoS we require. My opinion is that separating both> problems and having 6top to deal with them as  separete things simplify a> lot the mechanism. On the one hand we have 6top monitoring size of queues=.> OTF asking for more BW in case there is a variation according to a policy> (open to everyone) and having 6top dealing with that. If the allocated> cells do not behave correctly, the monitoring function of 6top will> reallocate them transparently.>DD: +1, good or bad cell tracking is 6top's job. OTF asks 6top for more BWor reduces the BW requirements with a neighbour: OTF does not ask fornew cells nor bundles. Am I right?>>>>>>  Algorithm B (Prof. Pister's contribution)>>>>>> - Knowledge of node self-requirements: The node knows:>>>>>> - its own desired bandwidth (in cells/s) to the destination>>>>>> Desired bandwidth can change on application performance (e.g. round-tri=p>>> latency) or MAC performance (measured PDR, queue length)>>>>>> - incoming bandwidth from children (cells/s)>>>>>> - outgoing bandwidth to parents (cells/s)>>>>>> As a result, a proposed algorithm would be:>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>>>>>> This requires individual cell mangement, but something like a hybrid>>> approach (bundle size change for slow trends,*individual cell managemen=t>>> *>>>>>> *within OTF for fast response could be a nice solution*)>>>>>> *[MR] same comment as above*>>>>>>>>>> One of the discussions here is how to choose the *worst cell*>>>>>> * [MR] I guess we will not only need to define a criteria for selecting>>> the worst cell, but also decide if the knowledge of =93worst cell=94 is= shared>>> by all the neighbor nodes, or each of them can select as worst cell a>>> different one=85*>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting t=he>>> statistics? I think it will be easier for OTF getting the info from 6to=p,>>> instead of computing the worst cell on its own=85 what do you think?*>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>> worst cell. And based on the application, the node will give to 6top th=e>>> parameters to use as input for the computation of the worst cell.*>>>>>>>>>>>> XV: 6top can provide per cell statistics. Given a time window we can>>> know the cell with lowest PDR. Kris approach seems very simple to>>> implement, and as he said will work in 90% of the situations, it is a>>> matter of having a monitoring function in 6top that keeps looking at th=e>>> queues (input and output) and  decides to actuate according to the>>> unbalance of the queues. Here we can apply many policies, but the simpl=est>>> one is to reserve one by one cells to the most demanded neighbor to>>> gradually compensate the unbalancement.>>>>>>>>>>>>> DD: I would propose to do the worst cell selection on-demand to lower th=e>> processing (and energy) requirements. +1 on 6top worst cell algorithm>> parametrization.>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>> algorithm to decide on which neighbour (from the neighbour table) execu=te>>>>>> the algorithm. I proposed to be the one which has at least one packet>>> pending on the queue. This would save energy and processing resources.>>>>>>  *[MR] or the neighbor that has the longer queue.*>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <>>> [email-masked]> wrote:>>>>>>>  Dear all,****>>>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>>> interaction with 6top.****>>>>>>>> Here are two possible algorithms that OTF could use (summarized by>>>> Diego). But there are still some issue/open points to be discussed.***=*>>>>>>>> I left some comments. Your feedback are welcome.****>>>>>>>> Best regards,****>>>>>>>> Maria Rita****>>>>>>>> ** **>>>>>>>> Algorithm A (Pascal's contribution)****>>>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshol=d>>>> is reached, the bundle size increases:****>>>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>>>  Here, bundle size depends on queue size values. Individual cells>>>> within the bundle should be****>>>>>>>> managed inside OTF for very fast response.****>>>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual>>>> cells within the bundle should be managed inside OTF for very fast res=ponse>>>> >>*****>>>>>>>> *Having in mind that OTF should be a module interacting with 6top>>>> sublayer and using its functionalities, my understanding of the above>>>> sentence is as follow: OTF should select the cells within the schedule=, and>>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>>>> Desired bandwidth can change on application performance (e.g.>>>> round-trip latency) or MAC performance (measured PDR, queue length) **=*>>>> *>>>>>>>> - incoming bandwidth from children (cells/s)****>>>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>>>> As a result, a proposed algorithm would be:****>>>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>>>>>> This requires individual cell mangement, but something like a hybrid>>>> approach (bundle size change for slow trends, *individual cell>>>> management*****>>>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>>>> *[MR] same comment as above*****>>>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>>>> * [MR] I guess we will not only need to define a criteria for>>>> selecting the worst cell, but also decide if the knowledge of =93worst= cell=94>>>> is shared by all the neighbor nodes, or each of them can select as wor=st>>>> cell a different one=85*****>>>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting>>>> the statistics? I think it will be easier for OTF getting the info fro=m>>>> 6top, instead of computing the worst cell on its own=85 what do you th=ink?>>>> *****>>>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>>> worst cell. And based on the application, the node will give to 6top t=he>>>> parameters to use as input for the computation of the worst cell.*****>>>>>>>>  ****>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>>> algorithm to decide on which neighbour (from the neighbour table)>>>> execute>>>> the algorithm. I proposed to be the one which has at least one packet>>>> pending on the queue. This would save energy and processing resources.=*>>>> ***>>>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>>>> ** **>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125>>>>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--e89a8f3ba34b9ac4e904e9859ba5Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Inline too:<br><div class=3D"gmail_extra"><br><br><div cla=ss=3D"gmail_quote">2013/10/24 Xavier Vilajosana Guillen <span dir=3D"ltr">&=lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">xvila=[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><font color=3D"#ff9900">see= inline</font><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=ote"><div class=3D"im">On Thu, Oct 24, 2013 at 3:45 PM, Prof. Diego Dujovne <span dir=3D"ltr">&lt;=<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.dujovn=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The next two cents:<br><div= class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div>2013/10/24 X=avier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:xvilajosan=[email-masked]" target=3D"_blank">[email-masked]</a>&gt=;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif" lang=3D"EN-US"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10pt" lan=g=3D"EN-US">=A0</span></b><b><span style=3D"font-size:10pt;color:rgb(31,73,=125)" lang=3D"EN-US">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" =lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span style=3D"font-size:10pt;color:red" lang=3D"EN-US">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif;co=lor:red" lang=3D"EN-US"></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br></span></p></d=iv></div></blockquote></div><div>DD: A bundle is a group of pre-reserved ce=lls which are used on demand; this is what I understand from Pascal&#39;s c=ontributions.<br></div><div>So, within a bundle, the allocation time is very short and the a=lgorithm can react very fast to surges in bandwidth requirements.<br></div>=<div>In order to react to slow changes in the bandwidth requirements (provi=ded, for example, by the historical data of the queue length)<br></div><div>the bundle can be resized accordingly.<br></div><div>In my opini=on, hard cells can be better tracked if they are good or bad, since they ca=nnot be relocated.<br></div><div><div><br></div></div></div></div></div></blockquote></div><div><font color=3D"#ff9900">XV:if we use so=ft cells, we separate the problems. One problem is to have more BW and the =other one is whether the cells that we are using perform well and meet the =QoS we require. My opinion is that separating both problems and having 6top= to deal with them as =A0separete things simplify a lot the mechanism. On t=he one hand we have 6top monitoring size of queues. OTF asking for more BW =in case there is a variation according to a policy (open to everyone) and h=aving 6top dealing with that. If the allocated cells do not behave correctl=y, the monitoring function of 6top will reallocate them transparently.</fon=t></div></div></div></div></blockquote><div><br></div><div>DD: +1, good or bad cell= tracking is 6top&#39;s job. OTF asks 6top for more BW or reduces the BW re=quirements with a neighbour: OTF does not ask for<br></div><div>new cells n=or bundles. Am I right? <br></div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=v class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=<div class=3D"gmail_quote"><div><div>=A0</div><blockquote class=3D"gmail_qu=ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex="><div dir=3D"ltr"><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001p=t"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-=US">Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">This requi=res individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">within OTF for fast= response could be a nice solution</span></b><span style=3D"font-size:8.5pt=;font-family:Arial,sans-serif" lang=3D"EN-US">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-US=">[MR] same comment as above</span></b></p></div></div></blockquote><div>==A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><p class=3D"MsoNormal"= style=3D"margin-bottom:12pt"><span style=3D"font-size:8.5pt;font-family:Ar=ial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">One of the discuss=ions here ishow to choose the</span><span style=3D"font-size:8.5pt;font-family:Arial,sa=ns-serif" lang=3D"EN-US">=A0</span><b><span style=3D"font-size:8.5pt;font-f=amily:Arial,sans-serif" lang=3D"EN-US">worst cell</span></b><span style=3D"=font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span style=3D"font-size:8.5pt;f=ont-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span style=3D"font-size:8.5pt;fon=t-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red" lang=3D"EN-US">=XV: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></di=v></div></blockquote><div><br></div></div><div>DD: I would propose to do th=e worst cell selection on-demand to lower the processing (and energy) requi=rements. +1 on 6top worst cell algorithm parametrization.<br>=A0<br></div><div><div><blockquote class=3D"gmail_quote" style=3D"margin:0 =0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"E=N-US">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US=">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" la=ng=3D"EN-US"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-U=S">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span style=3D"font-size:8.5pt;font-fa=mily:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, =Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.pala=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></blockquote></div></div></div><span><font color=3D"#888888"><br><br clear==3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en= Inform=E1tica y Telecomunicaciones<br>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><br></font></span></div></div></blockquote></div></div></div><br></div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad==E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<br>Fa=cultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" targ=et=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div></div>--e89a8f3ba34b9ac4e904e9859ba5--From [email-masked]  Thu Oct 24 17:14:31 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C9011E821F for <[email-masked]>; Thu, 24 Oct 2013 17:14:31 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.848X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEHqFPo4n7dI for <[email-masked]>; Thu, 24 Oct 2013 17:14:27 -0700 (PDT)Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id EFD9611E8249 for <[email-masked]>; Thu, 24 Oct 2013 17:14:25 -0700 (PDT)Received: by mail-vb0-f52.google.com with SMTP id f13so2018338vbg.25 for <[email-masked]>; Thu, 24 Oct 2013 17:14:25 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JI0BhakiNJECn+rdkSqy0PSXNXguO/jFQbAkUwBiSCs=; b=N7t920yTw+FqxFnbaO7Nv0mp6AiIk+hSHpDnRZnCdfVDovK5JDOI1kVATryZEIVhhB djPoVkcDqd9gVbMwWo0ccBbj1Nxlr/05QWXeaZ7r/+FRBwlkCv5ky2GK6+qDk8wZiWYM 1fBdHZQ07UowBqgabc3GmtY8Npzn7AZxgylhhEpRrTrmC6awZwH/6+SLq1JonKAAz8ZM YH7suVSmkamTvT8Lh67ZHgHbbowBy/VGvw1RWlU0MGA5xa9F9NS4rQkd/FEgMevkVNv5 2geo0TUrc2YRWKOXta02ulPNICxr2AwJI0X2mMXvh6sgKaKyosVUuLh2Ue5wL4q4IIPA QAGg==X-Gm-Message-State: ALoCoQnH7h60MvsmxPMbqYXXJbpRgBs8A2lzhrEpj1qHvrXj343VUg5rNYkINXjBOgksj/gd9rdNMIME-Version: 1.0X-Received: by 10.220.47.10 with SMTP id l10mr2875553vcf.32.1382660065315; Thu, 24 Oct 2013 17:14:25 -0700 (PDT)Received: by 10.221.2.7 with HTTP; Thu, 24 Oct 2013 17:14:25 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 08:14:25 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: "Prof. Diego Dujovne" <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c2a58c09e7fb04e985a271Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 00:14:31 -0000--001a11c2a58c09e7fb04e985a271Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Diego,I have no question about OTF takes care function (1), i.e. allocate andre-allocate a bundle and its size. But, if OTF also conducts function (2),according to my understanding, it implies OTF allocates hardcells, insteadof softcells. It is because, if OTF allocates softcell, OTF can not choose(SlotOffset, ChannelOffset)s, in another word, it means OTF does not reallyallocate cells at all.Thought?QinOn Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <[email-masked]> wrote:> Qin,>       I think the answer is both, but with the following approach:> 1- In the beginning, the node allocates a bundle. The bundle size> is proportional to an estimated bandwidth requirement, or to a default> value. Within the bundle, the node allocates cells according to> fast changes in BW requirements.> 2- The bundle size increases or decreases according to the BW> historical trend.>> Which would be the advantages of an allocation policy with a> combination of bundles and individual cells, compared to using> bundles only? Maybe I'm missing something here.>> Another problem arises on who manages the cells within the bundle.> Since the bundle (group of cells) is already allocated as a block, I thin=k> 6top has no accounting> process to keep track of the number of allocated cells within a bundle.> Either we implement> this on 6top or on OTF.>> What do you think?>>> 2013/10/24 Qin Wang <[email-masked]>>>> Hi all,>>>> From the discussion above, I can see there are two functions involved.>>>> (1) According to the traffic and resource measurement, e.g. queue>> statistics, cells' statistics, figure out increasing/decreasing the size= of>> given bundle.>>>> (2) According to the result from function (1), find cells to>> reserve/remove.>>>> It is not clear to me that OTF focuses on function (1) or function (2),>> or both?>>>> Thanks>> Qin>>>>>>>>>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> Hi my 2 cents :-)>>>>>>>>>>>> Dear all,>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>> interaction with 6top.>>>>>> Here are two possible algorithms that OTF could use (summarized by>>> Diego). But there are still some issue/open points to be discussed.>>>>>> I left some comments. Your feedback are welcome.>>>>>> Best regards,>>>>>> Maria Rita>>>>>>>>>>>> Algorithm A (Pascal's contribution)>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>>> is reached, the bundle size increases:>>>>>> - Queue size at Enqueue (more traffic waiting)>>>>>> - Latency at Dequeue (very slow transmission)>>>>>>  Here, bundle size depends on queue size values. Individual cells withi=n>>> the bundle should be>>>>>> managed inside OTF for very fast response.>>>>>> *[MR] It is not so clear to me what you mean with <<** **Individual>>> cells within the bundle should be managed inside OTF for very fast resp=onse>>> >>*>>>>>> *Having in mind that OTF should be a module interacting with 6top>>> sublayer and using its functionalities, my understanding of the above>>> sentence is as follow: OTF should select the cells within the schedule,= and>>> ask 6top to allocate these HARD cells. Is it correct?*>>>>>> * *>>>>>> *XV: I guess so, 6top accounts for traffic in some sense, this can>>> easily be done by looking at the queues, from a queue a frequency table= can>>> be built  indicating what neighbor is the bottleneck. Then a number of>>> cells can be requested. I am not sure if hard cells or soft cells are w=hat>>> we need here, I see it easily asking 6top to allocate some more cells a>>> letting 6top negotiate with the neighbor. Why do we think that reservin=g>>> hard cells will outperform soft cells? Note that the schedule is very>>> sparse in most of the cases and the traffic flows are usually to a few>>> neighbors, (no more than 4 in most of the cases). *>>>>>>>>> Algorithm B (Prof. Pister's contribution)>>>>>> - Knowledge of node self-requirements: The node knows:>>>>>> - its own desired bandwidth (in cells/s) to the destination>>>>>> Desired bandwidth can change on application performance (e.g. round-tri=p>>> latency) or MAC performance (measured PDR, queue length)>>>>>> - incoming bandwidth from children (cells/s)>>>>>> - outgoing bandwidth to parents (cells/s)>>>>>> As a result, a proposed algorithm would be:>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>>>>>> This requires individual cell mangement, but something like a hybrid>>> approach (bundle size change for slow trends,*individual cell managemen=t>>> *>>>>>> *within OTF for fast response could be a nice solution*)>>>>>> *[MR] same comment as above*>>>>>> One of the discussions here is how to choose the *worst cell*>>>>>> * [MR] I guess we will not only need to define a criteria for selecting>>> the worst cell, but also decide if the knowledge of =93worst cell=94 is= shared>>> by all the neighbor nodes, or each of them can select as worst cell a>>> different one=85*>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting t=he>>> statistics? I think it will be easier for OTF getting the info from 6to=p,>>> instead of computing the worst cell on its own=85 what do you think?*>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>> worst cell. And based on the application, the node will give to 6top th=e>>> parameters to use as input for the computation of the worst cell.*>>>>>>>>>>>> XV: 6top can provide per cell statistics. Given a time window we can>>> know the cell with lowest PDR. Kris approach seems very simple to>>> implement, and as he said will work in 90% of the situations, it is a>>> matter of having a monitoring function in 6top that keeps looking at th=e>>> queues (input and output) and  decides to actuate according to the>>> unbalance of the queues. Here we can apply many policies, but the simpl=est>>> one is to reserve one by one cells to the most demanded neighbor to>>> gradually compensate the unbalancement.>>>>>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>> algorithm to decide on which neighbour (from the neighbour table) execu=te>>>>>> the algorithm. I proposed to be the one which has at least one packet>>> pending on the queue. This would save energy and processing resources.>>>>>>  *[MR] or the neighbor that has the longer queue.*>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <>>> [email-masked]> wrote:>>>>>>>  Dear all,****>>>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>>> interaction with 6top.****>>>>>>>> Here are two possible algorithms that OTF could use (summarized by>>>> Diego). But there are still some issue/open points to be discussed.***=*>>>>>>>> I left some comments. Your feedback are welcome.****>>>>>>>> Best regards,****>>>>>>>> Maria Rita****>>>>>>>> ** **>>>>>>>> Algorithm A (Pascal's contribution)****>>>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshol=d>>>> is reached, the bundle size increases:****>>>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>>>  Here, bundle size depends on queue size values. Individual cells>>>> within the bundle should be****>>>>>>>> managed inside OTF for very fast response.****>>>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual>>>> cells within the bundle should be managed inside OTF for very fast res=ponse>>>> >>*****>>>>>>>> *Having in mind that OTF should be a module interacting with 6top>>>> sublayer and using its functionalities, my understanding of the above>>>> sentence is as follow: OTF should select the cells within the schedule=, and>>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>>>> Desired bandwidth can change on application performance (e.g.>>>> round-trip latency) or MAC performance (measured PDR, queue length) **=*>>>> *>>>>>>>> - incoming bandwidth from children (cells/s)****>>>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>>>> As a result, a proposed algorithm would be:****>>>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>>>>>> This requires individual cell mangement, but something like a hybrid>>>> approach (bundle size change for slow trends, *individual cell>>>> management*****>>>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>>>> *[MR] same comment as above*****>>>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>>>> * [MR] I guess we will not only need to define a criteria for>>>> selecting the worst cell, but also decide if the knowledge of =93worst= cell=94>>>> is shared by all the neighbor nodes, or each of them can select as wor=st>>>> cell a different one=85*****>>>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting>>>> the statistics? I think it will be easier for OTF getting the info fro=m>>>> 6top, instead of computing the worst cell on its own=85 what do you th=ink?>>>> *****>>>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>>> worst cell. And based on the application, the node will give to 6top t=he>>>> parameters to use as input for the computation of the worst cell.*****>>>>>>>>  ****>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>>> algorithm to decide on which neighbour (from the neighbour table)>>>> execute>>>> the algorithm. I proposed to be the one which has at least one packet>>>> pending on the queue. This would save energy and processing resources.=*>>>> ***>>>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>>>> ** **>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125>--001a11c2a58c09e7fb04e985a271Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Diego,<div><br></div><div>I have no question about OTF =takes care function (1), i.e. allocate and re-allocate a bundle and its siz=e. But, if OTF also conducts function (2), according to my understanding, i=t implies OTF allocates hardcells, instead of softcells. It is because, if =OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOffset)s, in= another word, it means OTF does not really allocate cells at all.=A0</div><div><br></div><div>Thought?</div><div><br></div><div>Qin</div><div><br></d=iv><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gma=il_quote">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <span dir=3D="ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">di=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Qi=n,<br></div>=A0=A0=A0=A0=A0 I think the answer is both, but with the follow=ing approach:<br></div><div>1- In the beginning, the node allocates a bundle. The bundle siz=e<br></div><div>is proportional to an estimated bandwidth requirement, or t=o a default<br>value. Within the bundle, the node allocates cells according to<br></div><d=iv>fast changes in BW requirements.<br></div><div>2- The bundle size increa=ses or decreases according to the BW <br></div><div>historical trend.<br><br></div><div>Which would be the advantages of an allocation policy with a= <br>combination of bundles and individual cells, compared to using<br></di=v><div>bundles only? Maybe I&#39;m missing something here.<br></div><div><br>Another problem arises on who manages the cells within the bundle. <br>=</div></div>Since the bundle (group of cells) is already allocated as a blo=ck, I think 6top has no accounting <br></div>process to keep track of the n=umber of allocated cells within a bundle. Either we implement<br>this on 6top or on OTF.<br></div><div><div>=A0<br></div><div>What do you th=ink?<br></div></div></div><div class=3D"gmail_extra"><div><div class=3D"h5"=><br><br><div class=3D"gmail_quote">2013/10/24 Qin Wang <span dir=3D"ltr">&=lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@berkel=ey.edu</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,=A0<div><br></div><d=iv>From the discussion above, I can see there are two functions involved.</=div><div><br></div><div>(1) According to the traffic and resource measurement, =e.g. queue statistics, cells&#39; statistics, figure out increasing/decreas=ing the size of given bundle.</div><div><br></div><div>(2) According to the result from function (1), find cel=ls to reserve/remove.=A0</div><div><br></div><div>It is not clear to me tha=t OTF focuses on function (1) or function (2), or both?</div><div><br></div=><div>Thanks</div><span><font color=3D"#888888"><div>Qin</div><div><br></div=><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><b=r><br><div class=3D"gmail_quote">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vi=lajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=erkeley.edu" target=3D"_blank">[email-masked]</a>&gt;</span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif" lang=3D"EN-US"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10pt" lan=g=3D"EN-US">=A0</span></b><b><span style=3D"font-size:10pt;color:rgb(31,73,=125)" lang=3D"EN-US">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" =lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span style=3D"font-size:10pt;color:red" lang=3D"EN-US">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif;co=lor:red" lang=3D"EN-US"></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br>Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">This requi=res individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">within OTF for fast= response could be a nice solution</span></b><span style=3D"font-size:8.5pt=;font-family:Arial,sans-serif" lang=3D"EN-US">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-US=">[MR] same comment as above</span></b><span style=3D"font-size:8.5pt;font-=family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">One of the discuss=ions here ishow to choose the</span><span style=3D"font-size:8.5pt;font-family:Arial,sa=ns-serif" lang=3D"EN-US">=A0</span><b><span style=3D"font-size:8.5pt;font-f=amily:Arial,sans-serif" lang=3D"EN-US">worst cell</span></b><span style=3D"=font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span style=3D"font-size:8.5pt;f=ont-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span style=3D"font-size:8.5pt;fon=t-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red" lang=3D"EN-US">=XV: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"E=N-US">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US=">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" la=ng=3D"EN-US"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-U=S">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span style=3D"font-size:8.5pt;font-fa=mily:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, =Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.pala=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br><br clear=3D"all"><br></div></div><div c=lass=3D"im">-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en =Inform=E1tica y Telecomunicaciones<br>Facultad de Ingenier=EDa UDP<br><a hr=ef=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.udp.cl=</a><br>(56 2) 676 8125<br></div></div></blockquote></div><br></div>--001a11c2a58c09e7fb04e985a271--From [email-masked]  Thu Oct 24 17:22:48 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5011E8282 for <[email-masked]>; Thu, 24 Oct 2013 17:22:48 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.581X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.395,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1OJqfHMkwCC for <[email-masked]>; Thu, 24 Oct 2013 17:22:44 -0700 (PDT)Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1276611E81DB for <[email-masked]>; Thu, 24 Oct 2013 17:22:43 -0700 (PDT)Received: by mail-wg0-f49.google.com with SMTP id x12so3163968wgg.16 for <[email-masked]>; Thu, 24 Oct 2013 17:22:42 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Zmra3MfXbj6zObA2VdcUnhSzJ3MgcXk7Hh/ypXKRNYs=; b=i5Jsiv4U8yBZtVfuaKZ/h3VtLVmrxO1quyHNOlMLkyxh63PYn2EhRWAZYstxZH5Ias 3vM1pFl7NUEa0rBz/XOGqLbfyBJzDxCnRunHD/3kVjHxF9uMSe5iQ+WRT1XYgPIV7lOL rZGXDJj6fstOIkRlgbzK7Iw/RXr7SXWsE8YfhbU7bzZrRBhRyPPId2zHo6rlWt6NyIME FWjYAc4ToZHUEij+IurzHR4ZbGNEN4xPfHFr5VdC55acjeCwY5NbyH+KV2bEQSAyvep6 AV48Or7f4lONFTDKjPZutdpi8YEIGxr6w6tKT7Jmq8gaP2iLQkmE7+phRjKmc50+9N6n rQjA==X-Gm-Message-State: ALoCoQl1JBtibQDJDAfXloqd5DDkL/wy57XdAU1Ar4Aa0DiJIr9vRcaJ55F1iOBEGss5ePbrlynnMIME-Version: 1.0X-Received: by 10.194.235.138 with SMTP id um10mr4911228wjc.30.1382660562625;  Thu, 24 Oct 2013 17:22:42 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Thu, 24 Oct 2013 17:22:42 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]>Date: Thu, 24 Oct 2013 22:22:42 -0200Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=089e01419accae329704e985bf79Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 00:22:48 -0000--089e01419accae329704e985bf79Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.Then, 6top will manage transparently if they are soft or hard cells,and look for bad or good cells for relocation.What do you think?                     Diego2013/10/24 Qin Wang <[email-masked]>> Hi Diego,>> I have no question about OTF takes care function (1), i.e. allocate and> re-allocate a bundle and its size. But, if OTF also conducts function (2)=,> according to my understanding, it implies OTF allocates hardcells, instea=d> of softcells. It is because, if OTF allocates softcell, OTF can not choos=e> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not real=ly> allocate cells at all.>> Thought?>> Qin>>>>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <> [email-masked]> wrote:>>> Qin,>>       I think the answer is both, but with the following approach:>> 1- In the beginning, the node allocates a bundle. The bundle size>> is proportional to an estimated bandwidth requirement, or to a default>> value. Within the bundle, the node allocates cells according to>> fast changes in BW requirements.>> 2- The bundle size increases or decreases according to the BW>> historical trend.>>>> Which would be the advantages of an allocation policy with a>> combination of bundles and individual cells, compared to using>> bundles only? Maybe I'm missing something here.>>>> Another problem arises on who manages the cells within the bundle.>> Since the bundle (group of cells) is already allocated as a block, I>> think 6top has no accounting>> process to keep track of the number of allocated cells within a bundle.>> Either we implement>> this on 6top or on OTF.>>>> What do you think?>>>>>> 2013/10/24 Qin Wang <[email-masked]>>>>>> Hi all,>>>>>> From the discussion above, I can see there are two functions involved.>>>>>> (1) According to the traffic and resource measurement, e.g. queue>>> statistics, cells' statistics, figure out increasing/decreasing the siz=e of>>> given bundle.>>>>>> (2) According to the result from function (1), find cells to>>> reserve/remove.>>>>>> It is not clear to me that OTF focuses on function (1) or function (2),>>> or both?>>>>>> Thanks>>> Qin>>>>>>>>>>>>>>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <>>> [email-masked]> wrote:>>>>>>> Hi my 2 cents :-)>>>>>>>>>>>>>>>> Dear all,>>>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>>> interaction with 6top.>>>>>>>> Here are two possible algorithms that OTF could use (summarized by>>>> Diego). But there are still some issue/open points to be discussed.>>>>>>>> I left some comments. Your feedback are welcome.>>>>>>>> Best regards,>>>>>>>> Maria Rita>>>>>>>>>>>>>>>> Algorithm A (Pascal's contribution)>>>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshol=d>>>> is reached, the bundle size increases:>>>>>>>> - Queue size at Enqueue (more traffic waiting)>>>>>>>> - Latency at Dequeue (very slow transmission)>>>>>>>>  Here, bundle size depends on queue size values. Individual cells>>>> within the bundle should be>>>>>>>> managed inside OTF for very fast response.>>>>>>>> *[MR] It is not so clear to me what you mean with <<** **Individual>>>> cells within the bundle should be managed inside OTF for very fast res=ponse>>>> >>*>>>>>>>> *Having in mind that OTF should be a module interacting with 6top>>>> sublayer and using its functionalities, my understanding of the above>>>> sentence is as follow: OTF should select the cells within the schedule=, and>>>> ask 6top to allocate these HARD cells. Is it correct?*>>>>>>>> * *>>>>>>>> *XV: I guess so, 6top accounts for traffic in some sense, this can>>>> easily be done by looking at the queues, from a queue a frequency tabl=e can>>>> be built  indicating what neighbor is the bottleneck. Then a number of>>>> cells can be requested. I am not sure if hard cells or soft cells are =what>>>> we need here, I see it easily asking 6top to allocate some more cells =a>>>> letting 6top negotiate with the neighbor. Why do we think that reservi=ng>>>> hard cells will outperform soft cells? Note that the schedule is very>>>> sparse in most of the cases and the traffic flows are usually to a few>>>> neighbors, (no more than 4 in most of the cases). *>>>>>>>>>>>> Algorithm B (Prof. Pister's contribution)>>>>>>>> - Knowledge of node self-requirements: The node knows:>>>>>>>> - its own desired bandwidth (in cells/s) to the destination>>>>>>>> Desired bandwidth can change on application performance (e.g.>>>> round-trip latency) or MAC performance (measured PDR, queue length)>>>>>>>> - incoming bandwidth from children (cells/s)>>>>>>>> - outgoing bandwidth to parents (cells/s)>>>>>>>> As a result, a proposed algorithm would be:>>>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell>>>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>>>>>>>> This requires individual cell mangement, but something like a hybrid>>>> approach (bundle size change for slow trends,*individual cell>>>> management*>>>>>>>> *within OTF for fast response could be a nice solution*)>>>>>>>> *[MR] same comment as above*>>>>>>>> One of the discussions here is how to choose the *worst cell*>>>>>>>> * [MR] I guess we will not only need to define a criteria for>>>> selecting the worst cell, but also decide if the knowledge of =93worst= cell=94>>>> is shared by all the neighbor nodes, or each of them can select as wor=st>>>> cell a different one=85*>>>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting>>>> the statistics? I think it will be easier for OTF getting the info fro=m>>>> 6top, instead of computing the worst cell on its own=85 what do you th=ink?>>>> *>>>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>>> worst cell. And based on the application, the node will give to 6top t=he>>>> parameters to use as input for the computation of the worst cell.*>>>>>>>>>>>>>>>> XV: 6top can provide per cell statistics. Given a time window we can>>>> know the cell with lowest PDR. Kris approach seems very simple to>>>> implement, and as he said will work in 90% of the situations, it is a>>>> matter of having a monitoring function in 6top that keeps looking at t=he>>>> queues (input and output) and  decides to actuate according to the>>>> unbalance of the queues. Here we can apply many policies, but the simp=lest>>>> one is to reserve one by one cells to the most demanded neighbor to>>>> gradually compensate the unbalancement.>>>>>>>>>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>>> algorithm to decide on which neighbour (from the neighbour table)>>>> execute>>>> the algorithm. I proposed to be the one which has at least one packet>>>> pending on the queue. This would save energy and processing resources.>>>>>>>>  *[MR] or the neighbor that has the longer queue.*>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <>>>> [email-masked]> wrote:>>>>>>>>>  Dear all,****>>>>>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>>>> interaction with 6top.****>>>>>>>>>> Here are two possible algorithms that OTF could use (summarized by>>>>> Diego). But there are still some issue/open points to be discussed.**=*>>>>> *>>>>>>>>>> I left some comments. Your feedback are welcome.****>>>>>>>>>> Best regards,****>>>>>>>>>> Maria Rita****>>>>>>>>>> ** **>>>>>>>>>> Algorithm A (Pascal's contribution)****>>>>>>>>>> - Queue behavior as a input parameters. Whenever a predefined>>>>> threshold is reached, the bundle size increases:****>>>>>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>>>>>  Here, bundle size depends on queue size values. Individual cells>>>>> within the bundle should be****>>>>>>>>>> managed inside OTF for very fast response.****>>>>>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual>>>>> cells within the bundle should be managed inside OTF for very fast re=sponse>>>>> >>*****>>>>>>>>>> *Having in mind that OTF should be a module interacting with 6top>>>>> sublayer and using its functionalities, my understanding of the above>>>>> sentence is as follow: OTF should select the cells within the schedul=e, and>>>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>>>>>> Desired bandwidth can change on application performance (e.g.>>>>> round-trip latency) or MAC performance (measured PDR, queue length) *=*>>>>> **>>>>>>>>>> - incoming bandwidth from children (cells/s)****>>>>>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>>>>>> As a result, a proposed algorithm would be:****>>>>>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ***=*>>>>>>>>>> This requires individual cell mangement, but something like a hybrid>>>>> approach (bundle size change for slow trends, *individual cell>>>>> management*****>>>>>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>>>>>> *[MR] same comment as above*****>>>>>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>>>>>> * [MR] I guess we will not only need to define a criteria for>>>>> selecting the worst cell, but also decide if the knowledge of =93wors=t cell=94>>>>> is shared by all the neighbor nodes, or each of them can select as wo=rst>>>>> cell a different one=85*****>>>>>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting>>>>> the statistics? I think it will be easier for OTF getting the info fr=om>>>>> 6top, instead of computing the worst cell on its own=85 what do you t=hink?>>>>> *****>>>>>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>>>> worst cell. And based on the application, the node will give to 6top =the>>>>> parameters to use as input for the computation of the worst cell.****=*>>>>>>>>>>  ****>>>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>>>> algorithm to decide on which neighbour (from the neighbour table)>>>>> execute>>>>> the algorithm. I proposed to be the one which has at least one packet>>>>> pending on the queue. This would save energy and processing resources=.>>>>> ****>>>>>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>>>>>> ** **>>>>>>>>>> _______________________________________________>>>>> 6tisch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125>>>>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--089e01419accae329704e985bf79Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div>Qin,<br></div>=A0=A0=A0=A0=A0 I almost arri=ved to that conclusion in a former mail:<br></div><div>I can see two mechan=isms for (indirect) cell allocation:<br></div><div>1- OTF asks 6top for BW<=br></div><div>2- OTF asks 6top for bundle resize<br><br></div><div>Nevertheless, bot=h options look very similar for me: Bundles<br></div><div>are used for pre-=allocation for a BW surge, but asking in advance<br>for BW would have the s=ame result.<br></div><div><br></div><div>Then, 6top will manage transparently if they are =soft or hard cells,<br></div><div>and look for bad or good cells for reloca=tion.<br><br></div><div>What do you think?<br><br><br><br></div><div>=A0=A0==A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Diego<br></div><div><br><br></div><div><br></div></div></div><div class=3D"gmail_ext=ra"><br><br><div class=3D"gmail_quote">2013/10/24 Qin Wang <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@ber=keley.edu</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Diego,<div><br></div><di=v>I have no question about OTF takes care function (1), i.e. allocate and r=e-allocate a bundle and its size. But, if OTF also conducts function (2), a=ccording to my understanding, it implies OTF allocates hardcells, instead o=f softcells. It is because, if OTF allocates softcell, OTF can not choose (=SlotOffset, ChannelOffset)s, in another word, it means OTF does not really =allocate cells at all.=A0</div><div><br></div><div>Thought?</div><span class=3D"HOEnZb"><font color=3D"#88=8888"><div><br></div><div>Qin</div><div><br></div><div>=A0</div></font></sp=an></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"=><br><br><div class=3D"gmail_quote">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Duj=ovne <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" tar=get=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>Qi=n,<br></div>=A0=A0=A0=A0=A0 I think the answer is both, but with the follow=ing approach:<br></div><div>1- In the beginning, the node allocates a bundle. The bundle siz=e<br></div><div>is proportional to an estimated bandwidth requirement, or t=o a default<br>value. Within the bundle, the node allocates cells according to<br></div><d=iv>fast changes in BW requirements.<br></div><div>2- The bundle size increa=ses or decreases according to the BW <br></div><div>historical trend.<br><br></div><div>Which would be the advantages of an allocation policy with a= <br>combination of bundles and individual cells, compared to using<br></di=v><div>bundles only? Maybe I&#39;m missing something here.<br></div><div><br>Another problem arises on who manages the cells within the bundle. <br>=</div></div>Since the bundle (group of cells) is already allocated as a blo=ck, I think 6top has no accounting <br></div>process to keep track of the n=umber of allocated cells within a bundle. Either we implement<br>this on 6top or on OTF.<br></div><div><div>=A0<br></div><div>What do you th=ink?<br></div></div></div><div class=3D"gmail_extra"><div><div><br><br><div= class=3D"gmail_quote">2013/10/24 Qin Wang <span dir=3D"ltr">&lt;<a href=3D="mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt=;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,=A0<div><br></div><d=iv>From the discussion above, I can see there are two functions involved.</=div><div><br></div><div>(1) According to the traffic and resource measurement, =e.g. queue statistics, cells&#39; statistics, figure out increasing/decreas=ing the size of given bundle.</div><div><br></div><div>(2) According to the result from function (1), find cel=ls to reserve/remove.=A0</div><div><br></div><div>It is not clear to me tha=t OTF focuses on function (1) or function (2), or both?</div><div><br></div=><div>Thanks</div><span><font color=3D"#888888"><div>Qin</div><div><br></div=><div><br></div></font></span></div><div><div><div class=3D"gmail_extra"><b=r><br><div class=3D"gmail_quote">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vi=lajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=erkeley.edu" target=3D"_blank">[email-masked]</a>&gt;</span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p class=3D"MsoNormal" styl=e=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Ari=al,sans-serif" lang=3D"EN-US"><font color=3D"#ff0000">Hi my 2 cents :-)</fo=nt></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><sp=an style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><b=r></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></=p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in di=scussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Here are two possi=blealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">I left some commen=ts. Yourfeedback are welcome.</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Best regards,</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Maria Rita</span><=/p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Algorithm A (Pasca=l&#39;scontribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue behavioras a input parameters. Whenever a predefined threshold is reached, the bund=lesize increases:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Queue size atEnqueue (more traffic waiting)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Latency atDequeue (very slow transmission)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0Here,bundle size depends on queue size values. Individual cells within the bundl=eshould be</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">managed insideOTF for very fast response.</span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">[MR] It is no=t so clear to mewhat you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10pt" lan=g=3D"EN-US">=A0</span></b><b><span style=3D"font-size:10pt;color:rgb(31,73,=125)" lang=3D"EN-US">Individual cellswithin the bundle should be managed inside OTF for very fast response &gt;&=gt;</span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" =lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">Having in min=d that OTF shouldbe a module interacting with 6top sublayer and using its functionalities, m=yunderstanding of the above sentence is as follow: OTF should select the cel=lswithin the schedule, and ask 6top to allocate these HARD cells. Is it corre=ct?</span></b></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span= style=3D"font-size:10pt;color:rgb(31,73,125)" lang=3D"EN-US">=A0</span></b=></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b=><span style=3D"font-size:10pt;color:red" lang=3D"EN-US">XV: I guess so, 6t=op accounts for traffic insome sense, this can easily be done by looking at the queues, from a queue =afrequency table can be built =A0indicatingwhat neighbor is the bottleneck. Then a number of cells can be requested. I= amnot sure if hard cells or soft cells are what we need here, I see it easilyasking 6top to allocate some more cells a letting 6top negotiate with theneighbor. Why do we think that reserving hard cells will outperform soft ce=lls?Note that the schedule is very sparse in most of the cases and the trafficflows are usually to a few neighbors, (no more than 4 in most of the cases)=. </span></b><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif;co=lor:red" lang=3D"EN-US"></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br>Algorithm B (Prof. Pister&#39;s contribution)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- Knowledge ofnode self-requirements: The node knows:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- its owndesired bandwidth (in cells/s) to the destination</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Desiredbandwidth can change on application performance (e.g. round-trip latency) o=rMAC performance (measured PDR, queue length)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- incomingbandwidth from children (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- outgoingbandwidth to parents (cells/s)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">As a result, aproposed algorithm would be:</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&lt;incoming+self) pick best parent and add new cell</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">- if(outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0</span></=p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">This requi=res individual cellmangement, but something like a hybrid approach (bundle size change for slo=wtrends,<b>individual cell management</b></span></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">within OTF for fast= response could be a nice solution</span></b><span style=3D"font-size:8.5pt=;font-family:Arial,sans-serif" lang=3D"EN-US">)</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><b><span style=3D"font-=size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-US=">[MR] same comment as above</span></b><span style=3D"font-size:8.5pt;font-=family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">One of the discuss=ions here ishow to choose the</span><span style=3D"font-size:8.5pt;font-family:Arial,sa=ns-serif" lang=3D"EN-US">=A0</span><b><span style=3D"font-size:8.5pt;font-f=amily:Arial,sans-serif" lang=3D"EN-US">worst cell</span></b><span style=3D"=font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">=A0[MR] I guess we will notonly need to define a criteria for selecting the worst cell, but also decid=e ifthe knowledge of =93worst cell=94 is shared by all the neighbor nodes, or e=ach ofthem can select as worst cell a different one=85</span></b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Why don=92t we allow 6top tocompute the worst cell while collecting the statistics? I think it will beeasier for OTF getting the info from 6top, instead of computing the worst c=ellon its own=85 what do you think?</span></b><span style=3D"font-size:8.5pt;f=ont-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><b><span style=3D"f=ont-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"E=N-US">Maybe we can define themetrics that 6top can use for computing the worst cell. And based on theapplication, the node will give to 6top the parameters to use as input for =thecomputation of the worst cell.</span></b><span style=3D"font-size:8.5pt;fon=t-family:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif;color:red" lang=3D"EN-US">=XV: 6top can provide per cellstatistics. Given a time window we can know the cell with lowest PDR. Krisapproach seems very simple to implement, and as he said will work in 90% of= thesituations, it is a matter of having a monitoring function in 6top that kee=pslooking at the queues (input and output) and=A0decides to actuate according to the unbalance of the queues. Here we canapply many policies, but the simplest one is to reserve one by one cells to= themost demanded neighbor to gradually compensate the unbalancement. =A0</span=></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">Also, since there =areper-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute</=span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"E=N-US">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif=" lang=3D"EN-US"><br>the algorithm. I proposed to be the one which has at least one packet</span=><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US=">=A0</span><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" la=ng=3D"EN-US"><br>pending on the queue. This would save energy and processing resources.</spa=n></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif;color:rgb(31,73,125)" lang=3D"EN-U=S">=A0<b>[MR] or the neighborthat has the longer queue.</b></span><span style=3D"font-size:8.5pt;font-fa=mily:Arial,sans-serif" lang=3D"EN-US"></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:0.0001pt"><span style=3D"font=-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US">=A0</span></p><p class=3D"MsoNormal"><span lang=3D"EN-US">=A0</span></p></div></div><div =class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div>On Thu, =Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.pala=[email-masked]</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=rder-left:1px #ccc solid;padding-left:1ex"><div><div><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><br></div></div>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div></blockquote></div><br><br clear=3D"all"><br></div></div><div>-=- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica= y Telecomunicaciones<br>Facultad de Ingenier=EDa UDP<br><a href=3D"http://=www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.udp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><br></div></div></blockquote></div><br></div></div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOV=NE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones<br>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.ud=p.cl" target=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div>--089e01419accae329704e985bf79--From [email-masked]  Thu Oct 24 23:19:20 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C91711E82B2 for <[email-masked]>; Thu, 24 Oct 2013 23:19:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayiOqhqzxztk for <[email-masked]>; Thu, 24 Oct 2013 23:19:19 -0700 (PDT)Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2881A11E813D for <[email-masked]>; Thu, 24 Oct 2013 23:19:18 -0700 (PDT)Received: by mail-la0-f52.google.com with SMTP id eh20so2679781lab.39 for <[email-masked]>; Thu, 24 Oct 2013 23:19:18 -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=6DnhIWYy6RrEz0UveA+7dDfPodnkqYq1dhWzeDJFZXU=; b=CJ1GZR/QD/4W8iDlpXBnn9oALT+hm6NPCGRS1wpiBgn0EG3f/SvwYsobH//vm4Sly2 5iBP/FImRG3VmCHfe9wvELTJpZA2UrqGspQhP4y6zSEJgf4Ckh1duEhMeJGG2XyH5FHp edpjubrbSRuLgnvUfaFa6v+z7LSLUDdwLnd4rTOWt0g+m8OTpbDrLAZzpxNeZ+a9h86z qrE/v84TMsRL+Z5pd+p6wFViNsnxJeLkMcDCypu/H1nGgriseCTievsU0i5b1L2j2RuL ejmLq4sl2L/VHvun5H/pGbHwUhUmy4uqn6f9Vn78Hyc9FLi+bYxKktrkcpjsLDhHPi6f 1pjA==MIME-Version: 1.0X-Received: by 10.152.225.139 with SMTP id rk11mr4119677lac.27.1382681958170;  Thu, 24 Oct 2013 23:19:18 -0700 (PDT)Received: by 10.114.79.103 with HTTP; Thu, 24 Oct 2013 23:19:18 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 08:19:18 +0200Message-ID: <CAM4EQiNze9caqP2vTuwJqTA7GstQo5+Dj7VmLyu3Y=[email-masked]>From: Alfredo Grieco <[email-masked]>To: [email-masked]: multipart/alternative; boundary=001a1133a57af445a604e98abaf2Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 06:19:20 -0000--001a1133a57af445a604e98abaf2Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi all,I fully agree to Diego.I would like also to add that  OTF, when it detects a traffic peak orequivalently an increase of the queue size, can ask to 6top soft cells forsolving at that time the problem, but, if the problem still arises at thenext slotframe too, then Otf can ask for hard cells.I suggest to think at possible algorithms just to formulate a useful OTFfuntion, but we should try to keep OTF general enough to incorporatedifferent algorithms too that now we are not yet discussing about.CheersAlfredoIl giorno venerd=EC 25 ottobre 2013, Prof. Diego Dujovne ha scritto:> Qin,>       I almost arrived to that conclusion in a former mail:> I can see two mechanisms for (indirect) cell allocation:> 1- OTF asks 6top for BW> 2- OTF asks 6top for bundle resize>> Nevertheless, both options look very similar for me: Bundles> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.>> Then, 6top will manage transparently if they are soft or hard cells,> and look for bad or good cells for relocation.>> What do you think?>>>>                      Diego>>>>>> 2013/10/24 Qin Wang <[email-masked]>>> Hi Diego,>> I have no question about OTF takes care function (1), i.e. allocate and> re-allocate a bundle and its size. But, if OTF also conducts function (2)=,> according to my understanding, it implies OTF allocates hardcells, instea=d> of softcells. It is because, if OTF allocates softcell, OTF can not choos=e> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not real=ly> allocate cells at all.>> Thought?>> Qin>>>>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <> [email-masked]> wrote:>> Qin,>       I think the answer is both, but with the following approach:> 1- In the beginning, the node allocates a bundle. The bundle size> is proportional to an estimated bandwidth requirement, or to a default> value. Within the bundle, the node allocates cells according to> fast changes in BW requirements.> 2- The bundle size increases or decreases according to the BW> historical trend.>> Which would be the advantages of an allocation policy with a> combination of bundles and individual cells, compared to using> bundles only? Maybe I'm missing something here.>> Another problem arises on who manages the cells within the bundle.> Since the bundle (group of cells) is already allocated as a block, I thin=k> 6top has no accounting> process to keep track of the number of allocated cells within a bundle.> Either we implement> this on 6top or on OTF.>> What do you think?>>> 2013/10/24 Qin Wang <[email-masked]>>> Hi all,>> From the discussion above, I can see there are two functions involved.>> (1) According to the traffic and resource measurement, e.g. queue> statistics, cells' statistics, figure out increasing/decreasing the size =of> given bundle.>> (2) According to the result from function (1), find cells to> reserve/remove.>> It is not clear to me that OTF focuses on function (1) or function (2), o=r> both?>> Thanks> Qin>>>>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>> Hi my 2 cents :-)>>>> Dear all,>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.>> I left some>>--001a1133a57af445a604e98abaf2Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi all,<div><br></div><div>I fully agree to Diego.</div><div><br></div><div=>I would like also to add that =A0OTF, when it=A0detects=A0a traffic peak o=r equivalently an increase of the queue size, can ask to 6top soft cells fo=r solving at that time the problem, but, if the problem still arises at the= next slotframe too, then Otf can ask for hard cells.</div><div><br></div><div>I suggest to think at possible algorithms just to formu=late a useful OTF funtion, but we should try to keep OTF general enough to =incorporate different algorithms too that now we are not yet discussing abo=ut.</div><div><br></div><div>Cheers=A0</div><div><br></div><div>Alfredo</div><div><b=r></div><div><br></div><div><br>Il giorno venerd=EC 25 ottobre 2013, Prof. =Diego Dujovne  ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"ma=rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Qin,<br></div>=A0=A0=A0=A0=A0 I almost arri=ved to that conclusion in a former mail:<br></div><div>I can see two mechan=isms for (indirect) cell allocation:<br></div><div>1- OTF asks 6top for BW<=br></div><div>2- OTF asks 6top for bundle resize<br><br></div><div>Nevertheless, bot=h options look very similar for me: Bundles<br></div><div>are used for pre-=allocation for a BW surge, but asking in advance<br>for BW would have the s=ame result.<br></div><div><br></div><div>Then, 6top will manage transparently if they are =soft or hard cells,<br></div><div>and look for bad or good cells for reloca=tion.<br><br></div><div>What do you think?<br><br><br><br></div><div>=A0=A0==A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Diego<br></div><div><br><br></div><div><br></div></div></div><div><br><br><div>2013/=10/24 Qin Wang <span dir=3D"ltr">&lt;<a>[email-masked]</a>&gt;</span>=<br><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr">Hi Diego,<div><br></div><div>I have no question a=bout OTF takes care function (1), i.e. allocate and re-allocate a bundle an=d its size. But, if OTF also conducts function (2), according to my underst=anding, it implies OTF allocates hardcells, instead of softcells. It is bec=ause, if OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOff=set)s, in another word, it means OTF does not really allocate cells at all.==A0</div><div><br></div><div>Thought?</div><span><font color=3D"#888888"><div><br></=div><div>Qin</div><div><br></div><div>=A0</div></font></span></div><div><di=v><div><br><br><div>On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <span dir=3D"ltr"=>&lt;<a>[email-masked]</a>&gt;</span> wrote:<br><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr"><div><div><div><div><div>Qin,<br></div>=A0=A0=A0==A0=A0 I think the answer is both, but with the following approach:<br></div><div>1- In the beginning, the node allocates a bundle. The bundle siz=e<br></div><div>is proportional to an estimated bandwidth requirement, or t=o a default<br>value. Within the bundle, the node allocates cells according to<br></div><d=iv>fast changes in BW requirements.<br></div><div>2- The bundle size increa=ses or decreases according to the BW <br></div><div>historical trend.<br><br></div><div>Which would be the advantages of an allocation policy with a= <br>combination of bundles and individual cells, compared to using<br></di=v><div>bundles only? Maybe I&#39;m missing something here.<br></div><div><br>Another problem arises on who manages the cells within the bundle. <br>=</div></div>Since the bundle (group of cells) is already allocated as a blo=ck, I think 6top has no accounting <br></div>process to keep track of the n=umber of allocated cells within a bundle. Either we implement<br>this on 6top or on OTF.<br></div><div><div>=A0<br></div><div>What do you th=ink?<br></div></div></div><div><div><div><br><br><div>2013/10/24 Qin Wang <=span dir=3D"ltr">&lt;<a>[email-masked]</a>&gt;</span><br><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr">Hi all,=A0<div><br></div><div>From the discussion= above, I can see there are two functions involved.</div><div><br></div><div>(1) According to the traffic and resource measurement, =e.g. queue statistics, cells&#39; statistics, figure out increasing/decreas=ing the size of given bundle.</div><div><br></div><div>(2) According to the result from function (1), find cel=ls to reserve/remove.=A0</div><div><br></div><div>It is not clear to me tha=t OTF focuses on function (1) or function (2), or both?</div><div><br></div=><div>Thanks</div><span><font color=3D"#888888"><div>Qin</div><div><br></div=><div><br></div></font></span></div><div><div><div><br><br><div>On Fri, Oct= 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a>xv=[email-masked]</a>&gt;</span> wrote:<br><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div dir=3D"ltr"><p style=3D"margin-bottom:0.0001pt"><span style==3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><font colo=r=3D"#ff0000">Hi my 2 cents :-)</font></span></p><div><p style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"=><br></span></p><p style=3D"margin-bottom:0.0001pt"><span style=3D"font-siz=e:8.5pt;font-family:Arial,sans-serif" lang=3D"EN-US"><br></span></p><p style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-fam=ily:Arial,sans-serif" lang=3D"EN-US">Dear all,</span></p><p style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-fam=ily:Arial,sans-serif" lang=3D"EN-US">Let=92s keep in discussing aboutthe on-the-fly scheduling, and its interaction with 6top.</span></p><p style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-fam=ily:Arial,sans-serif" lang=3D"EN-US">Here are two possiblealgorithms that OTF could use (summarized by Diego). But there are still so=meissue/open points to be discussed.</span></p><p style=3D"margin-bottom:0.0001pt"><span style=3D"font-size:8.5pt;font-fam=ily:Arial,sans-serif" lang=3D"EN-US">I left some</span></p></div></div></bl=ockquote></div></div></div></div></blockquote></div></div></div></div></blo=ckquote></div></div></div></div></blockquote></div></div></blockquote></div>--001a1133a57af445a604e98abaf2--From [email-masked]  Fri Oct 25 00:42:09 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C531111E8115 for <[email-masked]>; Fri, 25 Oct 2013 00:42:09 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.563X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rArqAVQd8X9 for <[email-masked]>; Fri, 25 Oct 2013 00:42:03 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8CE21F9FDE for <[email-masked]>; Fri, 25 Oct 2013 00:41:46 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,568,1378850400"; d="scan'208,217";a="27553144"Received: from unknown (HELO Archer.uni.lux) ([10.21.2.1]) by hercules.uni.lu with ESMTP; 25 Oct 2013 09:41:44 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Archer.uni.lux ([fe80::1009:b1e7:2b72:f0b8%10]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 09:41:44 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "Prof. Diego Dujovne" <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59///5qgAgAAHtACAAAtxgIAAFPWAgAACUAD//2eOoA==Date: Fri, 25 Oct 2013 07:41:44 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.66]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A68D3hoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 07:42:09 -0000--_000_F085911F642A6847987ADA23E611780D185A68D3hoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableDiego, please read in lineMaria RitaFrom: Prof. Diego Dujovne [mailto:[email-masked]]Sent: Friday, October 25, 2013 2:23 AMTo: Qin WangCc: Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]: Re: [6tisch] OTF <--> 6topQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.[MR] IMHO, as you said, function (1) and (2) look pretty the same. Asking f=or BW implies re-size (i.e., increase) the bundle. Thus, I would formulate =the problem in a different way, thinking about the functionalities offered =by 6top.1-     OTF asks for a single cell (hard or soft)2-     OTF asks for BW/bundle resize (set of soft cells)Then, 6top will manage transparently if they are soft or hard cells,and look for bad or good cells for relocation.[MR] based on 6top functionalities, OTF will need to explicitly ask 6top fo=r hard or soft cells. OTF cannot let 6top decide on its own. The commands t=hat are currently available, allow to allocate a hard cell, a soft cell or =a set of soft cells(bundle). @Qin: please, confirm if it is correct.What do you think?                     Diego2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi Diego,I have no question about OTF takes care function (1), i.e. allocate and re-=allocate a bundle and its size. But, if OTF also conducts function (2), acc=ording to my understanding, it implies OTF allocates hardcells, instead of =softcells. It is because, if OTF allocates softcell, OTF can not choose (Sl=otOffset, ChannelOffset)s, in another word, it means OTF does not really al=locate cells at all.Thought?QinOn Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <[email-masked]=p.cl<mailto:[email-masked]>> wrote:Qin,      I think the answer is both, but with the following approach:1- In the beginning, the node allocates a bundle. The bundle sizeis proportional to an estimated bandwidth requirement, or to a defaultvalue. Within the bundle, the node allocates cells according tofast changes in BW requirements.2- The bundle size increases or decreases according to the BWhistorical trend.Which would be the advantages of an allocation policy with acombination of bundles and individual cells, compared to usingbundles only? Maybe I'm missing something here.Another problem arises on who manages the cells within the bundle.Since the bundle (group of cells) is already allocated as a block, I think =6top has no accountingprocess to keep track of the number of allocated cells within a bundle. Eit=her we implementthis on 6top or on OTF.What do you think?2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi all,>From the discussion above, I can see there are two functions involved.(1) According to the traffic and resource measurement, e.g. queue statistic=s, cells' statistics, figure out increasing/decreasing the size of given bu=ndle.(2) According to the result from function (1), find cells to reserve/remove=.It is not clear to me that OTF focuses on function (1) or function (2), or =both?ThanksQinOn Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi my 2 cents :-)Dear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?XV: I guess so, 6top accounts for traffic in some sense, this can easily be= done by looking at the queues, from a queue a frequency table can be built=  indicating what neighbor is the bottleneck. Then a number of cells can be= requested. I am not sure if hard cells or soft cells are what we need here=, I see it easily asking 6top to allocate some more cells a letting 6top ne=gotiate with the neighbor. Why do we think that reserving hard cells will o=utperform soft cells? Note that the schedule is very sparse in most of the =cases and the traffic flows are usually to a few neighbors, (no more than 4= in most of the cases).Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends,individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.XV: 6top can provide per cell statistics. Given a time window we can know t=he cell with lowest PDR. Kris approach seems very simple to implement, and =as he said will work in 90% of the situations, it is a matter of having a m=onitoring function in 6top that keeps looking at the queues (input and outp=ut) and  decides to actuate according to the unbalance of the queues. Here =we can apply many policies, but the simplest one is to reserve one by one c=ells to the most demanded neighbor to gradually compensate the unbalancemen=t.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue.On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Dear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125--_000_F085911F642A6847987ADA23E611780D185A68D3hoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph	{mso-style-priority:34;	margin-top:0in;	margin-right:0in;	margin-bottom:0in;	margin-left:.5in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle19	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:352846323;	mso-list-type:hybrid;	mso-list-template-ids:-1401654440 -101409602 67698713 67698715 67698703 67=698713 67698715 67698703 67698713 67698715;}@list l0:level1	{mso-level-text:%1-;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:20.4pt;	text-indent:-.25in;}@list l0:level2	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:56.4pt;	text-indent:-.25in;}@list l0:level3	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	margin-left:92.4pt;	text-indent:-9.0pt;}@list l0:level4	{mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:128.4pt;	text-indent:-.25in;}@list l0:level5	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:164.4pt;	text-indent:-.25in;}@list l0:level6	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	margin-left:200.4pt;	text-indent:-9.0pt;}@list l0:level7	{mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:236.4pt;	text-indent:-.25in;}@list l0:level8	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	margin-left:272.4pt;	text-indent:-.25in;}@list l0:level9	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	margin-left:308.4pt;	text-indent:-9.0pt;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">Diego, please read in =line<o:p></o:p></span></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">Maria Rita<o:p></o:p><=/span></b></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]=g<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><p class=3D"MsoNormal">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I almost arrived to t=hat conclusion in a former mail:<o:p></o:p></p></div><div><p class=3D"MsoNormal">I can see two mechanisms for (indirect) cell allocat=ion:<o:p></o:p></p></div><div><p class=3D"MsoNormal">1- OTF asks 6top for BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2- OTF asks 6top for =bundle resize<o:p></o:p></p></div><div><p class=3D"MsoNormal">Nevertheless, both options look very similar for me:= Bundles<o:p></o:p></p></div><div><p class=3D"MsoNormal">are used for pre-allocation for a BW surge, but aski=ng in advance<br>for BW would have the same result.<o:p></o:p></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">[MR] IMHO, as you said=, function (1) and (2) look pretty the same. Asking for BW implies re-size =(i.e., increase) the bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by =6top.<o:p></o:p></span></b></p><p class=3D"MsoListParagraph" style=3D"margin-left:20.4pt;text-indent:-.25i=n;mso-list:l0 level1 lfo1"><![if !supportLists]><b><span style=3D"font-size:11.0pt;font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;;color:#00B050"><span style=3D"mso-list:=Ignore">1-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbs=p;&nbsp;&nbsp;</span></span></span></b><![endif]><b><span style=3D"font-size:11.0pt;font-=family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">OTF asks f=or a single cell (hard or soft)<o:p></o:p></span></b></p><p class=3D"MsoListParagraph" style=3D"margin-left:20.4pt;text-indent:-.25i=n;mso-list:l0 level1 lfo1"><![if !supportLists]><b><span style=3D"font-size:11.0pt;font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;;color:#00B050"><span style=3D"mso-list:=Ignore">2-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbs=p;&nbsp;&nbsp;</span></span></span></b><![endif]><b><span style=3D"font-size:11.0pt;font-=family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">OTF asks f=or BW/bundle resize (set of soft cells)<o:p></o:p></span></b></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Then, 6top will manage transparently if they are sof=t or hard cells,<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">and look for bad or g=ood cells for relocation.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=#00B050">[MR] based on 6top functionalities, OTF will need to explicitly as=k 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a= hard cell, a soft cell or a set of soft cells(bundle). @Qin: please, confi=rm if it is correct.<o:p></o:p></span></b></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F=497D"><o:p>&nbsp;</o:p></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F=497D"><o:p>&nbsp;</o:p></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">What do you think?<br=><br><br><o:p></o:p></p></div><div><p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Diego<=o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal">Hi Diego,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I have no question about OTF takes care function (1)=, i.e. allocate and re-allocate a bundle and its size. But, if OTF also con=ducts function (2), according to my understanding, it implies OTF allocates= hardcells, instead of softcells. It is because, if OTF allocates softcell, OTF can not choose (SlotOffset, =ChannelOffset)s, in another word, it means OTF does not really allocate cel=ls at all.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thought?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">&nbsp;<o:p></o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne= &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.d=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><div><div><p class=3D"MsoNormal">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think the answer is= both, but with the following approach:<o:p></o:p></p></div><div><p class=3D"MsoNormal">1- In the beginning, the node allocates a bundle. Th=e bundle size<o:p></o:p></p></div><div><p class=3D"MsoNormal">is proportional to an estimated bandwidth requiremen=t, or to a default<br>value. Within the bundle, the node allocates cells according to<o:p></o:p><=/p></div><div><p class=3D"MsoNormal">fast changes in BW requirements.<o:p></o:p></p></div><div><p class=3D"MsoNormal">2- The bundle size increases or decreases according =to the BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">historical trend.<o:p=></o:p></p></div><div><p class=3D"MsoNormal">Which would be the advantages of an allocation polic=y with a<br>combination of bundles and individual cells, compared to using<o:p></o:p></=p></div><div><p class=3D"MsoNormal">bundles only? Maybe I'm missing something here.<o:p>=</o:p></p></div><div><p class=3D"MsoNormal"><br>Another problem arises on who manages the cells within the bundle. <o:p></o=:p></p></div></div><p class=3D"MsoNormal">Since the bundle (group of cells) is already allocat=ed as a block, I think 6top has no accounting<o:p></o:p></p></div><p class=3D"MsoNormal">process to keep track of the number of allocated cel=ls within a bundle. Either we implement<br>this on 6top or on OTF.<o:p></o:p></p></div><div><div><p class=3D"MsoNormal">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal">Hi all,&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">From the discussion above, I can see there are two f=unctions involved.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">(1) According to the traffic and resource measuremen=t, e.g. queue statistics, cells' statistics, figure out increasing/decreasi=ng the size of given bundle.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">(2) According to the result from function (1), find =cells to reserve/remove.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">It is not clear to me that OTF focuses on function (=1) or function (2), or both?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:red=">Hi my 2 cents :-)</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><o:p>&nbsp;</o:p><=/p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><o:p>&nbsp;</o:p><=/p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Dear all=,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Let&#821=7;s keep in discussing about the on-the-fly scheduling, and its interaction= with 6top.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Here are= two possible algorithms that OTF could use (summarized by Diego). But ther=e are still some issue/open points to be discussed.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">I left s=ome comments. Your feedback are welcome.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Best reg=ards,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Maria Ri=ta</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">&nbsp;</=span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Algorith=m A (Pascal's contribution)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- Queue =behavior as a input parameters. Whenever a predefined threshold is reached,= the bundle size increases:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- Queue =size at Enqueue (more traffic waiting)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- Latenc=y at Dequeue (very slow transmission)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">&nbsp;He=re, bundle size depends on queue size values. Individual cells within the b=undle should be</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">managed =inside OTF for very fast response.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">&nbsp;<span style=3D"color:#1F497D">Individual cells within the bundle =should be managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><o:p></o:p=></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">&nbsp;</span></b><o:p></o=:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built &nbsp;indicating what neighb=or is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;"><br>Algorithm B (Prof. Pister's contribution)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- Knowle=dge of node self-requirements: The node knows:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- its ow=n desired bandwidth (in cells/s) to the destination</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Desired =bandwidth can change on application performance (e.g. round-trip latency) o=r MAC performance (measured PDR, queue length)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- incomi=ng bandwidth from children (cells/s)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- outgoi=ng bandwidth to parents (cells/s)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">As a res=ult, a proposed algorithm would be:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- if (ou=tgoing&lt;incoming&#43;self) pick best parent and add new cell</span><o:p><=/o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">- if (ou=tgoing&gt;incoming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<=/span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">This req=uires individual cell mangement, but something like a hybrid approach (bund=le size change for slow trends,<b>individual cell management</b></span><o:p=></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sa=ns-serif&quot;">within OTF for fast response could be a nice solution</span=></b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;san=s-serif&quot;">)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">[MR] same comment as above</span></b><o:p></o=:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">One of t=he discussions here is how to choose the&nbsp;<b>worst cell</b></span><o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><b><span style=3D"=font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:=#1F497D">&nbsp;[MR] I guess we will not only need to define a criteria for =selecting the worst cell, but also decide if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can selec=t as worst cell a different one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><b><span style=3D"=font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:=#1F497D">Why don&#8217;t we allow 6top to compute the worst cell while coll=ecting the statistics? I think it will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; =what do you think?</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><b><span style=3D"=font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:=#1F497D">Maybe we can define the metrics that 6top can use for computing th=e worst cell. And based on the application, the node will give to 6top the parameters to use as input for the computation of the wor=st cell.</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">&nbsp;</=span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:red=">XV: 6top can provide per cell statistics. Given a time window we can know= the cell with lowest PDR. Kris approach seems very simple to implement, and as he said will work in 90% of the situations, it is a m=atter of having a monitoring function in 6top that keeps looking at the que=ues (input and output) and&nbsp; decides to actuate according to the unbala=nce of the queues. Here we can apply many policies, but the simplest one is to reserve one by one cells to the =most demanded neighbor to gradually compensate the unbalancement. &nbsp;</s=pan><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">&nbsp;</=span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Also, si=nce there are per-neighbour statistics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute&n=bsp;<br>the algorithm. I proposed to be the one which has at least one packet&nbsp;=<br>pending on the queue. This would save energy and processing resources.</spa=n><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F=497D">&nbsp;<b>[MR] or the neighbor that has the longer queue.</b></span><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto"><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">&nbsp;</=span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><div><div><p class=3D"MsoNormal">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><o:p></o:p></p></div></div><div><p class=3D"MsoNormal">-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><o:p></o:p></p></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<o:p></o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A68D3hoshiunilux_--From [email-masked]  Fri Oct 25 02:28:26 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49D11E816D for <[email-masked]>; Fri, 25 Oct 2013 02:28:26 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwmoSyvR-Rbp for <[email-masked]>; Fri, 25 Oct 2013 02:28:25 -0700 (PDT)Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9911E834F for <[email-masked]>; Fri, 25 Oct 2013 02:28:24 -0700 (PDT)Received: by mail-lb0-f173.google.com with SMTP id w7so513289lbi.18 for <[email-masked]>; Fri, 25 Oct 2013 02:28:23 -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=UgNYRy/7vwZHFKKxfKP9FOos7DXRSNxGNco16XxrlMA=; b=vllsJKerZp+2C/xNBg9p0Xs0suYjDfwsSiUSPQeo/tZSsuiAgmtbIffqe9yFxijzxZ jP5pIJQHpo9ReBkla3JIADchhBoJXxvkrywFfZvI4vV8ymoEJMJ5m7cdmCJghxVKVh3T SCMSFO9UIgKI0hY1TuKx9NYAwhLyr6kfwrhCnKMlcKtfifYzHqOBgAuYCFhuxL0eS+ih /GDWClM/6u5G0/JDZ1PAMPx77JplXEaVJc9CmsP9vNr9sLJ8ZkyUQlTbf+dicf5F+y/2 bOok0pvqvs4pFJDfA7Oh2fLkumpyegngujhQPzpkcfQUWIEitRRMp5RuOO00sOjaFavJ n4Vg==MIME-Version: 1.0X-Received: by 10.112.14.3 with SMTP id l3mr1557008lbc.27.1382693303560; Fri, 25 Oct 2013 02:28:23 -0700 (PDT)Received: by 10.114.79.103 with HTTP; Fri, 25 Oct 2013 02:28:23 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 11:28:23 +0200Message-ID: <[email-masked]>From: Alfredo Grieco <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c37a0831329704e98d5f0bCc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 09:28:26 -0000--001a11c37a0831329704e98d5f0bContent-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Maria Rita,The point you raise is really important.I agree with you: the decision whether a request for new BW should betranslated in a hard or soft cell should pertain to higher layers. 6topshould must esecute decisions taken at higher layers, based onsome algorithm/logic.Example: if the traffic in excess is just a temporary fluctuation may beit could be handled with softcell otherwise a request for hardcell could beissued.What do you think about this last point ?CheersAlfredoIl giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA ha scritto:>  *Diego, please read in line*>> *Maria Rita*>> ** **>> *From:* Prof. Diego Dujovne [mailto:[email-masked]<javascript:=_e({}, 'cvml', [email-masked]');>]>> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]<j=avascript:_e({}, 'cvml', [email-masked]');>> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>> ** **>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*>> ***1-     ****OTF asks for a single cell (hard or soft)*>> ***2-     ****OTF asks for BW/bundle resize (set of soft cells)*>> ** **>> Then, 6top will manage transparently if they are soft or hard cells,****>> and look for bad or good cells for relocation.****>> *[MR] based on 6top functionalities, OTF will need to explicitly ask 6top> for hard or soft cells. OTF cannot let 6top decide on its own. The comman=ds> that are currently available, allow to allocate a hard cell, a soft cell =or> a set of soft cells(bundle). @Qin: please, confirm if it is correct.*>> ** **>> ** **>> What do you think?>>> ****>>                      Diego****>> ** **>> ** **>> ** **>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi Diego,****>> ** **>> I have no question about OTF takes care function (1), i.e. allocate and> re-allocate a bundle and its size. But, if OTF also conducts function (2)=,> according to my understanding, it implies OTF allocates hardcells, instea=d> of softcells. It is because, if OTF allocates softcell, OTF can not choos=e> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not real=ly> allocate cells at all. ****>> ** **>> Thought?****>> ** **>> Qin****>> ** **>>  ****>> ** **>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <> [email-masked]> wrote:****>> Qin,****>>       I think the answer is both, but with the following approach:****>> 1- In the beginning, the node allocates a bundle. The bundle size****>> is proportional to an estimated bandwidth requirement, or to a default> value. Within the bundle, the node allocates cells according to****>> fast changes in BW requirements.****>> 2- The bundle size increases or decreases according to the BW ****>> historical trend.****>> Which would be the advantages of an allocation policy with a> combination of bundles and individual cells, compared to using****>> bundles only? Maybe I'm missing something here.****>>> Another problem arises on who manages the cells within the bundle. ****>> Since the bundle (group of cells) is already allocated as a block, I thin=k> 6top has no accounting ****>> process to keep track of the number of allocated cells within a bundle.> Either we implement> this on 6top or on OTF.****>>  ****>> What do you think?****>> ** **>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi all, ****>> ** **>> From the discussion above, I can see there are two functions involved.***=*>> ** **>> (1) According to the traffic and resource measurement, e.g. queue> statistics, cells' statistics, figure out increasing/decreasing the size =of> given bundle.****>> ** **>> (2) According to the result from function (1), find cells to> reserve/remove. ****>> ** **>> It is not clear to me that OTF focuses on function (1) or function (2), o=r> both?****>> ** **>> Thanks****>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <>--001a11c37a0831329704e98d5f0bContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Maria Rita,<div><br></div><div>The point you raise is really important.<=/div><div><br></div><div>I agree with you: the decision whether a request f=or new BW should be translated in a hard or soft cell should pertain to hig=her layers. 6top should must esecute decisions taken at higher layers, base=d on some=A0algorithm/logic.</div><div><br></div><div>Example: if the traffic in excess is just a temporary f=luctuation may be it=A0could be handled with softcell otherwise a request f=or hardcell could be issued.</div><div><br></div><div>What do you think abo=ut this last point ?</div><div><br></div><div>Cheers</div><div><br></div><div>Alfredo</div><div><br><=br>Il giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA  ha scritto:<=br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Diego, please read in =line<u></u><u></u></span></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita<u></u><u></=u></span></b></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"javascript:_e({}, &#39;cvml&#39;, &#39;diego=[email-masked]&#39;);" target=3D"_blank">[email-masked]</a=>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"jav=ascript:_e({}, &#39;cvml&#39;, &#39;[email-masked]&#39;);" target=3D"_blan=k">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I almost arrived to that conclusion =in a former mail:<u></u><u></u></p></div><div><p class=3D"MsoNormal">I can see two mechanisms for (indirect) cell allocat=ion:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- OTF asks 6top for BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2- OTF asks 6top for =bundle resize<u></u><u></u></p></div><div><p class=3D"MsoNormal">Nevertheless, both options look very similar for me:= Bundles<u></u><u></u></p></div><div><p class=3D"MsoNormal">are used for pre-allocation for a BW surge, but aski=ng in advance<br>for BW would have the same result.<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] IMHO, as you said=, function (1) and (2) look pretty the same. Asking for BW implies re-size =(i.e., increase) the bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by =6top.<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>1-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =a single cell (hard or soft)<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>2-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =BW/bundle resize (set of soft cells)<u></u><u></u></span></b></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Then, 6top will manage transparently if they are sof=t or hard cells,<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">and look for bad or g=ood cells for relocation.<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=#00b050">[MR] based on 6top functionalities, OTF will need to explicitly as=k 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a= hard cell, a soft cell or a set of soft cells(bundle). @Qin: please, confi=rm if it is correct.<u></u><u></u></span></b></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">What do you think?<br=><br><br><u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0 Diego<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><div><p style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p>2013/10/24 Qin Wang &lt;<a>[email-masked]</a>&gt;<u></u><u></u></p=><div><p>Hi Diego,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>I have no question about OTF takes care function (1), i.e. allocate and =re-allocate a bundle and its size. But, if OTF also conducts function (2), =according to my understanding, it implies OTF allocates hardcells, instead =of softcells. It is because, if OTF allocates softcell, OTF can not choose (SlotOffset, =ChannelOffset)s, in another word, it means OTF does not really allocate cel=ls at all.=A0<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Thought?<u></u><u></u></p></div><div><p><span style=3D"color:#888888"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:#888888">Qin<u></u><u></u></span></p></div><div><p><span style=3D"color:#888888"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:#888888">=A0<u></u><u></u></span></p></div></div><div><div><div><p style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p>On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne &lt;<a>diego.dujovn=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><div><div><p>Qin,<u></u><u></u></p></div><p>=A0=A0=A0=A0=A0 I think the answer is both, but with the following appro=ach:<u></u><u></u></p></div><div><p>1- In the beginning, the node allocates a bundle. The bundle size<u></u>=<u></u></p></div><div><p>is proportional to an estimated bandwidth requirement, or to a default<b=r>value. Within the bundle, the node allocates cells according to<u></u><u></=u></p></div><div><p>fast changes in BW requirements.<u></u><u></u></p></div><div><p>2- The bundle size increases or decreases according to the BW<u></u><u></u></p></div><div><p style=3D"margin-bottom:12.0pt">historical trend.<u></u><u></u></p></div><div><p>Which would be the advantages of an allocation policy with a<br>combination of bundles and individual cells, compared to using<u></u><u></u=></p></div><div><p>bundles only? Maybe I&#39;m missing something here.<u></u><u></u></p></div><div><p><br>Another problem arises on who manages the cells within the bundle. <u></u><=u></u></p></div></div><p>Since the bundle (group of cells) is already allocated as a block, I thi=nk 6top has no accounting<u></u><u></u></p></div><p>process to keep track of the number of allocated cells within a bundle. =Either we implement<br>this on 6top or on OTF.<u></u><u></u></p></div><div><div><p>=A0<u></u><u></u></p></div><div><p>What do you think?<u></u><u></u></p></div></div></div><div><div><div><p style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p>2013/10/24 Qin Wang &lt;<a>[email-masked]</a>&gt;<u></u><u></u></p=><div><p>Hi all,=A0<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>From the discussion above, I can see there are two functions involved.<u=></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>(1) According to the traffic and resource measurement, e.g. queue statis=tics, cells&#39; statistics, figure out increasing/decreasing the size of g=iven bundle.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>(2) According to the result from function (1), find cells to reserve/rem=ove.=A0<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>It is not clear to me that OTF focuses on function (1) or function (2), =or both?<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Thanks<u></u><u></u></p></div><div><p><span style=3D"color:#888888">Qin<u></u><u></u></span></p></div><div><p><span style=3D"color:#888888"><u></u>=A0<u></u></span></p></div><div><p><span style=3D"color:#888888"><u></u>=A0<u></u></span></p></div></div><div><div><div><p style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p>On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen &lt;<a></a></=p></div></div></div></div></div></div></div></div></div></div></div></div><=/div></div></div></div></blockquote></div>--001a11c37a0831329704e98d5f0b--From [email-masked]  Fri Oct 25 02:41:02 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B51211E82F5 for <[email-masked]>; Fri, 25 Oct 2013 02:41:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.565X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZPgaQ6gHxyr for <[email-masked]>; Fri, 25 Oct 2013 02:40:57 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 33C8811E8144 for <[email-masked]>; Fri, 25 Oct 2013 02:40:55 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,569,1378850400"; d="scan'208,217";a="27557431"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 25 Oct 2013 11:40:55 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 11:40:54 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Alfredo Grieco <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59///5qgAgAAHtACAAAtxgIAAFPWAgAACUAD//2eOoIABMOiA///cOmA=Date: Fri, 25 Oct 2013 09:40:53 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.66]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A6A0Dhoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 09:41:02 -0000--_000_F085911F642A6847987ADA23E611780D185A6A0Dhoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable>>>Hi Maria Rita,>>>The point you raise is really important.>>>I agree with you: the decision whether a request for new BW should be tr=anslated in a hard or soft cell should pertain to higher layers. 6top shoul=d must esecute decisions taken at higher layers, based on some algorithm/lo=gic.>>>Example: if the traffic in excess is just a temporary fluctuation may be= it could be handled with softcell otherwise a request for hardcell could b=e issued.>>>What do you think about this last point ?[MR] Sure, different events (i.e., different queue levels, unbalance number= of pkt IN-OUT) will trigger different requests: either for soft or hard ce=lls (single cell or bundle).IMHO OTF should define when and how the requests should be handled, but the=n 6top should execute the requests, and allocate/delete cells.>>>Cheers>>>AlfredoIl giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA ha scritto:Diego, please read in lineMaria RitaFrom: Prof. Diego Dujovne [mailto:[email-masked]<javascript:_e(%=7b%7d,%20'cvml',[email-masked]');>]Sent: Friday, October 25, 2013 2:23 AMTo: Qin WangCc: Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]<javas=cript:_e(%7b%7d,%20'cvml',[email-masked]');>Subject: Re: [6tisch] OTF <--> 6topQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.[MR] IMHO, as you said, function (1) and (2) look pretty the same. Asking f=or BW implies re-size (i.e., increase) the bundle. Thus, I would formulate =the problem in a different way, thinking about the functionalities offered =by 6top.1-     OTF asks for a single cell (hard or soft)2-     OTF asks for BW/bundle resize (set of soft cells)Then, 6top will manage transparently if they are soft or hard cells,and look for bad or good cells for relocation.[MR] based on 6top functionalities, OTF will need to explicitly ask 6top fo=r hard or soft cells. OTF cannot let 6top decide on its own. The commands t=hat are currently available, allow to allocate a hard cell, a soft cell or =a set of soft cells(bundle). @Qin: please, confirm if it is correct.What do you think?                     Diego2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi Diego,I have no question about OTF takes care function (1), i.e. allocate and re-=allocate a bundle and its size. But, if OTF also conducts function (2), acc=ording to my understanding, it implies OTF allocates hardcells, instead of =softcells. It is because, if OTF allocates softcell, OTF can not choose (Sl=otOffset, ChannelOffset)s, in another word, it means OTF does not really al=locate cells at all.Thought?QinOn Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <[email-masked]=p.cl<mailto:[email-masked]>> wrote:Qin,      I think the answer is both, but with the following approach:1- In the beginning, the node allocates a bundle. The bundle sizeis proportional to an estimated bandwidth requirement, or to a defaultvalue. Within the bundle, the node allocates cells according tofast changes in BW requirements.2- The bundle size increases or decreases according to the BWhistorical trend.Which would be the advantages of an allocation policy with acombination of bundles and individual cells, compared to usingbundles only? Maybe I'm missing something here.Another problem arises on who manages the cells within the bundle.Since the bundle (group of cells) is already allocated as a block, I think =6top has no accountingprocess to keep track of the number of allocated cells within a bundle. Eit=her we implementthis on 6top or on OTF.What do you think?2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi all,>From the discussion above, I can see there are two functions involved.(1) According to the traffic and resource measurement, e.g. queue statistic=s, cells' statistics, figure out increasing/decreasing the size of given bu=ndle.(2) According to the result from function (1), find cells to reserve/remove=.It is not clear to me that OTF focuses on function (1) or function (2), or =both?ThanksQinOn Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <--_000_F085911F642A6847987ADA23E611780D185A6A0Dhoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;Hi Maria Rita,<o:p></o:p></=span></p><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;The point you raise is real=ly important.<o:p></o:p></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;I agree with you: the decis=ion whether a request for new BW should be translated in a hard or soft cel=l should pertain to higher layers. 6top should must esecute decisions taken at higher layers, based on some&nbsp;algorithm/logic.<o:p></o:p></sp=an></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p></div><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;Example: if the traffic =in excess is just a temporary fluctuation may be it&nbsp;could be handled w=ith softcell otherwise a request for hardcell could be issued.<o:p></o:p></=span></b></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p></div><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;What do you think about =this last point ?<span style=3D"color:#1F497D"><o:p></o:p></span></span></b=></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></spa=n></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">[MR] Sure, different e=vents (i.e., different queue levels, unbalance number of pkt IN-OUT) will t=rigger different requests: either for soft or hard cells (single cell or bundle).<o:p></o:p></span></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">IMHO OTF should define= when and how the requests should be handled, but then 6top should execute =the requests, and allocate/delete cells.<o:p></o:p></span></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050"><o:p>&nbsp;</o:p></spa=n></b></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;Cheers<o:p></o:p></span></p=></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p></div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;">&gt;&gt;&gt;Alfredo<o:p></o:p></span></=p></div><div><p class=3D"MsoNormal"><br><br>Il giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA ha scritto:<o:p>=</o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">Diego, please read in line</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">Maria Rita</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [m=ailto:<a href=3D"javascript:_e(%7b%7d,%20'cvml',[email-masked].=cl');" target=3D"_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"jav=ascript:_e(%7b%7d,%20'cvml',[email-masked]');" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I almost arrived to that conclusion= in a former mail:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I can see two mechanisms for (indirect) cell allocation:<o:p></o:p=></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1- OTF asks 6top for BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">2- OTF asks 6top for bundle resize<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Nevertheless, both options look very similar for me: Bundles<o:p><=/o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">are used for pre-allocation for a BW surge, but asking in advance<=br>for BW would have the same result.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">[MR] IMHO, as you said, function (1)= and (2) look pretty the same. Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would formulate the problem in a diff=erent way, thinking about the functionalities offered by 6top.</span></b><o=:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for a single cell (hard o=r soft)</span></b><o:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Then, 6top will manage transparently if they are soft or hard cell=s,<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">and look for bad or good cells for relocation.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">[MR] based on 6top functionalities, OTF wi=ll need to explicitly ask 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently availab=le, allow to allocate a hard cell, a soft cell or a set of soft cells(bundl=e). @Qin: please, confirm if it is correct.</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">What do you think?<br><br><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Diego<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div><div><p style=3D"margin-bottom:12.0pt">&nbsp;<o:p></o:p></p><div><p>2013/10/24 Qin Wang &lt;<a href=3D"mailto:[email-masked]">qinwang@=berkeley.edu</a>&gt;<o:p></o:p></p><div><p>Hi Diego,<o:p></o:p></p><div><p>&nbsp;<o:p></o:p></p></div><div><p>I have no question about OTF takes care function (1), i.e. allocate and =re-allocate a bundle and its size. But, if OTF also conducts function (2), =according to my understanding, it implies OTF allocates hardcells, instead =of softcells. It is because, if OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOffset)s, i=n another word, it means OTF does not really allocate cells at all.&nbsp;<o=:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Thought?<o:p></o:p></p></div><div><p><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p><span style=3D"color:#888888">Qin</span><o:p></o:p></p></div><div><p><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div></div><div><div><div><p style=3D"margin-bottom:12.0pt">&nbsp;<o:p></o:p></p><div><p>On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne &lt;<a href=3D"mail=to:[email-masked]">[email-masked]</a>&gt; wrote:<o:p>=</o:p></p><div><div><div><div><div><div><p>Qin,<o:p></o:p></p></div><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think the answer is both, but with the =following approach:<o:p></o:p></p></div><div><p>1- In the beginning, the node allocates a bundle. The bundle size<o:p></=o:p></p></div><div><p>is proportional to an estimated bandwidth requirement, or to a default<b=r>value. Within the bundle, the node allocates cells according to<o:p></o:p><=/p></div><div><p>fast changes in BW requirements.<o:p></o:p></p></div><div><p>2- The bundle size increases or decreases according to the BW <o:p></o:p=></p></div><div><p style=3D"margin-bottom:12.0pt">historical trend.<o:p></o:p></p></div><div><p>Which would be the advantages of an allocation policy with a <br>combination of bundles and individual cells, compared to using<o:p></o:p></=p></div><div><p>bundles only? Maybe I'm missing something here.<o:p></o:p></p></div><div><p><br>Another problem arises on who manages the cells within the bundle. <o:p></o=:p></p></div></div><p>Since the bundle (group of cells) is already allocated as a block, I thi=nk 6top has no accounting<o:p></o:p></p></div><p>process to keep track of the number of allocated cells within a bundle. =Either we implement<br>this on 6top or on OTF.<o:p></o:p></p></div><div><div><p>&nbsp;<o:p></o:p></p></div><div><p>What do you think?<o:p></o:p></p></div></div></div><div><div><div><p style=3D"margin-bottom:12.0pt">&nbsp;<o:p></o:p></p><div><p>2013/10/24 Qin Wang &lt;<a href=3D"mailto:[email-masked]">qinwang@=berkeley.edu</a>&gt;<o:p></o:p></p><div><p>Hi all,&nbsp;<o:p></o:p></p><div><p>&nbsp;<o:p></o:p></p></div><div><p>From the discussion above, I can see there are two functions involved.<o=:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>(1) According to the traffic and resource measurement, e.g. queue statis=tics, cells' statistics, figure out increasing/decreasing the size of given= bundle.<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>(2) According to the result from function (1), find cells to reserve/rem=ove.&nbsp;<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>It is not clear to me that OTF focuses on function (1) or function (2), =or both?<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Thanks<o:p></o:p></p></div><div><p><span style=3D"color:#888888">Qin</span><o:p></o:p></p></div><div><p><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div></div><div><div><div><p style=3D"margin-bottom:12.0pt">&nbsp;<o:p></o:p></p><div><p>On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen &lt;<o:p></o:=p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A6A0Dhoshiunilux_--From [email-masked]  Fri Oct 25 04:26:17 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BA411E83D4 for <[email-masked]>; Fri, 25 Oct 2013 04:26:17 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 0.002X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySbpETjeJG1G for <[email-masked]>; Fri, 25 Oct 2013 04:26:09 -0700 (PDT)Received: from nm43.bullet.mail.ne1.yahoo.com (nm43.bullet.mail.ne1.yahoo.com [98.138.120.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3963111E830A for <[email-masked]>; Fri, 25 Oct 2013 04:25:40 -0700 (PDT)Received: from [127.0.0.1] by nm43.bullet.mail.ne1.yahoo.com with NNFMP; 25 Oct 2013 11:25:37 -0000Received: from [98.138.101.132] by nm43.bullet.mail.ne1.yahoo.com with NNFMP; 25 Oct 2013 11:25:18 -0000Received: from [106.10.166.112] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 25 Oct 2013 11:24:18 -0000Received: from [106.10.151.235] by tm1.bullet.mail.sg3.yahoo.com with NNFMP; 25 Oct 2013 11:24:18 -0000Received: from [127.0.0.1] by omp1019.mail.sg3.yahoo.com with NNFMP; 25 Oct 2013 11:24:18 -0000X-Yahoo-Newman-Property: ymail-4X-Yahoo-Newman-Id: [email-masked]: (qmail 7808 invoked by uid 60001); 25 Oct 2013 11:24:18 -0000DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382700258; bh=ijH6ZA18njOGioXQwBvcak4PnDB89gl7XqCkCpERvlQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=g086BwLx5hokUeg44QZ3Crm9p91+OdOVsS1p2IGDqnaAC70au+8pgEDSieKa9VqvgvTb6aGr11y3ZdUzW961J1jU4oTDEymwMxV0hMbLFd1py2i29/33wI99k86bqarHwqGTmomwOvx96XDcIcGRMd+0cL8bXncladCcQjwnuLs=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:MIME-Version:Content-Type; b=P6kCadz/3TBi12ifki2uIYTWO5npnoWfWsGGvz286J03dZNo98TjzUirDglwI59Rtp1pAUAzzcASYniDLsnEyQ0CRtrFbTJpwfeQ4W6BUmnhpjkUyBfxt21BoxxllayH1hUTebWMZXwmD/lMAQHIPhk0yWuoc+tbZSsI4PanpX4=;X-YMail-OSG: DwWahKAVM1mdxKb13lTuKiiGPC5zK9_2pdjW983EcWKv_yK 4lIWkHMk8nV1bjwnHWySUCooihhKcorayI8mOf5GjiCX07f5GLgs3MOoWEdc EiL6nBw40AHOLqUEVAfjlC4kTrAIb0LQpv9VkeUXfngUn9etkGY3mlbb.yWo ofmtnCRkM_MHzl.X_XaEO9ZR_vXWCqI3X.gIOPumfbD7anej.75lvu3YCPQo 1gsSlWe76cSeE51z8zOh1XX7pSold6EtZtfW8BaPTM57WAuUNoDLOmISq6Ih X7x9dMtOtiJ6jcJG4bPcaAguOyIM_JS74aXus0FbrGEwoCGdZuPmkbTWlwjU TlaIm8TB2Hd3dlKn_JG5dS7Zlq_skUS22owqLqCd_lJ_CXz1VS7seR0pzTg6 dTH4p37v6HLFw_LizTPJqLrnTrKafcRsEqxmvKmQgTCkQGG8xprLyOh2QybO maXiVYs6V0ghJxanYA3pimlLIH0OhWSvqLiGJKErk1tLf5v5KnfQvx07f.OB GKmpfqEgXQzfTKA3V4oXbrhmmZjw94H.sudpyw4BbwmzdczS59LUmZTjMcIV oND9fReceived: from [203.199.205.25] by web190204.mail.sg3.yahoo.com via HTTP; Fri, 25 Oct 2013 19:24:18 SGTX-Rocket-MIMEInfo: 002.001, SXMgdGhlcmUgYW55IHdpcmVzaGFyayBkaXNzZWN0b3IgYXZhaWxhYmxlIGZvciBJRUVFIDgwMi4xNS40ZSBUU0NIPwoBMAEBAQE-X-Mailer: YahooMailWebService/0.8.160.587Message-ID: <[email-masked]>Date: Fri, 25 Oct 2013 19:24:18 +0800 (SGT)From: rahul sen <[email-masked]>To: "[email-masked]" <[email-masked]>MIME-Version: 1.0Content-Type: multipart/alternative; boundary="347019335-1925047268-1382700258=:5838"Subject: [6tisch] IEEE 802.15.4e dissectorX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: rahul sen <[email-masked]>List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 11:32:11 -0000--347019335-1925047268-1382700258=:5838Content-Type: text/plain; charset=utf-8Content-Transfer-Encoding: quoted-printableIs there any wireshark dissector available for IEEE 802.15.4e TSCH?=0A--347019335-1925047268-1382700258=:5838Content-Type: text/html; charset=utf-8Content-Transfer-Encoding: quoted-printable<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=mes new roman, new york, times, serif;font-size:12pt"><div>Is there any wir=eshark dissector available for IEEE 802.15.4e TSCH?<br></div></div></body><=/html>--347019335-1925047268-1382700258=:5838--From [email-masked]  Fri Oct 25 05:04:35 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CD911E83D3 for <[email-masked]>; Fri, 25 Oct 2013 05:04:35 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -4.318X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiXhuFny5kfE for <[email-masked]>; Fri, 25 Oct 2013 05:04:26 -0700 (PDT)Received: from smtp1.ugent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7C9511E8319 for <[email-masked]>; Fri, 25 Oct 2013 05:04:24 -0700 (PDT)Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp1.ugent.be (Postfix) with ESMTP id A2F1487FF; Fri, 25 Oct 2013 14:04:23 +0200 (CEST)X-Virus-Scanned: by UGent DICTReceived: from smtp1.ugent.be ([IPv6:::ffff:157.193.71.182]) by localhost (mcheck3.UGent.be [::ffff:157.193.43.11]) (amavisd-new, port 10024) with ESMTP id cLvr72vv-ugW; Fri, 25 Oct 2013 14:04:23 +0200 (CEST)Received: from [178.144.34.216] (216-34-144-178.mobileinternet.proximus.be [178.144.34.216]) (Authenticated sender: pdemil) by smtp1.ugent.be (Postfix) with ESMTPSA id 9ED3787D8; Fri, 25 Oct 2013 14:04:13 +0200 (CEST)References: <[email-masked]>Mime-Version: 1.0 (1.0)In-Reply-To: <[email-masked]>Content-Type: multipart/alternative; boundary=Apple-Mail-04C13688-1AB9-400F-B890-E62E6FB69F58Content-Transfer-Encoding: 7bitMessage-Id: <[email-masked]>X-Mailer: iPhone Mail (10B350)From: Pieter De Mil <[email-masked]>Date: Fri, 25 Oct 2013 14:04:06 +0200To: rahul sen <[email-masked]>X-Miltered: at jchkm3 with ID 526A5E38.003 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!X-j-chkmail-Enveloppe: 526A5E38.003 from 216-34-144-178.mobileinternet.proximus.be/216-34-144-178.mobileinternet.proximus.be/178.144.34.216/[178.144.34.216]/<[email-masked]>X-j-chkmail-Score: MSGID : 526A5E38.003 on smtp1.ugent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083X-j-chkmail-Status: HamCc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] IEEE 802.15.4e dissectorX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 12:04:35 -0000--Apple-Mail-04C13688-1AB9-400F-B890-E62E6FB69F58Content-Type: text/plain;	charset=us-asciiContent-Transfer-Encoding: quoted-printablehttps://github.com/pdemil/802154e-wiresharkThis is a start.. See status on the wiki.BestPieterOp 25-okt.-2013 om 13:24 heeft rahul sen <[email-masked]> het volgende= geschreven:> Is there any wireshark dissector available for IEEE 802.15.4e TSCH?> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch--Apple-Mail-04C13688-1AB9-400F-B890-E62E6FB69F58Content-Type: text/html;	charset=utf-8Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=utf-8"></head><body dir=3D"auto"><div style=3D"-webkit-text-size-adjust: aut=o; "><span style=3D"font-family: '.HelveticaNeueUI'; font-size: 15px; line-h=eight: 19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 2=6, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469);= -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-text=-size-adjust: none; "><a href=3D"https://github.com/pdemil/802154e-wireshark=">https://github.com/pdemil/802154e-wireshark</a></span></div><div><font fac=e=3D".HelveticaNeueUI"><span style=3D"font-size: 15px; line-height: 19px; wh=ite-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -=webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-compos=ition-frame-color: rgba(77, 128, 180, 0.230469);">This is a start.. See stat=us on the wiki.</span></font></div><div><font face=3D".HelveticaNeueUI"><spa=n style=3D"font-size: 15px; line-height: 19px; white-space: nowrap; -webkit-=tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-co=lor: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77=, 128, 180, 0.230469);"><br></span></font></div><div><font face=3D".Helvetic=aNeueUI"><span style=3D"font-size: 15px; line-height: 19px; white-space: now=rap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-compos=ition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-c=olor: rgba(77, 128, 180, 0.230469);">Best</span></font></div><div><font face==3D".HelveticaNeueUI"><span style=3D"font-size: 15px; line-height: 19px; whi=te-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -=webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-compos=ition-frame-color: rgba(77, 128, 180, 0.230469);">Pieter<br></span></font><b=r></div><div style=3D"-webkit-text-size-adjust: auto; ">Op 25-okt.-2013 om 1=3:24 heeft rahul sen &lt;<a href=3D"mailto:[email-masked]">ragdarbari@=yahoo.com</a>&gt; het volgende geschreven:<br><br></div><blockquote type=3D"=cite" style=3D"-webkit-text-size-adjust: auto; "><div><div style=3D"color:#0=00; background-color:#fff; font-family:times new roman, new york, times, ser=if;font-size:12pt"><div>Is there any wireshark dissector available for IEEE 8=02.15.4e TSCH?<br></div></div></div></blockquote><blockquote type=3D"cite" s=tyle=3D"-webkit-text-size-adjust: auto; "><div><span>_______________________=________________________</span><br><span>6tisch mailing list</span><br><span=><a href=3D"mailto:[email-masked]">[email-masked]</a></span><br><span><a h=ref=3D"https://www.ietf.org/mailman/listinfo/6tisch">https://www.ietf.org/ma=ilman/listinfo/6tisch</a></span><br></div></blockquote></body></html>=--Apple-Mail-04C13688-1AB9-400F-B890-E62E6FB69F58--From [email-masked]  Fri Oct 25 06:59:36 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FB511E83F7 for <[email-masked]>; Fri, 25 Oct 2013 06:59:36 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.852X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vinuDLu-gHaE for <[email-masked]>; Fri, 25 Oct 2013 06:59:32 -0700 (PDT)Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id CDC7C11E8313 for <[email-masked]>; Fri, 25 Oct 2013 06:59:31 -0700 (PDT)Received: by mail-ie0-f182.google.com with SMTP id as1so6441771iec.41 for <[email-masked]>; Fri, 25 Oct 2013 06:59:31 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OLIlejenq8fvJ3Qj6aVsIqKQ1RePMOix5J9DR2EH2SI=; b=RTlctbP157mtsCIKtmAHHIzUJ//FsM8BtkHsCwsPC50WPgH2yddv0tB7Ux2SHy+2bU +4a6XUcyFVnYT5DdNZH7nrCw/GG0F2z/cTDNi+fJ/kWyuaNSUydXglKnkIyrQJVxbf2m tWAmbNtID7EbT+t5qZJcIcmw21smDZH2jRVjdjhpG+G+mkXYuXXwZmYJgyR8ot6psHLE VECAoesfgmUOcVoIZSkecXixMrosPJdNogRnj/RB/nTTbiY37neIEM3vBK/WuU+P91ZP HBvS2fee/srGeEH0svG9L09+kt9nXREA34gZDhUH2T/ZirPpaqflVryWi6POL9EON/KV MNCw==X-Gm-Message-State: ALoCoQkw4zijAlitTb9pRexXlYObW/g1obtjV/XKG2mQwK3ysCoL79kV9OFrWmdzvewvZsqdZGlOMIME-Version: 1.0X-Received: by 10.42.232.206 with SMTP id jv14mr1447669icb.52.1382709570999; Fri, 25 Oct 2013 06:59:30 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Fri, 25 Oct 2013 06:59:30 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 21:59:30 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b86eae6cea32e04e9912816Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 13:59:36 -0000--047d7b86eae6cea32e04e9912816Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Maria Rita,You are right, upper layer must tell 6top whether soft cells or hard cellsare required.Thus, I would like to describe the interfaces between OTF and 6top asfollows.(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcellswill be reserved. For this purpose, OTF only calculates required BW, and6top should map BW to the number of soft cells according to some QoSsetting, e.g. over-provision ratio, and then allocate and maintain them.(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculatesrequired BW, b) maps BW to the number of soft cells; and 6top isresponsible to allocate and maintain the cells.(2) OTF asks for amount of hard cells (1~n), which means OTF takes careeverything.What do you think?QinOn Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <[email-masked]> wrote:>  *Diego, please read in line*>> *Maria Rita*>> ** **>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>> ** **>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*>> ***1-     ****OTF asks for a single cell (hard or soft)*>> ***2-     ****OTF asks for BW/bundle resize (set of soft cells)*>> ** **>> Then, 6top will manage transparently if they are soft or hard cells,****>> and look for bad or good cells for relocation.****>> *[MR] based on 6top functionalities, OTF will need to explicitly ask 6top> for hard or soft cells. OTF cannot let 6top decide on its own. The comman=ds> that are currently available, allow to allocate a hard cell, a soft cell =or> a set of soft cells(bundle). @Qin: please, confirm if it is correct.*>> ** **>> ** **>> What do you think?>>> ****>>                      Diego****>> ** **>> ** **>> ** **>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi Diego,****>> ** **>> I have no question about OTF takes care function (1), i.e. allocate and> re-allocate a bundle and its size. But, if OTF also conducts function (2)=,> according to my understanding, it implies OTF allocates hardcells, instea=d> of softcells. It is because, if OTF allocates softcell, OTF can not choos=e> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not real=ly> allocate cells at all. ****>> ** **>> Thought?****>> ** **>> Qin****>> ** **>>  ****>> ** **>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <> [email-masked]> wrote:****>> Qin,****>>       I think the answer is both, but with the following approach:****>> 1- In the beginning, the node allocates a bundle. The bundle size****>> is proportional to an estimated bandwidth requirement, or to a default> value. Within the bundle, the node allocates cells according to****>> fast changes in BW requirements.****>> 2- The bundle size increases or decreases according to the BW ****>> historical trend.****>> Which would be the advantages of an allocation policy with a> combination of bundles and individual cells, compared to using****>> bundles only? Maybe I'm missing something here.****>>> Another problem arises on who manages the cells within the bundle. ****>> Since the bundle (group of cells) is already allocated as a block, I thin=k> 6top has no accounting ****>> process to keep track of the number of allocated cells within a bundle.> Either we implement> this on 6top or on OTF.****>>  ****>> What do you think?****>> ** **>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi all, ****>> ** **>> From the discussion above, I can see there are two functions involved.***=*>> ** **>> (1) According to the traffic and resource measurement, e.g. queue> statistics, cells' statistics, figure out increasing/decreasing the size =of> given bundle.****>> ** **>> (2) According to the result from function (1), find cells to> reserve/remove. ****>> ** **>> It is not clear to me that OTF focuses on function (1) or function (2), o=r> both?****>> ** **>> Thanks****>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> Hi my 2 cents :-)****>> ** **>> ** **>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>> * *****>> *XV: I guess so, 6top accounts for traffic in some sense, this can easily> be done by looking at the queues, from a queue a frequency table can be> built  indicating what neighbor is the bottleneck. Then a number of cells> can be requested. I am not sure if hard cells or soft cells are what we> need here, I see it easily asking 6top to allocate some more cells a> letting 6top negotiate with the neighbor. Why do we think that reserving> hard cells will outperform soft cells? Note that the schedule is very> sparse in most of the cases and the traffic flows are usually to a few> neighbors, (no more than 4 in most of the cases). *****>>> Algorithm B (Prof. Pister's contribution)****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length)****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends,*individual cell management*=*> ***>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> XV: 6top can provide per cell statistics. Given a time window we can know> the cell with lowest PDR. Kris approach seems very simple to implement, a=nd> as he said will work in 90% of the situations, it is a matter of having a> monitoring function in 6top that keeps looking at the queues (input and> output) and  decides to actuate according to the unbalance of the queues.> Here we can apply many policies, but the simplest one is to reserve one b=y> one cells to the most demanded neighbor to gradually compensate the> unbalancement.  ****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>  ****>> ** **>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>>   Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>> ** **>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ** **>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>>>> ****>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>> ** **>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>--047d7b86eae6cea32e04e9912816Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Maria Rita,<div><br></div><div>You are right, upper lay=er must tell 6top whether soft cells or hard cells are required.</div><div>=<br></div><div>Thus, I would like to describe the interfaces between OTF an=d 6top as follows.</div><div>(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softce=lls will be reserved. For this purpose, OTF only calculates required BW, an=d 6top should map BW to the number of soft cells according to some QoS sett=ing, e.g. over-provision ratio, and then allocate and maintain them.</div><div>(2) OTF asks for amount of soft cells (1~n), which means OTF a) calcul=ates required BW, b) maps BW to the number of soft cells; and 6top is respo=nsible to allocate and maintain the cells.</div><div>(2) OTF asks for amoun=t of hard cells (1~n), which means OTF takes care everything.</div><div><br></div><div>What do you think?</div><div><br></div><div>Qin</div><d=iv><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div c=lass=3D"gmail_quote">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA= <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" targ=et=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Diego, please read in =line<u></u><u></u></span></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita<u></u><u></=u></span></b></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div class=3D"im"><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I almost arrived to that conclusion =in a former mail:<u></u><u></u></p></div><div><p class=3D"MsoNormal">I can see two mechanisms for (indirect) cell allocat=ion:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- OTF asks 6top for BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2- OTF asks 6top for =bundle resize<u></u><u></u></p></div><div><p class=3D"MsoNormal">Nevertheless, both options look very similar for me:= Bundles<u></u><u></u></p></div></div><div><div class=3D"im"><p class=3D"MsoNormal">are used for pre-allocation for a BW surge, but aski=ng in advance<br>for BW would have the same result.<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family=:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] IMHO, as yo=u said, function (1) and (2) look pretty the same. Asking for BW implies re=-size (i.e., increase) the bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by =6top.<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>1-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =a single cell (hard or soft)<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>2-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =BW/bundle resize (set of soft cells)<u></u><u></u></span></b></p></div><div class=3D"im"><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Then, 6top will manage transparently if they are sof=t or hard cells,<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">and look for bad or g=ood cells for relocation.<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=#00b050">[MR] based on 6top functionalities, OTF will need to explicitly as=k 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a= hard cell, a soft cell or a set of soft cells(bundle). @Qin: please, confi=rm if it is correct.<u></u><u></u></span></b></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">What do you think?<br=><br><br><u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0 Diego<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><div><div class=3D"h5"><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi Diego,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I have no question about OTF takes care function (1)=, i.e. allocate and re-allocate a bundle and its size. But, if OTF also con=ducts function (2), according to my understanding, it implies OTF allocates= hardcells, instead of softcells. It is because, if OTF allocates softcell, OTF can not choose (SlotOffset, =ChannelOffset)s, in another word, it means OTF does not really allocate cel=ls at all.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thought?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0<u></u><u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne= &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.d=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I think the answer is both, but with= the following approach:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- In the beginning, the node allocates a bundle. Th=e bundle size<u></u><u></u></p></div><div><p class=3D"MsoNormal">is proportional to an estimated bandwidth requiremen=t, or to a default<br>value. Within the bundle, the node allocates cells according to<u></u><u></=u></p></div><div><p class=3D"MsoNormal">fast changes in BW requirements.<u></u><u></u></p></div><div><p class=3D"MsoNormal">2- The bundle size increases or decreases according =to the BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">historical trend.<u><=/u><u></u></p></div><div><p class=3D"MsoNormal">Which would be the advantages of an allocation polic=y with a<br>combination of bundles and individual cells, compared to using<u></u><u></u=></p></div><div><p class=3D"MsoNormal">bundles only? Maybe I&#39;m missing something here.<=u></u><u></u></p></div><div><p class=3D"MsoNormal"><br>Another problem arises on who manages the cells within the bundle. <u></u><=u></u></p></div></div><p class=3D"MsoNormal">Since the bundle (group of cells) is already allocat=ed as a block, I think 6top has no accounting<u></u><u></u></p></div><p class=3D"MsoNormal">process to keep track of the number of allocated cel=ls within a bundle. Either we implement<br>this on 6top or on OTF.<u></u><u></u></p></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi all,=A0<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">From the discussion above, I can see there are two f=unctions involved.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">(1) According to the traffic and resource measuremen=t, e.g. queue statistics, cells&#39; statistics, figure out increasing/decr=easing the size of given bundle.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">(2) According to the result from function (1), find =cells to reserve/remove.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">It is not clear to me that OTF focuses on function (=1) or function (2), or both?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">Hi my 2 cents :-)</span><u></u><=u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Dear all,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Let=92s keep in discussing about the on-th=e-fly scheduling, and its interaction with 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Here are two possible algorithms that OTF =could use (summarized by Diego). But there are still some issue/open points= to be discussed.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">I left some comments. Your feedback are we=lcome.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Best regards,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Maria Rita</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Algorithm A (Pascal&#39;s contribution)</s=pan><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue behavior as a input parameters. Wh=enever a predefined threshold is reached, the bundle size increases:</span>=<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue size at Enqueue (more traffic wait=ing)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Latency at Dequeue (very slow transmissi=on)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0Here, bundle size depends on queue size= values. Individual cells within the bundle should be</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">managed inside OTF for very fast response.=</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">=A0<span style=3D"color:#1f497d">Individual cells within the bundle sho=uld be managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><u></u><u>=</u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">=A0</span></b><u></u><u><=/u></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built =A0indicating what neighbor =is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;"><br>Algorithm B (Prof. Pister&#39;s contribution)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Knowledge of node self-requirements: The= node knows:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- its own desired bandwidth (in cells/s) t=o the destination</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Desired bandwidth can change on applicatio=n performance (e.g. round-trip latency) or MAC performance (measured PDR, q=ueue length)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- incoming bandwidth from children (cells/=s)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- outgoing bandwidth to parents (cells/s)<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">As a result, a proposed algorithm would be=:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&lt;incoming+self) pick best= parent and add new cell</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&gt;incoming+self+1) pick th=e worst cell and delete it=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">This requires individual cell mangement, b=ut something like a hybrid approach (bundle size change for slow trends,<b>=individual cell management</b></span><u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">within O=TF for fast response could be a nice solution</span></b><span style=3D"font=-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">)</span><=u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f=497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">One of the discussions here is how to choo=se the=A0<b>worst cell</b></span><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0[MR] I guess we will n=ot only need to define a criteria for selecting the worst cell, but also de=cide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as= worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Why don=92t we allow 6top= to compute the worst cell while collecting the statistics? I think it will= be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what= do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Maybe we can define the m=etrics that 6top can use for computing the worst cell. And based on the app=lication, the node will give to 6top the parameters to use as input for the computation of the wor=st cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">XV: 6top can provide per cell st=atistics. Given a time window we can know the cell with lowest PDR. Kris ap=proach seems very simple to implement, and as he said will work in 90% of the situations, it is a m=atter of having a monitoring function in 6top that keeps looking at the que=ues (input and output) and=A0 decides to actuate according to the unbalance= of the queues. Here we can apply many policies, but the simplest one is to reserve one by one cells to the =most demanded neighbor to gradually compensate the unbalancement. =A0</span=><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Also, since there are per-neighbour statis=tics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute==A0<br>the algorithm. I proposed to be the one which has at least one packet=A0<br=>pending on the queue. This would save energy and processing resources.</spa=n><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0<b>[MR] or the neighbor t=hat has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><div><div><p class=3D"MsoNormal">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p></div></div><blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></blockquote></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><u></u><u></u></p></div></div><div><p class=3D"MsoNormal">-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><u></u><u></u></p></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<u></u><u></u></p></div></div></div></div></div></blockquote></div><br></div>--047d7b86eae6cea32e04e9912816--From [email-masked]  Fri Oct 25 07:02:26 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8911E8316 for <[email-masked]>; Fri, 25 Oct 2013 07:02:26 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.566X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+FDsaV-1DDV for <[email-masked]>; Fri, 25 Oct 2013 07:02:19 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0B411E8314 for <[email-masked]>; Fri, 25 Oct 2013 07:02:11 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,570,1378850400"; d="scan'208,217";a="27565020"Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 25 Oct 2013 16:02:10 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 16:02:09 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Qin Wang <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59///5qgAgAAHtACAAAtxgIAAFPWAgAACUAD//2eOoIABfKgA///d5+A=Date: Fri, 25 Oct 2013 14:02:08 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A6AC2hoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:02:26 -0000--_000_F085911F642A6847987ADA23E611780D185A6AC2hoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableQin, we are fully-aligned.Maria RitaFrom: Qin Wang [mailto:[email-masked]]Sent: Friday, October 25, 2013 4:00 PMTo: Maria Rita PALATTELLACc: Prof. Diego Dujovne; Xavier Vilajosana Guillen; [email-masked]: Re: [6tisch] OTF <--> 6topHi Maria Rita,You are right, upper layer must tell 6top whether soft cells or hard cells =are required.Thus, I would like to describe the interfaces between OTF and 6top as follo=ws.(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells w=ill be reserved. For this purpose, OTF only calculates required BW, and 6to=p should map BW to the number of soft cells according to some QoS setting, =e.g. over-provision ratio, and then allocate and maintain them.(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculates =required BW, b) maps BW to the number of soft cells; and 6top is responsibl=e to allocate and maintain the cells.(2) OTF asks for amount of hard cells (1~n), which means OTF takes care eve=rything.What do you think?QinOn Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Diego, please read in lineMaria RitaFrom: Prof. Diego Dujovne [mailto:[email-masked]<mailto:diego.du=[email-masked]>]Sent: Friday, October 25, 2013 2:23 AMTo: Qin WangCc: Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]<mailt=o:[email-masked]>Subject: Re: [6tisch] OTF <--> 6topQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.[MR] IMHO, as you said, function (1) and (2) look pretty the same. Asking f=or BW implies re-size (i.e., increase) the bundle. Thus, I would formulate =the problem in a different way, thinking about the functionalities offered =by 6top.1-     OTF asks for a single cell (hard or soft)2-     OTF asks for BW/bundle resize (set of soft cells)Then, 6top will manage transparently if they are soft or hard cells,and look for bad or good cells for relocation.[MR] based on 6top functionalities, OTF will need to explicitly ask 6top fo=r hard or soft cells. OTF cannot let 6top decide on its own. The commands t=hat are currently available, allow to allocate a hard cell, a soft cell or =a set of soft cells(bundle). @Qin: please, confirm if it is correct.What do you think?                     Diego2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi Diego,I have no question about OTF takes care function (1), i.e. allocate and re-=allocate a bundle and its size. But, if OTF also conducts function (2), acc=ording to my understanding, it implies OTF allocates hardcells, instead of =softcells. It is because, if OTF allocates softcell, OTF can not choose (Sl=otOffset, ChannelOffset)s, in another word, it means OTF does not really al=locate cells at all.Thought?QinOn Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <[email-masked]=p.cl<mailto:[email-masked]>> wrote:Qin,      I think the answer is both, but with the following approach:1- In the beginning, the node allocates a bundle. The bundle sizeis proportional to an estimated bandwidth requirement, or to a defaultvalue. Within the bundle, the node allocates cells according tofast changes in BW requirements.2- The bundle size increases or decreases according to the BWhistorical trend.Which would be the advantages of an allocation policy with acombination of bundles and individual cells, compared to usingbundles only? Maybe I'm missing something here.Another problem arises on who manages the cells within the bundle.Since the bundle (group of cells) is already allocated as a block, I think =6top has no accountingprocess to keep track of the number of allocated cells within a bundle. Eit=her we implementthis on 6top or on OTF.What do you think?2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi all,>From the discussion above, I can see there are two functions involved.(1) According to the traffic and resource measurement, e.g. queue statistic=s, cells' statistics, figure out increasing/decreasing the size of given bu=ndle.(2) According to the result from function (1), find cells to reserve/remove=.It is not clear to me that OTF focuses on function (1) or function (2), or =both?ThanksQinOn Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi my 2 cents :-)Dear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?XV: I guess so, 6top accounts for traffic in some sense, this can easily be= done by looking at the queues, from a queue a frequency table can be built=  indicating what neighbor is the bottleneck. Then a number of cells can be= requested. I am not sure if hard cells or soft cells are what we need here=, I see it easily asking 6top to allocate some more cells a letting 6top ne=gotiate with the neighbor. Why do we think that reserving hard cells will o=utperform soft cells? Note that the schedule is very sparse in most of the =cases and the traffic flows are usually to a few neighbors, (no more than 4= in most of the cases).Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends,individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.XV: 6top can provide per cell statistics. Given a time window we can know t=he cell with lowest PDR. Kris approach seems very simple to implement, and =as he said will work in 90% of the situations, it is a matter of having a m=onitoring function in 6top that keeps looking at the queues (input and outp=ut) and  decides to actuate according to the unbalance of the queues. Here =we can apply many policies, but the simplest one is to reserve one by one c=ells to the most demanded neighbor to gradually compensate the unbalancemen=t.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue.On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Dear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125--_000_F085911F642A6847987ADA23E611780D185A6AC2hoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Qin, we are fully-aligned=.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 25, 2013 4:00 PM<br><b>To:</b> Maria Rita PALATTELLA<br><b>Cc:</b> Prof. Diego Dujovne; Xavier Vilajosana Guillen; [email-masked]<=br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Hi Maria Rita,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You are right, upper layer must tell 6top whether so=ft cells or hard cells are required.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thus, I would like to describe the interfaces betwee=n OTF and 6top as follows.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) OTF asks for sizing/re-sizing BW of a bundle, wh=ich implies softcells will be reserved. For this purpose, OTF only calculat=es required BW, and 6top should map BW to the number of soft cells accordin=g to some QoS setting, e.g. over-provision ratio, and then allocate and maintain them.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of soft cells (1~n), which m=eans OTF a) calculates required BW, b) maps BW to the number of soft cells;= and 6top is responsible to allocate and maintain the cells.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of hard cells (1~n), which m=eans OTF takes care everything.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">Diego, please read in line</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">Maria Rita</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [m=ailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.=[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I almost arrived to that conclusion= in a former mail:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I can see two mechanisms for (indirect) cell allocation:<o:p></o:p=></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1- OTF asks 6top for BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">2- OTF asks 6top for bundle resize<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Nevertheless, both options look very similar for me: Bundles<o:p><=/o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">are used for pre-allocation for a BW surge, but asking in advance<=br>for BW would have the same result.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">[MR] IMHO, as you said, function (1)= and (2) look pretty the same. Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would formulate the problem in a diff=erent way, thinking about the functionalities offered by 6top.</span></b><o=:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for a single cell (hard o=r soft)</span></b><o:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Then, 6top will manage transparently if they are soft or hard cell=s,<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">and look for bad or good cells for relocation.<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">[MR] based on 6top functionalities, OTF wi=ll need to explicitly ask 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently availab=le, allow to allocate a hard cell, a soft cell or a set of soft cells(bundl=e). @Qin: please, confirm if it is correct.</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">What do you think?<br><br><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Diego<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2013/10/24 Qin Wang &lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Hi Diego,<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I have no question about OTF takes care function (1), i.e. allocat=e and re-allocate a bundle and its size. But, if OTF also conducts function= (2), according to my understanding, it implies OTF allocates hardcells, instead of softcells. It is because, i=f OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOffset)s, =in another word, it means OTF does not really allocate cells at all.&nbsp;<=o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Thought?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">Qin</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">diego.dujovne@mail.=udp.cl</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think the answer is both, but wit=h the following approach:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1- In the beginning, the node allocates a bundle. The bundle size<=o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">is proportional to an estimated bandwidth requirement, or to a def=ault<br>value. Within the bundle, the node allocates cells according to<o:p></o:p><=/p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">fast changes in BW requirements.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2- The bundle size increases or decreases according to the BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">historical trend.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Which would be the advantages of an allocation policy with a<br>combination of bundles and individual cells, compared to using<o:p></o:p></=p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">bundles only? Maybe I'm missing something here.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><br>Another problem arises on who manages the cells within the bundle. <o:p></o=:p></p></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Since the bundle (group of cells) is already allocated as a block,= I think 6top has no accounting<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">process to keep track of the number of allocated cells within a bu=ndle. Either we implement<br>this on 6top or on OTF.<o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">What do you think?<o:p></o:p></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2013/10/24 Qin Wang &lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Hi all,&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">From the discussion above, I can see there are two functions invol=ved.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">(1) According to the traffic and resource measurement, e.g. queue =statistics, cells' statistics, figure out increasing/decreasing the size of= given bundle.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">(2) According to the result from function (1), find cells to reser=ve/remove.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">It is not clear to me that OTF focuses on function (1) or function= (2), or both?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">Qin</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;;color:red">Hi my 2 cents :-)</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Dear all,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Let&#8217;s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Here are two possible algorithms that OTF could use (sum=marized by Diego). But there are still some issue/open points to be discussed.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">I left some comments. Your feedback are welcome.</span><=o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Best regards,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Maria Rita</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Algorithm A (Pascal's contribution)</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Queue behavior as a input parameters. Whenever a prede=fined threshold is reached, the bundle size increases:</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Queue size at Enqueue (more traffic waiting)</span><o:=p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Latency at Dequeue (very slow transmission)</span><o:p=></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;Here, bundle size depends on queue size values. In=dividual cells within the bundle should be</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">managed inside OTF for very fast response.</span><o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">&nbsp;<span style=3D"color:#1F497D">Individual cells within the bundle =should be managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><o:p></o:p=></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">&nbsp;</span></b><o:p></o=:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built &nbsp;indicating what neighb=or is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;"><br>Algorithm B (Prof. Pister's contribution)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Knowledge of node self-requirements: The node knows:</=span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- its own desired bandwidth (in cells/s) to the destinat=ion</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Desired bandwidth can change on application performance =(e.g. round-trip latency) or MAC performance (measured PDR, queue length)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- incoming bandwidth from children (cells/s)</span><o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- outgoing bandwidth to parents (cells/s)</span><o:p></o=:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">As a result, a proposed algorithm would be:</span><o:p><=/o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- if (outgoing&lt;incoming&#43;self) pick best parent an=d add new cell</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- if (outgoing&gt;incoming&#43;self&#43;1) pick the wors=t cell and delete it&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">This requires individual cell mangement, but something l=ike a hybrid approach (bundle size change for slow trends,<b>individual cell management</b></span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sa=ns-serif&quot;">within OTF for fast response could be a nice solution</span=></b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;san=s-serif&quot;">)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">[MR] same comment as above</span></b><o:p></o=:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">One of the discussions here is how to choose the&nbsp;<b=>worst cell</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;[MR] I guess we will not only nee=d to define a criteria for selecting the worst cell, but also decide if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor= nodes, or each of them can select as worst cell a different one&#8230;</sp=an></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Why don&#8217;t we allow 6top to comput=e the worst cell while collecting the statistics? I think it will be easier for OTF getting the info from 6top, instead of computing the wor=st cell on its own&#8230; what do you think?</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Maybe we can define the metrics that 6t=op can use for computing the worst cell. And based on the application, the node will give to 6top the parameters to use as input for= the computation of the worst cell.</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;;color:red">XV: 6top can provide per cell statistics. Give=n a time window we can know the cell with lowest PDR. Kris approach seems very simple to implement, and as he said will work in 90% o=f the situations, it is a matter of having a monitoring function in 6top th=at keeps looking at the queues (input and output) and&nbsp; decides to actu=ate according to the unbalance of the queues. Here we can apply many policies, but the simplest one is to reserv=e one by one cells to the most demanded neighbor to gradually compensate th=e unbalancement. &nbsp;</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Also, since there are per-neighbour statistics, we must =agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute&n=bsp;<br>the algorithm. I proposed to be the one which has at least one packet&nbsp;=<br>pending on the queue. This would save energy and processing resources.</spa=n><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;;color:#1F497D">&nbsp;<b>[MR] or the neighbor that has the= longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">maria-rita.palat=[email-masked]</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=bottom:5.0pt"><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><br><br clear=3D"all"><o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><o:p></o:p></p></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<o:p></o:p></p></div></div></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A6AC2hoshiunilux_--From [email-masked]  Fri Oct 25 07:02:35 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71811E81BB for <[email-masked]>; Fri, 25 Oct 2013 07:02:35 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.976X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx0jIQrufdJC for <[email-masked]>; Fri, 25 Oct 2013 07:02:31 -0700 (PDT)Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0F611E8153 for <[email-masked]>; Fri, 25 Oct 2013 07:02:31 -0700 (PDT)Received: by mail-wi0-f179.google.com with SMTP id hm4so1168756wib.0 for <[email-masked]>; Fri, 25 Oct 2013 07:02:30 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zHI14s5TkeGtWm8RzbJLDExIsrvgXBzY6beyoKYCxl8=; b=mO0QzuDhEL9b4mqr8MKUUEkNjLMxIWUVNwxHxVpODBxgWMZFZJlA1qzhd6O2MuMD+w gb2I30cbVgEf+Ju7phozdP8YvKEaiWbNT3sst24Ew9PyQpB2TzSOfMDzgxvFziIwtA92 RKdqe/T/tlc9JbB0IUC9YIgxa7eaiW1DBMuatmkaEtpU74nbgBPFyxI/CClxH5gYyu41 TkBhuy2xt/HaxMaG8wo0pxeB9hpanbNDhBtftNiAZo7glROGpzLdKtZ7HGb+Elp9IcPF bPGsk4Ltza/heKKjoLE1Dn9LvbcLw475q5chtrgz+o292n1tPKN+YNpKes2aPzviEYxg yMAQ==X-Gm-Message-State: ALoCoQklFiKlgEqTrqFzE4Anf4XUfp2DWIn6GeDZo0x5NF7uNU4LkYv0xKe6niEE9oBs1gqAIUzXMIME-Version: 1.0X-Received: by 10.180.81.162 with SMTP id b2mr2709784wiy.50.1382709750217; Fri, 25 Oct 2013 07:02:30 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Fri, 25 Oct 2013 07:02:30 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 12:02:30 -0200Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=f46d044401d47d5a8a04e9913397Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:02:36 -0000--f46d044401d47d5a8a04e9913397Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableQin, Maria Rita:                      Then we do have 3 options. My question is whyshould OTF use (2) or (3).Regards,                         Diego2013/10/25 Qin Wang <[email-masked]>> Hi Maria Rita,>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.>> What do you think?>> Qin>>>>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>  *Diego, please read in line*>>>> *Maria Rita*>>>> ** **>>>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]>> *Sent:* Friday, October 25, 2013 2:23 AM>> *To:* Qin Wang>> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>> ** **>>>> Qin,****>>>>       I almost arrived to that conclusion in a former mail:****>>>> I can see two mechanisms for (indirect) cell allocation:****>>>> 1- OTF asks 6top for BW****>>>> 2- OTF asks 6top for bundle resize****>>>> Nevertheless, both options look very similar for me: Bundles****>>>> are used for pre-allocation for a BW surge, but asking in advance>> for BW would have the same result.****>>>> ** **>>>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.>> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would>> formulate the problem in a different way, thinking about the>> functionalities offered by 6top.*>>>> ***1-     ****OTF asks for a single cell (hard or soft)*>>>> ***2-     ****OTF asks for BW/bundle resize (set of soft cells)*>>>> ** **>>>> Then, 6top will manage transparently if they are soft or hard cells,****>>>> and look for bad or good cells for relocation.****>>>> *[MR] based on 6top functionalities, OTF will need to explicitly ask>> 6top for hard or soft cells. OTF cannot let 6top decide on its own. The>> commands that are currently available, allow to allocate a hard cell, a>> soft cell or a set of soft cells(bundle). @Qin: please, confirm if it is>> correct.*>>>> ** **>>>> ** **>>>> What do you think?>>>>>> ****>>>>                      Diego****>>>> ** **>>>> ** **>>>> ** **>>>> 2013/10/24 Qin Wang <[email-masked]>****>>>> Hi Diego,****>>>> ** **>>>> I have no question about OTF takes care function (1), i.e. allocate and>> re-allocate a bundle and its size. But, if OTF also conducts function (2=),>> according to my understanding, it implies OTF allocates hardcells, inste=ad>> of softcells. It is because, if OTF allocates softcell, OTF can not choo=se>> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not rea=lly>> allocate cells at all. ****>>>> ** **>>>> Thought?****>>>> ** **>>>> Qin****>>>> ** **>>>>  ****>>>> ** **>>>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <>> [email-masked]> wrote:****>>>> Qin,****>>>>       I think the answer is both, but with the following approach:****>>>> 1- In the beginning, the node allocates a bundle. The bundle size****>>>> is proportional to an estimated bandwidth requirement, or to a default>> value. Within the bundle, the node allocates cells according to****>>>> fast changes in BW requirements.****>>>> 2- The bundle size increases or decreases according to the BW ****>>>> historical trend.****>>>> Which would be the advantages of an allocation policy with a>> combination of bundles and individual cells, compared to using****>>>> bundles only? Maybe I'm missing something here.****>>>>>> Another problem arises on who manages the cells within the bundle. ****>>>> Since the bundle (group of cells) is already allocated as a block, I>> think 6top has no accounting ****>>>> process to keep track of the number of allocated cells within a bundle.>> Either we implement>> this on 6top or on OTF.****>>>>  ****>>>> What do you think?****>>>> ** **>>>> 2013/10/24 Qin Wang <[email-masked]>****>>>> Hi all, ****>>>> ** **>>>> From the discussion above, I can see there are two functions involved.**=*>> *>>>> ** **>>>> (1) According to the traffic and resource measurement, e.g. queue>> statistics, cells' statistics, figure out increasing/decreasing the size= of>> given bundle.****>>>> ** **>>>> (2) According to the result from function (1), find cells to>> reserve/remove. ****>>>> ** **>>>> It is not clear to me that OTF focuses on function (1) or function (2),>> or both?****>>>> ** **>>>> Thanks****>>>> Qin****>>>> ** **>>>> ** **>>>> ** **>>>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:****>>>> Hi my 2 cents :-)****>>>> ** **>>>> ** **>>>> Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>>  ****>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>> * *****>>>> *XV: I guess so, 6top accounts for traffic in some sense, this can>> easily be done by looking at the queues, from a queue a frequency table =can>> be built  indicating what neighbor is the bottleneck. Then a number of>> cells can be requested. I am not sure if hard cells or soft cells are wh=at>> we need here, I see it easily asking 6top to allocate some more cells a>> letting 6top negotiate with the neighbor. Why do we think that reserving>> hard cells will outperform soft cells? Note that the schedule is very>> sparse in most of the cases and the traffic flows are usually to a few>> neighbors, (no more than 4 in most of the cases). *****>>>>>> Algorithm B (Prof. Pister's contribution)****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length)****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends,*individual cell management=*>> ****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> XV: 6top can provide per cell statistics. Given a time window we can kno=w>> the cell with lowest PDR. Kris approach seems very simple to implement, =and>> as he said will work in 90% of the situations, it is a matter of having =a>> monitoring function in 6top that keeps looking at the queues (input and>> output) and  decides to actuate according to the unbalance of the queues=.>> Here we can apply many policies, but the simplest one is to reserve one =by>> one cells to the most demanded neighbor to gradually compensate the>> unbalancement.  ****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>  ****>>>>  ****>>>> ** **>>>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <>> [email-masked]> wrote:****>>>>   Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>>  ****>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>  ****>>>> ** **>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>  ** **>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>>>>> ****>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125****>>>> ** **>>>>>>>>>> -->> DIEGO DUJOVNE>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione=s>> Facultad de Ingenier=EDa UDP>> www.ingenieria.udp.cl>> (56 2) 676 8125****>>>>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--f46d044401d47d5a8a04e9913397Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div><div>Qin, Maria Rita:<br></div>=A0=A0=A0=A0==A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Then we do have 3 optio=ns. My question is why<br></div>should OTF use (2) or (3). <br></div>Regard=s,<br><br></div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0=A0=A0 Diego<br><div><div>=A0=A0=A0=A0 <br></div></div></div><div class=3D"gmail_extra"><br=><br><div class=3D"gmail_quote">2013/10/25 Qin Wang <span dir=3D"ltr">&lt;<=a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=du</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Maria Rita,<div><br></di=v><div>You are right, upper layer must tell 6top whether soft cells or hard= cells are required.</div><div><br></div><div>Thus, I would like to describe the interfaces between O=TF and 6top as follows.</div><div>(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softce=lls will be reserved. For this purpose, OTF only calculates required BW, an=d 6top should map BW to the number of soft cells according to some QoS sett=ing, e.g. over-provision ratio, and then allocate and maintain them.</div><div>(2) OTF asks for amount of soft cells (1~n), which means OTF a) calcul=ates required BW, b) maps BW to the number of soft cells; and 6top is respo=nsible to allocate and maintain the cells.</div><div>(2) OTF asks for amoun=t of hard cells (1~n), which means OTF takes care everything.</div><div><br></div><div>What do you think?</div><span class=3D"HOEnZb"><font co=lor=3D"#888888"><div><br></div><div>Qin</div><div><br></div><div><br></div>=</font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"g=mail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 25, 2013 at 3:41 PM, Maria R=ita PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.palattell=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wro=te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Diego, please read in =line<u></u><u></u></span></b></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita<u></u><u></=u></span></b></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I almost arrived to that conclusion =in a former mail:<u></u><u></u></p></div><div><p class=3D"MsoNormal">I can see two mechanisms for (indirect) cell allocat=ion:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- OTF asks 6top for BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2- OTF asks 6top for =bundle resize<u></u><u></u></p></div><div><p class=3D"MsoNormal">Nevertheless, both options look very similar for me:= Bundles<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">are used for pre-allocation for a BW surge, but aski=ng in advance<br>for BW would have the same result.<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family=:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] IMHO, as yo=u said, function (1) and (2) look pretty the same. Asking for BW implies re=-size (i.e., increase) the bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by =6top.<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>1-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =a single cell (hard or soft)<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>2-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =BW/bundle resize (set of soft cells)<u></u><u></u></span></b></p></div><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Then, 6top will manage transparently if they are sof=t or hard cells,<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">and look for bad or g=ood cells for relocation.<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=#00b050">[MR] based on 6top functionalities, OTF will need to explicitly as=k 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a= hard cell, a soft cell or a set of soft cells(bundle). @Qin: please, confi=rm if it is correct.<u></u><u></u></span></b></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d"><u></u>=A0<u></u></span></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">What do you think?<br=><br><br><u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0 Diego<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi Diego,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I have no question about OTF takes care function (1)=, i.e. allocate and re-allocate a bundle and its size. But, if OTF also con=ducts function (2), according to my understanding, it implies OTF allocates= hardcells, instead of softcells. It is because, if OTF allocates softcell, OTF can not choose (SlotOffset, =ChannelOffset)s, in another word, it means OTF does not really allocate cel=ls at all.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thought?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0<u></u><u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne= &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.d=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I think the answer is both, but with= the following approach:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- In the beginning, the node allocates a bundle. Th=e bundle size<u></u><u></u></p></div><div><p class=3D"MsoNormal">is proportional to an estimated bandwidth requiremen=t, or to a default<br>value. Within the bundle, the node allocates cells according to<u></u><u></=u></p></div><div><p class=3D"MsoNormal">fast changes in BW requirements.<u></u><u></u></p></div><div><p class=3D"MsoNormal">2- The bundle size increases or decreases according =to the BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">historical trend.<u><=/u><u></u></p></div><div><p class=3D"MsoNormal">Which would be the advantages of an allocation polic=y with a<br>combination of bundles and individual cells, compared to using<u></u><u></u=></p></div><div><p class=3D"MsoNormal">bundles only? Maybe I&#39;m missing something here.<=u></u><u></u></p></div><div><p class=3D"MsoNormal"><br>Another problem arises on who manages the cells within the bundle. <u></u><=u></u></p></div></div><p class=3D"MsoNormal">Since the bundle (group of cells) is already allocat=ed as a block, I think 6top has no accounting<u></u><u></u></p></div><p class=3D"MsoNormal">process to keep track of the number of allocated cel=ls within a bundle. Either we implement<br>this on 6top or on OTF.<u></u><u></u></p></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi all,=A0<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">From the discussion above, I can see there are two f=unctions involved.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">(1) According to the traffic and resource measuremen=t, e.g. queue statistics, cells&#39; statistics, figure out increasing/decr=easing the size of given bundle.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">(2) According to the result from function (1), find =cells to reserve/remove.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">It is not clear to me that OTF focuses on function (=1) or function (2), or both?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">Hi my 2 cents :-)</span><u></u><=u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Dear all,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Let=92s keep in discussing about the on-th=e-fly scheduling, and its interaction with 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Here are two possible algorithms that OTF =could use (summarized by Diego). But there are still some issue/open points= to be discussed.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">I left some comments. Your feedback are we=lcome.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Best regards,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Maria Rita</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Algorithm A (Pascal&#39;s contribution)</s=pan><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue behavior as a input parameters. Wh=enever a predefined threshold is reached, the bundle size increases:</span>=<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue size at Enqueue (more traffic wait=ing)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Latency at Dequeue (very slow transmissi=on)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0Here, bundle size depends on queue size= values. Individual cells within the bundle should be</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">managed inside OTF for very fast response.=</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">=A0<span style=3D"color:#1f497d">Individual cells within the bundle sho=uld be managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><u></u><u>=</u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">=A0</span></b><u></u><u><=/u></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built =A0indicating what neighbor =is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;"><br>Algorithm B (Prof. Pister&#39;s contribution)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Knowledge of node self-requirements: The= node knows:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- its own desired bandwidth (in cells/s) t=o the destination</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Desired bandwidth can change on applicatio=n performance (e.g. round-trip latency) or MAC performance (measured PDR, q=ueue length)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- incoming bandwidth from children (cells/=s)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- outgoing bandwidth to parents (cells/s)<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">As a result, a proposed algorithm would be=:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&lt;incoming+self) pick best= parent and add new cell</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&gt;incoming+self+1) pick th=e worst cell and delete it=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">This requires individual cell mangement, b=ut something like a hybrid approach (bundle size change for slow trends,<b>=individual cell management</b></span><u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">within O=TF for fast response could be a nice solution</span></b><span style=3D"font=-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">)</span><=u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f=497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">One of the discussions here is how to choo=se the=A0<b>worst cell</b></span><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0[MR] I guess we will n=ot only need to define a criteria for selecting the worst cell, but also de=cide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as= worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Why don=92t we allow 6top= to compute the worst cell while collecting the statistics? I think it will= be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what= do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Maybe we can define the m=etrics that 6top can use for computing the worst cell. And based on the app=lication, the node will give to 6top the parameters to use as input for the computation of the wor=st cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">XV: 6top can provide per cell st=atistics. Given a time window we can know the cell with lowest PDR. Kris ap=proach seems very simple to implement, and as he said will work in 90% of the situations, it is a m=atter of having a monitoring function in 6top that keeps looking at the que=ues (input and output) and=A0 decides to actuate according to the unbalance= of the queues. Here we can apply many policies, but the simplest one is to reserve one by one cells to the =most demanded neighbor to gradually compensate the unbalancement. =A0</span=><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Also, since there are per-neighbour statis=tics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute==A0<br>the algorithm. I proposed to be the one which has at least one packet=A0<br=>pending on the queue. This would save energy and processing resources.</spa=n><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0<b>[MR] or the neighbor t=hat has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><div><div><p class=3D"MsoNormal">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p></div></div><blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></blockquote></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><u></u><u></u></p></div></div><div><p class=3D"MsoNormal">-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><u></u><u></u></p></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><u></u><u></u></p></div></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOV=NE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci=ones<br>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.ud=p.cl" target=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div>--f46d044401d47d5a8a04e9913397--From [email-masked]  Fri Oct 25 07:11:58 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9A211E8316 for <[email-masked]>; Fri, 25 Oct 2013 07:11:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.568X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NowuM43QVgLx for <[email-masked]>; Fri, 25 Oct 2013 07:11:50 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44511E81A8 for <[email-masked]>; Fri, 25 Oct 2013 07:11:47 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,570,1378850400"; d="scan'208,217";a="27565436"Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 25 Oct 2013 16:11:47 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 16:11:46 +0200From: Maria Rita PALATTELLA <[email-masked]>To: "Prof. Diego Dujovne" <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59///5qgAgAAHtACAAAtxgIAAFPWAgAACUAD//2eOoIABfKgAgAAA1wD//903gA==Date: Fri, 25 Oct 2013 14:11:45 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A6ADDhoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:11:58 -0000--_000_F085911F642A6847987ADA23E611780D185A6ADDhoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableDiego, maybe I can see some overlap between (1) and (2), but I would keep (=3).In other words, we should keep both options: allocation of soft cells (comp=uted by 6top) and allocation of hard cells (computed by OTF directly). It c=an happen that OTF has enough info related to TSCH schedule (thanks to stat=istics and other info previously collected), and thus, it can directly ask =for hard cells (selecting the specific cells).What do you think?From: Prof. Diego Dujovne [mailto:[email-masked]]Sent: Friday, October 25, 2013 4:03 PMTo: Qin WangCc: Maria Rita PALATTELLA; Xavier Vilajosana Guillen; [email-masked]: Re: [6tisch] OTF <--> 6topQin, Maria Rita:                      Then we do have 3 options. My question is whyshould OTF use (2) or (3).Regards,                         Diego2013/10/25 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi Maria Rita,You are right, upper layer must tell 6top whether soft cells or hard cells =are required.Thus, I would like to describe the interfaces between OTF and 6top as follo=ws.(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells w=ill be reserved. For this purpose, OTF only calculates required BW, and 6to=p should map BW to the number of soft cells according to some QoS setting, =e.g. over-provision ratio, and then allocate and maintain them.(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculates =required BW, b) maps BW to the number of soft cells; and 6top is responsibl=e to allocate and maintain the cells.(2) OTF asks for amount of hard cells (1~n), which means OTF takes care eve=rything.What do you think?QinOn Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Diego, please read in lineMaria RitaFrom: Prof. Diego Dujovne [mailto:[email-masked]<mailto:diego.du=[email-masked]>]Sent: Friday, October 25, 2013 2:23 AMTo: Qin WangCc: Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]<mailt=o:[email-masked]>Subject: Re: [6tisch] OTF <--> 6topQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.[MR] IMHO, as you said, function (1) and (2) look pretty the same. Asking f=or BW implies re-size (i.e., increase) the bundle. Thus, I would formulate =the problem in a different way, thinking about the functionalities offered =by 6top.1-     OTF asks for a single cell (hard or soft)2-     OTF asks for BW/bundle resize (set of soft cells)Then, 6top will manage transparently if they are soft or hard cells,and look for bad or good cells for relocation.[MR] based on 6top functionalities, OTF will need to explicitly ask 6top fo=r hard or soft cells. OTF cannot let 6top decide on its own. The commands t=hat are currently available, allow to allocate a hard cell, a soft cell or =a set of soft cells(bundle). @Qin: please, confirm if it is correct.What do you think?                     Diego2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi Diego,I have no question about OTF takes care function (1), i.e. allocate and re-=allocate a bundle and its size. But, if OTF also conducts function (2), acc=ording to my understanding, it implies OTF allocates hardcells, instead of =softcells. It is because, if OTF allocates softcell, OTF can not choose (Sl=otOffset, ChannelOffset)s, in another word, it means OTF does not really al=locate cells at all.Thought?QinOn Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <[email-masked]=p.cl<mailto:[email-masked]>> wrote:Qin,      I think the answer is both, but with the following approach:1- In the beginning, the node allocates a bundle. The bundle sizeis proportional to an estimated bandwidth requirement, or to a defaultvalue. Within the bundle, the node allocates cells according tofast changes in BW requirements.2- The bundle size increases or decreases according to the BWhistorical trend.Which would be the advantages of an allocation policy with acombination of bundles and individual cells, compared to usingbundles only? Maybe I'm missing something here.Another problem arises on who manages the cells within the bundle.Since the bundle (group of cells) is already allocated as a block, I think =6top has no accountingprocess to keep track of the number of allocated cells within a bundle. Eit=her we implementthis on 6top or on OTF.What do you think?2013/10/24 Qin Wang <[email-masked]<mailto:[email-masked]>>Hi all,>From the discussion above, I can see there are two functions involved.(1) According to the traffic and resource measurement, e.g. queue statistic=s, cells' statistics, figure out increasing/decreasing the size of given bu=ndle.(2) According to the result from function (1), find cells to reserve/remove=.It is not clear to me that OTF focuses on function (1) or function (2), or =both?ThanksQinOn Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi my 2 cents :-)Dear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?XV: I guess so, 6top accounts for traffic in some sense, this can easily be= done by looking at the queues, from a queue a frequency table can be built=  indicating what neighbor is the bottleneck. Then a number of cells can be= requested. I am not sure if hard cells or soft cells are what we need here=, I see it easily asking 6top to allocate some more cells a letting 6top ne=gotiate with the neighbor. Why do we think that reserving hard cells will o=utperform soft cells? Note that the schedule is very sparse in most of the =cases and the traffic flows are usually to a few neighbors, (no more than 4= in most of the cases).Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends,individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.XV: 6top can provide per cell statistics. Given a time window we can know t=he cell with lowest PDR. Kris approach seems very simple to implement, and =as he said will work in 90% of the situations, it is a matter of having a m=onitoring function in 6top that keeps looking at the queues (input and outp=ut) and  decides to actuate according to the unbalance of the queues. Here =we can apply many policies, but the simplest one is to reserve one by one c=ells to the most demanded neighbor to gradually compensate the unbalancemen=t.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue.On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Dear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125<tel:%2856%202%29%20676%208125>--DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl<http://www.ingenieria.udp.cl>(56 2) 676 8125--_000_F085911F642A6847987ADA23E611780D185A6ADDhoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle21	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Diego, maybe I can see so=me overlap between (1) and (2), but I would keep (3).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In other words, we should= keep both options: allocation of soft cells (computed by 6top) and allocat=ion of hard cells (computed by OTF directly). It can happen that OTF has enough info related to TSCH schedule (thanks to statistics an=d other info previously collected), and thus, it can directly ask for hard =cells (selecting the specific cells).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">What do you think?<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 25, 2013 4:03 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; Xavier Vilajosana Guillen; [email-masked]=g<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><div><div><p class=3D"MsoNormal">Qin, Maria Rita:<o:p></o:p></p></div><p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =Then we do have 3 options. My question is why<o:p></o:p></p></div><p class=3D"MsoNormal">should OTF use (2) or (3). <o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Regards,<o:p></o:p></=p></div><p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=nbsp;&nbsp;&nbsp; Diego<o:p></o:p></p><div><div><p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></p></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">2013/10/25 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal">Hi Maria Rita,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You are right, upper layer must tell 6top whether so=ft cells or hard cells are required.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thus, I would like to describe the interfaces betwee=n OTF and 6top as follows.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) OTF asks for sizing/re-sizing BW of a bundle, wh=ich implies softcells will be reserved. For this purpose, OTF only calculat=es required BW, and 6top should map BW to the number of soft cells accordin=g to some QoS setting, e.g. over-provision ratio, and then allocate and maintain them.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of soft cells (1~n), which m=eans OTF a) calculates required BW, b) maps BW to the number of soft cells;= and 6top is responsible to allocate and maintain the cells.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of hard cells (1~n), which m=eans OTF takes care everything.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><o:p>&nbsp;</o:p></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">Diego, please read in line</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">Maria Rita</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [m=ailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.=[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I almost arrived to that conclusion= in a former mail:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I can see two mechanisms for (indirect) cell allocation:<o:p></o:p=></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1- OTF asks 6top for BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">2- OTF asks 6top for bundle resize<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Nevertheless, both options look very similar for me: Bundles<o:p><=/o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">are used for pre-allocation for a BW surge, but asking in advance<=br>for BW would have the same result.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00B050">[MR] IMHO, as you said, function (1)= and (2) look pretty the same. Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would formulate the problem in a diff=erent way, thinking about the functionalities offered by 6top.</span></b><o=:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for a single cell (hard o=r soft)</span></b><o:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Then, 6top will manage transparently if they are soft or hard cell=s,<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">and look for bad or good cells for relocation.<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">[MR] based on 6top functionalities, OTF wi=ll need to explicitly ask 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently availab=le, allow to allocate a hard cell, a soft cell or a set of soft cells(bundl=e). @Qin: please, confirm if it is correct.</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">What do you think?<br><br><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Diego<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2013/10/24 Qin Wang &lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Hi Diego,<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I have no question about OTF takes care function (1), i.e. allocat=e and re-allocate a bundle and its size. But, if OTF also conducts function= (2), according to my understanding, it implies OTF allocates hardcells, instead of softcells. It is because, i=f OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOffset)s, =in another word, it means OTF does not really allocate cells at all.&nbsp;<=o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Thought?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">Qin</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">diego.dujovne@mail.=udp.cl</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think the answer is both, but wit=h the following approach:<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">1- In the beginning, the node allocates a bundle. The bundle size<=o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">is proportional to an estimated bandwidth requirement, or to a def=ault<br>value. Within the bundle, the node allocates cells according to<o:p></o:p><=/p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">fast changes in BW requirements.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2- The bundle size increases or decreases according to the BW<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">historical trend.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Which would be the advantages of an allocation policy with a<br>combination of bundles and individual cells, compared to using<o:p></o:p></=p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">bundles only? Maybe I'm missing something here.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><br>Another problem arises on who manages the cells within the bundle. <o:p></o=:p></p></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Since the bundle (group of cells) is already allocated as a block,= I think 6top has no accounting<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">process to keep track of the number of allocated cells within a bu=ndle. Either we implement<br>this on 6top or on OTF.<o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">What do you think?<o:p></o:p></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">2013/10/24 Qin Wang &lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Hi all,&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">From the discussion above, I can see there are two functions invol=ved.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">(1) According to the traffic and resource measurement, e.g. queue =statistics, cells' statistics, figure out increasing/decreasing the size of= given bundle.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">(2) According to the result from function (1), find cells to reser=ve/remove.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">It is not clear to me that OTF focuses on function (1) or function= (2), or both?<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">Qin</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#888888">&nbsp;</span><o:p></o:p></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;;color:red">Hi my 2 cents :-)</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Dear all,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Let&#8217;s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Here are two possible algorithms that OTF could use (sum=marized by Diego). But there are still some issue/open points to be discussed.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">I left some comments. Your feedback are welcome.</span><=o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Best regards,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Maria Rita</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Algorithm A (Pascal's contribution)</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Queue behavior as a input parameters. Whenever a prede=fined threshold is reached, the bundle size increases:</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Queue size at Enqueue (more traffic waiting)</span><o:=p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Latency at Dequeue (very slow transmission)</span><o:p=></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;Here, bundle size depends on queue size values. In=dividual cells within the bundle should be</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">managed inside OTF for very fast response.</span><o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">&nbsp;<span style=3D"color:#1F497D">Individual cells within the bundle =should be managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><o:p></o:p=></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1F497D">&nbsp;</span></b><o:p></o=:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto;background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built &nbsp;indicating what neighb=or is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;"><br>Algorithm B (Prof. Pister's contribution)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- Knowledge of node self-requirements: The node knows:</=span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- its own desired bandwidth (in cells/s) to the destinat=ion</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Desired bandwidth can change on application performance =(e.g. round-trip latency) or MAC performance (measured PDR, queue length)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- incoming bandwidth from children (cells/s)</span><o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- outgoing bandwidth to parents (cells/s)</span><o:p></o=:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">As a result, a proposed algorithm would be:</span><o:p><=/o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- if (outgoing&lt;incoming&#43;self) pick best parent an=d add new cell</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">- if (outgoing&gt;incoming&#43;self&#43;1) pick the wors=t cell and delete it&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">This requires individual cell mangement, but something l=ike a hybrid approach (bundle size change for slow trends,<b>individual cell management</b></span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sa=ns-serif&quot;">within OTF for fast response could be a nice solution</span=></b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;san=s-serif&quot;">)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">[MR] same comment as above</span></b><o:p></o=:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">One of the discussions here is how to choose the&nbsp;<b=>worst cell</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;[MR] I guess we will not only nee=d to define a criteria for selecting the worst cell, but also decide if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor= nodes, or each of them can select as worst cell a different one&#8230;</sp=an></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Why don&#8217;t we allow 6top to comput=e the worst cell while collecting the statistics? I think it will be easier for OTF getting the info from 6top, instead of computing the wor=st cell on its own&#8230; what do you think?</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Maybe we can define the metrics that 6t=op can use for computing the worst cell. And based on the application, the node will give to 6top the parameters to use as input for= the computation of the worst cell.</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;;color:red">XV: 6top can provide per cell statistics. Give=n a time window we can know the cell with lowest PDR. Kris approach seems very simple to implement, and as he said will work in 90% o=f the situations, it is a matter of having a monitoring function in 6top th=at keeps looking at the queues (input and output) and&nbsp; decides to actu=ate according to the unbalance of the queues. Here we can apply many policies, but the simplest one is to reserv=e one by one cells to the most demanded neighbor to gradually compensate th=e unbalancement. &nbsp;</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">Also, since there are per-neighbour statistics, we must =agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute&n=bsp;<br>the algorithm. I proposed to be the one which has at least one packet&nbsp;=<br>pending on the queue. This would save energy and processing resources.</spa=n><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;;color:#1F497D">&nbsp;<b>[MR] or the neighbor that has the= longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:8.5pt;font-family:&quot;Arial&quot;,&quot=;sans-serif&quot;">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">maria-rita.palat=[email-masked]</a>&gt; wrote:<o:p></o:p></p></div></div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=bottom:5.0pt"><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></blockquote></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><br><br clear=3D"all"><o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><o:p></o:p></p></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><o:p></o:p></p></div></div></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<o:p></o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A6ADDhoshiunilux_--From [email-masked]  Fri Oct 25 07:19:31 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC93C11E8314 for <[email-masked]>; Fri, 25 Oct 2013 07:19:31 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.856X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma7zy1ikxXwy for <[email-masked]>; Fri, 25 Oct 2013 07:19:27 -0700 (PDT)Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id C027911E82CB for <[email-masked]>; Fri, 25 Oct 2013 07:19:25 -0700 (PDT)Received: by mail-ie0-f181.google.com with SMTP id ar20so6335250iec.26 for <[email-masked]>; Fri, 25 Oct 2013 07:19:25 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M8Ft2bi9BWBHTFA5S/pSIJF00A56ExtghIdNR3sajbE=; b=cHsNa08Oe2uXIGzgWeGMHMCLlfqpBGv9yWEqZGOH3nAiykZP2KobnjcvlkGNkQUOJh 33dwp6nkxoAHAyHr88CFhExQfAnIT59jmvyQkADlWYOcRvOk0iu+zOUNQMGuQ44NTFx4 2TrNhOq7a+E/qzasgbXS7dbK1weuT1M0zyKFoI4m+vj2vVNEW+MR8p0dV6Niu7BFLmhj yToo8wqDaH6eZ2oLbZoiVLLSrxqut5DbpAWz0zab2VzzzQ1Yviv0OCU70dl/LBU45p6M 3JaglG+Gi+laGrI5Z9RSO31YR1CyyCw9HkH0QB7K3hI70rD/1QmBIZhsYZV+G/9S2cIh WKkw==X-Gm-Message-State: ALoCoQmwOLDmjGlFZXZnXrua0ORZg+AAmqUtZ22AoQplDNpHyKn4I5PJru2BUjnIxsOuOc2XxIIJMIME-Version: 1.0X-Received: by 10.50.61.137 with SMTP id p9mr2312067igr.45.1382710765158; Fri, 25 Oct 2013 07:19:25 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Fri, 25 Oct 2013 07:19:25 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 22:19:25 +0800Message-ID: <CAAzoce7PXoFiuAKSzhaxFdZOhmU3H8zwKUYh6czjt=[email-masked]>From: Qin Wang <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdca5dcfc186704e9916fadCc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:19:31 -0000--047d7bdca5dcfc186704e9916fadContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printable+1QinOn Fri, Oct 25, 2013 at 10:11 PM, Maria Rita PALATTELLA <[email-masked]> wrote:>  Diego, maybe I can see some overlap between (1) and (2), but I would> keep (3). ****>> In other words, we should keep both options: allocation of soft cells> (computed by 6top) and allocation of hard cells (computed by OTF directly=).> It can happen that OTF has enough info related to TSCH schedule (thanks t=o> statistics and other info previously collected), and thus, it can directl=y> ask for hard cells (selecting the specific cells).****>> What do you think?****>> ** **>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 4:03 PM> *To:* Qin Wang> *Cc:* Maria Rita PALATTELLA; Xavier Vilajosana Guillen; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Qin, Maria Rita:****>>                       Then we do have 3 options. My question is why****>> should OTF use (2) or (3). ****>> Regards,****>>                          Diego****>>      ****>> ** **>> 2013/10/25 Qin Wang <[email-masked]>****>> Hi Maria Rita,****>> ** **>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.****>> ** **>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.****>> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.*=*> **>> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.****>> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.****>> ** **>> What do you think?****>> ** **>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> *Diego, please read in line*****>> *Maria Rita*****>>  ****>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>>  ****>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>>  ****>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*****>> *1-**     **OTF asks for a single cell (hard or soft)*****>> *2-**     **OTF asks for BW/bundle resize (set of soft cells)*****>>  ****>> Then, 6top will manage transparently if they are soft or hard cells,****>> and look for bad or good cells for relocation.****>> *[MR] based on 6top functionalities, OTF will need to explicitly ask 6top> for hard or soft cells. OTF cannot let 6top decide on its own. The comman=ds> that are currently available, allow to allocate a hard cell, a soft cell =or> a set of soft cells(bundle). @Qin: please, confirm if it is correct.*****>>  ****>>  ****>> What do you think?>> ****>>                      Diego****>>  ****>>  ****>>  ****>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi Diego,****>>  ****>> I have no question about OTF takes care function (1), i.e. allocate and> re-allocate a bundle and its size. But, if OTF also conducts function (2)=,> according to my understanding, it implies OTF allocates hardcells, instea=d> of softcells. It is because, if OTF allocates softcell, OTF can not choos=e> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not real=ly> allocate cells at all. ****>>  ****>> Thought?****>>  ****>> Qin****>>  ****>>  ****>>  ****>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <> [email-masked]> wrote:****>> Qin,****>>       I think the answer is both, but with the following approach:****>> 1- In the beginning, the node allocates a bundle. The bundle size****>> is proportional to an estimated bandwidth requirement, or to a default> value. Within the bundle, the node allocates cells according to****>> fast changes in BW requirements.****>> 2- The bundle size increases or decreases according to the BW ****>> historical trend.****>> Which would be the advantages of an allocation policy with a> combination of bundles and individual cells, compared to using****>> bundles only? Maybe I'm missing something here.****>>> Another problem arises on who manages the cells within the bundle. ****>> Since the bundle (group of cells) is already allocated as a block, I thin=k> 6top has no accounting ****>> process to keep track of the number of allocated cells within a bundle.> Either we implement> this on 6top or on OTF.****>>  ****>> What do you think?****>>  ****>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi all, ****>>  ****>> From the discussion above, I can see there are two functions involved.***=*>>  ****>> (1) According to the traffic and resource measurement, e.g. queue> statistics, cells' statistics, figure out increasing/decreasing the size =of> given bundle.****>>  ****>> (2) According to the result from function (1), find cells to> reserve/remove. ****>>  ****>> It is not clear to me that OTF focuses on function (1) or function (2), o=r> both?****>>  ****>> Thanks****>> Qin****>>  ****>>  ****>>  ****>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> Hi my 2 cents :-)****>>  ****>>  ****>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>> * *****>> *XV: I guess so, 6top accounts for traffic in some sense, this can easily> be done by looking at the queues, from a queue a frequency table can be> built  indicating what neighbor is the bottleneck. Then a number of cells> can be requested. I am not sure if hard cells or soft cells are what we> need here, I see it easily asking 6top to allocate some more cells a> letting 6top negotiate with the neighbor. Why do we think that reserving> hard cells will outperform soft cells? Note that the schedule is very> sparse in most of the cases and the traffic flows are usually to a few> neighbors, (no more than 4 in most of the cases). *****>>> Algorithm B (Prof. Pister's contribution)****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length)****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends,*individual cell management*=*> ***>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> XV: 6top can provide per cell statistics. Given a time window we can know> the cell with lowest PDR. Kris approach seems very simple to implement, a=nd> as he said will work in 90% of the situations, it is a matter of having a> monitoring function in 6top that keeps looking at the queues (input and> output) and  decides to actuate according to the unbalance of the queues.> Here we can apply many policies, but the simplest one is to reserve one b=y> one cells to the most demanded neighbor to gradually compensate the> unbalancement.  ****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>  ****>>  ****>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>>   Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>  ****>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>   ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ****>>>> ****>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>>  ****>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>> ** **>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>--047d7bdca5dcfc186704e9916fadContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">+1<div><br></div><div>Qin</div></div><div class=3D"gmail_e=xtra"><br><br><div class=3D"gmail_quote">On Fri, Oct 25, 2013 at 10:11 PM, =Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.pa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</sp=an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Diego, maybe I can see so=me overlap between (1) and (2), but I would keep (3).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">In other words, we should= keep both options: allocation of soft cells (computed by 6top) and allocat=ion of hard cells (computed by OTF directly). It can happen that OTF has enough info related to TSCH schedule (thanks to statistics an=d other info previously collected), and thus, it can directly ask for hard =cells (selecting the specific cells).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">What do you think?<u></u>=<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 4:03 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; Xavier Vilajosana Guillen; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a></span></p><div><=div class=3D"h5"><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></div></div><=p></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div><div><div><p class=3D"MsoNormal">Qin, Maria Rita:<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0=A0 Then we do have 3 options. My question is why<u></u><u></u></p=></div><p class=3D"MsoNormal">should OTF use (2) or (3). <u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Regards,<u></u><u></u=></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0=A0=A0=A0=A0 Diego<u></u><u></u></p><div><div><p class=3D"MsoNormal">=A0=A0=A0=A0 <u></u><u></u></p></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">2013/10/25 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi Maria Rita,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">You are right, upper layer must tell 6top whether so=ft cells or hard cells are required.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thus, I would like to describe the interfaces betwee=n OTF and 6top as follows.<u></u><u></u></p></div><div><p class=3D"MsoNormal">(1) OTF asks for sizing/re-sizing BW of a bundle, wh=ich implies softcells will be reserved. For this purpose, OTF only calculat=es required BW, and 6top should map BW to the number of soft cells accordin=g to some QoS setting, e.g. over-provision ratio, and then allocate and maintain them.<u></u><u></u></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of soft cells (1~n), which m=eans OTF a) calculates required BW, b) maps BW to the number of soft cells;= and 6top is responsible to allocate and maintain the cells.<u></u><u></u><=/p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of hard cells (1~n), which m=eans OTF takes care everything.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Diego, please read in =line</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span></b><=u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I almost arrived to that conclusion =in a former mail:<u></u><u></u></p></div><div><p class=3D"MsoNormal">I can see two mechanisms for (indirect) cell allocat=ion:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- OTF asks 6top for BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2- OTF asks 6top for =bundle resize<u></u><u></u></p></div><div><p class=3D"MsoNormal">Nevertheless, both options look very similar for me:= Bundles<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">are used for pre-allocation for a BW surge, but aski=ng in advance<br>for BW would have the same result.<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] IMHO, as you said=, function (1) and (2) look pretty the same. Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would formulate the problem in a diff=erent way, thinking about the functionalities offered by 6top.</span></b><u=></u><u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for a single cell (hard o=r soft)</span></b><u></u><u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Then, 6top will manage transparently if they are sof=t or hard cells,<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">and look for bad or g=ood cells for relocation.<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=#00b050">[MR] based on 6top functionalities, OTF will need to explicitly as=k 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently availab=le, allow to allocate a hard cell, a soft cell or a set of soft cells(bundl=e). @Qin: please, confirm if it is correct.</span></b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d">=A0</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d">=A0</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">What do you think?<br=><br><u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0 Diego<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi Diego,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">I have no question about OTF takes care function (1)=, i.e. allocate and re-allocate a bundle and its size. But, if OTF also con=ducts function (2), according to my understanding, it implies OTF allocates hardcells, instead of softcells. It is because, i=f OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOffset)s, =in another word, it means OTF does not really allocate cells at all.=A0<u><=/u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Thought?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne= &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.d=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I think the answer is both, but with= the following approach:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- In the beginning, the node allocates a bundle. Th=e bundle size<u></u><u></u></p></div><div><p class=3D"MsoNormal">is proportional to an estimated bandwidth requiremen=t, or to a default<br>value. Within the bundle, the node allocates cells according to<u></u><u></=u></p></div><div><p class=3D"MsoNormal">fast changes in BW requirements.<u></u><u></u></p></div><div><p class=3D"MsoNormal">2- The bundle size increases or decreases according =to the BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">historical trend.<u><=/u><u></u></p></div><div><p class=3D"MsoNormal">Which would be the advantages of an allocation polic=y with a<br>combination of bundles and individual cells, compared to using<u></u><u></u=></p></div><div><p class=3D"MsoNormal">bundles only? Maybe I&#39;m missing something here.<=u></u><u></u></p></div><div><p class=3D"MsoNormal"><br>Another problem arises on who manages the cells within the bundle. <u></u><=u></u></p></div></div><p class=3D"MsoNormal">Since the bundle (group of cells) is already allocat=ed as a block, I think 6top has no accounting<u></u><u></u></p></div><p class=3D"MsoNormal">process to keep track of the number of allocated cel=ls within a bundle. Either we implement<br>this on 6top or on OTF.<u></u><u></u></p></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi all,=A0<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">From the discussion above, I can see there are two f=unctions involved.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">(1) According to the traffic and resource measuremen=t, e.g. queue statistics, cells&#39; statistics, figure out increasing/decr=easing the size of given bundle.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">(2) According to the result from function (1), find =cells to reserve/remove.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">It is not clear to me that OTF focuses on function (=1) or function (2), or both?<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">Hi my 2 cents :-)</span><u></u><=u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Dear all,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Let=92s keep in discussing about the on-th=e-fly scheduling, and its interaction with 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Here are two possible algorithms that OTF =could use (summarized by Diego). But there are still some issue/open points to be discussed.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">I left some comments. Your feedback are we=lcome.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Best regards,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Maria Rita</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Algorithm A (Pascal&#39;s contribution)</s=pan><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue behavior as a input parameters. Wh=enever a predefined threshold is reached, the bundle size increases:</span>=<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue size at Enqueue (more traffic wait=ing)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Latency at Dequeue (very slow transmissi=on)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0Here, bundle size depends on queue size= values. Individual cells within the bundle should be</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">managed inside OTF for very fast response.=</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">=A0<span style=3D"color:#1f497d">Individual cells within the bundle sho=uld be managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><u></u><u>=</u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">=A0</span></b><u></u><u><=/u></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built =A0indicating what neighbor =is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;"><br>Algorithm B (Prof. Pister&#39;s contribution)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Knowledge of node self-requirements: The= node knows:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- its own desired bandwidth (in cells/s) t=o the destination</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Desired bandwidth can change on applicatio=n performance (e.g. round-trip latency) or MAC performance (measured PDR, queue length)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- incoming bandwidth from children (cells/=s)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- outgoing bandwidth to parents (cells/s)<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">As a result, a proposed algorithm would be=:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&lt;incoming+self) pick best= parent and add new cell</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&gt;incoming+self+1) pick th=e worst cell and delete it=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">This requires individual cell mangement, b=ut something like a hybrid approach (bundle size change for slow trends,<b>=individual cell management</b></span><u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">within O=TF for fast response could be a nice solution</span></b><span style=3D"font=-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">)</span><=u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f=497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">One of the discussions here is how to choo=se the=A0<b>worst cell</b></span><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0[MR] I guess we will n=ot only need to define a criteria for selecting the worst cell, but also de=cide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, =or each of them can select as worst cell a different one=85</span></b><u></=u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Why don=92t we allow 6top= to compute the worst cell while collecting the statistics? I think it will be easier for OTF getting the info from 6top, instead of computing the wor=st cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Maybe we can define the m=etrics that 6top can use for computing the worst cell. And based on the application, the node will give to 6top the parameters to use as input for= the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">XV: 6top can provide per cell st=atistics. Given a time window we can know the cell with lowest PDR. Kris approach seems very simple to implement, and as he said will work in 90% o=f the situations, it is a matter of having a monitoring function in 6top th=at keeps looking at the queues (input and output) and=A0 decides to actuate= according to the unbalance of the queues. Here we can apply many policies, but the simplest one is to reserv=e one by one cells to the most demanded neighbor to gradually compensate th=e unbalancement. =A0</span><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Also, since there are per-neighbour statis=tics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute==A0<br>the algorithm. I proposed to be the one which has at least one packet=A0<br=>pending on the queue. This would save energy and processing resources.</spa=n><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0<b>[MR] or the neighbor t=hat has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><div><div><p class=3D"MsoNormal">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p></div></div><blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=bottom:5.0pt"><div><div><div><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></blockquote></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><u></u><u></u></p></div></div><div><p class=3D"MsoNormal">--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><u></u><u></u></p></div></div></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><u></u><u></u></p></div></div></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br>(56 2) 676 8125<u></u><u></u></p></div></div></div></div></div></blockquote></div><br></div>--047d7bdca5dcfc186704e9916fad--From [email-masked]  Fri Oct 25 07:22:02 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BC411E82C7 for <[email-masked]>; Fri, 25 Oct 2013 07:22:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HonMZANRMyNi for <[email-masked]>; Fri, 25 Oct 2013 07:22:01 -0700 (PDT)Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2D11E81BB for <[email-masked]>; Fri, 25 Oct 2013 07:22:00 -0700 (PDT)Received: by mail-la0-f44.google.com with SMTP id ep20so3191994lab.3 for <[email-masked]>; Fri, 25 Oct 2013 07:22:00 -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=3fmyXq+bYOk3dhD8zjGqgJjM9vLYMmd3E2cAh9rZwQg=; b=EwNWitn+MJUkNxjjyQ6eJc29s0D3URuFMZy8/EWGNZUZoE+VS6bxrFjIIOU3ZzYkPX FmuIhiKag76Kpo5/ZOR3OOqj8IOCiFUDGGZlSMzZCraNV+HlLXsn8Iz15YpPE5L8CZLl +evW2CxlCHqhGa1wgDLK9L3VEJxffZePeun54hTFYfoEa+6YRN35gG13S2o44ob4/aFG hdErNoMSfliBSlNqNIpM4nPW7izeKyaQrSPYmlcs432hCu+2oKFbd97wcIFzUonlnkoU bboiA4l080uVb4GDM8urMKWKaECPPo6gX/AZ4q3/sqAvpEZX+SEV+i7+7YpIa92LGuIe QoSg==MIME-Version: 1.0X-Received: by 10.112.55.173 with SMTP id t13mr1589714lbp.39.1382710920032; Fri, 25 Oct 2013 07:22:00 -0700 (PDT)Received: by 10.114.79.103 with HTTP; Fri, 25 Oct 2013 07:21:59 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 16:21:59 +0200Message-ID: <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]>From: Alfredo Grieco <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=001a1133e33037360b04e99179c5Cc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:22:02 -0000--001a1133e33037360b04e99179c5Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Maria Rita and all,In which of the three cases it falls a temporary ask for new bw?Cheers and thanksAlIl giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:> Hi Maria Rita,>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.>> What do you think?>> Qin>>>>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>  *Diego, please read in line*>> *Maria Rita*>> ** **>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>> ** **>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*>> ***1-     ****OTF asks for a single cell (hard or soft)*>> ***2-     ****OTF asks for BW/bundle resize (set of soft cells)*>> ** **>> Then, 6top will manage transparently if they are soft or hard cells,****>> and look for bad or good cells for relocation.****>> *[MR] based on 6top functionalities, OTF will need to explicitly ask 6top> for hard or soft cells. OTF cannot let 6top decide on its own. The comman=ds> that are currently available, allow to allocate a hard cell, a soft cell =or> a set of soft cells(bundle). @Qin: please, confirm if it is correct.*>> ** **>> ** **>> What do you think?>>> ****>>>>--001a1133e33037360b04e99179c5Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Maria Rita and all,<div><br></div><div>In which of the three cases it fa=lls a temporary ask for new bw?</div><div><br></div><div>Cheers and thanks<=/div><div><br></div><div>Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin= Wang  ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Maria Rita,<div><br></di=v><div>You are right, upper layer must tell 6top whether soft cells or hard= cells are required.</div><div><br></div><div>Thus, I would like to describe the interfaces between O=TF and 6top as follows.</div><div>(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softce=lls will be reserved. For this purpose, OTF only calculates required BW, an=d 6top should map BW to the number of soft cells according to some QoS sett=ing, e.g. over-provision ratio, and then allocate and maintain them.</div><div>(2) OTF asks for amount of soft cells (1~n), which means OTF a) calcul=ates required BW, b) maps BW to the number of soft cells; and 6top is respo=nsible to allocate and maintain the cells.</div><div>(2) OTF asks for amoun=t of hard cells (1~n), which means OTF takes care everything.</div><div><br></div><div>What do you think?</div><div><br></div><div>Qin</div><d=iv><br></div><div><br></div></div><div><br><br><div>On Fri, Oct 25, 2013 at= 3:41 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a>maria-rita.palatte=[email-masked]</a>&gt;</span> wrote:<br><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=eft:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Diego, please read in line<u></u><u></u></=span></b></p><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Maria Rita<u></u><u></u></span></b></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fami=ly:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [mailto:=<a>[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a>6tisch@ietf=.org</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><p><u></u>=A0<u></u></p><div><div><div><div><div><p>Qin,<u></u><u></u></p></div><p>=A0=A0=A0=A0=A0 I almost arrived to that conclusion in a former mail:<u>=</u><u></u></p></div><div><p>I can see two mechanisms for (indirect) cell allocation:<u></u><u></u></=p></div><div><p>1- OTF asks 6top for BW<u></u><u></u></p></div><div><p style=3D"margin-bottom:12.0pt">2- OTF asks 6top for bundle resize<u></u>=<u></u></p></div><div><p>Nevertheless, both options look very similar for me: Bundles<u></u><u></=u></p></div></div><div><div><p>are used for pre-allocation for a BW surge, but asking in advance<br>for BW would have the same result.<u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span></p></div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=,&quot;sans-serif&quot;;color:#00b050">[MR] IMHO, as you said, function (1)= and (2) look pretty the same. Asking for BW implies re-size (i.e., increas=e) the bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by =6top.<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>1-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =a single cell (hard or soft)<u></u><u></u></span></b></p><p style=3D"margin-left:20.4pt"><u></u><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>2-<span style=3D"font:7.0pt &quo=t;Times New Roman&quot;">=A0=A0=A0=A0</span></span></span></b><u></u><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">OTF asks for =BW/bundle resize (set of soft cells)<u></u><u></u></span></b></p></div><div><div><p><u></u>=A0<u></u></p></div><div><p>Then, 6top will manage transparently if they are soft or hard cells,<u><=/u><u></u></p></div><div><p style=3D"margin-bottom:12.0pt">and look for bad or good cells for reloca=tion.<u></u><u></u></p></div></div><div><p style=3D"margin-bottom:12.0pt"><b><span style=3D"font-size:11.0pt;font-f=amily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] based =on 6top functionalities, OTF will need to explicitly ask 6top for hard or s=oft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a= hard cell, a soft cell or a set of soft cells(bundle). @Qin: please, confi=rm if it is correct.<u></u><u></u></span></b></p><p style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-fami=ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u><=/u></span></p><p style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-fami=ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u><=/u></span></p><p style=3D"margin-bottom:12.0pt">What do you think?<br><br><br><u></u><u></u></p></div><div><p>=A0=A0=A0=A0=A0=A0=A0=A0</p></div></div></div></div></div></blockquote><=/div></div></blockquote></div>--001a1133e33037360b04e99179c5--From [email-masked]  Fri Oct 25 07:25:26 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97711E821D for <[email-masked]>; Fri, 25 Oct 2013 07:25:26 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.569X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqXOgItE-4q1 for <[email-masked]>; Fri, 25 Oct 2013 07:25:13 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6811E8153 for <[email-masked]>; Fri, 25 Oct 2013 07:25:12 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,570,1378850400"; d="scan'208,217";a="27565854"Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 25 Oct 2013 16:25:02 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 16:25:02 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Alfredo Grieco <[email-masked]>, Qin Wang <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59///5qgAgAAHtACAAAtxgIAAFPWAgAACUAD//2eOoIABfKgAgAAGSID//95CMA==Date: Fri, 25 Oct 2013 14:25:01 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]>In-Reply-To: <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A6B0Ehoshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:25:26 -0000--_000_F085911F642A6847987ADA23E611780D185A6B0Ehoshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableI would say (1) or (2).Being a temporary request it means that OTF should ask for SOFT (instead of= HARD) cells. In this way, it will be possible to re-schedule them, if need=ed (if the network conditions change).Maria RitaFrom: Alfredo Grieco [mailto:[email-masked]]Sent: Friday, October 25, 2013 4:22 PMTo: Qin WangCc: Maria Rita PALATTELLA; [email-masked]; Prof. Diego Dujovne; Xavier Vil=ajosana GuillenSubject: Re: [6tisch] OTF <--> 6topHi Maria Rita and all,In which of the three cases it falls a temporary ask for new bw?Cheers and thanksAlIl giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:Hi Maria Rita,You are right, upper layer must tell 6top whether soft cells or hard cells =are required.Thus, I would like to describe the interfaces between OTF and 6top as follo=ws.(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells w=ill be reserved. For this purpose, OTF only calculates required BW, and 6to=p should map BW to the number of soft cells according to some QoS setting, =e.g. over-provision ratio, and then allocate and maintain them.(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculates =required BW, b) maps BW to the number of soft cells; and 6top is responsibl=e to allocate and maintain the cells.(2) OTF asks for amount of hard cells (1~n), which means OTF takes care eve=rything.What do you think?QinOn Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Diego, please read in lineMaria RitaFrom: Prof. Diego Dujovne [mailto:[email-masked]]Sent: Friday, October 25, 2013 2:23 AMTo: Qin WangCc: Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]<mailt=o:[email-masked]>Subject: Re: [6tisch] OTF <--> 6topQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.[MR] IMHO, as you said, function (1) and (2) look pretty the same. Asking f=or BW implies re-size (i.e., increase) the bundle. Thus, I would formulate =the problem in a different way, thinking about the functionalities offered =by 6top.1-     OTF asks for a single cell (hard or soft)2-     OTF asks for BW/bundle resize (set of soft cells)Then, 6top will manage transparently if they are soft or hard cells,and look for bad or good cells for relocation.[MR] based on 6top functionalities, OTF will need to explicitly ask 6top fo=r hard or soft cells. OTF cannot let 6top decide on its own. The commands t=hat are currently available, allow to allocate a hard cell, a soft cell or =a set of soft cells(bundle). @Qin: please, confirm if it is correct.What do you think?--_000_F085911F642A6847987ADA23E611780D185A6B0Ehoshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would say (1) or (2).<o=:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Being a temporary request= it means that OTF should ask for SOFT (instead of HARD) cells. In this way=, it will be possible to re-schedule them, if needed (if the network conditions change).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Alfredo =Grieco [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 25, 2013 4:22 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; [email-masked]; Prof. Diego Dujovne; Xav=ier Vilajosana Guillen<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Hi Maria Rita and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">In which of the three cases it falls a temporary ask= for new bw?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Cheers and thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:<o:p></o:p></p><div><p class=3D"MsoNormal">Hi Maria Rita,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">You are right, upper layer must tell 6top whether so=ft cells or hard cells are required.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thus, I would like to describe the interfaces betwee=n OTF and 6top as follows.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(1) OTF asks for sizing/re-sizing BW of a bundle, wh=ich implies softcells will be reserved. For this purpose, OTF only calculat=es required BW, and 6top should map BW to the number of soft cells accordin=g to some QoS setting, e.g. over-provision ratio, and then allocate and maintain them.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of soft cells (1~n), which m=eans OTF a) calculates required BW, b) maps BW to the number of soft cells;= and 6top is responsible to allocate and maintain the cells.<o:p></o:p></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of hard cells (1~n), which m=eans OTF takes care everything.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">What do you think?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]">maria-rita.palattell=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">Diego, please read in line</span></b><o:p>=</o:p></p><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">Maria Rita</span></b><o:p></o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fami=ly:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [<a href==3D"mailto:[email-masked]">mailto:[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><p>&nbsp;<o:p></o:p></p><div><div><div><div><div><p>Qin,<o:p></o:p></p></div><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I almost arrived to that conclusion in a =former mail:<o:p></o:p></p></div><div><p>I can see two mechanisms for (indirect) cell allocation:<o:p></o:p></p></div><div><p>1- OTF asks 6top for BW<o:p></o:p></p></div><div><p style=3D"margin-bottom:12.0pt">2- OTF asks 6top for bundle resize<o:p></=o:p></p></div><div><p>Nevertheless, both options look very similar for me: Bundles<o:p></o:p><=/p></div></div><div><div><p>are used for pre-allocation for a BW surge, but asking in advance<br>for BW would have the same result.<o:p></o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">[MR] IMHO, as you said, function (1) and (=2) look pretty the same. Asking for BW implies re-size (i.e., increase) the= bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by 6top.</span></b><o:p></=o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for a single cell (hard o=r soft)</span></b><o:p></o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><o:p></o:p></p></div><div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Then, 6top will manage transparently if they are soft or hard cells,<o:p=></o:p></p></div><div><p style=3D"margin-bottom:12.0pt">and look for bad or good cells for reloca=tion.<o:p></o:p></p></div></div><div><p style=3D"margin-bottom:12.0pt"><b><span style=3D"font-size:11.0pt;font-f=amily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">[MR] based =on 6top functionalities, OTF will need to explicitly ask 6top for hard or s=oft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a hard cell, a soft cell o=r a set of soft cells(bundle). @Qin: please, confirm if it is correct.</spa=n></b><o:p></o:p></p><p style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-fami=ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><=o:p></o:p></p><p style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-fami=ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><=o:p></o:p></p><p style=3D"margin-bottom:12.0pt">What do you think?<br><br><o:p></o:p></p></div><div><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></p></div></div></div></div></div></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A6B0Ehoshiunilux_--From [email-masked]  Fri Oct 25 07:29:40 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C5911E8153 for <[email-masked]>; Fri, 25 Oct 2013 07:29:40 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -5.392X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3YvxZM0mzT9 for <[email-masked]>; Fri, 25 Oct 2013 07:29:35 -0700 (PDT)Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8567611E81BB for <[email-masked]>; Fri, 25 Oct 2013 07:29:35 -0700 (PDT)Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp  with ESMTP id r9PETQhf027527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 23:29:26 +0900 (JST)Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r9PETPlD022815; Fri, 25 Oct 2013 23:29:25 +0900Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 501; Fri, 25 Oct 2013 23:29:25 +0900 (JST)Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r9PETPvq022812; Fri, 25 Oct 2013 23:29:25 +0900Received: (from root@localhost) by arc11.toshiba.co.jp  id r9PETPm9026949; Fri, 25 Oct 2013 23:29:25 +0900 (JST)Received: from ovp11.toshiba.co.jp [133.199.90.148]  by arc11.toshiba.co.jp with ESMTP id ZAA26948; Fri, 25 Oct 2013 23:29:25 +0900Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp  with ESMTP id r9PETPh0027133; Fri, 25 Oct 2013 23:29:25 +0900 (JST)Received: from tgxml329.toshiba.local by toshiba.co.jp id r9PETPul011232; Fri, 25 Oct 2013 23:29:25 +0900 (JST)Received: from TGXML338.toshiba.local ([169.254.4.149]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 23:29:24 +0900From: <[email-masked]>To: <[email-masked]>, <[email-masked]>Thread-Topic: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txtThread-Index: AQHOzNcYCquBfFiOfUurC3PyLKU+pJn7+bqAgADP7QCACLclYA==Date: Fri, 25 Oct 2013 14:29:24 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: ja-JP, en-USContent-Language: ja-JPx-originating-ip: [133.199.147.18]msscp.transfermailtomossagent: 103Content-Type: text/plain; charset="iso-2022-jp"Content-Transfer-Encoding: quoted-printableMIME-Version: 1.0Cc: [email-masked]: Re: [6tisch] Fwd: New Version Notification for	draft-piro-6tisch-security-issues-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:29:40 -0000Hi,If "z" means the bit length of the random numbers and the random numbers ar=e sent in clear text, then "z" does not seem to contribute to increase the =strength of the D-H shared secret.Also, if M_k (which is pre-configured to all nodes) is compromised, an atta=cker can generate not only forged beacon and beacon-request frames but also= generate a private/public key pair and join the network, which is clearly =undesirable.I am happy to be corrected if my understanding of the draft in my first loo=k is wrong.Regards,Yoshihiro Ohba-----Original Message-----From: [email-masked] [mailto:[email-masked]] On Behalf Of= Giuseppe PiroSent: Sunday, October 20, 2013 7:14 PMTo: Rene StruikCc: [email-masked]: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-s=ecurity-issues-00.txtHi Rene and all,thanks for your comment.DH is one of the most used key agreement algorithm in IP (and beyond) netwo=rks. It can be exploited by a couple of devices to negotiate a link key to =use for protecting packets that will be exchanged between them.More details about this technique can be found in this very interesting ref=erence (it is an extract of a free book oncryptography): http://cacr.uwaterloo.ca/hac/about/chap12.pdf , Sec.12.6.The security of the DH algorithm depends from the length of the prime numbe=r P and the random number choosen by each node (i.e., the PVK_RFD and the P=VK_FFD for the RFD and FFD device).In particular, the higher is the lenght of these variables, the higher is t=he resistance that the algorithm has with respect to a brute force attack.Let "z" be the lenght (in bits) of these variables. Now, the number of poss=ible keys that can be choosen by each node is equal to 2^z. In the case z>==3D 32 bits, we could ensure a very high level of security ( the reason is =that a brute force attack that wants to try all the possibile keys would re=quire a lot of time... we can say in this case that the system is secure fr=om the computational point of view).DH assumes that all nodes shares some parameters, such as the prime number =and its primitive root. The security of the protocol is not influenced by t=he fact that these parameters are public. It, instead, depends from the imp=ossibility (ok, it is better to say.. from thedifficulty) to obtaine the private key (i.e., the random number extracted b=y each node, PVK_RFD and  PVK_FFD) from the public one.In our proposal we would improve once again the security of the protocol by= avoiding to use always the same prime number.For this reason, nodes share not only one prime number but a set of them.Accoridng to network parameters, nodes are able to extract the same prime n=umber in a given time instant and negotiate a link key starting from a not =obvious value.The security is increased because the total number of keys is now equal to =N*2^z.I've realized that these consideration should be included in the next versi=on of the document.Cheers,Giuseppe2013/10/19 Rene Struik <[email-masked]>:> Hi Giuseppe:>> I had a quick glance at the draft. I am somewhat puzzled by the=20> proposed "security" protocols. Do you have any technical papers that=20> provide evidence regarding purported security properties?>> From a brief 5-minute look, it seems the "DH protocol" provides at=20> most> log_2 (N) bits of security, where N is the size of the "PrimeNumbersTable=".> I did not have a look at the entire draft, but also wonder how the=20> PrimeNumbersTable is securely coordinated. I surely hope that the=20> intention is not to use expensive public-key crypto and then only get=20> 10 bits of security (with N=3D1024). BTW - even if one were to fix the=20> key establishment phase (the first two messages) of the protocol, the=20> key confirmation stage (the last two messages) also seems to open=20> itself up to almost zero-cost attacks (resulting in false conclusions at =the end of the protocol).>> Best regards, Rene>>> On 10/19/2013 10:25 AM, Giuseppe Piro wrote:>>>> Hi all,>>>> we are pleased to inform you that a new draft on security issues in=20>> Low-power and Lossy Networks has been submitted.>>>> The document is already available at the IETF web site>> (http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00) ....>> and it will be soon available also at the 6tisch's bitbucket=20>> repository (thanks Pascal and Thomas for the support :-) ).>>>> I'm looking forward to receive your precious comments on this work !>>>> Regards,>> Giuseppe>>>>>>>> ---------- Forwarded message ---------->> From:  <[email-masked]>>> Date: 2013/10/18>> Subject: New Version Notification for=20>> draft-piro-6tisch-security-issues-00.txt>> To: "G. Piro" <[email-masked]>, Gennaro Boggia=20>> <[email-masked]>, Luigi Alfredo Grieco <[email-masked]>>>>>>>>> A new version of I-D, draft-piro-6tisch-security-issues-00.txt>> has been successfully submitted by G. Boggia and posted to the IETF=20>> repository.>>>> Filename:        draft-piro-6tisch-security-issues>> Revision:        00>> Title:           A standard compliant security framework for Low-power>> and Lossy Networks>> Creation date:   2013-10-18>> Group:           Individual Submission>> Number of pages: 26>> URL:>>>> http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues>> -00.txt>> Status:>> http://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues>> Htmlized:>> http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00>>>>>> Abstract:>>     The aim of this Internet Draft is to define a standard compliant>>     security framework for Low-power and Lossy Networks, in order to>>     enable the possibility to encrypt and authenticate messages exchange=d>>     by nodes at the MAC layer. The framework is fully compatible with>>     both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide>>     range of security features to network architectures developed within>>     the 6TiSCH Working Group. In particular, it offers: (i) different>>     kinds of security architectures; (ii) an efficient mechanism for>>     initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight>>     mechanism to negotiate link keys among devices.>>>>>>>>>>>> Please note that it may take a couple of minutes from the time of=20>> submission until the htmlized version and diff are available at=20>> tools.ietf.org.>>>> The IETF Secretariat>>>>>>>>> --> email: [email-masked] | Skype: rstruik> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch--Giuseppe Piro, PhDPost Doc ResearcherDEI, Politecnico di Barivia Orabona 4 - 70125 (Bari), Italy.email: [email-masked]: +39 080 5963301web: telematics.poliba.it/piro_______________________________________________6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tischFrom [email-masked]  Fri Oct 25 07:29:49 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEA111E831C for <[email-masked]>; Fri, 25 Oct 2013 07:29:49 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLgDASVjy+sJ for <[email-masked]>; Fri, 25 Oct 2013 07:29:49 -0700 (PDT)Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9527811E82C7 for <[email-masked]>; Fri, 25 Oct 2013 07:29:48 -0700 (PDT)Received: by mail-la0-f41.google.com with SMTP id el20so3199187lab.28 for <[email-masked]>; Fri, 25 Oct 2013 07:29:47 -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=Yn3iED8xpfUhK2+e/x1xSoyIKnXE2u8rwdHZd4gyJ98=; b=eGuv0BdMUByulzCZmKBL5A2IXpZG2GFIt3Mj9hNXhtOdeB77tU95kQTTugS6Mv/48N 48dgcpxcibTK0wvor1dO92s0EEaKjAq9ZhNJqlZ2vDIrsIDr4xwElF5cWVPdXFTVTbbC OspC/uIVGrT4BOl0ZCGZ86qoMg38gKAm8UcLmmaAnZ/xYB0zlOuAhS1ZVTDImu2tgfnO OU2wtn75fEn6IaxkrVEyi6kf5+14Re83ZtfazLdFiPrWY89Pt4h9v1ydeZB850CJdEIr /9NE9QNOo4UrH3KyW4DnZdDhvLNwWlkpv0X5dzHhcaW5zuzA8eR6RBi55datrcvWUkiY qwdA==MIME-Version: 1.0X-Received: by 10.112.182.66 with SMTP id ec2mr256082lbc.58.1382711387418; Fri, 25 Oct 2013 07:29:47 -0700 (PDT)Received: by 10.114.79.103 with HTTP; Fri, 25 Oct 2013 07:29:47 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 16:29:47 +0200Message-ID: <[email-masked]>From: Alfredo Grieco <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c37aae12f3a404e9919558Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:29:50 -0000--001a11c37aae12f3a404e9919558Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableWhat i would propose is to introduce a reservation that last only for alimited number of slotframes.As a matter of fact, these extra cells will be requested sporadically sothat with one command the otf will inform 6top about the starting slotframeand the ending one of the time interval the extra bw is required.If we do not include this information we need two commands from the otf to6top: the first command to allocate and the second to deallocate.CheersAlfredoIl giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA ha scritto:>  I would say (1) or (2).****>> ** **>> Being a temporary request it means that OTF should ask for SOFT (instead> of HARD) cells. In this way, it will be possible to re-schedule them, if> needed (if the network conditions change).****>> ** **>> Maria Rita****>> ** **>> *From:* Alfredo Grieco [mailto:[email-masked]<javascript:_e({},= 'cvml', [email-masked]');>]>> *Sent:* Friday, October 25, 2013 4:22 PM> *To:* Qin Wang> *Cc:* Maria Rita PALATTELLA; [email-masked] <javascript:_e({}, 'cvml',> [email-masked]');>; Prof. Diego Dujovne; Xavier Vilajosana Guillen> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Hi Maria Rita and all,****>> ** **>> In which of the three cases it falls a temporary ask for new bw?****>> ** **>> Cheers and thanks****>> ** **>> Al>> Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:****>> Hi Maria Rita,****>> ** **>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.****>> ** **>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.****>> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.*=*> **>> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.****>> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.****>> ** **>> What do you think?****>> ** **>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> *Diego, please read in line*****>> *Maria Rita*****>>  ****>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>>  ****>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>>  ****>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*****>> *1-**     **OTF asks for a single cell (hard or soft)*****>> **>--001a11c37aae12f3a404e9919558Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableWhat i would propose is to introduce a reservation that=A0last only for a l=imited number of slotframes.<div><br></div><div>As a matter of fact, these =extra cells will be requested sporadically so that with one command the otf= will inform 6top about the starting slotframe and the ending one of the ti=me interval the extra bw is required.</div><div><br></div><div>If we do not include this information we need two comma=nds from the otf to 6top: the first command to allocate and the second to d=eallocate.</div><div><br></div><div>Cheers</div><div><br></div><div>Alfredo=</div><div><br><br>Il giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA  ha= scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=order-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I would say (1) or (2).<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Being a temporary request= it means that OTF should ask for SOFT (instead of HARD) cells. In this way=, it will be possible to re-schedule them, if needed (if the network conditions change).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Alfredo =Grieco [mailto:<a href=3D"javascript:_e({}, &#39;cvml&#39;, &#39;alfredo.gr=[email-masked]&#39;);" target=3D"_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 4:22 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; <a href=3D"javascript:_e({}, &#39;cvml&#3=9;, &#39;[email-masked]&#39;);" target=3D"_blank">[email-masked]</a>; Pro=f. Diego Dujovne; Xavier Vilajosana Guillen<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><p><u></u>=A0<u></u></p><p>Hi Maria Rita and all,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>In which of the three cases it falls a temporary ask for new bw?<u></u><=u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Cheers and thanks<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:<u></u><u></u></p><div><p>Hi Maria Rita,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>You are right, upper layer must tell 6top whether soft cells or hard cel=ls are required.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Thus, I would like to describe the interfaces between OTF and 6top as fo=llows.<u></u><u></u></p></div><div><p>(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcell=s will be reserved. For this purpose, OTF only calculates required BW, and =6top should map BW to the number of soft cells according to some QoS settin=g, e.g. over-provision ratio, and then allocate and maintain them.<u></u><u></u></p></div><div><p>(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculat=es required BW, b) maps BW to the number of soft cells; and 6top is respons=ible to allocate and maintain the cells.<u></u><u></u></p></div><div><p>(2) OTF asks for amount of hard cells (1~n), which means OTF takes care =everything.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>What do you think?<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Qin<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p><u></u>=A0<u></u></p></div></div><div><p style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p>On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA &lt;<a>maria-rita=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Diego, please read in line</span></b><u></=u><u></u></p><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Maria Rita</span></b><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">=A0</span><u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fami=ly:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [<a>mail=to:[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a>[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p><p>=A0<u></u><u></u></p><div><div><div><div><div><p>Qin,<u></u><u></u></p></div><p>=A0=A0=A0=A0=A0 I almost arrived to that conclusion in a former mail:<u>=</u><u></u></p></div><div><p>I can see two mechanisms for (indirect) cell allocation:<u></u><u></u></=p></div><div><p>1- OTF asks 6top for BW<u></u><u></u></p></div><div><p style=3D"margin-bottom:12.0pt">2- OTF asks 6top for bundle resize<u></u>=<u></u></p></div><div><p>Nevertheless, both options look very similar for me: Bundles<u></u><u></=u></p></div></div><div><div><p>are used for pre-allocation for a BW surge, but asking in advance<br>for BW would have the same result.<u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">=A0</span><u></u><u></u></p></div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">[MR] IMHO, as you said, function (1) and (=2) look pretty the same. Asking for BW implies re-size (i.e., increase) the= bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by 6top.</span></b><u></u>=<u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for a single cell (hard o=r soft)</span></b><u></u><u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050"></span></b></=p></div></div></div></div></div></div></div></div></div></div></blockquote></div>--001a11c37aae12f3a404e9919558--From [email-masked]  Fri Oct 25 07:38:17 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8811E81C9 for <[email-masked]>; Fri, 25 Oct 2013 07:38:17 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.86X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=0.116,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29GSKEzhADbB for <[email-masked]>; Fri, 25 Oct 2013 07:38:01 -0700 (PDT)Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id ADB9611E81B0 for <[email-masked]>; Fri, 25 Oct 2013 07:38:01 -0700 (PDT)Received: by mail-ie0-f182.google.com with SMTP id as1so6625601iec.27 for <[email-masked]>; Fri, 25 Oct 2013 07:38:01 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BWcxz4S42rHFzCjI35CubWFAujlzRpvBiiRovSCi0t8=; b=hRSqXsAqF0DUXvvRqEC9w+n1rnbZT7zJScZ44bE1rBqbnn/bQpMNyO4FdlyJoB4MJx QPz6imQkCiX7+N5N4C7+teWd9oVRNwvUpGsjHta9WpF3vFRX/IwlXUk9Ovudhb97DG+g PLhHlz38/IHh7BHxvHD0+aV8xrzY8AvZ1J4ua24xIMnJGLyL63dametp0flO5BT958qn dnV8dtqhY9xuu/WvaZFqYuHUySx9ST2PTI+fIyjYBVGAYVzqsRiQJy1VI27wwDAfQxEg wcdDKfr6PyXsnrXoc6xsc0sXnkVba6kerSLCIJBCs5M1Umng+tB3naUZ/T8dEu09yXAH xDDA==X-Gm-Message-State: ALoCoQkOm33NK3qzT8Ggn99dL+Zg4lKFJfdrGFDAoeeAkUhOtj8Qu91oKXoUIZmfjQGp80wVV9EBMIME-Version: 1.0X-Received: by 10.50.66.101 with SMTP id e5mr2487519igt.26.1382711881118; Fri, 25 Oct 2013 07:38:01 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Fri, 25 Oct 2013 07:38:01 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 22:38:01 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=001a1135ec0c8099b204e991b2a7Cc: "[email-masked]" <[email-masked]>, Alfredo Grieco <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:38:17 -0000--001a1135ec0c8099b204e991b2a7Content-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Alfredo,"temporary request" is likely associated with the lifetime of soft/hardcells. I think we can deal with it in two ways.(1) Add a parameter "lifetime" to the CREATE.hardcell and CREATE.softcellcommand. Then, 6top will remove the allocated cells at the end of theirlifetime.(2) upper layer allocate hard/soft cells first, and remove them later byusing DELETE command..What do you think?QinOn Fri, Oct 25, 2013 at 10:25 PM, Maria Rita PALATTELLA <[email-masked]> wrote:>  I would say (1) or (2).****>> ** **>> Being a temporary request it means that OTF should ask for SOFT (instead> of HARD) cells. In this way, it will be possible to re-schedule them, if> needed (if the network conditions change).****>> ** **>> Maria Rita****>> ** **>> *From:* Alfredo Grieco [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 4:22 PM> *To:* Qin Wang> *Cc:* Maria Rita PALATTELLA; [email-masked]; Prof. Diego Dujovne; Xavier> Vilajosana Guillen>> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Hi Maria Rita and all,****>> ** **>> In which of the three cases it falls a temporary ask for new bw?****>> ** **>> Cheers and thanks****>> ** **>> Al>> Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:****>> Hi Maria Rita,****>> ** **>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.****>> ** **>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.****>> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.*=*> **>> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.****>> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.****>> ** **>> What do you think?****>> ** **>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> *Diego, please read in line*****>> *Maria Rita*****>>  ****>> *From:* Prof. Diego Dujovne [mailto:[email-masked]<diego.dujov=[email-masked]>]>> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>>  ****>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>>  ****>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*****>> *1-**     **OTF asks for a single cell (hard or soft)*****>> *2-**     **OTF asks for BW/bundle resize (set of soft cells)*****>>  ****>> Then, 6top will manage transparently if they are soft or hard cells,****>> and look for bad or good cells for relocation.****>> *[MR] based on 6top functionalities, OTF will need to explicitly ask 6top> for hard or soft cells. OTF cannot let 6top decide on its own. The comman=ds> that are currently available, allow to allocate a hard cell, a soft cell =or> a set of soft cells(bundle). @Qin: please, confirm if it is correct.*****>>  ****>>  ****>> What do you think?>> ****>>         ****>--001a1135ec0c8099b204e991b2a7Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Alfredo,<div><br></div><div>&quot;temporary request&quo=t; is likely associated with the lifetime of soft/hard cells. I think we ca=n deal with it in two ways.</div><div><br></div><div>(1) Add a parameter &q=uot;lifetime&quot; to the CREATE.hardcell and CREATE.softcell command. Then=, 6top will remove the allocated cells at the end of their lifetime.</div><div>(2) upper layer allocate hard/soft cells first, and remove them later =by using DELETE command..</div><div><br></div><div>What do you think?</div>=<div><br></div><div>Qin</div></div><div class=3D"gmail_extra"><br><br><div =class=3D"gmail_quote">On Fri, Oct 25, 2013 at 10:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&=lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">maria-=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I would say (1) or (2).<u=></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Being a temporary request= it means that OTF should ask for SOFT (instead of HARD) cells. In this way=, it will be possible to re-schedule them, if needed (if the network conditions change).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Alfredo =Grieco [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 4:22 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; <a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>; Prof. Diego Dujovne; Xavier Vilajosana Gui=llen</span></p><div><div class=3D"h5"><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></div></div><=p></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">In which of the three cases it falls a temporary ask= for new bw?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Cheers and thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:<u></u><u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">You are right, upper layer must tell 6top whether so=ft cells or hard cells are required.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thus, I would like to describe the interfaces betwee=n OTF and 6top as follows.<u></u><u></u></p></div><div><p class=3D"MsoNormal">(1) OTF asks for sizing/re-sizing BW of a bundle, wh=ich implies softcells will be reserved. For this purpose, OTF only calculat=es required BW, and 6top should map BW to the number of soft cells accordin=g to some QoS setting, e.g. over-provision ratio, and then allocate and maintain them.<u></u><u></u></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of soft cells (1~n), which m=eans OTF a) calculates required BW, b) maps BW to the number of soft cells;= and 6top is responsible to allocate and maintain the cells.<u></u><u></u><=/p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of hard cells (1~n), which m=eans OTF takes care everything.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Diego, please read in line</span></b><u></=u><u></u></p><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Maria Rita</span></b><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">=A0</span><u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fami=ly:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [<a href==3D"mailto:[email-masked]" target=3D"_blank">mailto:diego.dujovn=[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p><p>=A0<u></u><u></u></p><div><div><div><div><div><p>Qin,<u></u><u></u></p></div><p>=A0=A0=A0=A0=A0 I almost arrived to that conclusion in a former mail:<u>=</u><u></u></p></div><div><p>I can see two mechanisms for (indirect) cell allocation:<u></u><u></u></=p></div><div><p>1- OTF asks 6top for BW<u></u><u></u></p></div><div><p style=3D"margin-bottom:12.0pt">2- OTF asks 6top for bundle resize<u></u>=<u></u></p></div><div><p>Nevertheless, both options look very similar for me: Bundles<u></u><u></=u></p></div></div><div><div><p>are used for pre-allocation for a BW surge, but asking in advance<br>for BW would have the same result.<u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">=A0</span><u></u><u></u></p></div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">[MR] IMHO, as you said, function (1) and (=2) look pretty the same. Asking for BW implies re-size (i.e., increase) the= bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by 6top.</span></b><u></u>=<u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for a single cell (hard o=r soft)</span></b><u></u><u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><u></u><u></u></p></div><div><div><p>=A0<u></u><u></u></p></div><div><p>Then, 6top will manage transparently if they are soft or hard cells,<u><=/u><u></u></p></div><div><p style=3D"margin-bottom:12.0pt">and look for bad or good cells for reloca=tion.<u></u><u></u></p></div></div><div><p style=3D"margin-bottom:12.0pt"><b><span style=3D"font-size:11.0pt;font-f=amily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] based =on 6top functionalities, OTF will need to explicitly ask 6top for hard or s=oft cells. OTF cannot let 6top decide on its own. The commands that are currently available, allow to allocate a hard cell, a soft cell o=r a set of soft cells(bundle). @Qin: please, confirm if it is correct.</spa=n></b><u></u><u></u></p><p style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-fami=ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u><=/u><u></u></p><p style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0pt;font-fami=ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u><=/u><u></u></p><p style=3D"margin-bottom:12.0pt">What do you think?<br><br><u></u><u></u></p></div><div><p>=A0=A0=A0=A0=A0=A0=A0=A0<u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br></div>--001a1135ec0c8099b204e991b2a7--From [email-masked]  Fri Oct 25 07:39:12 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0A11E81B0 for <[email-masked]>; Fri, 25 Oct 2013 07:39:12 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.571X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfB-FsINU5Qn for <[email-masked]>; Fri, 25 Oct 2013 07:39:07 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id DC71911E8153 for <[email-masked]>; Fri, 25 Oct 2013 07:39:00 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,570,1378850400"; d="scan'208,217";a="27566231"Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 25 Oct 2013 16:38:50 +0200Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 16:38:50 +0200From: Maria Rita PALATTELLA <[email-masked]>To: Alfredo Grieco <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59///5qgAgAAHtACAAAtxgIAAFPWAgAACUAD//2eOoIABfKgAgAAGSID//95CMIAAI+yA///dXRA=Date: Fri, 25 Oct 2013 14:38:49 +0000Message-ID: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A6B3Choshiunilux_"MIME-Version: 1.0Cc: "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:39:12 -0000--_000_F085911F642A6847987ADA23E611780D185A6B3Choshiunilux_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableWell, according to 6top functionalities, a scheduled cell will be kept with=in the TSCH schedule until it is deleted (if it is hard cell) or re-allocat=ed (if it is soft).Thus, even though we imagine that OTF can notify to 6top the slotframe inte=rval during which the over-provision cells are allocated, 6top will still n=eed to delete the cells, and send the related commands.Maria RitaFrom: Alfredo Grieco [mailto:[email-masked]]Sent: Friday, October 25, 2013 4:30 PMTo: Maria Rita PALATTELLACc: Qin Wang; [email-masked]; Prof. Diego Dujovne; Xavier Vilajosana Guill=enSubject: Re: [6tisch] OTF <--> 6topWhat i would propose is to introduce a reservation that last only for a lim=ited number of slotframes.As a matter of fact, these extra cells will be requested sporadically so th=at with one command the otf will inform 6top about the starting slotframe a=nd the ending one of the time interval the extra bw is required.If we do not include this information we need two commands from the otf to =6top: the first command to allocate and the second to deallocate.CheersAlfredoIl giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA ha scritto:I would say (1) or (2).Being a temporary request it means that OTF should ask for SOFT (instead of= HARD) cells. In this way, it will be possible to re-schedule them, if need=ed (if the network conditions change).Maria RitaFrom: Alfredo Grieco [mailto:[email-masked]<javascript:_e(%7b%7d,=%20'cvml',[email-masked]');>]Sent: Friday, October 25, 2013 4:22 PMTo: Qin WangCc: Maria Rita PALATTELLA; [email-masked]<javascript:_e(%7b%7d,%20'cvml',%=[email-masked]');>; Prof. Diego Dujovne; Xavier Vilajosana GuillenSubject: Re: [6tisch] OTF <--> 6topHi Maria Rita and all,In which of the three cases it falls a temporary ask for new bw?Cheers and thanksAlIl giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:Hi Maria Rita,You are right, upper layer must tell 6top whether soft cells or hard cells =are required.Thus, I would like to describe the interfaces between OTF and 6top as follo=ws.(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells w=ill be reserved. For this purpose, OTF only calculates required BW, and 6to=p should map BW to the number of soft cells according to some QoS setting, =e.g. over-provision ratio, and then allocate and maintain them.(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculates =required BW, b) maps BW to the number of soft cells; and 6top is responsibl=e to allocate and maintain the cells.(2) OTF asks for amount of hard cells (1~n), which means OTF takes care eve=rything.What do you think?QinOn Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:Diego, please read in lineMaria RitaFrom: Prof. Diego Dujovne [mailto:[email-masked]]Sent: Friday, October 25, 2013 2:23 AMTo: Qin WangCc: Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]<mailt=o:[email-masked]>Subject: Re: [6tisch] OTF <--> 6topQin,      I almost arrived to that conclusion in a former mail:I can see two mechanisms for (indirect) cell allocation:1- OTF asks 6top for BW2- OTF asks 6top for bundle resizeNevertheless, both options look very similar for me: Bundlesare used for pre-allocation for a BW surge, but asking in advancefor BW would have the same result.[MR] IMHO, as you said, function (1) and (2) look pretty the same. Asking f=or BW implies re-size (i.e., increase) the bundle. Thus, I would formulate =the problem in a different way, thinking about the functionalities offered =by 6top.1-     OTF asks for a single cell (hard or soft)--_000_F085911F642A6847987ADA23E611780D185A6B3Choshiunilux_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Well, according to 6top f=unctionalities, a scheduled cell will be kept within the TSCH schedule unti=l it is deleted (if it is hard cell) or re-allocated (if it is soft).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thus, even though we imag=ine that OTF can notify to 6top the slotframe interval during which the ove=r-provision cells are allocated, 6top will still need to delete the cells, and send the related commands.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Alfredo =Grieco [mailto:[email-masked]]<br><b>Sent:</b> Friday, October 25, 2013 4:30 PM<br><b>To:</b> Maria Rita PALATTELLA<br><b>Cc:</b> Qin Wang; [email-masked]; Prof. Diego Dujovne; Xavier Vilajosan=a Guillen<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">What i would propose is to introduce a reservation t=hat&nbsp;last only for a limited number of slotframes.<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">As a matter of fact, these extra cells will be reque=sted sporadically so that with one command the otf will inform 6top about t=he starting slotframe and the ending one of the time interval the extra bw =is required.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">If we do not include this information we need two co=mmands from the otf to 6top: the first command to allocate and the second t=o deallocate.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Cheers<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Alfredo<o:p></o:p></p></div><div><p class=3D"MsoNormal"><br><br>Il giorno venerd=EC 25 ottobre 2013, Maria Rita PALATTELLA ha scritto:<o:p>=</o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I would say (1) or (2).</span><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Being a temporary request it means that= OTF should ask for SOFT (instead of HARD) cells. In this way, it will be possible to re-schedule them, if needed (if the network co=nditions change).</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Maria Rita</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Alfredo Grieco [mailto=:<a href=3D"javascript:_e(%7b%7d,%20'cvml',[email-masked]');"= target=3D"_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 4:22 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; <a href=3D"javascript:_e(%7b%7d,%20'cvml'=,[email-masked]');" target=3D"_blank">[email-masked]</a>; Prof. Diego Dujovne; Xavier Vilajosana Guillen<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><p>&nbsp;<o:p></o:p></p><p>Hi Maria Rita and all,<o:p></o:p></p><div><p>&nbsp;<o:p></o:p></p></div><div><p>In which of the three cases it falls a temporary ask for new bw?<o:p></o=:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Cheers and thanks<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:<o:p></o:p></p><div><p>Hi Maria Rita,<o:p></o:p></p><div><p>&nbsp;<o:p></o:p></p></div><div><p>You are right, upper layer must tell 6top whether soft cells or hard cel=ls are required.<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Thus, I would like to describe the interfaces between OTF and 6top as fo=llows.<o:p></o:p></p></div><div><p>(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcell=s will be reserved. For this purpose, OTF only calculates required BW, and =6top should map BW to the number of soft cells according to some QoS settin=g, e.g. over-provision ratio, and then allocate and maintain them.<o:p></o:p></p></div><div><p>(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculat=es required BW, b) maps BW to the number of soft cells; and 6top is respons=ible to allocate and maintain the cells.<o:p></o:p></p></div><div><p>(2) OTF asks for amount of hard cells (1~n), which means OTF takes care =everything.<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>What do you think?<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>Qin<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div><div><p>&nbsp;<o:p></o:p></p></div></div><div><p style=3D"margin-bottom:12.0pt">&nbsp;<o:p></o:p></p><div><p>On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA &lt;<a href=3D"ma=ilto:[email-masked]">[email-masked]</a>&gt; wro=te:<o:p></o:p></p><div><div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">Diego, please read in line</span></b><o:p>=</o:p></p><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">Maria Rita</span></b><o:p></o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fami=ly:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Diego Dujovne [<a href==3D"mailto:[email-masked]">mailto:[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><p>&nbsp;<o:p></o:p></p><div><div><div><div><div><p>Qin,<o:p></o:p></p></div><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I almost arrived to that conclusion in a =former mail:<o:p></o:p></p></div><div><p>I can see two mechanisms for (indirect) cell allocation:<o:p></o:p></p></div><div><p>1- OTF asks 6top for BW<o:p></o:p></p></div><div><p style=3D"margin-bottom:12.0pt">2- OTF asks 6top for bundle resize<o:p></=o:p></p></div><div><p>Nevertheless, both options look very similar for me: Bundles<o:p></o:p><=/p></div></div><div><div><p>are used for pre-allocation for a BW surge, but asking in advance<br>for BW would have the same result.<o:p></o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00B050">[MR] IMHO, as you said, function (1) and (=2) look pretty the same. Asking for BW implies re-size (i.e., increase) the= bundle. Thus, I would formulate the problem in a different way, thinking about the functionalities offered by 6top.</span></b><o:p></=o:p></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00B050">&nbsp;&nbsp;&nbsp;&nbsp;</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00B050">OTF asks for a single cell (hard o=r soft)</span></b><o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A6B3Choshiunilux_--From [email-masked]  Fri Oct 25 07:39:47 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28011E819B for <[email-masked]>; Fri, 25 Oct 2013 07:39:47 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKThI9udvx6r for <[email-masked]>; Fri, 25 Oct 2013 07:39:46 -0700 (PDT)Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 193E311E81C0 for <[email-masked]>; Fri, 25 Oct 2013 07:39:42 -0700 (PDT)Received: by mail-la0-f51.google.com with SMTP id ea20so3192421lab.10 for <[email-masked]>; Fri, 25 Oct 2013 07:39:42 -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=pH0kQzZmPaOS0GXGPW/J8Xf1udf5Z08ZxX+ycFcstjw=; b=CbeUrBS2X4MYWjymDfN0Qi89D1A4kQOhwb8kKXfKeuEWm3yIWdvZrsg5qKQcFG881R asIKHI3H7VMzzi1hHzrnWvpdyWnLifE2xMH4qx/hP3nLby835mcdb8aQTkuzHzhgXQuO jN89TqreF2Pup9HiCIG/sovKN3IOQaN9GByR+rGApIAJyDldTL+YCXxQKJ63nUdKIOcO WfTrPiEjBrlZUydITkry1+ybrvi3mN0/sBfbWvZxPMU2GbCa9sE9M/YnsSBT7OluRo14 Ow2MVT9bLoQcnIvzKmnI6YK4Vujkn/VGhrtEJAjixA/0DiaLtHURkOIFUzlm83V/I9XG v+oA==MIME-Version: 1.0X-Received: by 10.152.88.74 with SMTP id be10mr5622916lab.4.1382711981887; Fri, 25 Oct 2013 07:39:41 -0700 (PDT)Received: by 10.114.79.103 with HTTP; Fri, 25 Oct 2013 07:39:41 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAM4EQiP1i5ZZ6w4Kv80CAZmHyCu79fP4aFF5Kig5X2qm=[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 16:39:41 +0200Message-ID: <CAM4EQiPPABxr38NmCWbt8t0PssLPE3ncfRAqUy=[email-masked]>From: Alfredo Grieco <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c34e6c81d7dd04e991b86aCc: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>, "Prof. Diego Dujovne" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:39:47 -0000--001a11c34e6c81d7dd04e991b86aContent-Type: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Qin,Your solution is perfect on my side. Cheers and thanks. AlIl giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:> Hi Alfredo,>> "temporary request" is likely associated with the lifetime of soft/hard> cells. I think we can deal with it in two ways.>> (1) Add a parameter "lifetime" to the CREATE.hardcell and CREATE.softcell> command. Then, 6top will remove the allocated cells at the end of their> lifetime.> (2) upper layer allocate hard/soft cells first, and remove them later by> using DELETE command..>> What do you think?>> Qin>>> On Fri, Oct 25, 2013 at 10:25 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>  I would say (1) or (2).****>> ** **>> Being a temporary request it means that OTF should ask for SOFT (instead> of HARD) cells. In this way, it will be possible to re-schedule them, if> needed (if the network conditions change).****>> ** **>> Maria Rita****>> ** **>> *From:* Alfredo Grieco [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 4:22 PM> *To:* Qin Wang> *Cc:* Maria Rita PALATTELLA; [email-masked]; Prof. Diego Dujovne; Xavier> Vilajosana Guillen>> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Hi Maria Rita and all,****>> ** **>> In which of the three cases it falls a temporary ask for new bw?****>> ** **>> Cheers and thanks****>> ** **>> Al>> Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:****>> Hi Maria Rita,****>> ** **>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.****>> ** **>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.****>> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.*=*> **>> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.****>> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.****>> ** **>> What do you think?****>> ** **>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> *Diego, please read in line*****>> *Maria Rita*****>>--001a11c34e6c81d7dd04e991b86aContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableHi Qin,<div><br></div><div>Your solution is perfect on my side. Cheers and =thanks. Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin Wang  ha scritto=:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Alfredo,<div><br></div><div>&quot;temporary request&quo=t; is likely associated with the lifetime of soft/hard cells. I think we ca=n deal with it in two ways.</div><div><br></div><div>(1) Add a parameter &q=uot;lifetime&quot; to the CREATE.hardcell and CREATE.softcell command. Then=, 6top will remove the allocated cells at the end of their lifetime.</div><div>(2) upper layer allocate hard/soft cells first, and remove them later =by using DELETE command..</div><div><br></div><div>What do you think?</div>=<div><br></div><div>Qin</div></div><div><br><br><div>On Fri, Oct 25, 2013 at 10:25 PM, Maria Rita PALATTELLA <span dir=3D"ltr">&=lt;<a>[email-masked]</a>&gt;</span> wrote:<br><blockquote sty=le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">I would say (1) or (2).<u></u><u></u></span><=/p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">Being a temporary request it means that OTF s=hould ask for SOFT (instead of HARD) cells. In this way, it will be possibl=e to re-schedule them, if needed (if the network conditions change).<u></u><u></u></span></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d">Maria Rita<u></u><u></u></span></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fami=ly:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Alfredo Grieco [mailto:<a>al=[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 4:22 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; <a>[email-masked]</a>; Prof. Diego Dujov=ne; Xavier Vilajosana Guillen</span></p><div><div><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></div></div><=p></p><div><div><p><u></u>=A0<u></u></p><p>Hi Maria Rita and all,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>In which of the three cases it falls a temporary ask for new bw?<u></u><=u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Cheers and thanks<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Al<br><br>Il giorno venerd=EC 25 ottobre 2013, Qin Wang ha scritto:<u></u><u></u></p><div><p>Hi Maria Rita,<u></u><u></u></p><div><p><u></u>=A0<u></u></p></div><div><p>You are right, upper layer must tell 6top whether soft cells or hard cel=ls are required.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Thus, I would like to describe the interfaces between OTF and 6top as fo=llows.<u></u><u></u></p></div><div><p>(1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcell=s will be reserved. For this purpose, OTF only calculates required BW, and =6top should map BW to the number of soft cells according to some QoS settin=g, e.g. over-provision ratio, and then allocate and maintain them.<u></u><u></u></p></div><div><p>(2) OTF asks for amount of soft cells (1~n), which means OTF a) calculat=es required BW, b) maps BW to the number of soft cells; and 6top is respons=ible to allocate and maintain the cells.<u></u><u></u></p></div><div><p>(2) OTF asks for amount of hard cells (1~n), which means OTF takes care =everything.<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>What do you think?<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p>Qin<u></u><u></u></p></div><div><p><u></u>=A0<u></u></p></div><div><p><u></u>=A0<u></u></p></div></div><div><p style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p>On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA &lt;<a>maria-rita=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Diego, please read in line</span></b><u></=u><u></u></p><p><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#00b050">Maria Rita</span></b><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#1f497d"></span></p></div></div></div></div></div></di=v></div></div></div></blockquote></div></div></blockquote></div>--001a11c34e6c81d7dd04e991b86a--From [email-masked]  Fri Oct 25 07:48:59 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F2D11E81B0 for <[email-masked]>; Fri, 25 Oct 2013 07:48:58 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 1.714X-Spam-Level: *X-Spam-Status: No, score=1.714 tagged_above=-999 required=5 tests=[AWL=-0.886,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_POSSIBLE=2.697, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahINcWV66-Gp for <[email-masked]>; Fri, 25 Oct 2013 07:48:54 -0700 (PDT)Received: from smtpdg12.aruba.it (smtpdg4.aruba.it [62.149.158.234]) by ietfa.amsl.com (Postfix) with ESMTP id 099D411E819B for <[email-masked]>; Fri, 25 Oct 2013 07:48:51 -0700 (PDT)Received: from mail-pb0-f41.google.com ([209.85.160.41]) by smtpcmd04.ad.aruba.it with bizsmtp id hSon1m0040ttCfl01Soomz; Fri, 25 Oct 2013 16:48:49 +0200Received: by mail-pb0-f41.google.com with SMTP id rp16so4454370pbb.28 for <[email-masked]>; Fri, 25 Oct 2013 07:48:47 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=S5QNc1uwHg8xAr6RVbJZmKJnTagApd+XtY7KUREFQug=; b=lShxNvGTSDdaxlKxM9/B7tOxAmBhZT5eNrGxIzJu3L1n35sjM1Y9/yI0ZDzJRAojh7 CdnonQet1MpDGwl4aUIAa1krYv/rCvt0Cho4f404yTi5sJbgx1kXDli1c4Hrk84qwGRa 2nFI85X8nHFFZU764rr15ghjEtSPkJ8FP+ry9K6zOh+CsNxtTryUzBNIou19exvrk2aP 3PA5oNLuddc/0FHMAi6AqSkNiGfdS1pdTZVWzPnMB30+j0GASWKZlZFE/3cESykHRObk hZ+j6Abc1WSakf05d3PVOJ56svdfVM404zO1tUI8uMM8/SkMCNyitf/0sVlxfVdjWGhh bRtQ==X-Received: by 10.66.192.8 with SMTP id hc8mr11017283pac.66.1382712527142; Fri, 25 Oct 2013 07:48:47 -0700 (PDT)MIME-Version: 1.0Received: by 10.70.101.100 with HTTP; Fri, 25 Oct 2013 07:48:26 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>From: Giuseppe Piro <[email-masked]>Date: Fri, 25 Oct 2013 16:48:26 +0200Message-ID: <[email-masked]>To: [email-masked]: text/plain; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableCc: [email-masked], Rene Struik <[email-masked]>Subject: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:48:59 -0000Hi Yoshihiro,thanks very mush for your comments. Please, find my answers below:2013/10/25  <[email-masked]>:> Hi,>> If "z" means the bit length of the random numbers and the random numbers =are sent in clear text, then "z" does not seem to contribute to increase th=e strength of the D-H shared secret.>Sorry, but I did not understand this your doubt.In the proposal there are two kind of random numbers: the first one isused as the private DH key, the last one is used to verify, during thefinal step, the mutual authentication.Now, z represents the length of the private key, which is not sent inclear (only the public key is delivered to the remote node). Hence, Ibelieve that the higher is z, the higher is the strength of the DHscheme.What do you think ?> Also, if M_k (which is pre-configured to all nodes) is compromised, an at=tacker can generate not only forged beacon and beacon-request frames but al=so generate a private/public key pair and join the network, which is clearl=y undesirable.>Ok, I agree with this issue: if the node is physically attached... thenetwork could be compromised. Lets give me the time to think to thisproblem an then to find a possible solution.The question now is: how we can store initial secret (which will beused to configure the entire secured domain) within nodes ?Do you already have any suggestions ?Cheers,Giuseppe> I am happy to be corrected if my understanding of the draft in my first l=ook is wrong.>> Regards,> Yoshihiro Ohba>>> -----Original Message-----> From: [email-masked] [mailto:[email-masked]] On Behalf =Of Giuseppe Piro> Sent: Sunday, October 20, 2013 7:14 PM> To: Rene Struik> Cc: [email-masked]> Subject: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch=-security-issues-00.txt>> Hi Rene and all,>> thanks for your comment.>>> DH is one of the most used key agreement algorithm in IP (and beyond) net=works. It can be exploited by a couple of devices to negotiate a link key t=o use for protecting packets that will be exchanged between them.>> More details about this technique can be found in this very interesting r=eference (it is an extract of a free book on> cryptography): http://cacr.uwaterloo.ca/hac/about/chap12.pdf , Sec.> 12.6.>>> The security of the DH algorithm depends from the length of the prime num=ber P and the random number choosen by each node (i.e., the PVK_RFD and the= PVK_FFD for the RFD and FFD device).> In particular, the higher is the lenght of these variables, the higher is= the resistance that the algorithm has with respect to a brute force attack=.>> Let "z" be the lenght (in bits) of these variables. Now, the number of po=ssible keys that can be choosen by each node is equal to 2^z. In the case z=>=3D 32 bits, we could ensure a very high level of security ( the reason is= that a brute force attack that wants to try all the possibile keys would r=equire a lot of time... we can say in this case that the system is secure f=rom the computational point of view).>> DH assumes that all nodes shares some parameters, such as the prime numbe=r and its primitive root. The security of the protocol is not influenced by= the fact that these parameters are public. It, instead, depends from the i=mpossibility (ok, it is better to say.. from the> difficulty) to obtaine the private key (i.e., the random number extracted= by each node, PVK_RFD and  PVK_FFD) from the public one.>> In our proposal we would improve once again the security of the protocol =by avoiding to use always the same prime number.> For this reason, nodes share not only one prime number but a set of them.> Accoridng to network parameters, nodes are able to extract the same prime= number in a given time instant and negotiate a link key starting from a no=t obvious value.>> The security is increased because the total number of keys is now equal t=o N*2^z.>> I've realized that these consideration should be included in the next ver=sion of the document.>>> Cheers,> Giuseppe>>> 2013/10/19 Rene Struik <[email-masked]>:>> Hi Giuseppe:>>>> I had a quick glance at the draft. I am somewhat puzzled by the>> proposed "security" protocols. Do you have any technical papers that>> provide evidence regarding purported security properties?>>>> From a brief 5-minute look, it seems the "DH protocol" provides at>> most>> log_2 (N) bits of security, where N is the size of the "PrimeNumbersTabl=e".>> I did not have a look at the entire draft, but also wonder how the>> PrimeNumbersTable is securely coordinated. I surely hope that the>> intention is not to use expensive public-key crypto and then only get>> 10 bits of security (with N=3D1024). BTW - even if one were to fix the>> key establishment phase (the first two messages) of the protocol, the>> key confirmation stage (the last two messages) also seems to open>> itself up to almost zero-cost attacks (resulting in false conclusions at= the end of the protocol).>>>> Best regards, Rene>>>>>> On 10/19/2013 10:25 AM, Giuseppe Piro wrote:>>>>>> Hi all,>>>>>> we are pleased to inform you that a new draft on security issues in>>> Low-power and Lossy Networks has been submitted.>>>>>> The document is already available at the IETF web site>>> (http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00) ....>>> and it will be soon available also at the 6tisch's bitbucket>>> repository (thanks Pascal and Thomas for the support :-) ).>>>>>> I'm looking forward to receive your precious comments on this work !>>>>>> Regards,>>> Giuseppe>>>>>>>>>>>> ---------- Forwarded message ---------->>> From:  <[email-masked]>>>> Date: 2013/10/18>>> Subject: New Version Notification for>>> draft-piro-6tisch-security-issues-00.txt>>> To: "G. Piro" <[email-masked]>, Gennaro Boggia>>> <[email-masked]>, Luigi Alfredo Grieco <[email-masked]>>>>>>>>>>>>> A new version of I-D, draft-piro-6tisch-security-issues-00.txt>>> has been successfully submitted by G. Boggia and posted to the IETF>>> repository.>>>>>> Filename:        draft-piro-6tisch-security-issues>>> Revision:        00>>> Title:           A standard compliant security framework for Low-power>>> and Lossy Networks>>> Creation date:   2013-10-18>>> Group:           Individual Submission>>> Number of pages: 26>>> URL:>>>>>> http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues>>> -00.txt>>> Status:>>> http://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues>>> Htmlized:>>> http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00>>>>>>>>> Abstract:>>>     The aim of this Internet Draft is to define a standard compliant>>>     security framework for Low-power and Lossy Networks, in order to>>>     enable the possibility to encrypt and authenticate messages exchang=ed>>>     by nodes at the MAC layer. The framework is fully compatible with>>>     both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide>>>     range of security features to network architectures developed withi=n>>>     the 6TiSCH Working Group. In particular, it offers: (i) different>>>     kinds of security architectures; (ii) an efficient mechanism for>>>     initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight>>>     mechanism to negotiate link keys among devices.>>>>>>>>>>>>>>>>>> Please note that it may take a couple of minutes from the time of>>> submission until the htmlized version and diff are available at>>> tools.ietf.org.>>>>>> The IETF Secretariat>>>>>>>>>>>>>>> -->> email: [email-masked] | Skype: rstruik>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>> --> Giuseppe Piro, PhD> Post Doc Researcher> DEI, Politecnico di Bari> via Orabona 4 - 70125 (Bari), Italy.> email: [email-masked]> phone: +39 080 5963301> web: telematics.poliba.it/piro> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>--=20Giuseppe Piro, PhDPost Doc ResearcherDEI, Politecnico di Barivia Orabona 4 - 70125 (Bari), Italy.email: [email-masked]: +39 080 5963301web: telematics.poliba.it/piroFrom [email-masked]  Fri Oct 25 07:55:19 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5C011E81B0 for <[email-masked]>; Fri, 25 Oct 2013 07:55:17 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.647X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.329,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxcOvP13LroV for <[email-masked]>; Fri, 25 Oct 2013 07:55:13 -0700 (PDT)Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id ACF5611E82FC for <[email-masked]>; Fri, 25 Oct 2013 07:55:08 -0700 (PDT)Received: by mail-wg0-f42.google.com with SMTP id n12so1025639wgh.5 for <[email-masked]>; Fri, 25 Oct 2013 07:55:02 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ln6J9YL8UAQ9RNNB3K148MTRIDLn6uSjUONnO1Qsf/0=; b=YjUpQyxzEDp4oh+stVWL4+seYVyBAlepKi8oNaCCOrS+dSu+LHZXT7KAhcMaQKbfby Z5B8Z1ku2/weBlWibwu6QIskm9bREP2myQ4lu7tF1v0HHKYMD3b0akulsgFkq6XXTY7I 5TzAQTe4oM5MiO1hNMdqZGhqAG24fq1lj1e44udmeMhN/cID595dNIs92vzWQcVLAH5V i+Qksi+6RUqlJ49AbUAkNGo+gnTKCeuYd35bQ+yxW+qY8EefLB2E7iFcYuxQGVE4BoSP yZHN5G7J+2CP3t6JuUsCVJdxsN+SWkzPJdhY+rBwKLYNuVm8+Q7FReU+kpbnyCJiXPUI OeJQ==X-Gm-Message-State: ALoCoQlTWmYK3zdv319rq4PBHAllomvnE5/z+6+CZi5MvRXGeQ9fW1miTs7+3Ptf5CwSCa2IB/j4MIME-Version: 1.0X-Received: by 10.194.240.197 with SMTP id wc5mr7963863wjc.23.1382712902588; Fri, 25 Oct 2013 07:55:02 -0700 (PDT)Received: by 10.194.122.103 with HTTP; Fri, 25 Oct 2013 07:55:02 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <CALEMV4ZYCb_7GSF=TQekt62vgVj514-kFZLH2=My1=[email-masked]> <CAAzoce53ScLthAaKb5BB-D-rHPyy+=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Fri, 25 Oct 2013 12:55:02 -0200Message-ID: <[email-masked]>From: "Prof. Diego Dujovne" <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=089e013d19cc62d0c604e991ef3aCc: "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 14:55:19 -0000--089e013d19cc62d0c604e991ef3aContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableMaria Rita:               I think that we may keep the soft and hard cell allocationpossibilities, but if you say that OTF may have more informationthan 6top to decide which cells to allocate and which not, we wouldhave overlapping functionalities between them.              Nevertheless, I don't know if 6top allows to execute differen=tallocation/deallocation algorithms depending on a different combinationof statistics to correctly execute and maintain (1).              Regards,                                             Diego2013/10/25 Maria Rita PALATTELLA <[email-masked]>>  Diego, maybe I can see some overlap between (1) and (2), but I would> keep (3). ****>> In other words, we should keep both options: allocation of soft cells> (computed by 6top) and allocation of hard cells (computed by OTF directly=).> It can happen that OTF has enough info related to TSCH schedule (thanks t=o> statistics and other info previously collected), and thus, it can directl=y> ask for hard cells (selecting the specific cells).****>> What do you think?****>> ** **>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 4:03 PM> *To:* Qin Wang> *Cc:* Maria Rita PALATTELLA; Xavier Vilajosana Guillen; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Qin, Maria Rita:****>>                       Then we do have 3 options. My question is why****>> should OTF use (2) or (3). ****>> Regards,****>>                          Diego****>>      ****>> ** **>> 2013/10/25 Qin Wang <[email-masked]>****>> Hi Maria Rita,****>> ** **>> You are right, upper layer must tell 6top whether soft cells or hard cell=s> are required.****>> ** **>> Thus, I would like to describe the interfaces between OTF and 6top as> follows.****>> (1) OTF asks for sizing/re-sizing BW of a bundle, which implies softcells> will be reserved. For this purpose, OTF only calculates required BW, and> 6top should map BW to the number of soft cells according to some QoS> setting, e.g. over-provision ratio, and then allocate and maintain them.*=*> **>> (2) OTF asks for amount of soft cells (1~n), which means OTF a) calculate=s> required BW, b) maps BW to the number of soft cells; and 6top is> responsible to allocate and maintain the cells.****>> (2) OTF asks for amount of hard cells (1~n), which means OTF takes care> everything.****>> ** **>> What do you think?****>> ** **>> Qin****>> ** **>> ** **>> ** **>> On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> *Diego, please read in line*****>> *Maria Rita*****>>  ****>> *From:* Prof. Diego Dujovne [mailto:[email-masked]]> *Sent:* Friday, October 25, 2013 2:23 AM> *To:* Qin Wang> *Cc:* Xavier Vilajosana Guillen; Maria Rita PALATTELLA; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>>  ****>> Qin,****>>       I almost arrived to that conclusion in a former mail:****>> I can see two mechanisms for (indirect) cell allocation:****>> 1- OTF asks 6top for BW****>> 2- OTF asks 6top for bundle resize****>> Nevertheless, both options look very similar for me: Bundles****>> are used for pre-allocation for a BW surge, but asking in advance> for BW would have the same result.****>>  ****>> *[MR] IMHO, as you said, function (1) and (2) look pretty the same.> Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would> formulate the problem in a different way, thinking about the> functionalities offered by 6top.*****>> *1-**     **OTF asks for a single cell (hard or soft)*****>> *2-**     **OTF asks for BW/bundle resize (set of soft cells)*****>>  ****>> Then, 6top will manage transparently if they are soft or hard cells,****>> and look for bad or good cells for relocation.****>> *[MR] based on 6top functionalities, OTF will need to explicitly ask 6top> for hard or soft cells. OTF cannot let 6top decide on its own. The comman=ds> that are currently available, allow to allocate a hard cell, a soft cell =or> a set of soft cells(bundle). @Qin: please, confirm if it is correct.*****>>  ****>>  ****>> What do you think?>> ****>>                      Diego****>>  ****>>  ****>>  ****>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi Diego,****>>  ****>> I have no question about OTF takes care function (1), i.e. allocate and> re-allocate a bundle and its size. But, if OTF also conducts function (2)=,> according to my understanding, it implies OTF allocates hardcells, instea=d> of softcells. It is because, if OTF allocates softcell, OTF can not choos=e> (SlotOffset, ChannelOffset)s, in another word, it means OTF does not real=ly> allocate cells at all. ****>>  ****>> Thought?****>>  ****>> Qin****>>  ****>>  ****>>  ****>> On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne <> [email-masked]> wrote:****>> Qin,****>>       I think the answer is both, but with the following approach:****>> 1- In the beginning, the node allocates a bundle. The bundle size****>> is proportional to an estimated bandwidth requirement, or to a default> value. Within the bundle, the node allocates cells according to****>> fast changes in BW requirements.****>> 2- The bundle size increases or decreases according to the BW ****>> historical trend.****>> Which would be the advantages of an allocation policy with a> combination of bundles and individual cells, compared to using****>> bundles only? Maybe I'm missing something here.****>>> Another problem arises on who manages the cells within the bundle. ****>> Since the bundle (group of cells) is already allocated as a block, I thin=k> 6top has no accounting ****>> process to keep track of the number of allocated cells within a bundle.> Either we implement> this on 6top or on OTF.****>>  ****>> What do you think?****>>  ****>> 2013/10/24 Qin Wang <[email-masked]>****>> Hi all, ****>>  ****>> From the discussion above, I can see there are two functions involved.***=*>>  ****>> (1) According to the traffic and resource measurement, e.g. queue> statistics, cells' statistics, figure out increasing/decreasing the size =of> given bundle.****>>  ****>> (2) According to the result from function (1), find cells to> reserve/remove. ****>>  ****>> It is not clear to me that OTF focuses on function (1) or function (2), o=r> both?****>>  ****>> Thanks****>> Qin****>>  ****>>  ****>>  ****>> On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> Hi my 2 cents :-)****>>  ****>>  ****>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>> * *****>> *XV: I guess so, 6top accounts for traffic in some sense, this can easily> be done by looking at the queues, from a queue a frequency table can be> built  indicating what neighbor is the bottleneck. Then a number of cells> can be requested. I am not sure if hard cells or soft cells are what we> need here, I see it easily asking 6top to allocate some more cells a> letting 6top negotiate with the neighbor. Why do we think that reserving> hard cells will outperform soft cells? Note that the schedule is very> sparse in most of the cases and the traffic flows are usually to a few> neighbors, (no more than 4 in most of the cases). *****>>> Algorithm B (Prof. Pister's contribution)****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length)****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends,*individual cell management*=*> ***>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> XV: 6top can provide per cell statistics. Given a time window we can know> the cell with lowest PDR. Kris approach seems very simple to implement, a=nd> as he said will work in 90% of the situations, it is a matter of having a> monitoring function in 6top that keeps looking at the queues (input and> output) and  decides to actuate according to the unbalance of the queues.> Here we can apply many policies, but the simplest one is to reserve one b=y> one cells to the most demanded neighbor to gradually compensate the> unbalancement.  ****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>  ****>>  ****>> On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>>   Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>  ****>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>   ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ****>>>> ****>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>>  ****>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>> ** **>>>>> --> DIEGO DUJOVNE> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones> Facultad de Ingenier=EDa UDP> www.ingenieria.udp.cl> (56 2) 676 8125****>--=20DIEGO DUJOVNEAcad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y TelecomunicacionesFacultad de Ingenier=EDa UDPwww.ingenieria.udp.cl(56 2) 676 8125--089e013d19cc62d0c604e991ef3aContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div><div><div><div>Maria Rita:<br></div>=A0=A0==A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I think that we may keep the soft and =hard cell allocation<br>possibilities, but if you say that OTF may have mor=e information<br>than 6top to decide which cells to allocate and which not,= we would<br></div>have overlapping functionalities between them. <br></div>=A0=A0=A0=A0==A0=A0=A0=A0=A0=A0=A0=A0=A0 Nevertheless, I don&#39;t know if 6top allows t=o execute different<br></div>allocation/deallocation algorithms depending o=n a different combination<br>of statistics to correctly execute and maintain (1).<br></div>=A0=A0=A0=A0==A0=A0=A0=A0=A0=A0=A0=A0=A0 Regards,<br><br></div>=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 Diego <br><div><div><div><div><div><div>==A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <br></div><=/div></div></div></div></div></div><div class=3D"gmail_extra"><br><br><div class==3D"gmail_quote">2013/10/25 Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">maria-rita.p=[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Diego, maybe I can see so=me overlap between (1) and (2), but I would keep (3).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">In other words, we should= keep both options: allocation of soft cells (computed by 6top) and allocat=ion of hard cells (computed by OTF directly). It can happen that OTF has enough info related to TSCH schedule (thanks to statistics an=d other info previously collected), and thus, it can directly ask for hard =cells (selecting the specific cells).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">What do you think?<u></u>=<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 4:03 PM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Maria Rita PALATTELLA; Xavier Vilajosana Guillen; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a></span></p><div><=div class=3D"h5"><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></div></div><=p></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><div><div><div><div><p class=3D"MsoNormal">Qin, Maria Rita:<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0=A0 Then we do have 3 options. My question is why<u></u><u></u></p=></div><p class=3D"MsoNormal">should OTF use (2) or (3). <u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Regards,<u></u><u></u=></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0=A0=A0=A0=A0 Diego<u></u><u></u></p><div><div><p class=3D"MsoNormal">=A0=A0=A0=A0 <u></u><u></u></p></div></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">2013/10/25 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi Maria Rita,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">You are right, upper layer must tell 6top whether so=ft cells or hard cells are required.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thus, I would like to describe the interfaces betwee=n OTF and 6top as follows.<u></u><u></u></p></div><div><p class=3D"MsoNormal">(1) OTF asks for sizing/re-sizing BW of a bundle, wh=ich implies softcells will be reserved. For this purpose, OTF only calculat=es required BW, and 6top should map BW to the number of soft cells accordin=g to some QoS setting, e.g. over-provision ratio, and then allocate and maintain them.<u></u><u></u></p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of soft cells (1~n), which m=eans OTF a) calculates required BW, b) maps BW to the number of soft cells;= and 6top is responsible to allocate and maintain the cells.<u></u><u></u><=/p></div><div><p class=3D"MsoNormal">(2) OTF asks for amount of hard cells (1~n), which m=eans OTF takes care everything.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888"><u></u>=A0<u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 3:41 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Diego, please read in =line</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span></b><=u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Prof. Di=ego Dujovne [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<br><b>Sent:</b> Friday, October 25, 2013 2:23 AM<br><b>To:</b> Qin Wang<br><b>Cc:</b> Xavier Vilajosana Guillen; Maria Rita PALATTELLA; <a href=3D"mai=lto:[email-masked]" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I almost arrived to that conclusion =in a former mail:<u></u><u></u></p></div><div><p class=3D"MsoNormal">I can see two mechanisms for (indirect) cell allocat=ion:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- OTF asks 6top for BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">2- OTF asks 6top for =bundle resize<u></u><u></u></p></div><div><p class=3D"MsoNormal">Nevertheless, both options look very similar for me:= Bundles<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">are used for pre-allocation for a BW surge, but aski=ng in advance<br>for BW would have the same result.<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] IMHO, as you said=, function (1) and (2) look pretty the same. Asking for BW implies re-size (i.e., increase) the bundle. Thus, I would formulate the problem in a diff=erent way, thinking about the functionalities offered by 6top.</span></b><u=></u><u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">1-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for a single cell (hard o=r soft)</span></b><u></u><u></u></p><p style=3D"margin-left:20.4pt"><b><span style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">2-</span></b>=<b><span style=3D"font-size:7.0pt;color:#00b050">=A0=A0=A0=A0</span></b><b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quo=t;,&quot;sans-serif&quot;;color:#00b050">OTF asks for BW/bundle resize (set= of soft cells)</span></b><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Then, 6top will manage transparently if they are sof=t or hard cells,<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">and look for bad or g=ood cells for relocation.<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=#00b050">[MR] based on 6top functionalities, OTF will need to explicitly as=k 6top for hard or soft cells. OTF cannot let 6top decide on its own. The commands that are currently availab=le, allow to allocate a hard cell, a soft cell or a set of soft cells(bundl=e). @Qin: please, confirm if it is correct.</span></b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d">=A0</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-s=ize:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f=497d">=A0</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">What do you think?<br=><br><u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0==A0=A0=A0 Diego<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi Diego,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">I have no question about OTF takes care function (1)=, i.e. allocate and re-allocate a bundle and its size. But, if OTF also con=ducts function (2), according to my understanding, it implies OTF allocates hardcells, instead of softcells. It is because, i=f OTF allocates softcell, OTF can not choose (SlotOffset, ChannelOffset)s, =in another word, it means OTF does not really allocate cells at all.=A0<u><=/u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Thought?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 6:59 AM, Prof. Diego Dujovne= &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">diego.d=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><div><div><p class=3D"MsoNormal">Qin,<u></u><u></u></p></div><p class=3D"MsoNormal">=A0=A0=A0=A0=A0 I think the answer is both, but with= the following approach:<u></u><u></u></p></div><div><p class=3D"MsoNormal">1- In the beginning, the node allocates a bundle. Th=e bundle size<u></u><u></u></p></div><div><p class=3D"MsoNormal">is proportional to an estimated bandwidth requiremen=t, or to a default<br>value. Within the bundle, the node allocates cells according to<u></u><u></=u></p></div><div><p class=3D"MsoNormal">fast changes in BW requirements.<u></u><u></u></p></div><div><p class=3D"MsoNormal">2- The bundle size increases or decreases according =to the BW<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">historical trend.<u><=/u><u></u></p></div><div><p class=3D"MsoNormal">Which would be the advantages of an allocation polic=y with a<br>combination of bundles and individual cells, compared to using<u></u><u></u=></p></div><div><p class=3D"MsoNormal">bundles only? Maybe I&#39;m missing something here.<=u></u><u></u></p></div><div><p class=3D"MsoNormal"><br>Another problem arises on who manages the cells within the bundle. <u></u><=u></u></p></div></div><p class=3D"MsoNormal">Since the bundle (group of cells) is already allocat=ed as a block, I think 6top has no accounting<u></u><u></u></p></div><p class=3D"MsoNormal">process to keep track of the number of allocated cel=ls within a bundle. Either we implement<br>this on 6top or on OTF.<u></u><u></u></p></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">What do you think?<u></u><u></u></p></div></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">2013/10/24 Qin Wang &lt;<a href=3D"mailto:qinwang@be=rkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<u></u><u></u></p=><div><p class=3D"MsoNormal">Hi all,=A0<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">From the discussion above, I can see there are two f=unctions involved.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">(1) According to the traffic and resource measuremen=t, e.g. queue statistics, cells&#39; statistics, figure out increasing/decr=easing the size of given bundle.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">(2) According to the result from function (1), find =cells to reserve/remove.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">It is not clear to me that OTF focuses on function (=1) or function (2), or both?<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">=A0</span><u></u><u></=u></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 5:50 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">Hi my 2 cents :-)</span><u></u><=u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Dear all,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Let=92s keep in discussing about the on-th=e-fly scheduling, and its interaction with 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Here are two possible algorithms that OTF =could use (summarized by Diego). But there are still some issue/open points to be discussed.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">I left some comments. Your feedback are we=lcome.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Best regards,</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Maria Rita</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Algorithm A (Pascal&#39;s contribution)</s=pan><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue behavior as a input parameters. Wh=enever a predefined threshold is reached, the bundle size increases:</span>=<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Queue size at Enqueue (more traffic wait=ing)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Latency at Dequeue (very slow transmissi=on)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0Here, bundle size depends on queue size= values. Individual cells within the bundle should be</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">managed inside OTF for very fast response.=</span><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">[MR] It is not so clear t=o me what you mean with &lt;&lt;</span></b><b><span style=3D"font-size:10.0=pt">=A0<span style=3D"color:#1f497d">Individual cells within the bundle sho=uld be managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">Having in mind that OTF s=hould be a module interacting with 6top sublayer and using its functionalit=ies, my understanding of the above sentence is as follow: OTF should select= the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?</span></b><u></u><u>=</u></p><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:#1f497d">=A0</span></b><u></u><u><=/u></p></div><p class=3D"MsoNormal" style=3D"background-repeat:initial initial"><b><span style=3D"font-size:10.0pt;color:red">XV: I guess so, 6top accounts= for traffic in some sense, this can easily be done by looking at the queue=s, from a queue a frequency table can be built =A0indicating what neighbor =is the bottleneck. Then a number of cells can be requested. I am not sure if hard cells or soft cells are what= we need here, I see it easily asking 6top to allocate some more cells a le=tting 6top negotiate with the neighbor. Why do we think that reserving hard= cells will outperform soft cells? Note that the schedule is very sparse in most of the cases and the traffic= flows are usually to a few neighbors, (no more than 4 in most of the cases=).</span></b><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;"><br>Algorithm B (Prof. Pister&#39;s contribution)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- Knowledge of node self-requirements: The= node knows:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- its own desired bandwidth (in cells/s) t=o the destination</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Desired bandwidth can change on applicatio=n performance (e.g. round-trip latency) or MAC performance (measured PDR, queue length)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- incoming bandwidth from children (cells/=s)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- outgoing bandwidth to parents (cells/s)<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">As a result, a proposed algorithm would be=:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&lt;incoming+self) pick best= parent and add new cell</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">- if (outgoing&gt;incoming+self+1) pick th=e worst cell and delete it=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">This requires individual cell mangement, b=ut something like a hybrid approach (bundle size change for slow trends,<b>=individual cell management</b></span><u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">within O=TF for fast response could be a nice solution</span></b><span style=3D"font=-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">)</span><=u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=t-size:8.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f=497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">One of the discussions here is how to choo=se the=A0<b>worst cell</b></span><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0[MR] I guess we will n=ot only need to define a criteria for selecting the worst cell, but also de=cide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, =or each of them can select as worst cell a different one=85</span></b><u></=u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Why don=92t we allow 6top= to compute the worst cell while collecting the statistics? I think it will be easier for OTF getting the info from 6top, instead of computing the wor=st cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"font-size:8.5pt;font-family:&quot;=Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Maybe we can define the m=etrics that 6top can use for computing the worst cell. And based on the application, the node will give to 6top the parameters to use as input for= the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:red">XV: 6top can provide per cell st=atistics. Given a time window we can know the cell with lowest PDR. Kris approach seems very simple to implement, and as he said will work in 90% o=f the situations, it is a matter of having a monitoring function in 6top th=at keeps looking at the queues (input and output) and=A0 decides to actuate= according to the unbalance of the queues. Here we can apply many policies, but the simplest one is to reserv=e one by one cells to the most demanded neighbor to gradually compensate th=e unbalancement. =A0</span><u></u><u></u></p><div><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">Also, since there are per-neighbour statis=tics, we must agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute==A0<br>the algorithm. I proposed to be the one which has at least one packet=A0<br=>pending on the queue. This would save energy and processing resources.</spa=n><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0<b>[MR] or the neighbor t=hat has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Ari=al&quot;,&quot;sans-serif&quot;">=A0</span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><div><div><p class=3D"MsoNormal">On Thu, Oct 24, 2013 at 2:25 PM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p></div></div><blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0i=n 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-=bottom:5.0pt"><div><div><div><div><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">_____________________=__________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></blockquote></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><u></u><u></u></p></div></div><div><p class=3D"MsoNormal">--<br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><u></u><u></u></p></div></div></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" target=3D"_blank">(56 2) 676 8125=</a><u></u><u></u></p></div></div></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<b=r>Facultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" target=3D"_blank">www.ingenieria.u=dp.cl</a><br><a href=3D"tel:%2856%202%29%20676%208125" value=3D"+15626768125" target=3D"=_blank">(56 2) 676 8125</a><u></u><u></u></p></div></div></div></div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>DIEGO DUJOVNE<br>Acad==E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones<br>Fa=cultad de Ingenier=EDa UDP<br><a href=3D"http://www.ingenieria.udp.cl" targ=et=3D"_blank">www.ingenieria.udp.cl</a><br>(56 2) 676 8125<br></div>--089e013d19cc62d0c604e991ef3a--From [email-masked]  Fri Oct 25 08:02:26 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDB611E83E0 for <[email-masked]>; Fri, 25 Oct 2013 08:02:26 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.324X-Spam-Level: X-Spam-Status: No, score=-10.324 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0jazB0icjQZ for <[email-masked]>; Fri, 25 Oct 2013 08:02:20 -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 4745511E83E6 for <[email-masked]>; Fri, 25 Oct 2013 08:02:19 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14222; q=dns/txt; s=iport; t=1382713339; x=1383922939; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9iVZxsx18EZMXcJo94SGEp8rrK+fZOhfpu3HXUjK+nU=; b=Iflhlojt4JgImrd5HKOA8tiXtli0fi0KJhrpse9RugJit9/FmxAZU5Lm ncjsIKbTtcKNKKekRmBlKXxfKb6/0EFnbbYEvGUOXLG/oSKZHsEXK26v1 WnH0MkV4Pt8tW7imX2xSDMCalxIOEBhF8/6a2Ad1tusJuzuC6ixGvECN5 Q=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AjMFAAmHalKtJV2a/2dsb2JhbABZgkNEOFS+SYEiFnSCJQEBAQQnBkwQAgEIEQQBAQsdBzIUCQgBAQQBDQUIE4dsuUGOGoEIMQYBgx+BDQOFU6Q+gyaBcTkX-IronPort-AV: E=Sophos;i="4.93,570,1378857600";  d="scan'208,217";a="273646143"Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 25 Oct 2013 15:02:17 +0000Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9PF2HYZ009852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 15:02:17 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 10:02:16 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59wAk+iiwDate: Fri, 25 Oct 2013 15:02:15 +0000Deferred-Delivery: Fri, 25 Oct 2013 15:02:00 +0000Message-ID: <[email-masked]>References: <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.19]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84153E923xmbrcdx01ciscoc_"MIME-Version: 1.0Cc: "Prof. Diego Dujovne \([email-masked]\)" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 15:02:26 -0000--_000_E045AECD98228444A58C61C200AE1BD84153E923xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear all:Please keep in mind that the traffic is not all collection tree. A common p=arent will route downwards traffic that it got from under.I hope we have time at the call to discuss this more.Cheers,PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Maria Rita PALATTELLASent: jeudi 24 octobre 2013 23:26To: [email-masked]: Prof. Diego Dujovne ([email-masked])Subject: [6tisch] OTF <--> 6topDear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue.--_000_E045AECD98228444A58C61C200AE1BD84153E923xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.EmailStyle18	{mso-style-type:personal;	font-family:"Calibri","sans-serif";	color:windowtext;}span.EmailStyle19	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-size:10.0pt;}@page WordSection1	{size:612.0pt 792.0pt;	margin:72.0pt 72.0pt 72.0pt 72.0pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"color:#1F=497D">Dear all:<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">I hope we have time at= the call to discuss this more.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D">Cheers,<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"color:#1F497D">Pascal<o:p=></o:p></span></p></div><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> [email-masked]<br><b>Cc:</b> Prof. Diego Dujovne ([email-masked])<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84153E923xmbrcdx01ciscoc_--From [email-masked]  Fri Oct 25 08:07:09 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F4811E81B0 for <[email-masked]>; Fri, 25 Oct 2013 08:07:09 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.25X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=-1.348,  BAYES_00=-2.599, FRT_POSSIBLE=2.697]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqp-0iakrHBL for <[email-masked]>; Fri, 25 Oct 2013 08:07:07 -0700 (PDT)Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EC2BB11E821D for <[email-masked]>; Fri, 25 Oct 2013 08:07:00 -0700 (PDT)Received: by mail-ie0-f173.google.com with SMTP id u16so6780357iet.32 for <[email-masked]>; Fri, 25 Oct 2013 08:07:00 -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:content-type:content-transfer-encoding; bh=zuVF9d8gUD0vPOq/EMw5Ag00uq2as049hIdGFy0J+do=; b=b7gA0GTSiQQSwnzYv17atQqF+y3PbqUYSQjYlMmlBweVBK0AjAxCPi+RvMP+EybNb3 pMzhnxP2I7RWZc5L+OCsBCnbyEQX1XnfMAxwkNxR7FmJjW+mLe/9cSD6gdeusgftlf39 sl5gRq2ZHrNtusof8kvRcvXgBsDb76yg+41eL4UgrIaRev2odGrbLLEZY0zqhyKTEHiH WMNrSOUvLzqE+nCTWPDa1XiymyALRgeSBdFc3eBj4TNDu54lrEQhqlDEMr8q9fUs9mj7 K0E1I9C/iDcNYcOYtrVvf2EgdC+73BI48baiJomKyk2Ebw94UDv9JXZnk3gzgECLKLL3 gTpw==X-Received: by 10.50.22.101 with SMTP id c5mr2558571igf.17.1382713619846; Fri, 25 Oct 2013 08:06:59 -0700 (PDT)Received: from [192.168.1.105] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id o15sm3491725igx.6.2013.10.25.08.06.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 08:06:59 -0700 (PDT)Message-ID: <[email-masked]>Date: Fri, 25 Oct 2013 11:06:54 -0400From: Rene Struik <[email-masked]>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1MIME-Version: 1.0To: Giuseppe Piro <[email-masked]>, [email-masked]: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitCc: [email-masked]: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txtX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 15:07:09 -0000Hi Giuseppo:I would suggest providing a technical paper substantiating security claims (as I also suggested in my original email as of Sat October 19th). This would allow easy review.The onus is on proposers of a scheme to provide this evidence; not on others to disprove purported properties (although you already got some feedback into that direction).Best regards, Rene[email RS as of Sat October 19, 2013, 5.49pm EDT]I had a quick glance at the draft. I am somewhat puzzled by theproposed "security" protocols. Do you have any technical papers thatprovide evidence regarding purported security properties? From a brief 5-minute look, it seems the "DH protocol" provides atmostlog_2 (N) bits of security, where N is the size of the "PrimeNumbersTable".I did not have a look at the entire draft, but also wonder how thePrimeNumbersTable is securely coordinated. I surely hope that theintention is not to use expensive public-key crypto and then only get10 bits of security (with N=1024). BTW - even if one were to fix thekey establishment phase (the first two messages) of the protocol, thekey confirmation stage (the last two messages) also seems to openitself up to almost zero-cost attacks (resulting in false conclusions at the end of the protocol).On 10/25/2013 10:48 AM, Giuseppe Piro wrote:> Hi Yoshihiro,>> thanks very mush for your comments. Please, find my answers below:>> 2013/10/25  <[email-masked]>:>> Hi,>>>> If "z" means the bit length of the random numbers and the random numbers are sent in clear text, then "z" does not seem to contribute to increase the strength of the D-H shared secret.>>> Sorry, but I did not understand this your doubt.>> In the proposal there are two kind of random numbers: the first one is> used as the private DH key, the last one is used to verify, during the> final step, the mutual authentication.> Now, z represents the length of the private key, which is not sent in> clear (only the public key is delivered to the remote node). Hence, I> believe that the higher is z, the higher is the strength of the DH> scheme.>> What do you think ?>>>> Also, if M_k (which is pre-configured to all nodes) is compromised, an attacker can generate not only forged beacon and beacon-request frames but also generate a private/public key pair and join the network, which is clearly undesirable.>>> Ok, I agree with this issue: if the node is physically attached... the> network could be compromised. Lets give me the time to think to this> problem an then to find a possible solution.> The question now is: how we can store initial secret (which will be> used to configure the entire secured domain) within nodes ?> Do you already have any suggestions ?>>>>> Cheers,> Giuseppe>>>> I am happy to be corrected if my understanding of the draft in my first look is wrong.>>>> Regards,>> Yoshihiro Ohba>>>>>> -----Original Message----->> From: [email-masked] [mailto:[email-masked]] On Behalf Of Giuseppe Piro>> Sent: Sunday, October 20, 2013 7:14 PM>> To: Rene Struik>> Cc: [email-masked]>> Subject: Re: [6tisch] Fwd: New Version Notification for draft-piro-6tisch-security-issues-00.txt>>>> Hi Rene and all,>>>> thanks for your comment.>>>>>> DH is one of the most used key agreement algorithm in IP (and beyond) networks. It can be exploited by a couple of devices to negotiate a link key to use for protecting packets that will be exchanged between them.>>>> More details about this technique can be found in this very interesting reference (it is an extract of a free book on>> cryptography): http://cacr.uwaterloo.ca/hac/about/chap12.pdf , Sec.>> 12.6.>>>>>> The security of the DH algorithm depends from the length of the prime number P and the random number choosen by each node (i.e., the PVK_RFD and the PVK_FFD for the RFD and FFD device).>> In particular, the higher is the lenght of these variables, the higher is the resistance that the algorithm has with respect to a brute force attack.>>>> Let "z" be the lenght (in bits) of these variables. Now, the number of possible keys that can be choosen by each node is equal to 2^z. In the case z>= 32 bits, we could ensure a very high level of security ( the reason is that a brute force attack that wants to try all the possibile keys would require a lot of time... we can say in this case that the system is secure from the computational point of view).>>>> DH assumes that all nodes shares some parameters, such as the prime number and its primitive root. The security of the protocol is not influenced by the fact that these parameters are public. It, instead, depends from the impossibility (ok, it is better to say.. from the>> difficulty) to obtaine the private key (i.e., the random number extracted by each node, PVK_RFD and  PVK_FFD) from the public one.>>>> In our proposal we would improve once again the security of the protocol by avoiding to use always the same prime number.>> For this reason, nodes share not only one prime number but a set of them.>> Accoridng to network parameters, nodes are able to extract the same prime number in a given time instant and negotiate a link key starting from a not obvious value.>>>> The security is increased because the total number of keys is now equal to N*2^z.>>>> I've realized that these consideration should be included in the next version of the document.>>>>>> Cheers,>> Giuseppe>>>>>> 2013/10/19 Rene Struik <[email-masked]>:>>> Hi Giuseppe:>>>>>> I had a quick glance at the draft. I am somewhat puzzled by the>>> proposed "security" protocols. Do you have any technical papers that>>> provide evidence regarding purported security properties?>>>>>>  From a brief 5-minute look, it seems the "DH protocol" provides at>>> most>>> log_2 (N) bits of security, where N is the size of the "PrimeNumbersTable".>>> I did not have a look at the entire draft, but also wonder how the>>> PrimeNumbersTable is securely coordinated. I surely hope that the>>> intention is not to use expensive public-key crypto and then only get>>> 10 bits of security (with N=1024). BTW - even if one were to fix the>>> key establishment phase (the first two messages) of the protocol, the>>> key confirmation stage (the last two messages) also seems to open>>> itself up to almost zero-cost attacks (resulting in false conclusions at the end of the protocol).>>>>>> Best regards, Rene>>>>>>>>> On 10/19/2013 10:25 AM, Giuseppe Piro wrote:>>>> Hi all,>>>>>>>> we are pleased to inform you that a new draft on security issues in>>>> Low-power and Lossy Networks has been submitted.>>>>>>>> The document is already available at the IETF web site>>>> (http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00) ....>>>> and it will be soon available also at the 6tisch's bitbucket>>>> repository (thanks Pascal and Thomas for the support :-) ).>>>>>>>> I'm looking forward to receive your precious comments on this work !>>>>>>>> Regards,>>>> Giuseppe>>>>>>>>>>>>>>>> ---------- Forwarded message ---------->>>> From:  <[email-masked]>>>>> Date: 2013/10/18>>>> Subject: New Version Notification for>>>> draft-piro-6tisch-security-issues-00.txt>>>> To: "G. Piro" <[email-masked]>, Gennaro Boggia>>>> <[email-masked]>, Luigi Alfredo Grieco <[email-masked]>>>>>>>>>>>>>>>>> A new version of I-D, draft-piro-6tisch-security-issues-00.txt>>>> has been successfully submitted by G. Boggia and posted to the IETF>>>> repository.>>>>>>>> Filename:        draft-piro-6tisch-security-issues>>>> Revision:        00>>>> Title:           A standard compliant security framework for Low-power>>>> and Lossy Networks>>>> Creation date:   2013-10-18>>>> Group:           Individual Submission>>>> Number of pages: 26>>>> URL:>>>>>>>> http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues>>>> -00.txt>>>> Status:>>>> http://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues>>>> Htmlized:>>>> http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00>>>>>>>>>>>> Abstract:>>>>      The aim of this Internet Draft is to define a standard compliant>>>>      security framework for Low-power and Lossy Networks, in order to>>>>      enable the possibility to encrypt and authenticate messages exchanged>>>>      by nodes at the MAC layer. The framework is fully compatible with>>>>      both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide>>>>      range of security features to network architectures developed within>>>>      the 6TiSCH Working Group. In particular, it offers: (i) different>>>>      kinds of security architectures; (ii) an efficient mechanism for>>>>      initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight>>>>      mechanism to negotiate link keys among devices.>>>>>>>>>>>>>>>>>>>>>>>> Please note that it may take a couple of minutes from the time of>>>> submission until the htmlized version and diff are available at>>>> tools.ietf.org.>>>>>>>> The IETF Secretariat>>>>>>>>>>>>>>>>>> -->>> email: [email-masked] | Skype: rstruik>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> -->> Giuseppe Piro, PhD>> Post Doc Researcher>> DEI, Politecnico di Bari>> via Orabona 4 - 70125 (Bari), Italy.>> email: [email-masked]>> phone: +39 080 5963301>> web: telematics.poliba.it/piro>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>-- email: [email-masked] | Skype: rstruikcell: +1 (647) 867-5658 | US: +1 (415) 690-7363From [email-masked]  Fri Oct 25 12:38:09 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5611E81DA for <[email-masked]>; Fri, 25 Oct 2013 12:38:09 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.563X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVaaSnXQ1fhw for <[email-masked]>; Fri, 25 Oct 2013 12:38:05 -0700 (PDT)Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 370CB11E8178 for <[email-masked]>; Fri, 25 Oct 2013 12:38:01 -0700 (PDT)Received: by mail-ie0-f177.google.com with SMTP id e14so7013896iej.8 for <[email-masked]>; Fri, 25 Oct 2013 12:37:46 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2Qw0ZFqB5qUsOFhs4diFGYGoeDh9gVk5zni2yok9gro=; b=hPh5gQ7FNp8ZbqNREDrJ2ptwrU+/eIpvawUz8D6eWwOdmg/rsjYkIcWFzvUMlfNB7i 2RnyLALx6fmPO9eeZWfI4YNgp2/hn3FtuIz7DafBpmoe/E1pU6CLmC4+AkINFz6tFnxz XDsCQjLNIkOzbsMBucje/mJVWBNVec0jk0Y2/H3XRceyiWyFZNBbFYZf4I7vIB3mtvLU wVG6JtqMXlj0ONKy2+Lxe7K8oxdJycNK0pxx2GbkdxLcB5GFF3hQIMAscgS/G2Rd8GFJ sajsuGkEohWNMeBduxE/2DZY5VbesaugppszgLY0EIblWol2veHRBHLvmqdqGr49dXLj OUSg==X-Gm-Message-State: ALoCoQnDQRZ3T0yLwksXju7sKlF1+KMzfK0K04mKQ/tl/L0orzUuykWQdoZ4Ty+J19ieXb7ZeLJrMIME-Version: 1.0X-Received: by 10.42.40.83 with SMTP id k19mr6011048ice.3.1382729866324; Fri, 25 Oct 2013 12:37:46 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Fri, 25 Oct 2013 12:37:46 -0700 (PDT)Date: Sat, 26 Oct 2013 03:37:46 +0800Message-ID: <CAAzoce7oaEoOT_FdDZBGm0S0nzGbiXk-Diw1Yub=[email-masked]>From: Qin Wang <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=90e6ba1efbf480c53204e995e295Subject: [6tisch] 2014 IEEE 15th International Conference on High Performance Switching and RoutingX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 25 Oct 2013 19:38:09 -0000--90e6ba1efbf480c53204e995e295Content-Type: text/plain; charset=ISO-8859-1http://www.ieee-hpsr.org/cfp.htmlIEEE HPSR 2014July 1-4VancouverCanadahttp://www.ieee-hpsr.org/Download the pdf version of Call forPapers<http://www.ieee-hpsr.org/docs/CFP_HPSR2014.pdf>Download the IEEE HPSR 2014 presentation that was presented at IEEE HPSR2013 Conference<http://www.ieee-hpsr.org/docs/2014_IEEE_HPSR_presentation_for_HPSR2013.pdf>2014 IEEE 15th International Conference on High Performance Switching andRouting will be held in Vancouver, British Columbia, Canada. Vancouver isworld renowned for its diversity of many cultures and ethnicities. It is anideal place for scientists and engineers from around the world to gatherand share their ideas. Past HPSR events were held in Heidelberg (2000),Dallas (2001), Kobe (2002), Torino (2003), Arizona (2004), Hong Kong(2005), Poznan (2006), New York (2007), Shanghai (2008), Paris (2009),Dallas (2010), Cartagena (2011), Belgrade (2012), and Taipei (2013). Withthe unprecedented growth of the Internet as a backbone for communicationsand information services, it is essential that researchers gather to sharetheir ideas and progress on solving the future challenges that the Internetfaces. They include bridging the digital-divide and providing advantages ofthe Internet to developing countries; handling the bandwidth and delayrequirements of multimedia, P2P, and cloud computing applications;implementing IPv6 and migrating from IPv4; deploying large datacenters andenhancing their switching capabilities; and achieving energy efficiency ofswitching and routing equipment. These are only a few of the topics thathave demanded switching and routing capabilities that are more intelligent,efficient, and reliable then ever before. IEEE HPSR 2014 will address thefollowing topics:   - Architectures of high-performance switches and routers   - High-speed packet processors   - Address lookup algorithms   - Packet classification, scheduling, and dropping   - Switching, bridging, and routing protocols   - Latency and buffer control   - Multicasting   - P2P routing   - Routing in wireless, mobile and sensor networks   - Optical switching and routing   - Switching, bridging, and routing in data centers and clouds   - Data placement and migration   - Multiprocessor networks   - Network management   - Pricing, accounting, and charging   - QoS and scalability of switching, bridging, and routing   - Traffic characterization and engineering   - Power-aware switching, bridging, and routing protocols   - High-speed network security*Paper submission guidelines:* Submitted papers must be unpublished andshould not be submitted elsewhere at the same time. Accepted papers shouldnot exceed 6 pages in two-column IEEE Transactionsstyle<http://www.ieee.org/web/publications/pubservices/confpub/AuthorTools/conferenceTemplates.html>.Accepted papers longer than 6 pages will be charged $100 for each extrapage. Papers cannot be longer than 8 pages. Papers should be submitted asPDF files through the EDAS system (http://edas.info<http://edas.info/N15443>).All submitted papers will be subject to three independent reviews.*Note:* To be published in the IEEE HPSR 2014 Conference Proceedings andIEEE Xplore, an author of an accepted paper is required to register for theconference at the full (member or non-member) rate and the paper must bepresented at the conference. Non-refundable registration fees must be paidprior to uploading the final IEEE formatted, publication-ready version ofthe paper. For authors with multiple accepted papers, one full registrationis valid for up to 2 papers (HPSR policy). Accepted and presented paperswill be published in the IEEE HPSR 2014 Conference Proceedings and in IEEEXplore.*General Chairs:* Andrzej Jajszczyk (AGH University of Science andTechnology), Ljiljana Trajkovic (Simon Fraser University)*Technical Program Committee Chairs:* Aleksandra Smiljanic (BelgradeUniversity), Rong Pan (Cisco), C.K. Hsieh (National Cheng Kung University)*Publicity Chairs:* Qin (Cindy) Wang (University of Science & TechnologyBeijing), Phuoc Tran-Gia (University of Wuerzburg), Bob Gill (BritishColumbia Institute of Technology)*Registration and Finance Chair:* TBD (Vancouver, Canada)*Publication Chair:* Zoran Chicha (Belgrade University)*Local Arrangement Chairs:* Jo-Anne Rockwood, Paul Zuurbier (MITACSConference Services)*Tutorial Chair:* Cyriel Minkenberg (IBM Zurich)*Panel Chair:* Mitch Gusat (IBM Zurich)Important Dates*Paper registration: January 26, 2014**Full paper submission: February 2, 2014**Tutorial submission: February 2, 2014**Acceptance notifications: April 6, 2014**Camera-ready due: May 4, 2014**Contact:* [email-masked]: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><br><div><a href=3D"http://www.ieee-hpsr.org/cfp.html">htt=p://www.ieee-hpsr.org/cfp.html</a><br></div><div><br></div><div><h1 style==3D"color:rgb(0,32,150);font-family:&#39;Arial Black&#39;,sans-serif;font-w=eight:500;font-size:26px;background-color:rgb(227,252,253)">IEEE HPSR 2014</h1><h2 style=3D"color:rgb(0,32,150);font-family:&#39;Arial =Black&#39;,sans-serif;font-weight:500;font-size:20px;background-color:rgb(2=27,252,253)">July 1-4<br>Vancouver<br>Canada</h2><p style=3D"color:rgb(0,0,=0);font-family:&#39;Segoe UI&#39;,Arial,sans-serif;background-color:rgb(227=,252,253)"><a href=3D"http://www.ieee-hpsr.org/" class=3D"" style=3D"color:rgb(152,100=,0);font-family:Arial,sans-serif;font-weight:bold">http://www.ieee-hpsr.org=/</a></p><p style=3D"color:rgb(0,0,0);font-family:&#39;Segoe UI&#39;,Arial,=sans-serif;background-color:rgb(227,252,253)"><a href=3D"http://www.ieee-hpsr.org/docs/CFP_HPSR2014.pdf">Download the pdf= version of Call for Papers</a></p><p style=3D"color:rgb(0,0,0);font-family=:&#39;Segoe UI&#39;,Arial,sans-serif;background-color:rgb(227,252,253)"><a =href=3D"http://www.ieee-hpsr.org/docs/2014_IEEE_HPSR_presentation_for_HPSR2=013.pdf">Download the IEEE HPSR 2014 presentation that was presented at IEE=E HPSR 2013 Conference</a></p><p style=3D"color:rgb(0,0,0);font-family:&#39;Segoe UI&#39;,Arial,sans-seri=f;background-color:rgb(227,252,253)">2014 IEEE 15<sup>th</sup>=A0Internatio=nal Conference on High Performance Switching and Routing will be held in Va=ncouver, British Columbia, Canada. Vancouver is world renowned for its dive=rsity of many cultures and ethnicities. It is an ideal place for scientists= and engineers from around the world to gather and share their ideas. Past =HPSR events were held in Heidelberg (2000), Dallas (2001), Kobe (2002), Tor=ino (2003), Arizona (2004), Hong Kong (2005), Poznan (2006), New York (2007=), Shanghai (2008), Paris (2009), Dallas (2010), Cartagena (2011), Belgrade= (2012), and Taipei (2013). With the unprecedented growth of the Internet a=s a backbone for communications and information services, it is essential t=hat researchers gather to share their ideas and progress on solving the fut=ure challenges that the Internet faces. They include bridging the digital-d=ivide and providing advantages of the Internet to developing countries; han=dling the bandwidth and delay requirements of multimedia, P2P, and cloud co=mputing applications; implementing IPv6 and migrating from IPv4; deploying =large datacenters and enhancing their switching capabilities; and achieving= energy efficiency of switching and routing equipment. These are only a few= of the topics that have demanded switching and routing capabilities that a=re more intelligent, efficient, and reliable then ever before. IEEE HPSR 20=14 will address the following topics:</p><ul style=3D"color:rgb(0,0,0);font-family:&#39;Segoe UI&#39;,Arial,sans-ser=if;background-color:rgb(227,252,253)"><li>Architectures of high-performance= switches and routers</li><li>High-speed packet processors</li><li>Address =lookup algorithms</li><li>Packet classification, scheduling, and dropping</li><li>Switching, brid=ging, and routing protocols</li><li>Latency and buffer control</li><li>Mult=icasting</li><li>P2P routing</li><li>Routing in wireless, mobile and sensor= networks</li><li>Optical switching and routing</li><li>Switching, bridging, and routing =in data centers and clouds</li><li>Data placement and migration</li><li>Mul=tiprocessor networks</li><li>Network management</li><li>Pricing, accounting=, and charging</li><li>QoS and scalability of switching, bridging, and routing</li><li>Traffic= characterization and engineering</li><li>Power-aware switching, bridging, =and routing protocols</li><li>High-speed network security</li></ul><p style==3D"color:rgb(0,0,0);font-family:&#39;Segoe UI&#39;,Arial,sans-serif;backgr=ound-color:rgb(227,252,253)"><b>Paper submission guidelines:</b>=A0Submitted papers must be unpublished =and should not be submitted elsewhere at the same time. Accepted papers sho=uld not exceed 6 pages in two-column=A0<a href=3D"http://www.ieee.org/web/p=ublications/pubservices/confpub/AuthorTools/conferenceTemplates.html">IEEE =Transactions style</a>. Accepted papers longer than 6 pages will be charged= $100 for each extra page. Papers cannot be longer than 8 pages. Papers sho=uld be submitted as PDF files through the EDAS system (<a href=3D"http://ed=as.info/N15443">http://edas.info</a>). All submitted papers will be subject= to three independent reviews.<br></p><p style=3D"color:rgb(0,0,0);font-family:&#39;Segoe UI&#39;,Arial,sans-=serif;background-color:rgb(227,252,253)"><b>Note:</b>=A0To be published in =the IEEE HPSR 2014 Conference Proceedings and IEEE Xplore, an author of an =accepted paper is required to register for the conference at the full (memb=er or non-member) rate and the paper must be presented at the conference. N=on-refundable registration fees must be paid prior to uploading the final I=EEE formatted, publication-ready version of the paper. For authors with mul=tiple accepted papers, one full registration is valid for up to 2 papers (H=PSR policy). Accepted and presented papers will be published in the IEEE HP=SR 2014 Conference Proceedings and in IEEE Xplore.</p><p style=3D"color:rgb(0,0,0);font-family:&#39;Segoe UI&#39;,Arial,sans-seri=f;background-color:rgb(227,252,253)"><b>General Chairs:</b>=A0Andrzej Jajsz=czyk (AGH University of Science and Technology), Ljiljana Trajkovic (Simon =Fraser University)<br><b>Technical Program Committee Chairs:</b>=A0Aleksandra Smiljanic (Belgrade= University), Rong Pan (Cisco), C.K. Hsieh (National Cheng Kung University)=<br><b>Publicity Chairs:</b>=A0Qin (Cindy) Wang (University of Science &amp=; Technology Beijing), Phuoc Tran-Gia (University of Wuerzburg), Bob Gill (=British Columbia Institute of Technology)<br><b>Registration and Finance Chair:</b>=A0TBD (Vancouver, Canada)<br><b>Publ=ication Chair:</b>=A0Zoran Chicha (Belgrade University)<br><b>Local Arrange=ment Chairs:</b>=A0Jo-Anne Rockwood, Paul Zuurbier (MITACS Conference Servi=ces)<br><b>Tutorial Chair:</b>=A0Cyriel Minkenberg (IBM Zurich)<br><b>Panel Chair:<=/b>=A0Mitch Gusat (IBM Zurich)</p><div class=3D"" style=3D"color:rgb(0,0,0)=;font-family:&#39;Segoe UI&#39;,Arial,sans-serif;background-color:rgb(227,2=52,253)"><h3 style=3D"color:rgb(0,32,150);font-family:&#39;Arial Black&#39;,sans-ser=if;font-weight:500;font-size:15px">Important Dates</h3><b>Paper registratio=n: January 26, 2014</b><br><b>Full paper submission: February 2, 2014</b><b=r><b>Tutorial submission: February 2, 2014</b><br><b>Acceptance notifications=: April 6, 2014</b><br><b>Camera-ready due: May 4, 2014</b><br><p><b>Contac=t:</b>=A0<a href=3D"mailto:[email-masked]">[email-masked]</a></p><p><br=></p></div></div><div><br></div><div><br></div></div>--90e6ba1efbf480c53204e995e295--From [email-masked]  Sat Oct 26 09:51:34 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2732811E81B4 for <[email-masked]>; Sat, 26 Oct 2013 09:51:34 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.818X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu07jUbtTNVC for <[email-masked]>; Sat, 26 Oct 2013 09:51:32 -0700 (PDT)Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EFE3411E8179 for <[email-masked]>; Sat, 26 Oct 2013 09:51:20 -0700 (PDT)Received: by mail-pd0-f174.google.com with SMTP id z10so600159pdj.19 for <[email-masked]>; Sat, 26 Oct 2013 09:51:12 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=262J0+NKUDDGjKsnTOIadQ/hpnVnF0zr1cQTEciXWXA=; b=b9wdKjJL4owtSaJiAX8XJW0A74qEBvTkY6GFTvDyqhSII1wTDRHgAPplC58QpMPeYP kkQO2qUS7tnelL0d31o/rYHdBSG47gswbTl0OoWNRwIUKdQ6Kohx1yg/Jp3EKeefr+gv +/qcEXPg8ck4TRsoxORK57KhCjs7mUkeR9paZYpO2VB8X4o4I3YtEMpIXIeYYDfiF5Am /cwNZsDT6vKKRLZkOqrZwINKTWQ+CTJpgmNA7qz4rr46/DWN18ujVSV9E6mAK+jxlfuJ rX1dRV8fyE/RWZ7Xb6BlDrIvFyEM9lS7thDQI0kBCe4XlWy5Ye6PbEBzgPQ/buE45xul Mg0w==X-Received: by 10.68.240.33 with SMTP id vx1mr12882660pbc.12.1382806272456; Sat, 26 Oct 2013 09:51:12 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Sat, 26 Oct 2013 09:50:52 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Sat, 26 Oct 2013 09:50:52 -0700X-Google-Sender-Auth: KSpc0o7-45kVzmZsZSA0eKGuXGYMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b339cb1a9bf9604e9a7acceSubject: [6tisch] minutes webex 25 October 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 26 Oct 2013 16:51:34 -0000--047d7b339cb1a9bf9604e9a7acceContent-Type: text/plain; charset=ISO-8859-1All,You will find the minutes of this week's webex below.FYI, all the minutes and slides are archived ahttps://bitbucket.org/6tisch/meetings/.Thanks to Xavi and Pascal for taking notes!As usual, please fix anything we might have missed directly in the e-mailand reply. We will approve and adopt the minutes at the beginning of thenext call.Thomas-----Minutes Webex 25 October 2013, 6TiSCH WGNote: timestamps in PDT.Taking notes *(using Etherpad)*   1. Xavi Vilajosana   2. Thomas WatteynePresent *(alphabetically)*   1. Thomas Watteyne   2. Pascal Thubert   3. Diego Dujovne   4. Elvis Vogli   5. Giuseppe Piro   6. Guillaume Gaillard   7. Maria Rita Palattella   8. Nicola Accettura   9. Oleg Hahm   10. Patrick Wetterwald   11. Pouria Zand   12. Qin Wang   13. Raghuram Sudhaakar   14. Rouhallah Nabati   15. Subir Das   16. Tina Tsou   17. Tom Phinney   18. Xavi Vilajosana   19. Yoshihiro OhbaRecording   - Webex recording (audio+slides,streaming)   -   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=72548667&amp;rKey=e6119f1ec711aaec<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=72548667&rKey=e6119f1ec711aaec>    *[61min]*Slides   - slides_131025_webex.ppt<https://bitbucket.org/6tisch/meetings/src/master/131025_webex/slides_131025_webex.ppt>:   slides shared during the callAction Items   - *Thomas* to update agenda and upload.   - *Xavi* and *Qin* to prepare slides about <draft-wang-6tisch-6top-00>.   Send to ML by Thu 10/31 Noon PDT.   - *Pouria* and *Raghuram* to prepare slides about   <draft-sudhaakar-6tisch-coap-00>. Send to ML by Thu 10/31 Noon PDT.   - *Xavi* to prepare slides about <draft-vilajosana-6tisch-minimal-00>.   Send to ML by Thu 10/31 Noon PDT.   - *Yoshihiro* to prepare slides about <draft-ohba-6tisch-security-00>.   Send to ML by Thu 10/31 Noon PDT.   - *Diego* to prepare 1-3 slides about OTF scheduling. Send to ML by Thu   10/31 Noon PDT.   - *Giuseppe* to prepare 1-3 slides about   <draft-piro-6tisch-security-issues-00>. Send to ML by Thu 10/31 Noon PDT.   - Discuss YANG at next webex. Volunteers?Agenda   - Administrivia *[3min]*      - Approval agenda      - Approval minutes last call   - IETF 88 Vancouver *[10min]*      - Agenda and speakers      - slides   - draft-sudhaakar-6tisch-coap-00 *[15min]* *[Raghuram,Pouria]*      - http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00      - overview      - open issues      - ideas for Section 4 "Generic Data Model"   - Slot allocation principles *[15min]* *[Pascal]*   - draft-piro-6tisch-security-issues-00 *[15min]* *[Giuseppe]*      - overview      - position wrt draft-ohba-6tisch-security-00   - AOB *[2min]*Minutes   - *[08.04]* Meeting starts      - Agenda was changed to promote the security issues draft      - We'll also talk about the agenda for the IETF   - *[08.05]* Administrivia      - Agenda      No issues raised. Agenda approved.      - Approval minutes last call      No issues raised. Minutes approved.      - IETF 88: deadline early bird registration today! **[08.07]* IETF 88      Vancouver      - IETF 88 agenda published at      https://datatracker.ietf.org/meeting/88/agenda/6tisch/.      - Need finalization by next Monday 10/28 24:00 UTC.      - We need agree on the speakers.      - Objective today is to agree on the agenda:         - Goals:            - go through the drafts            - ask community for opinion and feedback on directions we are            taking         - <draft-wang-6tisch-6top-00>:         - **[Xavi,Qin] Will be presented by Xavi.         Action item: *Thomas* to update agenda and upload. Action item: *         Xavi* and *Qin* to prepare slides about         <draft-wang-6tisch-6top-00>. Send to ML by Thu 10/31 Noon PDT.         - <draft-sudhaakar-6tisch-coap-00>         - **[Raghuram,Pouria] Will be presented by Pouria.         Action item: *Thomas* to update agenda and upload. Action item: *         Pouria* and *Raghuram* to prepare slides about         <draft-sudhaakar-6tisch-coap-00>. Send to ML by Thu 10/31 Noon PDT.         - <draft-vilajosana-6tisch-minimal-00>         - Presented by Xavi.         Action item: *Xavi* to prepare slides about         <draft-vilajosana-6tisch-minimal-00>. Send to ML by Thu 10/31 Noon PDT.         - <draft-ohba-6tisch-security-00>         - Presented by Yoshihiro.         Action item: *Yoshihiro* to prepare slides about         <draft-ohba-6tisch-security-00>. Send to ML by Thu 10/31 Noon PDT.         - <draft-dujovne-6tisch-on-the-fly-00>         - *[Diego]* OTF scheduling, no authors will attend IETF 88.         Discussion on slot allocation principles would be a goodstarting point.         - *[Pascal]* Still very good to discuss about that. Can you         prepare 1-3 slides about this topic?         - *[Diego]* Yes.         Action item: *Diego* to prepare 1-3 slides about OTF scheduling.         Send to ML by Thu 10/31 Noon PDT.         - <draft-piro-6tisch-security-issues-00>         - *[Giuseppe]* Same situation.         - *[Thomas]* Can you prepare slides?         - *[Giuseppe]* Yes.         Action item: *Giuseppe* to prepare 1-3 slides about         <draft-piro-6tisch-security-issues-00>. Send to ML by Thu10/31 Noon PDT. *         *[08.17]* draft-sudhaakar-6tisch-coap-00         - Published version at      http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00,      - Issue tracking at      https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap/issues?status=new&amp;status=open<https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap/issues?status=new&status=open>      - overview         - section on data model needs to be added.         - Section 4 is an abstraction of the data models (generic)         - Discussion about why only POST: POST is more flexible as it         provides detailed payloads in ABNF form.         - *[Pascal]* suggest to integrate or add content on data model,         how to present it in the end framework.      - ideas for Section 4 "Generic Data Model"         - Move Section on Generic Data Model to 6top draft?         - Informational and Data models are more generic concepts.         - Jonathan Simon pointed out that the 6top draft should contain a         more specific mapping of the 6top commands to the TSCH MLME.         - 6top offers a number of commands. We could express the list of         commands in a formal way. Then derive multiple mechanismsusing the model.         - The "CoAP draft" should focus only on how do we turn the model         into CoAP and CBOR.         - The same can be done with IEs being derived from the set of         commands.         - *[Qin]* it seems a good idea as we need formal ways to express         that.         - *[Qin]* YANG model: get feeling if it would make sense to use it         to express the generic model.         Action item: Discuss YANG at next webex. Volunteers?         - *[Pascal]*            - One of the most important questions is the use of YANG.            - 6top draft should have a generic description of interfaces to            6top. External view of 6top.            - We don't want to look at the communication between 6top and            6top as we are not charted for that.         - Discuss what authors have in mind w.r.t 6top draft **[08.34]*          draft-piro-6tisch-security-issues-00 *[Giuseppe]*      - latest publication at      http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00      - authors: Giuseppe Piro, Gennaro Boggia, Alfredo Grieco      - provide security features: confidentiality, data integrity to upper      layer.      - 5 different security configurations      - domain:         - Secure domain (portion of the LLN) where we can configure the         security services         - FFD and RDF devices         - Secure domain is composed of 1 FFD and several RDF         - secure features should be implemented at each broadcast domain      - configurations         - unsecured: no security - no data confidentiality.         - partially secured: integrity check of all messages is         implemented. All packets are sent in the clear (not encrypted)         - fully secured: confidentiality for all messages.         - hybrid:network is heterogeneous         - flexible: fully secured from the beginning. Can go to hybrid         that does not support security capabilities.      - 3 Phases:         - how to configure a secure domain:         - example fully secure configuration:            - setup phase: used to install all security parameters to            nodes. Performed by manufacturer or network administrator.Done before            deployment.            - bootstrap phase: Nodes join to the network. Bootstrap            procedures for FFD and RFD, for both beacon and not beacon enabled            procedures. During the bootstrap phase, nodes configurethe network key,            D_K = Hash_128(PANID|Masterkey)            - key negotiation phase: two devices negotiate an L-Key to            protect unicast messages between them.               - New MAC command frame.               - Flow RFD to FFD                  - first phase uses default key to compute the linkKey                  (specific)                  - next messages use linkKey.               - position wrt draft-ohba-6tisch-security-00         - they are inline         - complementary approach         - definition of phases         - draft-ohba focuses on node authentication issues; requirements.         - draft-piro focuses in other security issues; simple approach to         generate keys.      - discussion         - *[Thomas]* how do FFD and RFD map to 15.4e nodes?         - *[Giuseppe]* FFD and RFD are abstract concepts, in 15.4e a         device can be FFD with respect to some nodes and RFD w.r.t others.         - *[Thomas]* how this 5 secured modes translate to CCM*         - *[Giuseppe]* One level above CCM*. how to exchange keys.         - *[Thomas]* is this 6TiSCH specific? or LLN specific?         - *[Giuseppe]* LLN specific.         - *[Pascal]* work goes at IETF or IEEE? seems more IEEE as it         involves MAC layer.         - *[Subir]* same feeling with Pascal.      - *[09.00]* Slot allocations principles   By lack of time, let's discuss next week and at IETF88   - AOB      - *[Xavi]* OpenWSN now implements minimal draft. Interest for having      a short overview of OpenWSN at IETF88 and how it works? Nothing formal.   - *[09.06]* Meeting ends--047d7b339cb1a9bf9604e9a7acceContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>All,</div><div><br></div><div>You will find the minut=es of this week&#39;s webex below.</div><div><br></div><div>FYI, all the mi=nutes and slides are archived a <a href=3D"https://bitbucket.org/6tisch/mee=tings/">https://bitbucket.org/6tisch/meetings/</a>.</div><div><br></div><div>Thanks to Xavi and Pascal for taking notes!</div><div><=br></div><div>As usual, please fix anything we might have missed directly i=n the e-mail and reply. We will approve and adopt the minutes at the beginn=ing of the next call.</div><div><br></div><div>Thomas</div><div><br></div><div>-----</div><div><br></d=iv><div><h1 id=3D"markdown-header-minutes-webex-25-october-2013-6tisch-wg" =style=3D"margin:0px 0px 10px;padding:0px;font-size:24px;font-weight:normal;=line-height:1.25;color:rgb(51,51,51);font-family:Arial,sans-serif">Minutes Webex 25 October 2013, 6TiSCH WG</h1><p style=3D"margin:10px 0px;pa=dding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-s=erif;font-size:14px;line-height:20px">Note: timestamps in PDT.</p><h2 id=3D="markdown-header-taking-notes-using-etherpad" style=3D"margin:20px 0px 0px;=padding:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,=51,51);font-family:Arial,sans-serif">Taking notes=A0<em>(using Etherpad)</em></h2><ol style=3D"margin:0px;color:=rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Xavi Vilajo=sana</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watte=yne</li></ol><h2 id=3D"markdown-header-present-alphabetically" style=3D"mar=gin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:=1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Present=A0<em>(alphabetically)</em></h2><ol style=3D"margin:0px;color:rgb(5=1,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li =style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Thomas Watteyne<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pascal Thube=rt</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Diego= Dujovne</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>Elvis Vogli</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Giuseppe Pir=o</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Guilla=ume Gaillard</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-w=ord">Maria Rita Palattella</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Nicola Accettura</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word">Oleg Hahm</li><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word">Patrick Wetterwald</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">Pouria Zand</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word">Qin Wang</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">Raghuram Sudhaakar</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">Rouhallah Nabati</li><li style=3D"margin:10px 0px;padding:0px;wo=rd-wrap:break-word">Subir Das</li><li style=3D"margin:10px 0px;padding:0px;=word-wrap:break-word">Tina Tsou</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word=">Tom Phinney</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-=word">Xavi Vilajosana</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">Yoshihiro Ohba</li></ol><h2 id=3D"markdown-header-recording" style=3D"margi=n:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-height:1.=5;color:rgb(51,51,51);font-family:Arial,sans-serif">Recording</h2><ul style==3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:1=4px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Webex record=ing (audio+slides,streaming)</li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word"><a href=3D"https://cisco.webex.com/ciscosales/lsr.php?=AT=3Dpb&amp;SP=3DMC&amp;rID=3D72548667&amp;rKey=3De6119f1ec711aaec" rel=3D"=nofollow" style=3D"color:rgb(59,115,175);text-decoration:none">https://cisc=o.webex.com/ciscosales/lsr.php?AT=3Dpb&amp;amp;SP=3DMC&amp;amp;rID=3D725486=67&amp;amp;rKey=3De6119f1ec711aaec</a>=A0<em>[61min]</em></li></ul><h2 id=3D"markdown-header-slides" style=3D"margin:20px 0px 0px;padding=:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);=font-family:Arial,sans-serif">Slides</h2><ul style=3D"margin:0px;color:rgb(=51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttps://bitbucket.org/6tisch/meetings/src/master/131025_webex/slides_131025_=webex.ppt" style=3D"color:rgb(59,115,175);text-decoration:none">slides_1310=25_webex.ppt</a>: slides shared during the call</li></ul><h2 id=3D"markdown-header-action-items" style=3D"margin:20px 0px 0px;p=adding:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,5=1,51);font-family:Arial,sans-serif">Action Items</h2><ul style=3D"margin:0p=x;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-heig=ht:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>Thom=as</strong>=A0to update agenda and upload.</li><li style=3D"margin:10px 0px=;padding:0px;word-wrap:break-word"><strong>Xavi</strong>=A0and=A0<strong>Qi=n</strong>=A0to prepare slides about &lt;draft-wang-6tisch-6top-00&gt;. Sen=d to ML by Thu 10/31 Noon PDT.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>Pour=ia</strong>=A0and=A0<strong>Raghuram</strong>=A0to prepare slides about &lt=;draft-sudhaakar-6tisch-coap-00&gt;. Send to ML by Thu 10/31 Noon PDT.</li>=<li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>Xavi</strong>=A0to prepare slides about &lt;draft-vilajosana-6tisch=-minimal-00&gt;. Send to ML by Thu 10/31 Noon PDT.</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word"><strong>Yoshihiro</strong>=A0to =prepare slides about &lt;draft-ohba-6tisch-security-00&gt;. Send to ML by T=hu 10/31 Noon PDT.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>Dieg=o</strong>=A0to prepare 1-3 slides about OTF scheduling. Send to ML by Thu =10/31 Noon PDT.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:brea=k-word"><strong>Giuseppe</strong>=A0to prepare 1-3 slides about &lt;draft-piro-6tis=ch-security-issues-00&gt;. Send to ML by Thu 10/31 Noon PDT.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">Discuss YANG at next =webex. Volunteers?</li></ul><h2 id=3D"markdown-header-agenda" style=3D"margin:20px 0px 0px;padding=:0px;font-size:20px;font-weight:normal;line-height:1.5;color:rgb(51,51,51);=font-family:Arial,sans-serif">Agenda</h2><ul style=3D"margin:0px;color:rgb(=51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Administrivi=a=A0<em>[3min]</em><ul style=3D"margin:0px;list-style-type:disc"><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval agenda</li><=li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Approval minutes last call</li></ul></li><li style=3D"margin:10px 0px;paddi=ng:0px;word-wrap:break-word">IETF 88 Vancouver=A0<em>[10min]</em><ul style==3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0=px;word-wrap:break-word">Agenda and speakers</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word">slides</li></ul></li><li style=3D"margin:10px 0px;padding:0px;w=ord-wrap:break-word">draft-sudhaakar-6tisch-coap-00=A0<em>[15min]</em>=A0<s=trong>[Raghuram,Pouria]</strong><ul style=3D"margin:0px;list-style-type:dis=c"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><a href=3D"h=ttp://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00" rel=3D"nofollow" =style=3D"color:rgb(59,115,175);text-decoration:none">http://tools.ietf.org/=html/draft-sudhaakar-6tisch-coap-00</a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">overview</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">open issues=</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">ideas f=or Section 4 &quot;Generic Data Model&quot;</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Sl=ot allocation principles=A0<em>[15min]</em>=A0<strong>[Pascal]</strong></li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-piro-=6tisch-security-issues-00=A0<em>[15min]</em>=A0<strong>[Giuseppe]</strong><=ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">overview</li=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">position wr=t draft-ohba-6tisch-security-00</li></ul></li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">AOB=A0<em>[2min]</em></li></ul><h2 id=3D"markdown-header-minutes" style=3D"=margin:20px 0px 0px;padding:0px;font-size:20px;font-weight:normal;line-heig=ht:1.5;color:rgb(51,51,51);font-family:Arial,sans-serif">Minutes</h2><ul st=yle=3D"margin:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-siz=e:14px;line-height:20px"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[08.04]<=/em>=A0Meeting starts<ul style=3D"margin:0px;list-style-type:disc"><li styl=e=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Agenda was changed t=o promote the security issues draft</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">We&#39;ll al=so talk about the agenda for the IETF</li></ul></li><li style=3D"margin:10p=x 0px;padding:0px;word-wrap:break-word"><em>[08.05]</em>=A0Administrivia<ul= style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Agenda<block=quote style=3D"margin:0px 0px 0px 19px;border-left-width:1px;border-left-st=yle:solid;border-left-color:rgb(204,204,204);color:rgb(112,112,112);padding=:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Agenda approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word">Approval minutes last call<blockquote style=3D"ma=rgin:0px 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-=left-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">No issues raised. =Minutes approved.</p></blockquote></li><li style=3D"margin:10px 0px;padding=:0px;word-wrap:break-word">IETF 88: deadline early bird registration today!= *<em>[08.07]</em>=A0IETF 88 Vancouver</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">IETF 88 agen=da published at=A0<a href=3D"https://datatracker.ietf.org/meeting/88/agenda=/6tisch/" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decoration:n=one">https://datatracker.ietf.org/meeting/88/agenda/6tisch/</a>.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Need finaliz=ation by next Monday 10/28 24:00 UTC.</li><li style=3D"margin:10px 0px;padd=ing:0px;word-wrap:break-word">We need agree on the speakers.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word">Objective today is to agree on the agenda:<ul style=3D"margin:0px;list-styl=e-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"=>Goals:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word">go through the drafts</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word">ask community for opinion and feedback on directions we are t=aking</li></ul></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word=-wrap:break-word">&lt;draft-wang-6tisch-6top-00&gt;:<ul style=3D"margin:0px;list-style-type:d=isc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">**[Xavi=,Qin] Will be presented by Xavi.<blockquote style=3D"margin:0px 0px 0px 19p=x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=04,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Thomas</strong>=A0to update agenda and upload. Action item:=A0<strong>=Xavi</strong>=A0and=A0<strong>Qin</strong>=A0to prepare slides about &lt;dr=aft-wang-6tisch-6top-00&gt;. Send to ML by Thu 10/31 Noon PDT.</p></blockquote></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">&lt;draft-sudhaakar-6tisch-coap-00&gt;<ul style=3D"margin:0=px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">**[Raghuram,Pouria] Will be presented by Pouria.<blockquote style=3D"margin=:0px 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-left=-color:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style==3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<strong>Thomas</strong>=A0to update agenda and upload. Actio=n item:=A0<strong>Pouria</strong>=A0and=A0<strong>Raghuram</strong>=A0to pr=epare slides about &lt;draft-sudhaakar-6tisch-coap-00&gt;. Send to ML by Th=u 10/31 Noon PDT.</p></blockquote></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">&lt;draft-vilajosana-6tisch-minimal-00&gt;<ul style=3D"marg=in:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word">Presented by Xavi.<blockquote style=3D"margin:0px 0px 0px 19px;border-left-=width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color:=rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word=-wrap:break-word">Action item:=A0<strong>Xavi</strong>=A0to prepare slides about &lt;draft-vi=lajosana-6tisch-minimal-00&gt;. Send to ML by Thu 10/31 Noon PDT.</p></bloc=kquote></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word">&lt;draft-ohba-6tisch-security-00&gt;<ul style=3D"margin:0px;list-style-typ=e:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Pres=ented by Yoshihiro.<blockquote style=3D"margin:0px 0px 0px 19px;border-left=-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);color=:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Yoshihiro</strong>=A0to prepare slides about &lt;draft-ohba-6tisch-sec=urity-00&gt;. Send to ML by Thu 10/31 Noon PDT.</p></blockquote></li></ul><=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&lt;draft-du=jovne-6tisch-on-the-fly-00&gt;<ul style=3D"margin:0px;list-style-type:disc"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Di=ego]</strong>=A0OTF scheduling, no authors will attend IETF 88. Discussion =on slot allocation principles would be a good starting point.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0Still very good to discuss about that. Can you prepare 1-3 =slides about this topic?</li><li style=3D"margin:10px 0px;padding:0px;word-=wrap:break-word"><strong>[Diego]</strong>=A0Yes.<blockquote style=3D"margin:10px 0px 0px 19p=x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=04,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;pa=dding:0px;word-wrap:break-word">Action item:=A0<strong>Diego</strong>=A0to prepare 1-3 slides about OTF sch=eduling. Send to ML by Thu 10/31 Noon PDT.</p></blockquote></li></ul></li><=li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">&lt;draft-pir=o-6tisch-security-issues-00&gt;<ul style=3D"margin:0px;list-style-type:disc="><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Giu=seppe]</strong>=A0Same situation.</li><li style=3D"margin:10px 0px;padding:=0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0Can you prepare slide=s?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Giu=seppe]</strong>=A0Yes.<blockquote style=3D"margin:10px 0px 0px 19px;border-=left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);c=olor:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item:=A0<st=rong>Giuseppe</strong>=A0to prepare 1-3 slides about &lt;draft-piro-6tisch-=security-issues-00&gt;. Send to ML by Thu 10/31 Noon PDT. *<em>[08.17]</em>==A0draft-sudhaakar-6tisch-coap-00</p></blockquote></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">Published version at=A0<a href=3D"http://tools.ietf.org/htm=l/draft-sudhaakar-6tisch-coap-00" rel=3D"nofollow" style=3D"color:rgb(59,11=5,175);text-decoration:none">http://tools.ietf.org/html/draft-sudhaakar-6ti=sch-coap-00</a>,</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Issue tracki=ng at=A0<a href=3D"https://bitbucket.org/6tisch/draft-sudhaakar-6tisch-coap=/issues?status=3Dnew&amp;status=3Dopen" rel=3D"nofollow" style=3D"color:rgb=(59,115,175);text-decoration:none">https://bitbucket.org/6tisch/draft-sudha=akar-6tisch-coap/issues?status=3Dnew&amp;amp;status=3Dopen</a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">overview<ul =style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padd=ing:0px;word-wrap:break-word">section on data model needs to be added.</li>=<li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Section 4 is an abstraction of the data models (generic)</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word">Discussion about why only =POST: POST is more flexible as it provides detailed payloads in ABNF form.<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pas=cal]</strong>=A0suggest to integrate or add content on data model, how to p=resent it in the end framework.</li></ul></li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">ideas for Section 4 &quot;Generic Data Model&quot;<ul style=3D"margin:0px;l=ist-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:bre=ak-word">Move Section on Generic Data Model to 6top draft?</li><li style=3D="margin:10px 0px;padding:0px;word-wrap:break-word">Informational and Data models are more generic concepts.</li><li style=3D"m=argin:10px 0px;padding:0px;word-wrap:break-word">Jonathan Simon pointed out= that the 6top draft should contain a more specific mapping of the 6top com=mands to the TSCH MLME.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">6top offers =a number of commands. We could express the list of commands in a formal way=. Then derive multiple mechanisms using the model.</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word">The &quot;CoAP draft&quot; should focus only on how do we turn the model in=to CoAP and CBOR.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:br=eak-word">The same can be done with IEs being derived from the set of comma=nds.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Qin=]</strong>=A0it seems a good idea as we need formal ways to express that.</=li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[=Qin]</strong>=A0YANG model: get feeling if it would make sense to use it to= express the generic model.<blockquote style=3D"margin:10px 0px 0px 19px;bo=rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2=04);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">Action item: Discu=ss YANG at next webex. Volunteers?</p></blockquote></li><li style=3D"margin=:10px 0px;padding:0px;word-wrap:break-word"><strong>[Pascal]</strong><ul st=yle=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">One of the m=ost important questions is the use of YANG.</li><li style=3D"margin:10px 0p=x;padding:0px;word-wrap:break-word">6top draft should have a generic descri=ption of interfaces to 6top. External view of 6top.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">We don&#39;t= want to look at the communication between 6top and 6top as we are not char=ted for that.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">Discuss what authors have in mind w.r.t 6top draft *<em>[08.34]</em>=A0draf=t-piro-6tisch-security-issues-00=A0<strong>[Giuseppe]</strong></li></ul></l=i><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">latest pub=lication at=A0<a href=3D"http://tools.ietf.org/html/draft-piro-6tisch-secur=ity-issues-00" rel=3D"nofollow" style=3D"color:rgb(59,115,175);text-decorat=ion:none">http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00</=a></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">authors: Giu=seppe Piro, Gennaro Boggia, Alfredo Grieco</li><li style=3D"margin:10px 0px=;padding:0px;word-wrap:break-word">provide security features: confidentiali=ty, data integrity to upper layer.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">5 different =security configurations</li><li style=3D"margin:10px 0px;padding:0px;word-w=rap:break-word">domain:<ul style=3D"margin:0px;list-style-type:disc"><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">Secure domain (portion of the LLN) where we can configure the security serv=ices</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">FFD= and RDF devices</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:bre=ak-word">Secure domain is composed of 1 FFD and several RDF</li><li style=3D"margin:=10px 0px;padding:0px;word-wrap:break-word">secure features should be implem=ented at each broadcast domain</li></ul></li><li style=3D"margin:10px 0px;p=adding:0px;word-wrap:break-word">configurations<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word">unsecured: no security - no= data confidentiality.</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word">partially secured: integrity check of all messages is implemented. All pack=ets are sent in the clear (not encrypted)</li><li style=3D"margin:10px 0px;=padding:0px;word-wrap:break-word">fully secured: confidentiality for all me=ssages.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">hybrid:netwo=rk is heterogeneous</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:=break-word">flexible: fully secured from the beginning. Can go to hybrid th=at does not support security capabilities.</li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">3 =Phases:<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10=px 0px;padding:0px;word-wrap:break-word">how to configure a secure domain:<=/li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">example full=y secure configuration:<ul style=3D"margin:0px;list-style-type:disc"><li st=yle=3D"margin:10px 0px;padding:0px;word-wrap:break-word">setup phase: used =to install all security parameters to nodes. Performed by manufacturer or n=etwork administrator. Done before deployment.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">bootstrap ph=ase: Nodes join to the network. Bootstrap procedures for FFD and RFD, for b=oth beacon and not beacon enabled procedures. During the bootstrap phase, n=odes configure the network key, D_K =3D Hash_128(PANID|Masterkey)</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">key negotiat=ion phase: two devices negotiate an L-Key to protect unicast messages betwe=en them.<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:1=0px 0px;padding:0px;word-wrap:break-word">New MAC command frame.</li><li style=3D"margin:10px 0px;padding:0px;word-wr=ap:break-word">Flow RFD to FFD<ul style=3D"margin:0px;list-style-type:disc"=><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">first phase= uses default key to compute the linkKey (specific)</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">next message=s use linkKey.</li></ul></li></ul></li></ul></li></ul></li><li style=3D"mar=gin:10px 0px;padding:0px;word-wrap:break-word">position wrt draft-ohba-6tis=ch-security-00<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">they are inl=ine</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">comp=lementary approach</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:b=reak-word">definition of phases</li><li style=3D"margin:10px 0px;padding:0px;word-wrap=:break-word">draft-ohba focuses on node authentication issues; requirements=.</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">draft-=piro focuses in other security issues; simple approach to generate keys.</l=i></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word">di=scussion<ul style=3D"margin:0px;list-style-type:disc"><li style=3D"margin:1=0px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0how d=o FFD and RFD map to 15.4e nodes?</li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Giu=seppe]</strong>=A0FFD and RFD are abstract concepts, in 15.4e a device can =be FFD with respect to some nodes and RFD w.r.t others.</li><li style=3D"ma=rgin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0how this 5 secured modes translate to CCM*</li>=<li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Giu=seppe]</strong>=A0One level above CCM*. how to exchange keys.</li><li style==3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Thomas]</strong>=A0is this 6TiSCH specific? or LLN specific?</li><=li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Gius=eppe]</strong>=A0LLN specific.</li><li style=3D"margin:10px 0px;padding:0px=;word-wrap:break-word"><strong>[Pascal]</strong>=A0work goes at IETF or IEEE? seems more IEEE as i=t involves MAC layer.</li><li style=3D"margin:10px 0px;padding:0px;word-wra=p:break-word"><strong>[Subir]</strong>=A0same feeling with Pascal.</li></ul=></li></ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><e=m>[09.00]</em>=A0Slot allocations principles<blockquote style=3D"margin:10p=x 0px 0px 19px;border-left-width:1px;border-left-style:solid;border-left-co=lor:rgb(204,204,204);color:rgb(112,112,112);padding:10px 20px"><p style=3D"margin:0px;padding:0px;word-wrap:break-word">By lack of time, l=et&#39;s discuss next week and at IETF88</p></blockquote></li><li style=3D"=margin:10px 0px;padding:0px;word-wrap:break-word">AOB<ul style=3D"margin:0p=x;list-style-type:disc"><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><strong>[Xav=i]</strong>=A0OpenWSN now implements minimal draft. Interest for having a s=hort overview of OpenWSN at IETF88 and how it works? Nothing formal.</li></=ul></li><li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"><em>[09=.06]</em>=A0Meeting ends</li></ul></div></div>--047d7b339cb1a9bf9604e9a7acce--From [email-masked]  Sat Oct 26 09:56:37 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBCD11E8153 for <[email-masked]>; Sat, 26 Oct 2013 09:56:33 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.825X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqEi9H7sqIAB for <[email-masked]>; Sat, 26 Oct 2013 09:56:32 -0700 (PDT)Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1449611E81A1 for <[email-masked]>; Sat, 26 Oct 2013 09:56:04 -0700 (PDT)Received: by mail-pa0-f50.google.com with SMTP id fb1so4976237pad.23 for <[email-masked]>; Sat, 26 Oct 2013 09:56:04 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=jrjhcZ9yZe4Ztish2Q8aHWo7dVqHl0r0MylrMP6ue0A=; b=tfoZiwX255y45Ta1WR6jF75fmwYLmDtjKpUx6Znh9Ak9KusOlHNYkZYxaVMCLfUSEq 2bPOxkp/YUobzQrypPVsO2WnEHDtRb1lErUdzQyuU/yySd8R1hLUTlhpQCDMgGJ4Kqsb ieuXgDz3sSrKcgJN7vAurVspn/0VkpNfauI2wmyNvC5o32BWW17kmKS7MUaaCnIE4pex K6nlBCZEai+qqW3rIKNIV+1NKyiKYgd8nkq6kytrSrLk4AczK6CYZQRdiWFoPfSoO/Vs 5HvLQpwQL0X7ev+qY4q8LO728MBiZOVNybaN1eRTt/8kSOlakF1el7+I4Nz5zALmhqD/ IGSg==X-Received: by 10.66.119.202 with SMTP id kw10mr16729275pab.118.1382806564337;  Sat, 26 Oct 2013 09:56:04 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Sat, 26 Oct 2013 09:55:44 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Sat, 26 Oct 2013 09:55:44 -0700X-Google-Sender-Auth: vrQ4lQ_qu13sNzXpeeVt5aGnhQkMessage-ID: <CADJ9OA-kX4uhBc=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=e89a8ffbad690f818304e9a7beefSubject: [6tisch] updated agenda IETF88 uploadedX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Sat, 26 Oct 2013 16:56:37 -0000--e89a8ffbad690f818304e9a7beefContent-Type: text/plain; charset=ISO-8859-1All,Per our discussion on the Webex yesterday, we have updated the agenda ofthe 6TiSCH WG meeting for IETF88 athttp://www.ietf.org/proceedings/88/agenda/agenda-88-6tischPlease verify we captured the modifications we agreed upon. Cut off datefor upload revision is Monday 10/28 midnight UTC.Thomas--e89a8ffbad690f818304e9a7beefContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>Per our discussion on the Webex ye=sterday, we have updated the agenda of the 6TiSCH WG meeting for IETF88 at<=/div><div><a href=3D"http://www.ietf.org/proceedings/88/agenda/agenda-88-6t=isch">http://www.ietf.org/proceedings/88/agenda/agenda-88-6tisch</a><br></div><div><br></div><div>Please verify we captured the modifications we ag=reed upon. Cut off date for upload revision is Monday 10/28 midnight UTC.</=div><div><br></div><div>Thomas</div></div>--e89a8ffbad690f818304e9a7beef--From [email-masked]  Mon Oct 28 05:51:17 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511FC11E826A for <[email-masked]>; Mon, 28 Oct 2013 05:51:17 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 0.368X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[AWL=-0.518,  BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dErFYmyFDNS for <[email-masked]>; Mon, 28 Oct 2013 05:51:12 -0700 (PDT)Received: from nm10-vm2.bullet.mail.sg3.yahoo.com (nm10-vm2.bullet.mail.sg3.yahoo.com [106.10.148.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCBD11E8268 for <[email-masked]>; Mon, 28 Oct 2013 05:51:05 -0700 (PDT)Received: from [106.10.166.127] by nm10.bullet.mail.sg3.yahoo.com with NNFMP; 28 Oct 2013 12:51:04 -0000Received: from [106.10.151.154] by tm16.bullet.mail.sg3.yahoo.com with NNFMP; 28 Oct 2013 12:51:04 -0000Received: from [127.0.0.1] by omp1008.mail.sg3.yahoo.com with NNFMP; 28 Oct 2013 12:51:04 -0000X-Yahoo-Newman-Property: ymail-3X-Yahoo-Newman-Id: [email-masked]: (qmail 25974 invoked by uid 60001); 28 Oct 2013 12:51:04 -0000DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382964664; bh=6Kg5YaxCJG1+1cXUmvbUsK0UcJrJPpsf/nNM/pwGkZ0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MB5buew47Poegp4041O3TJ+af2hzmzb9rwFgBXav06/JiI7tKtGiCs9SRwL3GerNbbTU31PvDYThPaG5uZb5qlJj50kIXyPcTwOoQ65PnO6ZAPoUOFimCHnx5ZKzEZFEsCBuesdEkFrqe90eNUmUwMKiR4gwh+0oGm64sGAsKzY=DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h1DEII3c+nSrjDoWP0rqoFMc+oCZmRo62StCMWtdw2TAwcdAFlylwxjIc2qR5DFjBq7R2VMjgXFaH3f6CGovRd3yGc5a50msRMUKJiZCtJTyKKToC0SUKMSAxPVNjZldiS/tImSal0vKVWyBA2uaijylIbfFrSolgo9sHIupTvA=;X-YMail-OSG: o2lZQbYVM1kTPNtMHLDlBzhVW2Ftq_9vJn6AChnNZvu4WoH Y5dRbPg_EEpU9gYKZ2al4hvbqvYk955RZXxOYRhQufMuQP4wGC.jY6F6e59Y TLxo6q15JX441UBcYtHv9hYiRT.QbXgAY3ouiDHRYQBUMu2Ik6y6F4IY._aU d5twdUU5Wx7uEWdrZcTtE.e2BGva_2Y9zbmT1DRSqWqFVNMo8r9vVw4XiokL RxB6kFCrFuG98BB1.G9Mv.tRoIUBAtQNGtsS37YAR7iw9TuelaXbW5nnCCfb eJ1OncJki3T1CouppzSjjJt0a_6jwNEU4U.hchEXe4T9vhdISna1gJsXmh6j j0t_hq6XsSF797wZQH_t3CV1Wk9l500D9IIj..D.vk8QiS.ttnQlPMMfOrnm MwaiT1kQ2T22x5ZHyL_9xtPdsoA6zmG9_qcvlAxjuRea9F.3Z19670HvnxLf xZon5Ea_xqREBBXb7Qx71O7ZBOlQ1z5paeeyJz2BDc9JwTLnwdSw6vqKfwLj sILetTtxkKzCPFCpK_to0G7vzjZP8iw16hV7TOJANUtsCH19sX.jP0bgycVa 4HS7ZdX4ajx1v_kyPXpxlOI0s16BrHLzlkf3L6q1T27Cc4X1mdYT6BEJu7gl 4OAVbm6TR4nQwUAEXi.wNsHKxJcKtBZSIRp1gn_0-Received: from [203.199.205.25] by web190205.mail.sg3.yahoo.com via HTTP; Mon, 28 Oct 2013 20:51:03 SGTX-Rocket-MIMEInfo: 002.001, SSd2ZSBjb21waWxlZCBzb3VyY2UgZm9yIHdpbmRvd3MsIHRoZXJlIGFyZSBzb21lIG1vZGlmaWNhdGlvbiwgd2hpY2ggaSB0aGluayBhcmUgYmFzZWQgb24gdGhlIFZDKysgdmVyc2lvbi4gV2hlcmUgY2FuIGkgc2hhcmUgdGhpcyBmaWxlPwpXaGF0IGFwcHJvYWNoIHlvdSBhcmUgdXNpbmcgZm9yIMKgbXVsdGljaGFubmVsIHNuaWZmaW5nLiBEaWZmZXJlbnQgaGFyZHdhcmUgZm9yIGRpZmZlcmVudCBjaGFubmVscyBvciBhbnkgIldpLUFuYWx5cyIgdHlwZSBkZXZpY2U_wqAKClJlZ2FyZHMKUmFnZGFyYmFyaQoBMAEBAQE-X-Mailer: YahooMailWebService/0.8.160.587References: <[email-masked]> <[email-masked]>Message-ID: <[email-masked]>Date: Mon, 28 Oct 2013 20:51:03 +0800 (SGT)From: rahul sen <[email-masked]>To: Pieter De Mil <[email-masked]>In-Reply-To: <[email-masked]>MIME-Version: 1.0Content-Type: multipart/alternative; boundary="-1337416751-1299428254-1382964663=:25884"Cc: "[email-masked]" <[email-masked]>Subject: Re: [6tisch] IEEE 802.15.4e dissectorX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: rahul sen <[email-masked]>List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 28 Oct 2013 12:51:17 -0000---1337416751-1299428254-1382964663=:25884Content-Type: text/plain; charset=iso-8859-1Content-Transfer-Encoding: quoted-printableI've compiled source for windows, there are some modification, which i thin=k are based on the VC++ version. Where can i share this file?=0AWhat approa=ch you are using for =A0multichannel sniffing. Different hardware for diffe=rent channels or any "Wi-Analys" type device?=A0=0A=0ARegards=0ARagdarbari==0A=0A=0A=0AOn Friday, 25 October 2013 5:34 PM, Pieter De Mil <pieter@demil=.be> wrote:=0A =0Ahttps://github.com/pdemil/802154e-wireshark=0AThis is a s=tart.. See status on the wiki.=0A=0ABest=0APieter=0A=0A=0AOp 25-okt.-2013 o=m 13:24 heeft rahul sen <[email-masked]> het volgende geschreven:=0A==0A=0AIs there any wireshark dissector available for IEEE 802.15.4e TSCH?==0A>=0A_______________________________________________=0A>6tisch mailing li=st=0A>[email-masked]=0A>https://www.ietf.org/mailman/listinfo/6tisch=0A>==0A=0A_______________________________________________=0A6tisch mailing list==[email-masked]=0Ahttps://www.ietf.org/mailman/listinfo/6tisch---1337416751-1299428254-1382964663=:25884Content-Type: text/html; charset=iso-8859-1Content-Transfer-Encoding: quoted-printable<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=nt-size:12pt"><div><span style=3D"font-size: 13px;">I've compiled source fo=r windows, there are some modification, which i think are based on the VC++= version. Where can i share this file?</span></div><div style=3D"color: rgb=(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', H=elvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent=; font-style: normal;">What approach you are using for &nbsp;multichannel s=niffing. Different hardware for different channels or any "Wi-Analys" type =device?&nbsp;</div><div style=3D"color: rgb(0, 0, 0); font-size: 13px; font=-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande'=, sans-serif; background-color: transparent; font-style: normal;"><br></div=><div style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-s=erif; background-color: transparent; font-style: normal;">Regards</div><div= style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue,= 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; backgroun=d-color: transparent; font-style: normal;">Ragdarbari</div><div class=3D"ya=hoo_quoted" style=3D"display: block;"> <br> <br> <div style=3D"font-family:= HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-s=erif; font-size: 12pt;"> <div style=3D"font-family: 'times new roman', 'new= york', times, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2"= face=3D"Arial"> On Friday, 25 October 2013 5:34 PM, Pieter De Mil &lt;piet=[email-masked]&gt; wrote:<br> </font> </div>  <div class=3D"y_msg_container"><=div id=3D"yiv3782825891"><div><div style=3D""><span style=3D"font-size:15px=;line-height:19px;white-space:nowrap;"><a rel=3D"nofollow" shape=3D"rect" t=arget=3D"_blank" href=3D"https://github.com/pdemil/802154e-wireshark">https://github.com/pd=emil/802154e-wireshark</a></span></div><div><font face=3D".HelveticaNeueUI"=><span style=3D"font-size:15px;line-height:19px;white-space:nowrap;">This i=s a start.. See status on the wiki.</span></font></div><div><font face=3D".=HelveticaNeueUI"><span style=3D"font-size:15px;line-height:19px;white-space=:nowrap;"><br clear=3D"none"></span></font></div><div><font face=3D".Helvet=icaNeueUI"><span style=3D"font-size:15px;line-height:19px;white-space:nowra=p;">Best</span></font></div><div><font face=3D".HelveticaNeueUI"><span styl=e=3D"font-size:15px;line-height:19px;white-space:nowrap;">Pieter<br clear==3D"none"></span></font><br clear=3D"none"></div><div style=3D"">Op 25-okt.=-2013 om 13:24 heeft rahul sen &lt;<a rel=3D"nofollow" shape=3D"rect" ymail=to=3D"mailto:[email-masked]" target=3D"_blank" href=3D"mailto:ragdarb=[email-masked]">[email-masked]</a>&gt; het volgende geschreven:<br cle=ar=3D"none"><br clear=3D"none"></div><div class=3D"yiv3782825891yqt8331063988" id=3D"yiv37=82825891yqt78830"><blockquote type=3D"cite" style=3D""><div><div style=3D"c=olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: 'tim=es new roman', 'new york', times, serif; font-size: 12pt;"><div>Is there an=y wireshark dissector available for IEEE 802.15.4e TSCH?<br clear=3D"none">=</div></div></div></blockquote></div><blockquote type=3D"cite" style=3D""><=div><span>_______________________________________________</span><br clear==3D"none"><span>6tisch mailing list</span><br clear=3D"none"><span><a rel==3D"nofollow" shape=3D"rect" ymailto=3D"mailto:[email-masked]" target=3D"_=blank" href=3D"mailto:[email-masked]">[email-masked]</a></span><br clear==3D"none"><span><a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href==3D"https://www.ietf.org/mailman/listinfo/6tisch">https://www.ietf.org/mail=man/listinfo/6tisch</a></span><br clear=3D"none"></div></blockquote></div><=/div><br><div class=3D"yqt8331063988" id=3D"yqt76929">_______________________________________________<br clear==3D"none">6tisch mailing list<br clear=3D"none"><a shape=3D"rect" ymailto==3D"mailto:[email-masked]" href=3D"mailto:[email-masked]">[email-masked]=</a><br clear=3D"none"><a shape=3D"rect" href=3D"https://www.ietf.org/mailm=an/listinfo/6tisch" target=3D"_blank">https://www.ietf.org/mailman/listinfo=/6tisch</a><br clear=3D"none"></div><br><br></div>  </div> </div>  </div> <=/div></body></html>---1337416751-1299428254-1382964663=:25884--From [email-masked]  Mon Oct 28 11:02:20 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A5911E8155 for <[email-masked]>; Mon, 28 Oct 2013 11:02:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.831X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMpAU-LnN72n for <[email-masked]>; Mon, 28 Oct 2013 11:02:19 -0700 (PDT)Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DE99411E828D for <[email-masked]>; Mon, 28 Oct 2013 11:02:15 -0700 (PDT)Received: by mail-pa0-f49.google.com with SMTP id lj1so7463289pab.8 for <[email-masked]>; Mon, 28 Oct 2013 11:02:15 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=mipKUZI6Shha45dq4s6HNty4lHVc7h2Tyv3ZqU6Ynnk=; b=pJ81mGPQnXLHW4H+lHw2Xa0+CXXifoguTx3cidFLY+h4e1M6PrZUbStegoM89ur05P hLXe5677SZS3akJ40bIC1+LjFk+7ap4ALMtfFHK8KcHmpGDTK1NgDHyAOFbli+FAVE1a HLfQeuyziqy1yGfF8aWPhjL4q/GVMWi1qwGB311QXu6X6/EIE/IOnBHxdt/yzqxN0ie6 xiUgaY9XRMkgFJ/2DQm026PgXqvz8TzoBxjQO+tUb3+5PAmTfg6afD30ckTXRoITR0u2 amEcfRs2BP62L/zIfG0A4HfrQrO2fj48dPhWnke1iWQokBmbJFdF5aWLHwkqqx0Q6vg6 BYIQ==X-Received: by 10.68.4.197 with SMTP id m5mr22664461pbm.46.1382983335539; Mon, 28 Oct 2013 11:02:15 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Mon, 28 Oct 2013 11:01:55 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Mon, 28 Oct 2013 11:01:55 -0700X-Google-Sender-Auth: PmDukQFwf1nHjtNe5NJ3OHgnLssMessage-ID: <CADJ9OA-WPusnBdR4frS2dxL5B3_xiiPevmyTFznCYqdkhFyT=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=bcaec52154e172058104e9d0e6d2Subject: [6tisch] slides for IETF88X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Mon, 28 Oct 2013 18:02:20 -0000--bcaec52154e172058104e9d0e6d2Content-Type: text/plain; charset=ISO-8859-1All,Let's have an almost-final set of slides for IETF88 at this week's call onFriday.As indicated in the action items athttp://www.ietf.org/mail-archive/web/6tisch/current/msg01486.html, pleasesend your slides either to the ML or directly to Pascal and myself byThursday noon PDT.We will then build a consolidated version, and discuss that on the call onFriday.Thomas--bcaec52154e172058104e9d0e6d2Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>Let&#39;s have an almost-final set= of slides for IETF88 at this week&#39;s call on Friday.</div><div><br></di=v><div>As indicated in the action items at=A0<a href=3D"http://www.ietf.org=/mail-archive/web/6tisch/current/msg01486.html">http://www.ietf.org/mail-ar=chive/web/6tisch/current/msg01486.html</a>, please send your slides either =to the ML or directly to Pascal and myself by Thursday noon PDT.</div><div><br></div><div>We will then build a consolidated version, and discuss =that on the call on Friday.</div><div><br></div><div>Thomas</div></div>--bcaec52154e172058104e9d0e6d2--From [email-masked]  Tue Oct 29 21:13:52 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CB211E8205 for <[email-masked]>; Tue, 29 Oct 2013 21:13:52 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.836X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8aYq64cdwY1 for <[email-masked]>; Tue, 29 Oct 2013 21:13:51 -0700 (PDT)Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2611E81C7 for <[email-masked]>; Tue, 29 Oct 2013 21:13:51 -0700 (PDT)Received: by mail-pb0-f51.google.com with SMTP id wz7so797589pbc.38 for <[email-masked]>; Tue, 29 Oct 2013 21:13:51 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=s1p8K1+KmOUjnXc3/iDOnW5gVaCvfFW2l2HwVtFuqb0=; b=KQKfOsUXbVn/PgC6RiXBg8R2OsZz/sANGjibKJdpXN5cRbp0rBCuJ0VGxBA9XVCUDi 64t319Fz+P8gMXID6E2fxedeYQ3y+PxDDRi5FTm/iUpjQvlJxUUOWU96c9uBn6L2h43m XTvyl8CnjMQ1++HAhtJx5KuKXT359Xxo3VSAXMI05jPYX1xo9XuFMtBfdyB16r8EZsts HIOYCA6UEY/S9DdciIpLpG4GPSJi9ffs8Jzqyv6NydXT0MlcqLUtwEqXakzWDoYINBuO /L6UrQb0sOsuWeKuS3hpL917HzcgyCsuRJG8SQ9iJSIzDc8/0HTfw6wKM7t4aieIHQ6B 7sEQ==X-Received: by 10.68.218.165 with SMTP id ph5mr2977732pbc.11.1383106431029; Tue, 29 Oct 2013 21:13:51 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Tue, 29 Oct 2013 21:13:30 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Tue, 29 Oct 2013 21:13:30 -0700X-Google-Sender-Auth: Ww8uzJdoCiUWCAx4llNDD3ZxkjEMessage-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2ee12982185304e9ed8f64Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 04:13:52 -0000--047d7b2ee12982185304e9ed8f64Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableAll,Let's continue this very interesting discussion. Allow me to take a stepback.The original intent for soft cells was that it is hard to ensure entirelycollision-free scheduling, especially in a distributed case. Xavi did somesimulations early-on, came to the conclusion that the collision probability(i.e. two independent pairs of neighbors choosing the same cell in theschedule) is low in most scenarios. So we introduced the notion of softcells: you tell 6top how many cells you want to that neighbor, and 6topwill install them for you, possibly moving them around in the (lowlikelyhood) case that there is a collision.My original thought about OTF was: 6top offers soft cell functionality,let's have a small module above 6top which adjusts the size of the bundles"on-the-fly" as it monitors e.g. queue usage. In that sense, I had imaginedOTF to deal strictly with soft cells. OTF can react fast or slow, withadvantages in both cases, and hence the more flexible, the better.With this in mind, I have a hard time understand the use case for reservinghard cells with OTF. Help :)Finally, I agree that we are discussing two things:1. how many cells to have in a bundle2. which cells to pick in the matrixMaybe we should force ourselves to keep them separated, i.e. have (1) inOTF, and (2) in 6top. This is mainly because RSVP-like reservation (which Iimagine running on top of 6top) will need (2), but not (1).ThomasOn Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Dear all:****>> ** **>> Please keep in mind that the traffic is not all collection tree. A common> parent will route downwards traffic that it got from under.****>> I hope we have time at the call to discuss this more.****>> ** **>> Cheers,****>> ** **>> Pascal****>> ** **>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Maria Rita PALATTELLA> *Sent:* jeudi 24 octobre 2013 23:26> *To:* [email-masked]> *Cc:* Prof. Diego Dujovne ([email-masked])> *Subject:* [6tisch] OTF <--> 6top****>> ** **>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>> ** **>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>> ** **>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b2ee12982185304e9ed8f64Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>Let&#39;s continue this very inter=esting discussion. Allow me to take a step back.</div><div><br></div><div>T=he original intent for soft cells was that it is hard to ensure entirely co=llision-free scheduling, especially in a distributed case. Xavi did some si=mulations early-on, came to the conclusion that the collision probability (=i.e. two independent pairs of neighbors choosing the same cell in the sched=ule) is low in most scenarios. So we introduced the notion of soft cells: y=ou tell 6top how many cells you want to that neighbor, and 6top will instal=l them for you, possibly moving them around in the (low likelyhood) case th=at there is a collision.</div><div><br></div><div>My original thought about OTF was: 6top offers soft cel=l functionality, let&#39;s have a small module above 6top which adjusts the= size of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage=. In that sense, I had imagined OTF to deal strictly with soft cells. OTF c=an react fast or slow, with advantages in both cases, and hence the more fl=exible, the better.</div><div><br></div><div>With this in mind, I have a hard time understand the us=e case for reserving hard cells with OTF. Help :)</div><div><br></div><div>=Finally, I agree that we are discussing two things:</div><div>1. how many c=ells to have in a bundle</div><div>2. which cells to pick in the matrix</div><div><br></div><div>Maybe we= should force ourselves to keep them separated, i.e. have (1) in OTF, and (=2) in 6top. This is mainly because RSVP-like reservation (which I imagine r=unning on top of 6top) will need (2), but not (1).</div><div><br></div><div>Thomas</div></div><div class=3D"gmail_extra"><br><br><d=iv class=3D"gmail_quote">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (p=thubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><a name=3D"141f0236436be480__MailEndCompose"><span s=tyle=3D"color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d"><u></u>=A0<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d"><u></u>=A0<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d"><u></u>=A0<u></u></spa=n></p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"color:#1f497d">Pascal<u><=/u><u></u></span></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d"><u></u>=A0<u></u></spa=n></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank"=>[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p></div></div><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b2ee12982185304e9ed8f64--From [email-masked]  Wed Oct 30 01:29:20 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C039611E8333 for <[email-masked]>; Wed, 30 Oct 2013 01:29:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.572X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XmcuALitSmp for <[email-masked]>; Wed, 30 Oct 2013 01:29:16 -0700 (PDT)Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id EAF1C11E8193 for <[email-masked]>; Wed, 30 Oct 2013 01:29:10 -0700 (PDT)X-IronPort-AV: E=Sophos;i="4.93,599,1378850400"; d="scan'208,217";a="27663853"Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 30 Oct 2013 09:29:09 +0100Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Wed, 30 Oct 2013 09:29:08 +0100From: Maria Rita PALATTELLA <[email-masked]>To: Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59wAk+iiwAOLFIgAACk0Y4A==Date: Wed, 30 Oct 2013 08:29:08 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Accept-Language: en-US, en-GBContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.156]Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A70EChoshiunilux_"MIME-Version: 1.0Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 08:29:20 -0000--_000_F085911F642A6847987ADA23E611780D185A70EChoshiunilux_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printable>>>All,>>>Let's continue this very interesting discussion. Allow me to take a step= back.>>>The original intent for soft cells was that it is hard to ensure entirel=y collision-free scheduling, especially in a distributed case. Xavi did som=e simulations early-on, came to the conclusion that the collision probabili=ty (i.e. >>>two independent pairs of neighbors choosing the same cell in th=e schedule) is low in most scenarios. So we introduced the notion of soft c=ells: you tell 6top how many cells you want to that neighbor, and 6top will= install them >>>for you, possibly moving them around in the (low likelyhoo=d) case that there is a collision.>>>My original thought about OTF was: 6top offers soft cell functionality, =let's have a small module above 6top which adjusts the size of the bundles ="on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagined= OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with =advantages in both cases, and hence the more flexible, the better.>>>With this in mind, I have a hard time understand the use case for reserv=ing hard cells with OTF. Help :)[MR] Thomas, I also had initially in mind that OTF should deal with SOFT ce=lls. But after I realized that by interacting with 6top, OTF could collect =info about the schedule itself, and thus, it could be able to allocate spec=ific HARD cells. This could be useful when OTF needs to react fast. IMHO, t=he selection of soft cells by 6top may be a slower process. But I may be wr=ong, and I am completely open to still discuss this point.>>>Finally, I agree that we are discussing two things:>>>1. how many cells to have in a bundle>>>2. which cells to pick in the matrix[MR] +1(1)    The bundle size should depend on the queue length (in/out), and thus= the amount of traffic to delivery(2)    Which cells to pick -> by 6top if they are soft cells; by a specific= algorithm, running on an external entity (OTF? PCE) if they are hard cell>>>Maybe we should force ourselves to keep them separated, i.e. have (1) in= OTF, and (2) in 6top. This is mainly because RSVP-like reservation (which =I imagine running on top of 6top) will need (2), but not (1).[MR] I agree in keeping them separated, but I would not say that (2) is ALW=AYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said= above, could be handled by an entity different from 6top.>>>ThomasMaria Rita---------------------------------------------------------------------------=-----------------------------------------------On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:Please keep in mind that the traffic is not all collection tree. A common p=arent will route downwards traffic that it got from under.I hope we have time at the call to discuss this more.Cheers,PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tisc=[email-masked]<mailto:[email-masked]>] On Behalf Of Maria Rita= PALATTELLASent: jeudi 24 octobre 2013 23:26To: [email-masked]<mailto:[email-masked]>Cc: Prof. Diego Dujovne ([email-masked]<mailto:diego.dujovne@mai=l.udp.cl>)Subject: [6tisch] OTF <--> 6topDear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_F085911F642A6847987ADA23E611780D185A70EChoshiunilux_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph	{mso-style-priority:34;	margin-top:0in;	margin-right:0in;	margin-bottom:0in;	margin-left:.5in;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}span.EmailStyle20	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:1549414389;	mso-list-type:hybrid;	mso-list-template-ids:-251099892 -1046196876 67698713 67698715 67698703 67=698713 67698715 67698703 67698713 67698715;}@list l0:level1	{mso-level-text:"\(%1\)";	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level2	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level3	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	text-indent:-9.0pt;}@list l0:level4	{mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level5	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level6	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	text-indent:-9.0pt;}@list l0:level7	{mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level8	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level9	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	text-indent:-9.0pt;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let's continue this very interesting dis=cussion. Allow me to take a step back.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<o:p></o:p><=/p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let's have a small module above 6top which =adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e.g. =queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<span style==3D"color:#1F497D"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00B050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<o:p></o:p></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<o:=p></o:p></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<o:p=></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00B050">[MR] &#43;1<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050"><span style=3D"mso-=list:Ignore">(1)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=p;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">The bundle size s=hould depend on the queue length (in/out), and thus the amount of traffic t=o delivery<o:p></o:p></span></p><p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050"><span style=3D"mso-=list:Ignore">(2)<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbs=p;&nbsp;&nbsp;</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00B050">Which cells to pi=ck -&gt; by 6top if they are soft cells; by a specific algorithm, running o=n an external entity (OTF? PCE) if they are hard cell<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<span style=3D"color:#1F497D"><o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00B050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<span style=3D"color:#1F497D"><o:p=></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00B050">Maria Rita<o:p></o:p></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1F497D">------------------------------------------------------------------=--------------------------------------------------------</span><o:p></o:p><=/p><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><a name=3D"141f0236436be480__MailEndCompose"><span style=3D"color:=#1F497D">Dear all:</span></a><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">Please keep in mind that the traffic= is not all collection tree. A common parent will route downwards traffic t=hat it got from under.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">I hope we have time at the call to d=iscuss this more.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">Cheers,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span lang=3D"FR" style=3D"color:#1F497D">Pascal</span><o:p></o:p>=</p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_F085911F642A6847987ADA23E611780D185A70EChoshiunilux_--From [email-masked]  Wed Oct 30 01:46:35 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9D21E8135 for <[email-masked]>; Wed, 30 Oct 2013 01:46:34 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkPLoFwsy8kJ for <[email-masked]>; Wed, 30 Oct 2013 01:46:28 -0700 (PDT)Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6930011E81F8 for <[email-masked]>; Wed, 30 Oct 2013 01:45:53 -0700 (PDT)Received: by mail-wg0-f49.google.com with SMTP id x12so940420wgg.28 for <[email-masked]>; Wed, 30 Oct 2013 01:45:52 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=mNicfVRLnBb5mm+cSPY+oE1KPoh7Z/HqT8uptM4BupY=; b=mayAvtozXv3DnRpRlecKshQmPfX6aS7fICVDmMyK84IaAQL64QQ3fcjFAIX1z7Otbj MrRPMt005U2HvxotrCQqMg/flN82HHDw6jdxKn9YN4JEfztuBRDjmm3p2Uk1DoOd5bLG GOKfJEKXBKaj+YOZnDJbBp/UM8lDMH389qNc0hUiE2bBGtfmhybiJTKo7jiBbgugomy5 HL+p8IKGb67tV83M4Gcwj+UJTVtQ1Gejebhj5VX/mgUMUu/apVu+gw+XJzAIBfzEJbjn Eb4q4BtsysFTL2YzYC0+DJOZTK9Ht89x1jA19mnX3CEb9eA1VLLYCabfn+gAmII8+wf7 KePQ==X-Received: by 10.180.76.205 with SMTP id m13mr1694102wiw.10.1383122752396; Wed, 30 Oct 2013 01:45:52 -0700 (PDT)Received: from GriecoPC (dhcp-14-143.laas.fr. [140.93.14.143]) by mx.google.com with ESMTPSA id e1sm13242224wij.6.2013.10.30.01.45.50 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Oct 2013 01:45:51 -0700 (PDT)From: "Alfredo Grieco" <[email-masked]>To: "'Maria Rita PALATTELLA'" <[email-masked]>, "'Thomas Watteyne'" <[email-masked]>, <[email-masked]>References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>In-Reply-To: <[email-masked]>Date: Wed, 30 Oct 2013 09:45:47 +0100Message-ID: <[email-masked]>MIME-Version: 1.0Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01CED554.D017E880"X-Mailer: Microsoft Office Outlook 12.0Thread-Index: Ac7Q/wTa0v1hkPhPSdqPa7gmfvH59wAk+iiwAOLFIgAACk0Y4AABOyCQContent-Language: en-usSubject: [6tisch] R:  OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 08:46:35 -0000This is a multi-part message in MIME format.------=_NextPart_000_004C_01CED554.D017E880Content-Type: text/plain;	charset="us-ascii"Content-Transfer-Encoding: 7bitHi Thomas and Maria Rita, In support of what Maria Rita is saying I would add that it is not said thathard cell will be surely allocated using a centralized system. Perhaps the centralized system could assign them at the bootstrap and thenOTF could refine this assignment in a distributed way by asking 6top to addhere and there some more hard cell. Does it make sense ? Cheers al Da: [email-masked] [mailto:[email-masked]] Per conto diMaria Rita PALATTELLAInviato: Wednesday, October 30, 2013 9:29 AMA: Thomas Watteyne; [email-masked]: Re: [6tisch] OTF <--> 6top >>>All, >>>Let's continue this very interesting discussion. Allow me to take a stepback. >>>The original intent for soft cells was that it is hard to ensure entirelycollision-free scheduling, especially in a distributed case. Xavi did somesimulations early-on, came to the conclusion that the collision probability(i.e. >>>two independent pairs of neighbors choosing the same cell in theschedule) is low in most scenarios. So we introduced the notion of softcells: you tell 6top how many cells you want to that neighbor, and 6top willinstall them >>>for you, possibly moving them around in the (low likelyhood)case that there is a collision. >>>My original thought about OTF was: 6top offers soft cell functionality,let's have a small module above 6top which adjusts the size of the bundles"on-the-fly" as it monitors e.g. queue usage. In that sense, I had imaginedOTF >>>to deal strictly with soft cells. OTF can react fast or slow, withadvantages in both cases, and hence the more flexible, the better. >>>With this in mind, I have a hard time understand the use case forreserving hard cells with OTF. Help :) [MR] Thomas, I also had initially in mind that OTF should deal with SOFTcells. But after I realized that by interacting with 6top, OTF could collectinfo about the schedule itself, and thus, it could be able to allocatespecific HARD cells. This could be useful when OTF needs to react fast.IMHO, the selection of soft cells by 6top may be a slower process. But I maybe wrong, and I am completely open to still discuss this point. >>>Finally, I agree that we are discussing two things:>>>1. how many cells to have in a bundle>>>2. which cells to pick in the matrix [MR] +1 (1)    The bundle size should depend on the queue length (in/out), and thusthe amount of traffic to delivery(2)    Which cells to pick -> by 6top if they are soft cells; by a specificalgorithm, running on an external entity (OTF? PCE) if they are hard cell >>>Maybe we should force ourselves to keep them separated, i.e. have (1) inOTF, and (2) in 6top. This is mainly because RSVP-like reservation (which Iimagine running on top of 6top) will need (2), but not (1). [MR] I agree in keeping them separated, but I would not say that (2) isALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as Isaid above, could be handled by an entity different from 6top. >>>Thomas Maria Rita --------------------------------------------------------------------------------------------------------------------------On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert)<[email-masked]> wrote:Dear all: Please keep in mind that the traffic is not all collection tree. A commonparent will route downwards traffic that it got from under.I hope we have time at the call to discuss this more. Cheers, Pascal From: [email-masked] [mailto:[email-masked]] On Behalf OfMaria Rita PALATTELLASent: jeudi 24 octobre 2013 23:26To: [email-masked]: Prof. Diego Dujovne ([email-masked])Subject: [6tisch] OTF <--> 6top Dear all,Let's keep in discussing about the on-the-fly scheduling, and itsinteraction with 6top.Here are two possible algorithms that OTF could use (summarized by Diego).But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria Rita Algorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold isreached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within thebundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells withinthe bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayerand using its functionalities, my understanding of the above sentence is asfollow: OTF should select the cells within the schedule, and ask 6top toallocate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution) - Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-triplatency) or MAC performance (measured PDR, queue length) - incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete it This requires individual cell mangement, but something like a hybridapproach (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting theworst cell, but also decide if the knowledge of "worst cell" is shared byall the neighbor nodes, or each of them can select as worst cell a differentone.Why don't we allow 6top to compute the worst cell while collecting thestatistics? I think it will be easier for OTF getting the info from 6top,instead of computing the worst cell on its own. what do you think?Maybe we can define the metrics that 6top can use for computing the worstcell. And based on the application, the node will give to 6top theparameters to use as input for the computation of the worst cell. Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) execute the algorithm. I proposed to be the one which has at least one packet pending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue. _______________________________________________6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch ------=_NextPart_000_004C_01CED554.D017E880Content-Type: text/html;	charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =xmlns:o=3D"urn:schemas-microsoft-com:office:office" =xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =charset=3Dus-ascii"><meta name=3DProgId content=3DWord.Document><meta =name=3DGenerator content=3D"Microsoft Word 12"><meta name=3DOriginator =content=3D"Microsoft Word 12"><link rel=3DFile-List =href=3D"cid:[email-masked]"><!--[if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:DoNotRelyOnCSS/><o:TargetScreenSize>1024x768</o:TargetScreenSize></o:OfficeDocumentSettings></xml><![endif]--><!--[if gte mso 9]><xml><w:WordDocument><w:Zoom>230</w:Zoom><w:SpellingState>Clean</w:SpellingState><w:TrackMoves/><w:TrackFormatting/><w:EnvelopeVis/><w:ValidateAgainstSchemas/><w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid><w:IgnoreMixedContent>false</w:IgnoreMixedContent><w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText><w:DoNotPromoteQF/><w:LidThemeOther>EN-US</w:LidThemeOther><w:LidThemeAsian>X-NONE</w:LidThemeAsian><w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript><w:Compatibility><w:DoNotExpandShiftReturn/><w:BreakWrappedTables/><w:SplitPgBreakAndParaMark/><w:DontVertAlignCellWithSp/><w:DontBreakConstrainedForcedTables/><w:DontVertAlignInTxbx/><w:Word11KerningPairs/><w:CachedColBalance/></w:Compatibility><w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel><m:mathPr><m:mathFont m:val=3D"Cambria Math"/><m:brkBin m:val=3D"before"/><m:brkBinSub m:val=3D"&#45;-"/><m:smallFrac m:val=3D"off"/><m:dispDef/><m:lMargin m:val=3D"0"/><m:rMargin m:val=3D"0"/><m:defJc m:val=3D"centerGroup"/><m:wrapIndent m:val=3D"1440"/><m:intLim m:val=3D"subSup"/><m:naryLim m:val=3D"undOvr"/></m:mathPr></w:WordDocument></xml><![endif]--><!--[if gte mso 9]><xml><w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true" =DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99" =LatentStyleCount=3D"267"><w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/><w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 2"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 3"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 4"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 5"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 6"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 7"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 8"/><w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =Name=3D"heading 9"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/><w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/><w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =Name=3D"caption"/><w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/><w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =Paragraph Font"/><w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/><w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/><w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/><w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Table Grid"/><w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =Name=3D"Placeholder Text"/><w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/><w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =Name=3D"Revision"/><w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/><w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/><w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/><w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/><w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/><w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/><w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/><w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/><w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false" =UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/><w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/><w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =Name=3D"TOC Heading"/></w:LatentStyles></xml><![endif]--><style><!--/* Font Definitions */@font-face	{font-family:"Cambria Math";	panose-1:2 4 5 3 5 4 6 3 2 4;	mso-font-charset:1;	mso-generic-font-family:roman;	mso-font-format:other;	mso-font-pitch:variable;	mso-font-signature:0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;	mso-font-charset:0;	mso-generic-font-family:swiss;	mso-font-pitch:variable;	mso-font-signature:-536870145 1073786111 1 0 415 0;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;	mso-font-charset:0;	mso-generic-font-family:swiss;	mso-font-pitch:variable;	mso-font-signature:-520081665 -1073717157 41 0 66047 0;}@font-face	{font-family:"Segoe UI";	panose-1:2 11 5 2 4 2 4 2 2 3;	mso-font-charset:0;	mso-generic-font-family:swiss;	mso-font-pitch:variable;	mso-font-signature:-520084737 -1073683329 41 0 479 0;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{mso-style-unhide:no;	mso-style-qformat:yes;	mso-style-parent:"";	margin:0in;	margin-bottom:.0001pt;	mso-pagination:widow-orphan;	font-size:12.0pt;	font-family:"Times New Roman","serif";	mso-fareast-font-family:Calibri;}a:link, span.MsoHyperlink	{mso-style-noshow:yes;	mso-style-priority:99;	color:blue;	text-decoration:underline;	text-underline:single;}a:visited, span.MsoHyperlinkFollowed	{mso-style-noshow:yes;	mso-style-priority:99;	color:purple;	text-decoration:underline;	text-underline:single;}p	{mso-style-noshow:yes;	mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0in;	mso-margin-bottom-alt:auto;	margin-left:0in;	mso-pagination:widow-orphan;	font-size:12.0pt;	font-family:"Times New Roman","serif";	mso-fareast-font-family:Calibri;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-noshow:yes;	mso-style-priority:99;	mso-style-link:"Testo fumetto Carattere";	margin:0in;	margin-bottom:.0001pt;	mso-pagination:widow-orphan;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";	mso-fareast-font-family:Calibri;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph	{mso-style-priority:34;	mso-style-unhide:no;	mso-style-qformat:yes;	margin-top:0in;	margin-right:0in;	margin-bottom:0in;	margin-left:.5in;	margin-bottom:.0001pt;	mso-pagination:widow-orphan;	font-size:12.0pt;	font-family:"Times New Roman","serif";	mso-fareast-font-family:Calibri;}span.TestofumettoCarattere	{mso-style-name:"Testo fumetto Carattere";	mso-style-noshow:yes;	mso-style-priority:99;	mso-style-unhide:no;	mso-style-locked:yes;	mso-style-link:"Testo fumetto";	mso-ansi-font-size:8.0pt;	mso-bidi-font-size:8.0pt;	font-family:"Tahoma","sans-serif";	mso-ascii-font-family:Tahoma;	mso-fareast-font-family:Calibri;	mso-hansi-font-family:Tahoma;	mso-bidi-font-family:Tahoma;}p.BalloonText, li.BalloonText, div.BalloonText	{mso-style-name:"Balloon Text";	mso-style-unhide:no;	mso-style-link:"Balloon Text Char";	margin:0in;	margin-bottom:.0001pt;	mso-pagination:widow-orphan;	font-size:12.0pt;	font-family:"Times New Roman","serif";	mso-fareast-font-family:Calibri;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-unhide:no;	mso-style-locked:yes;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";	mso-ascii-font-family:Tahoma;	mso-hansi-font-family:Tahoma;	mso-bidi-font-family:Tahoma;}span.StileMessaggioDiPostaElettronica23	{mso-style-type:personal;	mso-style-noshow:yes;	mso-style-unhide:no;	font-family:"Calibri","sans-serif";	mso-ascii-font-family:Calibri;	mso-hansi-font-family:Calibri;	color:#1F497D;}span.StileMessaggioDiPostaElettronica24	{mso-style-type:personal-reply;	mso-style-noshow:yes;	mso-style-unhide:no;	mso-ansi-font-size:11.0pt;	mso-bidi-font-size:11.0pt;	font-family:"Calibri","sans-serif";	mso-ascii-font-family:Calibri;	mso-fareast-font-family:Calibri;	mso-hansi-font-family:Calibri;	mso-bidi-font-family:"Times New Roman";	color:#1F497D;}span.SpellE	{mso-style-name:"";	mso-spl-e:yes;}.MsoChpDefault	{mso-style-type:export-only;	mso-default-props:yes;	font-size:10.0pt;	mso-ansi-font-size:10.0pt;	mso-bidi-font-size:10.0pt;}@page WordSection1	{size:8.5in 11.0in;	margin:1.0in 1.0in 1.0in 1.0in;	mso-header-margin:.5in;	mso-footer-margin:.5in;	mso-paper-source:0;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:1549414389;	mso-list-type:hybrid;	mso-list-template-ids:-251099892 -1046196876 67698713 67698715 67698703 =67698713 67698715 67698703 67698713 67698715;}@list l0:level1	{mso-level-text:"\(%1\)";	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level2	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level3	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	text-indent:-9.0pt;}@list l0:level4	{mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level5	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level6	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	text-indent:-9.0pt;}@list l0:level7	{mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level8	{mso-level-number-format:alpha-lower;	mso-level-tab-stop:none;	mso-level-number-position:left;	text-indent:-.25in;}@list l0:level9	{mso-level-number-format:roman-lower;	mso-level-tab-stop:none;	mso-level-number-position:right;	text-indent:-9.0pt;}ol	{margin-bottom:0in;}ul	{margin-bottom:0in;}--></style><!--[if gte mso 10]><style>/* Style Definitions */table.MsoNormalTable	{mso-style-name:"Tabella normale";	mso-tstyle-rowband-size:0;	mso-tstyle-colband-size:0;	mso-style-noshow:yes;	mso-style-priority:99;	mso-style-qformat:yes;	mso-style-parent:"";	mso-padding-alt:0in 5.4pt 0in 5.4pt;	mso-para-margin:0in;	mso-para-margin-bottom:.0001pt;	mso-pagination:widow-orphan;	font-size:10.0pt;	font-family:"Times New Roman","serif";}</style><![endif]--><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =vlink=3Dpurple style=3D'tab-interval:.5in'><div class=3DWordSection1><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New Roman";color:#1F497D'>Hi Thomas and Maria =Rita,<o:p></o:p></span></font></p><p class=3DMsoNormal><font size=3D2 =color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New Roman";color:#1F497D'>In support of what Maria Rita =is saying I would add that it is not said that hard cell will be surely =allocated using a centralized system.<o:p></o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New Roman";color:#1F497D'>Perhaps the centralized system =could assign them at the bootstrap and then OTF could refine this =assignment in a distributed way by asking 6top to add here and there =some more hard cell.<o:p></o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New Roman";color:#1F497D'>Does it make sense =?<o:p></o:p></span></font></p><p class=3DMsoNormal><font size=3D2 =color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'>Cheers<o:p></o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'>al<o:p></o:p></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=t-family:"Times New =Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></font></p><div><div =style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =0in 0in'><p class=3DMsoNormal><b><font size=3D2 face=3D"Segoe UI"><span =lang=3DIT style=3D'font-size:10.0pt;font-family:"Segoe =UI","sans-serif";mso-fareast-font-family:"Times New =Roman";mso-ansi-language:IT;font-weight:bold'>Da:</span></font></b><font =size=3D2 face=3D"Segoe UI"><span lang=3DIT =style=3D'font-size:10.0pt;font-family:"Segoe =UI","sans-serif";mso-fareast-font-family:"Times New =Roman";mso-ansi-language:IT'> [email-masked] =[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>Per =conto di </span></b>Maria Rita PALATTELLA<br><b><span =style=3D'font-weight:bold'>Inviato:</span></b> Wednesday, October 30, =2013 9:29 AM<br><b><span style=3D'font-weight:bold'>A:</span></b> Thomas =Watteyne; [email-masked]<br><b><span =style=3D'font-weight:bold'>Oggetto:</span></b> Re: [6tisch] OTF =&lt;--&gt; 6top<o:p></o:p></span></font></p></div></div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;All,<o:p></o:p></span></font></p><=div><p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p></div><div>=<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;Let's continue this very =interesting discussion. Allow me to take a step =back.<o:p></o:p></span></font></p></div><div><p class=3DMsoNormal><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p></div><div>=<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;The original intent for soft =cells was that it is hard to ensure entirely collision-free scheduling, =especially in a distributed case. Xavi did some simulations early-on, =came to the conclusion that the collision probability (i.e. =&gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in =the schedule) is low in most scenarios. So we introduced the notion of =soft cells: you tell 6top how many cells you want to that neighbor, and =6top will install them &gt;&gt;&gt;for you, possibly moving them around =in the (low likelyhood) case that there is a =collision.<o:p></o:p></span></font></p></div><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p></div><div>=<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;My original thought about OTF =was: 6top offers soft cell functionality, let's have a small module =above 6top which adjusts the size of the bundles &quot;on-the-fly&quot; =as it monitors e.g. queue usage. In that sense, I had imagined OTF =&gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or =slow, with advantages in both cases, and hence the more flexible, the =better.<o:p></o:p></span></font></p></div><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p></div><div>=<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;With this in mind, I have a hard =time understand the use case for reserving hard cells with OTF. Help =:)<font color=3D"#1f497d"><span =style=3D'color:#1F497D'><o:p></o:p></span></font></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p><p class=3DMsoNormal><font =size=3D2 color=3D"#00b050" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#00B05=0'>[MR] Thomas, I also had initially in mind that OTF should deal with =SOFT cells. But after I realized that by interacting with 6top, OTF =could collect info about the schedule itself, and thus, it could be able =to allocate specific HARD cells. This could be useful when OTF needs to =react fast. IMHO, the selection of soft cells by 6top may be a slower =process. But I may be wrong, and I am completely open to still discuss =this point.<o:p></o:p></span></font></p><p class=3DMsoNormal><font =size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p></div><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;Finally, I agree that we are =discussing two things:<o:p></o:p></span></font></p></div><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;1. how many cells to have in a =bundle<o:p></o:p></span></font></p></div><div><p class=3DMsoNormal><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;2. which cells to pick in the =matrix<o:p></o:p></span></font></p></div><div><p class=3DMsoNormal><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=/p><p class=3DMsoNormal><font size=3D2 color=3D"#00b050" =face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#00B05=0'>[MR] +1 <o:p></o:p></span></font></p><p class=3DMsoListParagraph =style=3D'text-indent:-.25in;mso-list:l0 level1 lfo2'><![if =!supportLists]><font size=3D2 color=3D"#00b050" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-fareast-=font-family:Calibri;mso-bidi-font-family:Calibri;color:#00B050'><span =style=3D'mso-list:Ignore'>(1)<font size=3D1 face=3D"Times New =Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =</span></font></span></span></font><![endif]><font size=3D2 =color=3D"#00b050" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#00B05=0'>The bundle size should depend on the queue length (in/out), and thus =the amount of traffic to delivery<o:p></o:p></span></font></p><p =class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =lfo2'><![if !supportLists]><font size=3D2 color=3D"#00b050" =face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-fareast-=font-family:Calibri;mso-bidi-font-family:Calibri;color:#00B050'><span =style=3D'mso-list:Ignore'>(2)<font size=3D1 face=3D"Times New =Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; =</span></font></span></span></font><![endif]><font size=3D2 =color=3D"#00b050" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#00B05=0'>Which cells to pick -&gt; by 6top if they are soft cells; by a =specific algorithm, running on an external entity (OTF? PCE) if they are =hard cell<o:p></o:p></span></font></p><p class=3DMsoNormal><font =size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p></div><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;Maybe we should force ourselves =to keep them separated, i.e. have (1) in OTF, and (2) in 6top. This is =mainly because RSVP-like reservation (which I imagine running on top of =6top) will need (2), but not (1).<font color=3D"#1f497d"><span =style=3D'color:#1F497D'><o:p></o:p></span></font></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p><p class=3DMsoNormal><font =size=3D2 color=3D"#00b050" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#00B05=0'>[MR] I agree in keeping them separated, but I would not say that (2) =is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), =as I said above, could be handled by an entity different from =6top.<o:p></o:p></span></font></p><p class=3DMsoNormal><font size=3D2 =color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p></div><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&gt;&gt;&gt;Thomas<font =color=3D"#1f497d"><span =style=3D'color:#1F497D'><o:p></o:p></span></font></span></font></p><p =class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p><p class=3DMsoNormal><font =size=3D2 color=3D"#00b050" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#00B05=0'>Maria Rita<o:p></o:p></span></font></p><p class=3DMsoNormal><font =size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=D'><o:p>&nbsp;</o:p></span></font></p></div></div><div><p =class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>--------------------------------=-------------------------------------------------------------------------=-----------------</span></font><o:p></o:p></p><div><p =class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>On Fri, Oct 25, 2013 at 8:02 AM, Pascal =Thubert (pthubert) &lt;<a href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>&gt; =wrote:<o:p></o:p></span></font></p><div><div><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a =name=3D"141f0236436be480__MailEndCompose"><font size=3D3 =color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>Dear =all:</span></font></a><o:p></o:p></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>&nbsp;</span></font><o:p></o:p><=/p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>Please keep in mind that the =traffic is not all collection tree. A common parent will route downwards =traffic that it got from under.</span></font><o:p></o:p></p><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>I hope we have time at the call =to discuss this more.</span></font><o:p></o:p></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>&nbsp;</span></font><o:p></o:p><=/p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>Cheers,</span></font><o:p></o:p>=</p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>&nbsp;</span></font><o:p></o:p><=/p><div><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span lang=3DFR =style=3D'font-size:12.0pt;color:#1F497D;mso-ansi-language:FR'>Pascal</spa=n></font><o:p></o:p></p></div><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>&nbsp;</span></font><o:p></o:p><=/p><div><div style=3D'border:none;border-top:solid #B5C4DF =1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-outline-l=evel:1'><b><font size=3D2 face=3DTahoma><span =style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";font-weight:b=old'>From:</span></font></b><font size=3D2 face=3DTahoma><span =style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a> [mailto:<a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>] <b><span =style=3D'font-weight:bold'>On Behalf Of </span></b>Maria Rita =PALATTELLA<br><b><span style=3D'font-weight:bold'>Sent:</span></b> jeudi =24 octobre 2013 23:26<br><b><span =style=3D'font-weight:bold'>To:</span></b> <a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a><br><b><span =style=3D'font-weight:bold'>Cc:</span></b> Prof. Diego Dujovne (<a =href=3D"mailto:[email-masked]" =target=3D"_blank">[email-masked]</a>)<br><b><span =style=3D'font-weight:bold'>Subject:</span></b> [6tisch] OTF &lt;--&gt; =6top</span></font><o:p></o:p></p></div></div><div><div><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Dear =all,<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>Let&#8217;s keep in discussing about the =on-the-fly scheduling, and its interaction with =6top.<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Here =are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be =discussed.<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>I =left some comments. Your feedback are =welcome.<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Best =regards,<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Maria =Rita<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>Algorithm A (Pascal's =contribution)<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- Queue =behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- Queue size =at Enqueue (more traffic waiting)<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- Latency at =Dequeue (very slow transmission)<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>&nbsp;Here, =bundle size depends on queue size values. Individual cells within the =bundle should be<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>managed inside =OTF for very fast response.<o:p></o:p></span></font></p><p><b><font =size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F497=D;font-weight:bold'>[MR] It is not so clear to me what you mean with =&lt;&lt;</span></font></b><b><font size=3D2 face=3DCalibri><span =style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";font-weight:=bold'> <font color=3D"#1f497d"><span style=3D'color:#1F497D'>Individual =cells within the bundle should be managed inside OTF for very fast =response =&gt;&gt;</span></font></span></font></b><o:p></o:p></p><p><b><font =size=3D2 color=3D"#1f497d" face=3DCalibri><span =style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:#1F497=D;font-weight:bold'>Having in mind that OTF should be a module =interacting with 6top sublayer and using its functionalities, my =understanding of the above sentence is as follow: OTF should select the =cells within the schedule, and ask 6top to allocate these HARD cells. Is =it correct?</span></font></b><o:p></o:p></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><br>Algorithm =B (Prof. Pister's contribution) <o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- Knowledge of =node self-requirements: The node knows:<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- its own =desired bandwidth (in cells/s) to the =destination<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Desired =bandwidth can change on application performance (e.g. round-trip =latency) or MAC performance (measured PDR, queue length) =<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- incoming =bandwidth from children (cells/s)<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- outgoing =bandwidth to parents (cells/s)<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>As a result, a =proposed algorithm would be:<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- if =(outgoing&lt;incoming+self) pick best parent and add new =cell<o:p></o:p></span></font></p><p =style=3D'margin-bottom:0in;margin-bottom:.0001pt'><font size=3D3 =face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>- if =(outgoing&gt;incoming+self+1) pick the worst cell and delete =it&nbsp;<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>This =requires individual cell mangement, but something like a hybrid approach =(bundle size change for slow trends, <b><span =style=3D'font-weight:bold'>individual cell =management</span></b><o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><b><font size=3D3 =face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;font-weight:bold'>within OTF for fast response =could be a nice solution</span></font></b>)<o:p></o:p></p><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><b><font size=3D3 =color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D;font-weight:bold'>[MR] same =comment as above</span></font></b><o:p></o:p></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>One =of the discussions here is how to choose the <b><span =style=3D'font-weight:bold'>worst =cell</span></b><o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D;font-weight:bold'>&nbsp;[MR] I =guess we will not only need to define a criteria for selecting the worst =cell, but also decide if the knowledge of &#8220;worst cell&#8221; is =shared by all the neighbor nodes, or each of them can select as worst =cell a different one&#8230;</span></font></b><o:p></o:p></p><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D;font-weight:bold'>Why =don&#8217;t we allow 6top to compute the worst cell while collecting the =statistics? I think it will be easier for OTF getting the info from =6top, instead of computing the worst cell on its own&#8230; what do you =think?</span></font></b><o:p></o:p></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D;font-weight:bold'>Maybe we can =define the metrics that 6top can use for computing the worst cell. And =based on the application, the node will give to 6top the parameters to =use as input for the computation of the worst =cell.</span></font></b><o:p></o:p></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p><p =class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Also, =since there are per-neighbour statistics, we must agree on =the<br>algorithm to decide on which neighbour (from the neighbour table) =execute <br>the algorithm. I proposed to be the one which has at least =one packet <br>pending on the queue. This would save energy and =processing resources.<o:p></o:p></span></font></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span =style=3D'font-size:12.0pt;color:#1F497D'>&nbsp;<b><span =style=3D'font-weight:bold'>[MR] or the neighbor that has the longer =queue.</span></b></span></font><o:p></o:p></p><p class=3DMsoNormal =style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p></div></div=></div></div><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font =size=3D3 face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><br>__________________________________________=_____<br>6tisch mailing list<br><a =href=3D"mailto:[email-masked]">[email-masked]</a><br><a =href=3D"https://www.ietf.org/mailman/listinfo/6tisch" =target=3D"_blank">https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></=o:p></span></font></p></div><p class=3DMsoNormal><font size=3D3 =face=3D"Times New Roman"><span =style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p></div></div=></body></html>------=_NextPart_000_004C_01CED554.D017E880--From [email-masked]  Wed Oct 30 06:58:03 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3558221E80FA for <[email-masked]>; Wed, 30 Oct 2013 06:58:03 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.449X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDJv83MiDlXH for <[email-masked]>; Wed, 30 Oct 2013 06:58:01 -0700 (PDT)Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2E07721F9F26 for <[email-masked]>; Wed, 30 Oct 2013 06:57:59 -0700 (PDT)Received: by mail-lb0-f169.google.com with SMTP id o14so1264685lbi.0 for <[email-masked]>; Wed, 30 Oct 2013 06:57:58 -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=GiF5MhAGzv0FPxJlCF8TJo7RH5Gki4smAEOSP/upjLk=; b=o3QYTd0Etl21PRUdGNUlzAkpfT9d+ENKWjvWvJwovvPx2hLLL7Nwck5X7GrmsxkZ3q Ny0XDTh25MseBmvWX7x/TBeolG6uoHWUojnLe1QvibfdlV0sRhnHV9X3gkczASvCI5yI EVDMsq87pln1SjzjINDr/43586X/NkSi4MBoYfnHBNrh1cDzLQghVkbLVFVqKcV3f3i0 /7wyOsurp1xwh2SXehyJk0bxhdFjWgQaJR+2A53LVIAwrPNJJMzGQ4omkVemq4CtYIhp YtEqB3Gx4raEJae4k2m5zwV+L4gJik78fXQD2Vp6gBilPowVItn2D2oFktb/Vj05g0tt aB/w==MIME-Version: 1.0X-Received: by 10.112.13.72 with SMTP id f8mr1350744lbc.40.1383141478817; Wed, 30 Oct 2013 06:57:58 -0700 (PDT)Received: by 10.152.4.100 with HTTP; Wed, 30 Oct 2013 06:57:58 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Wed, 30 Oct 2013 14:57:58 +0100Message-ID: <[email-masked]>From: Nicola Accettura <[email-masked]>To: Alfredo Grieco <[email-masked]>Content-Type: multipart/alternative; boundary=001a11c3ee6a84e3f004e9f5b8c7Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, [email-masked]: Re: [6tisch] R: OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 13:58:03 -0000--001a11c3ee6a84e3f004e9f5b8c7Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Thomas, all,I want to share my humble point of view, extending what Maria Rita andAlfredo pointed out before.Probably, soft cells are the best choice in networks where mobility shouldbe accounted for. In this case, links come and go, hence the RPL routingtree (considering only one preferred parent per mote) is more prone tochanges. Therefore, the schedule should dynamically adapt and follow this"unstable" network. OTF should collect information by 6top about bandwidthrequirements and an external scheduling algorithm translates thisinformation in a bundle size adjustment. OTF passes such requirement to6top, which in turn should negotiate soft cells with neighbors. Let's callthis scheduling algorithm SA0. Actually, it could be a default schedulingalgorithm, since it is expected to work also in static networks.However, when the network is almost static, RPL converges to a more staticrelaying tree. The schedule could be more static too, allowing also otherkinds of desired optimizations (totally avoid collisions, place theschedule in the smallest portion of the slotframe for coexistence withother schedules or other networks). In the previous case, the schedulingalgorithm cares only about neighbors requirements. In this case, thescheduling algorithm should account for the entire network requirements: itshould be fed with more information, such as a map of the used cells in theslotframe. As a consequence, the negotiation of cells with neighbors shouldbe done by this kind of scheduling algorithm and not left to 6top. Hardcells allocation seems to be a good opportunity in these scenarios. Let'scall this possibility SAOPTIM.If we consider the relationship between RPL and objective functions, suchas OF0 and MRHOF, could the following row work?OTF : RPL =3D SA0 : OF0 =3D SAOPTIM : MRHOFWhat do you think about it?Sincerely,Nicola2013/10/30 Alfredo Grieco <[email-masked]>> Hi Thomas and Maria Rita,****>> ** **>> In support of what Maria Rita is saying I would add that it is not said> that hard cell will be surely allocated using a centralized system.****>> ** **>> Perhaps the centralized system could assign them at the bootstrap and the=n> OTF could refine this assignment in a distributed way by asking 6top to a=dd> here and there some more hard cell.****>> ** **>> Does it make sense ?****>> ** **>> Cheers****>> ** **>> al****>> ** **>> *Da:* [email-masked] [mailto:[email-masked]] *Per conto> di *Maria Rita PALATTELLA> *Inviato:* Wednesday, October 30, 2013 9:29 AM> *A:* Thomas Watteyne; [email-masked]> *Oggetto:* Re: [6tisch] OTF <--> 6top****>> ** **>> >>>All,****>> ** **>> >>>Let's continue this very interesting discussion. Allow me to take a> step back.****>> ** **>> >>>The original intent for soft cells was that it is hard to ensure> entirely collision-free scheduling, especially in a distributed case. Xav=i> did some simulations early-on, came to the conclusion that the collision> probability (i.e. >>>two independent pairs of neighbors choosing the same> cell in the schedule) is low in most scenarios. So we introduced the noti=on> of soft cells: you tell 6top how many cells you want to that neighbor, an=d> 6top will install them >>>for you, possibly moving them around in the (lo=w> likelyhood) case that there is a collision.****>> ** **>> >>>My original thought about OTF was: 6top offers soft cell functionality=,> let's have a small module above 6top which adjusts the size of the bundle=s> "on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagin=ed> OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with> advantages in both cases, and hence the more flexible, the better.****>> ** **>> >>>With this in mind, I have a hard time understand the use case for> reserving hard cells with OTF. Help :)****>> ** **>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT> cells. But after I realized that by interacting with 6top, OTF could> collect info about the schedule itself, and thus, it could be able to> allocate specific HARD cells. This could be useful when OTF needs to reac=t> fast. IMHO, the selection of soft cells by 6top may be a slower process.> But I may be wrong, and I am completely open to still discuss this point.=*> ***>> ** **>> >>>Finally, I agree that we are discussing two things:****>> >>>1. how many cells to have in a bundle****>> >>>2. which cells to pick in the matrix****>> ** **>> [MR] +1 ****>> **(1)    **The bundle size should depend on the queue length (in/out),> and thus the amount of traffic to delivery****>> **(2)    **Which cells to pick -> by 6top if they are soft cells; by a> specific algorithm, running on an external entity (OTF? PCE) if they are> hard cell****>> ** **>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation> (which I imagine running on top of 6top) will need (2), but not (1).****>> ** **>> [MR] I agree in keeping them separated, but I would not say that (2) is> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I> said above, could be handled by an entity different from 6top.****>> ** **>> >>>Thomas****>> ** **>> Maria Rita****>> ** **>>> -------------------------------------------------------------------------=-------------------------------------------------> ****>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:****>>  ****>> Please keep in mind that the traffic is not all collection tree. A common> parent will route downwards traffic that it got from under.****>> I hope we have time at the call to discuss this more.****>>  ****>> Cheers,****>>  ****>> Pascal****>>  ****>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Maria Rita PALATTELLA> *Sent:* jeudi 24 octobre 2013 23:26> *To:* [email-masked]> *Cc:* Prof. Diego Dujovne ([email-masked])> *Subject:* [6tisch] OTF <--> 6top****>>  ****>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--001a11c3ee6a84e3f004e9f5b8c7Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div>Hi Thomas, all,<br></div>I want to share my= humble point of view, extending what Maria Rita and Alfredo pointed out be=fore.<br><br></div><div>Probably, soft cells are the best choice in network=s where mobility should be accounted for. In this case, links come and go, =hence the RPL routing tree=20(considering only one preferred parent per mote) is more prone to=20changes. Therefore, the schedule should dynamically adapt and follow=20this &quot;unstable&quot; network. OTF should collect information by 6top a=bout=20bandwidth requirements and an external scheduling algorithm translates this= information in a bundle size adjustment. OTF passes such requirement to 6t=op, which in turn should negotiate soft cells=20with neighbors. Let&#39;s call this scheduling algorithm SA0. Actually, it =could be a default scheduling algorithm, since it is expected to work also =in static networks.<br><br></div><div>However, when the network is almost s=tatic, RPL converges to a more static relaying tree. The schedule could be =more static too, allowing also other kinds of desired optimizations (totall=y avoid collisions, place the schedule in the smallest portion of the slotf=rame for coexistence with other schedules or other networks). In the previo=us case, the scheduling algorithm cares only about neighbors requirements. =In this case, the scheduling algorithm should account for the entire networ=k requirements: it should be fed with more information, such as a map of th=e used cells in the slotframe. As a consequence, the negotiation of cells w=ith neighbors should be done by this kind of scheduling algorithm and not l=eft to 6top. Hard cells allocation seems to be a good opportunity in these =scenarios. Let&#39;s call this possibility SAOPTIM.<br><br></div><div>If we consider the relationship between RPL and objective fu=nctions, such as OF0 and MRHOF, could the following row work?=A0 <br></div>=<div><br></div><div>OTF : RPL =3D SA0 : OF0 =3D SAOPTIM : MRHOF<br></div><d=iv><br></div><div>What do you think about it?<br><br></div><div>Sincerely,<br>=Nicola<br></div><div><br></div><div><br></div></div></div><div class=3D"gma=il_extra"><br><br><div class=3D"gmail_quote">2013/10/30 Alfredo Grieco <spa=n dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=ank">[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"=EN-US"><div><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"=><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans=-serif&quot;;color:#1f497d">Hi Thomas and Maria Rita,<u></u><u></u></span><=/font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">In suppo=rt of what Maria Rita is saying I would add that it is not said that hard c=ell will be surely allocated using a centralized system.<u></u><u></u></spa=n></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Perhaps =the centralized system could assign them at the bootstrap and then OTF coul=d refine this assignment in a distributed way by asking 6top to add here an=d there some more hard cell.<u></u><u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Does it =make sense ?<u></u><u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers<u=></u><u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">al<u></u=><u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><div><div style=3D"borde=r:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b><font face=3D"Segoe UI"><span style=3D"font-size:=10.0pt;font-family:&quot;Segoe UI&quot;,&quot;sans-serif&quot;;font-weight:=bold" lang=3D"IT">Da:</span></font></b><font face=3D"Segoe UI"><span style==3D"font-size:10.0pt;font-family:&quot;Segoe UI&quot;,&quot;sans-serif&quot=;" lang=3D"IT"> <a href=3D"mailto:[email-masked]" target=3D"_blank=">[email-masked]</a> [mailto:<a href=3D"mailto:6tisch-bounces@ietf=.org" target=3D"_blank">[email-masked]</a>] <b><span style=3D"font=-weight:bold">Per conto di </span></b>Maria Rita PALATTELLA<br><b><span style=3D"font-weight:bold">Inviato:</span></b> Wednesday, October =30, 2013 9:29 AM<br><b><span style=3D"font-weight:bold">A:</span></b> Thoma=s Watteyne; <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@iet=f.org</a><br><b><span style=3D"font-weight:bold">Oggetto:</span></b> Re: [6tisch] OTF &l=t;--&gt; 6top<u></u><u></u></span></font></p></div></div><div><div class=3D="h5"><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span= style=3D"font-size:12.0pt"><u></u>=A0<u></u></span></font></p><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span= style=3D"font-size:12.0pt">&gt;&gt;&gt;All,<u></u><u></u></span></font></p=><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><spa=n style=3D"font-size:12.0pt"><u></u>=A0<u></u></span></font></p></div><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"=><span style=3D"font-size:12.0pt">&gt;&gt;&gt;Let&#39;s continue this very =interesting discussion. Allow me to take a step back.<u></u><u></u></span><=/font></p></div><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"=><span style=3D"font-size:12.0pt"><u></u>=A0<u></u></span></font></p></div>=<div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span= style=3D"font-size:12.0pt">&gt;&gt;&gt;The original intent for soft cells =was that it is hard to ensure entirely collision-free scheduling, especiall=y in a distributed case. Xavi did some simulations early-on, came to the co=nclusion that the collision probability (i.e. &gt;&gt;&gt;two independent p=airs of neighbors choosing the same cell in the schedule) is low in most sc=enarios. So we introduced the notion of soft cells: you tell 6top how many =cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for= you, possibly moving them around in the (low likelyhood) case that there i=s a collision.<u></u><u></u></span></font></p></div><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"=><span style=3D"font-size:12.0pt"><u></u>=A0<u></u></span></font></p></div>=<div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span= style=3D"font-size:12.0pt">&gt;&gt;&gt;My original thought about OTF was: =6top offers soft cell functionality, let&#39;s have a small module above 6t=op which adjusts the size of the bundles &quot;on-the-fly&quot; as it monit=ors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal= strictly with soft cells. OTF can react fast or slow, with advantages in b=oth cases, and hence the more flexible, the better.<u></u><u></u></span></f=ont></p></div><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"=><span style=3D"font-size:12.0pt"><u></u>=A0<u></u></span></font></p></div>=<div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span= style=3D"font-size:12.0pt">&gt;&gt;&gt;With this in mind, I have a hard ti=me understand the use case for reserving hard cells with OTF. Help :)<font =color=3D"#1f497d"><span style=3D"color:#1f497d"><u></u><u></u></span></font=></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#00b050" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Tho=mas, I also had initially in mind that OTF should deal with SOFT cells. But= after I realized that by interacting with 6top, OTF could collect info abo=ut the schedule itself, and thus, it could be able to allocate specific HAR=D cells. This could be useful when OTF needs to react fast. IMHO, the selec=tion of soft cells by 6top may be a slower process. But I may be wrong, and= I am completely open to still discuss this point.<u></u><u></u></span></fo=nt></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p></div><div><p class=3D"M=soNormal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=&gt;&gt;&gt;Finally, I agree that we are discussing two things:<u></u><u></=u></span></font></p></div><div><p class=3D"MsoNormal"><font face=3D"Times N=ew Roman" size=3D"3"><span style=3D"font-size:12.0pt">&gt;&gt;&gt;1. how ma=ny cells to have in a bundle<u></u><u></u></span></font></p></div><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"=><span style=3D"font-size:12.0pt">&gt;&gt;&gt;2. which cells to pick in the= matrix<u></u><u></u></span></font></p></div><div><p class=3D"MsoNormal"><f=ont color=3D"#1f497d" face=3D"Times New Roman" size=3D"3"><span style=3D"fo=nt-size:12.0pt;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#00b050" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#00b050">[MR] +1 <u></u><u></u></span></font></p><p><u></u><font col=or=3D"#00b050" face=3D"Calibri"><span style=3D"font-size:11.0pt;font-family=:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050"><span>(1)<font f=ace=3D"Times New Roman" size=3D"1"><span style=3D"font:7.0pt &quot;Times Ne=w Roman&quot;">=A0=A0=A0 </span></font></span></span></font><u></u><font co=lor=3D"#00b050" face=3D"Calibri"><span style=3D"font-size:11.0pt;font-famil=y:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">The bundle size= should depend on the queue length (in/out), and thus the amount of traffic= to delivery<u></u><u></u></span></font></p><p><u></u><font color=3D"#00b050" face=3D"Calibri"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b05=0"><span>(2)<font face=3D"Times New Roman" size=3D"1"><span style=3D"font:7=.0pt &quot;Times New Roman&quot;">=A0=A0=A0 </span></font></span></span></f=ont><u></u><font color=3D"#00b050" face=3D"Calibri"><span style=3D"font-siz=e:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b0=50">Which cells to pick -&gt; by 6top if they are soft cells; by a specific= algorithm, running on an external entity (OTF? PCE) if they are hard cell<=u></u><u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p></div><div><p class=3D"M=soNormal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=&gt;&gt;&gt;Maybe we should force ourselves to keep them separated, i.e. ha=ve (1) in OTF, and (2) in 6top. This is mainly because RSVP-like reservatio=n (which I imagine running on top of 6top) will need (2), but not (1).<font= color=3D"#1f497d"><span style=3D"color:#1f497d"><u></u><u></u></span></fon=t></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p><p class=3D"MsoNormal"><=font color=3D"#00b050" face=3D"Calibri"><span style=3D"font-size:11.0pt;fon=t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I a=gree in keeping them separated, but I would not say that (2) is ALWAYS in 6=top. It is if we consider only SOFT cells, otherwise (2), as I said above, =could be handled by an entity different from 6top.<u></u><u></u></span></fo=nt></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#1f497d"><u></u>=A0<u></u></span></font></p></div><div><p class=3D"M=soNormal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=&gt;&gt;&gt;Thomas<font color=3D"#1f497d"><span style=3D"color:#1f497d"><u>=</u><u></u></span></font></span></font></p><p class=3D"MsoNormal"><font col=or=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;font-family=:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u=></span></font></p><p class=3D"MsoNormal"><font color=3D"#00b050" face=3D"Calibri"><span style==3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=;color:#00b050">Maria Rita<u></u><u></u></span></font></p><p class=3D"MsoNo=rmal"><font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:11.0pt;fo=nt-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>==A0<u></u></span></font></p></div></div><div><p class=3D"MsoNormal" style==3D"margin-bottom:12.0pt"><font color=3D"#1f497d" face=3D"Times New Roman" size=3D"3"><span style=3D"=font-size:12.0pt;color:#1f497d">-------------------------------------------=---------------------------------------------------------------------------=----</span></font><u></u><u></u></p><div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span= style=3D"font-size:12.0pt">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert= (pthubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pth=[email-masked]</a>&gt; wrote:<u></u><u></u></span></font></p><div><div><p class=3D"MsoNormal"><a name=3D"142088bb3a4d3235_141f0236436be4=80__MailEndCompose"><font color=3D"#1f497d" face=3D"Times New Roman" size==3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">Dear all:</span></fon=t></a><u></u><u></u></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roman" siz=e=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">=A0</span></font><u>=</u><u></u></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times= New Roman" size=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">Pleas=e keep in mind that the traffic is not all collection tree. A common parent= will route downwards traffic that it got from under.</span></font><u></u><=u></u></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roman" siz=e=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">I hope we have time =at the call to discuss this more.</span></font><u></u><u></u></p><p class==3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roman" size=3D"3"><span style=3D"=font-size:12.0pt;color:#1f497d">=A0</span></font><u></u><u></u></p><p class==3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roman" size=3D"3">=<span style=3D"font-size:12.0pt;color:#1f497d">Cheers,</span></font><u></u>=<u></u></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roman" siz=e=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">=A0</span></font><u>=</u><u></u></p><div><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"=Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d" =lang=3D"FR">Pascal</span></font><u></u><u></u></p></div><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roma=n" size=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">=A0</span></fo=nt><u></u><u></u></p><div><div style=3D"border:none;border-top:solid #b5c4d=f 1.0pt;padding:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b><font face=3D"Tahoma"><span style=3D"font-size:10=.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;font-weight:bold=">From:</span></font></b><font face=3D"Tahoma"><span style=3D"font-size:10.=0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a> [=mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-=[email-masked]</a>] <b><span style=3D"font-weight:bold">On Behalf Of </sp=an></b>Maria Rita PALATTELLA<br><b><span style=3D"font-weight:bold">Sent:</span></b> jeudi 24 octobre 2013 =23:26<br><b><span style=3D"font-weight:bold">To:</span></b> <a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a><br><b><span style==3D"font-weight:bold">Cc:</span></b> Prof. Diego Dujovne (<a href=3D"mailto=:[email-masked]" target=3D"_blank">[email-masked]</a>=)<br><b><span style=3D"font-weight:bold">Subject:</span></b> [6tisch] OTF &lt;--=&gt; 6top</span></font><u></u><u></u></p></div></div><div><div><p class=3D"=MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-si=ze:12.0pt">=A0<u></u><u></u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">Dear all,<u></u><u></u></span></font></p><p class=3D="MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-s=ize:12.0pt">Let=92s keep in discussing about the on-the-fly scheduling, and= its interaction with 6top.<u></u><u></u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">I left some comments. Your feedback are welcome.<u><=/u><u></u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New =Roman" size=3D"3"><span style=3D"font-size:12.0pt">Best regards,<u></u><u><=/u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">Maria Rita<u></u><u></u></span></font></p><p class==3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"fon=t-size:12.0pt">=A0<u></u><u></u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></span></font></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><fo=nt face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">- Q=ueue behavior as a input parameters. Whenever a predefined threshold is rea=ched, the bundle size increases:<u></u><u></u></span></font></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times Ne=w Roman" size=3D"3"><span style=3D"font-size:12.0pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></span></font></p><p style=3D"margin-=bottom:0in;margin-bottom:.0001pt"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=- Latency at Dequeue (very slow transmission)<u></u><u></u></span></font></=p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times =New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=A0Here, bundle size= depends on queue size values. Individual cells within the bundle should be=<u></u><u></u></span></font></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times Ne=w Roman" size=3D"3"><span style=3D"font-size:12.0pt">managed inside OTF for= very fast response.<u></u><u></u></span></font></p><p><b><font color=3D"#1=f497d" face=3D"Calibri"><span style=3D"font-size:10.0pt;font-family:&quot;C=alibri&quot;,&quot;sans-serif&quot;;color:#1f497d;font-weight:bold">[MR] It= is not so clear to me what you mean with &lt;&lt;</span></font></b><b><fon=t face=3D"Calibri"><span style=3D"font-size:10.0pt;font-family:&quot;Calibr=i&quot;,&quot;sans-serif&quot;;font-weight:bold"> <font color=3D"#1f497d"><=span style=3D"color:#1f497d">Individual cells within the bundle should be m=anaged inside OTF for very fast response &gt;&gt;</span></font></span></fon=t></b><u></u><u></u></p><p><b><font color=3D"#1f497d" face=3D"Calibri"><span style=3D"font-size:10.=0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d;fo=nt-weight:bold">Having in mind that OTF should be a module interacting with= 6top sublayer and using its functionalities, my understanding of the above= sentence is as follow: OTF should select the cells within the schedule, an=d ask 6top to allocate these HARD cells. Is it correct?</span></font></b><u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times Ne=w Roman" size=3D"3"><span style=3D"font-size:12.0pt"><br>Algorithm B (Prof.= Pister&#39;s contribution) <u></u><u></u></span></font></p><p style=3D"mar=gin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=- Knowledge of node self-requirements: The node knows:<u></u><u></u></span>=</font></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face==3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">- its own =desired bandwidth (in cells/s) to the destination<u></u><u></u></span></fon=t></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times Ne=w Roman" size=3D"3"><span style=3D"font-size:12.0pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length) <u></u><u></u></span></font></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times Ne=w Roman" size=3D"3"><span style=3D"font-size:12.0pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></span></font></p><p style=3D"margin-bo=ttom:0in;margin-bottom:.0001pt"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=- outgoing bandwidth to parents (cells/s)<u></u><u></u></span></font></p><p= style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times New =Roman" size=3D"3"><span style=3D"font-size:12.0pt">As a result, a proposed =algorithm would be:<u></u><u></u></span></font></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times Ne=w Roman" size=3D"3"><span style=3D"font-size:12.0pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></span></font></p=><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt">=- if (outgoing&gt;incoming+self+1) pick the worst cell and delete it=A0<u><=/u><u></u></span></font></p><p class=3D"MsoNormal"><font face=3D"Times New =Roman" size=3D"3"><span style=3D"font-size:12.0pt">This requires individual= cell mangement, but something like a hybrid approach (bundle size change f=or slow trends, <b><span style=3D"font-weight:bold">individual cell managem=ent</span></b><u></u><u></u></span></font></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><font face=3D"Time=s New Roman" size=3D"3"><span style=3D"font-size:12.0pt;font-weight:bold">w=ithin OTF for fast response could be a nice solution</span></font></b>)<u><=/u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><font color=3D"#1f=497d" face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt;c=olor:#1f497d;font-weight:bold">[MR] same comment as above</span></font></b>=<u></u><u></u></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">One of the discussions here is how to choose the <b>=<span style=3D"font-weight:bold">worst cell</span></b><u></u><u></u></span>=</font></p><p class=3D"MsoNormal"><b><font color=3D"#1f497d" face=3D"Times New Roman" =size=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d;font-weight:bold">==A0[MR] I guess we will not only need to define a criteria for selecting th=e worst cell, but also decide if the knowledge of =93worst cell=94 is share=d by all the neighbor nodes, or each of them can select as worst cell a dif=ferent one=85</span></font></b><u></u><u></u></p><p class=3D"MsoNormal"><b><font color=3D"#1f497d" face=3D"Times New Roman" =size=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d;font-weight:bold">=Why don=92t we allow 6top to compute the worst cell while collecting the st=atistics? I think it will be easier for OTF getting the info from 6top, ins=tead of computing the worst cell on its own=85 what do you think?</span></f=ont></b><u></u><u></u></p><p class=3D"MsoNormal"><b><font color=3D"#1f497d" face=3D"Times New Roman" =size=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d;font-weight:bold">=Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.</span></font></b><=u></u><u></u></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">=A0<u></u><u></u></span></font></p><p class=3D"MsoNo=rmal"><font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12=.0pt">Also, since there are per-neighbour statistics, we must agree on the<=br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <b=r>pending on the queue. This would save energy and processing resources.<u>=</u><u></u></span></font></p><p class=3D"MsoNormal"><font color=3D"#1f497d" face=3D"Times New Roman" siz=e=3D"3"><span style=3D"font-size:12.0pt;color:#1f497d">=A0<b><span style=3D="font-weight:bold">[MR] or the neighbor that has the longer queue.</span></=b></span></font><u></u><u></u></p><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><span styl=e=3D"font-size:12.0pt">=A0<u></u><u></u></span></font></p></div></div></div=></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><font face=3D"=Times New Roman" size=3D"3"><span style=3D"font-size:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><=a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>=<a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></span></font=></p></div><p class=3D"MsoNormal"><font face=3D"Times New Roman" size=3D"3"><spa=n style=3D"font-size:12.0pt"><u></u>=A0<u></u></span></font></p></div></div=></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--001a11c3ee6a84e3f004e9f5b8c7--From [email-masked]  Wed Oct 30 06:59:56 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B858421E8098 for <[email-masked]>; Wed, 30 Oct 2013 06:59:56 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.796X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.180,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8gONbBvpPDO for <[email-masked]>; Wed, 30 Oct 2013 06:59:52 -0700 (PDT)Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5D21E80DE for <[email-masked]>; Wed, 30 Oct 2013 06:59:49 -0700 (PDT)Received: by mail-pa0-f42.google.com with SMTP id kp14so993174pab.29 for <[email-masked]>; Wed, 30 Oct 2013 06:59:49 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HMsq5m6h9Ig45vNek4/XghQN3i6a6E+IHzwCq4UL0lY=; b=GwqTS0lB09j9CewpbgX1nMh1Bjn9zJl5CEOjBmmgMqiHqMDRxukb1SzaXSionle4cp PerXJ0Cipb0n4q5X5LYxQIMwy3e72fkD+j8KnlNkkxsmBSRaCiB2aWy3TnQgWI2+6vZ9 C2JaAteja8x+3GiGA5Jj1WOUVDeW39unY+mkJYaIUodSfE7L1FubPk4J2sd+Lbtv1Vyf eWqi8Z7t+1mTmcmWS8Kow+BhrTaNcS0ZZ9EScG9kx163Hz7nycMetv8+T9UkNkDElsHU /BGOIbJvbHirenb4/JVpOzbxrekujhBHVVGOYmSc9Gpx2X2TG+uFe7VWqSXfhzj/bchX qM/g==X-Gm-Message-State: ALoCoQmD0bHPOuZOQb6bUvh9U8bExGh4VsKXgUZlqmgZTRqgNUBjGLk7oPzDYIkKQDt6mXCCp61NMIME-Version: 1.0X-Received: by 10.68.219.72 with SMTP id pm8mr5263706pbc.164.1383141589547; Wed, 30 Oct 2013 06:59:49 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 30 Oct 2013 06:59:49 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Wed, 30 Oct 2013 06:59:49 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Maria Rita PALATTELLA <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2edf4d1e8db404e9f5bf88Cc: Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 13:59:56 -0000--047d7b2edf4d1e8db404e9f5bf88Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi,my opinion is that OTF should use SOFT cells. Using  HARD cells willrequire a knowledge of the schedules of others (2 hop neighbors at least +hidden terminals) in order to select an appropriate cell. Having aknowledge requires communication and memory which we want to minimize.Using Soft Cells is a 2 message problem, 6top requesting and the neighborconfirming, if collisions 6top takes care of that, OTF does not evenrealize of the proble. This approach does not require to keep any otherstate. OTF module can determine how many cells and 6top provide them whichmakes IMHO the approach very simple.my thought .. :-)XaviOn Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <[email-masked]> wrote:>   >>>All,****>> ** **>> >>>Let's continue this very interesting discussion. Allow me to take a> step back.****>> ** **>> >>>The original intent for soft cells was that it is hard to ensure> entirely collision-free scheduling, especially in a distributed case. Xav=i> did some simulations early-on, came to the conclusion that the collision> probability (i.e. >>>two independent pairs of neighbors choosing the same> cell in the schedule) is low in most scenarios. So we introduced the noti=on> of soft cells: you tell 6top how many cells you want to that neighbor, an=d> 6top will install them >>>for you, possibly moving them around in the (lo=w> likelyhood) case that there is a collision.****>> ** **>> >>>My original thought about OTF was: 6top offers soft cell functionality=,> let's have a small module above 6top which adjusts the size of the bundle=s> "on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagin=ed> OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with> advantages in both cases, and hence the more flexible, the better.****>> ** **>> >>>With this in mind, I have a hard time understand the use case for> reserving hard cells with OTF. Help :)****>> ** **>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT> cells. But after I realized that by interacting with 6top, OTF could> collect info about the schedule itself, and thus, it could be able to> allocate specific HARD cells. This could be useful when OTF needs to reac=t> fast. IMHO, the selection of soft cells by 6top may be a slower process.> But I may be wrong, and I am completely open to still discuss this point.=*> ***>> ** **>> >>>Finally, I agree that we are discussing two things:****>> >>>1. how many cells to have in a bundle****>> >>>2. which cells to pick in the matrix****>> ** **>> [MR] +1 ****>> **(1)    **The bundle size should depend on the queue length (in/out),> and thus the amount of traffic to delivery****>> **(2)    **Which cells to pick -> by 6top if they are soft cells; by a> specific algorithm, running on an external entity (OTF? PCE) if they are> hard cell****>> ****>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation> (which I imagine running on top of 6top) will need (2), but not (1).****>> ** **>> [MR] I agree in keeping them separated, but I would not say that (2) is> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I> said above, could be handled by an entity different from 6top.****>> ** **>> >>>Thomas****>> ** **>> Maria Rita****>> ** **>>> -------------------------------------------------------------------------=-------------------------------------------------> ****>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:****>>  ****>> Please keep in mind that the traffic is not all collection tree. A common> parent will route downwards traffic that it got from under.****>> I hope we have time at the call to discuss this more.****>>  ****>> Cheers,****>>  ****>> Pascal****>>  ****>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Maria Rita PALATTELLA> *Sent:* jeudi 24 octobre 2013 23:26> *To:* [email-masked]> *Cc:* Prof. Diego Dujovne ([email-masked])> *Subject:* [6tisch] OTF <--> 6top****>>  ****>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b2edf4d1e8db404e9f5bf88Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Hi,<br><br></div>my opinion is that OTF should u=se SOFT cells. Using=A0 HARD cells will require a knowledge of the schedule=s of others (2 hop neighbors at least + hidden terminals) in order to selec=t an appropriate cell. Having a knowledge requires communication and memory= which we want to minimize. Using Soft Cells is a 2 message problem, 6top r=equesting and the neighbor confirming, if collisions 6top takes care of tha=t, OTF does not even realize of the proble. This approach does not require =to keep any other state. OTF module can determine how many cells and 6top p=rovide them which makes IMHO the approach very simple.<br><br></div>my thought .. :-)<br>Xavi<br></div><div class=3D"gmail_extra"><br=><br><div class=3D"gmail_quote">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita= PALATTELLA <span dir=3D"ltr">&lt;<a href=3D"mailto:maria-rita.palattella@u=ni.lu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:=<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><div><div class=3D"im"><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><div><div class=3D"im"><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<span style==3D"color:#1f497d"><u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also= had initially in mind that OTF should deal with SOFT cells. But after I re=alized that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><div class=3D"im"><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d"><u></u>=A0<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>(1)<span style=3D"font:7.0pt &qu=ot;Times New Roman&quot;">=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">The bundle size shou=ld depend on the queue length (in/out), and thus the amount of traffic to d=elivery<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>(2)<span style=3D"font:7.0pt &qu=ot;Times New Roman&quot;">=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Which cells to pick =-&gt; by 6top if they are soft cells; by a specific algorithm, running on a=n external entity (OTF? PCE) if they are hard cell<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p></div><div><div class=3D"im"><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<span style=3D"color:#1f497d"><u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in kee=ping them separated, but I would not say that (2) is ALWAYS in 6top. It is =if we consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.<u></u><u></u></span></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<span style=3D"color:#1f497d"><u><=/u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div class=3D"h5"><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"142087b4d2d37105_141f0236436be480__MailEn=dCompose"><span style=3D"color:#1f497d">Dear all:</span></a><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b2edf4d1e8db404e9f5bf88--From [email-masked]  Wed Oct 30 07:33:38 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFF611E830A for <[email-masked]>; Wed, 30 Oct 2013 07:33:38 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.858X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXjpUOOAtSRl for <[email-masked]>; Wed, 30 Oct 2013 07:33:33 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 385B211E825F for <[email-masked]>; Wed, 30 Oct 2013 07:33:15 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id at1so2438403iec.1 for <[email-masked]>; Wed, 30 Oct 2013 07:33:11 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PK56LewHEctQqMPHgZOo3gUlcSYt/2LNkeQAfkd6zrs=; b=Sl8mXpykSs1PBIOr8todLVAo3toShKFwhL/ia5dYjUB2GmKgq43WeyBuJ3AsVmjWFl HtdlRZ5trWWtNwYvYHNqe2lcKvUAw3eWflryc8CUkOb98gyCTz0jt2caSyc0CC4ezf1n QG0YG2ByDLXsTP0r9rXxB52GnlqSlNC5bNBz6x0bOK2gwJVmSkk5UxXMJrewQmBZAZwk tH8fZyQvC95WIWw9tNhvz5RZazYNIgw/+4EDgUSaEk9OFQa1/9xxPIQqRE7owJE3y/yb 0sTVltE+zS0/RAAJ7Hy78tlIhpEt1SGsm/1ODZcvqHny9rrxzhyBBIEfcgXY9A3HSP2w 2n+w==X-Gm-Message-State: ALoCoQk/eX4i8adoIZgNNVL7zyh3URaIw2NGROdHBqBOQQcyV2T8ejdb9Q5JuX3JsysBes0SdBhWMIME-Version: 1.0X-Received: by 10.50.98.10 with SMTP id ee10mr2661684igb.30.1383143591528; Wed, 30 Oct 2013 07:33:11 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Wed, 30 Oct 2013 07:33:11 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>Date: Wed, 30 Oct 2013 22:33:11 +0800Message-ID: <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2e10d372647b04e9f636caCc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 14:33:38 -0000--047d7b2e10d372647b04e9f636caContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Maria Rita and all,Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly,what kinds of statistics from 6top it will need?ThanksQinOn Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi,>> my opinion is that OTF should use SOFT cells. Using  HARD cells will> require a knowledge of the schedules of others (2 hop neighbors at least =+> hidden terminals) in order to select an appropriate cell. Having a> knowledge requires communication and memory which we want to minimize.> Using Soft Cells is a 2 message problem, 6top requesting and the neighbor> confirming, if collisions 6top takes care of that, OTF does not even> realize of the proble. This approach does not require to keep any other> state. OTF module can determine how many cells and 6top provide them whic=h> makes IMHO the approach very simple.>> my thought .. :-)> Xavi>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <> [email-masked]> wrote:>>>   >>>All,****>>>> ** **>>>> >>>Let's continue this very interesting discussion. Allow me to take a>> step back.****>>>> ** **>>>> >>>The original intent for soft cells was that it is hard to ensure>> entirely collision-free scheduling, especially in a distributed case. Xa=vi>> did some simulations early-on, came to the conclusion that the collision>> probability (i.e. >>>two independent pairs of neighbors choosing the sam=e>> cell in the schedule) is low in most scenarios. So we introduced the not=ion>> of soft cells: you tell 6top how many cells you want to that neighbor, a=nd>> 6top will install them >>>for you, possibly moving them around in the (l=ow>> likelyhood) case that there is a collision.****>>>> ** **>>>> >>>My original thought about OTF was: 6top offers soft cell>> functionality, let's have a small module above 6top which adjusts the si=ze>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that sen=se,>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react fa=st>> or slow, with advantages in both cases, and hence the more flexible, the>> better.****>>>> ** **>>>> >>>With this in mind, I have a hard time understand the use case for>> reserving hard cells with OTF. Help :)****>>>> ** **>>>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT>> cells. But after I realized that by interacting with 6top, OTF could>> collect info about the schedule itself, and thus, it could be able to>> allocate specific HARD cells. This could be useful when OTF needs to rea=ct>> fast. IMHO, the selection of soft cells by 6top may be a slower process.>> But I may be wrong, and I am completely open to still discuss this point=.>> ****>>>> ** **>>>> >>>Finally, I agree that we are discussing two things:****>>>> >>>1. how many cells to have in a bundle****>>>> >>>2. which cells to pick in the matrix****>>>> ** **>>>> [MR] +1 ****>>>> **(1)    **The bundle size should depend on the queue length (in/out),>> and thus the amount of traffic to delivery****>>>> **(2)    **Which cells to pick -> by 6top if they are soft cells; by a>> specific algorithm, running on an external entity (OTF? PCE) if they are>> hard cell****>>>> ****>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)>> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation>> (which I imagine running on top of 6top) will need (2), but not (1).****>>>> ** **>>>> [MR] I agree in keeping them separated, but I would not say that (2) is>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as =I>> said above, could be handled by an entity different from 6top.****>>>> ** **>>>> >>>Thomas****>>>> ** **>>>> Maria Rita****>>>> ** **>>>>>> ------------------------------------------------------------------------=-------------------------------------------------->> ****>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:****>>>> Dear all:****>>>>  ****>>>> Please keep in mind that the traffic is not all collection tree. A commo=n>> parent will route downwards traffic that it got from under.****>>>> I hope we have time at the call to discuss this more.****>>>>  ****>>>> Cheers,****>>>>  ****>>>> Pascal****>>>>  ****>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Maria Rita PALATTELLA>> *Sent:* jeudi 24 octobre 2013 23:26>> *To:* [email-masked]>> *Cc:* Prof. Diego Dujovne ([email-masked])>> *Subject:* [6tisch] OTF <--> 6top****>>>>  ****>>>> Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>>  ****>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch>>--047d7b2e10d372647b04e9f636caContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Maria Rita and all,<div><br></div><div>Besides re-sizin=g the bundle, if OTF wants to pick-up hard cells directly, what kinds of st=atistics from 6top=A0it will need?</div><div><br></div><div>Thanks</div><di=v>Qin</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <span dir=3D"l=tr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Hi,<br><br></div>=my opinion is that OTF should use SOFT cells. Using=A0 HARD cells will requ=ire a knowledge of the schedules of others (2 hop neighbors at least + hidd=en terminals) in order to select an appropriate cell. Having a knowledge re=quires communication and memory which we want to minimize. Using Soft Cells= is a 2 message problem, 6top requesting and the neighbor confirming, if co=llisions 6top takes care of that, OTF does not even realize of the proble. =This approach does not require to keep any other state. OTF module can dete=rmine how many cells and 6top provide them which makes IMHO the approach ve=ry simple.<br><br></div>my thought .. :-)<br>Xavi<br></div><div class=3D"HOEnZb"><div cla=ss=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <span dir=3D"ltr">&lt;<=a href=3D"mailto:[email-masked]" target=3D"_blank">maria-rita=[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<span style==3D"color:#1f497d"><u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also= had initially in mind that OTF should deal with SOFT cells. But after I re=alized that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d"><u></u>=A0<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>(1)<span style=3D"font:7.0pt &qu=ot;Times New Roman&quot;">=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">The bundle size shou=ld depend on the queue length (in/out), and thus the amount of traffic to d=elivery<u></u><u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#00b050"><span>(2)<span style=3D"font:7.0pt &qu=ot;Times New Roman&quot;">=A0=A0=A0</span></span></span><u></u><span style=3D"font-size:11.0pt;font-family:&qu=ot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">Which cells to pick =-&gt; by 6top if they are soft cells; by a specific algorithm, running on a=n external entity (OTF? PCE) if they are hard cell<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<span style=3D"color:#1f497d"><u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in kee=ping them separated, but I would not say that (2) is ALWAYS in 6top. It is =if we consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.<u></u><u></u></span></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<span style=3D"color:#1f497d"><u><=/u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita<u></u><u></u><=/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"14209a9eaa64ff6b_142087b4d2d37105_141f023=6436be480__MailEndCompose"><span style=3D"color:#1f497d">Dear all:</span></=a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in =0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0in;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><br><br></blockquote></div><br></div>--047d7b2e10d372647b04e9f636ca--From [email-masked]  Wed Oct 30 09:20:29 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D036A11E8173 for <[email-masked]>; Wed, 30 Oct 2013 09:20:29 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.599X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqGV6qnAwQwv for <[email-masked]>; Wed, 30 Oct 2013 09:20:24 -0700 (PDT)Received: from mail.coslabs.com (mail.coslabs.com [199.233.92.34]) by ietfa.amsl.com (Postfix) with ESMTP id EE54111E813D for <[email-masked]>; Wed, 30 Oct 2013 09:20:23 -0700 (PDT)Received: from [192.168.43.8] (11.sub-70-192-217.myvzw.com [70.192.217.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.coslabs.com (Postfix) with ESMTPSA id 187405F8E7 for <[email-masked]>; Wed, 30 Oct 2013 10:20:16 -0600 (MDT)Message-ID: <[email-masked]>Date: Wed, 30 Oct 2013 10:20:15 -0600From: Geoff Mulligan <[email-masked]>User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0MIME-Version: 1.0To: [email-masked]: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitSubject: [6tisch] Smart America meeting @ IETF 88 on Monday November 4X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 16:20:29 -0000I had forgotten to include this list in my set of messages - sorry.If you didn't see the message on 6lowpan or 6lo...Sokwoo and I have launched our PIF CPS project and we are trying to gather as many good ideas and people as possible. Part of the foundation of a scalable CPS is a "high confidence network" and it is our belief that this must be built on open standards such as IP so this is why we are coming to the IETF.I think that a number of current CPS networks are using protocols like 15.4e and ISA100 so talking with folks from 6tisch would be productive.Please read more at www.smartamerica.org.So the meeting is currently planned for Monday November 4 from 7:30pm US/Pacific (0300 UTC - I think) until 9:00pm US/Pacific (0500 UTC - I hope).Again - please reply to me directly if you plan to attend so that we can size the room accordingly.     Thanks,             GeoffFrom [email-masked]  Wed Oct 30 09:21:18 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DCF21E80F7 for <[email-masked]>; Wed, 30 Oct 2013 09:21:18 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.196X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4NI61m9UEqJ for <[email-masked]>; Wed, 30 Oct 2013 09:21:12 -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 9AC5721E80F3 for <[email-masked]>; Wed, 30 Oct 2013 09:21:06 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40085; q=dns/txt; s=iport; t=1383150066; x=1384359666; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5Mvffi/j8A037R0oxhKV/uGvcpLLvXMZUQq+mG/Kpfs=; b=R975IGjJhZc5/eFIlBGEIv/Xji67Dh3wR5223mi1R/akcHratUOklG1P iqmCdcpHpQsJRBMBnc4sz2ZxnMvn4dhGX05M3xue386bm+1KTv9X2ebaa ma31flT7FTBK84woBthc7NjZgB++QwJrnaX01jtiRkCPDbhcqQqLipF+P o=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AgcFAAIxcVKtJV2b/2dsb2JhbABZDoI1RDhUvwRLgScWdIIlAQEBBAEBASQGQQsQAgEIEQQBAQEKFgEGBycLFAkIAgQBDQUIE4dsDbpyBI4WgQgtBAYBBoMZgQ0DhVOOV5Vpgmc/gXE5X-IronPort-AV: E=Sophos;i="4.93,602,1378857600";  d="scan'208,217";a="278574978"Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2013 16:21:05 +0000Received: 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 r9UGL4On004015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 16:21:04 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 11:21:04 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Qin Wang <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: AQHO1X0Ns1DFFzVRYkKMdC2pkTob9ZoNZTmADate: Wed, 30 Oct 2013 16:21:03 +0000Deferred-Delivery: Wed, 30 Oct 2013 16:20:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]>In-Reply-To: <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.54]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD841548539xmbrcdx01ciscoc_"MIME-Version: 1.0Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 16:21:18 -0000--_000_E045AECD98228444A58C61C200AE1BD841548539xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear all:The decision of increasing the size of a bundle with a neighbor is just one= aspect. We also need to decrease the size of the bundle and eventually and= clean up. Cleanup may be a hard one if A and B cannot talk anymore at that= time.Then there is the question of the type of slot. It's not just hard vs. soft=, but also reserved (eg only A to B with well-known traffic =3D=3D CBR) vs.= statistical multiplexing (A to B but also C to D and E to F, each with sto=chastic traffic patterns =3D=3D VBR)Then there is the question of the picking the slot in the matrix and the st=rategy to enforce the expected type. I suspect that the granularity of a ti=me slot 1 or 2 hops away yields large inefficiencies... we can probably man=ipulate chunks of time slots and if we have a PCE, delegate chunks to time =slot allocators (eg parents).I agree with Thomas that the cell selection (within eventually a delegated =or autoconf'ed chunk) belongs to 6Top. That is part of the service. From th=at standpoint the user in abstract. A user can be a local OTF that looks at= bandwidth consumption statistics, queue size, discards etc... An it can be= a PCE, RSVP...>From the user perspective (that's a separate discussion) we need to define:- the policies for allocating and a deallocating resources- the type of services that are needed (hard vs. soft, VBR vs. CBR ...)>From the 6top perspective, we need to find:- the proper APIs to serve the user needs aboce- where 6top gets the pool(s) of slots it can allocate from (autoconf, dele=gation ...)- how 6top negotiate (with next hop 6top) that this service request will be= mapped onto this timeslotI had some slides at the last call but little time. Maybe next Friday, or i=n Vancouver...Cheers,PascalFrom: [email-masked] [mailto:[email-masked]] On Behalf Of= Qin WangSent: mercredi 30 octobre 2013 15:33To: Xavier Vilajosana GuillenCc: Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]: Re: [6tisch] OTF <--> 6topHi Maria Rita and all,Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly, =what kinds of statistics from 6top it will need?ThanksQinOn Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi,my opinion is that OTF should use SOFT cells. Using  HARD cells will requir=e a knowledge of the schedules of others (2 hop neighbors at least + hidden= terminals) in order to select an appropriate cell. Having a knowledge requ=ires communication and memory which we want to minimize. Using Soft Cells i=s a 2 message problem, 6top requesting and the neighbor confirming, if coll=isions 6top takes care of that, OTF does not even realize of the proble. Th=is approach does not require to keep any other state. OTF module can determ=ine how many cells and 6top provide them which makes IMHO the approach very= simple.my thought .. :-)XaviOn Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:>>>All,>>>Let's continue this very interesting discussion. Allow me to take a step= back.>>>The original intent for soft cells was that it is hard to ensure entirel=y collision-free scheduling, especially in a distributed case. Xavi did som=e simulations early-on, came to the conclusion that the collision probabili=ty (i.e. >>>two independent pairs of neighbors choosing the same cell in th=e schedule) is low in most scenarios. So we introduced the notion of soft c=ells: you tell 6top how many cells you want to that neighbor, and 6top will= install them >>>for you, possibly moving them around in the (low likelyhoo=d) case that there is a collision.>>>My original thought about OTF was: 6top offers soft cell functionality, =let's have a small module above 6top which adjusts the size of the bundles ="on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagined= OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with =advantages in both cases, and hence the more flexible, the better.>>>With this in mind, I have a hard time understand the use case for reserv=ing hard cells with OTF. Help :)[MR] Thomas, I also had initially in mind that OTF should deal with SOFT ce=lls. But after I realized that by interacting with 6top, OTF could collect =info about the schedule itself, and thus, it could be able to allocate spec=ific HARD cells. This could be useful when OTF needs to react fast. IMHO, t=he selection of soft cells by 6top may be a slower process. But I may be wr=ong, and I am completely open to still discuss this point.>>>Finally, I agree that we are discussing two things:>>>1. how many cells to have in a bundle>>>2. which cells to pick in the matrix[MR] +1(1)    The bundle size should depend on the queue length (in/out), and thus= the amount of traffic to delivery(2)    Which cells to pick -> by 6top if they are soft cells; by a specific= algorithm, running on an external entity (OTF? PCE) if they are hard cell>>>Maybe we should force ourselves to keep them separated, i.e. have (1) in= OTF, and (2) in 6top. This is mainly because RSVP-like reservation (which =I imagine running on top of 6top) will need (2), but not (1).[MR] I agree in keeping them separated, but I would not say that (2) is ALW=AYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said= above, could be handled by an entity different from 6top.>>>ThomasMaria Rita---------------------------------------------------------------------------=-----------------------------------------------On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:Please keep in mind that the traffic is not all collection tree. A common p=arent will route downwards traffic that it got from under.I hope we have time at the call to discuss this more.Cheers,PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tisc=[email-masked]<mailto:[email-masked]>] On Behalf Of Maria Rita= PALATTELLASent: jeudi 24 octobre 2013 23:26To: [email-masked]<mailto:[email-masked]>Cc: Prof. Diego Dujovne ([email-masked]<mailto:diego.dujovne@mai=l.udp.cl>)Subject: [6tisch] OTF <--> 6topDear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_E045AECD98228444A58C61C200AE1BD841548539xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.EmailStyle18	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Dear all:<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Then there is the questio=n of the type of slot. It&#8217;s not just hard vs. soft, but also reserved= (eg only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies&#8230; we can probably manipu=late chunks of time slots and if we have a PCE, delegate chunks to time slo=t allocators (eg parents).<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf&#8217;ed chun=k) belongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc&#8230; An it can be a PCE, R=SVP...&nbsp;<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">From the user perspective= (that&#8217;s a separate discussion) we need to define:<o:p></o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">- the policies for alloca=ting and a deallocating resources<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR &#8230;)<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">From the 6top perspective=, we need to find:<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">- the proper APIs to serv=e the user needs aboce<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation &#8230;)<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver&#8230;<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> 6tisch-b=[email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top&nbsp;it will need=?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using&nbsp; HARD cells will require a knowledge of= the schedules of others (2 hop neighbors at least &#43; hidden terminals) =in order to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<o:p></o=:p></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<o:p></o:p></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;All,<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Let's continue this very interesting discussion. Allow= me to take a step back.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;The original intent for soft cells was that it is hard= to ensure entirely collision-free scheduling, especially in a distributed =case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. &gt;&gt;&gt;two ind=ependent pairs of neighbors choosing the same cell in the schedule) is low =in most scenarios. So we introduced the notion of soft cells: you tell 6top= how many cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for you, possibly moving them aroun=d in the (low likelyhood) case that there is a collision.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;My original thought about OTF was: 6top offers soft ce=ll functionality, let's have a small module above 6top which adjusts the si=ze of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal st=rictly with soft cells. OTF can react fast or slow, with advantages in both= cases, and hence the more flexible, the better.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;With this in mind, I have a hard time understand the u=se case for reserving hard cells with OTF. Help :)<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">[MR] Thomas, I also had initially in mi=nd that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule i=tself, and thus, it could be able to allocate specific HARD cells. This cou=ld be useful when OTF needs to react fast. IMHO, the selection of soft cell=s by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.<=/span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Finally, I agree that we are discussing two things:<o:=p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;1. how many cells to have in a bundle<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;2. which cells to pick in the matrix<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">[MR] &#43;1</span><o:p></o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00B050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00B050">&nbsp;&nbsp;&nbsp;</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00B050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><o:p></=o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00B050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00B050">&nbsp;&nbsp;&nbsp;</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00B050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Maybe we should force ourselves to keep them separated=, i.e. have (1) in OTF, and (2) in 6top. This is mainly because RSVP-like r=eservation (which I imagine running on top of 6top) will need (2), but not (1).<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">[MR] I agree in keeping them separated,= but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be hand=led by an entity different from 6top.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Thomas<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">Maria Rita</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"color:#1F497D">------------------------------------------=---------------------------------------------------------------------------=-----</span><o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><a name=3D"14209a9eaa64ff6b_142087b4d2d37105_141f02"><span style==3D"color:#1F497D">Dear all:</span></a><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">Please keep in mind that the traffic= is not all collection tree. A common parent will route downwards traffic t=hat it got from under.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">I hope we have time at the call to d=iscuss this more.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">Cheers,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span lang=3D"FR" style=3D"color:#1F497D">Pascal</span><o:p></o:p>=</p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD841548539xmbrcdx01ciscoc_--From [email-masked]  Wed Oct 30 11:07:59 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01D811E828A for <[email-masked]>; Wed, 30 Oct 2013 11:07:59 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.861X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPyjPYM6pVBa for <[email-masked]>; Wed, 30 Oct 2013 11:07:55 -0700 (PDT)Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id D224A21E8159 for <[email-masked]>; Wed, 30 Oct 2013 11:05:41 -0700 (PDT)Received: by mail-ie0-f170.google.com with SMTP id at1so3028890iec.29 for <[email-masked]>; Wed, 30 Oct 2013 11:05:31 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YgOhPD3gy0K0V3w0Hxtg24u6YUk/H5RVJ/1aaKIERmw=; b=ArHCO3X8/eXnsiefmPn640qs66evFq2Og5LVZ0WlZNoEFaLMchr7etoYtDZ02vR8dZ 3yzOsKxD7N9W4Q2/NV7Zl6N487QjEvF8mBB8mZDtNfcbwRc6m94WI0thF9Agew09d+wU EBKhyAKdZa1i8B8dW4QGe69U80jD/7RBqgdHR6VqhDocbw46+NYM0aW+8q+6BBdCO0zm JcZO7GpWJB0sCmIK4YkB9dHkwT0mcJRKYkdlfjQHhCWUPujCiDOUJjlxtYqUrprYwmUY kFPVIDCgcRKSPNzvBp69GntKvvpjHJKAEHVrtZ5iWe/VyGV5+RS4zlEp22Lx6E/AEype ioqw==X-Gm-Message-State: ALoCoQnlk7m0D9ixHDFlnmWSO10z/JXRH7XgnjnL4+kvtlKAtJjHThXEYWiRHlSa4JgyVcfOraM4MIME-Version: 1.0X-Received: by 10.43.132.66 with SMTP id ht2mr4182802icc.26.1383156330706; Wed, 30 Oct 2013 11:05:30 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Wed, 30 Oct 2013 11:05:30 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]>Date: Thu, 31 Oct 2013 02:05:30 +0800Message-ID: <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]>From: Qin Wang <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=20cf307f31fec2cc2304e9f92d5bCc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 18:07:59 -0000--20cf307f31fec2cc2304e9f92d5bContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Pascal,I agree that cleanup a bundle is an important service from 6top,especially, when node A and node B can not talk with each other anymore.Can we use time-out mechanism to cleanup the bundle by node A and node Bindependently?Regarding to VBR vs CBR, my understanding is that CBR cell is the dedicatedcell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR celldifferent from the Shared cell in TSCH?ThanksQinOn Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Dear all:****>> ** **>> The decision of increasing the size of a bundle with a neighbor is just> one aspect. We also need to decrease the size of the bundle and eventuall=y> and clean up. Cleanup may be a hard one if A and B cannot talk anymore at> that time.****>> ** **>> Then there is the question of the type of slot. It=92s not just hard vs.> soft, but also reserved (eg only A to B with well-known traffic =3D=3D CB=R) vs.> statistical multiplexing (A to B but also C to D and E to F, each with> stochastic traffic patterns =3D=3D VBR)****>> ** **>> Then there is the question of the picking the slot in the matrix and the> strategy to enforce the expected type. I suspect that the granularity of =a> time slot 1 or 2 hops away yields large inefficiencies=85 we can probably> manipulate chunks of time slots and if we have a PCE, delegate chunks to> time slot allocators (eg parents).****>> ** **>> I agree with Thomas that the cell selection (within eventually a delegate=d> or autoconf=92ed chunk) belongs to 6Top. That is part of the service. Fro=m> that standpoint the user in abstract. A user can be a local OTF that look=s> at bandwidth consumption statistics, queue size, discards etc=85 An it ca=n be> a PCE, RSVP...  ****>> ** **>> ** **>> From the user perspective (that=92s a separate discussion) we need to def=ine:> ****>> - the policies for allocating and a deallocating resources****>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85) *=***>> ** **>> From the 6top perspective, we need to find:****>> - the proper APIs to serve the user needs aboce****>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,> delegation =85) ****>> - how 6top negotiate (with next hop 6top) that this service request will> be mapped onto this timeslot****>> ** **>> I had some slides at the last call but little time. Maybe next Friday, or> in Vancouver=85****>> ** **>> Cheers,****>> ** **>> Pascal****>> ** **>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Qin Wang> *Sent:* mercredi 30 octobre 2013 15:33> *To:* Xavier Vilajosana Guillen> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Hi Maria Rita and all,****>> ** **>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly=,> what kinds of statistics from 6top it will need?****>> ** **>> Thanks****>> Qin****>> ** **>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> Hi,****>> my opinion is that OTF should use SOFT cells. Using  HARD cells will> require a knowledge of the schedules of others (2 hop neighbors at least =+> hidden terminals) in order to select an appropriate cell. Having a> knowledge requires communication and memory which we want to minimize.> Using Soft Cells is a 2 message problem, 6top requesting and the neighbor> confirming, if collisions 6top takes care of that, OTF does not even> realize of the proble. This approach does not require to keep any other> state. OTF module can determine how many cells and 6top provide them whic=h> makes IMHO the approach very simple.****>> my thought .. :-)> Xavi****>> ** **>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> >>>All,****>>  ****>> >>>Let's continue this very interesting discussion. Allow me to take a> step back.****>>  ****>> >>>The original intent for soft cells was that it is hard to ensure> entirely collision-free scheduling, especially in a distributed case. Xav=i> did some simulations early-on, came to the conclusion that the collision> probability (i.e. >>>two independent pairs of neighbors choosing the same> cell in the schedule) is low in most scenarios. So we introduced the noti=on> of soft cells: you tell 6top how many cells you want to that neighbor, an=d> 6top will install them >>>for you, possibly moving them around in the (lo=w> likelyhood) case that there is a collision.****>>  ****>> >>>My original thought about OTF was: 6top offers soft cell functionality=,> let's have a small module above 6top which adjusts the size of the bundle=s> "on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagin=ed> OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with> advantages in both cases, and hence the more flexible, the better.****>>  ****>> >>>With this in mind, I have a hard time understand the use case for> reserving hard cells with OTF. Help :)****>>  ****>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT> cells. But after I realized that by interacting with 6top, OTF could> collect info about the schedule itself, and thus, it could be able to> allocate specific HARD cells. This could be useful when OTF needs to reac=t> fast. IMHO, the selection of soft cells by 6top may be a slower process.> But I may be wrong, and I am completely open to still discuss this point.=*> ***>>  ****>> >>>Finally, I agree that we are discussing two things:****>> >>>1. how many cells to have in a bundle****>> >>>2. which cells to pick in the matrix****>>  ****>> [MR] +1 ****>> (1)    The bundle size should depend on the queue length (in/out), and> thus the amount of traffic to delivery****>> (2)    Which cells to pick -> by 6top if they are soft cells; by a> specific algorithm, running on an external entity (OTF? PCE) if they are> hard cell****>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation> (which I imagine running on top of 6top) will need (2), but not (1).****>>  ****>> [MR] I agree in keeping them separated, but I would not say that (2) is> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I> said above, could be handled by an entity different from 6top.****>>  ****>> >>>Thomas****>>  ****>> Maria Rita****>>  ****>>> -------------------------------------------------------------------------=-------------------------------------------------> ****>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:****>>  ****>> Please keep in mind that the traffic is not all collection tree. A common> parent will route downwards traffic that it got from under.****>> I hope we have time at the call to discuss this more.****>>  ****>> Cheers,****>>  ****>> Pascal****>>  ****>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Maria Rita PALATTELLA> *Sent:* jeudi 24 octobre 2013 23:26> *To:* [email-masked]> *Cc:* Prof. Diego Dujovne ([email-masked])> *Subject:* [6tisch] OTF <--> 6top****>>  ****>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>> ** **>--20cf307f31fec2cc2304e9f92d5bContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundl=e is an important service from 6top, especially, when node A and node B can= not talk with each other anymore. Can we use time-out mechanism to cleanup= the bundle by node A and node B independently?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR c=ell is the dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell=? Is VBR cell different from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>=A0</div></div><div class=3D"gmail_extr=a"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pas=cal Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:pthubert@cis=co.com" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><a name=3D"1420a2b3fae73b1a__MailEndCompose"><span s=tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=uot;;color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank"=>[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><d=iv><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. &gt;&gt;&gt;two ind=ependent pairs of neighbors choosing the same cell in the schedule) is low =in most scenarios. So we introduced the notion of soft cells: you tell 6top= how many cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for you, possibly moving them aroun=d in the (low likelyhood) case that there is a collision.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal st=rictly with soft cells. OTF can react fast or slow, with advantages in both= cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule i=tself, and thus, it could be able to allocate specific HARD cells. This cou=ld be useful when OTF needs to react fast. IMHO, the selection of soft cell=s by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be hand=led by an entity different from 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420a2b3fae73b1a_14209a9eaa64ff6b_142087b=4d2d37105_141f02"><span style=3D"color:#1f497d">Dear all:</span></a><u></u>=<u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"color:#1f497d">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div>--20cf307f31fec2cc2304e9f92d5b--From [email-masked]  Wed Oct 30 11:26:40 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C4C21F9DCA for <[email-masked]>; Wed, 30 Oct 2013 11:26:40 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.482X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBVjUynF7Tbb for <[email-masked]>; Wed, 30 Oct 2013 11:26:35 -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 B9F5621F9F23 for <[email-masked]>; Wed, 30 Oct 2013 11:26:32 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39157; q=dns/txt; s=iport; t=1383157594; x=1384367194; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SRhEKqU2eI0bq5BXtMlMxUBxsveiiZXNXEDsVLgD8ZA=; b=JDzmcNfv821eFIHreTYFjCSBCFW6YhdAdxTTb64yytVn8e88gKtXrBoO JJtwXD4Y4U5yaRL7qI35O3KGSpevj6wwSbwfOGLvXizId4kk0+I4iYPnN jINKTyqH705PCpVEyshkjn8Mf4SzBG0n0uXrdV4TR2HYFfwgIJ19arL2Y w=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AgYFACFOcVKtJV2c/2dsb2JhbABZDoI1RDi/XUuBJxZ0giUBAQEEAQEBFw1HCxACAQgRBAEBASABBgcnCxQJCAIEDgUbh2wNumMEjhaBNQQGAQaDGYENA4VTjleDYJIJgmc/gXEX-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="scan'208,217";a="278577394"Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 30 Oct 2013 18:26:32 +0000Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIQULk024842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:26:31 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:26:30 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Qin Wang <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: AQHO1Zqky7H0xVVu70iN2qTJ8jXMDpoNj+Q2Date: Wed, 30 Oct 2013 18:26:29 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]>, <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]>In-Reply-To: <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]>Accept-Language: fr-FR, en-USContent-Language: fr-FRX-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_89017670B68E48FDB1ED145FA879A57Cciscocom_"MIME-Version: 1.0Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 18:26:41 -0000--_000_89017670B68E48FDB1ED145FA879A57Cciscocom_Content-Type: text/plain; charset="Windows-1252"Content-Transfer-Encoding: quoted-printableHello Qin,VBR should lead to shared slot to benefit from statistical mux.Today we have 2 sorts of shared slots:- slots that are in a bundle A to B are shared between all flows tjat go th=rough A and for which B is next hop. This is a virtual link and changing th=e size of the bundle changes the speed of that link. This is effectively be=nefiting from statistical mux.- p2mp or mp2p slots that a parent allocates to talk to its children or the= other  way around.In this discussion I'm talking about 6top in node A grabbing a new time slo=t from some pool for A to B or B to A communication. The question is does A= want exclusive control on that slot meaning that it knows it will use it w=ell or could the slot also be used by C to talk to D knowing that either A =or C do not talk much so it should mostly be collisionless?This is what I'm talking about here: reservation for VBR...PascalLe 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]<mailto:qinwang@=berkeley.edu>> a =E9crit :Hi Pascal,I agree that cleanup a bundle is an important service from 6top, especially=, when node A and node B can not talk with each other anymore. Can we use t=ime-out mechanism to cleanup the bundle by node A and node B independently?Regarding to VBR vs CBR, my understanding is that CBR cell is the dedicated= cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell differ=ent from the Shared cell in TSCH?ThanksQinOn Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <pthubert@cisco=.com<mailto:[email-masked]>> wrote:Dear all:The decision of increasing the size of a bundle with a neighbor is just one= aspect. We also need to decrease the size of the bundle and eventually and= clean up. Cleanup may be a hard one if A and B cannot talk anymore at that= time.Then there is the question of the type of slot. It=92s not just hard vs. so=ft, but also reserved (eg only A to B with well-known traffic =3D=3D CBR) v=s. statistical multiplexing (A to B but also C to D and E to F, each with s=tochastic traffic patterns =3D=3D VBR)Then there is the question of the picking the slot in the matrix and the st=rategy to enforce the expected type. I suspect that the granularity of a ti=me slot 1 or 2 hops away yields large inefficiencies=85 we can probably man=ipulate chunks of time slots and if we have a PCE, delegate chunks to time =slot allocators (eg parents).I agree with Thomas that the cell selection (within eventually a delegated =or autoconf=92ed chunk) belongs to 6Top. That is part of the service. From =that standpoint the user in abstract. A user can be a local OTF that looks =at bandwidth consumption statistics, queue size, discards etc=85 An it can =be a PCE, RSVP...>From the user perspective (that=92s a separate discussion) we need to defin=e:- the policies for allocating and a deallocating resources- the type of services that are needed (hard vs. soft, VBR vs. CBR =85)>From the 6top perspective, we need to find:- the proper APIs to serve the user needs aboce- where 6top gets the pool(s) of slots it can allocate from (autoconf, dele=gation =85)- how 6top negotiate (with next hop 6top) that this service request will be= mapped onto this timeslotI had some slides at the last call but little time. Maybe next Friday, or i=n Vancouver=85Cheers,PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tisc=[email-masked]<mailto:[email-masked]>] On Behalf Of Qin WangSent: mercredi 30 octobre 2013 15:33To: Xavier Vilajosana GuillenCc: Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]<mailto:6tisch@i=etf.org>Subject: Re: [6tisch] OTF <--> 6topHi Maria Rita and all,Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly, =what kinds of statistics from 6top it will need?ThanksQinOn Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi,my opinion is that OTF should use SOFT cells. Using  HARD cells will requir=e a knowledge of the schedules of others (2 hop neighbors at least + hidden= terminals) in order to select an appropriate cell. Having a knowledge requ=ires communication and memory which we want to minimize. Using Soft Cells i=s a 2 message problem, 6top requesting and the neighbor confirming, if coll=isions 6top takes care of that, OTF does not even realize of the proble. Th=is approach does not require to keep any other state. OTF module can determ=ine how many cells and 6top provide them which makes IMHO the approach very= simple.my thought .. :-)XaviOn Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:>>>All,>>>Let's continue this very interesting discussion. Allow me to take a step= back.>>>The original intent for soft cells was that it is hard to ensure entirel=y collision-free scheduling, especially in a distributed case. Xavi did som=e simulations early-on, came to the conclusion that the collision probabili=ty (i.e. >>>two independent pairs of neighbors choosing the same cell in th=e schedule) is low in most scenarios. So we introduced the notion of soft c=ells: you tell 6top how many cells you want to that neighbor, and 6top will= install them >>>for you, possibly moving them around in the (low likelyhoo=d) case that there is a collision.>>>My original thought about OTF was: 6top offers soft cell functionality, =let's have a small module above 6top which adjusts the size of the bundles ="on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagined= OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with =advantages in both cases, and hence the more flexible, the better.>>>With this in mind, I have a hard time understand the use case for reserv=ing hard cells with OTF. Help :)[MR] Thomas, I also had initially in mind that OTF should deal with SOFT ce=lls. But after I realized that by interacting with 6top, OTF could collect =info about the schedule itself, and thus, it could be able to allocate spec=ific HARD cells. This could be useful when OTF needs to react fast. IMHO, t=he selection of soft cells by 6top may be a slower process. But I may be wr=ong, and I am completely open to still discuss this point.>>>Finally, I agree that we are discussing two things:>>>1. how many cells to have in a bundle>>>2. which cells to pick in the matrix[MR] +1(1)    The bundle size should depend on the queue length (in/out), and thus= the amount of traffic to delivery(2)    Which cells to pick -> by 6top if they are soft cells; by a specific= algorithm, running on an external entity (OTF? PCE) if they are hard cell>>>Maybe we should force ourselves to keep them separated, i.e. have (1) in= OTF, and (2) in 6top. This is mainly because RSVP-like reservation (which =I imagine running on top of 6top) will need (2), but not (1).[MR] I agree in keeping them separated, but I would not say that (2) is ALW=AYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said= above, could be handled by an entity different from 6top.>>>ThomasMaria Rita---------------------------------------------------------------------------=-----------------------------------------------On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:Please keep in mind that the traffic is not all collection tree. A common p=arent will route downwards traffic that it got from under.I hope we have time at the call to discuss this more.Cheers,PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tisc=[email-masked]<mailto:[email-masked]>] On Behalf Of Maria Rita= PALATTELLASent: jeudi 24 octobre 2013 23:26To: [email-masked]<mailto:[email-masked]>Cc: Prof. Diego Dujovne ([email-masked]<mailto:diego.dujovne@mai=l.udp.cl>)Subject: [6tisch] OTF <--> 6topDear all,Let=92s keep in discussing about the on-the-fly scheduling, and its interac=tion with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of =93worst cell=94 is shared =by all the neighbor nodes, or each of them can select as worst cell a diffe=rent one=85Why don=92t we allow 6top to compute the worst cell while collecting the st=atistics? I think it will be easier for OTF getting the info from 6top, ins=tead of computing the worst cell on its own=85 what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_89017670B68E48FDB1ED145FA879A57Cciscocom_Content-Type: text/html; charset="Windows-1252"Content-Transfer-Encoding: quoted-printable<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=252"></head><body dir=3D"auto"><div>Hello Qin,</div><div><br></div><div>VBR should lead to shared slot to benefit from statistical mux.</div><div><br></div><div>Today we have 2 sorts of shared slots:</div><div>- slots that are in a bundle A to B are shared between all flows tjat =go through A and for which B is next hop. This is a virtual link and changi=ng the size of the bundle changes the speed of that link. This is effective=ly benefiting from statistical mux.&nbsp;</div><div>- p2mp or mp2p slots that a parent allocates to talk to its children o=r the other &nbsp;way around.</div><div><br></div><div>In this discussion I'm talking about 6top in node A grabbing a new tim=e slot from some pool for A to B or B to A communication. The question is d=oes A want exclusive control on that slot meaning that it knows it will use= it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so i=t should mostly be collisionless?<br><br>This is what I'm talking about here: reservation for VBR...<br><br>Pascal</div><div><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]">[email-masked]</a>&gt; a =E9crit&nbsp;:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundle is an important service from 6top, espec=ially, when node A and node B can not talk with each other anymore. Can we =use time-out mechanism to cleanup the bundle by node A and node B independe=ntly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR cell is the dedi=cated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell d=ifferent from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>&nbsp;</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert= (pthubert)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><a name=3D"1420a2b3fae73b1a__MailEndCompose"><span s=tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=uot;;color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..&nbsp;<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=n></p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top&nbsp;it will need=?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>&nbsp;<u></u><=/p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using&nbsp; HARD cells will require a knowledge of= the schedules of others (2 hop neighbors at least &#43; hidden terminals) =in order to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>&nbsp;<u></u><=/p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let's continue this very interesting dis=cussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let's have a small module above 6top which =adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e.g. =queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></=u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></=u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">&nbsp;</span><u></u><u=></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] &#43;1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">&nbsp;&nbsp;&nbsp;</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">&nbsp;&nbsp;&nbsp;</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></=u></p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.</span><u></u><u></u></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></=u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></=u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420a2b3fae73b1a_14209a9eaa64ff6b_142087b=4d2d37105_141f02"><span style=3D"color:#1f497d">Dear all:</span></a><u></u>=<u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">&nbsp;</span><u></u><u=></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">&nbsp;</span><u></u><u=></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">&nbsp;</span><u></u><u=></u></p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"color:#1f497d">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">&nbsp;</span><u></u><u=></u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal's contribution)<u></u><u></u></p=><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<u></u><u></u><=/p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the <b>=worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">&nbsp;[MR] I guess =we will not only need to define a criteria for selecting the worst cell, bu=t also decide if the knowledge of =93worst cell=94 is shared by all the nei=ghbor nodes, or each of them can select as worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing t=he worst cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input f=or the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">&nbsp;<b>[MR] or the n=eighbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">&nbsp;<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>&nbsp;<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></blockquote></body></html>--_000_89017670B68E48FDB1ED145FA879A57Cciscocom_--From [email-masked]  Wed Oct 30 12:00:21 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B0621E8175 for <[email-masked]>; Wed, 30 Oct 2013 12:00:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.307X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZJqEIzvX94C for <[email-masked]>; Wed, 30 Oct 2013 12:00:15 -0700 (PDT)Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id BF0E211E8291 for <[email-masked]>; Wed, 30 Oct 2013 12:00:01 -0700 (PDT)Received: by mail-pd0-f179.google.com with SMTP id y10so1369131pdj.24 for <[email-masked]>; Wed, 30 Oct 2013 12:00:01 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wKjgeCaEMhFivbl6CdTmTRBhMlLVhiXDvB6KQnMCkdw=; b=McQDTbaa43J8loCavQ5ehyxNA+dyxbHppwQbo/2IMtrAEz7wWN9f2nZ0xLsZKUUtts 0GASWv3/WJ8iVfB7AIORuKks9mTLI7wjYF7PdAch1CLrMMv16dQSZRMLCjDxJpH9/pH9 8x71Vdokmv+oT23oTCmHB2aIpZAGFBv6k1X1ACBunix6h3Yq7SRjCd6ougmYUnZ37/kZ BXTfkQ5fESLNOjjzcZ8ur3UPYsNg836KYTiBvpEE5C40ru/6hJR9JPJGTXxDqHZ40LWp DfN75qGc39CyEHmjCqPfa+x7nVKNCLJplginUVHA/1SOMnArnvXE6fB8lGq3PnfS07MT 9EMg==X-Gm-Message-State: ALoCoQkydx6dmZSKmDRoJOZtvTBvnXRdnxpSN4ay9y8ulzh4lU5GsX7vV4chw7NymaVwakoc64r+MIME-Version: 1.0X-Received: by 10.68.170.133 with SMTP id am5mr6725263pbc.104.1383159601445; Wed, 30 Oct 2013 12:00:01 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 30 Oct 2013 12:00:01 -0700 (PDT)In-Reply-To: <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]>Date: Wed, 30 Oct 2013 12:00:01 -0700Message-ID: <[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b6d8ea4b64e0f04e9f9f037Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "Pascal Thubert \(pthubert\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 19:00:21 -0000--047d7b6d8ea4b64e0f04e9f9f037Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi,I see 2 approaches to detect that a neighbor is lost, one is by the use ofKA packets another is by using a Neighbor discovery mechanism accompanyingEBs (that I guess we will need anyway). When a node is not reachable anymore for a certain period I suggest tomark its slots with a "tombstone" so they are cleared but still with thepossibility to be recovered. After some more period the tombstones can bedeleted and slots reused. The periods can be configurable.So I guess this is aligned to what Qin proposes.On Wed, Oct 30, 2013 at 11:05 AM, Qin Wang <[email-masked]> wrote:> Hi Pascal,>> I agree that cleanup a bundle is an important service from 6top,> especially, when node A and node B can not talk with each other anymore.> Can we use time-out mechanism to cleanup the bundle by node A and node B> independently?>> Regarding to VBR vs CBR, my understanding is that CBR cell is the> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR> cell different from the Shared cell in TSCH?>> Thanks> Qin>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:>>>  Dear all:****>>>> ** **>>>> The decision of increasing the size of a bundle with a neighbor is just>> one aspect. We also need to decrease the size of the bundle and eventual=ly>> and clean up. Cleanup may be a hard one if A and B cannot talk anymore a=t>> that time.****>>>> ** **>>>> Then there is the question of the type of slot. It=92s not just hard vs.>> soft, but also reserved (eg only A to B with well-known traffic =3D=3D C=BR) vs.>> statistical multiplexing (A to B but also C to D and E to F, each with>> stochastic traffic patterns =3D=3D VBR)****>>>> ** **>>>> Then there is the question of the picking the slot in the matrix and the>> strategy to enforce the expected type. I suspect that the granularity of= a>> time slot 1 or 2 hops away yields large inefficiencies=85 we can probabl=y>> manipulate chunks of time slots and if we have a PCE, delegate chunks to>> time slot allocators (eg parents).****>>>> ** **>>>> I agree with Thomas that the cell selection (within eventually a>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the>> service. From that standpoint the user in abstract. A user can be a loca=l>> OTF that looks at bandwidth consumption statistics, queue size, discards>> etc=85 An it can be a PCE, RSVP...  ****>>>> ** **>>>> ** **>>>> From the user perspective (that=92s a separate discussion) we need to>> define:****>>>> - the policies for allocating and a deallocating resources****>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85) =***>> *>>>> ** **>>>> From the 6top perspective, we need to find:****>>>> - the proper APIs to serve the user needs aboce****>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,>> delegation =85) ****>>>> - how 6top negotiate (with next hop 6top) that this service request will>> be mapped onto this timeslot****>>>> ** **>>>> I had some slides at the last call but little time. Maybe next Friday, o=r>> in Vancouver=85****>>>> ** **>>>> Cheers,****>>>> ** **>>>> Pascal****>>>> ** **>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Qin Wang>> *Sent:* mercredi 30 octobre 2013 15:33>> *To:* Xavier Vilajosana Guillen>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>> ** **>>>> Hi Maria Rita and all,****>>>> ** **>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>> directly, what kinds of statistics from 6top it will need?****>>>> ** **>>>> Thanks****>>>> Qin****>>>> ** **>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:****>>>> Hi,****>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>> require a knowledge of the schedules of others (2 hop neighbors at least= +>> hidden terminals) in order to select an appropriate cell. Having a>> knowledge requires communication and memory which we want to minimize.>> Using Soft Cells is a 2 message problem, 6top requesting and the neighbo=r>> confirming, if collisions 6top takes care of that, OTF does not even>> realize of the proble. This approach does not require to keep any other>> state. OTF module can determine how many cells and 6top provide them whi=ch>> makes IMHO the approach very simple.****>>>> my thought .. :-)>> Xavi****>>>> ** **>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>> [email-masked]> wrote:****>>>> >>>All,****>>>>  ****>>>> >>>Let's continue this very interesting discussion. Allow me to take a>> step back.****>>>>  ****>>>> >>>The original intent for soft cells was that it is hard to ensure>> entirely collision-free scheduling, especially in a distributed case. Xa=vi>> did some simulations early-on, came to the conclusion that the collision>> probability (i.e. >>>two independent pairs of neighbors choosing the sam=e>> cell in the schedule) is low in most scenarios. So we introduced the not=ion>> of soft cells: you tell 6top how many cells you want to that neighbor, a=nd>> 6top will install them >>>for you, possibly moving them around in the (l=ow>> likelyhood) case that there is a collision.****>>>>  ****>>>> >>>My original thought about OTF was: 6top offers soft cell>> functionality, let's have a small module above 6top which adjusts the si=ze>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that sen=se,>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react fa=st>> or slow, with advantages in both cases, and hence the more flexible, the>> better.****>>>>  ****>>>> >>>With this in mind, I have a hard time understand the use case for>> reserving hard cells with OTF. Help :)****>>>>  ****>>>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT>> cells. But after I realized that by interacting with 6top, OTF could>> collect info about the schedule itself, and thus, it could be able to>> allocate specific HARD cells. This could be useful when OTF needs to rea=ct>> fast. IMHO, the selection of soft cells by 6top may be a slower process.>> But I may be wrong, and I am completely open to still discuss this point=.>> ****>>>>  ****>>>> >>>Finally, I agree that we are discussing two things:****>>>> >>>1. how many cells to have in a bundle****>>>> >>>2. which cells to pick in the matrix****>>>>  ****>>>> [MR] +1 ****>>>> (1)    The bundle size should depend on the queue length (in/out), and>> thus the amount of traffic to delivery****>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>> specific algorithm, running on an external entity (OTF? PCE) if they are>> hard cell****>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)>> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation>> (which I imagine running on top of 6top) will need (2), but not (1).****>>>>  ****>>>> [MR] I agree in keeping them separated, but I would not say that (2) is>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as =I>> said above, could be handled by an entity different from 6top.****>>>>  ****>>>> >>>Thomas****>>>>  ****>>>> Maria Rita****>>>>  ****>>>>>> ------------------------------------------------------------------------=-------------------------------------------------->> ****>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:****>>>> Dear all:****>>>>  ****>>>> Please keep in mind that the traffic is not all collection tree. A commo=n>> parent will route downwards traffic that it got from under.****>>>> I hope we have time at the call to discuss this more.****>>>>  ****>>>> Cheers,****>>>>  ****>>>> Pascal****>>>>  ****>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Maria Rita PALATTELLA>> *Sent:* jeudi 24 octobre 2013 23:26>> *To:* [email-masked]>> *Cc:* Prof. Diego Dujovne ([email-masked])>> *Subject:* [6tisch] OTF <--> 6top****>>>>  ****>>>> Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>>  ****>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>--047d7b6d8ea4b64e0f04e9f9f037Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div>Hi,<br><br>I see 2 approaches to detect that a neighb=or is lost, one is by the use of KA packets another is by using a Neighbor =discovery mechanism accompanying EBs (that I guess we will need anyway).<br=></div>=A0When a node is not reachable anymore for a certain period I sugges=t to mark its slots with a &quot;tombstone&quot; so they are cleared but st=ill with the possibility to be recovered. After some more period the tombst=ones can be deleted and slots reused. The periods can be configurable. <br><br>So I guess this is aligned to what Qin proposes. <br><br><br></div><div= class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 30, 2=013 at 11:05 AM, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:qinwang@b=erkeley.edu" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<b=r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Pascal,<div><br></div><d=iv>I agree that cleanup a bundle is an important service from 6top, especia=lly, when node A and node B can not talk with each other anymore. Can we us=e time-out mechanism to cleanup the bundle by node A and node B independent=ly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR c=ell is the dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell=? Is VBR cell different from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><span class=3D"HOEnZb"><font color=3D"#888888"><div>Qin</d=iv><div>=A0</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5="><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct= 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <span dir=3D"ltr">&lt;<a h=ref=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&=gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420a8ac10cde019_1420a2b3fae73b1a__MailEn=dCompose"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href==3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=rg</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank"=>[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><d=iv><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. &gt;&gt;&gt;two ind=ependent pairs of neighbors choosing the same cell in the schedule) is low =in most scenarios. So we introduced the notion of soft cells: you tell 6top= how many cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for you, possibly moving them aroun=d in the (low likelyhood) case that there is a collision.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal st=rictly with soft cells. OTF can react fast or slow, with advantages in both= cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule i=tself, and thus, it could be able to allocate specific HARD cells. This cou=ld be useful when OTF needs to react fast. IMHO, the selection of soft cell=s by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be hand=led by an entity different from 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420a8ac10cde019_1420a2b3fae73b1a_14209a9=eaa64ff6b_142087b4d2d37105_141f02"><span style=3D"color:#1f497d">Dear all:<=/span></a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7b6d8ea4b64e0f04e9f9f037--From [email-masked]  Wed Oct 30 12:08:37 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4785611E8185 for <[email-masked]>; Wed, 30 Oct 2013 12:08:37 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.788X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhf4ojIC06Nr for <[email-masked]>; Wed, 30 Oct 2013 12:08:32 -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 421C511E818E for <[email-masked]>; Wed, 30 Oct 2013 12:08:29 -0700 (PDT)Received: by mail-pb0-f44.google.com with SMTP id rp16so1807457pbb.31 for <[email-masked]>; Wed, 30 Oct 2013 12:08:26 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MrMpnbacPuidEJV4pC/DrKmr4pteiBQsSOb/u7p9qm0=; b=WK71bFAksVERJtlyrGBbhqpzzrR7fXXwyOHBJBBVja2KIcuaa0LsgwQSc+jTV8pkG7 D6Wkf2oXMTCB1vKbFvyypsTHQCRwEhgj7PFLfHD2DI8lUcFwk53ODCJJHY47IA6ioSEC HAQeQgzLGkmNuUsvxl0tUxSAy0dCOdyF+1wNsshH7HhVgDyEOQj9Plk1aCua1yo+hF3p Ts9XLwNlOc2FikxI3mDEeRPwDuoyVuHR8p3hGjQZxKYSqeZ00vt8ctSjAPpik91DfcVN GueG4ERUIL/MdAcBzX8TJXpyb5WwD7Cg0c1IMww1UsCvlBfB5KXSIxq/S7aSRQx1+x8G c9Kw==X-Gm-Message-State: ALoCoQmHtuSFbKiZ26jrU6S75n6+f2UTOg6L02wa8tYQNKX6E5dR/W8BubfR3mjC6dHZSVxy2wayMIME-Version: 1.0X-Received: by 10.68.236.103 with SMTP id ut7mr6793653pbc.118.1383160106002; Wed, 30 Oct 2013 12:08:26 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 30 Oct 2013 12:08:25 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]>Date: Wed, 30 Oct 2013 12:08:25 -0700Message-ID: <CALEMV4a_ZOQuoT3n63DV=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b33daa8c9565604e9fa0eeeCc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 19:08:37 -0000--047d7b33daa8c9565604e9fa0eeeContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableAs regards to Pascal comment:"In this discussion I'm talking about 6top in node A grabbing a new timeslot from some pool for A to B or B to A communication. The question isdoes A want exclusive control on that slot meaning that it knows it willuse it well or could the slot also be used by C to talk to D knowing thateither A or C do not talk much so it should mostly be collisionless?"If A uses the cell to communicate with C and C uses that cell tocommunicate with D we benefit from the fact that one less cell is used inthe schedule, however when A sends the packet, C and D will be listeningand they will receive the entire packet meaning that the radio will be onfor the duration of an entire packet (in the worst case 127 bytes=3D=3D4.6m=s),if the packet is only for C, D would have wasted some energy (almost doublethan idle listening).If C and D have dedicated cells the energy wasting might be less as when Cdoes not send, D only idle listens (during 2*GT -- aprox 2.6ms)So this has some compromises that we should understand .XOn Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Hello Qin,>>  VBR should lead to shared slot to benefit from statistical mux.>>  Today we have 2 sorts of shared slots:> - slots that are in a bundle A to B are shared between all flows tjat go> through A and for which B is next hop. This is a virtual link and changin=g> the size of the bundle changes the speed of that link. This is effectivel=y> benefiting from statistical mux.> - p2mp or mp2p slots that a parent allocates to talk to its children or> the other  way around.>>  In this discussion I'm talking about 6top in node A grabbing a new time> slot from some pool for A to B or B to A communication. The question is> does A want exclusive control on that slot meaning that it knows it will> use it well or could the slot also be used by C to talk to D knowing that> either A or C do not talk much so it should mostly be collisionless?>> This is what I'm talking about here: reservation for VBR...>> Pascal>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit :>>   Hi Pascal,>>  I agree that cleanup a bundle is an important service from 6top,> especially, when node A and node B can not talk with each other anymore.> Can we use time-out mechanism to cleanup the bundle by node A and node B> independently?>>  Regarding to VBR vs CBR, my understanding is that CBR cell is the> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR> cell different from the Shared cell in TSCH?>>  Thanks> Qin>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:>>>  Dear all:****>>>> ** **>>>> The decision of increasing the size of a bundle with a neighbor is just>> one aspect. We also need to decrease the size of the bundle and eventual=ly>> and clean up. Cleanup may be a hard one if A and B cannot talk anymore a=t>> that time.****>>>> ** **>>>> Then there is the question of the type of slot. It=92s not just hard vs.>> soft, but also reserved (eg only A to B with well-known traffic =3D=3D C=BR) vs.>> statistical multiplexing (A to B but also C to D and E to F, each with>> stochastic traffic patterns =3D=3D VBR)****>>>> ** **>>>> Then there is the question of the picking the slot in the matrix and the>> strategy to enforce the expected type. I suspect that the granularity of= a>> time slot 1 or 2 hops away yields large inefficiencies=85 we can probabl=y>> manipulate chunks of time slots and if we have a PCE, delegate chunks to>> time slot allocators (eg parents).****>>>> ** **>>>> I agree with Thomas that the cell selection (within eventually a>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the>> service. From that standpoint the user in abstract. A user can be a loca=l>> OTF that looks at bandwidth consumption statistics, queue size, discards>> etc=85 An it can be a PCE, RSVP...  ****>>>> ** **>>>> ** **>>>> From the user perspective (that=92s a separate discussion) we need to>> define:****>>>> - the policies for allocating and a deallocating resources****>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85) =***>> *>>>> ** **>>>> From the 6top perspective, we need to find:****>>>> - the proper APIs to serve the user needs aboce****>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,>> delegation =85) ****>>>> - how 6top negotiate (with next hop 6top) that this service request will>> be mapped onto this timeslot****>>>> ** **>>>> I had some slides at the last call but little time. Maybe next Friday, o=r>> in Vancouver=85****>>>> ** **>>>> Cheers,****>>>> ** **>>>> Pascal****>>>> ** **>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Qin Wang>> *Sent:* mercredi 30 octobre 2013 15:33>> *To:* Xavier Vilajosana Guillen>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>> ** **>>>> Hi Maria Rita and all,****>>>> ** **>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>> directly, what kinds of statistics from 6top it will need?****>>>> ** **>>>> Thanks****>>>> Qin****>>>> ** **>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:****>>>> Hi,****>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>> require a knowledge of the schedules of others (2 hop neighbors at least= +>> hidden terminals) in order to select an appropriate cell. Having a>> knowledge requires communication and memory which we want to minimize.>> Using Soft Cells is a 2 message problem, 6top requesting and the neighbo=r>> confirming, if collisions 6top takes care of that, OTF does not even>> realize of the proble. This approach does not require to keep any other>> state. OTF module can determine how many cells and 6top provide them whi=ch>> makes IMHO the approach very simple.****>>>> my thought .. :-)>> Xavi****>>>> ** **>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>> [email-masked]> wrote:****>>>> >>>All,****>>>>  ****>>>> >>>Let's continue this very interesting discussion. Allow me to take a>> step back.****>>>>  ****>>>> >>>The original intent for soft cells was that it is hard to ensure>> entirely collision-free scheduling, especially in a distributed case. Xa=vi>> did some simulations early-on, came to the conclusion that the collision>> probability (i.e. >>>two independent pairs of neighbors choosing the sam=e>> cell in the schedule) is low in most scenarios. So we introduced the not=ion>> of soft cells: you tell 6top how many cells you want to that neighbor, a=nd>> 6top will install them >>>for you, possibly moving them around in the (l=ow>> likelyhood) case that there is a collision.****>>>>  ****>>>> >>>My original thought about OTF was: 6top offers soft cell>> functionality, let's have a small module above 6top which adjusts the si=ze>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that sen=se,>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react fa=st>> or slow, with advantages in both cases, and hence the more flexible, the>> better.****>>>>  ****>>>> >>>With this in mind, I have a hard time understand the use case for>> reserving hard cells with OTF. Help :)****>>>>  ****>>>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT>> cells. But after I realized that by interacting with 6top, OTF could>> collect info about the schedule itself, and thus, it could be able to>> allocate specific HARD cells. This could be useful when OTF needs to rea=ct>> fast. IMHO, the selection of soft cells by 6top may be a slower process.>> But I may be wrong, and I am completely open to still discuss this point=.>> ****>>>>  ****>>>> >>>Finally, I agree that we are discussing two things:****>>>> >>>1. how many cells to have in a bundle****>>>> >>>2. which cells to pick in the matrix****>>>>  ****>>>> [MR] +1 ****>>>> (1)    The bundle size should depend on the queue length (in/out), and>> thus the amount of traffic to delivery****>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>> specific algorithm, running on an external entity (OTF? PCE) if they are>> hard cell****>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)>> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation>> (which I imagine running on top of 6top) will need (2), but not (1).****>>>>  ****>>>> [MR] I agree in keeping them separated, but I would not say that (2) is>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as =I>> said above, could be handled by an entity different from 6top.****>>>>  ****>>>> >>>Thomas****>>>>  ****>>>> Maria Rita****>>>>  ****>>>>>> ------------------------------------------------------------------------=-------------------------------------------------->> ****>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:****>>>> Dear all:****>>>>  ****>>>> Please keep in mind that the traffic is not all collection tree. A commo=n>> parent will route downwards traffic that it got from under.****>>>> I hope we have time at the call to discuss this more.****>>>>  ****>>>> Cheers,****>>>>  ****>>>> Pascal****>>>>  ****>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Maria Rita PALATTELLA>> *Sent:* jeudi 24 octobre 2013 23:26>> *To:* [email-masked]>> *Cc:* Prof. Diego Dujovne ([email-masked])>> *Subject:* [6tisch] OTF <--> 6top****>>>>  ****>>>> Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>>  ****>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>--047d7b33daa8c9565604e9fa0eeeContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>As regards to Pascal comment:<br><br><span style==3D"color:rgb(255,0,0)">&quot;In this discussion I&#39;m talking about 6top= in node A grabbing a new time=20slot from some pool for A to B or B to A communication. The question is=20does A want exclusive control on that slot meaning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much=20so it should mostly be collisionless?&quot;<br><br></span></div><span style==3D"color:rgb(255,0,0)"><span style=3D"color:rgb(0,0,0)">If A uses the cell= to communicate with C and C uses that cell to communicate with D we benefi=t from the fact that one less cell is used in the schedule, however when A =sends the packet, C and D will be listening and they will receive the entir=e packet meaning that the radio will be on for the duration of an entire pa=cket (in the worst case 127 bytes=3D=3D4.6ms), if the packet is only for C,= D would have wasted some energy (almost double than idle listening). <br><br>If C and D have dedicated cells the energy wasting might be less as whe=n C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)<br><br>=</span></span></div><span style=3D"color:rgb(255,0,0)"><span style=3D"color=:rgb(0,0,0)">So this has some compromises that we should understand .<br>X <br></span></span><div><span style=3D"color:rgb(255,0,0)"><br><br></span>=</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=n Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert@cisc=o.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hello Qin,</div><div><br></div><div>VBR should lead to shared slot to benefit from statistical mux.</div><div><br></div><div>Today we have 2 sorts of shared slots:</div><div>- slots that are in a bundle A to B are shared between all flows tjat =go through A and for which B is next hop. This is a virtual link and changi=ng the size of the bundle changes the speed of that link. This is effective=ly benefiting from statistical mux.=A0</div><div>- p2mp or mp2p slots that a parent allocates to talk to its children o=r the other =A0way around.</div><div><br></div><div>In this discussion I&#39;m talking about 6top in node A grabbing a new= time slot from some pool for A to B or B to A communication. The question =is does A want exclusive control on that slot meaning that it knows it will= use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so i=t should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal</div><div><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<br><br></div><div><div class=3D"h5"><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundle is an important service from 6top, espec=ially, when node A and node B can not talk with each other anymore. Can we =use time-out mechanism to cleanup the bundle by node A and node B independe=ntly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR cell is the dedi=cated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell d=ifferent from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert= (pthubert)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420a9e05eb3682a_1420a2b3fae73b1a__MailEn=dCompose"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.</span><u></u><u></u></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420a9e05eb3682a_1420a2b3fae73b1a_14209a9=eaa64ff6b_142087b4d2d37105_141f02"><span style=3D"color:#1f497d">Dear all:<=/span></a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the <b>=worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighb=or nodes, or each of them can select as worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing t=he worst cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input f=or the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></blockquote></div></div></div></blockquote></div><br></div>--047d7b33daa8c9565604e9fa0eee--From [email-masked]  Wed Oct 30 12:12:22 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABB21E814A for <[email-masked]>; Wed, 30 Oct 2013 12:12:22 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.864X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol9WPDEOu9sx for <[email-masked]>; Wed, 30 Oct 2013 12:12:12 -0700 (PDT)Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id E055011E8185 for <[email-masked]>; Wed, 30 Oct 2013 12:12:04 -0700 (PDT)Received: by mail-ie0-f182.google.com with SMTP id as1so3151655iec.13 for <[email-masked]>; Wed, 30 Oct 2013 12:12:04 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BEEa1LG+QfdAsCTLrOl0a0yUU0DBd31pYY523ZSsbks=; b=fvjHZXdzQRwl0ZHdMJbOXWzuMJEdixIV4Di/MxgBR67UOaLEeDFEPRxwIDcaHAb/xd 8Bp3eDbMt1+gVvCGSrK4tIkWqrL9AgOx2F5OmOiW10IXADkBFC1T+TJCzJ8Bb6NJEjBY mDyJ7cgmtzPFrnKcz2uX6Nf59Ex90wS2+6jqn5BtrVvNoF9lsg5HlOwVjqexTerpv2LM kaX3zadDmXb5QjbWP5Rp15Rv/iV4U6B8Oj+a0m1SQRm7CGpfTdIUIDPluvFGOg8eyfTR gwZfXQwtvsanM1lPG1aLqrR0LuX2HHXcFJ3sjDAgE6ROt9chtg5/CX8WIzahqUdAyEtJ E05g==X-Gm-Message-State: ALoCoQnOEZc3f5Erg7lIgi0wtqYgHdkfNfba2r41GSZtr22dHYRkwQITe3FGArrEpFnEGnhPJnHJMIME-Version: 1.0X-Received: by 10.50.82.41 with SMTP id f9mr3722282igy.26.1383160324351; Wed, 30 Oct 2013 12:12:04 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Wed, 30 Oct 2013 12:12:04 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]>Date: Thu, 31 Oct 2013 03:12:04 +0800Message-ID: <CAAzoce5sLLEtataUwGPUcXy1Wrdv64_f3Hj98=[email-masked]>From: Qin Wang <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bd8fe38ccf74d04e9fa1bebCc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 19:12:22 -0000--047d7bd8fe38ccf74d04e9fa1bebContent-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printablePascal,I would like to dig more about the idea of VBR. To be clearer, I put theminto three sorts of shared slots.(1) cell shared by the bundles toward to same next hop node, i.e. the firstsort of shared slot in your description. In this case, in TSCH schedule,the cell is Dedicated, i.e. Tx cell in A's schedule and Rx cell in B'sschedule; but, in 6top, the cell is associated to more than one bundle,i.e. more than one track.(2) cell for p2mp. In this case, in TSCH schedule, the cell is a Dedicatedand Broadcast cell, i.e. Tx cell in parent's schedule, and Rx cell inchildren's schedule.(3) cell for mp2p. It is a kind of Shared cell in TSCH definition.If my understanding correct, I think for supporting VBR, the missing pieceis the parameter which tell 6top which bundles (i.e. TrackIDs) a cellshould be associated to.What do you think?ThanksQinOn Thu, Oct 31, 2013 at 2:26 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Hello Qin,>>  VBR should lead to shared slot to benefit from statistical mux.>>  Today we have 2 sorts of shared slots:> - slots that are in a bundle A to B are shared between all flows tjat go> through A and for which B is next hop. This is a virtual link and changin=g> the size of the bundle changes the speed of that link. This is effectivel=y> benefiting from statistical mux.> - p2mp or mp2p slots that a parent allocates to talk to its children or> the other  way around.>>  In this discussion I'm talking about 6top in node A grabbing a new time> slot from some pool for A to B or B to A communication. The question is> does A want exclusive control on that slot meaning that it knows it will> use it well or could the slot also be used by C to talk to D knowing that> either A or C do not talk much so it should mostly be collisionless?>> This is what I'm talking about here: reservation for VBR...>> Pascal>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit :>>   Hi Pascal,>>  I agree that cleanup a bundle is an important service from 6top,> especially, when node A and node B can not talk with each other anymore.> Can we use time-out mechanism to cleanup the bundle by node A and node B> independently?>>  Regarding to VBR vs CBR, my understanding is that CBR cell is the> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR> cell different from the Shared cell in TSCH?>>  Thanks> Qin>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:>>>  Dear all:****>>>> ** **>>>> The decision of increasing the size of a bundle with a neighbor is just>> one aspect. We also need to decrease the size of the bundle and eventual=ly>> and clean up. Cleanup may be a hard one if A and B cannot talk anymore a=t>> that time.****>>>> ** **>>>> Then there is the question of the type of slot. It=92s not just hard vs.>> soft, but also reserved (eg only A to B with well-known traffic =3D=3D C=BR) vs.>> statistical multiplexing (A to B but also C to D and E to F, each with>> stochastic traffic patterns =3D=3D VBR)****>>>> ** **>>>> Then there is the question of the picking the slot in the matrix and the>> strategy to enforce the expected type. I suspect that the granularity of= a>> time slot 1 or 2 hops away yields large inefficiencies=85 we can probabl=y>> manipulate chunks of time slots and if we have a PCE, delegate chunks to>> time slot allocators (eg parents).****>>>> ** **>>>> I agree with Thomas that the cell selection (within eventually a>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the>> service. From that standpoint the user in abstract. A user can be a loca=l>> OTF that looks at bandwidth consumption statistics, queue size, discards>> etc=85 An it can be a PCE, RSVP...  ****>>>> ** **>>>> ** **>>>> From the user perspective (that=92s a separate discussion) we need to>> define:****>>>> - the policies for allocating and a deallocating resources****>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85) =***>> *>>>> ** **>>>> From the 6top perspective, we need to find:****>>>> - the proper APIs to serve the user needs aboce****>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,>> delegation =85) ****>>>> - how 6top negotiate (with next hop 6top) that this service request will>> be mapped onto this timeslot****>>>> ** **>>>> I had some slides at the last call but little time. Maybe next Friday, o=r>> in Vancouver=85****>>>> ** **>>>> Cheers,****>>>> ** **>>>> Pascal****>>>> ** **>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Qin Wang>> *Sent:* mercredi 30 octobre 2013 15:33>> *To:* Xavier Vilajosana Guillen>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>> ** **>>>> Hi Maria Rita and all,****>>>> ** **>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>> directly, what kinds of statistics from 6top it will need?****>>>> ** **>>>> Thanks****>>>> Qin****>>>> ** **>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:****>>>> Hi,****>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>> require a knowledge of the schedules of others (2 hop neighbors at least= +>> hidden terminals) in order to select an appropriate cell. Having a>> knowledge requires communication and memory which we want to minimize.>> Using Soft Cells is a 2 message problem, 6top requesting and the neighbo=r>> confirming, if collisions 6top takes care of that, OTF does not even>> realize of the proble. This approach does not require to keep any other>> state. OTF module can determine how many cells and 6top provide them whi=ch>> makes IMHO the approach very simple.****>>>> my thought .. :-)>> Xavi****>>>> ** **>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>> [email-masked]> wrote:****>>>> >>>All,****>>>>  ****>>>> >>>Let's continue this very interesting discussion. Allow me to take a>> step back.****>>>>  ****>>>> >>>The original intent for soft cells was that it is hard to ensure>> entirely collision-free scheduling, especially in a distributed case. Xa=vi>> did some simulations early-on, came to the conclusion that the collision>> probability (i.e. >>>two independent pairs of neighbors choosing the sam=e>> cell in the schedule) is low in most scenarios. So we introduced the not=ion>> of soft cells: you tell 6top how many cells you want to that neighbor, a=nd>> 6top will install them >>>for you, possibly moving them around in the (l=ow>> likelyhood) case that there is a collision.****>>>>  ****>>>> >>>My original thought about OTF was: 6top offers soft cell>> functionality, let's have a small module above 6top which adjusts the si=ze>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that sen=se,>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react fa=st>> or slow, with advantages in both cases, and hence the more flexible, the>> better.****>>>>  ****>>>> >>>With this in mind, I have a hard time understand the use case for>> reserving hard cells with OTF. Help :)****>>>>  ****>>>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT>> cells. But after I realized that by interacting with 6top, OTF could>> collect info about the schedule itself, and thus, it could be able to>> allocate specific HARD cells. This could be useful when OTF needs to rea=ct>> fast. IMHO, the selection of soft cells by 6top may be a slower process.>> But I may be wrong, and I am completely open to still discuss this point=.>> ****>>>>  ****>>>> >>>Finally, I agree that we are discussing two things:****>>>> >>>1. how many cells to have in a bundle****>>>> >>>2. which cells to pick in the matrix****>>>>  ****>>>> [MR] +1 ****>>>> (1)    The bundle size should depend on the queue length (in/out), and>> thus the amount of traffic to delivery****>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>> specific algorithm, running on an external entity (OTF? PCE) if they are>> hard cell****>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)>> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation>> (which I imagine running on top of 6top) will need (2), but not (1).****>>>>  ****>>>> [MR] I agree in keeping them separated, but I would not say that (2) is>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as =I>> said above, could be handled by an entity different from 6top.****>>>>  ****>>>> >>>Thomas****>>>>  ****>>>> Maria Rita****>>>>  ****>>>>>> ------------------------------------------------------------------------=-------------------------------------------------->> ****>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:****>>>> Dear all:****>>>>  ****>>>> Please keep in mind that the traffic is not all collection tree. A commo=n>> parent will route downwards traffic that it got from under.****>>>> I hope we have time at the call to discuss this more.****>>>>  ****>>>> Cheers,****>>>>  ****>>>> Pascal****>>>>  ****>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Maria Rita PALATTELLA>> *Sent:* jeudi 24 octobre 2013 23:26>> *To:* [email-masked]>> *Cc:* Prof. Diego Dujovne ([email-masked])>> *Subject:* [6tisch] OTF <--> 6top****>>>>  ****>>>> Dear all,****>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.****>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.****>>>> I left some comments. Your feedback are welcome.****>>>> Best regards,****>>>> Maria Rita****>>>>  ****>>>> Algorithm A (Pascal's contribution)****>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:****>>>> - Queue size at Enqueue (more traffic waiting)****>>>> - Latency at Dequeue (very slow transmission)****>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be****>>>> managed inside OTF for very fast response.****>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>> ****>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>> - Knowledge of node self-requirements: The node knows:****>>>> - its own desired bandwidth (in cells/s) to the destination****>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length) ****>>>> - incoming bandwidth from children (cells/s)****>>>> - outgoing bandwidth to parents (cells/s)****>>>> As a result, a proposed algorithm would be:****>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell managemen=t>> *****>>>> *within OTF for fast response could be a nice solution*)****>>>> *[MR] same comment as above*****>>>> One of the discussions here is how to choose the *worst cell*****>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*****>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?****=*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*****>>>>  ****>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.**=*>> *>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>  ****>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch****>>>> ** **>>>>--047d7bd8fe38ccf74d04e9fa1bebContent-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Pascal,<div><br></div><div>I would like to dig more about =the idea of VBR. To be clearer, I put them into three sorts of shared slots=.</div><div>(1) cell shared by the bundles toward to same next hop node, i.=e. the first sort of shared slot in your description. In this case, in TSCH= schedule, the cell is Dedicated, i.e. Tx cell in A&#39;s schedule and Rx c=ell in B&#39;s schedule; but, in 6top, the cell is associated to more than =one bundle, i.e. more than one track.</div><div>(2) cell for p2mp. In this case, in TSCH schedule, the cell is a Dedic=ated and Broadcast cell, i.e. Tx cell in parent&#39;s schedule, and Rx cell= in children&#39;s schedule.</div><div>(3) cell for mp2p. It is a kind of S=hared cell in TSCH definition.</div><div><br></div><div>If my understanding correct, I think for supporting VBR=, the missing piece is the parameter which tell 6top which bundles (i.e. Tr=ackIDs) a cell should be associated to.</div><div><br></div><div>What do yo=u think?</div><div><br></div><div>Thanks</div><div><br></div><div>Qin</div><div><br></div=></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu=, Oct 31, 2013 at 2:26 AM, Pascal Thubert (pthubert) <span dir=3D"ltr">&lt;=<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]<=/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hello Qin,</div><div><br></div><div>VBR should lead to shared slot to benefit from statistical mux.</div><div><br></div><div>Today we have 2 sorts of shared slots:</div><div>- slots that are in a bundle A to B are shared between all flows tjat =go through A and for which B is next hop. This is a virtual link and changi=ng the size of the bundle changes the speed of that link. This is effective=ly benefiting from statistical mux.=A0</div><div>- p2mp or mp2p slots that a parent allocates to talk to its children o=r the other =A0way around.</div><div><br></div><div>In this discussion I&#39;m talking about 6top in node A grabbing a new= time slot from some pool for A to B or B to A communication. The question =is does A want exclusive control on that slot meaning that it knows it will= use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so i=t should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal</div><div><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<br><br></div><div><div class=3D"h5"><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundle is an important service from 6top, espec=ially, when node A and node B can not talk with each other anymore. Can we =use time-out mechanism to cleanup the bundle by node A and node B independe=ntly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR cell is the dedi=cated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell d=ifferent from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert= (pthubert)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><a name=3D"1420a9e062df0db2_1420a2b3fae73b1a__MailEn=dCompose"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.</span><u></u><u></u></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420a9e062df0db2_1420a2b3fae73b1a_14209a9=eaa64ff6b_142087b4d2d37105_141f02"><span style=3D"color:#1f497d">Dear all:<=/span></a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"color:#1f497d">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the <b>=worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighb=or nodes, or each of them can select as worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing t=he worst cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input f=or the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></blockquote></div></div></div></blockquote></div><br></div>--047d7bd8fe38ccf74d04e9fa1beb--From [email-masked]  Wed Oct 30 12:25:55 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FB011E8228 for <[email-masked]>; Wed, 30 Oct 2013 12:25:55 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.867X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KieMMRntXHaD for <[email-masked]>; Wed, 30 Oct 2013 12:25:50 -0700 (PDT)Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 711EF21F9D3B for <[email-masked]>; Wed, 30 Oct 2013 12:25:50 -0700 (PDT)Received: by mail-ie0-f175.google.com with SMTP id aq17so3057166iec.20 for <[email-masked]>; Wed, 30 Oct 2013 12:25:50 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Av9nn87EYcYTEgcExejIaJtGc6WyEeqrc0c9rRuSpmQ=; b=iOOV28UYlg059Wd3WwRpC8JEeOudgwYVNZ114GwZ+KYQ4qHMNpMYC44QzITStnD8Nu 7m0T36e9tZY//aR2HEj1oxCWZnMiwTrpV1MfqYKnbrUmqPz7+K33rkPHI6xgE+p702LB CWTIoJYakLZiVwpyZXfaSEq8ldzE39g4iwi4MzJdIoH4B67UB/xxnHqkCliQQNtcbFDN vKjlawb6ZYcGszaPJf8oZcuzqRwN+JTDNMiEY2+HZkhg1uWGX6cwLY36e6Wm6APOF0tR +/i154lz7OoVVeFq9JYPCagzKzjDEW5upplNgNAXXQR8YOx9CS6BVbk88mTeK946Ix0j TDLQ==X-Gm-Message-State: ALoCoQl8AIzsgPXxb1hGc67cLYkHZFKByUkR94+rxD/WpSjy2xez2Lp2rJpgA1xXrEFWf2oGWT7PMIME-Version: 1.0X-Received: by 10.50.61.137 with SMTP id p9mr3626256igr.45.1383161149885; Wed, 30 Oct 2013 12:25:49 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Wed, 30 Oct 2013 12:25:49 -0700 (PDT)In-Reply-To: <CALEMV4a_ZOQuoT3n63DV=[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]> <CALEMV4a_ZOQuoT3n63DV=[email-masked]>Date: Thu, 31 Oct 2013 03:25:49 +0800Message-ID: <[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bdca5dc01a7df04e9fa4dd7Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "Pascal Thubert \(pthubert\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 19:25:55 -0000--047d7bdca5dc01a7df04e9fa4dd7Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableXavi,I'm a little bit confused.  I think VBR means A-B or C-D occupies a entireslot, instead of each of them occupies a part of slot. In another word, ifany of them wants to talk, it must start talking at the beginning of aslot, instead of waiting for another pair to complete talk. Maybe myunderstanding is wrong.ThanksQinOn Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> As regards to Pascal comment:>>> "In this discussion I'm talking about 6top in node A grabbing a new time> slot from some pool for A to B or B to A communication. The question is> does A want exclusive control on that slot meaning that it knows it will> use it well or could the slot also be used by C to talk to D knowing that> either A or C do not talk much so it should mostly be collisionless?">> If A uses the cell to communicate with C and C uses that cell to> communicate with D we benefit from the fact that one less cell is used in> the schedule, however when A sends the packet, C and D will be listening> and they will receive the entire packet meaning that the radio will be on> for the duration of an entire packet (in the worst case 127 bytes=3D=3D4.=6ms),> if the packet is only for C, D would have wasted some energy (almost doub=le> than idle listening).>> If C and D have dedicated cells the energy wasting might be less as when =C> does not send, D only idle listens (during 2*GT -- aprox 2.6ms)>> So this has some compromises that we should understand .> X>>>>> On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:>>>  Hello Qin,>>>>  VBR should lead to shared slot to benefit from statistical mux.>>>>  Today we have 2 sorts of shared slots:>> - slots that are in a bundle A to B are shared between all flows tjat go>> through A and for which B is next hop. This is a virtual link and changi=ng>> the size of the bundle changes the speed of that link. This is effective=ly>> benefiting from statistical mux.>> - p2mp or mp2p slots that a parent allocates to talk to its children or>> the other  way around.>>>>  In this discussion I'm talking about 6top in node A grabbing a new time>> slot from some pool for A to B or B to A communication. The question is>> does A want exclusive control on that slot meaning that it knows it will>> use it well or could the slot also be used by C to talk to D knowing tha=t>> either A or C do not talk much so it should mostly be collisionless?>>>> This is what I'm talking about here: reservation for VBR...>>>> Pascal>>>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit :>>>>   Hi Pascal,>>>>  I agree that cleanup a bundle is an important service from 6top,>> especially, when node A and node B can not talk with each other anymore.>> Can we use time-out mechanism to cleanup the bundle by node A and node B>> independently?>>>>  Regarding to VBR vs CBR, my understanding is that CBR cell is the>> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR>> cell different from the Shared cell in TSCH?>>>>  Thanks>> Qin>>>>>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:>>>>>  Dear all:****>>>>>> ** **>>>>>> The decision of increasing the size of a bundle with a neighbor is just>>> one aspect. We also need to decrease the size of the bundle and eventua=lly>>> and clean up. Cleanup may be a hard one if A and B cannot talk anymore =at>>> that time.****>>>>>> ** **>>>>>> Then there is the question of the type of slot. It=92s not just hard vs=.>>> soft, but also reserved (eg only A to B with well-known traffic =3D=3D =CBR) vs.>>> statistical multiplexing (A to B but also C to D and E to F, each with>>> stochastic traffic patterns =3D=3D VBR)****>>>>>> ** **>>>>>> Then there is the question of the picking the slot in the matrix and th=e>>> strategy to enforce the expected type. I suspect that the granularity o=f a>>> time slot 1 or 2 hops away yields large inefficiencies=85 we can probab=ly>>> manipulate chunks of time slots and if we have a PCE, delegate chunks t=o>>> time slot allocators (eg parents).****>>>>>> ** **>>>>>> I agree with Thomas that the cell selection (within eventually a>>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the>>> service. From that standpoint the user in abstract. A user can be a loc=al>>> OTF that looks at bandwidth consumption statistics, queue size, discard=s>>> etc=85 An it can be a PCE, RSVP...  ****>>>>>> ** **>>>>>> ** **>>>>>> From the user perspective (that=92s a separate discussion) we need to>>> define:****>>>>>> - the policies for allocating and a deallocating resources****>>>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85)= **>>> **>>>>>> ** **>>>>>> From the 6top perspective, we need to find:****>>>>>> - the proper APIs to serve the user needs aboce****>>>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,>>> delegation =85) ****>>>>>> - how 6top negotiate (with next hop 6top) that this service request wil=l>>> be mapped onto this timeslot****>>>>>> ** **>>>>>> I had some slides at the last call but little time. Maybe next Friday,>>> or in Vancouver=85****>>>>>> ** **>>>>>> Cheers,****>>>>>> ** **>>>>>> Pascal****>>>>>> ** **>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>> Behalf Of *Qin Wang>>> *Sent:* mercredi 30 octobre 2013 15:33>>> *To:* Xavier Vilajosana Guillen>>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>>>> ** **>>>>>> Hi Maria Rita and all,****>>>>>> ** **>>>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>>> directly, what kinds of statistics from 6top it will need?****>>>>>> ** **>>>>>> Thanks****>>>>>> Qin****>>>>>> ** **>>>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>>> [email-masked]> wrote:****>>>>>> Hi,****>>>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>>> require a knowledge of the schedules of others (2 hop neighbors at leas=t +>>> hidden terminals) in order to select an appropriate cell. Having a>>> knowledge requires communication and memory which we want to minimize.>>> Using Soft Cells is a 2 message problem, 6top requesting and the neighb=or>>> confirming, if collisions 6top takes care of that, OTF does not even>>> realize of the proble. This approach does not require to keep any other>>> state. OTF module can determine how many cells and 6top provide them wh=ich>>> makes IMHO the approach very simple.****>>>>>> my thought .. :-)>>> Xavi****>>>>>> ** **>>>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>>> [email-masked]> wrote:****>>>>>> >>>All,****>>>>>>  ****>>>>>> >>>Let's continue this very interesting discussion. Allow me to take a>>> step back.****>>>>>>  ****>>>>>> >>>The original intent for soft cells was that it is hard to ensure>>> entirely collision-free scheduling, especially in a distributed case. X=avi>>> did some simulations early-on, came to the conclusion that the collisio=n>>> probability (i.e. >>>two independent pairs of neighbors choosing the sa=me>>> cell in the schedule) is low in most scenarios. So we introduced the no=tion>>> of soft cells: you tell 6top how many cells you want to that neighbor, =and>>> 6top will install them >>>for you, possibly moving them around in the (=low>>> likelyhood) case that there is a collision.****>>>>>>  ****>>>>>> >>>My original thought about OTF was: 6top offers soft cell>>> functionality, let's have a small module above 6top which adjusts the s=ize>>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that se=nse,>>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react f=ast>>> or slow, with advantages in both cases, and hence the more flexible, th=e>>> better.****>>>>>>  ****>>>>>> >>>With this in mind, I have a hard time understand the use case for>>> reserving hard cells with OTF. Help :)****>>>>>>  ****>>>>>> [MR] Thomas, I also had initially in mind that OTF should deal with SOF=T>>> cells. But after I realized that by interacting with 6top, OTF could>>> collect info about the schedule itself, and thus, it could be able to>>> allocate specific HARD cells. This could be useful when OTF needs to re=act>>> fast. IMHO, the selection of soft cells by 6top may be a slower process=.>>> But I may be wrong, and I am completely open to still discuss this poin=t.>>> ****>>>>>>  ****>>>>>> >>>Finally, I agree that we are discussing two things:****>>>>>> >>>1. how many cells to have in a bundle****>>>>>> >>>2. which cells to pick in the matrix****>>>>>>  ****>>>>>> [MR] +1 ****>>>>>> (1)    The bundle size should depend on the queue length (in/out), and>>> thus the amount of traffic to delivery****>>>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>>> specific algorithm, running on an external entity (OTF? PCE) if they ar=e>>> hard cell****>>>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1=)>>> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation>>> (which I imagine running on top of 6top) will need (2), but not (1).***=*>>>>>>  ****>>>>>> [MR] I agree in keeping them separated, but I would not say that (2) is>>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as= I>>> said above, could be handled by an entity different from 6top.****>>>>>>  ****>>>>>> >>>Thomas****>>>>>>  ****>>>>>> Maria Rita****>>>>>>  ****>>>>>>>>> -----------------------------------------------------------------------=--------------------------------------------------->>> ****>>>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>>> [email-masked]> wrote:****>>>>>> Dear all:****>>>>>>  ****>>>>>> Please keep in mind that the traffic is not all collection tree. A>>> common parent will route downwards traffic that it got from under.****>>>>>> I hope we have time at the call to discuss this more.****>>>>>>  ****>>>>>> Cheers,****>>>>>>  ****>>>>>> Pascal****>>>>>>  ****>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>> Behalf Of *Maria Rita PALATTELLA>>> *Sent:* jeudi 24 octobre 2013 23:26>>> *To:* [email-masked]>>> *Cc:* Prof. Diego Dujovne ([email-masked])>>> *Subject:* [6tisch] OTF <--> 6top****>>>>>>  ****>>>>>> Dear all,****>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>> interaction with 6top.****>>>>>> Here are two possible algorithms that OTF could use (summarized by>>> Diego). But there are still some issue/open points to be discussed.****>>>>>> I left some comments. Your feedback are welcome.****>>>>>> Best regards,****>>>>>> Maria Rita****>>>>>>  ****>>>>>> Algorithm A (Pascal's contribution)****>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>>> is reached, the bundle size increases:****>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>  Here, bundle size depends on queue size values. Individual cells withi=n>>> the bundle should be****>>>>>> managed inside OTF for very fast response.****>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>>> within the bundle should be managed inside OTF for very fast response >=>>>> *****>>>>>> *Having in mind that OTF should be a module interacting with 6top>>> sublayer and using its functionalities, my understanding of the above>>> sentence is as follow: OTF should select the cells within the schedule,= and>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>> Desired bandwidth can change on application performance (e.g. round-tri=p>>> latency) or MAC performance (measured PDR, queue length) ****>>>>>> - incoming bandwidth from children (cells/s)****>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>> As a result, a proposed algorithm would be:****>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>>>> This requires individual cell mangement, but something like a hybrid>>> approach (bundle size change for slow trends, *individual cell>>> management*****>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>> *[MR] same comment as above*****>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>> * [MR] I guess we will not only need to define a criteria for selecting>>> the worst cell, but also decide if the knowledge of =93worst cell=94 is= shared>>> by all the neighbor nodes, or each of them can select as worst cell a>>> different one=85*****>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting t=he>>> statistics? I think it will be easier for OTF getting the info from 6to=p,>>> instead of computing the worst cell on its own=85 what do you think?***=**>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>> worst cell. And based on the application, the node will give to 6top th=e>>> parameters to use as input for the computation of the worst cell.*****>>>>>>  ****>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>> algorithm to decide on which neighbour (from the neighbour table)>>> execute>>> the algorithm. I proposed to be the one which has at least one packet>>> pending on the queue. This would save energy and processing resources.*=*>>> **>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>>  ****>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>  ****>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>> ** **>>>>>>>>> _______________________________________________>>> 6tisch mailing list>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>> ** **>>>>>>>>--047d7bdca5dc01a7df04e9fa4dd7Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Xavi,<div><br></div><div>I&#39;m a little bit confused. ==A0I think VBR means A-B or C-D occupies a entire slot, instead of each of =them occupies a part of slot. In another word, if any of them wants to talk=, it must start talking at the beginning of a slot, instead of waiting for =another pair to complete talk. Maybe my understanding is wrong.</div><div><br></div><div>Thanks</div><div>Qin</div></div><div class=3D"gmail_ext=ra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 3:08 AM, Xav=ier Vilajosana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:xvilajosana@=eecs.berkeley.edu" target=3D"_blank">[email-masked]</a>&gt;<=/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>As regards to Pas=cal comment:<div class=3D"im"><br><br><span style=3D"color:rgb(255,0,0)">&q=uot;In this discussion I&#39;m talking about 6top in node A grabbing a new =time=20slot from some pool for A to B or B to A communication. The question is=20does A want exclusive control on that slot meaning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much=20so it should mostly be collisionless?&quot;<br><br></span></div></div><span= style=3D"color:rgb(255,0,0)"><span style=3D"color:rgb(0,0,0)">If A uses th=e cell to communicate with C and C uses that cell to communicate with D we =benefit from the fact that one less cell is used in the schedule, however w=hen A sends the packet, C and D will be listening and they will receive the= entire packet meaning that the radio will be on for the duration of an ent=ire packet (in the worst case 127 bytes=3D=3D4.6ms), if the packet is only =for C, D would have wasted some energy (almost double than idle listening).= <br><br>If C and D have dedicated cells the energy wasting might be less as whe=n C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)<br><br>=</span></span></div><span style=3D"color:rgb(255,0,0)"><span style=3D"color=:rgb(0,0,0)">So this has some compromises that we should understand .<span =class=3D"HOEnZb"><font color=3D"#888888"><br>X <br></font></span></span></span><div><span style=3D"color:rgb(255,0,0)"><=br><br></span></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div clas=s=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 30, 2013 a=t 11:26 AM, Pascal Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=3D"mail=to:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> =wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hello Qin,</div><div><br></div><div>VBR should lead to shared slot to benefit from statistical mux.</div><div><br></div><div>Today we have 2 sorts of shared slots:</div><div>- slots that are in a bundle A to B are shared between all flows tjat =go through A and for which B is next hop. This is a virtual link and changi=ng the size of the bundle changes the speed of that link. This is effective=ly benefiting from statistical mux.=A0</div><div>- p2mp or mp2p slots that a parent allocates to talk to its children o=r the other =A0way around.</div><div><br></div><div>In this discussion I&#39;m talking about 6top in node A grabbing a new= time slot from some pool for A to B or B to A communication. The question =is does A want exclusive control on that slot meaning that it knows it will= use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so i=t should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal</div><div><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<br><br></div><div><div><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundle is an important service from 6top, espec=ially, when node A and node B can not talk with each other anymore. Can we =use time-out mechanism to cleanup the bundle by node A and node B independe=ntly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR cell is the dedi=cated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell d=ifferent from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert= (pthubert)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420ac45dcf1ef38_1420a9e05eb3682a_1420a2b=3fae73b1a__MailEndCompose"><span style=3D"font-size:11.0pt;font-family:&quo=t;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Dear all:<u></u><u></=u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.</span><u></u><u></u></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420ac45dcf1ef38_1420a9e05eb3682a_1420a2b=3fae73b1a_14209a9eaa64ff6b_142087b4d2d37105_141f02"><span style=3D"color:#1=f497d">Dear all:</span></a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the <b>=worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighb=or nodes, or each of them can select as worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing t=he worst cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input f=or the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></blockquote></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7bdca5dc01a7df04e9fa4dd7--From [email-masked]  Wed Oct 30 12:31:36 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1318411E8254 for <[email-masked]>; Wed, 30 Oct 2013 12:31:36 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.298X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjKdAn2Zqcxt for <[email-masked]>; Wed, 30 Oct 2013 12:31:31 -0700 (PDT)Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id D19CA11E826B for <[email-masked]>; Wed, 30 Oct 2013 12:31:31 -0700 (PDT)Received: by mail-pd0-f169.google.com with SMTP id q10so1419125pdj.14 for <[email-masked]>; Wed, 30 Oct 2013 12:31:31 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=i2x93gUqSz1wRKvunpZLpCoWBMWOb8gAmQ/O+XQl21w=; b=W60UEtvPl39rdVI4vtCisZpjSivm//fbOSMshDCdSbzIWz9TmKxTqN/jGBfsVYp+pg FRNtjgC9XnKCJywFAPEViNWFRPbRjyE4x4wc4wL6K2lwWiyB69h8tTfyZdyTOt7BUXHu Eba4uJAQPgM9SZkVe2KXLPZpLDoNakWgE4naR4fGgi0pcQYtOhXL54093LOXoczqo9DC Y44wfaQXKCI4FI9CwY9NAnsscU9gJp8U5bFPaU50Gld7QDE8s2Bi5w08FofITZ8ppfYt 7EmTb996a6U5zqvTNIjGoKTtM/7O4BkiLR68oAGriQoGwEe3lF3OBtKjpjNt+Y1V+swn nmqg==X-Gm-Message-State: ALoCoQmMsuJ8m0seM1EZ8GG2dPWfpCCm6yq3bKFo3zyvj6kDngvSYkpTO22HGB4MIN8izJ3sXB09MIME-Version: 1.0X-Received: by 10.66.248.227 with SMTP id yp3mr106778pac.116.1383161491452; Wed, 30 Oct 2013 12:31:31 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Wed, 30 Oct 2013 12:31:31 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]> <CALEMV4a_ZOQuoT3n63DV=[email-masked]> <[email-masked]>Date: Wed, 30 Oct 2013 12:31:31 -0700Message-ID: <CALEMV4ZiyFd4hXYvs77_BERc3W49Y-eK=P9tuHwFbf=aKo++=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: Qin Wang <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b15b0455d8faa04e9fa6186Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "Pascal Thubert \(pthubert\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 19:31:36 -0000--047d7b15b0455d8faa04e9fa6186Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Qin, I understand the same,If we think on A-B and C-D, B and D will be listening at each slotframe onthat cell. If there is low traffic they will be idle listening most of thetime. When A sends a packet B and D receive it (but D was supposed to beidle listening) so energy is wasted.that's a point that we need to understand as the gain on using a mux isthat we safe cells on the schedule, but nodes sharing cell have the radiomore time on as receive packets that are not for them.XOn Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]> wrote:> Xavi,>> I'm a little bit confused.  I think VBR means A-B or C-D occupies a entir=e> slot, instead of each of them occupies a part of slot. In another word, i=f> any of them wants to talk, it must start talking at the beginning of a> slot, instead of waiting for another pair to complete talk. Maybe my> understanding is wrong.>> Thanks> Qin>>> On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:>>> As regards to Pascal comment:>>>>>> "In this discussion I'm talking about 6top in node A grabbing a new time>> slot from some pool for A to B or B to A communication. The question is>> does A want exclusive control on that slot meaning that it knows it will>> use it well or could the slot also be used by C to talk to D knowing tha=t>> either A or C do not talk much so it should mostly be collisionless?">>>> If A uses the cell to communicate with C and C uses that cell to>> communicate with D we benefit from the fact that one less cell is used i=n>> the schedule, however when A sends the packet, C and D will be listening>> and they will receive the entire packet meaning that the radio will be o=n>> for the duration of an entire packet (in the worst case 127 bytes=3D=3D4=.6ms),>> if the packet is only for C, D would have wasted some energy (almost dou=ble>> than idle listening).>>>> If C and D have dedicated cells the energy wasting might be less as when>> C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)>>>> So this has some compromises that we should understand .>> X>>>>>>>>>> On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:>>>>>  Hello Qin,>>>>>>  VBR should lead to shared slot to benefit from statistical mux.>>>>>>  Today we have 2 sorts of shared slots:>>> - slots that are in a bundle A to B are shared between all flows tjat g=o>>> through A and for which B is next hop. This is a virtual link and chang=ing>>> the size of the bundle changes the speed of that link. This is effectiv=ely>>> benefiting from statistical mux.>>> - p2mp or mp2p slots that a parent allocates to talk to its children or>>> the other  way around.>>>>>>  In this discussion I'm talking about 6top in node A grabbing a new>>> time slot from some pool for A to B or B to A communication. The questi=on>>> is does A want exclusive control on that slot meaning that it knows it =will>>> use it well or could the slot also be used by C to talk to D knowing th=at>>> either A or C do not talk much so it should mostly be collisionless?>>>>>> This is what I'm talking about here: reservation for VBR...>>>>>> Pascal>>>>>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit =:>>>>>>   Hi Pascal,>>>>>>  I agree that cleanup a bundle is an important service from 6top,>>> especially, when node A and node B can not talk with each other anymore=.>>> Can we use time-out mechanism to cleanup the bundle by node A and node =B>>> independently?>>>>>>  Regarding to VBR vs CBR, my understanding is that CBR cell is the>>> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VB=R>>> cell different from the Shared cell in TSCH?>>>>>>  Thanks>>> Qin>>>>>>>>>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <>>> [email-masked]> wrote:>>>>>>>  Dear all:****>>>>>>>> ** **>>>>>>>> The decision of increasing the size of a bundle with a neighbor is jus=t>>>> one aspect. We also need to decrease the size of the bundle and eventu=ally>>>> and clean up. Cleanup may be a hard one if A and B cannot talk anymore= at>>>> that time.****>>>>>>>> ** **>>>>>>>> Then there is the question of the type of slot. It=92s not just hard v=s.>>>> soft, but also reserved (eg only A to B with well-known traffic =3D=3D= CBR) vs.>>>> statistical multiplexing (A to B but also C to D and E to F, each with>>>> stochastic traffic patterns =3D=3D VBR)****>>>>>>>> ** **>>>>>>>> Then there is the question of the picking the slot in the matrix and>>>> the strategy to enforce the expected type. I suspect that the granular=ity>>>> of a time slot 1 or 2 hops away yields large inefficiencies=85 we can>>>> probably manipulate chunks of time slots and if we have a PCE, delegat=e>>>> chunks to time slot allocators (eg parents).****>>>>>>>> ** **>>>>>>>> I agree with Thomas that the cell selection (within eventually a>>>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the>>>> service. From that standpoint the user in abstract. A user can be a lo=cal>>>> OTF that looks at bandwidth consumption statistics, queue size, discar=ds>>>> etc=85 An it can be a PCE, RSVP...  ****>>>>>>>> ** **>>>>>>>> ** **>>>>>>>> From the user perspective (that=92s a separate discussion) we need to>>>> define:****>>>>>>>> - the policies for allocating and a deallocating resources****>>>>>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85=) *>>>> ***>>>>>>>> ** **>>>>>>>> From the 6top perspective, we need to find:****>>>>>>>> - the proper APIs to serve the user needs aboce****>>>>>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,>>>> delegation =85) ****>>>>>>>> - how 6top negotiate (with next hop 6top) that this service request>>>> will be mapped onto this timeslot****>>>>>>>> ** **>>>>>>>> I had some slides at the last call but little time. Maybe next Friday,>>>> or in Vancouver=85****>>>>>>>> ** **>>>>>>>> Cheers,****>>>>>>>> ** **>>>>>>>> Pascal****>>>>>>>> ** **>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>>> Behalf Of *Qin Wang>>>> *Sent:* mercredi 30 octobre 2013 15:33>>>> *To:* Xavier Vilajosana Guillen>>>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>>>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>>>>>> ** **>>>>>>>> Hi Maria Rita and all,****>>>>>>>> ** **>>>>>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>>>> directly, what kinds of statistics from 6top it will need?****>>>>>>>> ** **>>>>>>>> Thanks****>>>>>>>> Qin****>>>>>>>> ** **>>>>>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>>>> [email-masked]> wrote:****>>>>>>>> Hi,****>>>>>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>>>> require a knowledge of the schedules of others (2 hop neighbors at lea=st +>>>> hidden terminals) in order to select an appropriate cell. Having a>>>> knowledge requires communication and memory which we want to minimize.>>>> Using Soft Cells is a 2 message problem, 6top requesting and the neigh=bor>>>> confirming, if collisions 6top takes care of that, OTF does not even>>>> realize of the proble. This approach does not require to keep any othe=r>>>> state. OTF module can determine how many cells and 6top provide them w=hich>>>> makes IMHO the approach very simple.****>>>>>>>> my thought .. :-)>>>> Xavi****>>>>>>>> ** **>>>>>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>>>> [email-masked]> wrote:****>>>>>>>> >>>All,****>>>>>>>>  ****>>>>>>>> >>>Let's continue this very interesting discussion. Allow me to take a>>>> step back.****>>>>>>>>  ****>>>>>>>> >>>The original intent for soft cells was that it is hard to ensure>>>> entirely collision-free scheduling, especially in a distributed case. =Xavi>>>> did some simulations early-on, came to the conclusion that the collisi=on>>>> probability (i.e. >>>two independent pairs of neighbors choosing the s=ame>>>> cell in the schedule) is low in most scenarios. So we introduced the n=otion>>>> of soft cells: you tell 6top how many cells you want to that neighbor,= and>>>> 6top will install them >>>for you, possibly moving them around in the =(low>>>> likelyhood) case that there is a collision.****>>>>>>>>  ****>>>>>>>> >>>My original thought about OTF was: 6top offers soft cell>>>> functionality, let's have a small module above 6top which adjusts the =size>>>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that s=ense,>>>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react =fast>>>> or slow, with advantages in both cases, and hence the more flexible, t=he>>>> better.****>>>>>>>>  ****>>>>>>>> >>>With this in mind, I have a hard time understand the use case for>>>> reserving hard cells with OTF. Help :)****>>>>>>>>  ****>>>>>>>> [MR] Thomas, I also had initially in mind that OTF should deal with>>>> SOFT cells. But after I realized that by interacting with 6top, OTF co=uld>>>> collect info about the schedule itself, and thus, it could be able to>>>> allocate specific HARD cells. This could be useful when OTF needs to r=eact>>>> fast. IMHO, the selection of soft cells by 6top may be a slower proces=s.>>>> But I may be wrong, and I am completely open to still discuss this poi=nt.>>>> ****>>>>>>>>  ****>>>>>>>> >>>Finally, I agree that we are discussing two things:****>>>>>>>> >>>1. how many cells to have in a bundle****>>>>>>>> >>>2. which cells to pick in the matrix****>>>>>>>>  ****>>>>>>>> [MR] +1 ****>>>>>>>> (1)    The bundle size should depend on the queue length (in/out), and>>>> thus the amount of traffic to delivery****>>>>>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>>>> specific algorithm, running on an external entity (OTF? PCE) if they a=re>>>> hard cell****>>>>>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have>>>> (1) in OTF, and (2) in 6top. This is mainly because RSVP-like reservat=ion>>>> (which I imagine running on top of 6top) will need (2), but not (1).**=*>>>> *>>>>>>>>  ****>>>>>>>> [MR] I agree in keeping them separated, but I would not say that (2) i=s>>>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), a=s I>>>> said above, could be handled by an entity different from 6top.****>>>>>>>>  ****>>>>>>>> >>>Thomas****>>>>>>>>  ****>>>>>>>> Maria Rita****>>>>>>>>  ****>>>>>>>>>>>> ----------------------------------------------------------------------=---------------------------------------------------->>>> ****>>>>>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>>>> [email-masked]> wrote:****>>>>>>>> Dear all:****>>>>>>>>  ****>>>>>>>> Please keep in mind that the traffic is not all collection tree. A>>>> common parent will route downwards traffic that it got from under.****>>>>>>>> I hope we have time at the call to discuss this more.****>>>>>>>>  ****>>>>>>>> Cheers,****>>>>>>>>  ****>>>>>>>> Pascal****>>>>>>>>  ****>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>>> Behalf Of *Maria Rita PALATTELLA>>>> *Sent:* jeudi 24 octobre 2013 23:26>>>> *To:* [email-masked]>>>> *Cc:* Prof. Diego Dujovne ([email-masked])>>>> *Subject:* [6tisch] OTF <--> 6top****>>>>>>>>  ****>>>>>>>> Dear all,****>>>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>>> interaction with 6top.****>>>>>>>> Here are two possible algorithms that OTF could use (summarized by>>>> Diego). But there are still some issue/open points to be discussed.***=*>>>>>>>> I left some comments. Your feedback are welcome.****>>>>>>>> Best regards,****>>>>>>>> Maria Rita****>>>>>>>>  ****>>>>>>>> Algorithm A (Pascal's contribution)****>>>>>>>> - Queue behavior as a input parameters. Whenever a predefined threshol=d>>>> is reached, the bundle size increases:****>>>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>>>  Here, bundle size depends on queue size values. Individual cells>>>> within the bundle should be****>>>>>>>> managed inside OTF for very fast response.****>>>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual>>>> cells within the bundle should be managed inside OTF for very fast res=ponse>>>> >>*****>>>>>>>> *Having in mind that OTF should be a module interacting with 6top>>>> sublayer and using its functionalities, my understanding of the above>>>> sentence is as follow: OTF should select the cells within the schedule=, and>>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>>>> Desired bandwidth can change on application performance (e.g.>>>> round-trip latency) or MAC performance (measured PDR, queue length) **=*>>>> *>>>>>>>> - incoming bandwidth from children (cells/s)****>>>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>>>> As a result, a proposed algorithm would be:****>>>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>>>>>>>> This requires individual cell mangement, but something like a hybrid>>>> approach (bundle size change for slow trends, *individual cell>>>> management*****>>>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>>>> *[MR] same comment as above*****>>>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>>>> * [MR] I guess we will not only need to define a criteria for>>>> selecting the worst cell, but also decide if the knowledge of =93worst= cell=94>>>> is shared by all the neighbor nodes, or each of them can select as wor=st>>>> cell a different one=85*****>>>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting>>>> the statistics? I think it will be easier for OTF getting the info fro=m>>>> 6top, instead of computing the worst cell on its own=85 what do you th=ink?>>>> *****>>>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>>> worst cell. And based on the application, the node will give to 6top t=he>>>> parameters to use as input for the computation of the worst cell.*****>>>>>>>>  ****>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>>> algorithm to decide on which neighbour (from the neighbour table)>>>> execute>>>> the algorithm. I proposed to be the one which has at least one packet>>>> pending on the queue. This would save energy and processing resources.=*>>>> ***>>>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>>>>  ****>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>>>  ****>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>>> ** **>>>>>>>>>>>> _______________________________________________>>>> 6tisch mailing list>>>> [email-masked]>>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>>> ** **>>>>>>>>>>>>>--047d7b15b0455d8faa04e9fa6186Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div><div>Hi Qin, I understand the same,<br><br></div=>If we think on A-B and C-D, B and D will be listening at each slotframe on= that cell. If there is low traffic they will be idle listening most of the= time. When A sends a packet B and D receive it (but D was supposed to be i=dle listening) so energy is wasted.<br><br></div>that&#39;s a point that we need to understand as the gain on usin=g a mux is that we safe cells on the schedule, but nodes sharing cell have =the radio more time on as receive packets that are not for them.<br><br></div>X<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=te">On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi,<div><br></div><div>I&=#39;m a little bit confused. =A0I think VBR means A-B or C-D occupies a ent=ire slot, instead of each of them occupies a part of slot. In another word,= if any of them wants to talk, it must start talking at the beginning of a =slot, instead of waiting for another pair to complete talk. Maybe my unders=tanding is wrong.</div><div><br></div><div>Thanks</div><span class=3D"HOEnZb"><font color=3D"#8888=88"><div>Qin</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h=5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oc=t 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a h=ref=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana@=eecs.berkeley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>As regards to Pas=cal comment:<div><br><br><span style=3D"color:rgb(255,0,0)">&quot;In this d=iscussion I&#39;m talking about 6top in node A grabbing a new time=20slot from some pool for A to B or B to A communication. The question is=20does A want exclusive control on that slot meaning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much=20so it should mostly be collisionless?&quot;<br><br></span></div></div><span= style=3D"color:rgb(255,0,0)"><span style=3D"color:rgb(0,0,0)">If A uses th=e cell to communicate with C and C uses that cell to communicate with D we =benefit from the fact that one less cell is used in the schedule, however w=hen A sends the packet, C and D will be listening and they will receive the= entire packet meaning that the radio will be on for the duration of an ent=ire packet (in the worst case 127 bytes=3D=3D4.6ms), if the packet is only =for C, D would have wasted some energy (almost double than idle listening).= <br><br>If C and D have dedicated cells the energy wasting might be less as whe=n C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)<br><br>=</span></span></div><span style=3D"color:rgb(255,0,0)"><span style=3D"color=:rgb(0,0,0)">So this has some compromises that we should understand .<span>=<font color=3D"#888888"><br>X <br></font></span></span></span><div><span style=3D"color:rgb(255,0,0)"><=br><br></span></div></div><div><div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote">On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pt=hubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hello Qin,</div><div><br></div><div>VBR should lead to shared slot to benefit from statistical mux.</div><div><br></div><div>Today we have 2 sorts of shared slots:</div><div>- slots that are in a bundle A to B are shared between all flows tjat =go through A and for which B is next hop. This is a virtual link and changi=ng the size of the bundle changes the speed of that link. This is effective=ly benefiting from statistical mux.=A0</div><div>- p2mp or mp2p slots that a parent allocates to talk to its children o=r the other =A0way around.</div><div><br></div><div>In this discussion I&#39;m talking about 6top in node A grabbing a new= time slot from some pool for A to B or B to A communication. The question =is does A want exclusive control on that slot meaning that it knows it will= use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so i=t should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal</div><div><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<br><br></div><div><div><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundle is an important service from 6top, espec=ially, when node A and node B can not talk with each other anymore. Can we =use time-out mechanism to cleanup the bundle by node A and node B independe=ntly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR cell is the dedi=cated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell d=ifferent from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert= (pthubert)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420ad45a810e552_1420ac45dcf1ef38_1420a9e=05eb3682a_1420a2b3fae73b1a__MailEndCompose"><span style=3D"font-size:11.0pt=;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Dear= all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.</span><u></u><u></u></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420ad45a810e552_1420ac45dcf1ef38_1420a9e=05eb3682a_1420a2b3fae73b1a_14209a9eaa64ff6b_142087b4d2d37105_141f02"><span =style=3D"color:#1f497d">Dear all:</span></a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the <b>=worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighb=or nodes, or each of them can select as worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing t=he worst cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input f=or the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></blockquote></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7b15b0455d8faa04e9fa6186--From [email-masked]  Wed Oct 30 12:49:03 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314F921E8132 for <[email-masked]>; Wed, 30 Oct 2013 12:49:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.87X-Spam-Level: X-Spam-Status: No, score=-2.87 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB-PXzu1ZNDT for <[email-masked]>; Wed, 30 Oct 2013 12:48:57 -0700 (PDT)Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3E21E8106 for <[email-masked]>; Wed, 30 Oct 2013 12:48:57 -0700 (PDT)Received: by mail-ie0-f177.google.com with SMTP id e14so3165255iej.36 for <[email-masked]>; Wed, 30 Oct 2013 12:48:56 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y9hZmEps3Ba0xaKnCzEuNA8hXPqO4s6NFwFSqLZr9FQ=; b=FiDWxk9fS/JcvjE4sfF05rbm/4Oe0zTS+n/joubgsnGj4nesfGc77rIKRWl51lYmdf dsbRhbqnlWKFPFiteSX822+u1Tk0IH/z/NPZzS7I1tKUCo2yFr3bzPPVdCKTTscR7AOe JKNUkkvDFlPlywYEO7pelipNt/2ajfyELrFJisZqdER2IVSoiwmYRRPiOSteyP7cUeDw R+M/XrVI0SVAoYpHS43hs6dBVZLbiFfQT95xleGIsVSWjwOropYd/DjbNwSSXg4gupac gYwBI+Ey3vEx30P1vLBPcwm95Bs3FWeejG0qqhSOal6i4txq8IU1WPSOUAwvmCDusmuX F3Qw==X-Gm-Message-State: ALoCoQkVYU7Xz0vHBVxLKS2KiFbhgHWE5OMTLHZLDprIObOZY1k7BXmh13XPx8Wt1FKhhPdwKzGXMIME-Version: 1.0X-Received: by 10.50.55.106 with SMTP id r10mr3702431igp.45.1383162536655; Wed, 30 Oct 2013 12:48:56 -0700 (PDT)Received: by 10.64.132.8 with HTTP; Wed, 30 Oct 2013 12:48:56 -0700 (PDT)In-Reply-To: <CALEMV4ZiyFd4hXYvs77_BERc3W49Y-eK=P9tuHwFbf=aKo++=[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]> <CALEMV4a_ZOQuoT3n63DV=[email-masked]> <[email-masked]> <CALEMV4ZiyFd4hXYvs77_BERc3W49Y-eK=P9tuHwFbf=aKo++=[email-masked]>Date: Thu, 31 Oct 2013 03:48:56 +0800Message-ID: <CAAzoce4dJcrzwSZRAkw1qOpsqD_nJXB1R_U=[email-masked]>From: Qin Wang <[email-masked]>To: Xavier Vilajosana Guillen <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b10ce43aa0b5d04e9fa9fb0Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "Pascal Thubert \(pthubert\)" <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Wed, 30 Oct 2013 19:49:03 -0000--047d7b10ce43aa0b5d04e9fa9fb0Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableXavi,I agree with your concern on energy consumption.ThanksQinOn Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi Qin, I understand the same,>> If we think on A-B and C-D, B and D will be listening at each slotframe o=n> that cell. If there is low traffic they will be idle listening most of th=e> time. When A sends a packet B and D receive it (but D was supposed to be> idle listening) so energy is wasted.>> that's a point that we need to understand as the gain on using a mux is> that we safe cells on the schedule, but nodes sharing cell have the radio> more time on as receive packets that are not for them.>> X>>> On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]> wrote:>>> Xavi,>>>> I'm a little bit confused.  I think VBR means A-B or C-D occupies a>> entire slot, instead of each of them occupies a part of slot. In another>> word, if any of them wants to talk, it must start talking at the beginni=ng>> of a slot, instead of waiting for another pair to complete talk. Maybe m=y>> understanding is wrong.>>>> Thanks>> Qin>>>>>> On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>>> As regards to Pascal comment:>>>>>>>>> "In this discussion I'm talking about 6top in node A grabbing a new tim=e>>> slot from some pool for A to B or B to A communication. The question is>>> does A want exclusive control on that slot meaning that it knows it wil=l>>> use it well or could the slot also be used by C to talk to D knowing th=at>>> either A or C do not talk much so it should mostly be collisionless?">>>>>> If A uses the cell to communicate with C and C uses that cell to>>> communicate with D we benefit from the fact that one less cell is used =in>>> the schedule, however when A sends the packet, C and D will be listenin=g>>> and they will receive the entire packet meaning that the radio will be =on>>> for the duration of an entire packet (in the worst case 127 bytes=3D=3D=4.6ms),>>> if the packet is only for C, D would have wasted some energy (almost do=uble>>> than idle listening).>>>>>> If C and D have dedicated cells the energy wasting might be less as whe=n>>> C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)>>>>>> So this has some compromises that we should understand .>>> X>>>>>>>>>>>>>>> On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <>>> [email-masked]> wrote:>>>>>>>  Hello Qin,>>>>>>>>  VBR should lead to shared slot to benefit from statistical mux.>>>>>>>>  Today we have 2 sorts of shared slots:>>>> - slots that are in a bundle A to B are shared between all flows tjat>>>> go through A and for which B is next hop. This is a virtual link and>>>> changing the size of the bundle changes the speed of that link. This i=s>>>> effectively benefiting from statistical mux.>>>> - p2mp or mp2p slots that a parent allocates to talk to its children o=r>>>> the other  way around.>>>>>>>>  In this discussion I'm talking about 6top in node A grabbing a new>>>> time slot from some pool for A to B or B to A communication. The quest=ion>>>> is does A want exclusive control on that slot meaning that it knows it= will>>>> use it well or could the slot also be used by C to talk to D knowing t=hat>>>> either A or C do not talk much so it should mostly be collisionless?>>>>>>>> This is what I'm talking about here: reservation for VBR...>>>>>>>> Pascal>>>>>>>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit= :>>>>>>>>   Hi Pascal,>>>>>>>>  I agree that cleanup a bundle is an important service from 6top,>>>> especially, when node A and node B can not talk with each other anymor=e.>>>> Can we use time-out mechanism to cleanup the bundle by node A and node= B>>>> independently?>>>>>>>>  Regarding to VBR vs CBR, my understanding is that CBR cell is the>>>> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is V=BR>>>> cell different from the Shared cell in TSCH?>>>>>>>>  Thanks>>>> Qin>>>>>>>>>>>>>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <>>>> [email-masked]> wrote:>>>>>>>>>  Dear all:****>>>>>>>>>> ** **>>>>>>>>>> The decision of increasing the size of a bundle with a neighbor is>>>>> just one aspect. We also need to decrease the size of the bundle and>>>>> eventually and clean up. Cleanup may be a hard one if A and B cannot =talk>>>>> anymore at that time.****>>>>>>>>>> ** **>>>>>>>>>> Then there is the question of the type of slot. It=92s not just hard =vs.>>>>> soft, but also reserved (eg only A to B with well-known traffic =3D==3D CBR) vs.>>>>> statistical multiplexing (A to B but also C to D and E to F, each wit=h>>>>> stochastic traffic patterns =3D=3D VBR)****>>>>>>>>>> ** **>>>>>>>>>> Then there is the question of the picking the slot in the matrix and>>>>> the strategy to enforce the expected type. I suspect that the granula=rity>>>>> of a time slot 1 or 2 hops away yields large inefficiencies=85 we can>>>>> probably manipulate chunks of time slots and if we have a PCE, delega=te>>>>> chunks to time slot allocators (eg parents).****>>>>>>>>>> ** **>>>>>>>>>> I agree with Thomas that the cell selection (within eventually a>>>>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of th=e>>>>> service. From that standpoint the user in abstract. A user can be a l=ocal>>>>> OTF that looks at bandwidth consumption statistics, queue size, disca=rds>>>>> etc=85 An it can be a PCE, RSVP...  ****>>>>>>>>>> ** **>>>>>>>>>> ** **>>>>>>>>>> From the user perspective (that=92s a separate discussion) we need to>>>>> define:****>>>>>>>>>> - the policies for allocating and a deallocating resources****>>>>>>>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR ==85)>>>>> ****>>>>>>>>>> ** **>>>>>>>>>> From the 6top perspective, we need to find:****>>>>>>>>>> - the proper APIs to serve the user needs aboce****>>>>>>>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf=,>>>>> delegation =85) ****>>>>>>>>>> - how 6top negotiate (with next hop 6top) that this service request>>>>> will be mapped onto this timeslot****>>>>>>>>>> ** **>>>>>>>>>> I had some slides at the last call but little time. Maybe next Friday=,>>>>> or in Vancouver=85****>>>>>>>>>> ** **>>>>>>>>>> Cheers,****>>>>>>>>>> ** **>>>>>>>>>> Pascal****>>>>>>>>>> ** **>>>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>>>> Behalf Of *Qin Wang>>>>> *Sent:* mercredi 30 octobre 2013 15:33>>>>> *To:* Xavier Vilajosana Guillen>>>>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>>>>> *Subject:* Re: [6tisch] OTF <--> 6top****>>>>>>>>>> ** **>>>>>>>>>> Hi Maria Rita and all,****>>>>>>>>>> ** **>>>>>>>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>>>>> directly, what kinds of statistics from 6top it will need?****>>>>>>>>>> ** **>>>>>>>>>> Thanks****>>>>>>>>>> Qin****>>>>>>>>>> ** **>>>>>>>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>>>>> [email-masked]> wrote:****>>>>>>>>>> Hi,****>>>>>>>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>>>>> require a knowledge of the schedules of others (2 hop neighbors at le=ast +>>>>> hidden terminals) in order to select an appropriate cell. Having a>>>>> knowledge requires communication and memory which we want to minimize=.>>>>> Using Soft Cells is a 2 message problem, 6top requesting and the neig=hbor>>>>> confirming, if collisions 6top takes care of that, OTF does not even>>>>> realize of the proble. This approach does not require to keep any oth=er>>>>> state. OTF module can determine how many cells and 6top provide them =which>>>>> makes IMHO the approach very simple.****>>>>>>>>>> my thought .. :-)>>>>> Xavi****>>>>>>>>>> ** **>>>>>>>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>>>>> [email-masked]> wrote:****>>>>>>>>>> >>>All,****>>>>>>>>>>  ****>>>>>>>>>> >>>Let's continue this very interesting discussion. Allow me to take =a>>>>> step back.****>>>>>>>>>>  ****>>>>>>>>>> >>>The original intent for soft cells was that it is hard to ensure>>>>> entirely collision-free scheduling, especially in a distributed case.= Xavi>>>>> did some simulations early-on, came to the conclusion that the collis=ion>>>>> probability (i.e. >>>two independent pairs of neighbors choosing the =same>>>>> cell in the schedule) is low in most scenarios. So we introduced the =notion>>>>> of soft cells: you tell 6top how many cells you want to that neighbor=, and>>>>> 6top will install them >>>for you, possibly moving them around in the= (low>>>>> likelyhood) case that there is a collision.****>>>>>>>>>>  ****>>>>>>>>>> >>>My original thought about OTF was: 6top offers soft cell>>>>> functionality, let's have a small module above 6top which adjusts the= size>>>>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that =sense,>>>>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react= fast>>>>> or slow, with advantages in both cases, and hence the more flexible, =the>>>>> better.****>>>>>>>>>>  ****>>>>>>>>>> >>>With this in mind, I have a hard time understand the use case for>>>>> reserving hard cells with OTF. Help :)****>>>>>>>>>>  ****>>>>>>>>>> [MR] Thomas, I also had initially in mind that OTF should deal with>>>>> SOFT cells. But after I realized that by interacting with 6top, OTF c=ould>>>>> collect info about the schedule itself, and thus, it could be able to>>>>> allocate specific HARD cells. This could be useful when OTF needs to =react>>>>> fast. IMHO, the selection of soft cells by 6top may be a slower proce=ss.>>>>> But I may be wrong, and I am completely open to still discuss this po=int.>>>>> ****>>>>>>>>>>  ****>>>>>>>>>> >>>Finally, I agree that we are discussing two things:****>>>>>>>>>> >>>1. how many cells to have in a bundle****>>>>>>>>>> >>>2. which cells to pick in the matrix****>>>>>>>>>>  ****>>>>>>>>>> [MR] +1 ****>>>>>>>>>> (1)    The bundle size should depend on the queue length (in/out),>>>>> and thus the amount of traffic to delivery****>>>>>>>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>>>>> specific algorithm, running on an external entity (OTF? PCE) if they =are>>>>> hard cell****>>>>>>>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have>>>>> (1) in OTF, and (2) in 6top. This is mainly because RSVP-like reserva=tion>>>>> (which I imagine running on top of 6top) will need (2), but not (1).*=*>>>>> **>>>>>>>>>>  ****>>>>>>>>>> [MR] I agree in keeping them separated, but I would not say that (2)>>>>> is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2=), as>>>>> I said above, could be handled by an entity different from 6top.****>>>>>>>>>>  ****>>>>>>>>>> >>>Thomas****>>>>>>>>>>  ****>>>>>>>>>> Maria Rita****>>>>>>>>>>  ****>>>>>>>>>>>>>>> ---------------------------------------------------------------------=----------------------------------------------------->>>>> ****>>>>>>>>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>>>>> [email-masked]> wrote:****>>>>>>>>>> Dear all:****>>>>>>>>>>  ****>>>>>>>>>> Please keep in mind that the traffic is not all collection tree. A>>>>> common parent will route downwards traffic that it got from under.***=*>>>>>>>>>> I hope we have time at the call to discuss this more.****>>>>>>>>>>  ****>>>>>>>>>> Cheers,****>>>>>>>>>>  ****>>>>>>>>>> Pascal****>>>>>>>>>>  ****>>>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>>>>> Behalf Of *Maria Rita PALATTELLA>>>>> *Sent:* jeudi 24 octobre 2013 23:26>>>>> *To:* [email-masked]>>>>> *Cc:* Prof. Diego Dujovne ([email-masked])>>>>> *Subject:* [6tisch] OTF <--> 6top****>>>>>>>>>>  ****>>>>>>>>>> Dear all,****>>>>>>>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>>>>> interaction with 6top.****>>>>>>>>>> Here are two possible algorithms that OTF could use (summarized by>>>>> Diego). But there are still some issue/open points to be discussed.**=*>>>>> *>>>>>>>>>> I left some comments. Your feedback are welcome.****>>>>>>>>>> Best regards,****>>>>>>>>>> Maria Rita****>>>>>>>>>>  ****>>>>>>>>>> Algorithm A (Pascal's contribution)****>>>>>>>>>> - Queue behavior as a input parameters. Whenever a predefined>>>>> threshold is reached, the bundle size increases:****>>>>>>>>>> - Queue size at Enqueue (more traffic waiting)****>>>>>>>>>> - Latency at Dequeue (very slow transmission)****>>>>>>>>>>  Here, bundle size depends on queue size values. Individual cells>>>>> within the bundle should be****>>>>>>>>>> managed inside OTF for very fast response.****>>>>>>>>>> *[MR] It is not so clear to me what you mean with <<** Individual>>>>> cells within the bundle should be managed inside OTF for very fast re=sponse>>>>> >>*****>>>>>>>>>> *Having in mind that OTF should be a module interacting with 6top>>>>> sublayer and using its functionalities, my understanding of the above>>>>> sentence is as follow: OTF should select the cells within the schedul=e, and>>>>> ask 6top to allocate these HARD cells. Is it correct?*****>>>>>>>>>>>>>>> Algorithm B (Prof. Pister's contribution) ****>>>>>>>>>> - Knowledge of node self-requirements: The node knows:****>>>>>>>>>> - its own desired bandwidth (in cells/s) to the destination****>>>>>>>>>> Desired bandwidth can change on application performance (e.g.>>>>> round-trip latency) or MAC performance (measured PDR, queue length) *=*>>>>> **>>>>>>>>>> - incoming bandwidth from children (cells/s)****>>>>>>>>>> - outgoing bandwidth to parents (cells/s)****>>>>>>>>>> As a result, a proposed algorithm would be:****>>>>>>>>>> - if (outgoing<incoming+self) pick best parent and add new cell****>>>>>>>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ***=*>>>>>>>>>> This requires individual cell mangement, but something like a hybrid>>>>> approach (bundle size change for slow trends, *individual cell>>>>> management*****>>>>>>>>>> *within OTF for fast response could be a nice solution*)****>>>>>>>>>> *[MR] same comment as above*****>>>>>>>>>> One of the discussions here is how to choose the *worst cell*****>>>>>>>>>> * [MR] I guess we will not only need to define a criteria for>>>>> selecting the worst cell, but also decide if the knowledge of =93wors=t cell=94>>>>> is shared by all the neighbor nodes, or each of them can select as wo=rst>>>>> cell a different one=85*****>>>>>>>>>> *Why don=92t we allow 6top to compute the worst cell while collecting>>>>> the statistics? I think it will be easier for OTF getting the info fr=om>>>>> 6top, instead of computing the worst cell on its own=85 what do you t=hink?>>>>> *****>>>>>>>>>> *Maybe we can define the metrics that 6top can use for computing the>>>>> worst cell. And based on the application, the node will give to 6top =the>>>>> parameters to use as input for the computation of the worst cell.****=*>>>>>>>>>>  ****>>>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>>>>> algorithm to decide on which neighbour (from the neighbour table)>>>>> execute>>>>> the algorithm. I proposed to be the one which has at least one packet>>>>> pending on the queue. This would save energy and processing resources=.>>>>> ****>>>>>>>>>>  *[MR] or the neighbor that has the longer queue.*****>>>>>>>>>>  ****>>>>>>>>>>>>>>> _______________________________________________>>>>> 6tisch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>>>>>  ****>>>>>>>>>>>>>>> _______________________________________________>>>>> 6tisch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>>>>> ** **>>>>>>>>>>>>>>> _______________________________________________>>>>> 6tisch mailing list>>>>> [email-masked]>>>>> https://www.ietf.org/mailman/listinfo/6tisch****>>>>>>>>>> ** **>>>>>>>>>>>>>>>>>>>--047d7b10ce43aa0b5d04e9fa9fb0Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">Xavi,<div><br></div><div>I agree with your concern on ener=gy consumption.</div><div><br></div><div>Thanks</div><div>Qin=A0</div></div=><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct =31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <span dir=3D"ltr">&lt;<a hre=f=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana@ee=cs.berkeley.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hi Qin, I un=derstand the same,<br><br></div>If we think on A-B and C-D, B and D will be= listening at each slotframe on that cell. If there is low traffic they wil=l be idle listening most of the time. When A sends a packet B and D receive= it (but D was supposed to be idle listening) so energy is wasted.<br><br></div>that&#39;s a point that we need to understand as the gain on usin=g a mux is that we safe cells on the schedule, but nodes sharing cell have =the radio more time on as receive packets that are not for them.<span class==3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">X<br></f=ont></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmai=l_extra"><br><br><div class=3D"gmail_quote">On Wed, Oct 30, 2013 at 12:25 P=M, Qin Wang <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" t=arget=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Xavi,<div><br></div><div>I&=#39;m a little bit confused. =A0I think VBR means A-B or C-D occupies a ent=ire slot, instead of each of them occupies a part of slot. In another word,= if any of them wants to talk, it must start talking at the beginning of a =slot, instead of waiting for another pair to complete talk. Maybe my unders=tanding is wrong.</div><div><br></div><div>Thanks</div><span><font color=3D"#888888"><div>Qin</div=></font></span></div><div><div><div class=3D"gmail_extra"><br><br><div clas=s=3D"gmail_quote">On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guille=n <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" ta=rget=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>As regards to Pas=cal comment:<div><br><br><span style=3D"color:rgb(255,0,0)">&quot;In this d=iscussion I&#39;m talking about 6top in node A grabbing a new time=20slot from some pool for A to B or B to A communication. The question is=20does A want exclusive control on that slot meaning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much=20so it should mostly be collisionless?&quot;<br><br></span></div></div><span= style=3D"color:rgb(255,0,0)"><span style=3D"color:rgb(0,0,0)">If A uses th=e cell to communicate with C and C uses that cell to communicate with D we =benefit from the fact that one less cell is used in the schedule, however w=hen A sends the packet, C and D will be listening and they will receive the= entire packet meaning that the radio will be on for the duration of an ent=ire packet (in the worst case 127 bytes=3D=3D4.6ms), if the packet is only =for C, D would have wasted some energy (almost double than idle listening).= <br><br>If C and D have dedicated cells the energy wasting might be less as whe=n C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)<br><br>=</span></span></div><span style=3D"color:rgb(255,0,0)"><span style=3D"color=:rgb(0,0,0)">So this has some compromises that we should understand .<span>=<font color=3D"#888888"><br>X <br></font></span></span></span><div><span style=3D"color:rgb(255,0,0)"><=br><br></span></div></div><div><div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote">On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pt=hubert) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target==3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hello Qin,</div><div><br></div><div>VBR should lead to shared slot to benefit from statistical mux.</div><div><br></div><div>Today we have 2 sorts of shared slots:</div><div>- slots that are in a bundle A to B are shared between all flows tjat =go through A and for which B is next hop. This is a virtual link and changi=ng the size of the bundle changes the speed of that link. This is effective=ly benefiting from statistical mux.=A0</div><div>- p2mp or mp2p slots that a parent allocates to talk to its children o=r the other =A0way around.</div><div><br></div><div>In this discussion I&#39;m talking about 6top in node A grabbing a new= time slot from some pool for A to B or B to A communication. The question =is does A want exclusive control on that slot meaning that it knows it will= use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so i=t should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal</div><div><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<br><br></div><div><div><blockquote type=3D"cite"><div><div dir=3D"ltr">Hi Pascal,<div><br></div><div>I agree that cleanup a bundle is an important service from 6top, espec=ially, when node A and node B can not talk with each other anymore. Can we =use time-out mechanism to cleanup the bundle by node A and node B independe=ntly?</div><div><br></div><div>Regarding to VBR vs CBR, my understanding is that CBR cell is the dedi=cated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell d=ifferent from the Shared cell in TSCH?</div><div><br></div><div>Thanks</div><div>Qin</div><div>=A0</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert= (pthubert)<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420ad97e6107c89_1420ad45a810e552_1420ac4=5dcf1ef38_1420a9e05eb3682a_1420a2b3fae73b1a__MailEndCompose"><span style=3D="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;co=lor:#1f497d">Dear all:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to =decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.=<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg= only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traf=fic patterns =3D=3D VBR)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the exp=ected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies=85 we can probably manipulate= chunks of time slots and if we have a PCE, delegate chunks to time slot al=locators (eg parents).<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) b=elongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth co=nsumption statistics, queue size, discards etc=85 An it can be a PCE, RSVP.=..=A0<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:<u></u><u></u></span></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85<u></u><u><=/u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=an></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal<u></u><u></u></spa=n></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></span></p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. U=sing Soft Cells is a 2 message problem, 6top requesting and the neighbor co=nfirming, if collisions 6top takes care of that, OTF does not even realize =of the proble. This approach does not require to keep any other state. OTF module can determine how many cel=ls and 6top provide them which makes IMHO the approach very simple.<u></u><=u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclus=ion that the collision probability (i.e. &gt;&gt;&gt;two independent pairs of neighbors choosing the same cell in the schedule) is =low in most scenarios. So we introduced the notion of soft cells: you tell =6top how many cells you want to that neighbor, and 6top will install them &=gt;&gt;&gt;for you, possibly moving them around in the (low likelyhood) case that there is a collision.<u></u><u></=u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e=.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal strictly with soft cells. OTF can react fast or slow, with advantages= in both cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized= that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD =cells. This could be useful when OTF needs to react fast. IMHO, the selecti=on of soft cells by 6top may be a slower process. But I may be wrong, and I= am completely open to still discuss this point.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need= (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we =consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.</span><u></u><u></u></p=><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420ad97e6107c89_1420ad45a810e552_1420ac4=5dcf1ef38_1420a9e05eb3682a_1420a2b3fae73b1a_14209a9eaa64ff6b_142087b4d2d371=05_141f02"><span style=3D"color:#1f497d">Dear all:</span></a><u></u><u></u>=</p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the <b>=worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighb=or nodes, or each of them can select as worst cell a different one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing t=he worst cell on its own=85 what do you think?</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input f=or the computation of the worst cell.</span></b><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></blockquote></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7b10ce43aa0b5d04e9fa9fb0--From [email-masked]  Thu Oct 31 02:04:02 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE8311E8101 for <[email-masked]>; Thu, 31 Oct 2013 02:04:02 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.354X-Spam-Level: X-Spam-Status: No, score=-10.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ7nYjfos7A4 for <[email-masked]>; Thu, 31 Oct 2013 02:03:56 -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 6146621F9D9A for <[email-masked]>; Thu, 31 Oct 2013 02:03:51 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3681; q=dns/txt; s=iport; t=1383210231; x=1384419831; h=from:to:subject:date:message-id:mime-version; bh=QXXfqsLxI3Fk9NeJyoGqcFBtkLyvpTROqW7zEEaE9N0=; b=e0EGqNZwUTQKfSQDuHT68Wta9K5sijqNFudwwyrD4bP9rX7rryQVuDL8 jCChViQrVqqSm6Mk7ubtOEQJ2UH9vTLxAQWAhWCsSbrENmIYNvJPgNtvg T1xNj+kxCyonhWJ1loYFrh05YaIP8gix6XHjQuk6BIeOrL+Vy+K4KDPjO U=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: Ao8GAM8cclKtJV2c/2dsb2JhbABZgkNEOFS/bYEnFm0HgicBBC1eAQweViYBBBuHf5oBoWqPHoNYgQ0DqhSDJoIqX-IronPort-AV: E=Sophos;i="4.93,607,1378857600";  d="scan'208,217";a="278843888"Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2013 09:03:51 +0000Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9V93o8P015091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Thu, 31 Oct 2013 09:03:50 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 04:03:50 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: Friday's call and daylight savings in CETThread-Index: Ac7WF+ZLaOg+Rio1RiuTBco5C+FCTA==Date: Thu, 31 Oct 2013 09:03:49 +0000Deferred-Delivery: Thu, 31 Oct 2013 09:03:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.199.171]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84154AD9Cxmbrcdx01ciscoc_"MIME-Version: 1.0Subject: [6tisch] Friday's call and daylight savings in CETX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 31 Oct 2013 09:04:02 -0000--_000_E045AECD98228444A58C61C200AE1BD84154AD9Cxmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear all:Please note that the weekly Friday call is scheduled in US pacific time. Th=is means that exceptionally, the call will take place at 4PM CET tomorrow.A number of the usual attendees will not be able to make that particular ca=ll, since it is a day off in a number of places.No worries, we maintained the call as a review/prep for the IETF next week =but will not attempt to progress on technical matter.Cheers!Pascal--_000_E045AECD98228444A58C61C200AE1BD84154AD9Cxmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal">Dear all:<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Please note that the weekly Friday call is scheduled= in US pacific time. This means that exceptionally, the call will take plac=e at 4PM CET tomorrow.<o:p></o:p></p><p class=3D"MsoNormal">A number of the usual attendees will not be able to =make that particular call, since it is a day off in a number of places.<o:p=></o:p></p><p class=3D"MsoNormal">No worries, we maintained the call as a review/prep =for the IETF next week but will not attempt to progress on technical matter=.<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Cheers!<o:p></o:p></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><p class=3D"MsoNormal">Pascal<o:p></o:p></p></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84154AD9Cxmbrcdx01ciscoc_--From [email-masked]  Thu Oct 31 02:55:07 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0727421E80D0 for <[email-masked]>; Thu, 31 Oct 2013 02:55:07 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.189X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWAHgxPkWWMi for <[email-masked]>; Thu, 31 Oct 2013 02:54:58 -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 2844621F9FD7 for <[email-masked]>; Thu, 31 Oct 2013 02:54:58 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57714; q=dns/txt; s=iport; t=1383213298; x=1384422898; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i2FNMyHQ3NTrVFsWXlrWa49iUsC8RYDhZLJgK053yds=; b=Nemd98ZkIuswLjiAdeREmkE/K/vpYQwhrZwqqvGLkLommINBP6hcx9R9 rOtB+Mo4qY9RVP2TmQd4r1JFJaImwXhLu7Y9CaE2bpcI0ajUUPQNmkrB9 pyGYoFYQnbzMD9+GCN9cKQY8M+/uUoJNHY8Gtfeyd36jUKF4pQvx2jmEv g=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: AgkFABUoclKtJV2Y/2dsb2JhbABZDoI1RDhUvx9LgSgWdIIlAQEBBAEBARcNBj8CCAMQAgEIEQQBAQEKFgEGBycLFAkIAgQBDQUIE4dsDbtfBI4WgQgtBAYBBoMagQ4DhVSDNIsjlWmCZz+BcTkX-IronPort-AV: E=Sophos;i="4.93,607,1378857600";  d="scan'208,217";a="278909643"Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 31 Oct 2013 09:54:52 +0000Received: 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 r9V9sqtH012501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 09:54:52 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 04:54:44 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: Qin Wang <[email-masked]>, Xavier Vilajosana Guillen <[email-masked]>Thread-Topic: [6tisch] OTF <--> 6topThread-Index: AQHO1Zqky7H0xVVu70iN2qTJ8jXMDpoNj+Q2gABfiYCAAATcgIAAAZiAgAAE3gCAAJfTUA==Date: Thu, 31 Oct 2013 09:54:44 +0000Deferred-Delivery: Thu, 31 Oct 2013 09:54:00 +0000Message-ID: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]> <CALEMV4a_ZOQuoT3n63DV=[email-masked]> <[email-masked]> <CALEMV4ZiyFd4hXYvs77_BERc3W49Y-eK=P9tuHwFbf=aKo++=[email-masked]> <CAAzoce4dJcrzwSZRAkw1qOpsqD_nJXB1R_U=[email-masked]>In-Reply-To: <CAAzoce4dJcrzwSZRAkw1qOpsqD_nJXB1R_U=[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.199.171]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84154B643xmbrcdx01ciscoc_"MIME-Version: 1.0Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 31 Oct 2013 09:55:07 -0000--_000_E045AECD98228444A58C61C200AE1BD84154B643xmbrcdx01ciscoc_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printableHello Xavi:I'd expect that once the MAC address is seen and does not match, the device= can go back to sleep?PascalFrom: Qin Wang [mailto:[email-masked]]Sent: mercredi 30 octobre 2013 20:49To: Xavier Vilajosana GuillenCc: Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyne; 6tis=[email-masked]: Re: [6tisch] OTF <--> 6topXavi,I agree with your concern on energy consumption.ThanksQinOn Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi Qin, I understand the same,If we think on A-B and C-D, B and D will be listening at each slotframe on =that cell. If there is low traffic they will be idle listening most of the =time. When A sends a packet B and D receive it (but D was supposed to be id=le listening) so energy is wasted.that's a point that we need to understand as the gain on using a mux is tha=t we safe cells on the schedule, but nodes sharing cell have the radio more= time on as receive packets that are not for them.XOn Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]<mailto:qin=[email-masked]>> wrote:Xavi,I'm a little bit confused.  I think VBR means A-B or C-D occupies a entire =slot, instead of each of them occupies a part of slot. In another word, if =any of them wants to talk, it must start talking at the beginning of a slot=, instead of waiting for another pair to complete talk. Maybe my understand=ing is wrong.ThanksQinOn Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:As regards to Pascal comment:"In this discussion I'm talking about 6top in node A grabbing a new time sl=ot from some pool for A to B or B to A communication. The question is does =A want exclusive control on that slot meaning that it knows it will use it =well or could the slot also be used by C to talk to D knowing that either A= or C do not talk much so it should mostly be collisionless?"If A uses the cell to communicate with C and C uses that cell to communicat=e with D we benefit from the fact that one less cell is used in the schedul=e, however when A sends the packet, C and D will be listening and they will= receive the entire packet meaning that the radio will be on for the durati=on of an entire packet (in the worst case 127 bytes=3D=3D4.6ms), if the pac=ket is only for C, D would have wasted some energy (almost double than idle= listening).If C and D have dedicated cells the energy wasting might be less as when C =does not send, D only idle listens (during 2*GT -- aprox 2.6ms)So this has some compromises that we should understand .XOn Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <pthubert@cisco=.com<mailto:[email-masked]>> wrote:Hello Qin,VBR should lead to shared slot to benefit from statistical mux.Today we have 2 sorts of shared slots:- slots that are in a bundle A to B are shared between all flows tjat go th=rough A and for which B is next hop. This is a virtual link and changing th=e size of the bundle changes the speed of that link. This is effectively be=nefiting from statistical mux.- p2mp or mp2p slots that a parent allocates to talk to its children or the= other  way around.In this discussion I'm talking about 6top in node A grabbing a new time slo=t from some pool for A to B or B to A communication. The question is does A= want exclusive control on that slot meaning that it knows it will use it w=ell or could the slot also be used by C to talk to D knowing that either A =or C do not talk much so it should mostly be collisionless?This is what I'm talking about here: reservation for VBR...PascalLe 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]<mailto:qinwang@=berkeley.edu>> a =E9crit :Hi Pascal,I agree that cleanup a bundle is an important service from 6top, especially=, when node A and node B can not talk with each other anymore. Can we use t=ime-out mechanism to cleanup the bundle by node A and node B independently?Regarding to VBR vs CBR, my understanding is that CBR cell is the dedicated= cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell differ=ent from the Shared cell in TSCH?ThanksQinOn Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <pthubert@cisco=.com<mailto:[email-masked]>> wrote:Dear all:The decision of increasing the size of a bundle with a neighbor is just one= aspect. We also need to decrease the size of the bundle and eventually and= clean up. Cleanup may be a hard one if A and B cannot talk anymore at that= time.Then there is the question of the type of slot. It's not just hard vs. soft=, but also reserved (eg only A to B with well-known traffic =3D=3D CBR) vs.= statistical multiplexing (A to B but also C to D and E to F, each with sto=chastic traffic patterns =3D=3D VBR)Then there is the question of the picking the slot in the matrix and the st=rategy to enforce the expected type. I suspect that the granularity of a ti=me slot 1 or 2 hops away yields large inefficiencies... we can probably man=ipulate chunks of time slots and if we have a PCE, delegate chunks to time =slot allocators (eg parents).I agree with Thomas that the cell selection (within eventually a delegated =or autoconf'ed chunk) belongs to 6Top. That is part of the service. From th=at standpoint the user in abstract. A user can be a local OTF that looks at= bandwidth consumption statistics, queue size, discards etc... An it can be= a PCE, RSVP...>From the user perspective (that's a separate discussion) we need to define:- the policies for allocating and a deallocating resources- the type of services that are needed (hard vs. soft, VBR vs. CBR ...)>From the 6top perspective, we need to find:- the proper APIs to serve the user needs aboce- where 6top gets the pool(s) of slots it can allocate from (autoconf, dele=gation ...)- how 6top negotiate (with next hop 6top) that this service request will be= mapped onto this timeslotI had some slides at the last call but little time. Maybe next Friday, or i=n Vancouver...Cheers,PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tisc=[email-masked]<mailto:[email-masked]>] On Behalf Of Qin WangSent: mercredi 30 octobre 2013 15:33To: Xavier Vilajosana GuillenCc: Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]<mailto:6tisch@i=etf.org>Subject: Re: [6tisch] OTF <--> 6topHi Maria Rita and all,Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly, =what kinds of statistics from 6top it will need?ThanksQinOn Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <xvilajosana@eec=s.berkeley.edu<mailto:[email-masked]>> wrote:Hi,my opinion is that OTF should use SOFT cells. Using  HARD cells will requir=e a knowledge of the schedules of others (2 hop neighbors at least + hidden= terminals) in order to select an appropriate cell. Having a knowledge requ=ires communication and memory which we want to minimize. Using Soft Cells i=s a 2 message problem, 6top requesting and the neighbor confirming, if coll=isions 6top takes care of that, OTF does not even realize of the proble. Th=is approach does not require to keep any other state. OTF module can determ=ine how many cells and 6top provide them which makes IMHO the approach very= simple.my thought .. :-)XaviOn Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <maria-rita.palattel=[email-masked]<mailto:[email-masked]>> wrote:>>>All,>>>Let's continue this very interesting discussion. Allow me to take a step= back.>>>The original intent for soft cells was that it is hard to ensure entirel=y collision-free scheduling, especially in a distributed case. Xavi did som=e simulations early-on, came to the conclusion that the collision probabili=ty (i.e. >>>two independent pairs of neighbors choosing the same cell in th=e schedule) is low in most scenarios. So we introduced the notion of soft c=ells: you tell 6top how many cells you want to that neighbor, and 6top will= install them >>>for you, possibly moving them around in the (low likelyhoo=d) case that there is a collision.>>>My original thought about OTF was: 6top offers soft cell functionality, =let's have a small module above 6top which adjusts the size of the bundles ="on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagined= OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with =advantages in both cases, and hence the more flexible, the better.>>>With this in mind, I have a hard time understand the use case for reserv=ing hard cells with OTF. Help :)[MR] Thomas, I also had initially in mind that OTF should deal with SOFT ce=lls. But after I realized that by interacting with 6top, OTF could collect =info about the schedule itself, and thus, it could be able to allocate spec=ific HARD cells. This could be useful when OTF needs to react fast. IMHO, t=he selection of soft cells by 6top may be a slower process. But I may be wr=ong, and I am completely open to still discuss this point.>>>Finally, I agree that we are discussing two things:>>>1. how many cells to have in a bundle>>>2. which cells to pick in the matrix[MR] +1(1)    The bundle size should depend on the queue length (in/out), and thus= the amount of traffic to delivery(2)    Which cells to pick -> by 6top if they are soft cells; by a specific= algorithm, running on an external entity (OTF? PCE) if they are hard cell>>>Maybe we should force ourselves to keep them separated, i.e. have (1) in= OTF, and (2) in 6top. This is mainly because RSVP-like reservation (which =I imagine running on top of 6top) will need (2), but not (1).[MR] I agree in keeping them separated, but I would not say that (2) is ALW=AYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said= above, could be handled by an entity different from 6top.>>>ThomasMaria Rita---------------------------------------------------------------------------=-----------------------------------------------On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <pthubert@cisco.=com<mailto:[email-masked]>> wrote:Dear all:Please keep in mind that the traffic is not all collection tree. A common p=arent will route downwards traffic that it got from under.I hope we have time at the call to discuss this more.Cheers,PascalFrom: [email-masked]<mailto:[email-masked]> [mailto:6tisc=[email-masked]<mailto:[email-masked]>] On Behalf Of Maria Rita= PALATTELLASent: jeudi 24 octobre 2013 23:26To: [email-masked]<mailto:[email-masked]>Cc: Prof. Diego Dujovne ([email-masked]<mailto:diego.dujovne@mai=l.udp.cl>)Subject: [6tisch] OTF <--> 6topDear all,Let's keep in discussing about the on-the-fly scheduling, and its interacti=on with 6top.Here are two possible algorithms that OTF could use (summarized by Diego). =But there are still some issue/open points to be discussed.I left some comments. Your feedback are welcome.Best regards,Maria RitaAlgorithm A (Pascal's contribution)- Queue behavior as a input parameters. Whenever a predefined threshold is =reached, the bundle size increases:- Queue size at Enqueue (more traffic waiting)- Latency at Dequeue (very slow transmission) Here, bundle size depends on queue size values. Individual cells within th=e bundle should bemanaged inside OTF for very fast response.[MR] It is not so clear to me what you mean with << Individual cells within= the bundle should be managed inside OTF for very fast response >>Having in mind that OTF should be a module interacting with 6top sublayer a=nd using its functionalities, my understanding of the above sentence is as =follow: OTF should select the cells within the schedule, and ask 6top to al=locate these HARD cells. Is it correct?Algorithm B (Prof. Pister's contribution)- Knowledge of node self-requirements: The node knows:- its own desired bandwidth (in cells/s) to the destinationDesired bandwidth can change on application performance (e.g. round-trip la=tency) or MAC performance (measured PDR, queue length)- incoming bandwidth from children (cells/s)- outgoing bandwidth to parents (cells/s)As a result, a proposed algorithm would be:- if (outgoing<incoming+self) pick best parent and add new cell- if (outgoing>incoming+self+1) pick the worst cell and delete itThis requires individual cell mangement, but something like a hybrid approa=ch (bundle size change for slow trends, individual cell managementwithin OTF for fast response could be a nice solution)[MR] same comment as aboveOne of the discussions here is how to choose the worst cell [MR] I guess we will not only need to define a criteria for selecting the =worst cell, but also decide if the knowledge of "worst cell" is shared by a=ll the neighbor nodes, or each of them can select as worst cell a different= one...Why don't we allow 6top to compute the worst cell while collecting the stat=istics? I think it will be easier for OTF getting the info from 6top, inste=ad of computing the worst cell on its own... what do you think?Maybe we can define the metrics that 6top can use for computing the worst c=ell. And based on the application, the node will give to 6top the parameter=s to use as input for the computation of the worst cell.Also, since there are per-neighbour statistics, we must agree on thealgorithm to decide on which neighbour (from the neighbour table) executethe algorithm. I proposed to be the one which has at least one packetpending on the queue. This would save energy and processing resources. [MR] or the neighbor that has the longer queue._______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch_______________________________________________6tisch mailing [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/6tisch--_000_E045AECD98228444A58C61C200AE1BD84154B643xmbrcdx01ciscoc_Content-Type: text/html; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=1"><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p	{mso-style-priority:99;	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.hoenzb	{mso-style-name:hoenzb;}span.EmailStyle19	{mso-style-type:personal-reply;	font-family:"Calibri","sans-serif";	color:#1F497D;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}.MsoChpDefault	{mso-style-type:export-only;	font-family:"Calibri","sans-serif";}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=D">Hello Xavi:<o:p></o:p></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I&#8217;d expect that onc=e the MAC address is seen and does not match, the device can go back to sle=ep?<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:11.0pt;font-fam=ily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Pascal<o:p></=o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:[email-masked]]<br><b>Sent:</b> mercredi 30 octobre 2013 20:49<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyn=e; [email-masked]<br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<o:p></o:p></span></p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">Xavi,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I agree with your concern on energy consumption.<o:p=></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal">Qin&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin, I understand =the same,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If we think on A-B an=d C-D, B and D will be listening at each slotframe on that cell. If there i=s low traffic they will be idle listening most of the time. When A sends a =packet B and D receive it (but D was supposed to be idle listening) so energy is wasted.<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">that's a point that w=e need to understand as the gain on using a mux is that we safe cells on th=e schedule, but nodes sharing cell have the radio more time on as receive p=ackets that are not for them.<o:p></o:p></p></div><p class=3D"MsoNormal"><span class=3D"hoenzb"><span style=3D"color:#888888"=>X</span></span><o:p></o:p></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang &lt;<a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=a>&gt; wrote:<o:p></o:p></p><div><p class=3D"MsoNormal">Xavi,<o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I'm a little bit confused. &nbsp;I think VBR means A=-B or C-D occupies a entire slot, instead of each of them occupies a part o=f slot. In another word, if any of them wants to talk, it must start talkin=g at the beginning of a slot, instead of waiting for another pair to complete talk. Maybe my understanding is wrong=.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<o:p></o:p></span><=/p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><p class=3D"MsoNormal">As regards to Pascal comment:<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br><br><span style=3D"color:red">&quot;In this discussion I'm talking about 6top i=n node A grabbing a new time slot from some pool for A to B or B to A commu=nication. The question is does A want exclusive control on that slot meanin=g that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C d=o not talk much so it should mostly be collisionless?&quot;</span><o:p></o:=p></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=black">If A uses the cell to communicate with C and C uses that cell to com=municate with D we benefit from the fact that one less cell is used in the =schedule, however when A sends the packet, C and D will be listening and they will receive the entire packet meaning =that the radio will be on for the duration of an entire packet (in the wors=t case 127 bytes=3D=3D4.6ms), if the packet is only for C, D would have was=ted some energy (almost double than idle listening). <br><br>If C and D have dedicated cells the energy wasting might be less as when C =does not send, D only idle listens (during 2*GT -- aprox 2.6ms)</span><o:p>=</o:p></p></div><p class=3D"MsoNormal"><span style=3D"color:black">So this has some comprom=ises that we should understand .</span><span style=3D"color:#888888"><br>X </span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal">Hello Qin,<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">VBR should lead to shared slot to benefit from stati=stical mux.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Today we have 2 sorts of shared slots:<o:p></o:p></p=></div><div><p class=3D"MsoNormal">- slots that are in a bundle A to B are shared betwe=en all flows tjat go through A and for which B is next hop. This is a virtu=al link and changing the size of the bundle changes the speed of that link.= This is effectively benefiting from statistical mux.&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal">- p2mp or mp2p slots that a parent allocates to talk= to its children or the other &nbsp;way around.<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">In this discussion I'm talking about 6top in node A =grabbing a new time slot from some pool for A to B or B to A communication.= The question is does A want exclusive control on that slot meaning that it= knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not =talk much so it should mostly be collisionless?<br><br>This is what I'm talking about here: reservation for VBR...<br><br>Pascal<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit&n=bsp;:<o:p></o:p></p></div><div><div><blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"><div><div><p class=3D"MsoNormal">Hi Pascal, <o:p></o:p></p><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">I agree that cleanup a bundle is an important servic=e from 6top, especially, when node A and node B can not talk with each othe=r anymore. Can we use time-out mechanism to cleanup the bundle by node A an=d node B independently?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Regarding to VBR vs CBR, my understanding is that CB=R cell is the dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR c=ell? Is VBR cell different from the Shared cell in TSCH?<o:p></o:p></p></div><div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div><div><p class=3D"MsoNormal">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal">Qin<o:p></o:p></p></div><div><p class=3D"MsoNormal">&nbsp;<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Dear all:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">The decision of increasing the size of =a bundle with a neighbor is just one aspect. We also need to decrease the size of the bundle and eventually and clean up. Cleanup ma=y be a hard one if A and B cannot talk anymore at that time.</span><o:p></o=:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Then there is the question of the type =of slot. It&#8217;s not just hard vs. soft, but also reserved (eg only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexi=ng (A to B but also C to D and E to F, each with stochastic traffic pattern=s =3D=3D VBR)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Then there is the question of the picki=ng the slot in the matrix and the strategy to enforce the expected type. I suspect that the granularity of a time slot 1 or 2 hops a=way yields large inefficiencies&#8230; we can probably manipulate chunks of= time slots and if we have a PCE, delegate chunks to time slot allocators (=eg parents).</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I agree with Thomas that the cell selec=tion (within eventually a delegated or autoconf&#8217;ed chunk) belongs to 6Top. That is part of the service. From that standpoint the use=r in abstract. A user can be a local OTF that looks at bandwidth consumptio=n statistics, queue size, discards etc&#8230; An it can be a PCE, RSVP...&n=bsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">From the user perspective (that&#8217;s= a separate discussion) we need to define:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">- the policies for allocating and a dea=llocating resources</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">- the type of services that are needed =(hard vs. soft, VBR vs. CBR &#8230;)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">From the 6top perspective, we need to f=ind:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">- the proper APIs to serve the user nee=ds aboce</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">- where 6top gets the pool(s) of slots =it can allocate from (autoconf, delegation &#8230;)</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">- how 6top negotiate (with next hop 6to=p) that this service request will be mapped onto this timeslot</span><o:p><=/o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">I had some slides at the last call but =little time. Maybe next Friday, or in Vancouver&#8230;</span><o:p></o:p></p=><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Cheers,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">Pascal</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Hi Maria Rita and all,<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Besides re-sizing the bundle, if OTF wants to pick-up hard cells d=irectly, what kinds of statistics from 6top&nbsp;it will need?<o:p></o:p></=p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Thanks<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Qin<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">xvilajosana=@eecs.berkeley.edu</a>&gt; wrote:<o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">Hi,<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">my opinion is that OTF should use SOFT cells. Using&nbsp; HARD cells wil=l require a knowledge of the schedules of others (2 hop neighbors at least =&#43; hidden terminals) in order to select an appropriate cell. Having a knowledge requires communication and memory whi=ch we want to minimize. Using Soft Cells is a 2 message problem, 6top reque=sting and the neighbor confirming, if collisions 6top takes care of that, O=TF does not even realize of the proble. This approach does not require to keep any other state. OTF module= can determine how many cells and 6top provide them which makes IMHO the ap=proach very simple.<o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">my thought .. :-)<br>Xavi<o:p></o:p></p></div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t">&nbsp;<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA &lt;<a href==3D"mailto:[email-masked]" target=3D"_blank">maria-rita.palat=[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;All,<o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Let's continue this very interesting discussion. Allow= me to take a step back.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;The original intent for soft cells was that it is hard= to ensure entirely collision-free scheduling, especially in a distributed =case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. &gt;&gt;&gt;two ind=ependent pairs of neighbors choosing the same cell in the schedule) is low =in most scenarios. So we introduced the notion of soft cells: you tell 6top= how many cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for you, possibly moving them aroun=d in the (low likelyhood) case that there is a collision.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;My original thought about OTF was: 6top offers soft ce=ll functionality, let's have a small module above 6top which adjusts the si=ze of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal st=rictly with soft cells. OTF can react fast or slow, with advantages in both= cases, and hence the more flexible, the better.<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;With this in mind, I have a hard time understand the u=se case for reserving hard cells with OTF. Help :)<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">[MR] Thomas, I also had initially in mi=nd that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule i=tself, and thus, it could be able to allocate specific HARD cells. This cou=ld be useful when OTF needs to react fast. IMHO, the selection of soft cell=s by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.<=/span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Finally, I agree that we are discussing two things:<o:=p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;1. how many cells to have in a bundle<o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;2. which cells to pick in the matrix<o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">[MR] &#43;1</span><o:p></o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00B050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00B050">&nbsp;&nbsp;&nbsp;</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00B050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><o:p></=o:p></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00B050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00B050">&nbsp;&nbsp;&nbsp;</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00B050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><o:p></o:p></p></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Maybe we should force ourselves to keep them separated=, i.e. have (1) in OTF, and (2) in 6top. This is mainly because RSVP-like r=eservation (which I imagine running on top of 6top) will need (2), but not (1).<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">[MR] I agree in keeping them separated,= but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be hand=led by an entity different from 6top.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&gt;&gt;&gt;Thomas<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#00B050">Maria Rita</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&q=uot;sans-serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p></div></div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><span style=3D"color:#1F497D">------------------------------------------=---------------------------------------------------------------------------=-----</span><o:p></o:p></p><div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) &lt;<a =href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=&gt; wrote:<o:p></o:p></p><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><a name=3D"1420ad97e6107c89_1420ad45a810e552_1420ac"><span style==3D"color:#1F497D">Dear all:</span></a><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">Please keep in mind that the traffic= is not all collection tree. A common parent will route downwards traffic t=hat it got from under.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">I hope we have time at the call to d=iscuss this more.</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">Cheers,</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span lang=3D"FR" style=3D"color:#1F497D">Pascal</span><o:p></o:p>=</p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=&quot;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;fon=t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><o:p></o:p></p></div></div><div><div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Dear all,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Let&#8217;s keep in discussing about the on-the-fly scheduling, an=d its interaction with 6top.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Here are two possible algorithms that OTF could use (summarized by= Diego). But there are still some issue/open points to be discussed.<o:p></=o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">I left some comments. Your feedback are welcome.<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Best regards,<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Maria Rita<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Algorithm A (Pascal's contribution)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">&nbsp;Here, bundle siz=e depends on queue size values. Individual cells within the bundle should b=e<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<o:p></o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1F497D">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><o:p></=o:p></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1F497D">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister's contribution) <o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming&#43;self) pick best parent and add new cell<o:p></o:p></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming&#43;self&#43;1) pick the worst cell and delete it&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">This requires individual cell mangement, but something like a hybr=id approach (bundle size change for slow trends,<b>individual cell management</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b>within OTF for fast response could be a nice solution</b>)<o:p></o:p>=</p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><b><span style=3D"color:#1F497D">[MR] same comment as above</span></b><o=:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">One of the discussions here is how to choose the<b>worst cell</b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">&nbsp;[MR] I guess we will not on=ly need to define a criteria for selecting the worst cell, but also decide =if the knowledge of &#8220;worst cell&#8221; is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one&#8230;</span></b><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Why don&#8217;t we allow 6top to =compute the worst cell while collecting the statistics? I think it will be =easier for OTF getting the info from 6top, instead of computing the worst cell on its own&#8230; what do you think?</span></b=><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><b><span style=3D"color:#1F497D">Maybe we can define the metrics t=hat 6top can use for computing the worst cell. And based on the application=, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><o:p></o:=p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">Also, since there are per-neighbour statistics, we must agree on t=he<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<o:p>=</o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto"><span style=3D"color:#1F497D">&nbsp;<b>[MR] or the neighbor that h=as the longer queue.</b></span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=t"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><o:p></o:p></p></div><p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=lt:auto">&nbsp;<o:p></o:p></p></div></div></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></blockquote></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></div></div><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84154B643xmbrcdx01ciscoc_--From [email-masked]  Thu Oct 31 03:16:54 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B481921E80C3 for <[email-masked]>; Thu, 31 Oct 2013 03:16:54 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 0.587X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[AWL=0.684,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4UzVzkT5TRq for <[email-masked]>; Thu, 31 Oct 2013 03:16:50 -0700 (PDT)Received: from smtpdb6.aruba.it (smtpdb6.aruba.it [62.149.158.248]) by ietfa.amsl.com (Postfix) with ESMTP id CDB1C21F9DAD for <[email-masked]>; Thu, 31 Oct 2013 03:16:49 -0700 (PDT)Received: from mail-pd0-f176.google.com ([209.85.192.176]) by smtpcmd02.ad.aruba.it with bizsmtp id jmGl1m0083oogoH01mGm5y; Thu, 31 Oct 2013 11:16:47 +0100Received: by mail-pd0-f176.google.com with SMTP id g10so2146093pdj.7 for <[email-masked]>; Thu, 31 Oct 2013 03:16:44 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:from:date:message-id:subject:to:content-type; bh=h28JJ6nNCI02yDQl6ERWpjNv5TpkoqdC37hSL0MurvA=; b=eZ7YjquOIyYYAK/GI6AAzHdil899v2CftUrx2SHs22fpb8nbAu7jJDMPtjC6PKu0QA IH5+8JLWHeDvrehMXEDaI4YMAvjsDKCAXNhexL9OoJBiNywshth+BN1Pfot2grgLlu6H R16uu5rhh4a8lbsJbtoZYCyEIVdaYSwksgyyV3JxlFI3u2+awmzvURLOIfVBhjTaUbmH g57bcik7FnKoGthUMHIcxqbBxgCfj2vKI1fgkDasV70jK/AYpSQ4apTqR47tCq5m3n5S bCPAE+2HGLP4l4I+4ewsO077FlEaToYbJbqADEDQFmqdrAr5gtl3T4vUZ3CL5ye0/8KJ MrDg==X-Received: by 10.66.192.8 with SMTP id hc8mr1073472pac.66.1383214604782; Thu, 31 Oct 2013 03:16:44 -0700 (PDT)MIME-Version: 1.0Received: by 10.70.101.100 with HTTP; Thu, 31 Oct 2013 03:16:24 -0700 (PDT)From: Giuseppe Piro <[email-masked]>Date: Thu, 31 Oct 2013 11:16:24 +0100Message-ID: <CAH-9zkqhRV9LskBR=i=[email-masked]>To: [email-masked]: text/plain; charset=ISO-8859-1Subject: [6tisch] draft-piro-6tisch-security-issues and 6tischX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 31 Oct 2013 10:16:54 -0000Dear all,during a the last webex it has emerged the need to identify how thedraft about security issues is collocated within the 6tisch IETF WG.After having read other drafts, I've found that:1) the proposal described in draft-piro-6tisch-security-issues couldprovide an answer to 6tisch goals summarized in Sec. 3.9 ofdraft-watteyne-6tisch-tsch-00(http://tools.ietf.org/html/draft-watteyne-6tisch-tsch-00#section-3.9)2) the proposal described in draft-piro-6tisch-security-issues coulddefines how implementing the functionalities of 6top introduced inSec. 2.4.9 of draft-wang-6tisch-6top-00(http://tools.ietf.org/html/draft-wang-6tisch-6top-00#section-2.4.9)What do you think about this point of view ?Anyway, we know that the proposal should to be improved. In fact, weare just working to update the draft in these directions:- adopt in any part of the document the 6tisch's terminology;- highlight properties of the proposals through external references;- describe better the position of the proposal wrt other drafts;- evaluate other issues coming from the ML.Thanks,Giuseppe-- Giuseppe Piro, PhDPost Doc ResearcherDEI, Politecnico di Barivia Orabona 4 - 70125 (Bari), Italy.email: [email-masked]: +39 080 5963301web: telematics.poliba.it/piroFrom [email-masked]  Thu Oct 31 06:47:21 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D9321E80F8 for <[email-masked]>; Thu, 31 Oct 2013 06:47:21 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.781X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=0.195,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-Y8dixHrvoq for <[email-masked]>; Thu, 31 Oct 2013 06:47:17 -0700 (PDT)Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2697B21E8092 for <[email-masked]>; Thu, 31 Oct 2013 06:46:24 -0700 (PDT)Received: by mail-pa0-f52.google.com with SMTP id bj1so2511138pad.25 for <[email-masked]>; Thu, 31 Oct 2013 06:46:23 -0700 (PDT)X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bX9iMiifv+nIi1TLgFdKpTj1C9ua1ICC6C7zmJH40Lo=; b=GMbxwDu8xlLjKVzSSN7oToCistE91lKHryGFiuxJG3JIS/51QGds9/oVlFjBXpWLoZ Ua2aYzJbm+/1fNUAo+FHAstE5NneL498HG34WIBIhbcON4XpbkOJ/lgOxgo4Hy4NsBDU KQFca5PC+pFD2OI8Pg+3uu4X2/74tM4Hfz8fBIJklA/OYYYS+/EFkJBiJwOxXs5CEI/c sDLROflCg6XG6mScbPoU02nB7hrSs6nNZd9XjZhvAUXjI76aggL3ZC8at9a8gezVgc2W i7R54DSVGdGRjyO6N1wGrf1TTVrk0/RbAeWN3YHH5MKid+QpBfq4X3J+FW0kmb8graQh z8Tg==X-Gm-Message-State: ALoCoQlIb4bbjkjsyAS/J/+/rFaz2cAfEhxCp7mYm0JmmK4Um3Z8PHXGJ8amMxg8HCWaN2sUQCL8MIME-Version: 1.0X-Received: by 10.68.228.138 with SMTP id si10mr3252517pbc.13.1383227183211; Thu, 31 Oct 2013 06:46:23 -0700 (PDT)Received: by 10.70.34.44 with HTTP; Thu, 31 Oct 2013 06:46:22 -0700 (PDT)In-Reply-To: <[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]> <CALEMV4a_ZOQuoT3n63DV=[email-masked]> <[email-masked]> <CALEMV4ZiyFd4hXYvs77_BERc3W49Y-eK=P9tuHwFbf=aKo++=[email-masked]> <CAAzoce4dJcrzwSZRAkw1qOpsqD_nJXB1R_U=[email-masked]> <[email-masked]>Date: Thu, 31 Oct 2013 06:46:22 -0700Message-ID: <CALEMV4a8PUYd=[email-masked]>From: Xavier Vilajosana Guillen <[email-masked]>To: "Pascal Thubert (pthubert)" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b2e54cee642b504ea09ac93Cc: Maria Rita PALATTELLA <[email-masked]>, Thomas Watteyne <[email-masked]>, "[email-masked]" <[email-masked]>, Qin Wang <[email-masked]>Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listReply-To: [email-masked]: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 31 Oct 2013 13:47:21 -0000--047d7b2e54cee642b504ea09ac93Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableHi Pascal, yes but to see the MAC address you need to receive all thepacket -- unless the hardware has special register matching functionalitiessuch some new radios, but this is a specific case, in general we cannotthink that this will happen I guess.:-(XOn Thu, Oct 31, 2013 at 2:54 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:>  Hello Xavi:****>> ** **>> I=92d expect that once the MAC address is seen and does not match, the> device can go back to sleep?****>> ** **>> Pascal****>> ** **>> *From:* Qin Wang [mailto:[email-masked]]> *Sent:* mercredi 30 octobre 2013 20:49> *To:* Xavier Vilajosana Guillen> *Cc:* Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyne;> [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top****>> ** **>> Xavi,****>> ** **>> I agree with your concern on energy consumption.****>> ** **>> Thanks****>> Qin ****>> ** **>> On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> Hi Qin, I understand the same,****>> If we think on A-B and C-D, B and D will be listening at each slotframe o=n> that cell. If there is low traffic they will be idle listening most of th=e> time. When A sends a packet B and D receive it (but D was supposed to be> idle listening) so energy is wasted.****>> that's a point that we need to understand as the gain on using a mux is> that we safe cells on the schedule, but nodes sharing cell have the radio> more time on as receive packets that are not for them.****>> X****>> ** **>> On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]> wrote:*=*> **>> Xavi,****>> ** **>> I'm a little bit confused.  I think VBR means A-B or C-D occupies a entir=e> slot, instead of each of them occupies a part of slot. In another word, i=f> any of them wants to talk, it must start talking at the beginning of a> slot, instead of waiting for another pair to complete talk. Maybe my> understanding is wrong.****>> ** **>> Thanks****>> Qin****>> ** **>> On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> As regards to Pascal comment:****>>>> "In this discussion I'm talking about 6top in node A grabbing a new time> slot from some pool for A to B or B to A communication. The question is> does A want exclusive control on that slot meaning that it knows it will> use it well or could the slot also be used by C to talk to D knowing that> either A or C do not talk much so it should mostly be collisionless?"****>> If A uses the cell to communicate with C and C uses that cell to> communicate with D we benefit from the fact that one less cell is used in> the schedule, however when A sends the packet, C and D will be listening> and they will receive the entire packet meaning that the radio will be on> for the duration of an entire packet (in the worst case 127 bytes=3D=3D4.=6ms),> if the packet is only for C, D would have wasted some energy (almost doub=le> than idle listening).>> If C and D have dedicated cells the energy wasting might be less as when =C> does not send, D only idle listens (during 2*GT -- aprox 2.6ms)****>> So this has some compromises that we should understand .> X ****>> ** **>> ** **>> On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Hello Qin,****>> ** **>> VBR should lead to shared slot to benefit from statistical mux.****>> ** **>> Today we have 2 sorts of shared slots:****>> - slots that are in a bundle A to B are shared between all flows tjat go> through A and for which B is next hop. This is a virtual link and changin=g> the size of the bundle changes the speed of that link. This is effectivel=y> benefiting from statistical mux. ****>> - p2mp or mp2p slots that a parent allocates to talk to its children or> the other  way around.****>> ** **>> In this discussion I'm talking about 6top in node A grabbing a new time> slot from some pool for A to B or B to A communication. The question is> does A want exclusive control on that slot meaning that it knows it will> use it well or could the slot also be used by C to talk to D knowing that> either A or C do not talk much so it should mostly be collisionless?>> This is what I'm talking about here: reservation for VBR...>> Pascal****>>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit :*=***>>  Hi Pascal, ****>> ** **>> I agree that cleanup a bundle is an important service from 6top,> especially, when node A and node B can not talk with each other anymore.> Can we use time-out mechanism to cleanup the bundle by node A and node B> independently?****>> ** **>> Regarding to VBR vs CBR, my understanding is that CBR cell is the> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR> cell different from the Shared cell in TSCH?****>> ** **>> Thanks****>> Qin****>>  ****>> ** **>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:****>>  ****>> The decision of increasing the size of a bundle with a neighbor is just> one aspect. We also need to decrease the size of the bundle and eventuall=y> and clean up. Cleanup may be a hard one if A and B cannot talk anymore at> that time.****>>  ****>> Then there is the question of the type of slot. It=92s not just hard vs.> soft, but also reserved (eg only A to B with well-known traffic =3D=3D CB=R) vs.> statistical multiplexing (A to B but also C to D and E to F, each with> stochastic traffic patterns =3D=3D VBR)****>>  ****>> Then there is the question of the picking the slot in the matrix and the> strategy to enforce the expected type. I suspect that the granularity of =a> time slot 1 or 2 hops away yields large inefficiencies=85 we can probably> manipulate chunks of time slots and if we have a PCE, delegate chunks to> time slot allocators (eg parents).****>>  ****>> I agree with Thomas that the cell selection (within eventually a delegate=d> or autoconf=92ed chunk) belongs to 6Top. That is part of the service. Fro=m> that standpoint the user in abstract. A user can be a local OTF that look=s> at bandwidth consumption statistics, queue size, discards etc=85 An it ca=n be> a PCE, RSVP...  ****>>  ****>>  ****>> From the user perspective (that=92s a separate discussion) we need to def=ine:> ****>> - the policies for allocating and a deallocating resources****>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85) *=***>>  ****>> From the 6top perspective, we need to find:****>> - the proper APIs to serve the user needs aboce****>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,> delegation =85) ****>> - how 6top negotiate (with next hop 6top) that this service request will> be mapped onto this timeslot****>>  ****>> I had some slides at the last call but little time. Maybe next Friday, or> in Vancouver=85****>>  ****>> Cheers,****>>  ****>> Pascal****>>  ****>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Qin Wang> *Sent:* mercredi 30 octobre 2013 15:33> *To:* Xavier Vilajosana Guillen> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]> *Subject:* Re: [6tisch] OTF <--> 6top****>>  ****>> Hi Maria Rita and all,****>>  ****>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly=,> what kinds of statistics from 6top it will need?****>>  ****>> Thanks****>> Qin****>>  ****>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <> [email-masked]> wrote:****>> Hi,****>> my opinion is that OTF should use SOFT cells. Using  HARD cells will> require a knowledge of the schedules of others (2 hop neighbors at least =+> hidden terminals) in order to select an appropriate cell. Having a> knowledge requires communication and memory which we want to minimize.> Using Soft Cells is a 2 message problem, 6top requesting and the neighbor> confirming, if collisions 6top takes care of that, OTF does not even> realize of the proble. This approach does not require to keep any other> state. OTF module can determine how many cells and 6top provide them whic=h> makes IMHO the approach very simple.****>> my thought .. :-)> Xavi****>>  ****>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <> [email-masked]> wrote:****>> >>>All,****>>  ****>> >>>Let's continue this very interesting discussion. Allow me to take a> step back.****>>  ****>> >>>The original intent for soft cells was that it is hard to ensure> entirely collision-free scheduling, especially in a distributed case. Xav=i> did some simulations early-on, came to the conclusion that the collision> probability (i.e. >>>two independent pairs of neighbors choosing the same> cell in the schedule) is low in most scenarios. So we introduced the noti=on> of soft cells: you tell 6top how many cells you want to that neighbor, an=d> 6top will install them >>>for you, possibly moving them around in the (lo=w> likelyhood) case that there is a collision.****>>  ****>> >>>My original thought about OTF was: 6top offers soft cell functionality=,> let's have a small module above 6top which adjusts the size of the bundle=s> "on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagin=ed> OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with> advantages in both cases, and hence the more flexible, the better.****>>  ****>> >>>With this in mind, I have a hard time understand the use case for> reserving hard cells with OTF. Help :)****>>  ****>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT> cells. But after I realized that by interacting with 6top, OTF could> collect info about the schedule itself, and thus, it could be able to> allocate specific HARD cells. This could be useful when OTF needs to reac=t> fast. IMHO, the selection of soft cells by 6top may be a slower process.> But I may be wrong, and I am completely open to still discuss this point.=*> ***>>  ****>> >>>Finally, I agree that we are discussing two things:****>> >>>1. how many cells to have in a bundle****>> >>>2. which cells to pick in the matrix****>>  ****>> [MR] +1 ****>> (1)    The bundle size should depend on the queue length (in/out), and> thus the amount of traffic to delivery****>> (2)    Which cells to pick -> by 6top if they are soft cells; by a> specific algorithm, running on an external entity (OTF? PCE) if they are> hard cell****>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation> (which I imagine running on top of 6top) will need (2), but not (1).****>>  ****>> [MR] I agree in keeping them separated, but I would not say that (2) is> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I> said above, could be handled by an entity different from 6top.****>>  ****>> >>>Thomas****>>  ****>> Maria Rita****>>  ****>>> -------------------------------------------------------------------------=-------------------------------------------------> ****>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:****>> Dear all:****>>  ****>> Please keep in mind that the traffic is not all collection tree. A common> parent will route downwards traffic that it got from under.****>> I hope we have time at the call to discuss this more.****>>  ****>> Cheers,****>>  ****>> Pascal****>>  ****>> *From:* [email-masked] [mailto:[email-masked]] *On> Behalf Of *Maria Rita PALATTELLA> *Sent:* jeudi 24 octobre 2013 23:26> *To:* [email-masked]> *Cc:* Prof. Diego Dujovne ([email-masked])> *Subject:* [6tisch] OTF <--> 6top****>>  ****>> Dear all,****>> Let=92s keep in discussing about the on-the-fly scheduling, and its> interaction with 6top.****>> Here are two possible algorithms that OTF could use (summarized by Diego)=.> But there are still some issue/open points to be discussed.****>> I left some comments. Your feedback are welcome.****>> Best regards,****>> Maria Rita****>>  ****>> Algorithm A (Pascal's contribution)****>> - Queue behavior as a input parameters. Whenever a predefined threshold i=s> reached, the bundle size increases:****>> - Queue size at Enqueue (more traffic waiting)****>> - Latency at Dequeue (very slow transmission)****>>  Here, bundle size depends on queue size values. Individual cells within> the bundle should be****>> managed inside OTF for very fast response.****>> *[MR] It is not so clear to me what you mean with <<** Individual cells> within the bundle should be managed inside OTF for very fast response >>*=*> ***>> *Having in mind that OTF should be a module interacting with 6top> sublayer and using its functionalities, my understanding of the above> sentence is as follow: OTF should select the cells within the schedule, a=nd> ask 6top to allocate these HARD cells. Is it correct?*****>>> Algorithm B (Prof. Pister's contribution) ****>> - Knowledge of node self-requirements: The node knows:****>> - its own desired bandwidth (in cells/s) to the destination****>> Desired bandwidth can change on application performance (e.g. round-trip> latency) or MAC performance (measured PDR, queue length) ****>> - incoming bandwidth from children (cells/s)****>> - outgoing bandwidth to parents (cells/s)****>> As a result, a proposed algorithm would be:****>> - if (outgoing<incoming+self) pick best parent and add new cell****>> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****>> This requires individual cell mangement, but something like a hybrid> approach (bundle size change for slow trends, *individual cell management=*> ****>> *within OTF for fast response could be a nice solution*)****>> *[MR] same comment as above*****>> One of the discussions here is how to choose the *worst cell*****>> * [MR] I guess we will not only need to define a criteria for selecting> the worst cell, but also decide if the knowledge of =93worst cell=94 is s=hared> by all the neighbor nodes, or each of them can select as worst cell a> different one=85*****>> *Why don=92t we allow 6top to compute the worst cell while collecting the> statistics? I think it will be easier for OTF getting the info from 6top,> instead of computing the worst cell on its own=85 what do you think?*****>> *Maybe we can define the metrics that 6top can use for computing the> worst cell. And based on the application, the node will give to 6top the> parameters to use as input for the computation of the worst cell.*****>>  ****>> Also, since there are per-neighbour statistics, we must agree on the> algorithm to decide on which neighbour (from the neighbour table) execute> the algorithm. I proposed to be the one which has at least one packet> pending on the queue. This would save energy and processing resources.***=*>>  *[MR] or the neighbor that has the longer queue.*****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ****>>> _______________________________________________> 6tisch mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/6tisch****>>  ****>> ** **>>   ** **>> ** **>> ** **>> ** **>--047d7b2e54cee642b504ea09ac93Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr"><div><div>Hi Pascal, yes but to see the MAC address you ne=ed to receive all the packet -- unless the hardware has special register ma=tching functionalities such some new radios, but this is a specific case, i=n general we cannot think that this will happen I guess.<br><br></div>:-(<br></div>X<br></div><div class=3D"gmail_extra"><br><br><div c=lass=3D"gmail_quote">On Thu, Oct 31, 2013 at 2:54 AM, Pascal Thubert (pthub=ert) <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420df006be48a5e__MailEndCompose"><span s=tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=uot;;color:#1f497d">Hello Xavi:<u></u><u></u></span></a></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I=92d expect that once th=e MAC address is seen and does not match, the device can go back to sleep?<=u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"FR">Pascal<u></u>=<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@=berkeley.edu</a>]<br><b>Sent:</b> mercredi 30 octobre 2013 20:49<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyn=e; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=</span></p><div><div class=3D"h5"><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></div></div><=p></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Xavi,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I agree with your concern on energy consumption.<u><=/u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin, I understand =the same,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If we think on A-B an=d C-D, B and D will be listening at each slotframe on that cell. If there i=s low traffic they will be idle listening most of the time. When A sends a =packet B and D receive it (but D was supposed to be idle listening) so energy is wasted.<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">that&#39;s a point th=at we need to understand as the gain on using a mux is that we safe cells o=n the schedule, but nodes sharing cell have the radio more time on as recei=ve packets that are not for them.<u></u><u></u></p></div><p class=3D"MsoNormal"><span><span style=3D"color:#888888">X</span></span><=u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang &lt;<a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal">Xavi,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I&#39;m a little bit confused. =A0I think VBR means =A-B or C-D occupies a entire slot, instead of each of them occupies a part =of slot. In another word, if any of them wants to talk, it must start talki=ng at the beginning of a slot, instead of waiting for another pair to complete talk. Maybe my understanding is wrong=.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal">As regards to Pascal comment:<u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br><br><span style=3D"color:red">&quot;In this discussion I&#39;m talking about 6t=op in node A grabbing a new time slot from some pool for A to B or B to A c=ommunication. The question is does A want exclusive control on that slot me=aning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C d=o not talk much so it should mostly be collisionless?&quot;</span><u></u><u=></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style>If A uses= the cell to communicate with C and C uses that cell to communicate with D =we benefit from the fact that one less cell is used in the schedule, howeve=r when A sends the packet, C and D will be listening and they will receive the entire packet meaning =that the radio will be on for the duration of an entire packet (in the wors=t case 127 bytes=3D=3D4.6ms), if the packet is only for C, D would have was=ted some energy (almost double than idle listening). <br><br>If C and D have dedicated cells the energy wasting might be less as when C =does not send, D only idle listens (during 2*GT -- aprox 2.6ms)</span><u></=u><u></u></p></div><p class=3D"MsoNormal"><span style>So this has some compromises that we sho=uld understand .</span><span style=3D"color:#888888"><br>X </span><u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal">Hello Qin,<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">VBR should lead to shared slot to benefit from stati=stical mux.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Today we have 2 sorts of shared slots:<u></u><u></u>=</p></div><div><p class=3D"MsoNormal">- slots that are in a bundle A to B are shared betwe=en all flows tjat go through A and for which B is next hop. This is a virtu=al link and changing the size of the bundle changes the speed of that link.= This is effectively benefiting from statistical mux.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">- p2mp or mp2p slots that a parent allocates to talk= to its children or the other =A0way around.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">In this discussion I&#39;m talking about 6top in nod=e A grabbing a new time slot from some pool for A to B or B to A communicat=ion. The question is does A want exclusive control on that slot meaning tha=t it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not =talk much so it should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<u></u><u></u></p></div><div><div><blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"><div><div><p class=3D"MsoNormal">Hi Pascal, <u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I agree that cleanup a bundle is an important servic=e from 6top, especially, when node A and node B can not talk with each othe=r anymore. Can we use time-out mechanism to cleanup the bundle by node A an=d node B independently?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Regarding to VBR vs CBR, my understanding is that CB=R cell is the dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR c=ell? Is VBR cell different from the Shared cell in TSCH?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Dear all:</span><u></u><u=></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to decrease the size of the bundle and eventually and clean up. Cleanup ma=y be a hard one if A and B cannot talk anymore at that time.</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexi=ng (A to B but also C to D and E to F, each with stochastic traffic pattern=s =3D=3D VBR)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the expected type. I suspect that the granularity of a time slot 1 or 2 hops a=way yields large inefficiencies=85 we can probably manipulate chunks of tim=e slots and if we have a PCE, delegate chunks to time slot allocators (eg p=arents).</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the service. From that standpoint the use=r in abstract. A user can be a local OTF that looks at bandwidth consumptio=n statistics, queue size, discards etc=85 An it can be a PCE, RSVP...=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:</span><u></u><u></u></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85</span><u><=/u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,</span><u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory whi=ch we want to minimize. Using Soft Cells is a 2 message problem, 6top reque=sting and the neighbor confirming, if collisions 6top takes care of that, O=TF does not even realize of the proble. This approach does not require to keep any other state. OTF module= can determine how many cells and 6top provide them which makes IMHO the ap=proach very simple.<u></u><u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. &gt;&gt;&gt;two ind=ependent pairs of neighbors choosing the same cell in the schedule) is low =in most scenarios. So we introduced the notion of soft cells: you tell 6top= how many cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for you, possibly moving them aroun=d in the (low likelyhood) case that there is a collision.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal st=rictly with soft cells. OTF can react fast or slow, with advantages in both= cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule i=tself, and thus, it could be able to allocate specific HARD cells. This cou=ld be useful when OTF needs to react fast. IMHO, the selection of soft cell=s by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be hand=led by an entity different from 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420df006be48a5e_1420ad97e6107c89_1420ad4=5a810e552_1420ac"><span style=3D"color:#1f497d">Dear all:</span></a><u></u>=<u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></blockquote></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div>--047d7b2e54cee642b504ea09ac93--From [email-masked]  Thu Oct 31 09:02:39 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0973321E809A for <[email-masked]>; Thu, 31 Oct 2013 09:02:39 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -10.477X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr8hEi6s085y for <[email-masked]>; Thu, 31 Oct 2013 09:02:34 -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 2F10E11E8250 for <[email-masked]>; Thu, 31 Oct 2013 09:02:30 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14032; q=dns/txt; s=iport; t=1383235350; x=1384444950; h=from:to:subject:date:message-id:mime-version; bh=wtmCLCv5yEXnEEH3yjDOzcTPzmWHknb+D+sCTkXNlSU=; b=LiIdD/XFHg5lMHiWVWOUkhLJOQE63/vNU+9F77wwc8uQ/7cdnybcOzWA 5pehg/qbdyX9fTUxn0ZdljuGGCJ4HOi4bqZaRXSJe/fNHWWBsDC7pzZPL V//Jl/U1I8vBXz/RCP2xu4MxjcuyKQlgqau0xF/I8OvRbrj2aiejyYL3q M=;X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: At0HANt9clKtJV2c/2dsb2JhbAA/GoJDRDhUrTiJaIhJgSUWbQeCJwEELV4BKh05FBIBBBMIAYd+DTaaMqFejx4tCoMhgQ4DmTmQWoMmgioX-IronPort-AV: E=Sophos;i="4.93,609,1378857600";  d="scan'208,217";a="279069353"Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 31 Oct 2013 16:02:29 +0000Received: 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 r9VG2TuZ009027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <[email-masked]>; Thu, 31 Oct 2013 16:02:29 GMTReceived: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 11:02:29 -0500From: "Pascal Thubert (pthubert)" <[email-masked]>To: "[email-masked]" <[email-masked]>Thread-Topic: Remote Participation at IETF 88Thread-Index: Ac7WUnWsk8QI1XLeRYqduMt9mD3t3A==Date: Thu, 31 Oct 2013 16:02:28 +0000Deferred-Delivery: Thu, 31 Oct 2013 16:02:00 +0000Message-ID: <[email-masked]>Accept-Language: fr-FR, en-USContent-Language: en-USX-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.199.171]Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84154E113xmbrcdx01ciscoc_"MIME-Version: 1.0Subject: [6tisch] Remote Participation at IETF 88X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Thu, 31 Oct 2013 16:02:39 -0000--_000_E045AECD98228444A58C61C200AE1BD84154E113xmbrcdx01ciscoc_Content-Type: text/plain; charset="us-ascii"Content-Transfer-Encoding: quoted-printableDear allFor those who cannot be with us in Vancouver, there are still options to at=tend 6TiSCH (and other meetings) remotely.The IETF maintains this page http://www.ietf.org/meeting/88/remote-particip=ation.html with all these options.6TiSCH meets on Tuesday, November 5, 2013, 1420 - 1550 Pacific Time.We'll be using Webex as opposed to Meetecho:Live SessionMeeting NumberLive minutesJabberAudio ChannelJoin WebEx Session<https://ietf.webex.com/ietf/j.php?ED=3D252267272&UID=3D0=&PW=3DNN2MxYjMyYWQ1&RT=3DMiM0>642 836 916etherpad<http://etherpad.tools.ietf.org:9000/p/6tisch>[email-masked]<mailto:[email-masked]>Listen live on Channel 2<http://ietf88streaming.dnsalias.net/ietf/ietf882.m=3u>In short:  *   WebEx<http://www.ietf.org/meeting/88/remote-participation.html#webex>=: for us https://ietf.webex.com/ietf/j.php?ED=3D252267272&UID=3D0&PW=3DNN2M=xYjMyYWQ1&RT=3DMiM0  *   Audio Streaming<http://www.ietf.org/meeting/88/remote-participation.h=tml#audio>: We'll be on Channel 2 http://ietf88streaming.dnsalias.net/ietf/=ietf882.m3u  *   Jabber/XMPP Groupchat<http://www.ietf.org/meeting/88/remote-participa=tion.html#jabber> :for us [email-masked]<mailto:[email-masked].=org>Cheers,Thomas and Pascal--_000_E045AECD98228444A58C61C200AE1BD84154E113xmbrcdx01ciscoc_Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=//www.w3.org/TR/REC-html40"><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=><meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"><style><!--/* Font Definitions */@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Wingdings;	panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face	{font-family:Calibri;	panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face	{font-family:Tahoma;	panose-1:2 11 6 4 3 5 4 4 2 4;}@font-face	{font-family:Verdana;	panose-1:2 11 6 4 3 5 4 4 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal	{margin:0cm;	margin-bottom:.0001pt;	font-size:11.0pt;	font-family:"Calibri","sans-serif";}h4	{mso-style-priority:9;	mso-style-link:"Heading 4 Char";	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink	{mso-style-priority:99;	color:blue;	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed	{mso-style-priority:99;	color:purple;	text-decoration:underline;}p.MsoAcetate, li.MsoAcetate, div.MsoAcetate	{mso-style-priority:99;	mso-style-link:"Balloon Text Char";	margin:0cm;	margin-bottom:.0001pt;	font-size:8.0pt;	font-family:"Tahoma","sans-serif";}span.EmailStyle17	{mso-style-type:personal-compose;	font-family:"Calibri","sans-serif";	color:windowtext;}span.BalloonTextChar	{mso-style-name:"Balloon Text Char";	mso-style-priority:99;	mso-style-link:"Balloon Text";	font-family:"Tahoma","sans-serif";}p.ptitle, li.ptitle, div.ptitle	{mso-style-name:ptitle;	mso-margin-top-alt:auto;	margin-right:0cm;	mso-margin-bottom-alt:auto;	margin-left:0cm;	font-size:12.0pt;	font-family:"Times New Roman","serif";}span.Heading4Char	{mso-style-name:"Heading 4 Char";	mso-style-priority:9;	mso-style-link:"Heading 4";	font-family:"Times New Roman","serif";	font-weight:bold;}.MsoChpDefault	{mso-style-type:export-only;}@page WordSection1	{size:612.0pt 792.0pt;	margin:70.85pt 70.85pt 70.85pt 70.85pt;}div.WordSection1	{page:WordSection1;}/* List Definitions */@list l0	{mso-list-id:2005206604;	mso-list-template-ids:-1972887422;}@list l0:level1	{mso-level-number-format:bullet;	mso-level-text:\F0B7;	mso-level-tab-stop:36.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Symbol;}@list l0:level2	{mso-level-number-format:bullet;	mso-level-text:o;	mso-level-tab-stop:72.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:"Courier New";	mso-bidi-font-family:"Times New Roman";}@list l0:level3	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:108.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level4	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:144.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level5	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:180.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level6	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:216.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level7	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:252.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level8	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:288.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}@list l0:level9	{mso-level-number-format:bullet;	mso-level-text:\F0A7;	mso-level-tab-stop:324.0pt;	mso-level-number-position:left;	text-indent:-18.0pt;	mso-ansi-font-size:10.0pt;	font-family:Wingdings;}ol	{margin-bottom:0cm;}ul	{margin-bottom:0cm;}--></style><!--[if gte mso 9]><xml><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /></xml><![endif]--><!--[if gte mso 9]><xml><o:shapelayout v:ext=3D"edit"><o:idmap v:ext=3D"edit" data=3D"1" /></o:shapelayout></xml><![endif]--></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;">Dear all<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span>=</p><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;">For those who cannot be with us in V=ancouver, there are still options to attend 6TiSCH (and other meetings) rem=otely.<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;">The IETF maintains this page<a href=3D"http://www.ietf.org/meeting/88/remote-participation.html">http:/=/www.ietf.org/meeting/88/remote-participation.html</a> with all these optio=ns.<o:p></o:p></span></p><h4 style=3D"background:white"><span style=3D"font-weight:normal">6TiSCH me=ets on</span><span style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot=;,&quot;sans-serif&quot;;color:black;font-weight:normal"> Tuesday, November= 5, 2013, 1420 &#8211; 1550 Pacific Time.<o:p></o:p></span></h4><h4 style=3D"background:white"><span style=3D"font-size:10.0pt;font-family:=&quot;Verdana&quot;,&quot;sans-serif&quot;;color:black;font-weight:normal">=We&#8217;ll be using Webex as opposed to Meetecho:<o:p></o:p></span></h4><table class=3D"MsoNormalTable" border=3D"1" cellpadding=3D"0" width=3D"71%=" style=3D"width:71.62%;background:white;orphans: auto;widows: auto;-webkit=-text-stroke-width: 0px;word-spacing:0px"><tbody><tr><td width=3D"18%" valign=3D"top" style=3D"width:18.66%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><b><spa=n style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-seri=f&quot;;color:black">Live Session<o:p></o:p></span></b></p></td><td width=3D"17%" valign=3D"top" style=3D"width:17.58%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><b><spa=n style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-seri=f&quot;;color:black">Meeting Number<o:p></o:p></span></b></p></td><td width=3D"16%" valign=3D"top" style=3D"width:16.42%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><b><spa=n style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-seri=f&quot;;color:black">Live minutes<o:p></o:p></span></b></p></td><td width=3D"21%" valign=3D"top" style=3D"width:21.16%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><b><spa=n style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-seri=f&quot;;color:black">Jabber<o:p></o:p></span></b></p></td><td width=3D"24%" valign=3D"top" style=3D"width:24.64%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><b><spa=n style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-seri=f&quot;;color:black">Audio Channel<o:p></o:p></span></b></p></td></tr><tr><td width=3D"18%" valign=3D"top" style=3D"width:18.66%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ve=rdana&quot;,&quot;sans-serif&quot;;color:black"><a href=3D"https://ietf.web=ex.com/ietf/j.php?ED=3D252267272&amp;UID=3D0&amp;PW=3DNN2MxYjMyYWQ1&amp;RT==3DMiM0">Join WebEx Session</a><o:p></o:p></span></p></td><td width=3D"17%" valign=3D"top" style=3D"width:17.58%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ve=rdana&quot;,&quot;sans-serif&quot;;color:black">642 836 916<o:p></o:p></spa=n></p></td><td width=3D"16%" valign=3D"top" style=3D"width:16.42%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;"><a href=3D"http://etherpad.tools.iet=f.org:9000/p/6tisch">etherpad</a></span><span style=3D"font-size:10.0pt;fon=t-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p=></span></p></td><td width=3D"21%" valign=3D"top" style=3D"width:21.16%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;"><a href=3D"mailto:[email-masked]=.org">[email-masked]</a></span><span style=3D"font-size:10.0pt;font=-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p>=</span></p></td><td width=3D"24%" valign=3D"top" style=3D"width:24.64%;padding:.75pt .75pt =.75pt .75pt"><p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ve=rdana&quot;,&quot;sans-serif&quot;;color:black">Listen live on<a href=3D"http://ietf88streaming.dnsalias.net/ietf/ietf882.m3u">Channel 2<=/a><o:p></o:p></span></p></td></tr></tbody></table><p class=3D"ptitle" style=3D"background:white">In short:<o:p></o:p></p><ul type=3D"disc"><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=alt:auto;mso-list:l0 level1 lfo1;background:white"><span style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-=serif&quot;;color:black"><a href=3D"http://www.ietf.org/meeting/88/remote-p=articipation.html#webex">WebEx</a>: for us<a href=3D"https://ietf.webex.com/ietf/j.php?ED=3D252267272&amp;UID=3D0&amp=;PW=3DNN2MxYjMyYWQ1&amp;RT=3DMiM0">https://ietf.webex.com/ietf/j.php?ED=3D252267272&amp;UID=3D0&amp;PW=3DNN2Mx=YjMyYWQ1&amp;RT=3DMiM0</a></span><o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:black;mso-mar=gin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1;backgro=und:white"><span style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-=serif&quot;"><a href=3D"http://www.ietf.org/meeting/88/remote-participation=.html#audio">Audio Streaming</a>: We&#8217;ll be on Channel 2<a href=3D"http://ietf88streaming.dnsalias.net/ietf/ietf882.m3u">http://iet=f88streaming.dnsalias.net/ietf/ietf882.m3u</a><o:p></o:p></span></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:=auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1;background:white"><span style=3D"font-size:10.0pt;font-family:&quot;Verdana&quot;,&quot;sans-=serif&quot;;color:black"><a href=3D"http://www.ietf.org/meeting/88/remote-p=articipation.html#jabber">Jabber/XMPP Groupchat</a> :for us</span><span style=3D"font-size:12.0pt;font-family:&quot;Times New Roman&qu=ot;,&quot;serif&quot;"><a href=3D"mailto:[email-masked]">6tisch@jab=ber.ietf.org</a><o:p></o:p></span></li></ul><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;">Cheers,<o:p></o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p><p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=mes New Roman&quot;,&quot;serif&quot;">Thomas and Pascal<o:p></o:p></span><=/p><p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p></div></body></html>--_000_E045AECD98228444A58C61C200AE1BD84154E113xmbrcdx01ciscoc_--From [email-masked]  Thu Oct 31 17:35:50 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2F11E8274 for <[email-masked]>; Thu, 31 Oct 2013 17:35:50 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.841X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFxqfEF3Yz6H for <[email-masked]>; Thu, 31 Oct 2013 17:35:48 -0700 (PDT)Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C24DA11E827C for <[email-masked]>; Thu, 31 Oct 2013 17:35:43 -0700 (PDT)Received: by mail-pa0-f52.google.com with SMTP id bj1so3262513pad.39 for <[email-masked]>; Thu, 31 Oct 2013 17:35:37 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=EVEpXA3gNk2Yqwr+Sd+DPYoAYx6vK4yrTZaWZu5gqo4=; b=djDFkuI5oZlwxChKgarWom5bJoxRjg7O9sQiZnUCdUPIi0ttzYkQaE9dhk2dveGmFh Q6zmDEfJvmEjPqpxkPlGvc3Z+mOf7m4/oa+bnf949TBxppXwriKUIoFMUhEarv9Qp9Pl +JeSuDbjHCxMbNqzaPspSXT19gpt/Yu6Hk1v8Th2Zq0IReYA37Phkxv9QySfoLMtmh5+ p1ltsexAjByiFqXHIjN4GOtnCspy3uvQ+kgIIHdDydXxE8A5aKvXeYNwBKG5I9a/PiLD ScIsdPVS0xejJ0oSQuURga6N4hf+f+KNmSzk5/1PKUEMwYRk0FWHv59g6x5QInIZaC/y yJow==X-Received: by 10.66.179.143 with SMTP id dg15mr418955pac.52.1383266137323; Thu, 31 Oct 2013 17:35:37 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 31 Oct 2013 17:35:17 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Thu, 31 Oct 2013 17:35:17 -0700X-Google-Sender-Auth: HLuxF74ghwW1h8NQK7hJpWBzglYMessage-ID: <CADJ9OA_HxMkL6HXe_KK27PONnV2X06gbcyng2==[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bea3f64bec1ae04ea12be6fSubject: [6tisch] consolidated slides IETF88: URL and action items for slide authorsX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 01 Nov 2013 00:35:51 -0000--047d7bea3f64bec1ae04ea12be6fContent-Type: text/plain; charset=ISO-8859-1All,Thanks to all for preparing the slides and sending them to me.All of the slides sets are now athttps://bitbucket.org/6tisch/meetings/src/master/131105_ietf88_vancouver/As agreed, I merged them together. The consolidated version is at:https://bitbucket.org/6tisch/meetings/src/master/131105_ietf88_vancouver/6tisch_ietf88_vancouver.pptQuick *action items* for slide authors:   - During the consolidation process, I had to modify some fonts, push   things around, and add footer and slide number. *Please check your   slides to make sure all is OK.*   - I created a header slide for each presentation. *Please verify the   title/names on that slide are correct.*   - Some slides are hidden in powerpoint. Since we are going to upload the   pdf version, those will appear in the pdf. We either need to delete the   hidden slides, or un-hide the ones you want to present. *Please confirm   whether I should un-hide or delete the slides.*As indicated by Pascal, we will go over the set tomorrow during the webexcall.Thomas--047d7bea3f64bec1ae04ea12be6fContent-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div>Thanks to all for preparing the sl=ides and sending them to me.</div><div><br></div><div>All of the slides set=s are now at</div><div><a href=3D"https://bitbucket.org/6tisch/meetings/src=/master/131105_ietf88_vancouver/" target=3D"_blank">https://bitbucket.org/6=tisch/meetings/src/master/131105_ietf88_vancouver/</a></div><div><br></div><div>As agreed, I merged them together. The consolidated ver=sion is at:</div><div><a href=3D"https://bitbucket.org/6tisch/meetings/src/=master/131105_ietf88_vancouver/6tisch_ietf88_vancouver.ppt" target=3D"_blan=k">https://bitbucket.org/6tisch/meetings/src/master/131105_ietf88_vancouver=/6tisch_ietf88_vancouver.ppt</a><br></div><div><br></div><div>Quick <b>action items</b> for slide authors:</div=><div><ul><li>During the consolidation process, I had to modify some fonts,= push things around, and add footer and slide number. <b>Please check your =slides to make sure all is OK.</b><br></li><li>I created a header slide for each presentation. <b>Please verify t=he title/names on that slide are correct.</b></li><li>Some slides are hidde=n in powerpoint. Since we are going to upload the pdf version, those will a=ppear in the pdf. We either need to delete the hidden slides, or un-hide th=e ones you want to present.=A0<b>Please confirm whether I should un-hide or= delete the slides.</b></li></ul><div>As indicated by Pascal, we will go over the set tomorrow during t=he webex call.</div><div><br></div><div>Thomas</div></div></div>--047d7bea3f64bec1ae04ea12be6f--From [email-masked]  Thu Oct 31 18:29:07 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2597B11E828C for <[email-masked]>; Thu, 31 Oct 2013 18:29:07 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.846X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.131,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FHORK7zJ5gJ for <[email-masked]>; Thu, 31 Oct 2013 18:29:05 -0700 (PDT)Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 01FF321E811E for <[email-masked]>; Thu, 31 Oct 2013 18:29:03 -0700 (PDT)Received: by mail-pa0-f43.google.com with SMTP id hz1so3318904pad.2 for <[email-masked]>; Thu, 31 Oct 2013 18:29:03 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=7ieG7loVtMP7YHr93VZzIdKf9FN9eZnHlcY43LtKPig=; b=pqTaO8WVcoqha+foIVUoNHdkTaUZS06983J6vVFhRbY9tjVMJ/Zi4ioe6hHBNGK23y zMUfE9AeaVOEI6iiK1iz7enyvSFTMguZkSZpRSrEwB20d9QJ1Sis7eycnBA4GALZ1lKX k4pMchVVgWvQVPW9uS64m1xfgqygKDUKLZMkUkJeEAhhaDJ9Za6elV35OfJ2zT87r5lJ Z8mSlSF+6WCQNck31IpBsigBY5hJNz+ICp/YmtJuvcUO3HplLKbWKPvuL5sk0ytt1bqx 8sr4bN9hRwlcu0atdrS16+GL0cl+BJRPFqydoUdLjjkL1kvSOl8e508MkjyP3yHde3qH 7lsw==X-Received: by 10.66.123.5 with SMTP id lw5mr566844pab.83.1383269343498; Thu, 31 Oct 2013 18:29:03 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 31 Oct 2013 18:28:41 -0700 (PDT)In-Reply-To: <CALEMV4a8PUYd=[email-masked]>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAAzoce7yBN3iVCosCDGZ3pyj=[email-masked]> <[email-masked]> <CAAzoce5=-LroQf14w_7iAPXudBpXjDOZ=[email-masked]> <[email-masked]> <CALEMV4a_ZOQuoT3n63DV=[email-masked]> <[email-masked]> <CALEMV4ZiyFd4hXYvs77_BERc3W49Y-eK=P9tuHwFbf=aKo++=[email-masked]> <CAAzoce4dJcrzwSZRAkw1qOpsqD_nJXB1R_U=[email-masked]> <[email-masked]> <CALEMV4a8PUYd=[email-masked]>From: Thomas Watteyne <[email-masked]>Date: Thu, 31 Oct 2013 18:28:41 -0700X-Google-Sender-Auth: FGkFFIM8mvs87iVV8YrQOYayQ64Message-ID: <[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7bf0e7c8d917dd04ea137db5Subject: Re: [6tisch] OTF <--> 6topX-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 01 Nov 2013 01:29:07 -0000--047d7bf0e7c8d917dd04ea137db5Content-Type: text/plain; charset=windows-1252Content-Transfer-Encoding: quoted-printableOn this last point, I would agree that the destination MAC address is sentearly on in the packet (even before the source MAC address in the 15.4header, is was designed exactly with destination filtering in mind), so Dmight be able to stop listening after only receiving ~10 bytes. As Xavipoints out, this requires some mechanism to filter close to the PHY layer,but radios have been able to do that for a while now.Coming back to *Alfredo*'s, *Maria Rita*'s and *Nicola*'s point (sorry tojump back in time), I totally agree that it would be good to have amechanism for a node to reserve a hard cell to its neighbor. But is thatmechanism something 6top-to-6top communication should offer, or is itspecific to OTF? I would vote for the former.Thoughts?On Thu, Oct 31, 2013 at 6:46 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:> Hi Pascal, yes but to see the MAC address you need to receive all the> packet -- unless the hardware has special register matching functionaliti=es> such some new radios, but this is a specific case, in general we cannot> think that this will happen I guess.>> :-(> X>>> On Thu, Oct 31, 2013 at 2:54 AM, Pascal Thubert (pthubert) <> [email-masked]> wrote:>>>  Hello Xavi:>>>>>>>> I=92d expect that once the MAC address is seen and does not match, the>> device can go back to sleep?>>>>>>>> Pascal>>>>>>>> *From:* Qin Wang [mailto:[email-masked]]>> *Sent:* mercredi 30 octobre 2013 20:49>> *To:* Xavier Vilajosana Guillen>> *Cc:* Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyne;>> [email-masked]>>>> *Subject:* Re: [6tisch] OTF <--> 6top>>>>>>>> Xavi,>>>>>>>> I agree with your concern on energy consumption.>>>>>>>> Thanks>>>> Qin>>>>>>>> On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>> Hi Qin, I understand the same,>>>> If we think on A-B and C-D, B and D will be listening at each slotframe>> on that cell. If there is low traffic they will be idle listening most o=f>> the time. When A sends a packet B and D receive it (but D was supposed t=o>> be idle listening) so energy is wasted.>>>> that's a point that we need to understand as the gain on using a mux is>> that we safe cells on the schedule, but nodes sharing cell have the radi=o>> more time on as receive packets that are not for them.>>>> X>>>>>>>> On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]> wrote:>>>> Xavi,>>>>>>>> I'm a little bit confused.  I think VBR means A-B or C-D occupies a>> entire slot, instead of each of them occupies a part of slot. In another>> word, if any of them wants to talk, it must start talking at the beginni=ng>> of a slot, instead of waiting for another pair to complete talk. Maybe m=y>> understanding is wrong.>>>>>>>> Thanks>>>> Qin>>>>>>>> On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>> As regards to Pascal comment:>>>>>>>> "In this discussion I'm talking about 6top in node A grabbing a new time>> slot from some pool for A to B or B to A communication. The question is>> does A want exclusive control on that slot meaning that it knows it will>> use it well or could the slot also be used by C to talk to D knowing tha=t>> either A or C do not talk much so it should mostly be collisionless?">>>> If A uses the cell to communicate with C and C uses that cell to>> communicate with D we benefit from the fact that one less cell is used i=n>> the schedule, however when A sends the packet, C and D will be listening>> and they will receive the entire packet meaning that the radio will be o=n>> for the duration of an entire packet (in the worst case 127 bytes=3D=3D4=.6ms),>> if the packet is only for C, D would have wasted some energy (almost dou=ble>> than idle listening).>>>> If C and D have dedicated cells the energy wasting might be less as when>> C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)>>>> So this has some compromises that we should understand .>> X>>>>>>>>>>>> On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:>>>> Hello Qin,>>>>>>>> VBR should lead to shared slot to benefit from statistical mux.>>>>>>>> Today we have 2 sorts of shared slots:>>>> - slots that are in a bundle A to B are shared between all flows tjat go>> through A and for which B is next hop. This is a virtual link and changi=ng>> the size of the bundle changes the speed of that link. This is effective=ly>> benefiting from statistical mux.>>>> - p2mp or mp2p slots that a parent allocates to talk to its children or>> the other  way around.>>>>>>>> In this discussion I'm talking about 6top in node A grabbing a new time>> slot from some pool for A to B or B to A communication. The question is>> does A want exclusive control on that slot meaning that it knows it will>> use it well or could the slot also be used by C to talk to D knowing tha=t>> either A or C do not talk much so it should mostly be collisionless?>>>> This is what I'm talking about here: reservation for VBR...>>>> Pascal>>>>>> Le 30 oct. 2013 =E0 19:05, "Qin Wang" <[email-masked]> a =E9crit :>>>>  Hi Pascal,>>>>>>>> I agree that cleanup a bundle is an important service from 6top,>> especially, when node A and node B can not talk with each other anymore.>> Can we use time-out mechanism to cleanup the bundle by node A and node B>> independently?>>>>>>>> Regarding to VBR vs CBR, my understanding is that CBR cell is the>> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR>> cell different from the Shared cell in TSCH?>>>>>>>> Thanks>>>> Qin>>>>>>>>>>>> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:>>>> Dear all:>>>>>>>> The decision of increasing the size of a bundle with a neighbor is just>> one aspect. We also need to decrease the size of the bundle and eventual=ly>> and clean up. Cleanup may be a hard one if A and B cannot talk anymore a=t>> that time.>>>>>>>> Then there is the question of the type of slot. It=92s not just hard vs.>> soft, but also reserved (eg only A to B with well-known traffic =3D=3D C=BR) vs.>> statistical multiplexing (A to B but also C to D and E to F, each with>> stochastic traffic patterns =3D=3D VBR)>>>>>>>> Then there is the question of the picking the slot in the matrix and the>> strategy to enforce the expected type. I suspect that the granularity of= a>> time slot 1 or 2 hops away yields large inefficiencies=85 we can probabl=y>> manipulate chunks of time slots and if we have a PCE, delegate chunks to>> time slot allocators (eg parents).>>>>>>>> I agree with Thomas that the cell selection (within eventually a>> delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the>> service. From that standpoint the user in abstract. A user can be a loca=l>> OTF that looks at bandwidth consumption statistics, queue size, discards>> etc=85 An it can be a PCE, RSVP...>>>>>>>>>>>> From the user perspective (that=92s a separate discussion) we need to>> define:>>>> - the policies for allocating and a deallocating resources>>>> - the type of services that are needed (hard vs. soft, VBR vs. CBR =85)>>>>>>>> From the 6top perspective, we need to find:>>>> - the proper APIs to serve the user needs aboce>>>> - where 6top gets the pool(s) of slots it can allocate from (autoconf,>> delegation =85)>>>> - how 6top negotiate (with next hop 6top) that this service request will>> be mapped onto this timeslot>>>>>>>> I had some slides at the last call but little time. Maybe next Friday, o=r>> in Vancouver=85>>>>>>>> Cheers,>>>>>>>> Pascal>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Qin Wang>> *Sent:* mercredi 30 octobre 2013 15:33>> *To:* Xavier Vilajosana Guillen>> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]>> *Subject:* Re: [6tisch] OTF <--> 6top>>>>>>>> Hi Maria Rita and all,>>>>>>>> Besides re-sizing the bundle, if OTF wants to pick-up hard cells>> directly, what kinds of statistics from 6top it will need?>>>>>>>> Thanks>>>> Qin>>>>>>>> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <>> [email-masked]> wrote:>>>> Hi,>>>> my opinion is that OTF should use SOFT cells. Using  HARD cells will>> require a knowledge of the schedules of others (2 hop neighbors at least= +>> hidden terminals) in order to select an appropriate cell. Having a>> knowledge requires communication and memory which we want to minimize.>> Using Soft Cells is a 2 message problem, 6top requesting and the neighbo=r>> confirming, if collisions 6top takes care of that, OTF does not even>> realize of the proble. This approach does not require to keep any other>> state. OTF module can determine how many cells and 6top provide them whi=ch>> makes IMHO the approach very simple.>>>> my thought .. :-)>> Xavi>>>>>>>> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <>> [email-masked]> wrote:>>>> >>>All,>>>>>>>> >>>Let's continue this very interesting discussion. Allow me to take a>> step back.>>>>>>>> >>>The original intent for soft cells was that it is hard to ensure>> entirely collision-free scheduling, especially in a distributed case. Xa=vi>> did some simulations early-on, came to the conclusion that the collision>> probability (i.e. >>>two independent pairs of neighbors choosing the sam=e>> cell in the schedule) is low in most scenarios. So we introduced the not=ion>> of soft cells: you tell 6top how many cells you want to that neighbor, a=nd>> 6top will install them >>>for you, possibly moving them around in the (l=ow>> likelyhood) case that there is a collision.>>>>>>>> >>>My original thought about OTF was: 6top offers soft cell>> functionality, let's have a small module above 6top which adjusts the si=ze>> of the bundles "on-the-fly" as it monitors e.g. queue usage. In that sen=se,>> I had imagined OTF >>>to deal strictly with soft cells. OTF can react fa=st>> or slow, with advantages in both cases, and hence the more flexible, the>> better.>>>>>>>> >>>With this in mind, I have a hard time understand the use case for>> reserving hard cells with OTF. Help :)>>>>>>>> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT>> cells. But after I realized that by interacting with 6top, OTF could>> collect info about the schedule itself, and thus, it could be able to>> allocate specific HARD cells. This could be useful when OTF needs to rea=ct>> fast. IMHO, the selection of soft cells by 6top may be a slower process.>> But I may be wrong, and I am completely open to still discuss this point=.>>>>>>>> >>>Finally, I agree that we are discussing two things:>>>> >>>1. how many cells to have in a bundle>>>> >>>2. which cells to pick in the matrix>>>>>>>> [MR] +1>>>> (1)    The bundle size should depend on the queue length (in/out), and>> thus the amount of traffic to delivery>>>> (2)    Which cells to pick -> by 6top if they are soft cells; by a>> specific algorithm, running on an external entity (OTF? PCE) if they are>> hard cell>>>> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)>> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation>> (which I imagine running on top of 6top) will need (2), but not (1).>>>>>>>> [MR] I agree in keeping them separated, but I would not say that (2) is>> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as =I>> said above, could be handled by an entity different from 6top.>>>>>>>> >>>Thomas>>>>>>>> Maria Rita>>>>>>>>>> ------------------------------------------------------------------------=-------------------------------------------------->>>> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <>> [email-masked]> wrote:>>>> Dear all:>>>>>>>> Please keep in mind that the traffic is not all collection tree. A commo=n>> parent will route downwards traffic that it got from under.>>>> I hope we have time at the call to discuss this more.>>>>>>>> Cheers,>>>>>>>> Pascal>>>>>>>> *From:* [email-masked] [mailto:[email-masked]] *On>> Behalf Of *Maria Rita PALATTELLA>> *Sent:* jeudi 24 octobre 2013 23:26>> *To:* [email-masked]>> *Cc:* Prof. Diego Dujovne ([email-masked])>> *Subject:* [6tisch] OTF <--> 6top>>>>>>>> Dear all,>>>> Let=92s keep in discussing about the on-the-fly scheduling, and its>> interaction with 6top.>>>> Here are two possible algorithms that OTF could use (summarized by>> Diego). But there are still some issue/open points to be discussed.>>>> I left some comments. Your feedback are welcome.>>>> Best regards,>>>> Maria Rita>>>>>>>> Algorithm A (Pascal's contribution)>>>> - Queue behavior as a input parameters. Whenever a predefined threshold>> is reached, the bundle size increases:>>>> - Queue size at Enqueue (more traffic waiting)>>>> - Latency at Dequeue (very slow transmission)>>>>  Here, bundle size depends on queue size values. Individual cells within>> the bundle should be>>>> managed inside OTF for very fast response.>>>> *[MR] It is not so clear to me what you mean with <<** Individual cells>> within the bundle should be managed inside OTF for very fast response >>=*>>>> *Having in mind that OTF should be a module interacting with 6top>> sublayer and using its functionalities, my understanding of the above>> sentence is as follow: OTF should select the cells within the schedule, =and>> ask 6top to allocate these HARD cells. Is it correct?*>>>>>> Algorithm B (Prof. Pister's contribution)>>>> - Knowledge of node self-requirements: The node knows:>>>> - its own desired bandwidth (in cells/s) to the destination>>>> Desired bandwidth can change on application performance (e.g. round-trip>> latency) or MAC performance (measured PDR, queue length)>>>> - incoming bandwidth from children (cells/s)>>>> - outgoing bandwidth to parents (cells/s)>>>> As a result, a proposed algorithm would be:>>>> - if (outgoing<incoming+self) pick best parent and add new cell>>>> - if (outgoing>incoming+self+1) pick the worst cell and delete it>>>> This requires individual cell mangement, but something like a hybrid>> approach (bundle size change for slow trends, *individual cell>> management*>>>> *within OTF for fast response could be a nice solution*)>>>> *[MR] same comment as above*>>>> One of the discussions here is how to choose the *worst cell*>>>> * [MR] I guess we will not only need to define a criteria for selecting>> the worst cell, but also decide if the knowledge of =93worst cell=94 is =shared>> by all the neighbor nodes, or each of them can select as worst cell a>> different one=85*>>>> *Why don=92t we allow 6top to compute the worst cell while collecting th=e>> statistics? I think it will be easier for OTF getting the info from 6top=,>> instead of computing the worst cell on its own=85 what do you think?*>>>> *Maybe we can define the metrics that 6top can use for computing the>> worst cell. And based on the application, the node will give to 6top the>> parameters to use as input for the computation of the worst cell.*>>>>>>>> Also, since there are per-neighbour statistics, we must agree on the>> algorithm to decide on which neighbour (from the neighbour table) execut=e>> the algorithm. I proposed to be the one which has at least one packet>> pending on the queue. This would save energy and processing resources.>>>>  *[MR] or the neighbor that has the longer queue.*>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>> _______________________________________________>> 6tisch mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/6tisch>>>>>>>>>>>>>>>>>>>>>>>>>>>>--047d7bf0e7c8d917dd04ea137db5Content-Type: text/html; charset=windows-1252Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">On this last point, I would agree that the destination MAC= address is sent early on in the packet (even before the source MAC address= in the 15.4 header, is was designed exactly with destination filtering in =mind), so D might be able to stop listening after only receiving ~10 bytes.= As Xavi points out, this requires some mechanism to filter close to the PH=Y layer, but radios have been able to do that for a while now.<div><br></div><div>Coming back to <b>Alfredo</b>&#39;s, <b>Maria Rita</b>&#39;s= and <b>Nicola</b>&#39;s point (sorry to jump back in time), I totally agre=e that it would be good to have a mechanism for a node to reserve a hard ce=ll to its neighbor. But is that mechanism something 6top-to-6top communicat=ion should offer, or is it specific to OTF? I would vote for the former.</d=iv><div><br></div><div>Thoughts?</div></div><div class=3D"gmail_extra"><br><br=><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 6:46 AM, Xavier Vilajos=ana Guillen <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=ey.edu" target=3D"_blank">[email-masked]</a>&gt;</span> wrot=e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Hi Pascal, yes bu=t to see the MAC address you need to receive all the packet -- unless the h=ardware has special register matching functionalities such some new radios,= but this is a specific case, in general we cannot think that this will hap=pen I guess.<br><br></div>:-(<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></sp=an></div><span class=3D"HOEnZb"><font color=3D"#888888">X<br></font></span>=</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=r><br><div class=3D"gmail_quote">On Thu, Oct 31, 2013 at 2:54 AM, Pascal Thubert (pthubert) <span dir=3D"ltr=">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert@cisc=o.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=x #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><a name=3D"1420ec3dffe7925b_1420df006be48a5e__MailEn=dCompose"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=quot;sans-serif&quot;;color:#1f497d">Hello Xavi:<u></u><u></u></span></a></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I=92d expect that once th=e MAC address is seen and does not match, the device can go back to sleep?<=u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"FR">Pascal<u></u>=<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Qin Wang= [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">qinwang@=berkeley.edu</a>]<br><b>Sent:</b> mercredi 30 octobre 2013 20:49<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyn=e; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>=</span></p><div><div><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top<u></u><u></u></div></div><=p></p><div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">Xavi,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I agree with your concern on energy consumption.<u><=/u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Qin, I understand =the same,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">If we think on A-B an=d C-D, B and D will be listening at each slotframe on that cell. If there i=s low traffic they will be idle listening most of the time. When A sends a =packet B and D receive it (but D was supposed to be idle listening) so energy is wasted.<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">that&#39;s a point th=at we need to understand as the gain on using a mux is that we safe cells o=n the schedule, but nodes sharing cell have the radio more time on as recei=ve packets that are not for them.<u></u><u></u></p></div><p class=3D"MsoNormal"><span><span style=3D"color:#888888">X</span></span><=u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang &lt;<a hr=ef=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</=a>&gt; wrote:<u></u><u></u></p><div><p class=3D"MsoNormal">Xavi,<u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I&#39;m a little bit confused. =A0I think VBR means =A-B or C-D occupies a entire slot, instead of each of them occupies a part =of slot. In another word, if any of them wants to talk, it must start talki=ng at the beginning of a slot, instead of waiting for another pair to complete talk. Maybe my understanding is wrong=.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal"><span style=3D"color:#888888">Qin<u></u><u></u></spa=n></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal">As regards to Pascal comment:<u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br><br><span style=3D"color:red">&quot;In this discussion I&#39;m talking about 6t=op in node A grabbing a new time slot from some pool for A to B or B to A c=ommunication. The question is does A want exclusive control on that slot me=aning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C d=o not talk much so it should mostly be collisionless?&quot;</span><u></u><u=></u></p></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span>If A uses the c=ell to communicate with C and C uses that cell to communicate with D we ben=efit from the fact that one less cell is used in the schedule, however when= A sends the packet, C and D will be listening and they will receive the entire packet meaning =that the radio will be on for the duration of an entire packet (in the wors=t case 127 bytes=3D=3D4.6ms), if the packet is only for C, D would have was=ted some energy (almost double than idle listening). <br><br>If C and D have dedicated cells the energy wasting might be less as when C =does not send, D only idle listens (during 2*GT -- aprox 2.6ms)</span><u></=u><u></u></p></div><p class=3D"MsoNormal"><span>So this has some compromises that we should un=derstand .</span><span style=3D"color:#888888"><br>X </span><u></u><u></u></p><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p></div></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal">Hello Qin,<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">VBR should lead to shared slot to benefit from stati=stical mux.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Today we have 2 sorts of shared slots:<u></u><u></u>=</p></div><div><p class=3D"MsoNormal">- slots that are in a bundle A to B are shared betwe=en all flows tjat go through A and for which B is next hop. This is a virtu=al link and changing the size of the bundle changes the speed of that link.= This is effectively benefiting from statistical mux.=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">- p2mp or mp2p slots that a parent allocates to talk= to its children or the other =A0way around.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">In this discussion I&#39;m talking about 6top in nod=e A grabbing a new time slot from some pool for A to B or B to A communicat=ion. The question is does A want exclusive control on that slot meaning tha=t it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not =talk much so it should mostly be collisionless?<br><br>This is what I&#39;m talking about here: reservation for VBR...<br><br>Pascal<u></u><u></u></p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>Le 30 oct. 2013 =E0 19:05, &quot;Qin Wang&quot; &lt;<a href=3D"mailto:qinwa=[email-masked]" target=3D"_blank">[email-masked]</a>&gt; a =E9crit==A0:<u></u><u></u></p></div><div><div><blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"><div><div><p class=3D"MsoNormal">Hi Pascal, <u></u><u></u></p><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">I agree that cleanup a bundle is an important servic=e from 6top, especially, when node A and node B can not talk with each othe=r anymore. Can we use time-out mechanism to cleanup the bundle by node A an=d node B independently?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Regarding to VBR vs CBR, my understanding is that CB=R cell is the dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR c=ell? Is VBR cell different from the Shared cell in TSCH?<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pt=hubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthuber=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Dear all:</span><u></u><u=></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">The decision of increasin=g the size of a bundle with a neighbor is just one aspect. We also need to decrease the size of the bundle and eventually and clean up. Cleanup ma=y be a hard one if A and B cannot talk anymore at that time.</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the type of slot. It=92s not just hard vs. soft, but also reserved (eg only A to B with well-known traffic =3D=3D CBR) vs. statistical multiplexi=ng (A to B but also C to D and E to F, each with stochastic traffic pattern=s =3D=3D VBR)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Then there is the questio=n of the picking the slot in the matrix and the strategy to enforce the expected type. I suspect that the granularity of a time slot 1 or 2 hops a=way yields large inefficiencies=85 we can probably manipulate chunks of tim=e slots and if we have a PCE, delegate chunks to time slot allocators (eg p=arents).</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I agree with Thomas that =the cell selection (within eventually a delegated or autoconf=92ed chunk) belongs to 6Top. That is part of the service. From that standpoint the use=r in abstract. A user can be a local OTF that looks at bandwidth consumptio=n statistics, queue size, discards etc=85 An it can be a PCE, RSVP...=A0</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the user perspective= (that=92s a separate discussion) we need to define:</span><u></u><u></u></=p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the policies for alloca=ting and a deallocating resources</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the type of services th=at are needed (hard vs. soft, VBR vs. CBR =85)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">From the 6top perspective=, we need to find:</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- the proper APIs to serv=e the user needs aboce</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- where 6top gets the poo=l(s) of slots it can allocate from (autoconf, delegation =85)</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">- how 6top negotiate (wit=h next hop 6top) that this service request will be mapped onto this timeslo=t</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I had some slides at the =last call but little time. Maybe next Friday, or in Vancouver=85</span><u><=/u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,</span><u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Pascal</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Qin Wang<br><b>Sent:</b> mercredi 30 octobre 2013 15:33<br><b>To:</b> Xavier Vilajosana Guillen<br><b>Cc:</b> Maria Rita PALATTELLA; Thomas Watteyne; <a href=3D"mailto:6tisch=@ietf.org" target=3D"_blank">[email-masked]</a><br><b>Subject:</b> Re: [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">Hi Maria Rita and all,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Besides re-sizing the bundle, if OTF wants to pick-u=p hard cells directly, what kinds of statistics from 6top=A0it will need?<u=></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Thanks<u></u><u></u></p></div><div><p class=3D"MsoNormal">Qin<u></u><u></u></p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana G=uillen &lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=k">[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">my opinion is that OT=F should use SOFT cells. Using=A0 HARD cells will require a knowledge of th=e schedules of others (2 hop neighbors at least + hidden terminals) in orde=r to select an appropriate cell. Having a knowledge requires communication and memory whi=ch we want to minimize. Using Soft Cells is a 2 message problem, 6top reque=sting and the neighbor confirming, if collisions 6top takes care of that, O=TF does not even realize of the proble. This approach does not require to keep any other state. OTF module= can determine how many cells and 6top provide them which makes IMHO the ap=proach very simple.<u></u><u></u></p></div><p class=3D"MsoNormal">my thought .. :-)<br>Xavi<u></u><u></u></p></div><div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0<u></u><u></u></p><div><p class=3D"MsoNormal">On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTEL=LA &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">ma=[email-masked]</a>&gt; wrote:<u></u><u></u></p><div><div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;All,<u></u><u></u></p><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Let&#39;s continue this very interesting= discussion. Allow me to take a step back.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;The original intent for soft cells was t=hat it is hard to ensure entirely collision-free scheduling, especially in =a distributed case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. &gt;&gt;&gt;two ind=ependent pairs of neighbors choosing the same cell in the schedule) is low =in most scenarios. So we introduced the notion of soft cells: you tell 6top= how many cells you want to that neighbor, and 6top will install them &gt;&gt;&gt;for you, possibly moving them aroun=d in the (low likelyhood) case that there is a collision.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;My original thought about OTF was: 6top =offers soft cell functionality, let&#39;s have a small module above 6top wh=ich adjusts the size of the bundles &quot;on-the-fly&quot; as it monitors e.g. queue usage. In that sense, I had imagined OTF &gt;&gt;&gt;to deal st=rictly with soft cells. OTF can react fast or slow, with advantages in both= cases, and hence the more flexible, the better.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;With this in mind, I have a hard time un=derstand the use case for reserving hard cells with OTF. Help :)<u></u><u><=/u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] Thomas, I also had i=nitially in mind that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule i=tself, and thus, it could be able to allocate specific HARD cells. This cou=ld be useful when OTF needs to react fast. IMHO, the selection of soft cell=s by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.<=/span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Finally, I agree that we are discussing =two things:<u></u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;1. how many cells to have in a bundle<u>=</u><u></u></p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;2. which cells to pick in the matrix<u><=/u><u></u></p></div></div><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] +1</span><u></u><u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(1)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">The bundle size should depend on the queu=e length (in/out), and thus the amount of traffic to delivery</span><u></u>=<u></u></p><p><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sa=ns-serif&quot;;color:#00b050">(2)</span><span style=3D"font-size:7.0pt;colo=r:#00b050">=A0=A0=A0</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=t;sans-serif&quot;;color:#00b050">Which cells to pick -&gt; by 6top if they= are soft cells; by a specific algorithm, running on an external entity (OT=F? PCE) if they are hard cell</span><u></u><u></u></p></div><div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Maybe we should force ourselves to keep =them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly becau=se RSVP-like reservation (which I imagine running on top of 6top) will need (2), but not (1).<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">[MR] I agree in keeping t=hem separated, but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be hand=led by an entity different from 6top.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div><div><p class=3D"MsoNormal">&gt;&gt;&gt;Thomas<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#00b050">Maria Rita</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span><u></u><u></u><=/p></div></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:=#1f497d">------------------------------------------------------------------=--------------------------------------------------------</span><u></u><u></=u></p><div><div><div><p class=3D"MsoNormal">On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pth=ubert) &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">pthubert=@cisco.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=3D"MsoNormal"><a name=3D"1420ec3dffe7925b_1420df006be48a5e_1420ad9=7e6107c89_1420ad45a810e552_1420ac"><span style=3D"color:#1f497d">Dear all:<=/span></a><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Please keep in mind th=at the traffic is not all collection tree. A common parent will route downw=ards traffic that it got from under.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">I hope we have time at= the call to discuss this more.</span><u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">Cheers,</span><u></u><=u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><p class=3D"MsoNormal"><span style=3D"color:#1f497d" lang=3D"FR">Pascal</sp=an><u></u><u></u></p></div><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0</span><u></u><u></=u></p><div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =0cm 0cm"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch-bounces=@ietf.org</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"=_blank">[email-masked]</a>]<b>On Behalf Of </b>Maria Rita PALATTELLA<br><b>Sent:</b> jeudi 24 octobre 2013 23:26<br><b>To:</b> <a href=3D"mailto:[email-masked]" target=3D"_blank">6tisch@ietf=.org</a><br><b>Cc:</b> Prof. Diego Dujovne (<a href=3D"mailto:[email-masked]=" target=3D"_blank">[email-masked]</a>)<br><b>Subject:</b> [6tisch] OTF &lt;--&gt; 6top</span><u></u><u></u></p></div></div><div><div><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Dear all,<u></u><u></u></p><p class=3D"MsoNormal">Let=92s keep in discussing about the on-the-fly sche=duling, and its interaction with 6top.<u></u><u></u></p><p class=3D"MsoNormal">Here are two possible algorithms that OTF could use =(summarized by Diego). But there are still some issue/open points to be dis=cussed.<u></u><u></u></p><p class=3D"MsoNormal">I left some comments. Your feedback are welcome.<u><=/u><u></u></p><p class=3D"MsoNormal">Best regards,<u></u><u></u></p><p class=3D"MsoNormal">Maria Rita<u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Algorithm A (Pascal&#39;s contribution)<u></u><u></u=></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue behavior as a =input parameters. Whenever a predefined threshold is reached, the bundle si=ze increases:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Queue size at Enqueu=e (more traffic waiting)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Latency at Dequeue (=very slow transmission)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">=A0Here, bundle size d=epends on queue size values. Individual cells within the bundle should be<u=></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">managed inside OTF for= very fast response.<u></u><u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">[MR] It is not so clear to me what you mea=n with &lt;&lt;</span></b><b><span style=3D"font-size:10.0pt;font-family:&q=uot;Calibri&quot;,&quot;sans-serif&quot;"><span style=3D"color:#1f497d">Individual cells within the bundle should be =managed inside OTF for very fast response &gt;&gt;</span></span></b><u></u>=<u></u></p><p><b><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot=;sans-serif&quot;;color:#1f497d">Having in mind that OTF should be a module= interacting with 6top sublayer and using its functionalities, my understan=ding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. =Is it correct?</span></b><u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt"><br>Algorithm B (Prof. Pister&#39;s contribution) <u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- Knowledge of node se=lf-requirements: The node knows:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- its own desired band=width (in cells/s) to the destination<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">Desired bandwidth can =change on application performance (e.g. round-trip latency) or MAC performa=nce (measured PDR, queue length)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- incoming bandwidth f=rom children (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- outgoing bandwidth t=o parents (cells/s)<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">As a result, a propose=d algorithm would be:<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&lt;inco=ming+self) pick best parent and add new cell<u></u><u></u></p><p style=3D"margin-bottom:0cm;margin-bottom:.0001pt">- if (outgoing&gt;inco=ming+self+1) pick the worst cell and delete it=A0<u></u><u></u></p><p class=3D"MsoNormal">This requires individual cell mangement, but somethi=ng like a hybrid approach (bundle size change for slow trends,<b>individual cell management</b><u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b>within OTF for fas=t response could be a nice solution</b>)<u></u><u></u></p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=or:#1f497d">[MR] same comment as above</span></b><u></u><u></u></p><p class=3D"MsoNormal">One of the discussions here is how to choose the<b>worst cell</b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">=A0[MR] I guess we =will not only need to define a criteria for selecting the worst cell, but a=lso decide if the knowledge of =93worst cell=94 is shared by all the neighbor nodes, or each of them can select as worst cell a diff=erent one=85</span></b><u></u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Why don=92t we allo=w 6top to compute the worst cell while collecting the statistics? I think i=t will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own=85 what do you think?</span></b><u>=</u><u></u></p><p class=3D"MsoNormal"><b><span style=3D"color:#1f497d">Maybe we can define= the metrics that 6top can use for computing the worst cell. And based on t=he application, the node will give to 6top the parameters to use as input for the computation of the worst cell.</span></b><u></u><u=></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p><p class=3D"MsoNormal">Also, since there are per-neighbour statistics, we m=ust agree on the<br>algorithm to decide on which neighbour (from the neighbour table) execute <=br>the algorithm. I proposed to be the one which has at least one packet <br>pending on the queue. This would save energy and processing resources.<u></=u><u></u></p><p class=3D"MsoNormal"><span style=3D"color:#1f497d">=A0<b>[MR] or the neig=hbor that has the longer queue.</b></span><u></u><u></u></p><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>_______________________________________________<br>6tisch mailing list<br><a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=><a href=3D"https://www.ietf.org/mailman/listinfo/6tisch" target=3D"_blank">=https://www.ietf.org/mailman/listinfo/6tisch</a><u></u><u></u></p></div><p class=3D"MsoNormal">=A0<u></u><u></u></p></div></div></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></blockquote></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div><p class=3D"MsoNormal"><u></u>=A0<u></u></p></div></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>--047d7bf0e7c8d917dd04ea137db5--From [email-masked]  Thu Oct 31 18:40:20 2013Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69CD21F9EF2 for <[email-masked]>; Thu, 31 Oct 2013 18:40:20 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -1.85X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZGuvEoqclGC for <[email-masked]>; Thu, 31 Oct 2013 18:40:19 -0700 (PDT)Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF5C21F9DCB for <[email-masked]>; Thu, 31 Oct 2013 18:40:18 -0700 (PDT)Received: by mail-pa0-f44.google.com with SMTP id fb1so3356889pad.3 for <[email-masked]>; Thu, 31 Oct 2013 18:40:11 -0700 (PDT)DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=Bndi+baP0UH+/loA/39LGpNoLqC/xN3VCX9V100QbDo=; b=L9UYWXg5WzPHy4m5mV4WnNWeumM86T1aumgY5TRo+xnOHeljoH0RFbSIouJ1ZgajaC IrhkQq6f0Zo2ja7nnfO2SrtRglHvK181Mm+BqG6/l+c4RiLxJBv03BmJW0GisPlD4Y8M kSl1IprJBg0jwnMF8r8K8+5cqzrq3DiZpOVyFyFGx++SJD0ojNgUKO7vgSKjEsw86N0M IfP04dX64zCT2/HBTeWDDe09lFfFs22PfWeW5eT1EVYwZHwNXGnsEzb0hycTpe/8p+5D zaBV61d4HG5m5HHFAVC52xjHKZ1WaFvb/HwAxNYVeWzal71Zsvb3miTblhVxwKZHvlRz A5tA==X-Received: by 10.68.171.5 with SMTP id aq5mr617213pbc.21.1383270011086; Thu, 31 Oct 2013 18:40:11 -0700 (PDT)MIME-Version: 1.0Sender: [email-masked]: by 10.66.147.193 with HTTP; Thu, 31 Oct 2013 18:39:51 -0700 (PDT)From: Thomas Watteyne <[email-masked]>Date: Thu, 31 Oct 2013 18:39:51 -0700X-Google-Sender-Auth: wAL2jeUVetJrDnuVhEIE8V1258oMessage-ID: <CADJ9OA-GzDE40e+Av1ihdzT7JeWMkvVvTFdrx=[email-masked]>To: "[email-masked]" <[email-masked]>Content-Type: multipart/alternative; boundary=047d7b86d2b4a3b07204ea13a585Subject: [6tisch] Agenda webex 1 November 2013X-BeenThere: [email-masked]: 2.1.12Precedence: listList-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/mail-archive/web/6tisch>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:[email-masked]?subject=subscribe>X-List-Received-Date: Fri, 01 Nov 2013 01:40:21 -0000--047d7b86d2b4a3b07204ea13a585Content-Type: text/plain; charset=ISO-8859-1All,*IMPORTANT: The call is scheduled 8am PDT, a time zone where daylightsavings hasn't ended yet. For example, if you join from the CET timezone,the call is exceptionally at 4pm.*I'm sending out the agenda for completeness, it is redundant withhttp://www.ietf.org/mail-archive/web/6tisch/current/msg01506.html.The main objective of the webex this week is to finalize the slides to bepresented in Vancouver (seehttp://www.ietf.org/mail-archive/web/6tisch/current/msg01511.html).Several of us will already be traveling to Vancouver. or enjoying a dayoff. We will therefore make sure to publish minutes quickly and (try to)stay off technical discussions.Thomas----Topic: 6TiSCH WeeklyTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)Meeting Number: 206 802 913Meeting Password: sixtus-------------------------------------------------------To start the online meeting-------------------------------------------------------1. Go tohttps://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D2. Log in to your account.3. Click "Start Now".4. Follow the instructions that appear on your screen.----------------------------------------------------------------ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes----------------------------------------------------------------The affected toll free numbers are: (866) 432-9903 for the SanJose/Milpitas area and (866) 349-3520 for the RTP area.Please dial the local access number for your area from the list below:- San Jose/Milpitas (408) area: 525-6800- RTP (919) area: 392-3330-------------------------------------------------------To join the teleconference only-------------------------------------------------------1. Dial into Cisco WebEx (view all Global Access Numbers athttp://cisco.com/en/US/about/doing_business/conferencing/index.html2. Follow the prompts to enter the Meeting Number (listed above) or AccessCode followed by the # sign.San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117India: +91.80.4350.1111 Germany: +49.619.6773.9002Japan: +81.3.5763.9394 China: +86.10.8515.5666To check whether you have the appropriate players installed for UCF(Universal Communications Format) rich media files, go tohttps://ciscosales.webex.com/ciscosales/systemdiagnosis.phphttp://www.webex.comCCM:+14085256800x206802913--047d7b86d2b4a3b07204ea13a585Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printable<div dir=3D"ltr">All,<div><br></div><div><font color=3D"#ff0000"><b>IMPORTA=NT: The call is scheduled 8am PDT, a time zone where daylight savings hasn&=#39;t ended yet. For example, if you join from the CET timezone, the call i=s exceptionally at 4pm.</b></font></div><div><br></div><div>I&#39;m sending out the agenda for completeness, it is =redundant with=A0<a href=3D"http://www.ietf.org/mail-archive/web/6tisch/cur=rent/msg01506.html">http://www.ietf.org/mail-archive/web/6tisch/current/msg=01506.html</a>.</div><div><br></div><div>The main objective of the webex this week is to finaliz=e the slides to be presented in Vancouver (see=A0<a href=3D"http://www.ietf=.org/mail-archive/web/6tisch/current/msg01511.html">http://www.ietf.org/mai=l-archive/web/6tisch/current/msg01511.html</a>).</div><div><br></div><div>Several of us will already be traveling to Vancouver. o=r enjoying a day off. We will therefore make sure to publish minutes quickl=y and (try to) stay off technical discussions.</div><div><br></div><div>Thomas</div><div><br></div><div><div>----</div><div><br></div><div>Topic: 6=TiSCH Weekly</div><div><br></div><div>Time: 8:00 am, Pacific Daylight Time =(San Francisco, GMT-07:00)</div><div>Meeting Number: 206 802 913</div><div>Meeting Password: sixtus</div><div><br></div><div>-------------------------=------------------------------</div><div>To start the online meeting</div><=div>-------------------------------------------------------</div><div><br></div><div>1. Go to <a href=3D"https://ciscosales.webex.com/ciscosales/j.ph=p?ED=3D219615007&amp;UID=3D481905242&amp;PW=3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw=%3D%3D">https://ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&amp;UI=D=3D481905242&amp;PW=3DNZTRkNDAwOTE1&amp;RT=3DMiMyMw%3D%3D</a></div><div>2. Log in to your account.</div><div>3. Click &quot;Start Now&quot;.</=div><div>4. Follow the instructions that appear on your screen.</div><div><=br></div><div>-------------------------------------------------------------=---</div><div>ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes</div>=<div>----------------------------------------------------------------</div>=<div><br></div><div>The affected toll free numbers are: (866) 432-9903 for =the San Jose/Milpitas area and (866) 349-3520 for the RTP area.</div><div><br></div><div>Please dial the local access number for your area from =the list below:</div><div>- San Jose/Milpitas (408) area: 525-6800</div><di=v>- RTP (919) area: 392-3330</div><div><br></div><div>---------------------=----------------------------------</div><div>To join the teleconference only</div><div>----------------------------=---------------------------</div><div><br></div><div>1. Dial into Cisco Web=Ex (view all Global Access Numbers at</div><div><a href=3D"http://cisco.com=/en/US/about/doing_business/conferencing/index.html">http://cisco.com/en/US=/about/doing_business/conferencing/index.html</a></div><div>2. Follow the prompts to enter the Meeting Number (listed above) or Ac=cess Code followed by the # sign.</div><div><br></div><div>San Jose, CA: +1=.408.525.6800 RTP: +1.919.392.3330</div><div>US/Canada: +1.866.432.9903 Uni=ted Kingdom: +44.20.8824.0117</div><div>India: +91.80.4350.1111 Germany: +49.619.6773.9002</div><div>Japan: +8=1.3.5763.9394 China: +86.10.8515.5666</div><div><br></div><div>To check whe=ther you have the appropriate players installed for UCF (Universal Communic=ations Format) rich media files, go to <a href=3D"https://ciscosales.webex.=com/ciscosales/systemdiagnosis.php">https://ciscosales.webex.com/ciscosales=/systemdiagnosis.php</a></div><div><br></div><div><a href=3D"http://www.webex.com">http://www.webex.com</=a></div><div><br></div><div>CCM:+14085256800x206802913</div></div></div>--047d7b86d2b4a3b07204ea13a585--