From nobody Fri Dec 1 07:37:28 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CDE129418 for ; Fri, 1 Dec 2017 07:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BSHUv_0r6k4 for ; Fri, 1 Dec 2017 07:37:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF741293EC for ; Fri, 1 Dec 2017 07:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32282; q=dns/txt; s=iport; t=1512142622; x=1513352222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G5GN6+OwdNaPd/4sozuiLNRqg+eonOhgTxAKeYhbIaI=; b=gwWK3k0svZyq/y50sqpPs5F9h4drcmIkUj8rGHBiKaTakXn6r6ZWPLU3 E0JZtBHnaT4rYYCAYcKSWfr9RYJyXZ+OILo8xSwO2ksUe02HzY6D2Rp+L +8NVksA8h6ENwF+C5aGVT0I8wTRLp21IiKP07fX5cNpJZk2hmCvGcQP6y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgAydiFa/4QNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeJkTgX1+kC+FUBSCAQojhRgCGoURQBcBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAQMjCkcFEAIBCBEEAQEhBwMCAgIwFAkIAgQOBQiJNmQQpn6CJ?= =?us-ascii?q?4pkAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDQYIKgVaBaYIdWDaDMgGBNhJcgl+?= =?us-ascii?q?CYwWLR41uiS0Ch3KBaYICiSmCH4YQiV6BUYx8hjEwgj8CERkBgTkBIQE2gU1vF?= =?us-ascii?q?TqCKQmETHgBhzsBJgSBCIEUAQEB?= X-IronPort-AV: E=Sophos; i="5.45,344,1508803200"; d="scan'208,217"; a="38997442" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 15:36:03 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vB1Fa3jH027823 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 15:36:03 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Dec 2017 09:36:02 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 1 Dec 2017 09:36:02 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: peter van der Stok Thread-Topic: [Roll] WGLC for draft-ietf-roll-aodv-rpl-02 Thread-Index: AQHTVwjNsLG0DwBOskiKMZkGUkvM26MuUqzg Date: Fri, 1 Dec 2017 15:35:47 +0000 Deferred-Delivery: Fri, 1 Dec 2017 15:35:11 +0000 Message-ID: <25c2ea6bb3b44cd69d4e93c57e7a5c20@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.5] Content-Type: multipart/alternative; boundary="_000_25c2ea6bb3b44cd69d4e93c57e7a5c20XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] WGLC for draft-ietf-roll-aodv-rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:37:13 -0000 --_000_25c2ea6bb3b44cd69d4e93c57e7a5c20XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhbCBhbGwgOg0KDQpPdmVyYWxsIEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IGlz IHJlYWR5IGZvciB0aGUgbmV4dCBzdGFnZSB5ZXQuIENvbXBhcmluZyB0byBkcmFmdC1wZXJraW5z LW1hbmV0LWFvZHZ2MjxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZXJr aW5zLW1hbmV0LWFvZHZ2Mi8+IEkgZmluZCB0aGUgcHJvdG9jb2wgZGVzY3JpcHRpb24gcXVpdGUg dGhpbiBhbmQgSSBkbyBub3Qgc2VlIHRoZSBpbmhlcml0YW5jZSB0aGF0IEkgZXhwZWN0ZWQuIEUu Zy4gSSBleHBlY3RlZCBhIG1vcmUgZGlyZWN0IG1hcHBpbmcsIGxpa2UsIHNhbWUgYmVoYXZpb3Is IGRpZmZlcmVudCBtZXNzYWdlIGZvcm1hdHMsIHRoaXMgbWFwcyB0byB0aGF0LCAgYWxsIHRoaXMg aW5zIGluaGVyaXRlZCwgb3Igc29tZXRoaW5nLiBDYW4gd2UgZG8gc29tZXRoaW5nIHRvIHByb3Zp ZGUgYSBiZXR0ZXIgYWxpZ25tZW50Pw0KDQpJIHdpbGwgbm90IGJlIGNvbW1lbnRpbmcgb24gdGhl IGFzeW1tZXRyaWMgYXNwZWN0IHNpbmNlIGEgZGlzY3Vzc2lvbiBoYXMgc3RhcnRlZCBhbHJlYWR5 IHdpdGggUmFodWwuDQoNCkkgZG8gbm90IHNlZSBsZXNzb25zIGxlYXJuZWQgZnJvbSBleHBlcmlt ZW50YWwgUkZDNjk5NzsgRG8gd2UgaGF2ZSBhbnk/IEluIHNvbWUgYXNwZWN0cyBJIGV2ZW4gc2Vl IGEgKGZpeGFibGUpIHJlZ3Jlc3Npb24sIGUuZy4gdGhlIHVzZSBvZiB0YXJnZXQgb3B0aW9uLg0K DQpBbHNvLCBJ4oCZbSB3b25kZXJpbmc6IERvIHdlIGhhdmUgaW1wbGVtZW50YXRpb25zPw0KDQpQ bGVhc2UgZmluZCBtb3JlICBjb21tZW50cyBiZWxvdzoNCg0KNTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTAyI3NlY3Rpb24tNT4uICBSUkVRIE1l c3NhZ2UNCkkgc3VnZ2VzdCB5b3UgdXNlIGEgVGFyZ2V0IG9wdGlvbiBmb3IgY2FycnkgdGhlIHRh cmdldCBhbmQgbGltaXQgeW91ciBuZXcgcG90aW9uIGNhcnJ5IHRoZSBzZXF1ZW5jZSBudW1iZXJz LiBSRkMgNjk5NyBkb2VzIHRoYXQgYWxyZWFkeS4gVGhpcyBhbGxvd3MgeW91IHRvIGRvIG1hbnkg dGhpbmdzLCBpbmNsdWRpbmcgbG9va2luZyB1cCBtb3JlIHRoYW4gb25lIHRhcmdldCB3aXRoIGEg c2luZ2xlIFJSRVEsIGJ1aWxkaW5nIG1vcmUgdGhhbiBvbmUgUlJFUSBET0RBR3MgZm9yIG1vc3Rs eSB0aGUgcHJpY2Ugb2Ygb25lLiBXaHkgc2hvdWxkIHdlIGxvc2UgdGhhdCBmZWF0dXJlPw0KDQoN CiAgIEluIG9yZGVyIHRvIGVzdGFibGlzaCB0aGUgdXBzdHJlYW0gcm91dGUgZnJvbSBUYXJnTm9k ZSB0byBPcmlnTm9kZSwNCiAgIE9yaWdOb2RlIG11bHRpY2FzdHMgdGhlIFJSRVEtSW5zdGFuY2Ug bWVzc2FnZSAoc2VlIEZpZ3VyZSA0KSB0byBpdHMNCiAgIG9uZS1ob3AgbmVpZ2hib3Vycy4gIElu IG9yZGVyIHRvIGVuYWJsZSBpbnRlcm1lZGlhdGUgbm9kZXMgUl9pIHRvDQogICBhc3NvY2lhdGUg YSBmdXR1cmUgUlJFUCBtZXNzYWdlIHRvIGFuIGluY29taW5nIFJSRVEgbWVzc2FnZSwgdGhlDQog ICBJbnN0YW5jZUlEIG9mIFJSRVEtSW5zdGFuY2UgTVVTVCBhc3NpZ24gYW4gb2RkIG51bWJlci4N Cg0KUkZDIDY5OTcgdXNlcyBsb2NhbCBpbnRhbmNlcyBmb3IgUDJQIHJvdXRlcy4gSW4gZmFjdCB3 ZSBkZWZpbmVkIGxvY2FsIGluc3RhbmNlcyBpbiBSUEwgUkZDIDY1NTAgZm9yIHRoYXQgc3BlY2lm aWMgcHVycG9zZS4gVGhlIGFkdmFudGFnZSBpcyB0aGF0IHRoZSBpbnN0YW5jZSBudW1iZXIgaXMg bWFuYWdlZCBsb2NhbGx5IGJ5IHRoZSBzb3VyY2UuIFRoZSBjb25jZXB0IG9mIGRpcmVjdGlvbiBp cyBhbHNvIGFscmVhZHkgaW5jbHVkZWQgaW4gYSBsb2NhbCBpbnN0YW5jZS4NCg0KDQoNCiAgIFdo ZW4gYW4gaW50ZXJtZWRpYXRlIG5vZGUgUl9pIHJlY2VpdmVzIGEgUlJFUSBtZXNzYWdlIGluIHN0 b3JpbmcNCg0KICAgbW9kZSwgaXQgTVVTVCBzdG9yZSB0aGUgT3JpZ05vZGUncyBJbnN0YW5jZUlE IChSUkVRLUluc3RhbmNlKSBhbG9uZw0KDQogICB3aXRoIHRoZSBvdGhlciByb3V0aW5nIGluZm9y bWF0aW9uIG5lZWRlZCB0byBlc3RhYmxpc2ggdGhlIHJvdXRlIGJhY2sNCg0KICAgdG8gdGhlIE9y aWdOb2RlLiAgVGhpcyB3aWxsIGVuYWJsZSBSX2kgdG8gZGV0ZXJtaW5lIHRoYXQgYSBmdXR1cmUN Cg0KICAgUlJFUCBtZXNzYWdlIChjb250YWluaW5nIGEgcGFpcmVkIEluc3RhbmNlSUQgZm9yIHRo ZSBUYXJnTm9kZSkgbXVzdA0KDQogICBiZSB0cmFuc21pdHRlZCBiYWNrIHRvIHRoZSBPcmlnTm9k ZSdzIElQIGFkZHJlc3MuDQoNCkluZm9ybWF0aW9uIG9mIGxpZmV0aW1lIGlzIGltcG9ydGFudCBo ZXJlLiBIb3cgbG9uZyBzaG91bGQgdGhhdCB0cmFuc2llbnQgc3RhdGUgYmUgbWFpbnRhaW5lZD8g V2hhdCBoYXBwZW5zIHdoZW4gYSBub2RlIGNhbm5vdCBob2xkIHRoYXQgaW5mb3JtYXRpb24gYmVj YXVzZSBpdCBpcyB0ZW1wb3JhcmlseSBzYXR1cmF0ZWQ/DQpSRkM2OTk3IGhhcyBtZXRyaWNzIHRo YXQgcHJvdmlkZSBhIGJvdW5kYXJ5IG9mIGhvdyDigJhmYXLigJkgYSBsb29rdXAgY2FuIGdldCwg ZS5nLiB0aGUgbWF4aW11bSBhY2NlcHRhYmxlIGNvc3QgZm9yIGEgcm91dGUuIFRoaXMgYXZvaWRz IGEgZmxvb2RpbmcgdGhyb3VnaG91dCBhIGxhcmdlciBuZXR3b3JrLiBXaGF0IGRvIHdlIGhhdmUg aGVyZT8NCg0KDQo2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwt YW9kdi1ycGwtMDIjc2VjdGlvbi02Pi4gIFJSRVAgTWVzc2FnZQ0KU2FtZSBhcyB0aGUgUlJBUSwg cGxlYXNlIHNwbGl0IHRvIHVzZSBhIHRhcmdldCBvcHRpb24uIFRoaXMgc2F2ZXMgeW91IHRoZSBs b2dpYyBvZiB0aGUgVCBiaXQsIGp1c3QgZG8gbm90IHBsYWNlIHRoZSB0YXJnZXQgb3B0aW9uLg0K DQoNCg0KICAgIFIgZGV0ZXJtaW5lcyB3aGV0aGVyIGl0cyBpbmZvcm1hdGlvbiBpcyBzdWZmaWNp ZW50bHkgcmVjZW50IGJ5DQoNCiAgIGNvbXBhcmluZyB0aGUgdmFsdWUgaXQgaGFzIHN0b3JlZCBm b3IgdGhlIFNlcXVlbmNlIE51bWJlciBvZiBUYXJnTm9kZQ0KDQogICBhZ2FpbnN0IHRoZSBEZXN0 U2Vxbm8gaW4gdGhlIGluY29taW5nIFJSRVEgbWVzc2FnZS4NCg0KSG93IGlzIHRoZSBjb21wYXJp c29uIGRvbmU/IFlvdSBuZWVkIHRvIGV4cGxhaW4gaG93IHlvdSBoYW5kbGUgd3JhcHBpbmcgU2Vx dWVuY2UgTnVtYmVyLiBTZWUgUlBMICA3LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY1NTAjc2VjdGlvbi03LjI+LiAgU2VxdWVuY2UgQ291bnRlciBPcGVyYXRpb24NCg0KDQoNCg0K ICAgSW4gb3JkZXIgdG8gcmVkdWNlIHRoZSBuZWVkIGZvciB0aGUgVGFyZ05vZGUgSVB2NiBBZGRy ZXNzIHRvIGJlDQoNCiAgIGluY2x1ZGVkIHdpdGggdGhlIFJSRVAgbWVzc2FnZSwgdGhlIEluc3Rh bmNlSUQgb2YgdGhlIFJSRVAtSW5zdGFuY2UNCg0KICAgaXMgcGFpcmVkLCB3aGVuZXZlciBwb3Nz aWJsZSwgd2l0aCB0aGUgSW5zdGFuY2VJRCBmcm9tIHRoZSBSUkVRDQoNCiAgIG1lc3NhZ2UsIHdo aWNoIGlzIGFsd2F5cyBhbiBvZGQgbnVtYmVyLiAgVGhlIHBhaXJpbmcgaXMgYWNjb21wbGlzaGVk DQoNCiAgIGJ5IGFkZGluZyBvbmUgdG8gdGhlIEluc3RhbmNlSUQgZnJvbSB0aGUgUlJFUSBtZXNz YWdlIGFuZCB1c2luZyB0aGF0LA0KDQogICB3aGVuZXZlciBwb3NzaWJsZSwgYXMgdGhlIEluc3Rh bmNlSUQgZm9yIHRoZSBSUkVQIG1lc3NhZ2UuDQoNClRoaXMgZm9yY2VzIHRoZSBuZWVkIGZvciBh IGdsb2JhbGx5IHVuaXF1ZSBpbnN0YW5jZSBJRC4gUmVhbGx5IGEgZGViYXRhYmxlIGlkZWEgYW5k IGxpbWl0cyB0aGUgYXBwbGljYWJpbGl0eSB3YXkgYmVsb3cgd2hhdCBSRkMgNjk5NyBjYW4gZG8u DQpIb3cgZG9lcyB0aGUgaW5zdGFuY2UgSUQgZ2V0IGFzc2lnbmVkPw0KDQpDaGVlcnMsDQoNClBh c2NhbA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSW5lcyBSb2JsZXMNClNlbnQ6IGx1bmRpIDYg bm92ZW1icmUgMjAxNyAxNTowOQ0KVG86IHJvbGwgPHJvbGxAaWV0Zi5vcmc+DQpDYzogcGV0ZXIg dmFuIGRlciBTdG9rIDxzdG9rY29uc0B4czRhbGwubmw+DQpTdWJqZWN0OiBbUm9sbF0gV0dMQyBm b3IgZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTAyDQoNCkRlYXIgYWxsLA0KDQpBIFdvcmtpbmcg R3JvdXAgTGFzdCBjYWxsIChXR0xDKSBzdGFydHMgdG9kYXkgKDExLzA2KSB1bnRpbCAxMS8yMC8y MDE3IGZvciBkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMDINCg0KVGhlIGRyYWZ0IGlzIGF2YWls YWJsZSBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y b2xsLWFvZHYtcnBsLw0KDQpQbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgdG8gc2VlIGlmIHlvdSB0 aGluayB0aGF0IGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhbmQgc2VuZCBjb21tZW50cyB0 byB0aGUgbGlzdCBzdGF0aW5nIHlvdXIgdmlldy4NCg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGlu IGFkdmFuY2UsDQoNClBldGVyIGFuZCBJbmVzLg0K --_000_25c2ea6bb3b44cd69d4e93c57e7a5c20XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IjsNCglwYW5vc2UtMToyIDE1IDMgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmgyDQoJe21zby1zdHlsZS1wcmlv cml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENoYXIiOw0KCW1hcmdpbi10b3A6Mi4wcHQ7DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0RDc4Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uSGVhZGluZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJZm9udC13ZWlnaHQ6Ym9s ZDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw YW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNEQ3ODt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZWFsIGFsbCZuYnNwOzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk92ZXJhbGwgSSBkbyBub3Qg dGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHRoZSBuZXh0IHN0YWdlIHlldC4g Q29tcGFyaW5nIHRvDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlcmtpbnMtbWFuZXQt YW9kdnYyLyI+ZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2djI8L2E+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4gSSBmaW5kIHRoZSBwcm90b2NvbCBkZXNjcmlwdGlvbg0KIHF1 aXRlIHRoaW4gYW5kIEkgZG8gbm90IHNlZSB0aGUgaW5oZXJpdGFuY2UgdGhhdCBJIGV4cGVjdGVk LiBFLmcuIEkgZXhwZWN0ZWQgYSBtb3JlIGRpcmVjdCBtYXBwaW5nLCBsaWtlLCBzYW1lIGJlaGF2 aW9yLCBkaWZmZXJlbnQgbWVzc2FnZSBmb3JtYXRzLCB0aGlzIG1hcHMgdG8gdGhhdCwgJm5ic3A7 YWxsIHRoaXMgaW5zIGluaGVyaXRlZCwgb3Igc29tZXRoaW5nLiBDYW4gd2UgZG8gc29tZXRoaW5n IHRvIHByb3ZpZGUgYSBiZXR0ZXIgYWxpZ25tZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSB3aWxsIG5vdCBiZSBjb21tZW50aW5nIG9uIHRoZSBhc3ltbWV0 cmljIGFzcGVjdCBzaW5jZSBhIGRpc2N1c3Npb24gaGFzIHN0YXJ0ZWQgYWxyZWFkeSB3aXRoIFJh aHVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3Qg c2VlIGxlc3NvbnMgbGVhcm5lZCBmcm9tIGV4cGVyaW1lbnRhbCBSRkM2OTk3OyBEbyB3ZSBoYXZl IGFueT8gSW4gc29tZSBhc3BlY3RzIEkgZXZlbiBzZWUgYSAoZml4YWJsZSkgcmVncmVzc2lvbiwg ZS5nLiB0aGUgdXNlIG9mIHRhcmdldCBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5BbHNvLCBJ4oCZbSB3b25kZXJpbmc6IERvIHdlIGhhdmUgaW1wbGVt ZW50YXRpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlBsZWFzZSBmaW5kIG1vcmUgJm5ic3A7Y29tbWVudHMgYmVsb3c6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGEgbmFtZT0ic2VjdGlvbi01Ij48L2E+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC0wMiNzZWN0aW9uLTUiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6c2VjdGlvbi01Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+NTwvc3Bhbj48L2I+PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6c2VjdGlvbi01Ij48L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6c2VjdGlvbi01Ij48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi4mbmJzcDsN CiBSUkVRIE1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgc3VnZ2VzdCB5b3UgdXNlIGEg VGFyZ2V0IG9wdGlvbiBmb3IgY2FycnkgdGhlIHRhcmdldCBhbmQgbGltaXQgeW91ciBuZXcgcG90 aW9uIGNhcnJ5IHRoZSBzZXF1ZW5jZSBudW1iZXJzLiBSRkMgNjk5NyBkb2VzIHRoYXQgYWxyZWFk eS4gVGhpcyBhbGxvd3MgeW91IHRvIGRvDQogbWFueSB0aGluZ3MsIGluY2x1ZGluZyBsb29raW5n IHVwIG1vcmUgdGhhbiBvbmUgdGFyZ2V0IHdpdGggYSBzaW5nbGUgUlJFUSwgYnVpbGRpbmcgbW9y ZSB0aGFuIG9uZSBSUkVRIERPREFHcyBmb3IgbW9zdGx5IHRoZSBwcmljZSBvZiBvbmUuIFdoeSBz aG91bGQgd2UgbG9zZSB0aGF0IGZlYXR1cmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluIG9yZGVyIHRvIGVzdGFibGlzaCB0aGUg dXBzdHJlYW0gcm91dGUgZnJvbSBUYXJnTm9kZSB0byBPcmlnTm9kZSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE9yaWdO b2RlIG11bHRpY2FzdHMgdGhlIFJSRVEtSW5zdGFuY2UgbWVzc2FnZSAoc2VlIEZpZ3VyZSA0KSB0 byBpdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IG9uZS1ob3AgbmVpZ2hib3Vycy4mbmJzcDsgSW4gb3JkZXIgdG8gZW5h YmxlIGludGVybWVkaWF0ZSBub2RlcyBSX2kgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFzc29jaWF0ZSBhIGZ1dHVy ZSBSUkVQIG1lc3NhZ2UgdG8gYW4gaW5jb21pbmcgUlJFUSBtZXNzYWdlLCB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IEluc3RhbmNlSUQgb2YgUlJFUS1JbnN0YW5jZSBNVVNUIGFzc2lnbiBhbiBvZGQgbnVtYmVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SRkMgNjk5NyB1c2VzIGxvY2FsIGludGFuY2VzIGZvciBQMlAg cm91dGVzLiBJbiBmYWN0IHdlIGRlZmluZWQgbG9jYWwgaW5zdGFuY2VzIGluIFJQTCBSRkMgNjU1 MCBmb3IgdGhhdCBzcGVjaWZpYyBwdXJwb3NlLiBUaGUgYWR2YW50YWdlIGlzIHRoYXQgdGhlIGlu c3RhbmNlDQogbnVtYmVyIGlzIG1hbmFnZWQgbG9jYWxseSBieSB0aGUgc291cmNlLiBUaGUgY29u Y2VwdCBvZiBkaXJlY3Rpb24gaXMgYWxzbyBhbHJlYWR5IGluY2x1ZGVkIGluIGEgbG9jYWwgaW5z dGFuY2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4gaW50ZXJt ZWRpYXRlIG5vZGUgUl9pIHJlY2VpdmVzIGEgUlJFUSBtZXNzYWdlIGluIHN0b3Jpbmc8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbW9kZSwgaXQgTVVTVCBzdG9yZSB0aGUgT3Jp Z05vZGUncyBJbnN0YW5jZUlEIChSUkVRLUluc3RhbmNlKSBhbG9uZzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyAmbmJzcDt3aXRoIHRoZSBvdGhlciByb3V0aW5nIGluZm9ybWF0aW9uIG5l ZWRlZCB0byBlc3RhYmxpc2ggdGhlIHJvdXRlIGJhY2s8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgdG8gdGhlIE9yaWdOb2RlLiZuYnNwOyBUaGlzIHdpbGwgZW5hYmxlIFJfaSB0 byBkZXRlcm1pbmUgdGhhdCBhIGZ1dHVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBSUkVQIG1lc3NhZ2UgKGNvbnRhaW5pbmcgYSBwYWlyZWQgSW5zdGFuY2VJRCBmb3IgdGhl IFRhcmdOb2RlKSBtdXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGJlIHRy YW5zbWl0dGVkIGJhY2sgdG8gdGhlIE9yaWdOb2RlJ3MgSVAgYWRkcmVzcy48bzpwPjwvbzpwPjwv cHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkluZm9ybWF0aW9uIG9mIGxpZmV0aW1lIGlzIGltcG9ydGFudCBoZXJlLiBIb3cgbG9uZyBz aG91bGQgdGhhdCB0cmFuc2llbnQgc3RhdGUgYmUgbWFpbnRhaW5lZD8gV2hhdCBoYXBwZW5zIHdo ZW4gYSBub2RlIGNhbm5vdCBob2xkIHRoYXQgaW5mb3JtYXRpb24gYmVjYXVzZSBpdA0KIGlzIHRl bXBvcmFyaWx5IHNhdHVyYXRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UkZDNjk5NyBoYXMgbWV0cmlj cyB0aGF0IHByb3ZpZGUgYSBib3VuZGFyeSBvZiBob3cg4oCYZmFy4oCZIGEgbG9va3VwIGNhbiBn ZXQsIGUuZy4gdGhlIG1heGltdW0gYWNjZXB0YWJsZSBjb3N0IGZvciBhIHJvdXRlLiBUaGlzIGF2 b2lkcyBhIGZsb29kaW5nIHRocm91Z2hvdXQgYSBsYXJnZXINCiBuZXR3b3JrLiBXaGF0IGRvIHdl IGhhdmUgaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxoMj48YSBuYW1lPSJzZWN0aW9uLTYiPjwvYT48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYt cnBsLTAyI3NlY3Rpb24tNiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpzZWN0aW9uLTYiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij42PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOnNlY3Rpb24t NiI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOnNlY3Rpb24tNiI+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4uJm5ic3A7DQogUlJFUCBNZXNzYWdlPG86cD48L286cD48L3NwYW4+PC9oMj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TYW1l IGFzIHRoZSBSUkFRLCBwbGVhc2Ugc3BsaXQgdG8gdXNlIGEgdGFyZ2V0IG9wdGlvbi4gVGhpcyBz YXZlcyB5b3UgdGhlIGxvZ2ljIG9mIHRoZSBUIGJpdCwganVzdCBkbyBub3QgcGxhY2UgdGhlIHRh cmdldCBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBSIGRl dGVybWluZXMgd2hldGhlciBpdHMgaW5mb3JtYXRpb24gaXMgc3VmZmljaWVudGx5IHJlY2VudCBi eTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBjb21wYXJp bmcgdGhlIHZhbHVlIGl0IGhhcyBzdG9yZWQgZm9yIHRoZSBTZXF1ZW5jZSBOdW1iZXIgb2YgVGFy Z05vZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBhZ2FpbnN0IHRoZSBEZXN0U2Vxbm8gaW4gdGhlIGluY29t aW5nIFJSRVEgbWVzc2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxoMz48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93IGlzIHRoZSBjb21wYXJpc29uIGRvbmU/IFlvdSBu ZWVkIHRvIGV4cGxhaW4gaG93IHlvdSBoYW5kbGUgd3JhcHBpbmcgU2VxdWVuY2UgTnVtYmVyLiBT ZWUgUlBMICZuYnNwOzwvc3Bhbj48YSBuYW1lPSJzZWN0aW9uLTcuMiI+PC9hPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUwI3NlY3Rpb24tNy4yIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOiZxdW90O3NlY3Rpb24tN1wuMiZxdW90OyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjcuMjwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazomcXVvdDtzZWN0aW9uLTdcLjIm cXVvdDsiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazomcXVvdDtzZWN0aW9u LTdcLjImcXVvdDsiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LiZuYnNw Ow0KIFNlcXVlbmNlIENvdW50ZXIgT3BlcmF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L2gzPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSW4gb3Jk ZXIgdG8gcmVkdWNlIHRoZSBuZWVkIGZvciB0aGUgVGFyZ05vZGUgSVB2NiBBZGRyZXNzIHRvIGJl PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGluY2x1ZGVkIHdpdGggdGhlIFJS RVAgbWVzc2FnZSwgdGhlIEluc3RhbmNlSUQgb2YgdGhlIFJSRVAtSW5zdGFuY2U8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXMgcGFpcmVkLCB3aGVuZXZlciBwb3NzaWJsZSwg d2l0aCB0aGUgSW5zdGFuY2VJRCBmcm9tIHRoZSBSUkVRPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UsIHdoaWNoIGlzIGFsd2F5cyBhbiBvZGQgbnVtYmVyLiZuYnNw OyBUaGUgcGFpcmluZyBpcyBhY2NvbXBsaXNoZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgYnkgYWRkaW5nIG9uZSB0byB0aGUgSW5zdGFuY2VJRCBmcm9tIHRoZSBSUkVRIG1l c3NhZ2UgYW5kIHVzaW5nIHRoYXQsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IHdoZW5ldmVyIHBvc3NpYmxlLCBhcyB0aGUgSW5zdGFuY2VJRCBmb3IgdGhlIFJSRVAgbWVzc2Fn ZS4mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGZvcmNlcyB0aGUgbmVlZCBmb3IgYSBnbG9i YWxseSB1bmlxdWUgaW5zdGFuY2UgSUQuIFJlYWxseSBhIGRlYmF0YWJsZSBpZGVhIGFuZCBsaW1p dHMgdGhlIGFwcGxpY2FiaWxpdHkgd2F5IGJlbG93IHdoYXQgUkZDIDY5OTcgY2FuIGRvLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhvdyBkb2VzIHRoZSBpbnN0YW5jZSBJRCBnZXQgYXNzaWduZWQ/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9sbCBbbWFpbHRvOnJvbGwtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SW5lcyBSb2JsZXM8YnI+DQo8Yj5T ZW50OjwvYj4gbHVuZGkgNiBub3ZlbWJyZSAyMDE3IDE1OjA5PGJyPg0KPGI+VG86PC9iPiByb2xs ICZsdDtyb2xsQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gcGV0ZXIgdmFuIGRlciBTdG9r ICZsdDtzdG9rY29uc0B4czRhbGwubmwmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtSb2xsXSBX R0xDIGZvciBkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RGVhciBhbGwsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkEgV29ya2luZyBHcm91cCBMYXN0IGNhbGwg KFdHTEMpIHN0YXJ0cyB0b2RheSAoMTEvMDYpIHVudGlsIDExLzIwLzIwMTcgZm9yIGRyYWZ0LWll dGYtcm9sbC1hb2R2LXJwbC0wMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5UaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5QbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgdG8gc2Vl IGlmIHlvdSB0aGluayB0aGF0IGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhbmQgc2VuZCBj b21tZW50cyB0byB0aGUgbGlzdCBzdGF0aW5nIHlvdXIgdmlldy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5UaGFuayB5b3UgdmVyeSBtdWNoIGluIGFkdmFuY2UsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlBldGVyIGFuZCBJbmVzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_25c2ea6bb3b44cd69d4e93c57e7a5c20XCHRCD001ciscocom_-- From nobody Mon Dec 4 01:56:49 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A695D124207 for ; Mon, 4 Dec 2017 01:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRW5hU3uoD4x for ; Mon, 4 Dec 2017 01:56:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDC51241F5 for ; Mon, 4 Dec 2017 01:56:47 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 048F484F27BA3 for ; Mon, 4 Dec 2017 09:56:44 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 09:56:45 +0000 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.219]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 15:26:34 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks , Rahul Jadhav CC: Ines Robles Thread-Topic: [Roll] Fwd: Review of useofrplinfo-19 Thread-Index: AQHTaVFANjK3yVyb5UeGRrn6O12GkKMy2Edg Date: Mon, 4 Dec 2017 09:56:33 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DB7E556@BLREML503-MBX.china.huawei.com> References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> <13976.1511987564@obiwan.sandelman.ca> In-Reply-To: <13976.1511987564@obiwan.sandelman.ca> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 09:56:49 -0000 Rahul> [RJ]: Lingering EDNOTE... I like using IP-in-IP destined to root Rahul> (because its relatively less processing overhead!), but hop-by-h= op has Rahul> its own advantage. The advantage is, If there is RPL aware node = with a Rahul> DAO-advertised IPv6 address not using the DIO-advertised network Rahul> prefix in PIO, then the routing would be faster/more efficient (= since Rahul> 6LR_i would be able to remove IP-in-IP and check the routing tab= le for Rahul> the dst in underlying IP hdr). Mcr> yes, you are right. Mcr> Can you tell us why such a node would exist? What's the use case? I do not have the use-case now. But by this change we disallow something wh= ich RFC6550 did allow.=20 Now I tried understanding the impact if the dst node is incorrectly identif= ied as ~Raf and following are my observations: 1. Storing MOP: (Raf to Raf) and (Raf to ~Raf)=20 Handling is exactly same. Thus no impact if identification goes wrong. 2. Storing MOP: (~Raf to Raf) and (~Raf to ~Raf)=20 Handling is Almost same. There is slight difference about what dst is put = in IP-in-IP header, but overall this has no impact i.e. IP-in-IP-hop (hop a= s dst) will be used but things should still work equally well. 3. Storing MOP: (Int to Raf) and (Root to Raf) is not a problem since BR kn= ows Raf is a Raf without depending on matching network prefix. 4. Non-storing MOP: This MOP does not have an impact because all the packet= s go to the 6LBR and 6LBR definitely knows whether node is Raf. Point is, there seems no (very less in one case) impact even if identificat= ion for Raf goes wrong. Or am I missing something very basic here? From nobody Mon Dec 4 04:42:24 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39E9126DC2 for ; Mon, 4 Dec 2017 04:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtqmdFqf29jv for ; Mon, 4 Dec 2017 04:42:21 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF14126BF0 for ; Mon, 4 Dec 2017 04:42:20 -0800 (PST) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id A47EE6E5 for ; Mon, 4 Dec 2017 13:42:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1512391338; bh=uefMuNBbhtFnjgJuPH9jOy42nISk1fjKro95cDdxJFc=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=q4KmKcpgTtqB2M6UnSSdeFLfQBDq3LLP8Wdn/YFXL6WI0XdZ1N92h6nwtMuvmcu4v FxxbEemiEY9y7MjmTk2qKmbht+luA3cnH8/3P7fwSHtv25ggeqB8D0s8uwzBUiE7yz /GPhvsK/1UBgf9Lsj5n1b+6Inb5J1VsXv0VUtuRUnuzBNAQSIIlk0rRaggR64Pe/EP FiPGHBtYPRww5DU2d+jSOkGaxQVOOGbD5lKK4Pay0JOd+8MI+UUkDOHmAmSGJl/ayO LAOCPXnCB1+fqqJ/dM1kyi5Phxiv1TBSrqkOYaGO9ObeoE0PzeNUSJP+T+DfvD/jmT z5DdvLxhFNeVw== Received: from mail-qt0-f176.google.com ([209.85.216.176]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Mon, 4 Dec 2017 13:42:15 +0100 (CET) Received: by mail-qt0-f176.google.com with SMTP id m59so3648725qte.11 for ; Mon, 04 Dec 2017 04:42:14 -0800 (PST) X-Gm-Message-State: AKGB3mIuLvUzZYm4cnLsdhS4B+VOyqqr7n3RLALLbr/YqZkjbPpK/CZP K9/PVatHOjwIlYh0lqyxWFT93wbaV/Sy7kpB6W4= X-Google-Smtp-Source: AGs4zMYXxv82EWGSYLkVTus/S7CfQDzCfOGBrUv9FiNuVz+SGJf2XO3SSD//C3qv+YKs5fKS+wc8MWYs808zOlfLzBM= X-Received: by 10.200.3.65 with SMTP id w1mr21261134qtg.297.1512391332331; Mon, 04 Dec 2017 04:42:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.150.163 with HTTP; Mon, 4 Dec 2017 04:41:51 -0800 (PST) In-Reply-To: <151221809789.7535.230934676547066993.idtracker@ietfa.amsl.com> References: <151221809789.7535.230934676547066993.idtracker@ietfa.amsl.com> From: Remous-Aris Koutsiamanis Date: Mon, 4 Dec 2017 13:42:16 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: roll@ietf.org Cc: Chenyang Ji , Nicolas Montavont , Diego Dujovne , Georgios Papadopoulos Content-Type: multipart/alternative; boundary="f4030435aa74200939055f830ccc" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] New Version Notification for draft-ji-traffic-aware-objective-function-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 12:42:24 -0000 --f4030435aa74200939055f830ccc Content-Type: text/plain; charset="UTF-8" Hello all, We have just submitted a new draft (draft-ji-traffic-aware-objective-function-00) describing an Traffic-aware objective function and the extension to the DAG Metric Container. This extension aims to help in distributing network traffic load in RPL networks, so that packet transmission (especially forwarding) duties are shared more equitably between nodes. The idea is that by having a more balanced network, we can avoid some nodes from prematurely exhausting their energy stores. This draft defines an extension to the DAG Metric Container type, used in DIO messages, and an Objective Function that utilizes this information in order to perform parent selection in a way that avoids overconcentration of child nodes onto parent nodes. Best, Aris On Sat, Dec 2, 2017 at 1:35 PM, wrote: > > A new version of I-D, draft-ji-traffic-aware-objective-function-00.txt > has been successfully submitted by Remous-Aris Koutsiamanis and posted to > the > IETF repository. > > Name: draft-ji-traffic-aware-objective-function > Revision: 00 > Title: Traffic-aware Objective Function > Document date: 2017-12-01 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet- > drafts/draft-ji-traffic-aware-objective-function-00.txt > Status: https://datatracker.ietf.org/doc/draft-ji-traffic-aware- > objective-function/ > Htmlized: https://tools.ietf.org/html/draft-ji-traffic-aware- > objective-function-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ji-traffic- > aware-objective-function-00 > > > Abstract: > This document proposes a packet transmission rate metric for parent > selection. This metric represents the amount of traffic that the > node is transmitting to the current parent node. This document also > proposes an Objective Function (OF) using the packet transmission > rate metric for parent selection in order to balance the amount of > traffic between nodes. > > > > > 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 > > --f4030435aa74200939055f830ccc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

We have just submitted a new draft (draf= t-ji-traffic-aware-ob= jective-function-00) describing an Traffic-aware objective function and the= extension to the DAG Metric Container.

This extension aims to help = in distributing network traffic load in RPL networks, so that packet transmission (especially forward= ing) duties are shared more equitably between nodes.
The idea is that by= having a more balanced network, we can avoid some nodes from prematurely e= xhausting their energy stores.

This draft defines an extension to th= e DAG Metric Container type, used in DIO messages, and an Objective Function that utilizes this infor= mation in order to perform parent selection in
a way that avoids overconcentration of child nodes= onto parent nodes.

Best,
Aris

On Sat, Dec 2, 2017 at 1:35 PM, <internet-drafts@ietf.org<= /a>> wrote:

A new version of I-D, draft-ji-traffic-aware-objective-function-00.txt=
has been successfully submitted by Remous-Aris Koutsiamanis and posted to t= he
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ji-traffic-aware-o= bjective-function
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Traffic-aware Objective Function Document date:=C2=A0 2017-12-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-ji-traffic-aware-objective-function-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ji-traffic-awar= e-objective-function/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ji-traffic-aware-object= ive-function-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ji-traff= ic-aware-objective-function-00


Abstract:
=C2=A0 =C2=A0This document proposes a packet transmission rate metric for p= arent
=C2=A0 =C2=A0selection.=C2=A0 This metric represents the amount of traffic = that the
=C2=A0 =C2=A0node is transmitting to the current parent node.=C2=A0 This do= cument also
=C2=A0 =C2=A0proposes an Objective Function (OF) using the packet transmiss= ion
=C2=A0 =C2=A0rate metric for parent selection in order to balance the amoun= t of
=C2=A0 =C2=A0traffic between nodes.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--f4030435aa74200939055f830ccc-- From nobody Mon Dec 4 05:53:14 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72536126C19 for ; Mon, 4 Dec 2017 05:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxcAkpz8G-uN for ; Mon, 4 Dec 2017 05:53:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4F2124BAC for ; Mon, 4 Dec 2017 05:53:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C54620072; Mon, 4 Dec 2017 08:55:57 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 206E182CCB; Mon, 4 Dec 2017 08:53:10 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: Rahul Jadhav , Ines Robles In-Reply-To: <982B626E107E334DBE601D979F31785C5DB7E556@BLREML503-MBX.china.huawei.com> References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> <13976.1511987564@obiwan.sandelman.ca> <982B626E107E334DBE601D979F31785C5DB7E556@BLREML503-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 13:53:12 -0000 --=-=-= Content-Type: text/plain Rahul Arvind Jadhav wrote: > Point is, there seems no (very less in one case) impact even if > identification for Raf goes wrong. Or am I missing something very basic > here? I think that I agree, there is little that breaks. Some extra encapsulation may occur, as the heuristic breaks for some senders. The DODAG root will know the correct information by DAOs in non-storing mode, and additionally any 6LRs above the node with the non-PIO address will know that it's in the DODAG. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlolU0UACgkQgItw+93Q 3WUkpwf/ft0yUHljNLs2NdFmLGZTU+c9MvWgrOibTi5uHZalOLBdp7iOyYMXCd+r QfBQhwhjhf3CFr6jvo/tDAqa6aCsGNi8K32U/f6rgDoPwx+I7t5kzzp/+/aemokH zFfks8tYqW0VJtzTrBOhxugndPp0uMnZHAOyonqbrvBUrHfH1BDkx4TgolaS6QCx u9QafGf8ahwQf9NGu0L/iO0v25IKyxx12vxv1SlwVkrxXDq8Esto/KAReggUWuFU YjpcQaFlo0JAadH8bl8fSlS5KVp1fn6nq5IOTOkAuBTyBjmJz/ow53gp5w+nEmbk 5BpEtNv4fVoaCsmESWVz8XTM2khNAw== =4dcI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 6 02:44:27 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD282129601 for ; Wed, 6 Dec 2017 02:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSA8rmJmzT8P for ; Wed, 6 Dec 2017 02:44:22 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51EC1279E5 for ; Wed, 6 Dec 2017 02:44:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id A951E81CDB for ; Wed, 6 Dec 2017 11:44:19 +0100 (CET) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id IrCZwDkD8BTm for ; Wed, 6 Dec 2017 11:44:19 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 21D3781CCC for ; Wed, 6 Dec 2017 11:44:19 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 21D3781CCC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.net; s=6A0CDB44-C782-11E6-82EC-91BDBA474D24; t=1512557059; bh=RmQ80B3EqZtOHYowdxBkaLkyD+1QFYSOOG8jRK9u8VE=; h=Date:From:To:Message-ID:MIME-Version; b=KumDu4So685nLiPOjZKYs1jqali7nC2J1l1OXQfBhdA9e3LrEtpv5Z5MD/VRmwX7v 5mzjsu11zTzfrqrX13QgJIfJ0eOZHJiqYr3JpxMGNd6qjtbwoxEA40ZC4DViyx+Vdr vXEA9u/GHneFxglAzXhQavUD5cDc9ItA+juOC/rY= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id JMhk4kWYrN50 for ; Wed, 6 Dec 2017 11:44:19 +0100 (CET) Received: from zmail131.enst.fr (zmail131.enst.fr [137.194.2.203]) by zproxy120.enst.fr (Postfix) with ESMTP id ED94F81CCB for ; Wed, 6 Dec 2017 11:44:18 +0100 (CET) Date: Wed, 6 Dec 2017 11:44:18 +0100 (CET) From: Chenyang JI To: roll Message-ID: <376455077.14923086.1512557058890.JavaMail.zimbra@imt-atlantique.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:660:7301:51:7877:3d2f:7cc7:c0a3] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF56 (Linux)/8.7.11_GA_1854) Thread-Index: M+ukIsLRWUOPcTuCQkg+twtaUci4rw== Thread-Topic: RPL-BIER question Archived-At: Subject: [Roll] RPL-BIER question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 10:44:25 -0000 Good morning, I read the draft draft-thubert-roll-bier-0 and there are points i could'nt understand. sentences in "" are from draft draft-thubert-roll-bier-00,and the questions are below 1) in section 6.1.1 " Several methods may be used to associate a bit in a biString to an IPv6 address. In order to guarantee interoperability, this specification RECOMMENDS that all implementations provide at least the method described therein. " in the last sentence,the word 'methods' refers methods to associate bit to an address? in the last sentence,where does the word 'therein' refers to? 2) in section 6.1 " In the bit-by-bit case, each bit is mapped in an unequivocal fashion with a single addressable resource in the network. In RPL-BIER storing mode, this is an IPv6 address as advertised in RPL storing mode DAO messages, whereas in RPL-BIER non-storing mode, this is a parent-child relationship as advertised in RPL non-storing mode DAO messages. " how can a parent-child relationship be mapped? 3) in section 6.1.1 " The 6LR maintains a binding cache entry (BCE) for the 6LN based on successful DAC messages. With this specification, the 6LR also stores the matching between the address and the bitString and uses it for searching its children when forwarding packets in non-storing mode (see Section 6.1.3). " Which information will each entry hold? matching IPv6 address -Group ID/bit string which bit string is an aggregation of bit strings of node's children or matching IPv6 address -Group ID/bit position bit position is the bitstring assigned to each address from root node 4) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " If i understand correct,1 DAO message MAY contain more than 1 BIO. Parent node generate BIO by aggregate child bitstring with its own per group,so parents and child may belong to different groups? 5) in section 6.1.3 " Forwarding is based on matching a bitString in a packet with those of children. For unicast packets, only one matching child gets the packet. For multicast packets, all matching children get a copy. Matches are found by scanning all children and performing bitwise operations as follows. " The binding cache entry is updated with each successful Duplicate address confirmation(DAC) which are being exchanged during duplicate address detection(DAD) to assign unique address to each node. If i understand correct DAD happens in neighbor discovery phase before parent selection so entries the node maintain may not belong to its child or its child may not be included in these entries. Or each node holds every neighbor's bit string in the binding cache entry? 6) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " In storing mode,DAO messages are send to parent,what's the point for parent to aggregate bitstring of its child? 7) section 6.1.4 Reliable Multicast based on Bit-by-bit BitStrings describes how multicast canbe achieved in storing and non-storing mode, could you show me an example of it? draft-thubert-roll-bier-00 https://tools.ietf.org/pdf/draft-thubert-roll-bier-00.pdf Thank you, Chenyang ji From nobody Wed Dec 6 05:30:59 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE51243F3 for ; Wed, 6 Dec 2017 05:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGuiIbvMI4Pd for ; Wed, 6 Dec 2017 05:30:55 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5111201FA for ; Wed, 6 Dec 2017 05:30:54 -0800 (PST) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id DACA5945 for ; Wed, 6 Dec 2017 14:30:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1512567052; bh=d5elB+csEKV0FJ392Mp/z8Yopxv8m74Boe3P3WXvhxw=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=KzIg3NocY1ymm7G+B/ankkkaK4NxeJQ66ixNcRYwyCS20PTakbuZF3n3SJl8GM3iP WHGFiPYKE2Xle9gTSgzasMZyIY1oVafTEB1oaAgzDg7mehpPIwT93yCNlGid/zs8o7 29toGNPKNwq81D/R/vkyg5jQNm8dKDXlEBl9mp/L5UEhsPyqDFgAPrfJlBLA9OuUds Uf3DRB9bLtGMfG7vWsdHdCx0h8Gko+pdGFnnnpCpU5bVQiK7gCwp0H7G8bTJIs9AtZ +dECbId868YrAr7ssx7cVPqVCyhHu96qWg9NYOqGPrScBjJrmOiEFCbVUyd7Iljqua Ts8NFU9ot9Y6A== Received: from mail-qt0-f176.google.com ([209.85.216.176]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Wed, 6 Dec 2017 14:30:44 +0100 (CET) Received: by mail-qt0-f176.google.com with SMTP id w10so8874245qtb.10 for ; Wed, 06 Dec 2017 05:30:44 -0800 (PST) X-Gm-Message-State: AKGB3mINXspfdm7fAezBOkAO8EiT9e8xSctn1uq2JBY38bVD2kdvlhEm CJvEqtbEIhASe2TMyyVoaMAt5nwLaE+A58kinK4= X-Google-Smtp-Source: AGs4zMay7fH9RNPk6iu4/qlMdgcaIl/j9fF1qBa349aZiWNhAMXdDTdFM34RfjWUHbx85gee05AoZwTGXQFhrEeu2+0= X-Received: by 10.200.52.146 with SMTP id w18mr4997596qtb.228.1512567041621; Wed, 06 Dec 2017 05:30:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.150.163 with HTTP; Wed, 6 Dec 2017 05:30:21 -0800 (PST) In-Reply-To: <151255814620.30686.8695526461123273289.idtracker@ietfa.amsl.com> References: <151255814620.30686.8695526461123273289.idtracker@ietfa.amsl.com> From: Remous-Aris Koutsiamanis Date: Wed, 6 Dec 2017 14:30:46 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: roll@ietf.org Cc: Chenyang Ji , Nicolas Montavont , Diego Dujovne , Georgios Papadopoulos Content-Type: multipart/alternative; boundary="001a11359aa8370764055fabf523" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] New Version Notification for draft-ji-roll-traffic-aware-objective-function-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 13:30:58 -0000 --001a11359aa8370764055fabf523 Content-Type: text/plain; charset="UTF-8" Hello all, We have just submitted a new draft (*draft-ji-roll-traffic-aware-object* *ive-function-00*) describing an Traffic-aware objective function and the extension to the DAG Metric Container. The previous version was misnamed as draft-ji-roll-traffic-aware-object ive-function-00. This extension aims to help in distributing network traffic load in RPL networks, so that packet transmission (especially forwarding) duties are shared more equitably between nodes. The idea is that by having a more balanced network, we can avoid some nodes from prematurely exhausting their energy stores. This draft defines an extension to the DAG Metric Container type, used in DIO messages, and an Objective Function that utilizes this information in order to perform parent selection in a way that avoids overconcentration of child nodes onto parent nodes. Best, Aris On Wed, Dec 6, 2017 at 12:02 PM, wrote: > > A new version of I-D, draft-ji-roll-traffic-aware- > objective-function-00.txt > has been successfully submitted by Remous-Aris Koutsiamanis and posted to > the > IETF repository. > > Name: draft-ji-roll-traffic-aware-objective-function > Revision: 00 > Title: Traffic-aware Objective Function > Document date: 2017-12-06 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet- > drafts/draft-ji-roll-traffic-aware-objective-function-00.txt > Status: https://datatracker.ietf.org/doc/draft-ji-roll-traffic- > aware-objective-function/ > Htmlized: https://tools.ietf.org/html/draft-ji-roll-traffic-aware- > objective-function-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ji-roll- > traffic-aware-objective-function-00 > > > Abstract: > This document proposes a packet transmission rate metric for parent > selection. This metric represents the amount of traffic that the > node is transmitting to the current parent node. This document also > proposes an Objective Function (OF) using the packet transmission > rate metric for parent selection in order to balance the amount of > traffic between nodes. > > > > > 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 > > --001a11359aa8370764055fabf523 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

We have just submitted a new draft = (draft-ji-roll-traffic-aware-objective-function-00) de= scribing an Traffic-aware objective function and the extension to the DAG M= etric Container.
The previous version was misnamed as draft-ji-r= oll-traffic-aware-objective-function-00.

This extension aims t= o help in distributing network traffic load in RPL networks, so that pack= et transmission (especially forwarding) duties are shared more equitably be= tween nodes.
The idea is that by having a more balanced network, we can = avoid some nodes from prematurely exhausting their energy stores.

Th= is draft defines an extension to the DAG Metric Container type, used in DIO messages, and an Objective Function that utilizes this information in or= der to perform parent selection in
a way that avoids overconcentration of child nodes onto parent nodes.

Best,
Aris

On Wed, Dec 6, 2017 a= t 12:02 PM, <internet-drafts@ietf.org> wrote:

A new version of I-D, draft-ji-roll-traffic-aware-objective-function-0= 0.txt
has been successfully submitted by Remous-Aris Koutsiamanis and posted to t= he
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ji-roll-traffic-aware-<= wbr>objective-function
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Traffic-aware Objective Function Document date:=C2=A0 2017-12-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-ji-roll-traffic-aware-objective-function-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ji-roll-tr= affic-aware-objective-function/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ji-roll-traffic-aware-<= wbr>objective-function-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ji-= roll-traffic-aware-objective-function-00


Abstract:
=C2=A0 =C2=A0This document proposes a packet transmission rate metric for p= arent
=C2=A0 =C2=A0selection.=C2=A0 This metric represents the amount of traffic = that the
=C2=A0 =C2=A0node is transmitting to the current parent node.=C2=A0 This do= cument also
=C2=A0 =C2=A0proposes an Objective Function (OF) using the packet transmiss= ion
=C2=A0 =C2=A0rate metric for parent selection in order to balance the amoun= t of
=C2=A0 =C2=A0traffic between nodes.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a11359aa8370764055fabf523-- From nobody Fri Dec 8 06:06:37 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9C124D37 for ; Fri, 8 Dec 2017 06:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYaddzIy9hat for ; Fri, 8 Dec 2017 06:06:33 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3106C124D68 for ; Fri, 8 Dec 2017 06:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5779; q=dns/txt; s=iport; t=1512741993; x=1513951593; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8q3lY8R4mKW9j9Fde+538QmRpweiz/kmxQInmAyU21Q=; b=JnR8dLkwU1m7I8E83vCuCm8TaOtQmD6Ap53ZtYljI+boNaDamclE+zME R3wwuF7Rj0l/+svB7x+2OIZ5l8TGhWepCrVygJBTxGvReOVhj2s3QvCpg WfiVcra5Lg1faJyKoJgGoVVtfpZT6LqKEXBEQQjdeFrg58gLq7eV/C741 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXBwC/mypa/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0JweOHI5iAR2Ce1yVMoIVChgNhRYChWk/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSMCAQECAQE4NAQXAgEINhAnCyUBAQQTCIogEKomimQBAQEBAQEBAQIBA?= =?us-ascii?q?QEBAQEBAQEaBYNbgWEBKYFWgWmBG4FaNoMyh2UFmUeJQQKHd4NwiS6CH4YSizm?= =?us-ascii?q?NCIknAhEZAYE6AR85gU9vFTqCGQEPhFV4AYkggRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,377,1508803200"; d="scan'208";a="333667269" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 14:06:32 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB8E6WaW014750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Dec 2017 14:06:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 08:06:31 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 8 Dec 2017 08:06:31 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL-BIER question Thread-Index: AdNwLYk9AjpTKp6xT+OAgTKYgo8iBA== Date: Fri, 8 Dec 2017 14:06:17 +0000 Deferred-Delivery: Fri, 8 Dec 2017 14:06:00 +0000 Message-ID: References: <376455077.14923086.1512557058890.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: <376455077.14923086.1512557058890.JavaMail.zimbra@imt-atlantique.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] RPL-BIER question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 14:06:35 -0000 Hello Chenyang Thanks for your uinterest! Please see below: 1) in section 6.1.1 " Several methods may be used to associate a bit in a biString to an IPv6 address. In order to guarantee interoperability, this specification RECOMMENDS that all implementations provide at least the method described therein. " in the last sentence,the word 'methods' refers methods to associate bit to = an address? in the last sentence,where does the word 'therein' refers to? [Pascal] It refers to the current section; that section suggests that the 6= LBR allocates it and returns it in the DAC. Note that this is for storing m= ode. 2) in section 6.1 " In the bit-by-bit case, each bit is mapped in an unequivocal fashion with a single addressable resource in the network. In RPL-BIER storing mode, this is an IPv6 address as advertised in RPL storing mode DAO messages, whereas in RPL-BIER non-storing mode, this is a parent-child relationship as advertised in RPL non-storing mode DAO messages. =20 " how can a parent-child relationship be mapped? [Pascal] That would be by setting the bit associated to the child. In non-s= toring you need to indicate all the hops, whereas in storing only the final= destinations need to be encoded. As an alternative, one could imagine tha the bits are allocated by RPL. In = that case, a NS-DAO-ACK could carry a bit associated with the target-transi= t relationship in the DAO. 3) in section 6.1.1 " The 6LR maintains a binding cache entry (BCE) for the 6LN based on successful DAC messages. With this specification, the 6LR also stores the matching between the address and the bitString and uses it for searching its children when forwarding packets in non-storing mode (see Section 6.1.3). " Which information will each entry hold? matching IPv6 address -Group ID/bit string which bit string is an aggregati= on of bit strings of node's children or matching IPv6 address -Group ID/bit= position bit position is the bitstring assigned to each address from root = node [Pascal] The latter if I understand ou well. The text means to say that the= parent maintains the bit for the child in the BCE. This is enough for NS m= ode. In storing it needs a routing table with per child the bitstrings avai= lable via the child. 4) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " If i understand correct,1 DAO message MAY contain more than 1 BIO. Parent node generate BIO by aggregate child bitstring with its own per grou= p,so parents and child may belong to different groups? [Pascal] I expect one BIO per group, that is correct. 5) in section 6.1.3 " Forwarding is based on matching a bitString in a packet with those of children. For unicast packets, only one matching child gets the packet. For multicast packets, all matching children get a copy. Matches are found by scanning all children and performing bitwise operations as follows. " The binding cache entry is updated with each successful Duplicate address c= onfirmation(DAC) which are being exchanged during duplicate address detecti= on(DAD) to assign unique address to each node. If i understand correct DAD happens in neighbor discovery phase before pare= nt selection so entries the node maintain may not belong to its child or it= s child may not be included in these entries. Or each node holds every neighbor's bit string in the binding cache entry? [Pascal]=20 [Pascal] An expectation is that a child uses its parents as 6LR and maintai= ns a BCE in each of them through NS(EARO). This is already true in RPL. 6) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " In storing mode,DAO messages are send to parent,what's the point for parent= to aggregate bitstring of its child? [Pascal]=20 [Pascal] The parent aggregates the bitmaps to send only one BIO representin= g self and all its children (more if multiple groups)/ 7) section 6.1.4 Reliable Multicast based on Bit-by-bit BitStrings describes h= ow multicast canbe achieved in storing and non-storing mode, could you show= me an example of it? [Pascal] Should be there https://datatracker.ietf.org/doc/slides-99-roll-ie= tf99-roll-slides-04/00/ but I can not seem to reach it. I'll unicast to you= . Cheers, Pascal draft-thubert-roll-bier-00 https://tools.ietf.org/pdf/draft-thubert-roll-bier-00.pdf Thank you, Chenyang ji _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Fri Dec 8 07:23:27 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F96127005 for ; Fri, 8 Dec 2017 07:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1cn8D-to3KL for ; Fri, 8 Dec 2017 07:23:21 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA68D12704B for ; Fri, 8 Dec 2017 07:23:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 82C248200B for ; Fri, 8 Dec 2017 16:23:15 +0100 (CET) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id J_PY6CR7uK6j for ; Fri, 8 Dec 2017 16:23:13 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 09C4F808F4 for ; Fri, 8 Dec 2017 16:23:13 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 09C4F808F4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.net; s=6A0CDB44-C782-11E6-82EC-91BDBA474D24; t=1512746593; bh=Yzp7N9KnDIFw/MR0DCwCvzmPQXbwkODsQsyaxQGNXIM=; h=Date:From:To:Message-ID:MIME-Version; b=iwOB49THvxV85tAl5Zf7W4cfhBJudg3NmAyiWTEnABXvfXlyIX2dGAu/sPRujZLrg Kr3EjAnSxh/PF6LMLKlDNgqAP3J/xR5bzpQk3CUCwM1km1AKNyugRc93No5C84EJfw LzyNP28ZYTWVilcT9b1D+JXrgaBACthXn5unTmRk= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id RupCX3z1X8ZN for ; Fri, 8 Dec 2017 16:23:12 +0100 (CET) Received: from zmail131.enst.fr (zmail131.enst.fr [137.194.2.203]) by zproxy120.enst.fr (Postfix) with ESMTP id C485581C85 for ; Fri, 8 Dec 2017 16:23:12 +0100 (CET) Date: Fri, 8 Dec 2017 16:23:12 +0100 (CET) From: Chenyang JI To: roll Message-ID: <1688746662.15845335.1512746592588.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: References: <376455077.14923086.1512557058890.JavaMail.zimbra@imt-atlantique.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:660:7301:51:7877:3d2f:7cc7:c0a3] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF56 (Linux)/8.7.11_GA_1854) Thread-Topic: RPL-BIER question Thread-Index: AdNwLYk9AjpTKp6xT+OAgTKYgo8iBFqF2Cl7 Archived-At: Subject: Re: [Roll] RPL-BIER question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:23:25 -0000 Hello, Thank you for the answer. I think i found the examples you mentioned https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99-roll-slides-04-00.pdf Regards, Chenyang ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "roll" Sent: Friday, December 8, 2017 3:06:17 PM Subject: Re: [Roll] RPL-BIER question Hello Chenyang Thanks for your uinterest! Please see below: 1) in section 6.1.1 " Several methods may be used to associate a bit in a biString to an IPv6 address. In order to guarantee interoperability, this specification RECOMMENDS that all implementations provide at least the method described therein. " in the last sentence,the word 'methods' refers methods to associate bit to an address? in the last sentence,where does the word 'therein' refers to? [Pascal] It refers to the current section; that section suggests that the 6LBR allocates it and returns it in the DAC. Note that this is for storing mode. 2) in section 6.1 " In the bit-by-bit case, each bit is mapped in an unequivocal fashion with a single addressable resource in the network. In RPL-BIER storing mode, this is an IPv6 address as advertised in RPL storing mode DAO messages, whereas in RPL-BIER non-storing mode, this is a parent-child relationship as advertised in RPL non-storing mode DAO messages. " how can a parent-child relationship be mapped? [Pascal] That would be by setting the bit associated to the child. In non-storing you need to indicate all the hops, whereas in storing only the final destinations need to be encoded. As an alternative, one could imagine tha the bits are allocated by RPL. In that case, a NS-DAO-ACK could carry a bit associated with the target-transit relationship in the DAO. 3) in section 6.1.1 " The 6LR maintains a binding cache entry (BCE) for the 6LN based on successful DAC messages. With this specification, the 6LR also stores the matching between the address and the bitString and uses it for searching its children when forwarding packets in non-storing mode (see Section 6.1.3). " Which information will each entry hold? matching IPv6 address -Group ID/bit string which bit string is an aggregation of bit strings of node's children or matching IPv6 address -Group ID/bit position bit position is the bitstring assigned to each address from root node [Pascal] The latter if I understand ou well. The text means to say that the parent maintains the bit for the child in the BCE. This is enough for NS mode. In storing it needs a routing table with per child the bitstrings available via the child. 4) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " If i understand correct,1 DAO message MAY contain more than 1 BIO. Parent node generate BIO by aggregate child bitstring with its own per group,so parents and child may belong to different groups? [Pascal] I expect one BIO per group, that is correct. 5) in section 6.1.3 " Forwarding is based on matching a bitString in a packet with those of children. For unicast packets, only one matching child gets the packet. For multicast packets, all matching children get a copy. Matches are found by scanning all children and performing bitwise operations as follows. " The binding cache entry is updated with each successful Duplicate address confirmation(DAC) which are being exchanged during duplicate address detection(DAD) to assign unique address to each node. If i understand correct DAD happens in neighbor discovery phase before parent selection so entries the node maintain may not belong to its child or its child may not be included in these entries. Or each node holds every neighbor's bit string in the binding cache entry? [Pascal] [Pascal] An expectation is that a child uses its parents as 6LR and maintains a BCE in each of them through NS(EARO). This is already true in RPL. 6) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " In storing mode,DAO messages are send to parent,what's the point for parent to aggregate bitstring of its child? [Pascal] [Pascal] The parent aggregates the bitmaps to send only one BIO representing self and all its children (more if multiple groups)/ 7) section 6.1.4 Reliable Multicast based on Bit-by-bit BitStrings describes how multicast canbe achieved in storing and non-storing mode, could you show me an example of it? [Pascal] Should be there https://datatracker.ietf.org/doc/slides-99-roll-ietf99-roll-slides-04/00/ but I can not seem to reach it. I'll unicast to you. Cheers, Pascal draft-thubert-roll-bier-00 https://tools.ietf.org/pdf/draft-thubert-roll-bier-00.pdf Thank you, Chenyang ji _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Fri Dec 8 07:28:37 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913FF1200C1 for ; Fri, 8 Dec 2017 07:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5DSQIGaQuZL for ; Fri, 8 Dec 2017 07:28:34 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887A1126C25 for ; Fri, 8 Dec 2017 07:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6658; q=dns/txt; s=iport; t=1512746914; x=1513956514; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Rxo2wEf0LpAtyI5Jwctb5fMuIKtl/cv+mM8jvGELGNw=; b=gaZxt2UiHaWKz+dxHF/VDdbDOJ4XakVPi9Mu8a0fyN2Qt7kSOAoXehGL tjG7qxjTR1LiYB75tu4bUW2xMXxhvKnTq2qAzkj6bAsC+4dEGWekvpt2B +BmBXRyyhK+XYanVP/YmKGojQ+6L/kmnbzeI53RTLRt3L9ScrtYqMddPD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DZBwBOripa/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0JweOHI5iAR2BfX5clTKCFQoYDYUWAoUfPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAQECAQFsBBMEAgEIEQQBASgHJwsUCQgBAQQTCIogEKooimMBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYNbgWEBKYFWgWmBG4FaNoMyh2UFikyIDIZ?= =?us-ascii?q?viUECh3eDcIkugh+BfYQVizmNCIknAhEZAYE6AR85gU9vFTqCGQEPglIcgWd4A?= =?us-ascii?q?YkggRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,378,1508803200"; d="scan'208";a="330072118" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 15:28:33 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB8FSXfj030654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Dec 2017 15:28:33 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 09:28:32 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Fri, 8 Dec 2017 09:28:32 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL-BIER question Thread-Index: AdNwLYk9AjpTKp6xT+OAgTKYgo8iBFqF2Cl7WoL+5xA= Date: Fri, 8 Dec 2017 15:28:16 +0000 Deferred-Delivery: Fri, 8 Dec 2017 15:27:44 +0000 Message-ID: <8f9e69eacdcd47aca9682f0a4ccc6027@XCH-RCD-001.cisco.com> References: <376455077.14923086.1512557058890.JavaMail.zimbra@imt-atlantique.net> <1688746662.15845335.1512746592588.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: <1688746662.15845335.1512746592588.JavaMail.zimbra@imt-atlantique.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] RPL-BIER question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:28:37 -0000 You did :) -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Chenyang JI Sent: vendredi 8 d=E9cembre 2017 16:23 To: roll Subject: Re: [Roll] RPL-BIER question Hello, Thank you for the answer. I think i found the examples you mentioned=20 https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99-roll-slide= s-04-00.pdf =20 Regards, Chenyang ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "roll" Sent: Friday, December 8, 2017 3:06:17 PM Subject: Re: [Roll] RPL-BIER question Hello Chenyang Thanks for your uinterest! Please see below: 1) in section 6.1.1 " Several methods may be used to associate a bit in a biString to an IPv6 address. In order to guarantee interoperability, this specification RECOMMENDS that all implementations provide at least the method described therein. " in the last sentence,the word 'methods' refers methods to associate bit to = an address? in the last sentence,where does the word 'therein' refers to? [Pascal] It refers to the current section; that section suggests that the 6= LBR allocates it and returns it in the DAC. Note that this is for storing m= ode. 2) in section 6.1 " In the bit-by-bit case, each bit is mapped in an unequivocal fashion with a single addressable resource in the network. In RPL-BIER storing mode, this is an IPv6 address as advertised in RPL storing mode DAO messages, whereas in RPL-BIER non-storing mode, this is a parent-child relationship as advertised in RPL non-storing mode DAO messages. =20 " how can a parent-child relationship be mapped? [Pascal] That would be by setting the bit associated to the child. In non-s= toring you need to indicate all the hops, whereas in storing only the final= destinations need to be encoded. As an alternative, one could imagine tha the bits are allocated by RPL. In = that case, a NS-DAO-ACK could carry a bit associated with the target-transi= t relationship in the DAO. 3) in section 6.1.1 " The 6LR maintains a binding cache entry (BCE) for the 6LN based on successful DAC messages. With this specification, the 6LR also stores the matching between the address and the bitString and uses it for searching its children when forwarding packets in non-storing mode (see Section 6.1.3). " Which information will each entry hold? matching IPv6 address -Group ID/bit string which bit string is an aggregati= on of bit strings of node's children or matching IPv6 address -Group ID/bit= position bit position is the bitstring assigned to each address from root = node [Pascal] The latter if I understand ou well. The text means to say that the= parent maintains the bit for the child in the BCE. This is enough for NS m= ode. In storing it needs a routing table with per child the bitstrings avai= lable via the child. 4) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " If i understand correct,1 DAO message MAY contain more than 1 BIO. Parent node generate BIO by aggregate child bitstring with its own per grou= p,so parents and child may belong to different groups? [Pascal] I expect one BIO per group, that is correct. 5) in section 6.1.3 " Forwarding is based on matching a bitString in a packet with those of children. For unicast packets, only one matching child gets the packet. For multicast packets, all matching children get a copy. Matches are found by scanning all children and performing bitwise operations as follows. " The binding cache entry is updated with each successful Duplicate address c= onfirmation(DAC) which are being exchanged during duplicate address detecti= on(DAD) to assign unique address to each node. If i understand correct DAD happens in neighbor discovery phase before pare= nt selection so entries the node maintain may not belong to its child or it= s child may not be included in these entries. Or each node holds every neighbor's bit string in the binding cache entry? [Pascal]=20 [Pascal] An expectation is that a child uses its parents as 6LR and maintai= ns a BCE in each of them through NS(EARO). This is already true in RPL. 6) in section 6.1.2 " In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode [RFC6550]. The BitString Information option (Figure 1) is used in replacement of the Target option. A DAO message contains one BIO per group, and the parent that receives the messages associates the BIO information to the advertising child. In order to build a DAO message, the parent regenerates its own BIO, one per group, by aggregating the bitStrings from all of its children with its own, and places the resulting BIOs in the DAO message. " In storing mode,DAO messages are send to parent,what's the point for parent= to aggregate bitstring of its child? [Pascal]=20 [Pascal] The parent aggregates the bitmaps to send only one BIO representin= g self and all its children (more if multiple groups)/ 7) section 6.1.4 Reliable Multicast based on Bit-by-bit BitStrings describes h= ow multicast canbe achieved in storing and non-storing mode, could you show= me an example of it? [Pascal] Should be there https://datatracker.ietf.org/doc/slides-99-roll-ie= tf99-roll-slides-04/00/ but I can not seem to reach it. I'll unicast to you= . Cheers, Pascal draft-thubert-roll-bier-00 https://tools.ietf.org/pdf/draft-thubert-roll-bier-00.pdf Thank you, Chenyang ji _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Wed Dec 13 10:28:37 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052D6128BBB; Wed, 13 Dec 2017 10:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTos40kkIuph; Wed, 13 Dec 2017 10:28:19 -0800 (PST) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC2D128CF0; Wed, 13 Dec 2017 10:28:14 -0800 (PST) Received: by mail-ot0-x241.google.com with SMTP id v21so2782721oth.6; Wed, 13 Dec 2017 10:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=V0P8bQ5WjlFKq22SfkAH5yNC6yEfHw1X8LgprwMsZ2g=; b=hrvq7nJNe9visoVaPeHDv+2SNlyqb6+O2xkmsV7MIuDm1XlAGibQu8nNWTzllCY6sY pTM28F0mlbhR8xmR+icnHjhEBlgRpVSNd0QPo82rMzQB8ESKMZM9z0wVG+PhTA0yVU+A nTWWc1Cx75S4xPwOgwj9pcszvJsKh8WsfKBk45JqBQ8/SXB9LDsXjFg81sTlxXxPqEYH 9l+nxBq3QqlWxGPwYsrYfkJBonudNWJl1SgpzzJA4RQtOCWx900w3bbVu384HnsQjRXv 0K+zAF+xviCZT3wjOhVbVcyjDnBXdGCCHd+UCr7PCbXZw/0KF1wuYjOSgScHYH2spuuJ sKFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=V0P8bQ5WjlFKq22SfkAH5yNC6yEfHw1X8LgprwMsZ2g=; b=F1Ae+letdSGlC3r6FlcfZbkI5HXZZdkE7KBB2kNXpWVqdLTVnstCewQZvl0/qSoBBV PmrJlMne5D6n1HLK1ZcID8Kfq+xR2AKeE5o1wKDNk6vEDZt5NIZ/HvP+sU2YsdL0reag NrF2dAVjpa0OQVGM2tlePIHuPO+XWg4Rk3ggJrwZzVOHgwp49Snz8GGdYvV+KPh1BDER G8ODjtGi8K5YNT9pnGoOiwgp3YXP6jt+2MZcluzryaJMjpvVlkJGWty5epuEwkZD53hN q3iMALVrGGLLpdbDK0A0ELJrqMvUyrGIPgUM92yZV8ElOCTgDtXRAtYLCDnW1WhmC5yq Mvdg== X-Gm-Message-State: AKGB3mJAM0iAVMwILtMPD1Jm5vmcUPp4ZiR3TtF1hdcMukQ4L4bI2Hxr wmQ50GJni7vE8T7xdtX199z/LpEg8o6L6sKkLYo= X-Google-Smtp-Source: ACJfBovGHVdc8/6X0fnI74c1ciMkVTyqpvdNSvxZ6MR1Txum7yQsf8uW+TaYbExwJwcD3G+hHbpJSWI7VqbrnhuCi4M= X-Received: by 10.157.56.200 with SMTP id k8mr2572828ote.3.1513189693841; Wed, 13 Dec 2017 10:28:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Dec 2017 13:28:13 -0500 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 13 Dec 2017 13:28:13 -0500 Message-ID: To: dcrouting@ietf.org, routing-discussion@ietf.org Cc: roll@ietf.org, rtg-dir@ietf.org, ospf@ietf.org, isis-wg@ietf.org, babel@ietf.org, manet@ietf.org Content-Type: multipart/alternative; boundary="001a11c01f182de59c05603cee49" Archived-At: Subject: Re: [Roll] dcrouting BOF in Singapore (Mailing LIsts) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 18:28:22 -0000 --001a11c01f182de59c05603cee49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Adding routing-discussion, other IGP-focused WGs and rtg-dir, please feel free to forward.] Hi! As we move these efforts forward, we have now created two new mailing lists= : Routing In Fat Trees (rift): https://www.ietf.org/mailman/admin/rift Link State Vector Routing (lsvr): https://www.ietf.org/mailman/admin/lsvr If you are interested in either effort (or both!), please subscribe!! The next step is to discuss and agree on a suitable charter for each of the proposed WGs =E2=80=94 I have asked the proponents to start a discussion on= the respective lists in the next few days. The goal is to take the Charters to the IESG and have them approved significantly in advance of IETF 101. As a reminder, the focus of these efforts (resulting from the dcrouting BOF) is on new solutions: ones that require a standalone effort (WG) =E2=80= =93 It is not expected that work/discussions on related incremental enhancements in an existing WG be delayed or deferred. Thanks! Alvaro. On November 23, 2017 at 4:17:26 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote: Hi! Thank you to everyone who participated in last week=E2=80=99s BOF!! After comparing notes with the BOF Chairs and my co-ADs, we believe there is good interest to start working on proposed charters for both RIFT and BGP-LS SPF. I will be working with the proponents on that in the next few weeks =E2=80=94 the current plan is for me to be the Responsible AD for bot= h of these efforts. Please stay tuned to this mailing list for further announcements on mailing lists and other details as we iron them out. Thanks!! Alvaro. --001a11c01f182de59c05603cee49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Adding routing-discussion, other IGP-focused WGs and rtg-dir, please feel free to forward.]


Hi!

As we move these efforts forward, we have now created two new mailing lists:

Routing In Fat Trees (rift):=C2=A0https://www.ietf.org/mailman/admin/rift=C2=A0
Link State Vector Routing (lsvr):=C2=A0https://www.ietf.org/mailman/admin/lsvr=C2=A0

If you are interested in either effort (or both!), please subscribe!!

The next step is to discuss and agree on a suitable charter for each of the proposed WGs =E2=80=94 I have asked the proponents to start a discussion on the respective lists in the next few days.=C2=A0 The goal is to take the Charters to the IESG and have them approved significantly in advance of IETF 101.

As a reminder, the focus of these efforts (resulting from the dcrouting BOF) is on new solutions: ones that require a standalone effort (WG) =E2=80=93 It is not expected that work/discussions on related incremental enhancements in an existing WG be delayed or deferred.

Thanks!

Alvaro.


On November 23, 2017 at 4:17:26 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

Hi!

Thank you to everyone who participated in last week=E2=80=99s BOF!!

After comparing notes with the BOF Chairs and my co-ADs, we believe there is good interest to start working on proposed charters for both RIFT and BGP-LS SPF.=C2=A0 I will be working with the proponents on that in the next few weeks =E2=80=94 the current plan is for me to be the Responsible AD for both of these efforts.

Please stay tuned to this mailing list for further announcements on mailing lists and other details as we iron them out.

Thanks!!

Alvaro.
--001a11c01f182de59c05603cee49-- From nobody Wed Dec 13 10:38:31 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301B212714F; Wed, 13 Dec 2017 10:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRSrEqhut57o; Wed, 13 Dec 2017 10:38:05 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B283124D6C; Wed, 13 Dec 2017 10:38:05 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id j2so2784287ota.13; Wed, 13 Dec 2017 10:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=h4/MaJNvomeevDTG3p2QGnvNfz5lYyi8YqsJZXJN6fg=; b=kmJNkvfqMG7zHI5j8Dy7ulTiLzIxxmOiOQ2UMhuqiiIo3VvZJWsHPa/+FsOC07OQpl +SvRRMbFFH1mr5TxBSoL0Xx/7SA4wmDEBVib4xa6CiswMEQDIw0HGUpO/gbOJQ5Nf+m2 z1zzUM5fTh5dxgmXa3ZAt57dVw5N+Bg8fcXdLjarSuV0Dy/iSq50tWLHhDs1KEzym1RI qh3o6G9/8+7ZBsssG1XoLcE6TQFUfxB5MemwOEvLuPkN1NEzADUX7nzPF5QCaOhUo7ot qN0HmLRk1KrQGew9VRj54k8yD+EhPSKifSsTg+fJjvKGaLhGj/Aq2ynDTJR77Sic3rPX 2RCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=h4/MaJNvomeevDTG3p2QGnvNfz5lYyi8YqsJZXJN6fg=; b=KFRtxM977g4zWdFxPNHs8ZmOH0GwNWJCGaRfLWi4XhwoalOGuNDF0QOxY7rgblOPHX Nodftw5aFWj0T9JJZyKlmkgkY6KRqDnTzelNdaaOW976HQrt9NDE4IusqGArU4Hm6+QO WBOVC1qvaYoLqfQj8wc3s6AdPce+XenlcmHdbaF7q2ltu1NeauUXMQn+8s6p5MK5ZTzH mq2M4z1RVi2xcUa5QcXFjuFY8nco6C2ODTPMWtLKMqxgc/H0piE+G44jCVym97h2tBZW pu81R3hrQ9KRMXAE6FF/tpyQPnk0rs5seg6HSTi873z827Gcuo491kmYL+AG/cKQI7Ci 2/Iw== X-Gm-Message-State: AKGB3mKZ6D7X9RkC5LPYDMVhTb/h3UEhys+Wao+hMAHkmTuhfz5Al2wg 0t1TZ4nH0EwWQAT/U3GR1mamrl29Ko/Fhd3B0AM= X-Google-Smtp-Source: ACJfBotpLlXPuBOGfX0NjCGgKZu8AlVokF1wzRavzTLXSYY6z+rI3XPTt2/6xhTMUQumWUO9ujKSoDeh/EfqRSj31M8= X-Received: by 10.157.56.200 with SMTP id k8mr2593526ote.3.1513190284506; Wed, 13 Dec 2017 10:38:04 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Dec 2017 13:38:04 -0500 From: Alvaro Retana In-Reply-To: References: X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 13 Dec 2017 13:38:04 -0500 Message-ID: To: dcrouting@ietf.org, routing-discussion@ietf.org Cc: babel@ietf.org, manet@ietf.org, ospf@ietf.org, roll@ietf.org, rtg-dir@ietf.org, isis-wg@ietf.org Content-Type: multipart/alternative; boundary="001a11c01f1862b98605603d1194" Archived-At: Subject: Re: [Roll] dcrouting BOF in Singapore (Mailing LIsts) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 18:38:08 -0000 --001a11c01f1862b98605603d1194 Content-Type: text/plain; charset="UTF-8" Sorry, here are the right links: rift: https://www.ietf.org/mailman/listinfo/rift lsvr: https://www.ietf.org/mailman/listinfo/lsvr Thanks to the eager people already subscribing for pointing this out! Alvaro. On December 13, 2017 at 10:28:13 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote: Routing In Fat Trees (rift): https://www.ietf.org/mailman/admin/rift Link State Vector Routing (lsvr): https://www.ietf.org/mailman/admin/lsvr --001a11c01f1862b98605603d1194 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Sorry, here are the right links:

lsvr:=C2=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/lsvr">https://www.ietf.org/= mailman/listinfo/lsvr=C2=A0

Thanks to the eager people already subscribing for pointing this= out!=C2=A0
<= br>
Alvaro.

On December 13, 2017 at 10:28:13 AM, Alvar= o Retana (aretana.ietf@gmail.com<= /a>) wrote:

Link State Vector Routing (lsvr):=C2=A0https://www.ietf.org/mailman/a= dmin/lsvr=C2=A0

--001a11c01f1862b98605603d1194-- From nobody Fri Dec 15 07:19:24 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4A128D3E for ; Fri, 15 Dec 2017 07:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM03TzMW8EOn for ; Fri, 15 Dec 2017 07:19:20 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F92B128B93 for ; Fri, 15 Dec 2017 07:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1513351157; bh=iZdi/WBEGaScBmO4p/cWnBNdfcAz+mhDN4v4 YEaNdnY=; h=Received:Subject:To:References:From:Cc:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=IPz7atxn23QkvxrV0xC6rOJ0Fy7DX4R4Y 4ng4yimGLf3LGff+ScKqCdJjuzoRoPG/os1Za1lF6o+Gg4Xo2b86x+pSQ+7hQxv/CGX gA3UyjEUFL4dZXqBybEAQWo01gUBy44ScqO6P43O3U3Qw3Ansx+ykRcUc1BgbmMKkiK rr/6rDIadkb4AsBh8Ra8AbHsieb+kzzc1sxpPzneKfJSdN2uvBmYCiz8HdxcJMsFVlk 3sw0HF47xn42OpJXWwjJbY/mkuqh6QnpMirngvtULWGpFznyOJ+a37IudjIXVM3rWMY NwRmfKe4cozE57UAa1BtI8CbuflG9/rFPhDnw72Pg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=mB+TvcRbSmACWocNYABNOwO9pQl1Rz6pv/X3wC0O3G47f06HC8vIJyKIoqD7iUuF2SaAt/UaAGm1kUzrT4MdPYVs+eqeZQ6fL6jFg7HfyLZakjcoCS6ZdvmG9KFfR/BTIoDnaj3S25BXmJM+fN9dddYDC6FV6Dt3y3qCwAHcaECueP7M79D6XCdR2tK2ZpY6ejU/OeBx+UETIZlrfRIZh4rH0B6cuQ8DSUxl1uRmFItYh4/R658a+TQm+6E/xmUqBls7N2Lh6QWy0NtSD+efnb1plnPihRjDUpDGGINnR2UoCwA/ylaIpaazb6odfHsHkxABD1hEPyAFSsS45xf10A==; h=Received:Subject:To:References:From:Cc:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1ePrlb-0005c0-IA; Fri, 15 Dec 2017 10:19:15 -0500 To: Rahul Jadhav References: From: Charlie Perkins Cc: Routing Over Low power and Lossy networks Message-ID: <363f0dc1-e40d-0a79-80af-1ed4a64bd817@earthlink.net> Date: Fri, 15 Dec 2017 07:19:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C0B3715A40B5E062AFBF3886" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95276be550561ef4f525d283444294d1c9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 15:19:23 -0000 This is a multi-part message in MIME format. --------------C0B3715A40B5E062AFBF3886 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Rahul, Thanks for the review!  It is much appreciated.  I have some follow-up below. On 11/15/2017 8:57 PM, Rahul Jadhav wrote: > > Following is my review of AODV-RPL. > > One of the stated goal of AODV-RPL is to cater to asymmetric links. > While this is really great to have, I have doubts that the current > specification achieves it in a practical way. Foll is the reasoning: > > 1. The Messaging: > > AODV-RPL requires that you send a multicast message from OrigNode > to TargNode and realise a routing path in the opposite direction. > > For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards > D and nodes B,C,D establish routing adjacencies in the opposite > direction. This kind of messaging is the reason why RPL depends on > bidirectional links for control/data paths. > It's not just RPL.  A lot of protocols work this way. > 2. The Assumptions: > > a. Quoting draft, > > “Each intermediate node R_i computes the rank for > RREQ-Instance and creates a routing table entry for the > upstream route towards thesource if the routing > metrics/constraints are satisfied.For this purpose R_i ***must > use the asymmetric link metric measured in the upstream > direction***, from R_i to its upstream neighbor that > multicasted the RREQ-Instance message.” > > This is the primary assumption which achieves asymmetric > behaviour. But it’s an implementation nightmare to do this > measurement especially because we do not know which neighbour we > might end up tieing up with (thus need to probe all neighbours). > I don't think this is true.  A node simply has to keep track of the information for the upstream destination, and the information about the specific node from which the RREQ was received. > It will add up so much to the control overhead and also requires > (a good deal of) state info to be maintained on behalf of the > neighbouring nodes. > I don't see why it adds much to the control overhead.  The state can be timed out after a relatively small duration of time.  We will add that timeout parameter for the next revision. > Anyways i tried to search for your implementation to check on this > but i could not find it. > > b. Use of past conditions to suggest future traffic path selection: > > “If the RREQ-Instance arrives over an interface that is not > known tobe symmetric, or is known to be asymmetric, the 'S' > bit is set to be 0.” > > This is a typical problem we face as well. Probing for > measurements at such scale (all neighbours) is a problem. If you > do the probing sparsely, the network conditions might have changed > when you want to use the measurements. > Yes, this is naturally a problem in dynamic networks.  We can't predict the future, so we are stuck with recording salient aspects of the past.  No matter how often we measure, it is guaranteed to be wrong some (or most!) of the time in the future.  And yet we persist. But we do not require periodic or exhaustive measurements for all neighbors -- only as needed for the protocol to work. > Other points: > > 1. Use of odd/even numbers for pairing instances may not be a robust > way of pairing … There could be race conditions where other > P2P-RPL instances or floating DODAG instances end up using one of > the same value in the instance-id pair. How to resolve such collision? > But, the instance-ids are local.  So if two different nodes use the same ID that is O.K.  If those two nodes need to have a peer-to-peer route to the same destination, that is still O.K., but the RREP sent back to one of the source nodes will be able to use the paired instance-ID and the streamlined RREP, and the other RREP will have to include an unpaired instance-ID along with the IPv6 address of the target node.  That will be a rare occurrence, and so the optimization of eliding the IPv6 address  will usually be possible. > 1. I would recommend to use Cooja with links in DGRM mode to evaluate > the perf. > This sounds like a good idea.  The other co-authors will probably have more follow-up about this. > 1. The RSSI values in the Appendix do not look correct. An RSSI of > <-70dbm is too good [1] to have for good PDR. The mapping of > RSSI-ETX in the appendix hence may not be correct (i believe these > values are from Cooja). > I don't understand how an RSSI could be "too good", unless you mean that the power level is too high and causes widespread interference.  Admittedly, I am no expert in interpreting PHY layer effects, but anyway usually higher received power allows more accurate detection, if the background noise level remains the same. > > [1]RSSI is Under-Appreciated > https://sing.stanford.edu/site/publications/emnets2006srinivasan.pdf > Thanks for the link.  I read through it very briefly on this fine morning.  However, I have also read other papers that seriously question the value of relying on RSSI.  I'll try to remember and find one for further discussion.  Notably, the authors seem to focus on particular hardware, and a single link between two neighbors, for their discussion, unless I missed something. Regards, Charlie P. --------------C0B3715A40B5E062AFBF3886 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Rahul,

Thanks for the review!  It is much appreciated.  I have some follow-up below.


On 11/15/2017 8:57 PM, Rahul Jadhav wrote:

Following is my review of AODV-RPL.

One of the stated goal of AODV-RPL is to cater to asymmetric links. While this is really great to have, I have doubts that the current specification achieves it in a practical way. Foll is the reasoning:

  1. The Messaging:

AODV-RPL requires that you send a multicast message from OrigNode to TargNode and realise a routing path in the opposite direction. 

For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and nodes B,C,D establish routing adjacencies in the opposite direction. This kind of messaging is the reason why RPL depends on bidirectional links for control/data paths.


It's not just RPL.  A lot of protocols work this way.

2. The Assumptions:

a. Quoting draft, 

“Each intermediate node R_i computes the rank for RREQ-Instance and creates a routing table entry for the upstream route towards the source if the routing metrics/constraints are satisfied.  For this purpose R_i ***must use the asymmetric link metric measured in the upstream direction***, from R_i to its upstream neighbor that multicasted the RREQ-Instance message.”

This is the primary assumption which achieves asymmetric behaviour. But it’s an implementation nightmare to do this measurement especially because we do not know which neighbour we might end up tieing up with (thus need to probe all neighbours).


I don't think this is true.  A node simply has to keep track of the information for the upstream destination, and the information about the specific node from which the RREQ was received.

It will add up so much to the control overhead and also requires (a good deal of) state info to be maintained on behalf of the neighbouring nodes.


I don't see why it adds much to the control overhead.  The state can be timed out after a relatively small duration of time.  We will add that timeout parameter for the next revision.


Anyways i tried to search for your implementation to check on this but i could not find it.

b. Use of past conditions to suggest future traffic path selection:

“If the RREQ-Instance arrives over an interface that is not known to be symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.”

This is a typical problem we face as well. Probing for measurements at such scale (all neighbours) is a problem. If you do the probing sparsely, the network conditions might have changed when you want to use the measurements.


Yes, this is naturally a problem in dynamic networks.  We can't predict the future, so we are stuck with recording salient aspects of the past.  No matter how often we measure, it is guaranteed to be wrong some (or most!) of the time in the future.  And yet we persist.

But we do not require periodic or exhaustive measurements for all neighbors -- only as needed for the protocol to work.


Other points:

  1. Use of odd/even numbers for pairing instances may not be a robust way of pairing … There could be race conditions where other P2P-RPL instances or floating DODAG instances end up using one of the same value in the instance-id pair. How to resolve such collision?

But, the instance-ids are local.  So if two different nodes use the same ID that is O.K.  If those two nodes need to have a peer-to-peer route to the same destination, that is still O.K., but the RREP sent back to one of the source nodes will be able to use the paired instance-ID and the streamlined RREP, and the other RREP will have to include an unpaired instance-ID along with the IPv6 address of the target node.  That will be a rare occurrence, and so the optimization of eliding the IPv6 address  will usually be possible.

  1. I would recommend to use Cooja with links in DGRM mode to evaluate the perf.

This sounds like a good idea.  The other co-authors will probably have more follow-up about this.

  1. The RSSI values in the Appendix do not look correct. An RSSI of <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX in the appendix hence may not be correct (i believe these values are from Cooja).

I don't understand how an RSSI could be "too good", unless you mean that the power level is too high and causes widespread interference.  Admittedly, I am no expert in interpreting PHY layer effects, but anyway usually higher received power allows more accurate detection, if the background noise level remains the same.



Thanks for the link.  I read through it very briefly on this fine morning.  However, I have also read other papers that seriously question the value of relying on RSSI.  I'll try to remember and find one for further discussion.  Notably, the authors seem to focus on particular hardware, and a single link between two neighbors, for their discussion, unless I missed something.

Regards,
Charlie P.

--------------C0B3715A40B5E062AFBF3886-- From nobody Wed Dec 20 04:11:03 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB32B1275F4 for ; Wed, 20 Dec 2017 04:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz2ucoKYftCu for ; Wed, 20 Dec 2017 04:10:59 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC10E12741D for ; Wed, 20 Dec 2017 04:10:58 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id r78so9474406wme.5 for ; Wed, 20 Dec 2017 04:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rT3AgVAi6PATl6nRtFhYUc3kanKpvecoQaX048cEByw=; b=TOk5MwhFEwFc+h9jrda50nPx3c19vtWdo6w9MLCBAXtBic7H0LzegIgbnlXFQIFZUV /6ClQp7WXR88mtPl+3CRD/i+GhSGkpC58Vjjezp89BjBlmKgDQpgxNwfggROw6fFdoqV 68acw91SlmAK0gTaHi8+Y+5je6aU0UulHJ25iCX33X5+0ewaNMKEXTOE+/JHJz3xCXnt NDxNAlk9+G0R0xkgPHPOoLQmL0x/tYATTXtJL8SiUlGguOS5q8nXc9eG4jUjDiNwGRyI QXwI4O4GLpT6pUhLiIvJHNppiVeEbGYnfcf4WDfJTgL/IyVXDTdPdIhpnOx1W0SJEu5Z XQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rT3AgVAi6PATl6nRtFhYUc3kanKpvecoQaX048cEByw=; b=JfLjQwxhEk8UzDtyuoOoXYE7MfSn08ItrcHr4MuuppXgYpxkDxes5oHV6RoISW0Bjq LnHl6SNFSWjJ1fH07hD04RTKkdZiO0mtq2Xe/ffOxB51wsmLFeS4ZBnzSWnaOHGoy6EB TSGDBtv/iTqnNjW3wPaBEkfr35I1LLji2c+dF4UuCi5QqHvAQQ6Jiuhs8gHuEBCK5jlA KccrFgXCnqexHC3zTd3hZw4ALKjsH4SA/yInsNkDaoBdn/1qLtLYln8v1b8XbSHUn6vp fMvRX5KHbXhVADvs9D9OxDJT48psBrkFAzel0FwG2ZFnpe0oz9J9VITDuhCjkYPYEEsg xaiA== X-Gm-Message-State: AKGB3mKbs8FVJgzRZSTRW/VBVCCmCKbRZazaTTMovrd/SlQSBAwN3jWh EmH5d+0VodZ6xhHMlKC9pbN7jYuVSQDbxfKqKys= X-Google-Smtp-Source: ACJfBosF3xjCERTC4OoUCmr72wcZKG1fbb2lBEf27JitPH5yBpY35oevMPjrEFA6RAHJK8BeSoLKb2kJGCzuzWxgLnQ= X-Received: by 10.80.224.65 with SMTP id g1mr5261740edl.264.1513771856981; Wed, 20 Dec 2017 04:10:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.142.4 with HTTP; Wed, 20 Dec 2017 04:10:56 -0800 (PST) In-Reply-To: <363f0dc1-e40d-0a79-80af-1ed4a64bd817@earthlink.net> References: <363f0dc1-e40d-0a79-80af-1ed4a64bd817@earthlink.net> From: Rahul Jadhav Date: Wed, 20 Dec 2017 17:40:56 +0530 Message-ID: To: Charlie Perkins Cc: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="089e082209a0ce72f30560c4799f" Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 12:11:02 -0000 --089e082209a0ce72f30560c4799f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Charlie, Please find my response inline.. Regards, Rahul On 15 December 2017 at 20:49, Charlie Perkins wrote: > Hello Rahul, > > Thanks for the review! It is much appreciated. I have some follow-up > below. > > On 11/15/2017 8:57 PM, Rahul Jadhav wrote: > > Following is my review of AODV-RPL. > > One of the stated goal of AODV-RPL is to cater to asymmetric links. While > this is really great to have, I have doubts that the current specificatio= n > achieves it in a practical way. Foll is the reasoning: > > 1. The Messaging: > > AODV-RPL requires that you send a multicast message from OrigNode to > TargNode and realise a routing path in the opposite direction. > > For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and > nodes B,C,D establish routing adjacencies in the opposite direction. This > kind of messaging is the reason why RPL depends on bidirectional links fo= r > control/data paths. > > > It's not just RPL. A lot of protocols work this way. > [RJ] But this mode of signaling does not help satisfy the stated goal of establishing asymmetric links. RPL (and others like p2p-rpl) follows this mode of signaling and hence depend on bidirectional links. > 2. The Assumptions: > > a. Quoting draft, > > =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance a= nd > creates a routing table entry for the upstream route towards the source > if the routing metrics/constraints are satisfied. For this purpose R_i > ***must use the asymmetric link metric measured in the upstream > direction***, from R_i to its upstream neighbor that multicasted the > RREQ-Instance message.=E2=80=9D > > This is the primary assumption which achieves asymmetric behaviour. But > it=E2=80=99s an implementation nightmare to do this measurement especiall= y because > we do not know which neighbour we might end up tieing up with (thus need = to > probe all neighbours). > > > I don't think this is true. A node simply has to keep track of the > information for the upstream destination, and the information about the > specific node from which the RREQ was received. > [RJ] Assuming a moderately populated hop, a node now needs to keep track of information in context all the peers on the same hop. You mentioned, 'node needs to track only upstream destination' ... but imo this is not true. For P2P paths, its a different DAG instance and thus there are no pre-determined *upstream destinations*. > It will add up so much to the control overhead and also requires (a good > deal of) state info to be maintained on behalf of the neighbouring nodes. > > > I don't see why it adds much to the control overhead. The state can be > timed out after a relatively small duration of time. We will add that > timeout parameter for the next revision. > [RJ] The reason for high control overhead is that the node will have to keep probing the neighbors to maintain state. The problem with smaller duration time is that the probe will be more frequent! Regardless, the table that needs to be maintained for such information is directly proportional to the number of neighboring peers. > > > Anyways i tried to search for your implementation to check on this but i > could not find it. > > b. Use of past conditions to suggest future traffic path selection: > > =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known= to be > symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2= =80=9D > > This is a typical problem we face as well. Probing for measurements at > such scale (all neighbours) is a problem. If you do the probing sparsely, > the network conditions might have changed when you want to use the > measurements. > > > Yes, this is naturally a problem in dynamic networks. We can't predict > the future, so we are stuck with recording salient aspects of the past. = No > matter how often we measure, it is guaranteed to be wrong some (or most!) > of the time in the future. And yet we persist. > > But we do not require periodic or exhaustive measurements for all > neighbors -- only as needed for the protocol to work. > [RJ] May be this is the part i don't get ... You mentioned "only as needed for the protocol to work" ... Can this be elaborated? > > Other points: > > 1. Use of odd/even numbers for pairing instances may not be a robust > way of pairing =E2=80=A6 There could be race conditions where other P2= P-RPL > instances or floating DODAG instances end up using one of the same val= ue in > the instance-id pair. How to resolve such collision? > > > But, the instance-ids are local. So if two different nodes use the same > ID that is O.K. If those two nodes need to have a peer-to-peer route to > the same destination, that is still O.K., but the RREP sent back to one o= f > the source nodes will be able to use the paired instance-ID and the > streamlined RREP, and the other RREP will have to include an unpaired > instance-ID along with the IPv6 address of the target node. That will be= a > rare occurrence, and so the optimization of eliding the IPv6 address wil= l > usually be possible. > [RJ] Yeah, for local instances this might not be a problem. Thanks. > > > 1. I would recommend to use Cooja with links in DGRM mode to evaluate > the perf. > > > This sounds like a good idea. The other co-authors will probably have > more follow-up about this. > > > 1. The RSSI values in the Appendix do not look correct. An RSSI of > <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX = in > the appendix hence may not be correct (i believe these values are from > Cooja). > > > I don't understand how an RSSI could be "too good", unless you mean that > the power level is too high and causes widespread interference. > Admittedly, I am no expert in interpreting PHY layer effects, but anyway > usually higher received power allows more accurate detection, if the > background noise level remains the same. > [RJ] My reference here is to the RSSI to ETX mapping table in the draft. The values noted in that table do not look correct. For RSSI -55 to -45dbm, the expected ETX is 993. On what basis was this table generated ? Typically i have found that RSSI of < -80dbm results in very good PDRs (also the ref i attached says the same). > > > > [1] RSSI is Under-Appreciated https://sing.stanford.edu/site > /publications/emnets2006srinivasan.pdf > > > Thanks for the link. I read through it very briefly on this fine > morning. However, I have also read other papers that seriously question > the value of relying on RSSI. > I'll try to remember and find one for further discussion. Notably, the > authors seem to focus on particular hardware, and a single link between t= wo > neighbors, for their discussion, unless I missed something. > [RJ] The authors have not merely focused on single link between two neighbors. The slides of the paper-talk gives a better picture, https://sing.stanford.edu/site/talks/emnets2006srinivasan.ppt > > Regards, > Charlie P. > > --089e082209a0ce72f30560c4799f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Charlie,

Ple= ase find my response inline..

Regards,
Rahul

On 15 December 2017 at= 20:49, Charlie Perkins <charles.perkins@earthlink.net> wrote:
=20 =20 =20

Hello Rahul,

Thanks for the review!=C2=A0 It is much appreciated.=C2=A0 I have so= me follow-up below.


On 11/15/2017 8:57 PM, Rahul Jadhav wrote:

Following is my review of AODV-RPL.

One of the stated goal of AODV-RPL is to cater to asymmetric links. While this is really great to have, I have doubts that the current specification achieves it in a practical way. Foll is the reasoning:

  1. The Messaging:

AODV-RPL requires that you send a multicast message from OrigNode to TargNode and realise a routing path in the opposite direction.=C2=A0

For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and nodes B,C,D establish routing adjacencies in the opposite direction. This kind of messaging is the reason why RPL depends on bidirectional links for control/data paths.


 It's not just RPL.=C2=A0 A lot of protocols work this way.

[RJ] But this mode of signal= ing does not help satisfy the stated goal of establishing asymmetric links.= RPL (and others like p2p-rpl) follows this mode of signaling and hence dep= end on bidirectional links.


2. The Assumptions:

a. Quoting draft,=C2=A0

=E2=80=9CEach intermediate node R_i computes th= e rank for RREQ-Instance and creates a routing table entry for the upstream route towards the=C2=A0source if the routing metrics/constraints are satisfied.=C2=A0 For this purpose R_i ***must use the asymmetric link metric measured in the upstream direction***, from R_i to its upstream neighbor that multicasted the RREQ-Instance message.=E2=80=9D

This is the primary assumption which achieves asymmetric behaviour. But it=E2=80=99s an implementati= on nightmare to do this measurement especially because we do not know which neighbour we might end up tieing up with (thus need to probe all neighbours).


 I don't think this is true.=C2=A0 A node simply has to keep track o= f the information for the upstream destination, and the information about the specific node from which the RREQ was received.

[RJ] Assuming a moderately populated ho= p, a node now needs to keep track of information in context all the peers o= n the same hop. You mentioned, 'node needs to track only upstream desti= nation' ... but imo this is not true. For P2P paths, its a different DA= G instance and thus there are no pre-determined *upstream destinations*.


It will add up so much to the control overhead and also requires (a good deal of) state info to be maintained on behalf of the neighbouring nodes.


 I don't see why it adds much to the control overhead.=C2=A0 The sta= te can be timed out after a relatively small duration of time.=C2=A0 We will a= dd that timeout parameter for the next revision.

[RJ] The reason for high control overhead is = that the node will have to keep probing the neighbors to maintain state. Th= e problem with smaller duration time is that the probe will be more frequen= t! Regardless, the table that needs to be maintained for such information i= s directly proportional to the number of neighboring peers.
<= br>
=C2=A0


Anyways i tried to search for your implementation to check on this but i could not find it.

b. Use of past conditions to suggest future traffic path selection:

=E2=80=9CIf the RREQ-Instance arrives over an interface that is not known to=C2=A0be symmetric, or is known to be asymmetric, the 'S' bit = is set to be 0.=E2=80=9D

This is a typical problem we face as well. Probing for measurements at such scale (all neighbours) is a problem. If you do the probing sparsely, the network conditions might have changed when you want to use the measurements.


 Yes, this is naturally a problem in dynamic networks.=C2=A0 We can'= t predict the future, so we are stuck with recording salient aspects of the past.=C2=A0 No matter how often we measure, it is guaranteed to = be wrong some (or most!) of the time in the future.=C2=A0 And yet we persist.

But we do not require periodic or exhaustive measurements for all neighbors -- only as needed for the protocol to work.
<= /div>

[RJ] May be this is the part i don= 9;t get ... You mentioned "only as needed for the protocol to work&quo= t; ... Can this be elaborated?



Other points:

  1. Use of odd/even numbers for pairing instances may not be a robust way of pairing =E2=80=A6 There co= uld be race conditions where other P2P-RPL instances or floating DODAG instances end up using one of the same value in the instance-id pair. How to resolve such collision?

 But, the instance-ids are local.=C2=A0 So if two different nodes use th= e same ID that is O.K.=C2=A0 If those two nodes need to have a peer-to-pe= er route to the same destination, that is still O.K., but the RREP sent back to one of the source nodes will be able to use the paired instance-ID and the streamlined RREP, and the other RREP will have to include an unpaired instance-ID along with the IPv6 address of the target node.=C2=A0 That will be a rare occurrence, and so the optimization of eliding the IPv6 address=C2=A0 will usually be possible= .

[RJ] Yeah, for loc= al instances this might not be a problem. Thanks.

  1. I would recommend to use Cooja with links in DGRM mode to evaluate the perf.

 This sounds like a good idea.=C2=A0 The other co-authors will probably have more follow-up about this.

  1. The RSSI values in the Appendix do not look correct. An RSSI of <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX in the appendix hence may not be correct (i believe these values are from Cooja).

I don't understand how an RSSI could be "too good", unles= s you mean that the power level is too high and causes widespread interference.=C2=A0 Admittedly, I am no expert in interpreting PHY laye= r effects, but anyway usually higher received power allows more accurate detection, if the background noise level remains the same.

[RJ] My reference here = is to the RSSI to ETX mapping table in the draft. The values noted in that = table do not look correct. For RSSI -55 to -45dbm, the expected ETX is 993.= On what basis was this table generated ? Typically i have found that RSSI = of < -80dbm results in very good PDRs (also the ref i attached says the = same).
=C2=A0



 Thanks for the link.=C2=A0 I read through it very briefly on this fine morning.=C2=A0 However, I have also read other papers that seriously question the value of relying on RSSI.=C2=A0
I'l= l try to remember and find one for further discussion. Notably, the authors seem to focus on particular hardware, and a single link between two neighbors, for their discussion, unless I missed something.

[RJ] The authors have not merely focused on single link bet= ween two neighbors. The slides of the paper-talk gives a better picture, htt= ps://sing.stanford.edu/site/talks/emnets2006srinivasan.ppt
=C2=A0
=

Regards,
Charlie P.


--089e082209a0ce72f30560c4799f-- From nobody Wed Dec 20 08:49:53 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4561200B9 for ; Wed, 20 Dec 2017 08:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=indianinstituteofscience.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CT2g93VeixV for ; Wed, 20 Dec 2017 08:49:47 -0800 (PST) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-ma1ind01on0069.outbound.protection.outlook.com [104.47.100.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC66126B71 for ; Wed, 20 Dec 2017 08:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=IndianInstituteofScience.onmicrosoft.com; s=selector1-iisc-ac-in; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=83FfdZUEf3QfpE12s1haT+U2uGBoQYAM2Wgigf/2WeE=; b=hdpfimsxnY3BT+IHgBVK24HQtvaZS4yv4g1Fg9oaHG06gvDH+tOopkXgjw7ki3S0pT1xlIYmTSykOnbIqrER7W4VB/FNMBpHFZeAaYVWvOJOJTV1UYNwrvxeGkTRCWGKN360ApfxweUSElhzMtNl1O3g67n2piyhI0c32vDgUpg= Received: from iisc.ac.in (117.192.105.98) by PN1PR01MB0559.INDPRD01.PROD.OUTLOOK.COM (10.164.142.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Wed, 20 Dec 2017 16:49:41 +0000 Date: Wed, 20 Dec 2017 22:19:37 +0530 From: "S.V.R.Anand" To: Routing Over Low power and Lossy networks Message-ID: <20171220164936.GC4099@iisc.ac.in> References: <363f0dc1-e40d-0a79-80af-1ed4a64bd817@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Originating-IP: [117.192.105.98] X-ClientProxiedBy: BM1PR01CA0096.INDPRD01.PROD.OUTLOOK.COM (10.174.208.12) To PN1PR01MB0559.INDPRD01.PROD.OUTLOOK.COM (10.164.142.11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 77f3529d-f418-4cac-568f-08d547c9aa9b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:PN1PR01MB0559; X-Microsoft-Exchange-Diagnostics: 1; PN1PR01MB0559; 3:+w+w+DLuzfUR37ujuyjP57xm6vn65nUlhEYImTrYzzFt4Bu2d8eBG7gXkme9GR1pAkYty6OLRdmnkd7ncAhA6QWnWkNrSGYYfuh+7rMCvI5OZ+u0K7M12n21sDRUisMSwq3CncID8rYFRT3bc9bpaQZhWjd4yIu/gJRN9q3xCOEv3RPbRb8+N8Y7mTfjffPvnVt6qK52gch+gfEPE2ydC8z6Lr/FWTzFK81+9FpFPNK668pMTW9r94uI57wrotug; 25:/StkuM61I7yB4rYgbXPG1Yp2eUYwd34eFSqnL+nXqmEuKjG5wW77vR4I0zSe1Gboiux/QEVpP9szfKAIzh+hFAMxA+I1i4eLyLCQDQt+UCcptGwNgqYk58C0VO79/ZaV0hFKsTBqbct6fX+gearRhU2wUmDgfarvxGNteMffvSXf8x0cCGrT9jXPt6wpm/UY7NJOi6MWvAPU8+nQNlbG+1Lalkt64VTaaQy7AiZ5ckX7Cb+bthW41b5SaiweTiC/c/7oUSXp+crZRDsq0HGWX7nWQHgY62OlN62wJ2EFZNCQnLJb1RG41SCglqhIhkmk8RmMXqnPRtdHEnLIirOb/g==; 31:HgUx3cTFGsSW/ciiSHuCJB0q4c16nQtHOvWKrdvn1kkiCVUixIk1AeRjyatDOzqv51K6KwpQsSIf4egQdeR1MRe5FHzqfIF3Jwyk1Pqt+TE11IASRMmd9HIXBM+eLvS8YyAnBFVjDO1xkYZVwYdKJJKTU2g0cXWCFJNkLj9kENJGPvh1PG0WhTNzip5XH+jBfGhRb43e7ShJ/Z7fWnqYylzC3vuxspaApjSSwtvWS0Y= X-MS-TrafficTypeDiagnostic: PN1PR01MB0559: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=anandsvr@iisc.ac.in; X-Microsoft-Exchange-Diagnostics: 1; PN1PR01MB0559; 20:uGxHZEkb4D4tHHvojH0rtgGLxw6TENGONsbDlSLlXW3hZQifrPoD5nmGQ9MaATqZDsqT+6pRUBprFjgGdTpQfE8w1CHPPJzQU9+P1rFU49CyAcWK5+J+9ZFqQJgA882MpUj285aZ903Y76782uhCMtJt7+fnj2fMKHD/gFYMVEObqvUNPfk+JPZrVEZJzQN5P/B9jXBCGqpo3Vv0H89qFzlr2ac8EyEmt3py7SotfJSZGhQMpsilsbKHRMQ3Xfe4; 4:WsTJQz+d8zKaAp1zhtoMrXWQ2aEonJR5U72PwE5E+Xj8mBLKcOkFqd4vpsuGl80vlqBsWeYsDNUEW0RjzOOeZtxprDKw/fO3BvHwgdAGRYWwzE7JwAW+0rKqDnimn8Ykjds87cAzSckIgjC9jHsoP68bJStkdECIAEaB1/OVyGB3gUSTt+4QXTArj1reiqGoXwYg9YDqfblokQ1hCGDFUzoYgTnCKoqcZtKTLDq2j5YuFSYWHzgizytHUGZ3xdSDyA/z9np5SCSA+i1fwgD6vJ7bpRs1M9M751sNOj+cUGf3Tj7p5Qd+GTzz45cn3CPV X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(226508931237476); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(10201501046)(3231023)(6041268)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:PN1PR01MB0559; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PN1PR01MB0559; X-Forefront-PRVS: 0527DFA348 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(39860400002)(366004)(396003)(199004)(189003)(24454002)(51914003)(55016002)(55236004)(8666007)(9686003)(83506002)(53936002)(8936002)(2906002)(6246003)(1076002)(59450400001)(47776003)(66066001)(36756003)(3846002)(6116002)(58126008)(33656002)(316002)(786003)(68736007)(6306002)(106356001)(105586002)(53546011)(386003)(6506007)(5890100001)(229853002)(4326008)(478600001)(39056004)(6916009)(42882006)(2950100002)(52146003)(2486003)(23676004)(53416004)(6666003)(25786009)(76176011)(5660300001)(7696005)(52116002)(74482002)(7736002)(97736004)(50466002)(305945005)(69596002)(16526018)(2870700001)(81166006)(966005)(81156014)(8676002)(18370500001)(80872002); DIR:OUT; SFP:1101; SCL:1; SRVR:PN1PR01MB0559; H:iisc.ac.in; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: iisc.ac.in does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtQTjFQUjAxTUIwNTU5OzIzOk54ckkvMk5pb0ducFV5NjZ1ODJLMG11QjlN?= =?utf-8?B?WktWQ1FsbzV3c0dXdUpJazZWdDZPME5oWFkza2lEUDg3VEZzZ1VqRHdhcTRr?= =?utf-8?B?QSszSXR2Y1hUV1JZM0tzVHh4d0lFMytZNEJxcHdRLzJLUi95OWV1Mk5rcm95?= =?utf-8?B?bXptQU9RcTJFcy9ieEJFQ2JLYk9yOHVsaFdtbk5tOEh3bmV1UDlwQ2xEMTJH?= =?utf-8?B?a3o3OGJGNnJsYjMzR2YzN3hRQmNlbHk0VUE0RmhPR3BIcm0yZlBWMWthcndY?= =?utf-8?B?TDAvQ05IRklkd1loTlRzamdGYklyUytGYnF2ditxWkRqczlFTFVEUzZxcnp2?= =?utf-8?B?bjRBZm12RGZkd2ZhbnlKekd5alZWdlZYY3FNeWhBdi9TRitQNTIzcHptdW9X?= =?utf-8?B?ejh0bE15WFl6V3VGdVBFYnI2TzNGNEtZbmR6cE0xYTUwblMwcEhwQ09hdXIw?= =?utf-8?B?RGREZnBLdG5SR1MyNzVBUW52dUJjYUxML1F1WEdSK212dUVhNEUwVU9MOEJk?= =?utf-8?B?Y3FmR0pGenlGYzNVYmlBQjRnWTZpNm15RkExSjlqUmszNC9mdEE3czI0OTVq?= =?utf-8?B?eDNFRzdUeGZMOUdWYVU4WXN3b09sSHljeE5EMmVleFZ2eHF5R2Fodkhpdkdm?= =?utf-8?B?S0ZzQ3VhejR3TXI3U0J3WFBscTNPOVl5bGxJcjJUdUJKSTU5clZNZ0twdXVH?= =?utf-8?B?ajIzdVBCaWdkWnJsdjNrNnB6d3ZCNzRtVDQrOHVlcmUrdVdBNmdMWVgzR2VL?= =?utf-8?B?U29uOUlnbXIyZkQ4RlMrNnlqMEY0dlo0U3BielpURlJ5UHljcytzdzJKU1RS?= =?utf-8?B?T3hEbkJOYzBTRjJudTN0Ly9vQUNzTE10UGNrblNzRTJjbndFSUFDSWJZVVVu?= =?utf-8?B?ZXg2WVZVczFKaGxmMU1yYkJsZitCd3BvVTBQamZnYjF6Y0lSL3ArMXBOT3la?= =?utf-8?B?WU5nK1RXNW45SCsvb2dnTFFWbW02ZUFBby90b2daOXBSeE5RWnlCTEVLSlZY?= =?utf-8?B?bEJDZjNNL1o4M2x6UXJ4WUFQZ0lHREtJT3R4QWNEU3c0VXYxcmlxdndsVGlh?= =?utf-8?B?S0QrQmlXaHRHYzRadzFjZXBFZW8rZVNoejFZclVMVS8yOEdOMEZ5WXc0QklM?= =?utf-8?B?ZVVHZkt4Z3E4K092MjZ0Z0JxcHFSMjJ6aW5mcHhBZXdhWS9WbEFhR1g3R0xP?= =?utf-8?B?T0d5NkpPbldPay9wS1FaN0ZuRytLMnNvekIrL0lodlNweWo5RXVWKzhpQnBD?= =?utf-8?B?cFhqWmpFNGJRdlFOMkgzS0NzNjh0K3ZwWDZUbk5RUm9ROFptaXorM0JLd25n?= =?utf-8?B?OVMydXpHTXoyS01MTUR6UHdBNXRvTUQxOEg4NDU3R0ZYa1hyeVdFOHZXNkp5?= =?utf-8?B?ZE9VNXlUK09wMHkzZjQ4L2daWXRKQjdIVm9rWkNhajJoQ2VjVjloZGFnZmpQ?= =?utf-8?B?ek5sWmNON3VKNG9aeXU5WHc0c2crSXNhRmxGOFNXTUdYTk5lL3dSMmNobFRL?= =?utf-8?B?YnBKaExWZ0VUNkUxQ001Yml2NHpzOEhXcmhZM0dZSXI3Lzd4a2J5bENTNEhh?= =?utf-8?B?S3RPd2FodmN0KzZ2elFtVldlY0ExUCtvVjF3U2VIYXNsdzRNai9ndzZFSGVi?= =?utf-8?B?TEVna3BZeU5KQitKbGxncEF2K0YvUFdQaHJRWFExaVhMWFhsMU9kK09CVEdl?= =?utf-8?B?Rjgvcnh1SkRuVENEVlRJbE0remlYWTFRMjM4R2xFR3hxbFdwYy9pQUVnV21W?= =?utf-8?B?UEF5b3R2TUM4NlBiMVR1bENqUzhFQ2YzUGtBaXZrYzZiT3d2eExVRGVuVnk3?= =?utf-8?B?d3pTM0NoT3c5Q0pRdWJjYllxN0hUdThHeU1GcHRhaUE5Z293elowZWFsNSsx?= =?utf-8?B?aW8ySHQzNWdCczloVUdjODZIUmxlejNHZEhPdmh1UEY4MWhBR2pka2FKTENU?= =?utf-8?B?UFlNR0xrdmxvbHJUMG1SWDF4L3VyYzVqN2RyRHkrOHh2TUVIOXVkYmdESGYx?= =?utf-8?B?eXpUalkrUmVNMkpBK0JYRHB6K21BUmhuZUNiMVY5YzFIMDduTG96WnA4YVpk?= =?utf-8?B?L3U1a0o4VW13ZU0zLzFuZi93RXN5ZFNCVEpRNVI3WWRpV1oydFQ0bDhPVFA2?= =?utf-8?Q?jwIY3UZlB+3ZrzbS0VaO8bI=3D?= X-Microsoft-Exchange-Diagnostics: 1; PN1PR01MB0559; 6:9+EdSjlsT36w8cSnUKbICkN9Gn0UpJt/eSMg3RR9hvxlicZ3xJe6+GxY+7XAn8KPj2UqsB56BRHCzPAUS//Wq6xbZARtSVBbw73TyAVO2OSEiaMT6gmnEoJatBq6kWSMrFPK90wyp04esOyayZQDKM5wWkm5hLkBtTLDd4zwLmpRdyyE8iL/Qb9eQB4Kc/PK5NxGdqf5MRU8oz/e7kIjF0gFEd559oTFvBqN/7lJ0rVQrusfHMgeG14OlXR91G5ZD77sAHClJ6un2EW7ngZ3hKNZ3Q7yyd7BA/g0XlWAiAIgzWotuGi7UQvHvbS6Dqu5E/Pg1CIVIxdVzESHme68wQFLwHHsLhm/YwFSsrR8fOs=; 5:Xs7ty5yoSQSyYuIpyZLCg+qYP3X4rQbGQn3d/Oyn1/scwc0eKORCpgLV510bAlD74FzPz0CKmTnw34RPR6jwVLDoty6nvigs4AycdElCYvMeGpGwJZ4K7Q7Rfsc/cqutl29N7vgcdDdlw7rSU6Y322coRz7FYnFsiU7VuGRSUqs=; 24:d4Fa9v6KkcN35dMjNt6KMhz1/U/0aoGczec9J3cJ6Epc3zk6+i8yc08GXIJcMRdE2Ofy6Jf9awl0mBza9R4KjxiKSjt55bt5YGKbGbtaDkM=; 7:ZQKZA6RY10je5Wt67J6wY3J1UIO5IqUaXtTwYGEqwjicezs+GFVVsTmIRO/GIIhq5dSRa6s4k7HfY+/T0E/I2KpFdA9dQXC1k7f116LPJtdJTPzA5dYk3q7m7WU7bCoAB+ZwYSJBZe1eq8N1evZR/4k+1E7V1fY4BwpGXVNuhhbcQ2iUMn/EVHuO8ToRxAYMiO+V2TLr/0vztbv8zf8ORwh2pll+Si4CBIpcLKf1/TGz2AMIQNfxpqhSPBDug10t SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ece.iisc.ernet.in X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2017 16:49:41.3473 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77f3529d-f418-4cac-568f-08d547c9aa9b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PN1PR01MB0559 Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 16:49:52 -0000 Hello Rahul, Thanks a lot for your review. I agree with your observation on the RSSI-ETX table. The RSSI values mentioned in the draft is the value obtained from the hardware register of the transceiver, in our case it is CC2420. The real RSSI value is obtained by adding an offset to this value as per the datasheet of the transceiver. In the case of CC2420 this offset is -45. So, we need to apply this offset to RSSI values given in the table. In summary, we will update the table with proper RSSI values in the next revision. Regards Anand The 12/20/2017 17:40, Rahul Jadhav wrote: > Hello Charlie, > > Please find my response inline.. > > Regards, > Rahul > > On 15 December 2017 at 20:49, Charlie Perkins > wrote: > > > Hello Rahul, > > > > Thanks for the review! It is much appreciated. I have some follow-up > > below. > > > > On 11/15/2017 8:57 PM, Rahul Jadhav wrote: > > > > Following is my review of AODV-RPL. > > > > One of the stated goal of AODV-RPL is to cater to asymmetric links. While > > this is really great to have, I have doubts that the current specification > > achieves it in a practical way. Foll is the reasoning: > > > > 1. The Messaging: > > > > AODV-RPL requires that you send a multicast message from OrigNode to > > TargNode and realise a routing path in the opposite direction. > > > > For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and > > nodes B,C,D establish routing adjacencies in the opposite direction. This > > kind of messaging is the reason why RPL depends on bidirectional links for > > control/data paths. > > > > > > It's not just RPL. A lot of protocols work this way. > > > > [RJ] But this mode of signaling does not help satisfy the stated goal of > establishing asymmetric links. RPL (and others like p2p-rpl) follows this > mode of signaling and hence depend on bidirectional links. > > > > 2. The Assumptions: > > > > a. Quoting draft, > > > > “Each intermediate node R_i computes the rank for RREQ-Instance and > > creates a routing table entry for the upstream route towards the source > > if the routing metrics/constraints are satisfied. For this purpose R_i > > ***must use the asymmetric link metric measured in the upstream > > direction***, from R_i to its upstream neighbor that multicasted the > > RREQ-Instance message.” > > > > This is the primary assumption which achieves asymmetric behaviour. But > > it’s an implementation nightmare to do this measurement especially because > > we do not know which neighbour we might end up tieing up with (thus need to > > probe all neighbours). > > > > > > I don't think this is true. A node simply has to keep track of the > > information for the upstream destination, and the information about the > > specific node from which the RREQ was received. > > > > [RJ] Assuming a moderately populated hop, a node now needs to keep track of > information in context all the peers on the same hop. You mentioned, 'node > needs to track only upstream destination' ... but imo this is not true. For > P2P paths, its a different DAG instance and thus there are no > pre-determined *upstream destinations*. > > > > It will add up so much to the control overhead and also requires (a good > > deal of) state info to be maintained on behalf of the neighbouring nodes. > > > > > > I don't see why it adds much to the control overhead. The state can be > > timed out after a relatively small duration of time. We will add that > > timeout parameter for the next revision. > > > > [RJ] The reason for high control overhead is that the node will have to > keep probing the neighbors to maintain state. The problem with smaller > duration time is that the probe will be more frequent! Regardless, the > table that needs to be maintained for such information is directly > proportional to the number of neighboring peers. > > > > > > > > > Anyways i tried to search for your implementation to check on this but i > > could not find it. > > > > b. Use of past conditions to suggest future traffic path selection: > > > > “If the RREQ-Instance arrives over an interface that is not known to be > > symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.” > > > > This is a typical problem we face as well. Probing for measurements at > > such scale (all neighbours) is a problem. If you do the probing sparsely, > > the network conditions might have changed when you want to use the > > measurements. > > > > > > Yes, this is naturally a problem in dynamic networks. We can't predict > > the future, so we are stuck with recording salient aspects of the past. No > > matter how often we measure, it is guaranteed to be wrong some (or most!) > > of the time in the future. And yet we persist. > > > > But we do not require periodic or exhaustive measurements for all > > neighbors -- only as needed for the protocol to work. > > > > [RJ] May be this is the part i don't get ... You mentioned "only as needed > for the protocol to work" ... Can this be elaborated? > > > > > > Other points: > > > > 1. Use of odd/even numbers for pairing instances may not be a robust > > way of pairing … There could be race conditions where other P2P-RPL > > instances or floating DODAG instances end up using one of the same value in > > the instance-id pair. How to resolve such collision? > > > > > > But, the instance-ids are local. So if two different nodes use the same > > ID that is O.K. If those two nodes need to have a peer-to-peer route to > > the same destination, that is still O.K., but the RREP sent back to one of > > the source nodes will be able to use the paired instance-ID and the > > streamlined RREP, and the other RREP will have to include an unpaired > > instance-ID along with the IPv6 address of the target node. That will be a > > rare occurrence, and so the optimization of eliding the IPv6 address will > > usually be possible. > > > > [RJ] Yeah, for local instances this might not be a problem. Thanks. > > > > > > > 1. I would recommend to use Cooja with links in DGRM mode to evaluate > > the perf. > > > > > > This sounds like a good idea. The other co-authors will probably have > > more follow-up about this. > > > > > > 1. The RSSI values in the Appendix do not look correct. An RSSI of > > <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX in > > the appendix hence may not be correct (i believe these values are from > > Cooja). > > > > > > I don't understand how an RSSI could be "too good", unless you mean that > > the power level is too high and causes widespread interference. > > Admittedly, I am no expert in interpreting PHY layer effects, but anyway > > usually higher received power allows more accurate detection, if the > > background noise level remains the same. > > > > [RJ] My reference here is to the RSSI to ETX mapping table in the draft. > The values noted in that table do not look correct. For RSSI -55 to -45dbm, > the expected ETX is 993. On what basis was this table generated ? Typically > i have found that RSSI of < -80dbm results in very good PDRs (also the ref > i attached says the same). > > > > > > > > > > [1] RSSI is Under-Appreciated https://sing.stanford.edu/site > > /publications/emnets2006srinivasan.pdf > > > > > > Thanks for the link. I read through it very briefly on this fine > > morning. However, I have also read other papers that seriously question > > the value of relying on RSSI. > > > I'll try to remember and find one for further discussion. Notably, the > > authors seem to focus on particular hardware, and a single link between two > > neighbors, for their discussion, unless I missed something. > > > > [RJ] The authors have not merely focused on single link between two > neighbors. The slides of the paper-talk gives a better picture, > https://sing.stanford.edu/site/talks/emnets2006srinivasan.ppt > > > > > > > Regards, > > Charlie P. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Dec 20 22:49:21 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303621241F8 for ; Wed, 20 Dec 2017 22:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzGEiTdm00WD for ; Wed, 20 Dec 2017 22:49:19 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F661120726 for ; Wed, 20 Dec 2017 22:49:19 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 128FF75C3A689 for ; Thu, 21 Dec 2017 06:49:15 +0000 (GMT) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 21 Dec 2017 06:49:16 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 14:49:09 +0800 From: "Houjianqiang (Derek)" To: Chenyang JI CC: roll Thread-Topic: Suggestions for draft-ji-roll-traffic-aware-objective-function-00 Thread-Index: AdN6AYMrlGyZK5ZrRUKoe01gXGXQXw== Date: Thu, 21 Dec 2017 06:49:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.224] Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086AB1C96DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] Suggestions for draft-ji-roll-traffic-aware-objective-function-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 06:49:21 -0000 --_000_DD0A994E4D6B3F4080662703C8C7C086AB1C96DGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chenyang, Nice to see that you are involved in improving the parent selection in RPL = network, and thanks for bringing the idea "Packet Transmission Rate" into r= oll WG. Your solution is very useful, especially when traffic generated fro= m different nodes is "highly" uneven. I have read through your draft and pr= ovide my comments and suggestions as below. 1. The format of your PTR metric should be modified in order to be co= nsistent with current Metric framework as define in RFC6551. Based on my un= derstanding, you are not requiring IANA to assign a new "DAGMC type" but ra= ther a new "Routing-MC-Type" inside the DAG Metric Container. There is a D= AG Metric Container Format in RFC6551 you can follow and put your PTR insid= e the container as a new metric object. Your co-author Georgios has given a= good example in his draft "draft-pkm-roll-nsa-extension-00". The metric co= ntainer gives you many functions, such as combining PTR with other metrics = like ETX (constraint), ChildCount (metric) and HopCount (metric), which has= been mentioned in your draft. 2. I noticed one weak point of your solution and I have come up with s= ome possible ways to solve that. Nodes select their preferred parent node b= ased on the PTRs of their potential parents (if I understand it right). For= the two-hop cases in your draft, it's fine, but for multi-hop cases, the d= ownstream nodes are unaware of the PTRs of the sink nodes (nodes connected = to the root). For example, in the right pattern of Figure 2 in your draft, = if new nodes come in below C1/C2/D1/D2, then the new nodes will prefer to c= hoose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new node E1->C1= , E2->C2, E3->D1, and assume E1/E2/E3 have PTR =3D 1pkt/s, then in this cas= e, PTR_C1 =3D PTR_C2 =3D PTR_D1 =3D 2 pkt/s, PTR_A =3D 6 pkt/s. This in the= end triggers D1 switches from A to B. So my point is when new nodes join i= n the downstream, they strongly influence the upstream connections. This ef= fect causes an unstable RPL network and should be minimized. One way I come= up with is to use the aggregation mode in the Metric Container so that new= nodes are able to know the whole PTRs along a link to the root and then se= lect based on the whole link condition. Another possible way is you can def= ine a new "RANK" computation that includes the PTRs along a link, e.g. RANK= _C1 =3D PTR_A+0.5*PTR_C1. 3. The PTR computation method hasn't been illustrated in your draft. A= fter thinking a bit more, here is my suggestion. The first method that came= into my mind is to compute base on a time cycle, e.g. count the number of = packet per 10 seconds, but then I denied this method for three reasons: 1. = Nodes may have sleep mode and cannot do this PTR computation when sleeping;= 2. a fixed time cycle may not be accurate to reflect PTR because nodes may= send packets at different rate at different time, e.g. 1pkt/s, 1pkt/hour, = 1pkt/day; 3. frequently computing PTR consumes more energy. I suggest doing= the PTR computation based on the time points when sending packets. For exa= mple, a node send Packet_n-1 at time t_n-1 and send Packet_n at time t_n, t= hen 1 / (t_n - t_n-1) reflects the packet rate. Then The PTR at time t_n co= uld be PTR_n =3D alpha * 1 / (t_n - t_n-1) + (1 - alpha) * PTR_n-1, where alpha are constant between 0 to 1. In this way, nodes refresh their P= TR when sending packets, and the PTR equation gives a smooth variation that= guarantees the stability of a RPL network. Hopefully my suggestions could help to improve the quality of your draft. Best regards, Derek Jianqiang Hou Related drafts and RFC: https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-func= tion/ https://datatracker.ietf.org/doc/rfc6551/ https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ --_000_DD0A994E4D6B3F4080662703C8C7C086AB1C96DGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chenyang,

 

Nice to see that you are involved in improving the p= arent selection in RPL network, and thanks for bringing the idea “Pac= ket Transmission Rate” into roll WG. Your solution is very useful, es= pecially when traffic generated from different nodes is = “highly” uneven. I have read through your draft and provide my = comments and suggestions as below.

 

1.      The format  of your PTR metric should b= e modified in order to be consistent with current Metric framework as defin= e in RFC6551. Based on my understanding, you are not requiring IANA to assi= gn a new “DAGMC type” but rather a new “Routing-MC-Type” inside the DAG Metric Container. There is a =  DAG Metric Container Format in RFC6551 you can follow and put your PT= R inside the container as a new metric object. Your co-author Georgios has = given a good example in his draft “draft-pkm-roll-nsa-extension-00= 221;. The metric container gives you many functions, such as combining PTR with = other metrics like ETX (constraint), ChildCount (metric) and HopCount (metr= ic), which has been mentioned in your draft.

 <= /o:p>

2.      I noticed one weak point of your solution an= d I have come up with some possible ways to solve that. Nodes select their = preferred parent node based on the PTRs of their potential parents (if I un= derstand it right). For the two-hop cases in your draft, it’s fine, but for multi-hop cases, the downstr= eam nodes are unaware of the PTRs of the sink nodes (nodes connected to the= root). For example, in the right pattern of Figure 2 in your draft, if new= nodes come in below C1/C2/D1/D2, then the new nodes will prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is lar= ger). Let’s say new node E1->C1, E2->C2, E3->D1, and assume = E1/E2/E3 have PTR =3D 1pkt/s, then in this case, PTR_C1 =3D PTR_C2 =3D PTR_= D1 =3D 2 pkt/s, PTR_A =3D 6 pkt/s. This in the end triggers D1 switches from A to B. So my point is when new nodes join in the downstr= eam, they strongly influence the upstream connections. This effect causes a= n unstable RPL network and should be minimized. One way I come up with is t= o use the aggregation mode in the Metric Container so that new nodes are able to know the whole PTRs along a= link to the root and then select based on the whole link condition. Anothe= r possible way is you can define a new “RANK” computation that = includes the PTRs along a link, e.g. RANK_C1 =3D PTR_A+0.5*PTR_C1.

 <= /o:p>

3.      The PTR com= putation method hasn’t been illustrated in your draft. After thinking= a bit more, here is my suggestion. The first method that came into my mind= is to compute base on a time cycle, e.g. count the number of packet per 10 seconds, but then I denied this method f= or three reasons: 1. Nodes may have sleep mode and cannot do this PTR compu= tation when sleeping; 2. a fixed time cycle may not be accurate to reflect = PTR because nodes may send packets at different rate at different time, e.g. 1pkt/s, 1pkt/hour, 1pkt/day; 3. = frequently computing PTR consumes more energy. I suggest doing the PTR comp= utation based on the time points when sending packets. For example, a node = send Packet_n-1 at time t_n-1 and send Packet_n at time t_n, then 1 / (t_n – t_n-1) reflects the packe= t rate. Then The PTR at time t_n could be

PTR_n =3D al= pha * 1 / (t_n – t_n-1) + (1 – alpha) * PTR_n-1,

where alpha = are constant between 0 to 1. In this way, nodes refresh their PTR when send= ing packets, and the PTR equation gives a smooth variation that guarantees = the stability of a RPL network.   

 

Hopefully my suggestions could help to improve the q= uality of your draft.

 

Best regards,

Derek Jianqiang Hou

 

Related drafts and RFC:

https://datatracker.ietf.org/doc/d= raft-ji-roll-traffic-aware-objective-function/

https://datatracker.ietf.org/doc/rfc6551/

https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-= extension/

 

 

 

--_000_DD0A994E4D6B3F4080662703C8C7C086AB1C96DGGEMM506MBSchina_-- From nobody Thu Dec 21 04:35:15 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7112D85E for ; Thu, 21 Dec 2017 04:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY_SMI7zQ4-I for ; Thu, 21 Dec 2017 04:35:10 -0800 (PST) Received: from zproxy130.enst.fr (zproxy130.enst.fr [137.194.2.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD2012D861 for ; Thu, 21 Dec 2017 04:35:09 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 70CAC120644; Thu, 21 Dec 2017 13:35:07 +0100 (CET) Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id f44QWDca8SRO; Thu, 21 Dec 2017 13:35:06 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id BACDC121197; Thu, 21 Dec 2017 13:35:06 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr BACDC121197 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.net; s=6A0CDB44-C782-11E6-82EC-91BDBA474D24; t=1513859706; bh=7/gMlWL2zOZQ5etDbqVSV2iwI5IqXdm9FsZbEOSt25E=; h=Date:From:To:Message-ID:MIME-Version; b=YSnWAD60RIcq0etDdBXFlnGkmT9cUu9v0aKstnYxc3Rqxz2pNUvV39PIlcH+RgJpq y5dclx3xlpAFR5YUPY76kzWocK2vMwCmHfZzeHBVH172HM/N6eJmlnjP4O78e6/u07 SwADhols4bagF8EIe6USOQoWan4lgBXPiPfJHw2I= X-Virus-Scanned: amavisd-new at zproxy130.enst.fr Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id gAwfb8-PNGun; Thu, 21 Dec 2017 13:35:06 +0100 (CET) Received: from zmail131.enst.fr (zmail131.enst.fr [137.194.2.203]) by zproxy130.enst.fr (Postfix) with ESMTP id 8210E120768; Thu, 21 Dec 2017 13:35:06 +0100 (CET) Date: Thu, 21 Dec 2017 13:35:06 +0100 (CET) From: Chenyang JI To: Houjianqiang Cc: roll Message-ID: <377942561.78028.1513859706249.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [2001:660:7301:51:787a:d942:4b3a:bd06] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF56 (Linux)/8.7.11_GA_1854) Thread-Topic: Suggestions for draft-ji-roll-traffic-aware-objective-function-00 Thread-Index: AdN6AYMrlGyZK5ZrRUKoe01gXGXQX/R7gGnV Archived-At: Subject: Re: [Roll] Suggestions for draft-ji-roll-traffic-aware-objective-function-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 12:35:14 -0000 Good morning, Thank you a lot for the suggestions,they are very helpful. I added some response below the suggestions after [RE] 1. The format of your PTR metric should be modified in order to be co= nsistent with current Metric framework as define in RFC6551. Based on my un= derstanding, you are not requiring IANA to assign a new "DAGMC type" but ra= ther a new "Routing-MC-Type" inside the DAG Metric Container. There is a D= AG Metric Container Format in RFC6551 you can follow and put your PTR insid= e the container as a new metric object. Your co-author Georgios has given a= good example in his draft "draft-pkm-roll-nsa-extension-00". The metric co= ntainer gives you many functions, such as combining PTR with other metrics = like ETX (constraint), ChildCount (metric) and HopCount (metric), which has= been mentioned in your draft. [RE] I'll make a new figure to clarify that Transmission rate is included i= n Metric container. 2. I noticed one weak point of your solution and I have come up with s= ome possible ways to solve that. Nodes select their preferred parent node b= ased on the PTRs of their potential parents (if I understand it right). For= the two-hop cases in your draft, it's fine, but for multi-hop cases, the d= ownstream nodes are unaware of the PTRs of the sink nodes (nodes connected = to the root). For example, in the right pattern of Figure 2 in your draft, = if new nodes come in below C1/C2/D1/D2, then the new nodes will prefer to c= hoose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new node E1->C1= , E2->C2, E3->D1, and assume E1/E2/E3 have PTR =3D 1pkt/s, then in this cas= e, PTR_C1 =3D PTR_C2 =3D PTR_D1 =3D 2 pkt/s, PTR_A =3D 6 pkt/s. This in the= end triggers D1 switches from A to B. So my point is when new nodes join i= n the downstream, they strongly influence the upstream connections. This ef= fect causes an unstable RPL network and should be minimized. One way I come= up with is to use the aggregation mode in the Metric Container so that new= nodes are able to know the whole PTRs along a link to the root and then se= lect based on the whole link condition. Another possible way is you can def= ine a new "RANK" computation that includes the PTRs along a link, e.g. RANK= _C1 =3D PTR_A+0.5*PTR_C1. [RE] You are right about the weak point,thank you. About the aggregation mode,if I understand correct that requires node to in= form its direct child about its transmission rate change(new node joins its= subtree,child changes parent etc),that may increase the frequency of DIO m= essages? About rank computation,nodes with larger transmission rate will have larger= rank than its neighbor nodes so there is a possibility it selects its neig= hbor as parent and increase the traffic of other subtree. I don't know if I described it in the right way,I'll send a example if need= ed. Regards Chenyang ----- Original Message ----- From: "Houjianqiang" To: "Chenyang JI" Cc: "roll" Sent: Thursday, December 21, 2017 7:49:08 AM Subject: Suggestions for draft-ji-roll-traffic-aware-objective-function-00 Hi Chenyang, Nice to see that you are involved in improving the parent selection in RPL = network, and thanks for bringing the idea "Packet Transmission Rate" into r= oll WG. Your solution is very useful, especially when traffic generated fro= m different nodes is "highly" uneven. I have read through your draft and pr= ovide my comments and suggestions as below. 1. The format of your PTR metric should be modified in order to be co= nsistent with current Metric framework as define in RFC6551. Based on my un= derstanding, you are not requiring IANA to assign a new "DAGMC type" but ra= ther a new "Routing-MC-Type" inside the DAG Metric Container. There is a D= AG Metric Container Format in RFC6551 you can follow and put your PTR insid= e the container as a new metric object. Your co-author Georgios has given a= good example in his draft "draft-pkm-roll-nsa-extension-00". The metric co= ntainer gives you many functions, such as combining PTR with other metrics = like ETX (constraint), ChildCount (metric) and HopCount (metric), which has= been mentioned in your draft. 2. I noticed one weak point of your solution and I have come up with s= ome possible ways to solve that. Nodes select their preferred parent node b= ased on the PTRs of their potential parents (if I understand it right). For= the two-hop cases in your draft, it's fine, but for multi-hop cases, the d= ownstream nodes are unaware of the PTRs of the sink nodes (nodes connected = to the root). For example, in the right pattern of Figure 2 in your draft, = if new nodes come in below C1/C2/D1/D2, then the new nodes will prefer to c= hoose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new node E1->C1= , E2->C2, E3->D1, and assume E1/E2/E3 have PTR =3D 1pkt/s, then in this cas= e, PTR_C1 =3D PTR_C2 =3D PTR_D1 =3D 2 pkt/s, PTR_A =3D 6 pkt/s. This in the= end triggers D1 switches from A to B. So my point is when new nodes join i= n the downstream, they strongly influence the upstream connections. This ef= fect causes an unstable RPL network and should be minimized. One way I come= up with is to use the aggregation mode in the Metric Container so that new= nodes are able to know the whole PTRs along a link to the root and then se= lect based on the whole link condition. Another possible way is you can def= ine a new "RANK" computation that includes the PTRs along a link, e.g. RANK= _C1 =3D PTR_A+0.5*PTR_C1. 3. The PTR computation method hasn't been illustrated in your draft. A= fter thinking a bit more, here is my suggestion. The first method that came= into my mind is to compute base on a time cycle, e.g. count the number of = packet per 10 seconds, but then I denied this method for three reasons: 1. = Nodes may have sleep mode and cannot do this PTR computation when sleeping;= 2. a fixed time cycle may not be accurate to reflect PTR because nodes may= send packets at different rate at different time, e.g. 1pkt/s, 1pkt/hour, = 1pkt/day; 3. frequently computing PTR consumes more energy. I suggest doing= the PTR computation based on the time points when sending packets. For exa= mple, a node send Packet_n-1 at time t_n-1 and send Packet_n at time t_n, t= hen 1 / (t_n - t_n-1) reflects the packet rate. Then The PTR at time t_n co= uld be PTR_n =3D alpha * 1 / (t_n - t_n-1) + (1 - alpha) * PTR_n-1, where alpha are constant between 0 to 1. In this way, nodes refresh their P= TR when sending packets, and the PTR equation gives a smooth variation that= guarantees the stability of a RPL network. Hopefully my suggestions could help to improve the quality of your draft. Best regards, Derek Jianqiang Hou Related drafts and RFC: https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-func= tion/ https://datatracker.ietf.org/doc/rfc6551/ https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ From nobody Thu Dec 21 18:48:13 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79012D7EE for ; Thu, 21 Dec 2017 18:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVtBAVM_vgc7 for ; Thu, 21 Dec 2017 18:48:09 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27525120713 for ; Thu, 21 Dec 2017 18:48:09 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3F98AD6D6FB77 for ; Fri, 22 Dec 2017 02:48:05 +0000 (GMT) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 22 Dec 2017 02:48:06 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Fri, 22 Dec 2017 10:48:02 +0800 From: "Houjianqiang (Derek)" To: Chenyang JI CC: roll Thread-Topic: Suggestions for draft-ji-roll-traffic-aware-objective-function-00 Thread-Index: AdN6AYMrlGyZK5ZrRUKoe01gXGXQX/R7gGnV9Hn4LWA= Date: Fri, 22 Dec 2017 02:48:01 +0000 Message-ID: References: <377942561.78028.1513859706249.JavaMail.zimbra@imt-atlantique.net> In-Reply-To: <377942561.78028.1513859706249.JavaMail.zimbra@imt-atlantique.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.224] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Suggestions for draft-ji-roll-traffic-aware-objective-function-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 02:48:12 -0000 SGkgQ2hlbnlhbmcsDQoNClJlZ2FyZGluZyB5b3VyIHF1ZXN0aW9ucywgcGxlYXNlIHNlZSBteSBy ZXNwb25zZSBpbiBsaW5lLg0KDQoyLiAgICAgIEkgbm90aWNlZCBvbmUgd2VhayBwb2ludCBvZiB5 b3VyIHNvbHV0aW9uIGFuZCBJIGhhdmUgY29tZSB1cCB3aXRoIHNvbWUgcG9zc2libGUgd2F5cyB0 byBzb2x2ZSB0aGF0LiBOb2RlcyBzZWxlY3QgdGhlaXIgcHJlZmVycmVkIHBhcmVudCBub2RlIGJh c2VkIG9uIHRoZSBQVFJzIG9mIHRoZWlyIHBvdGVudGlhbCBwYXJlbnRzIChpZiBJIHVuZGVyc3Rh bmQgaXQgcmlnaHQpLiBGb3IgdGhlIHR3by1ob3AgY2FzZXMgaW4geW91ciBkcmFmdCwgaXQncyBm aW5lLCBidXQgZm9yIG11bHRpLWhvcCBjYXNlcywgdGhlIGRvd25zdHJlYW0gbm9kZXMgYXJlIHVu YXdhcmUgb2YgdGhlIFBUUnMgb2YgdGhlIHNpbmsgbm9kZXMgKG5vZGVzIGNvbm5lY3RlZCB0byB0 aGUgcm9vdCkuIEZvciBleGFtcGxlLCBpbiB0aGUgcmlnaHQgcGF0dGVybiBvZiBGaWd1cmUgMiBp biB5b3VyIGRyYWZ0LCBpZiBuZXcgbm9kZXMgY29tZSBpbiBiZWxvdyBDMS9DMi9EMS9EMiwgdGhl biB0aGUgbmV3IG5vZGVzIHdpbGwgcHJlZmVyIHRvIGNob29zZSBDMS9DMi9EMSByYXRoZXIgdGhh biBEMiAoUFRSX0QyIGlzIGxhcmdlcikuIExldCdzIHNheSBuZXcgbm9kZSBFMS0+QzEsIEUyLT5D MiwgRTMtPkQxLCBhbmQgYXNzdW1lIEUxL0UyL0UzIGhhdmUgUFRSID0gMXBrdC9zLCB0aGVuIGlu IHRoaXMgY2FzZSwgUFRSX0MxID0gUFRSX0MyID0gUFRSX0QxID0gMiBwa3QvcywgUFRSX0EgPSA2 IHBrdC9zLiBUaGlzIGluIHRoZSBlbmQgdHJpZ2dlcnMgRDEgc3dpdGNoZXMgZnJvbSBBIHRvIEIu IFNvIG15IHBvaW50IGlzIHdoZW4gbmV3IG5vZGVzIGpvaW4gaW4gdGhlIGRvd25zdHJlYW0sIHRo ZXkgc3Ryb25nbHkgaW5mbHVlbmNlIHRoZSB1cHN0cmVhbSBjb25uZWN0aW9ucy4gVGhpcyBlZmZl Y3QgY2F1c2VzIGFuIHVuc3RhYmxlIFJQTCBuZXR3b3JrIGFuZCBzaG91bGQgYmUgbWluaW1pemVk LiBPbmUgd2F5IEkgY29tZSB1cCB3aXRoIGlzIHRvIHVzZSB0aGUgYWdncmVnYXRpb24gbW9kZSBp biB0aGUgTWV0cmljIENvbnRhaW5lciBzbyB0aGF0IG5ldyBub2RlcyBhcmUgYWJsZSB0byBrbm93 IHRoZSB3aG9sZSBQVFJzIGFsb25nIGEgbGluayB0byB0aGUgcm9vdCBhbmQgdGhlbiBzZWxlY3Qg YmFzZWQgb24gdGhlIHdob2xlIGxpbmsgY29uZGl0aW9uLiBBbm90aGVyIHBvc3NpYmxlIHdheSBp cyB5b3UgY2FuIGRlZmluZSBhIG5ldyAiUkFOSyIgY29tcHV0YXRpb24gdGhhdCBpbmNsdWRlcyB0 aGUgUFRScyBhbG9uZyBhIGxpbmssIGUuZy4gUkFOS19DMSA9IFBUUl9BKzAuNSpQVFJfQzEuDQoN CltSRV0gWW91IGFyZSByaWdodCBhYm91dCB0aGUgd2VhayBwb2ludCx0aGFuayB5b3UuDQpBYm91 dCB0aGUgYWdncmVnYXRpb24gbW9kZSxpZiBJIHVuZGVyc3RhbmQgY29ycmVjdCB0aGF0IHJlcXVp cmVzIG5vZGUgdG8gaW5mb3JtIGl0cyBkaXJlY3QgY2hpbGQgYWJvdXQgaXRzIHRyYW5zbWlzc2lv biByYXRlIGNoYW5nZShuZXcgbm9kZSBqb2lucyBpdHMgc3VidHJlZSxjaGlsZCBjaGFuZ2VzIHBh cmVudCBldGMpLHRoYXQgbWF5IGluY3JlYXNlIHRoZSBmcmVxdWVuY3kgb2YgRElPIG1lc3NhZ2Vz Pw0KDQo+PiBbRGVyZWtdIFRoZSBmcmVxdWVuY3kgb2Ygc2VuZGluZyBESU8gaXMgZGV0ZXJtaW5l ZCBieSBUcmlja2xlIGFsZ29yaXRobSwgbm90IHRoZSBhZ2dyZWdhdGlvbiBtb2RlLiBSUEwgYWRh cHRzIHRoZSBzZW5kaW5nIHJhdGUgb2YgRElPIG1lc3NhZ2VzIGJ5IGV4dGVuZGluZyB0aGUgVHJp Y2tsZSBhbGdvcml0aG0uIEluIGEgbmV0d29yayB3aXRoIHN0YWJsZSBsaW5rcyB0aGUgY29udHJv bCBtZXNzYWdlcyB3aWxsIGJlIHJhcmUgd2hlcmVhcyBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCB0 aGUgdG9wb2xvZ3kgY2hhbmdlcyBmcmVxdWVudGx5IHdpbGwgY2F1c2UgUlBMIHRvIHNlbmQgY29u dHJvbCBpbmZvcm1hdGlvbiBtb3JlIG9mdGVuLg0KDQpBYm91dCByYW5rIGNvbXB1dGF0aW9uLG5v ZGVzIHdpdGggbGFyZ2VyIHRyYW5zbWlzc2lvbiByYXRlIHdpbGwgaGF2ZSBsYXJnZXIgcmFuayB0 aGFuIGl0cyBuZWlnaGJvciBub2RlcyBzbyB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IGl0IHNlbGVj dHMgaXRzIG5laWdoYm9yIGFzIHBhcmVudCBhbmQgaW5jcmVhc2UgdGhlIHRyYWZmaWMgb2Ygb3Ro ZXIgc3VidHJlZS4NCkkgZG9uJ3Qga25vdyBpZiBJIGRlc2NyaWJlZCBpdCBpbiB0aGUgcmlnaHQg d2F5LEknbGwgc2VuZCBhIGV4YW1wbGUgaWYgbmVlZGVkLg0KDQo+PltEZXJla10gSSBndWVzcyBJ IGhhdmUgZ290IHdoYXQgeW91IG1lYW4uIExldCdzIHN0aWxsIHRha2UgdGhlIHJpZ2h0IHBhdHRl cm4gaW4gRmlndXJlIDIgaW4geW91ciBkcmFmdCBhcyBhbiBleGFtcGxlLCBhcmUgeW91IHNheWlu ZyB0aGF0IHdoZW4gUFRSX0QyIGJlY29tZXMgbGFyZ2VyLCBlLmcuIDVwa3QvcywgdGhlbiBQVFJf QiA9IDUuIElmIHVzaW5nIHRoZSAiUkFOSyIgZXF1YXRpb24gSSBzdWdnZXN0ZWQgYWJvdmUsIHRo ZW4gUkFOS19BID0gMywgUkFOS19CID0gNSwgUkFOS19EMSA9IDMuNSwgUkFOS19EMiA9IDcuNS4g SW4gdGhpcyBjYXNlIG5vZGUgRDIgbWF5IGNoYW5nZSBpdHMgcGFyZW50IGZyb20gQiB0byBEMS4g SWYgdGhpcyBpcyB3aGF0IHlvdSBtZWFuLCBkZWZpbml0ZWx5IHdlIGRvbid0IHdhbnQgdG8gc2Vl IHRoaXMgaGFwcGVuLiBUbyBhdm9pZCB0aGlzLCB5b3Ugc2hvdWxkIHNwZWNpZnkgd2hlbiBhbmQg dW5kZXIgd2hhdCBjb25kaXRpb24gdGhlIHBhcmVudCBzd2l0Y2ggd2lsbCBoYXBwZW4uIFRoZSBQ QVJFTlRfU1dJVENIX1RIUkVTSE9MRCBvZiBEMiBzaG91bGQgYmUgcmVsYXRlZCB0byBSQU5LX0Ig dG9nZXRoZXIgd2l0aCBQVFJfRDIuIEkgbWVhbiBzaW5jZSB0aGUgZG93bnN0cmVhbSBub2RlcyBp bmZsdWVuY2UgdGhlIFJBTksgb2YgdGhlaXIgdXBzdHJlYW0gcGFyZW50LCB0aGVuIG5vZGUgRDIg c2hvdWxkIGNvbXB1dGUgd2hhdCBSQU5LX0Igd2lsbCBiZSBpZiB3aXRob3V0IHRoZSBjb250cmli dXRpb24gb2YgRDIgaXRzZWxmLiAgICANCg0KUmVnYXJkcywgDQpEZXJlayBKaWFucWlhbmcgSG91 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaGVueWFuZyBKSSBbbWFpbHRv OmNoZW55YW5nLmppQGltdC1hdGxhbnRpcXVlLm5ldF0gDQpTZW50OiBUaHVyc2RheSwgRGVjZW1i ZXIgMjEsIDIwMTcgODozNSBQTQ0KVG86IEhvdWppYW5xaWFuZyAoRGVyZWspIDxob3VqaWFucWlh bmdAaHVhd2VpLmNvbT4NCkNjOiByb2xsIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFN1 Z2dlc3Rpb25zIGZvciBkcmFmdC1qaS1yb2xsLXRyYWZmaWMtYXdhcmUtb2JqZWN0aXZlLWZ1bmN0 aW9uLTAwDQoNCkdvb2QgbW9ybmluZywNCg0KVGhhbmsgeW91IGEgbG90IGZvciB0aGUgc3VnZ2Vz dGlvbnMsdGhleSBhcmUgdmVyeSBoZWxwZnVsLg0KSSBhZGRlZCBzb21lIHJlc3BvbnNlIGJlbG93 IHRoZSBzdWdnZXN0aW9ucyBhZnRlciBbUkVdDQoNCg0KMS4gICAgICBUaGUgZm9ybWF0ICBvZiB5 b3VyIFBUUiBtZXRyaWMgc2hvdWxkIGJlIG1vZGlmaWVkIGluIG9yZGVyIHRvIGJlIGNvbnNpc3Rl bnQgd2l0aCBjdXJyZW50IE1ldHJpYyBmcmFtZXdvcmsgYXMgZGVmaW5lIGluIFJGQzY1NTEuIEJh c2VkIG9uIG15IHVuZGVyc3RhbmRpbmcsIHlvdSBhcmUgbm90IHJlcXVpcmluZyBJQU5BIHRvIGFz c2lnbiBhIG5ldyAiREFHTUMgdHlwZSIgYnV0IHJhdGhlciBhIG5ldyAiUm91dGluZy1NQy1UeXBl IiBpbnNpZGUgdGhlIERBRyBNZXRyaWMgQ29udGFpbmVyLiBUaGVyZSBpcyBhICBEQUcgTWV0cmlj IENvbnRhaW5lciBGb3JtYXQgaW4gUkZDNjU1MSB5b3UgY2FuIGZvbGxvdyBhbmQgcHV0IHlvdXIg UFRSIGluc2lkZSB0aGUgY29udGFpbmVyIGFzIGEgbmV3IG1ldHJpYyBvYmplY3QuIFlvdXIgY28t YXV0aG9yIEdlb3JnaW9zIGhhcyBnaXZlbiBhIGdvb2QgZXhhbXBsZSBpbiBoaXMgZHJhZnQgImRy YWZ0LXBrbS1yb2xsLW5zYS1leHRlbnNpb24tMDAiLiBUaGUgbWV0cmljIGNvbnRhaW5lciBnaXZl cyB5b3UgbWFueSBmdW5jdGlvbnMsIHN1Y2ggYXMgY29tYmluaW5nIFBUUiB3aXRoIG90aGVyIG1l dHJpY3MgbGlrZSBFVFggKGNvbnN0cmFpbnQpLCBDaGlsZENvdW50IChtZXRyaWMpIGFuZCBIb3BD b3VudCAobWV0cmljKSwgd2hpY2ggaGFzIGJlZW4gbWVudGlvbmVkIGluIHlvdXIgZHJhZnQuDQoN CltSRV0gSSdsbCBtYWtlIGEgbmV3IGZpZ3VyZSB0byBjbGFyaWZ5IHRoYXQgVHJhbnNtaXNzaW9u IHJhdGUgaXMgaW5jbHVkZWQgaW4gTWV0cmljIGNvbnRhaW5lci4NCg0KDQoyLiAgICAgIEkgbm90 aWNlZCBvbmUgd2VhayBwb2ludCBvZiB5b3VyIHNvbHV0aW9uIGFuZCBJIGhhdmUgY29tZSB1cCB3 aXRoIHNvbWUgcG9zc2libGUgd2F5cyB0byBzb2x2ZSB0aGF0LiBOb2RlcyBzZWxlY3QgdGhlaXIg cHJlZmVycmVkIHBhcmVudCBub2RlIGJhc2VkIG9uIHRoZSBQVFJzIG9mIHRoZWlyIHBvdGVudGlh bCBwYXJlbnRzIChpZiBJIHVuZGVyc3RhbmQgaXQgcmlnaHQpLiBGb3IgdGhlIHR3by1ob3AgY2Fz ZXMgaW4geW91ciBkcmFmdCwgaXQncyBmaW5lLCBidXQgZm9yIG11bHRpLWhvcCBjYXNlcywgdGhl IGRvd25zdHJlYW0gbm9kZXMgYXJlIHVuYXdhcmUgb2YgdGhlIFBUUnMgb2YgdGhlIHNpbmsgbm9k ZXMgKG5vZGVzIGNvbm5lY3RlZCB0byB0aGUgcm9vdCkuIEZvciBleGFtcGxlLCBpbiB0aGUgcmln aHQgcGF0dGVybiBvZiBGaWd1cmUgMiBpbiB5b3VyIGRyYWZ0LCBpZiBuZXcgbm9kZXMgY29tZSBp biBiZWxvdyBDMS9DMi9EMS9EMiwgdGhlbiB0aGUgbmV3IG5vZGVzIHdpbGwgcHJlZmVyIHRvIGNo b29zZSBDMS9DMi9EMSByYXRoZXIgdGhhbiBEMiAoUFRSX0QyIGlzIGxhcmdlcikuIExldCdzIHNh eSBuZXcgbm9kZSBFMS0+QzEsIEUyLT5DMiwgRTMtPkQxLCBhbmQgYXNzdW1lIEUxL0UyL0UzIGhh dmUgUFRSID0gMXBrdC9zLCB0aGVuIGluIHRoaXMgY2FzZSwgUFRSX0MxID0gUFRSX0MyID0gUFRS X0QxID0gMiBwa3QvcywgUFRSX0EgPSA2IHBrdC9zLiBUaGlzIGluIHRoZSBlbmQgdHJpZ2dlcnMg RDEgc3dpdGNoZXMgZnJvbSBBIHRvIEIuIFNvIG15IHBvaW50IGlzIHdoZW4gbmV3IG5vZGVzIGpv aW4gaW4gdGhlIGRvd25zdHJlYW0sIHRoZXkgc3Ryb25nbHkgaW5mbHVlbmNlIHRoZSB1cHN0cmVh bSBjb25uZWN0aW9ucy4gVGhpcyBlZmZlY3QgY2F1c2VzIGFuIHVuc3RhYmxlIFJQTCBuZXR3b3Jr IGFuZCBzaG91bGQgYmUgbWluaW1pemVkLiBPbmUgd2F5IEkgY29tZSB1cCB3aXRoIGlzIHRvIHVz ZSB0aGUgYWdncmVnYXRpb24gbW9kZSBpbiB0aGUgTWV0cmljIENvbnRhaW5lciBzbyB0aGF0IG5l dyBub2RlcyBhcmUgYWJsZSB0byBrbm93IHRoZSB3aG9sZSBQVFJzIGFsb25nIGEgbGluayB0byB0 aGUgcm9vdCBhbmQgdGhlbiBzZWxlY3QgYmFzZWQgb24gdGhlIHdob2xlIGxpbmsgY29uZGl0aW9u LiBBbm90aGVyIHBvc3NpYmxlIHdheSBpcyB5b3UgY2FuIGRlZmluZSBhIG5ldyAiUkFOSyIgY29t cHV0YXRpb24gdGhhdCBpbmNsdWRlcyB0aGUgUFRScyBhbG9uZyBhIGxpbmssIGUuZy4gUkFOS19D MSA9IFBUUl9BKzAuNSpQVFJfQzEuDQoNCltSRV0gWW91IGFyZSByaWdodCBhYm91dCB0aGUgd2Vh ayBwb2ludCx0aGFuayB5b3UuDQpBYm91dCB0aGUgYWdncmVnYXRpb24gbW9kZSxpZiBJIHVuZGVy c3RhbmQgY29ycmVjdCB0aGF0IHJlcXVpcmVzIG5vZGUgdG8gaW5mb3JtIGl0cyBkaXJlY3QgY2hp bGQgYWJvdXQgaXRzIHRyYW5zbWlzc2lvbiByYXRlIGNoYW5nZShuZXcgbm9kZSBqb2lucyBpdHMg c3VidHJlZSxjaGlsZCBjaGFuZ2VzIHBhcmVudCBldGMpLHRoYXQgbWF5IGluY3JlYXNlIHRoZSBm cmVxdWVuY3kgb2YgRElPIG1lc3NhZ2VzPw0KQWJvdXQgcmFuayBjb21wdXRhdGlvbixub2RlcyB3 aXRoIGxhcmdlciB0cmFuc21pc3Npb24gcmF0ZSB3aWxsIGhhdmUgbGFyZ2VyIHJhbmsgdGhhbiBp dHMgbmVpZ2hib3Igbm9kZXMgc28gdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSBpdCBzZWxlY3RzIGl0 cyBuZWlnaGJvciBhcyBwYXJlbnQgYW5kIGluY3JlYXNlIHRoZSB0cmFmZmljIG9mIG90aGVyIHN1 YnRyZWUuDQpJIGRvbid0IGtub3cgaWYgSSBkZXNjcmliZWQgaXQgaW4gdGhlIHJpZ2h0IHdheSxJ J2xsIHNlbmQgYSBleGFtcGxlIGlmIG5lZWRlZC4NCg0KDQpSZWdhcmRzDQpDaGVueWFuZw0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiSG91amlhbnFpYW5nIiA8aG91amlh bnFpYW5nQGh1YXdlaS5jb20+DQpUbzogIkNoZW55YW5nIEpJIiA8Y2hlbnlhbmcuamlAaW10LWF0 bGFudGlxdWUubmV0Pg0KQ2M6ICJyb2xsIiA8cm9sbEBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciAyMSwgMjAxNyA3OjQ5OjA4IEFNDQpTdWJqZWN0OiBTdWdnZXN0aW9ucyBmb3Ig ZHJhZnQtamktcm9sbC10cmFmZmljLWF3YXJlLW9iamVjdGl2ZS1mdW5jdGlvbi0wMA0KDQpIaSBD aGVueWFuZywNCg0KTmljZSB0byBzZWUgdGhhdCB5b3UgYXJlIGludm9sdmVkIGluIGltcHJvdmlu ZyB0aGUgcGFyZW50IHNlbGVjdGlvbiBpbiBSUEwgbmV0d29yaywgYW5kIHRoYW5rcyBmb3IgYnJp bmdpbmcgdGhlIGlkZWEgIlBhY2tldCBUcmFuc21pc3Npb24gUmF0ZSIgaW50byByb2xsIFdHLiBZ b3VyIHNvbHV0aW9uIGlzIHZlcnkgdXNlZnVsLCBlc3BlY2lhbGx5IHdoZW4gdHJhZmZpYyBnZW5l cmF0ZWQgZnJvbSBkaWZmZXJlbnQgbm9kZXMgaXMgImhpZ2hseSIgdW5ldmVuLiBJIGhhdmUgcmVh ZCB0aHJvdWdoIHlvdXIgZHJhZnQgYW5kIHByb3ZpZGUgbXkgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zIGFzIGJlbG93Lg0KDQoNCjEuICAgICAgVGhlIGZvcm1hdCAgb2YgeW91ciBQVFIgbWV0cmlj IHNob3VsZCBiZSBtb2RpZmllZCBpbiBvcmRlciB0byBiZSBjb25zaXN0ZW50IHdpdGggY3VycmVu dCBNZXRyaWMgZnJhbWV3b3JrIGFzIGRlZmluZSBpbiBSRkM2NTUxLiBCYXNlZCBvbiBteSB1bmRl cnN0YW5kaW5nLCB5b3UgYXJlIG5vdCByZXF1aXJpbmcgSUFOQSB0byBhc3NpZ24gYSBuZXcgIkRB R01DIHR5cGUiIGJ1dCByYXRoZXIgYSBuZXcgIlJvdXRpbmctTUMtVHlwZSIgaW5zaWRlIHRoZSBE QUcgTWV0cmljIENvbnRhaW5lci4gVGhlcmUgaXMgYSAgREFHIE1ldHJpYyBDb250YWluZXIgRm9y bWF0IGluIFJGQzY1NTEgeW91IGNhbiBmb2xsb3cgYW5kIHB1dCB5b3VyIFBUUiBpbnNpZGUgdGhl IGNvbnRhaW5lciBhcyBhIG5ldyBtZXRyaWMgb2JqZWN0LiBZb3VyIGNvLWF1dGhvciBHZW9yZ2lv cyBoYXMgZ2l2ZW4gYSBnb29kIGV4YW1wbGUgaW4gaGlzIGRyYWZ0ICJkcmFmdC1wa20tcm9sbC1u c2EtZXh0ZW5zaW9uLTAwIi4gVGhlIG1ldHJpYyBjb250YWluZXIgZ2l2ZXMgeW91IG1hbnkgZnVu Y3Rpb25zLCBzdWNoIGFzIGNvbWJpbmluZyBQVFIgd2l0aCBvdGhlciBtZXRyaWNzIGxpa2UgRVRY IChjb25zdHJhaW50KSwgQ2hpbGRDb3VudCAobWV0cmljKSBhbmQgSG9wQ291bnQgKG1ldHJpYyks IHdoaWNoIGhhcyBiZWVuIG1lbnRpb25lZCBpbiB5b3VyIGRyYWZ0Lg0KDQoNCg0KMi4gICAgICBJ IG5vdGljZWQgb25lIHdlYWsgcG9pbnQgb2YgeW91ciBzb2x1dGlvbiBhbmQgSSBoYXZlIGNvbWUg dXAgd2l0aCBzb21lIHBvc3NpYmxlIHdheXMgdG8gc29sdmUgdGhhdC4gTm9kZXMgc2VsZWN0IHRo ZWlyIHByZWZlcnJlZCBwYXJlbnQgbm9kZSBiYXNlZCBvbiB0aGUgUFRScyBvZiB0aGVpciBwb3Rl bnRpYWwgcGFyZW50cyAoaWYgSSB1bmRlcnN0YW5kIGl0IHJpZ2h0KS4gRm9yIHRoZSB0d28taG9w IGNhc2VzIGluIHlvdXIgZHJhZnQsIGl0J3MgZmluZSwgYnV0IGZvciBtdWx0aS1ob3AgY2FzZXMs IHRoZSBkb3duc3RyZWFtIG5vZGVzIGFyZSB1bmF3YXJlIG9mIHRoZSBQVFJzIG9mIHRoZSBzaW5r IG5vZGVzIChub2RlcyBjb25uZWN0ZWQgdG8gdGhlIHJvb3QpLiBGb3IgZXhhbXBsZSwgaW4gdGhl IHJpZ2h0IHBhdHRlcm4gb2YgRmlndXJlIDIgaW4geW91ciBkcmFmdCwgaWYgbmV3IG5vZGVzIGNv bWUgaW4gYmVsb3cgQzEvQzIvRDEvRDIsIHRoZW4gdGhlIG5ldyBub2RlcyB3aWxsIHByZWZlciB0 byBjaG9vc2UgQzEvQzIvRDEgcmF0aGVyIHRoYW4gRDIgKFBUUl9EMiBpcyBsYXJnZXIpLiBMZXQn cyBzYXkgbmV3IG5vZGUgRTEtPkMxLCBFMi0+QzIsIEUzLT5EMSwgYW5kIGFzc3VtZSBFMS9FMi9F MyBoYXZlIFBUUiA9IDFwa3QvcywgdGhlbiBpbiB0aGlzIGNhc2UsIFBUUl9DMSA9IFBUUl9DMiA9 IFBUUl9EMSA9IDIgcGt0L3MsIFBUUl9BID0gNiBwa3Qvcy4gVGhpcyBpbiB0aGUgZW5kIHRyaWdn ZXJzIEQxIHN3aXRjaGVzIGZyb20gQSB0byBCLiBTbyBteSBwb2ludCBpcyB3aGVuIG5ldyBub2Rl cyBqb2luIGluIHRoZSBkb3duc3RyZWFtLCB0aGV5IHN0cm9uZ2x5IGluZmx1ZW5jZSB0aGUgdXBz dHJlYW0gY29ubmVjdGlvbnMuIFRoaXMgZWZmZWN0IGNhdXNlcyBhbiB1bnN0YWJsZSBSUEwgbmV0 d29yayBhbmQgc2hvdWxkIGJlIG1pbmltaXplZC4gT25lIHdheSBJIGNvbWUgdXAgd2l0aCBpcyB0 byB1c2UgdGhlIGFnZ3JlZ2F0aW9uIG1vZGUgaW4gdGhlIE1ldHJpYyBDb250YWluZXIgc28gdGhh dCBuZXcgbm9kZXMgYXJlIGFibGUgdG8ga25vdyB0aGUgd2hvbGUgUFRScyBhbG9uZyBhIGxpbmsg dG8gdGhlIHJvb3QgYW5kIHRoZW4gc2VsZWN0IGJhc2VkIG9uIHRoZSB3aG9sZSBsaW5rIGNvbmRp dGlvbi4gQW5vdGhlciBwb3NzaWJsZSB3YXkgaXMgeW91IGNhbiBkZWZpbmUgYSBuZXcgIlJBTksi IGNvbXB1dGF0aW9uIHRoYXQgaW5jbHVkZXMgdGhlIFBUUnMgYWxvbmcgYSBsaW5rLCBlLmcuIFJB TktfQzEgPSBQVFJfQSswLjUqUFRSX0MxLg0KDQoNCg0KMy4gICAgICBUaGUgUFRSIGNvbXB1dGF0 aW9uIG1ldGhvZCBoYXNuJ3QgYmVlbiBpbGx1c3RyYXRlZCBpbiB5b3VyIGRyYWZ0LiBBZnRlciB0 aGlua2luZyBhIGJpdCBtb3JlLCBoZXJlIGlzIG15IHN1Z2dlc3Rpb24uIFRoZSBmaXJzdCBtZXRo b2QgdGhhdCBjYW1lIGludG8gbXkgbWluZCBpcyB0byBjb21wdXRlIGJhc2Ugb24gYSB0aW1lIGN5 Y2xlLCBlLmcuIGNvdW50IHRoZSBudW1iZXIgb2YgcGFja2V0IHBlciAxMCBzZWNvbmRzLCBidXQg dGhlbiBJIGRlbmllZCB0aGlzIG1ldGhvZCBmb3IgdGhyZWUgcmVhc29uczogMS4gTm9kZXMgbWF5 IGhhdmUgc2xlZXAgbW9kZSBhbmQgY2Fubm90IGRvIHRoaXMgUFRSIGNvbXB1dGF0aW9uIHdoZW4g c2xlZXBpbmc7IDIuIGEgZml4ZWQgdGltZSBjeWNsZSBtYXkgbm90IGJlIGFjY3VyYXRlIHRvIHJl ZmxlY3QgUFRSIGJlY2F1c2Ugbm9kZXMgbWF5IHNlbmQgcGFja2V0cyBhdCBkaWZmZXJlbnQgcmF0 ZSBhdCBkaWZmZXJlbnQgdGltZSwgZS5nLiAxcGt0L3MsIDFwa3QvaG91ciwgMXBrdC9kYXk7IDMu IGZyZXF1ZW50bHkgY29tcHV0aW5nIFBUUiBjb25zdW1lcyBtb3JlIGVuZXJneS4gSSBzdWdnZXN0 IGRvaW5nIHRoZSBQVFIgY29tcHV0YXRpb24gYmFzZWQgb24gdGhlIHRpbWUgcG9pbnRzIHdoZW4g c2VuZGluZyBwYWNrZXRzLiBGb3IgZXhhbXBsZSwgYSBub2RlIHNlbmQgUGFja2V0X24tMSBhdCB0 aW1lIHRfbi0xIGFuZCBzZW5kIFBhY2tldF9uIGF0IHRpbWUgdF9uLCB0aGVuIDEgLyAodF9uIC0g dF9uLTEpIHJlZmxlY3RzIHRoZSBwYWNrZXQgcmF0ZS4gVGhlbiBUaGUgUFRSIGF0IHRpbWUgdF9u IGNvdWxkIGJlDQoNClBUUl9uID0gYWxwaGEgKiAxIC8gKHRfbiAtIHRfbi0xKSArICgxIC0gYWxw aGEpICogUFRSX24tMSwNCg0Kd2hlcmUgYWxwaGEgYXJlIGNvbnN0YW50IGJldHdlZW4gMCB0byAx LiBJbiB0aGlzIHdheSwgbm9kZXMgcmVmcmVzaCB0aGVpciBQVFIgd2hlbiBzZW5kaW5nIHBhY2tl dHMsIGFuZCB0aGUgUFRSIGVxdWF0aW9uIGdpdmVzIGEgc21vb3RoIHZhcmlhdGlvbiB0aGF0IGd1 YXJhbnRlZXMgdGhlIHN0YWJpbGl0eSBvZiBhIFJQTCBuZXR3b3JrLg0KDQpIb3BlZnVsbHkgbXkg c3VnZ2VzdGlvbnMgY291bGQgaGVscCB0byBpbXByb3ZlIHRoZSBxdWFsaXR5IG9mIHlvdXIgZHJh ZnQuDQoNCkJlc3QgcmVnYXJkcywNCkRlcmVrIEppYW5xaWFuZyBIb3UNCg0KUmVsYXRlZCBkcmFm dHMgYW5kIFJGQzoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppLXJv bGwtdHJhZmZpYy1hd2FyZS1vYmplY3RpdmUtZnVuY3Rpb24vDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9yZmM2NTUxLw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcGttLXJvbGwtbnNhLWV4dGVuc2lvbi8NCg== From nobody Fri Dec 22 01:36:04 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DC91205F0 for ; Fri, 22 Dec 2017 01:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxjxg1zA4JTX for ; Fri, 22 Dec 2017 01:35:59 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863FC120227 for ; Fri, 22 Dec 2017 01:35:59 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 86E07E35F6F39 for ; Fri, 22 Dec 2017 09:35:55 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 22 Dec 2017 09:35:56 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Fri, 22 Dec 2017 17:35:37 +0800 From: "Houjianqiang (Derek)" To: "aris@ariskou.com" , "georgios.papadopoulos@imt-atlantique.fr" CC: roll Thread-Topic: About the flags of metric container in draft-pkm-roll-nsa-extension Thread-Index: AdN7B9o4rCjH+BtCSymcw04SSPKXaA== Date: Fri, 22 Dec 2017 09:35:37 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.224] Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086AB265BDGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] About the flags of metric container in draft-pkm-roll-nsa-extension X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 09:36:02 -0000 --_000_DD0A994E4D6B3F4080662703C8C7C086AB265BDGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Remous-Aris and Georgios, Thanks for bringing your draft "draft-pkm-roll-nsa-extension" into roll WG.= It's a very interesting work and hope it could be adopted in this WG. The recent discussion with Chenyang triggers my interest to read this draft= again. Below are my comments. It seems that your NSA metric is locally used. I mean one node includes its= potential parents into NSA and sends this NSA down to its potential childr= en. If this is correct, then it would be good to specify the parameters use= d in the Metric Container (P,C, O, R ,A, Prec fields). (PS: there are two '= A' and two 'O' bits in Figure 3 of your draft...) I suggest this because I = find that to meet the NSA function you want, we may need to extend the usag= e of Metric defined in RFC6551. What RFC6551 bother me are the 'R' flag and= 'A' field in the MC. When NSA is used as a metric, R=3D1 indicates that th= e NSA is recorded along the path; R=3D0 indicates the NSA metric is aggrega= ted (this aggregation could be additive, multiplicative, reports a maximum = or minimum according to the 'A' field). I suppose the NSA metric requires t= o be used locally, not aggregation or recorded along the path. I guess the = 'P' flag may help to solve this issue or we may need a new flag in the MC t= o indicate a locally used metric. I am involved in draft "Load Balancing Objective Function in RPL" and I hav= e similar concern when setting the flags in the metric container for the pr= oposed Child Node Count (CNC) metric. We also want the CNC to be used local= ly, and it seems we need to extend the current metric usage in RFC6551. The= same requirement may appear in Chenyang's draft "Traffic-aware Objective F= unction". And one more thing. I find with your proposed NSA that includes parent addr= ess(es), we don't need to insert the parent address into our CNC metric. Th= is greatly simplifies our solution. That's good! Best regards, Derek Jianqiang Hou Related drafts: https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ https://datatracker.ietf.org/doc/rfc6551/ https://datatracker.ietf.org/doc/draft-qasem-roll-rpl-load-balancing/ https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-func= tion/ --_000_DD0A994E4D6B3F4080662703C8C7C086AB265BDGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Remous-Aris and Georgios,

 

Thanks for bringing your draft “draft-pkm-roll= -nsa-extension” into roll WG. It’s a very interesting work and = hope it could be adopted in this WG.

 

The recent discussion with Chenyang triggers my inte= rest to read this draft again. Below are my comments.

 

It seems that your NSA metric is locally used. I mea= n one node includes its potential parents into NSA and sends this NSA down = to its potential children. If this is correct, then it would be good to spe= cify the parameters used in the Metric Container (P,C, O, R ,A, Prec fields). (PS: there are two ‘A’ = and two ‘O’ bits in Figure 3 of your draft…) I suggest th= is because I find that to meet the NSA function you want, we may need to ex= tend the usage of Metric defined in RFC6551. What RFC6551 bother me are the ‘R’ flag and ‘A’ field in the MC. When = NSA is used as a metric, R=3D1 indicates that the NSA is recorded along the= path; R=3D0 indicates the NSA metric is aggregated (this aggregation could= be additive, multiplicative, reports a maximum or minimum according to the ‘A’ field). I suppose the NSA metric requires to be use= d locally, not aggregation or recorded along the path. I guess the ‘P= ’ flag may help to solve this issue or we may need a new flag in the = MC to indicate a locally used metric.

 

I am involved in draft “Load Balancing Objecti= ve Function in RPL” and I have similar concern when setting the flags= in the metric container for the proposed Child Node Count (CNC) metric. We= also want the CNC to be used locally, and it seems we need to extend the current metric usage in RFC6551. The same requ= irement may appear in Chenyang’s draft “Traffic-aware Objective= Function”.

 

And one more thing. I find with your proposed NSA th= at includes parent address(es), we don’t need to insert the parent ad= dress into our CNC metric. This greatly simplifies our solution. That’= ;s good!

 

Best regards,

Derek Jianqiang Hou

 

Related drafts:

https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-= extension/

https://datatracker.ietf.org/doc/rfc6551/

https://datatracker.ietf.org/doc/draft-qasem-= roll-rpl-load-balancing/

https://datatracker.ietf.org/doc/d= raft-ji-roll-traffic-aware-objective-function/

 

--_000_DD0A994E4D6B3F4080662703C8C7C086AB265BDGGEMM506MBSchina_-- From nobody Fri Dec 22 17:58:18 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F1B126D05 for ; Fri, 22 Dec 2017 17:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utnKlQBEQapo for ; Fri, 22 Dec 2017 17:58:15 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B43126CD6 for ; Fri, 22 Dec 2017 17:58:15 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3F38A57050969 for ; Sat, 23 Dec 2017 01:58:11 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 23 Dec 2017 01:58:12 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Sat, 23 Dec 2017 09:58:05 +0800 From: "Houjianqiang (Derek)" To: "aris@ariskou.com" , "georgios.papadopoulos@imt-atlantique.fr" CC: roll Thread-Topic: About the flags of metric container in draft-pkm-roll-nsa-extension Thread-Index: AdN7B9o4rCjH+BtCSymcw04SSPKXaAAiKY8w Date: Sat, 23 Dec 2017 01:58:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.224] Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C086AB2A63DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] About the flags of metric container in draft-pkm-roll-nsa-extension X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 01:58:17 -0000 --_000_DD0A994E4D6B3F4080662703C8C7C086AB2A63DGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another idea for your consideration. The "Transit Information" in the DAO O= ption contains parent address(es). What about enabling the use of Transit I= nformation in the DIO Option field? Derek From: Houjianqiang (Derek) Sent: Friday, December 22, 2017 5:35 PM To: 'aris@ariskou.com' ; 'georgios.papadopoulos@imt-atlan= tique.fr' Cc: roll Subject: About the flags of metric container in draft-pkm-roll-nsa-extensio= n Dear Remous-Aris and Georgios, Thanks for bringing your draft "draft-pkm-roll-nsa-extension" into roll WG.= It's a very interesting work and hope it could be adopted in this WG. The recent discussion with Chenyang triggers my interest to read this draft= again. Below are my comments. It seems that your NSA metric is locally used. I mean one node includes its= potential parents into NSA and sends this NSA down to its potential childr= en. If this is correct, then it would be good to specify the parameters use= d in the Metric Container (P,C, O, R ,A, Prec fields). (PS: there are two '= A' and two 'O' bits in Figure 3 of your draft...) I suggest this because I = find that to meet the NSA function you want, we may need to extend the usag= e of Metric defined in RFC6551. What RFC6551 bother me are the 'R' flag and= 'A' field in the MC. When NSA is used as a metric, R=3D1 indicates that th= e NSA is recorded along the path; R=3D0 indicates the NSA metric is aggrega= ted (this aggregation could be additive, multiplicative, reports a maximum = or minimum according to the 'A' field). I suppose the NSA metric requires t= o be used locally, not aggregation or recorded along the path. I guess the = 'P' flag may help to solve this issue or we may need a new flag in the MC t= o indicate a locally used metric. I am involved in draft "Load Balancing Objective Function in RPL" and I hav= e similar concern when setting the flags in the metric container for the pr= oposed Child Node Count (CNC) metric. We also want the CNC to be used local= ly, and it seems we need to extend the current metric usage in RFC6551. The= same requirement may appear in Chenyang's draft "Traffic-aware Objective F= unction". And one more thing. I find with your proposed NSA that includes parent addr= ess(es), we don't need to insert the parent address into our CNC metric. Th= is greatly simplifies our solution. That's good! Best regards, Derek Jianqiang Hou Related drafts: https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ https://datatracker.ietf.org/doc/rfc6551/ https://datatracker.ietf.org/doc/draft-qasem-roll-rpl-load-balancing/ https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-func= tion/ --_000_DD0A994E4D6B3F4080662703C8C7C086AB2A63DGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another idea for your = consideration. The “Transit Information” in the DAO Option cont= ains parent address(es). What about enabling the use of Transit Information= in the DIO Option field?

 

Derek<= /p>

 

From: Houjianqiang (Derek)
Sent: Friday, December 22, 2017 5:35 PM
To: 'aris@ariskou.com' <aris@ariskou.com>; 'georgios.papadopou= los@imt-atlantique.fr' <georgios.papadopoulos@imt-atlantique.fr>
Cc: roll <roll@ietf.org>
Subject: About the flags of metric container in draft-pkm-roll-nsa-e= xtension

 

Dear Remous-Aris and Georgios,

 

Thanks for bringing your draft “draft-pkm-roll= -nsa-extension” into roll WG. It’s a very interesting work and = hope it could be adopted in this WG.

 

The recent discussion with Chenyang triggers my inte= rest to read this draft again. Below are my comments.

 

It seems that your NSA metric is locally used. I mea= n one node includes its potential parents into NSA and sends this NSA down = to its potential children. If this is correct, then it would be good to spe= cify the parameters used in the Metric Container (P,C, O, R ,A, Prec fields). (PS: there are two ‘A’ = and two ‘O’ bits in Figure 3 of your draft…) I suggest th= is because I find that to meet the NSA function you want, we may need to ex= tend the usage of Metric defined in RFC6551. What RFC6551 bother me are the ‘R’ flag and ‘A’ field in the MC. When = NSA is used as a metric, R=3D1 indicates that the NSA is recorded along the= path; R=3D0 indicates the NSA metric is aggregated (this aggregation could= be additive, multiplicative, reports a maximum or minimum according to the ‘A’ field). I suppose the NSA metric requires to be use= d locally, not aggregation or recorded along the path. I guess the ‘P= ’ flag may help to solve this issue or we may need a new flag in the = MC to indicate a locally used metric.

 

I am involved in draft “Load Balancing Objecti= ve Function in RPL” and I have similar concern when setting the flags= in the metric container for the proposed Child Node Count (CNC) metric. We= also want the CNC to be used locally, and it seems we need to extend the current metric usage in RFC6551. The same requ= irement may appear in Chenyang’s draft “Traffic-aware Objective= Function”.

 

And one more thing. I find with your proposed NSA th= at includes parent address(es), we don’t need to insert the parent ad= dress into our CNC metric. This greatly simplifies our solution. That’= ;s good!

 

Best regards,

Derek Jianqiang Hou

 

Related drafts:

https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-= extension/

https://datatracker.ietf.org/doc/rfc6551/

https://datatracker.ietf.org/doc/draft-qasem-= roll-rpl-load-balancing/

https://datatracker.ietf.org/doc/d= raft-ji-roll-traffic-aware-objective-function/

 

--_000_DD0A994E4D6B3F4080662703C8C7C086AB2A63DGGEMM506MBSchina_-- From nobody Sun Dec 24 23:15:10 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2561205F0 for ; Sun, 24 Dec 2017 23:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuZ7LVnKPYnF for ; Sun, 24 Dec 2017 23:15:04 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFC312700F for ; Sun, 24 Dec 2017 23:15:04 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DEAE92CBA6DCE for ; Mon, 25 Dec 2017 07:14:59 +0000 (GMT) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 25 Dec 2017 07:15:01 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Mon, 25 Dec 2017 15:14:49 +0800 From: "Liubing (Remy)" To: "rahul.ietf@gmail.com" , Charlie Perkins CC: "Zhangmingui (Martin)" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] Review of AODV-RPL Thread-Index: AdN9Td6c059QFiwHTnWN9+TD2PcKvA== Date: Mon, 25 Dec 2017 07:14:48 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2EDC9AC0DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Review of AODV-RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 07:15:08 -0000 --_000_BB09947B5326FE42BA3918FA28765C2EDC9AC0DGGEMM506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFodWwsDQoNClBsZWFzZSBmaW5kIG15IGNvbW1lbnRzIGlubGluZS4NCg0KQmVzdCByZWdh cmRzLA0KUmVteQ0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUmFodWwgSmFkaGF2DQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIwLCAy MDE3IDg6MTEgUE0NClRvOiBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxp bmsubmV0PG1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+DQpDYzogUm91dGlu ZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc8bWFpbHRv OnJvbGxAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtSb2xsXSBSZXZpZXcgb2YgQU9EVi1SUEwN Cg0KSGVsbG8gQ2hhcmxpZSwNCg0KUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2UgaW5saW5lLi4NClJl Z2FyZHMsDQpSYWh1bA0KDQpPbiAxNSBEZWNlbWJlciAyMDE3IGF0IDIwOjQ5LCBDaGFybGllIFBl cmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PG1haWx0bzpjaGFybGVzLnBlcmtp bnNAZWFydGhsaW5rLm5ldD4+IHdyb3RlOg0KDQpIZWxsbyBSYWh1bCwNCg0KVGhhbmtzIGZvciB0 aGUgcmV2aWV3ISAgSXQgaXMgbXVjaCBhcHByZWNpYXRlZC4gIEkgaGF2ZSBzb21lIGZvbGxvdy11 cCBiZWxvdy4NCg0KT24gMTEvMTUvMjAxNyA4OjU3IFBNLCBSYWh1bCBKYWRoYXYgd3JvdGU6DQoN CkZvbGxvd2luZyBpcyBteSByZXZpZXcgb2YgQU9EVi1SUEwuDQoNCk9uZSBvZiB0aGUgc3RhdGVk IGdvYWwgb2YgQU9EVi1SUEwgaXMgdG8gY2F0ZXIgdG8gYXN5bW1ldHJpYyBsaW5rcy4gV2hpbGUg dGhpcyBpcyByZWFsbHkgZ3JlYXQgdG8gaGF2ZSwgSSBoYXZlIGRvdWJ0cyB0aGF0IHRoZSBjdXJy ZW50IHNwZWNpZmljYXRpb24gYWNoaWV2ZXMgaXQgaW4gYSBwcmFjdGljYWwgd2F5LiBGb2xsIGlz IHRoZSByZWFzb25pbmc6DQoNCiAgMS4gIFRoZSBNZXNzYWdpbmc6DQoNCkFPRFYtUlBMIHJlcXVp cmVzIHRoYXQgeW91IHNlbmQgYSBtdWx0aWNhc3QgbWVzc2FnZSBmcm9tIE9yaWdOb2RlIHRvIFRh cmdOb2RlIGFuZCByZWFsaXNlIGEgcm91dGluZyBwYXRoIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rp b24uDQoNCkZvciBlLmcuIEEgLT4gQiAtPiBDIC0+IEQsIEEgc2VuZHMgYSBSUkVRLUluc3RhbmNl IG1lc3NhZ2UgdG93YXJkcyBEIGFuZCBub2RlcyBCLEMsRCBlc3RhYmxpc2ggcm91dGluZyBhZGph Y2VuY2llcyBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLiBUaGlzIGtpbmQgb2YgbWVzc2FnaW5n IGlzIHRoZSByZWFzb24gd2h5IFJQTCBkZXBlbmRzIG9uIGJpZGlyZWN0aW9uYWwgbGlua3MgZm9y IGNvbnRyb2wvZGF0YSBwYXRocy4NCg0KSXQncyBub3QganVzdCBSUEwuICBBIGxvdCBvZiBwcm90 b2NvbHMgd29yayB0aGlzIHdheS4NCg0KW1JKXSBCdXQgdGhpcyBtb2RlIG9mIHNpZ25hbGluZyBk b2VzIG5vdCBoZWxwIHNhdGlzZnkgdGhlIHN0YXRlZCBnb2FsIG9mIGVzdGFibGlzaGluZyBhc3lt bWV0cmljIGxpbmtzLiBSUEwgKGFuZCBvdGhlcnMgbGlrZSBwMnAtcnBsKSBmb2xsb3dzIHRoaXMg bW9kZSBvZiBzaWduYWxpbmcgYW5kIGhlbmNlIGRlcGVuZCBvbiBiaWRpcmVjdGlvbmFsIGxpbmtz Lg0KW1JlbXldIEkgdGhpbmsgd2UgaGF2ZSBhIG1pc3VuZGVyc3RhbmRpbmcgaGVyZS4g4oCcQmlk aXJlY3Rpb25hbOKAnSB0YWxrcyBhYm91dCB0aGUgcmVhY2hhYmlsaXR5LCB3aGlsZSDigJxzeW1t ZXRyaWPigJ0gdGFsa3MgYWJvdXQgdGhlIHVwd2FyZCBhbmQgZG93bndhcmQgcm91dGVzLiBUaGUg 4oCcYXN5bW1ldHJpY+KAnSBoZXJlIHNpZ25pZmllcyB0aGUgdXB3YXJkIGFuZCBkb3dud2FyZCBy b3V0ZXMgYmV0d2VlbiB0aGUgT3JpZ05vZGUgYW5kIHRoZSBUYXJnTm9kZSBhcmUgZGlmZmVyZW50 LCB3aGlsZSAiYmlkaXJlY3Rpb25hbCIgbWVhbnMgY29udHJvbCBtZXNzYWdlcyBjYW4gYmUgcmVj ZWl2ZWQgaW4gdHdvIGRpcmVjdGlvbnMuIEJvdGggUlBMIGFuZCBBT0RWLVJQTCB1c2UgYmlkaXJl Y3Rpb25hbCBsaW5rcy4NCg0KMi4gVGhlIEFzc3VtcHRpb25zOg0KDQphLiBRdW90aW5nIGRyYWZ0 LA0KDQrigJxFYWNoIGludGVybWVkaWF0ZSBub2RlIFJfaSBjb21wdXRlcyB0aGUgcmFuayBmb3Ig UlJFUS1JbnN0YW5jZSBhbmQgY3JlYXRlcyBhIHJvdXRpbmcgdGFibGUgZW50cnkgZm9yIHRoZSB1 cHN0cmVhbSByb3V0ZSB0b3dhcmRzIHRoZSBzb3VyY2UgaWYgdGhlIHJvdXRpbmcgbWV0cmljcy9j b25zdHJhaW50cyBhcmUgc2F0aXNmaWVkLiAgRm9yIHRoaXMgcHVycG9zZSBSX2kgKioqbXVzdCB1 c2UgdGhlIGFzeW1tZXRyaWMgbGluayBtZXRyaWMgbWVhc3VyZWQgaW4gdGhlIHVwc3RyZWFtIGRp cmVjdGlvbioqKiwgZnJvbSBSX2kgdG8gaXRzIHVwc3RyZWFtIG5laWdoYm9yIHRoYXQgbXVsdGlj YXN0ZWQgdGhlIFJSRVEtSW5zdGFuY2UgbWVzc2FnZS7igJ0NCg0KVGhpcyBpcyB0aGUgcHJpbWFy eSBhc3N1bXB0aW9uIHdoaWNoIGFjaGlldmVzIGFzeW1tZXRyaWMgYmVoYXZpb3VyLiBCdXQgaXTi gJlzIGFuIGltcGxlbWVudGF0aW9uIG5pZ2h0bWFyZSB0byBkbyB0aGlzIG1lYXN1cmVtZW50IGVz cGVjaWFsbHkgYmVjYXVzZSB3ZSBkbyBub3Qga25vdyB3aGljaCBuZWlnaGJvdXIgd2UgbWlnaHQg ZW5kIHVwIHRpZWluZyB1cCB3aXRoICh0aHVzIG5lZWQgdG8gcHJvYmUgYWxsIG5laWdoYm91cnMp Lg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgdHJ1ZS4gIEEgbm9kZSBzaW1wbHkgaGFzIHRvIGtl ZXAgdHJhY2sgb2YgdGhlIGluZm9ybWF0aW9uIGZvciB0aGUgdXBzdHJlYW0gZGVzdGluYXRpb24s IGFuZCB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNwZWNpZmljIG5vZGUgZnJvbSB3aGljaCB0 aGUgUlJFUSB3YXMgcmVjZWl2ZWQuDQoNCltSSl0gQXNzdW1pbmcgYSBtb2RlcmF0ZWx5IHBvcHVs YXRlZCBob3AsIGEgbm9kZSBub3cgbmVlZHMgdG8ga2VlcCB0cmFjayBvZiBpbmZvcm1hdGlvbiBp biBjb250ZXh0IGFsbCB0aGUgcGVlcnMgb24gdGhlIHNhbWUgaG9wLiBZb3UgbWVudGlvbmVkLCAn bm9kZSBuZWVkcyB0byB0cmFjayBvbmx5IHVwc3RyZWFtIGRlc3RpbmF0aW9uJyAuLi4gYnV0IGlt byB0aGlzIGlzIG5vdCB0cnVlLiBGb3IgUDJQIHBhdGhzLCBpdHMgYSBkaWZmZXJlbnQgREFHIGlu c3RhbmNlIGFuZCB0aHVzIHRoZXJlIGFyZSBubyBwcmUtZGV0ZXJtaW5lZCAqdXBzdHJlYW0gZGVz dGluYXRpb25zKi4NCltSZW15XSBUaGUgdXBzdHJlYW0gZGVzdGluYXRpb24gaXMgdGhlIE9yaWdO b2RlLCB3aGljaCBpcyB0aGUgcm9vdCBvZiB0aGUgRE9EQUcuIEFuIGludGVybWVkaWF0ZSBub2Rl IG9ubHkgbmVlZHMgdG8gbWFpbnRhaW4gYSByb3V0ZSBlbnRyeSB0byB0aGUgT3JpZ05vZGUsIGlu Y2x1ZGluZyB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIG5leHQgaG9wIG9uIHRoZSB1cHN0cmVhbSBy b3V0ZS4gVGhlIG5leHQgaG9wIGlzIGFjdHVhbGx5IHRoZSBub2Rl4oCZcyBwcmVmZXJyZWQgcGFy ZW50IGluIHRoaXMgRE9EQUcuDQoNCg0KSXQgd2lsbCBhZGQgdXAgc28gbXVjaCB0byB0aGUgY29u dHJvbCBvdmVyaGVhZCBhbmQgYWxzbyByZXF1aXJlcyAoYSBnb29kIGRlYWwgb2YpIHN0YXRlIGlu Zm8gdG8gYmUgbWFpbnRhaW5lZCBvbiBiZWhhbGYgb2YgdGhlIG5laWdoYm91cmluZyBub2Rlcy4N Cg0KSSBkb24ndCBzZWUgd2h5IGl0IGFkZHMgbXVjaCB0byB0aGUgY29udHJvbCBvdmVyaGVhZC4g IFRoZSBzdGF0ZSBjYW4gYmUgdGltZWQgb3V0IGFmdGVyIGEgcmVsYXRpdmVseSBzbWFsbCBkdXJh dGlvbiBvZiB0aW1lLiAgV2Ugd2lsbCBhZGQgdGhhdCB0aW1lb3V0IHBhcmFtZXRlciBmb3IgdGhl IG5leHQgcmV2aXNpb24uDQoNCltSSl0gVGhlIHJlYXNvbiBmb3IgaGlnaCBjb250cm9sIG92ZXJo ZWFkIGlzIHRoYXQgdGhlIG5vZGUgd2lsbCBoYXZlIHRvIGtlZXAgcHJvYmluZyB0aGUgbmVpZ2hi b3JzIHRvIG1haW50YWluIHN0YXRlLiBUaGUgcHJvYmxlbSB3aXRoIHNtYWxsZXIgZHVyYXRpb24g dGltZSBpcyB0aGF0IHRoZSBwcm9iZSB3aWxsIGJlIG1vcmUgZnJlcXVlbnQhIFJlZ2FyZGxlc3Ms IHRoZSB0YWJsZSB0aGF0IG5lZWRzIHRvIGJlIG1haW50YWluZWQgZm9yIHN1Y2ggaW5mb3JtYXRp b24gaXMgZGlyZWN0bHkgcHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2YgbmVpZ2hib3Jpbmcg cGVlcnMuDQpbUmVteV0gVGhlIG5vZGUgZG9lc27igJl0IGhhdmUgdG8gcHJvYmUgYWxsIGl0cyBu ZWlnaGJvci4gRG9u4oCZdCBmb3JnZXQgdGhhdCBBT0RWLVJQTCBpcyBhbiBleHRlbnNpb24gb2Yg UlBMLCBhbmQgdGhlIFJSRVAgYW5kIFJSRVEgYXJlIHR3byBuZXcgRElPIG9wdGlvbnMuIFRodXMg dGhlIERJTyB0cmFuc21pc3Npb24sIGxvY2FsIHJlcGFpciBhbmQgbWFueSBvdGhlciBtZWNoYW5p c21zIHRvIG1haW50YWluIHRoZSBzdGF0ZSBhcmUgdGhlIHNhbWUgYXMgUlBMLiAgVGhlcmVmb3Jl LCB0aGUgY29udHJvbCBvdmVyaGVhZCB3aWxsIHN0YXkgdGhlIHNhbWUuDQoNCg0KDQoNCg0KDQpB bnl3YXlzIGkgdHJpZWQgdG8gc2VhcmNoIGZvciB5b3VyIGltcGxlbWVudGF0aW9uIHRvIGNoZWNr IG9uIHRoaXMgYnV0IGkgY291bGQgbm90IGZpbmQgaXQuDQoNCmIuIFVzZSBvZiBwYXN0IGNvbmRp dGlvbnMgdG8gc3VnZ2VzdCBmdXR1cmUgdHJhZmZpYyBwYXRoIHNlbGVjdGlvbjoNCg0K4oCcSWYg dGhlIFJSRVEtSW5zdGFuY2UgYXJyaXZlcyBvdmVyIGFuIGludGVyZmFjZSB0aGF0IGlzIG5vdCBr bm93biB0byBiZSBzeW1tZXRyaWMsIG9yIGlzIGtub3duIHRvIGJlIGFzeW1tZXRyaWMsIHRoZSAn UycgYml0IGlzIHNldCB0byBiZSAwLuKAnQ0KDQpUaGlzIGlzIGEgdHlwaWNhbCBwcm9ibGVtIHdl IGZhY2UgYXMgd2VsbC4gUHJvYmluZyBmb3IgbWVhc3VyZW1lbnRzIGF0IHN1Y2ggc2NhbGUgKGFs bCBuZWlnaGJvdXJzKSBpcyBhIHByb2JsZW0uIElmIHlvdSBkbyB0aGUgcHJvYmluZyBzcGFyc2Vs eSwgdGhlIG5ldHdvcmsgY29uZGl0aW9ucyBtaWdodCBoYXZlIGNoYW5nZWQgd2hlbiB5b3Ugd2Fu dCB0byB1c2UgdGhlIG1lYXN1cmVtZW50cy4NCg0KWWVzLCB0aGlzIGlzIG5hdHVyYWxseSBhIHBy b2JsZW0gaW4gZHluYW1pYyBuZXR3b3Jrcy4gIFdlIGNhbid0IHByZWRpY3QgdGhlIGZ1dHVyZSwg c28gd2UgYXJlIHN0dWNrIHdpdGggcmVjb3JkaW5nIHNhbGllbnQgYXNwZWN0cyBvZiB0aGUgcGFz dC4gIE5vIG1hdHRlciBob3cgb2Z0ZW4gd2UgbWVhc3VyZSwgaXQgaXMgZ3VhcmFudGVlZCB0byBi ZSB3cm9uZyBzb21lIChvciBtb3N0ISkgb2YgdGhlIHRpbWUgaW4gdGhlIGZ1dHVyZS4gIEFuZCB5 ZXQgd2UgcGVyc2lzdC4NCg0KQnV0IHdlIGRvIG5vdCByZXF1aXJlIHBlcmlvZGljIG9yIGV4aGF1 c3RpdmUgbWVhc3VyZW1lbnRzIGZvciBhbGwgbmVpZ2hib3JzIC0tIG9ubHkgYXMgbmVlZGVkIGZv ciB0aGUgcHJvdG9jb2wgdG8gd29yay4NCg0KW1JKXSBNYXkgYmUgdGhpcyBpcyB0aGUgcGFydCBp IGRvbid0IGdldCAuLi4gWW91IG1lbnRpb25lZCAib25seSBhcyBuZWVkZWQgZm9yIHRoZSBwcm90 b2NvbCB0byB3b3JrIiAuLi4gQ2FuIHRoaXMgYmUgZWxhYm9yYXRlZD8NCltSZW15XSBBZ2Fpbiwg aXQgaXMgc3RpbGwgaW4gdGhlIGZyYW1ld29yayBvZiBSUEwsIHNvIHRoZSBwcm9iaW5nIGlzIGRv bmUgaW4gdGhlIHNhbWUgd2F5IGFzIFJQTCwgaS5lLiBieSBESU8gYW5kIERJUywgd2hpY2ggYXJl IGNvbnRyb2xsZWQgYnkgdGhlIHRyaWNrbGUgdGltZXIuDQoNCg0KDQoNCk90aGVyIHBvaW50czoN Cg0KICAxLiAgVXNlIG9mIG9kZC9ldmVuIG51bWJlcnMgZm9yIHBhaXJpbmcgaW5zdGFuY2VzIG1h eSBub3QgYmUgYSByb2J1c3Qgd2F5IG9mIHBhaXJpbmcg4oCmIFRoZXJlIGNvdWxkIGJlIHJhY2Ug Y29uZGl0aW9ucyB3aGVyZSBvdGhlciBQMlAtUlBMIGluc3RhbmNlcyBvciBmbG9hdGluZyBET0RB RyBpbnN0YW5jZXMgZW5kIHVwIHVzaW5nIG9uZSBvZiB0aGUgc2FtZSB2YWx1ZSBpbiB0aGUgaW5z dGFuY2UtaWQgcGFpci4gSG93IHRvIHJlc29sdmUgc3VjaCBjb2xsaXNpb24/DQoNCkJ1dCwgdGhl IGluc3RhbmNlLWlkcyBhcmUgbG9jYWwuICBTbyBpZiB0d28gZGlmZmVyZW50IG5vZGVzIHVzZSB0 aGUgc2FtZSBJRCB0aGF0IGlzIE8uSy4gIElmIHRob3NlIHR3byBub2RlcyBuZWVkIHRvIGhhdmUg YSBwZWVyLXRvLXBlZXIgcm91dGUgdG8gdGhlIHNhbWUgZGVzdGluYXRpb24sIHRoYXQgaXMgc3Rp bGwgTy5LLiwgYnV0IHRoZSBSUkVQIHNlbnQgYmFjayB0byBvbmUgb2YgdGhlIHNvdXJjZSBub2Rl cyB3aWxsIGJlIGFibGUgdG8gdXNlIHRoZSBwYWlyZWQgaW5zdGFuY2UtSUQgYW5kIHRoZSBzdHJl YW1saW5lZCBSUkVQLCBhbmQgdGhlIG90aGVyIFJSRVAgd2lsbCBoYXZlIHRvIGluY2x1ZGUgYW4g dW5wYWlyZWQgaW5zdGFuY2UtSUQgYWxvbmcgd2l0aCB0aGUgSVB2NiBhZGRyZXNzIG9mIHRoZSB0 YXJnZXQgbm9kZS4gIFRoYXQgd2lsbCBiZSBhIHJhcmUgb2NjdXJyZW5jZSwgYW5kIHNvIHRoZSBv cHRpbWl6YXRpb24gb2YgZWxpZGluZyB0aGUgSVB2NiBhZGRyZXNzICB3aWxsIHVzdWFsbHkgYmUg cG9zc2libGUuDQoNCltSSl0gWWVhaCwgZm9yIGxvY2FsIGluc3RhbmNlcyB0aGlzIG1pZ2h0IG5v dCBiZSBhIHByb2JsZW0uIFRoYW5rcy4NCg0KDQogIDEuICBJIHdvdWxkIHJlY29tbWVuZCB0byB1 c2UgQ29vamEgd2l0aCBsaW5rcyBpbiBER1JNIG1vZGUgdG8gZXZhbHVhdGUgdGhlIHBlcmYuDQoN ClRoaXMgc291bmRzIGxpa2UgYSBnb29kIGlkZWEuICBUaGUgb3RoZXIgY28tYXV0aG9ycyB3aWxs IHByb2JhYmx5IGhhdmUgbW9yZSBmb2xsb3ctdXAgYWJvdXQgdGhpcy4NCg0KDQogIDEuICBUaGUg UlNTSSB2YWx1ZXMgaW4gdGhlIEFwcGVuZGl4IGRvIG5vdCBsb29rIGNvcnJlY3QuIEFuIFJTU0kg b2YgPC03MGRibSBpcyB0b28gZ29vZCBbMV0gdG8gaGF2ZSBmb3IgZ29vZCBQRFIuIFRoZSBtYXBw aW5nIG9mIFJTU0ktRVRYIGluIHRoZSBhcHBlbmRpeCBoZW5jZSBtYXkgbm90IGJlIGNvcnJlY3Qg KGkgYmVsaWV2ZSB0aGVzZSB2YWx1ZXMgYXJlIGZyb20gQ29vamEpLg0KDQpJIGRvbid0IHVuZGVy c3RhbmQgaG93IGFuIFJTU0kgY291bGQgYmUgInRvbyBnb29kIiwgdW5sZXNzIHlvdSBtZWFuIHRo YXQgdGhlIHBvd2VyIGxldmVsIGlzIHRvbyBoaWdoIGFuZCBjYXVzZXMgd2lkZXNwcmVhZCBpbnRl cmZlcmVuY2UuICBBZG1pdHRlZGx5LCBJIGFtIG5vIGV4cGVydCBpbiBpbnRlcnByZXRpbmcgUEhZ IGxheWVyIGVmZmVjdHMsIGJ1dCBhbnl3YXkgdXN1YWxseSBoaWdoZXIgcmVjZWl2ZWQgcG93ZXIg YWxsb3dzIG1vcmUgYWNjdXJhdGUgZGV0ZWN0aW9uLCBpZiB0aGUgYmFja2dyb3VuZCBub2lzZSBs ZXZlbCByZW1haW5zIHRoZSBzYW1lLg0KDQpbUkpdIE15IHJlZmVyZW5jZSBoZXJlIGlzIHRvIHRo ZSBSU1NJIHRvIEVUWCBtYXBwaW5nIHRhYmxlIGluIHRoZSBkcmFmdC4gVGhlIHZhbHVlcyBub3Rl ZCBpbiB0aGF0IHRhYmxlIGRvIG5vdCBsb29rIGNvcnJlY3QuIEZvciBSU1NJIC01NSB0byAtNDVk Ym0sIHRoZSBleHBlY3RlZCBFVFggaXMgOTkzLiBPbiB3aGF0IGJhc2lzIHdhcyB0aGlzIHRhYmxl IGdlbmVyYXRlZCA/IFR5cGljYWxseSBpIGhhdmUgZm91bmQgdGhhdCBSU1NJIG9mIDwgLTgwZGJt IHJlc3VsdHMgaW4gdmVyeSBnb29kIFBEUnMgKGFsc28gdGhlIHJlZiBpIGF0dGFjaGVkIHNheXMg dGhlIHNhbWUpLg0KDQoNCg0KDQoNClsxXSAgUlNTSSBpcyBVbmRlci1BcHByZWNpYXRlZCBodHRw czovL3Npbmcuc3RhbmZvcmQuZWR1L3NpdGUvcHVibGljYXRpb25zL2VtbmV0czIwMDZzcmluaXZh c2FuLnBkZg0KDQpUaGFua3MgZm9yIHRoZSBsaW5rLiAgSSByZWFkIHRocm91Z2ggaXQgdmVyeSBi cmllZmx5IG9uIHRoaXMgZmluZSBtb3JuaW5nLiAgSG93ZXZlciwgSSBoYXZlIGFsc28gcmVhZCBv dGhlciBwYXBlcnMgdGhhdCBzZXJpb3VzbHkgcXVlc3Rpb24gdGhlIHZhbHVlIG9mIHJlbHlpbmcg b24gUlNTSS4NCkknbGwgdHJ5IHRvIHJlbWVtYmVyIGFuZCBmaW5kIG9uZSBmb3IgZnVydGhlciBk aXNjdXNzaW9uLiBOb3RhYmx5LCB0aGUgYXV0aG9ycyBzZWVtIHRvIGZvY3VzIG9uIHBhcnRpY3Vs YXIgaGFyZHdhcmUsIGFuZCBhIHNpbmdsZSBsaW5rIGJldHdlZW4gdHdvIG5laWdoYm9ycywgZm9y IHRoZWlyIGRpc2N1c3Npb24sIHVubGVzcyBJIG1pc3NlZCBzb21ldGhpbmcuDQoNCltSSl0gVGhl IGF1dGhvcnMgaGF2ZSBub3QgbWVyZWx5IGZvY3VzZWQgb24gc2luZ2xlIGxpbmsgYmV0d2VlbiB0 d28gbmVpZ2hib3JzLiBUaGUgc2xpZGVzIG9mIHRoZSBwYXBlci10YWxrIGdpdmVzIGEgYmV0dGVy IHBpY3R1cmUsIGh0dHBzOi8vc2luZy5zdGFuZm9yZC5lZHUvc2l0ZS90YWxrcy9lbW5ldHMyMDA2 c3Jpbml2YXNhbi5wcHQNCg0KDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg== --_000_BB09947B5326FE42BA3918FA28765C2EDC9AC0DGGEMM506MBSchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5nbWFpbC1tLTkxMDgzNDQyNjAyNTUzNzg5OTBtLTMxMDMw MzUwNTYzNjUwMjEwM20yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1wMSwgbGkuZ21haWwtbS05MTA4 MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21h aWwtcDEsIGRpdi5nbWFpbC1tLTkxMDgzNDQyNjAyNTUzNzg5OTBtLTMxMDMwMzUwNTYzNjUwMjEw M20yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1wMQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy05 MTA4MzQ0MjYwMjU1Mzc4OTkwbV8tMzEwMzAzNTA1NjM2NTAyMTAzbV8yNzMwNzcwMzM1MDU5NTE5 NTVnbWFpbC1wMTsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLmdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEw MzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLXAyLCBsaS5nbWFpbC1tLTkx MDgzNDQyNjAyNTUzNzg5OTBtLTMxMDMwMzUwNTYzNjUwMjEwM20yNzMwNzcwMzM1MDU5NTE5NTVn bWFpbC1wMiwgZGl2LmdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAy MTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLXAyDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1f LTkxMDgzNDQyNjAyNTUzNzg5OTBtXy0zMTAzMDM1MDU2MzY1MDIxMDNtXzI3MzA3NzAzMzUwNTk1 MTk1NWdtYWlsLXAyOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0z MTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDMsIGxpLmdtYWlsLW0t OTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1 NWdtYWlsLXAzLCBkaXYuZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1 MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDMNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwt bV8tOTEwODM0NDI2MDI1NTM3ODk5MG1fLTMxMDMwMzUwNTYzNjUwMjEwM21fMjczMDc3MDMzNTA1 OTUxOTU1Z21haWwtcDM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5nbWFpbC1tLTkxMDgzNDQyNjAyNTUzNzg5 OTBtLTMxMDMwMzUwNTYzNjUwMjEwM20yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tOTEwODM0NDI2MDI1NTM3ODk5 MG1fLTMxMDMwMzUwNTYzNjUwMjEwM21fMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtYXBwbGUtY29u dmVydGVkLXNwYWNlO30NCnNwYW4uZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1 MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtYXBwbGUtdGFiLXNwYW4NCgl7bXNv LXN0eWxlLW5hbWU6Z21haWwtbV8tOTEwODM0NDI2MDI1NTM3ODk5MG1fLTMxMDMwMzUwNTYzNjUw MjEwM21fMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtYXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5nbWFp bC1tLTkxMDgzNDQyNjAyNTUzNzg5OTBtLTMxMDMwMzUwNTYzNjUwMjEwM20yNzMwNzcwMzM1MDU5 NTE5NTVnbWFpbC1zMQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy05MTA4MzQ0MjYwMjU1Mzc4 OTkwbV8tMzEwMzAzNTA1NjM2NTAyMTAzbV8yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1zMTt9DQpz cGFuLmdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3 NzAzMzUwNTk1MTk1NWdtYWlsLXMyDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTkxMDgzNDQy NjAyNTUzNzg5OTBtXy0zMTAzMDM1MDU2MzY1MDIxMDNtXzI3MzA3NzAzMzUwNTk1MTk1NWdtYWls LXMyO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODg4ODc4ODg7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjg5MjYyOTQwMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NjQwNDI5NjkxOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTA2MTkyOTEzMDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTA1NzExOTc3MTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTEyNjU5OTAxMjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTg2OTAyODMzMDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6NjM0NTQ1MzQ0O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVs Ng0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC10 YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFJhaHVsLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGZpbmQgbXkgY29tbWVudHMgaW5s aW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZW15PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9sbCBbPGEgaHJlZj0ibWFp bHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJhaHVsIEphZGhhdjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIERlY2VtYmVyIDIwLCAyMDE3IDg6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IENoYXJs aWUgUGVya2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsu bmV0Ij5jaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1JvbGxdIFJldmlldyBvZiBBT0RWLVJQTDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIENo YXJsaWUsIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlBsZWFzZSBmaW5kIG15IHJlc3BvbnNl IGlubGluZS4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhaHVs PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTUgRGVjZW1iZXIgMjAx NyBhdCAyMDo0OSwgQ2hhcmxpZSBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y2hhcmxlcy5w ZXJraW5zQGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5rIj5jaGFybGVzLnBlcmtpbnNAZWFy dGhsaW5rLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+SGVsbG8gUmFodWws PG86cD48L286cD48L3A+DQo8cD5UaGFua3MgZm9yIHRoZSByZXZpZXchJm5ic3A7IEl0IGlzIG11 Y2ggYXBwcmVjaWF0ZWQuJm5ic3A7IEkgaGF2ZSBzb21lIGZvbGxvdy11cCBiZWxvdy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDExLzE1LzIwMTcgODo1NyBQTSwgUmFodWwgSmFk aGF2IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iZ21h aWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1 OTUxOTU1Z21haWwtcDEiPg0KRm9sbG93aW5nIGlzIG15IHJldmlldyBvZiBBT0RWLVJQTC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTkxMDgzNDQyNjAyNTUzNzg5OTBtLTMxMDMw MzUwNTYzNjUwMjEwM20yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1wMSI+DQpPbmUgb2YgdGhlIHN0 YXRlZCBnb2FsIG9mIEFPRFYtUlBMIGlzIHRvIGNhdGVyIHRvIGFzeW1tZXRyaWMgbGlua3MuIFdo aWxlIHRoaXMgaXMgcmVhbGx5IGdyZWF0IHRvIGhhdmUsIEkgaGF2ZSBkb3VidHMgdGhhdCB0aGUg Y3VycmVudCBzcGVjaWZpY2F0aW9uIGFjaGlldmVzIGl0IGluIGEgcHJhY3RpY2FsIHdheS4gRm9s bCBpcyB0aGUgcmVhc29uaW5nOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIx Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPg0KVGhl IE1lc3NhZ2luZzo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iZ21haWwt bS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUx OTU1Z21haWwtcDEiPg0KQU9EVi1SUEwgcmVxdWlyZXMgdGhhdCB5b3Ugc2VuZCBhIG11bHRpY2Fz dCBtZXNzYWdlIGZyb20gT3JpZ05vZGUgdG8gVGFyZ05vZGUgYW5kIHJlYWxpc2UgYSByb3V0aW5n IHBhdGggaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbi48c3BhbiBjbGFzcz0iZ21haWwtbS05MTA4 MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21h aWwtYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNt MjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDEiPg0KRm9yIGUuZy4gQSAtJmd0OyBCIC0mZ3Q7IEMg LSZndDsgRCwgQSBzZW5kcyBhIFJSRVEtSW5zdGFuY2UgbWVzc2FnZSB0b3dhcmRzIEQgYW5kIG5v ZGVzIEIsQyxEIGVzdGFibGlzaCByb3V0aW5nIGFkamFjZW5jaWVzIGluIHRoZSBvcHBvc2l0ZSBk aXJlY3Rpb24uIFRoaXMga2luZCBvZiBtZXNzYWdpbmcgaXMgdGhlIHJlYXNvbiB3aHkgUlBMIGRl cGVuZHMgb24gYmlkaXJlY3Rpb25hbCBsaW5rcyBmb3IgY29udHJvbC9kYXRhIHBhdGhzLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpJdCdzIG5vdCBqdXN0IFJQTC4mbmJzcDsgQSBsb3Qgb2YgcHJv dG9jb2xzIHdvcmsgdGhpcyB3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltSSl0gQnV0IHRoaXMgbW9kZSBvZiBz aWduYWxpbmcgZG9lcyBub3QgaGVscCBzYXRpc2Z5IHRoZSBzdGF0ZWQgZ29hbCBvZiBlc3RhYmxp c2hpbmcgYXN5bW1ldHJpYyBsaW5rcy4gUlBMIChhbmQgb3RoZXJzIGxpa2UgcDJwLXJwbCkgZm9s bG93cyB0aGlzIG1vZGUgb2Ygc2lnbmFsaW5nIGFuZCBoZW5jZSBkZXBlbmQgb24gYmlkaXJlY3Rp b25hbCBsaW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPltSZW15XSBJIHRoaW5rIHdlIGhhdmUgYSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuIOKA nEJpZGlyZWN0aW9uYWzigJ0gdGFsa3MgYWJvdXQgdGhlIHJlYWNoYWJpbGl0eSwgd2hpbGUg4oCc c3ltbWV0cmlj4oCdIHRhbGtzIGFib3V0IHRoZSB1cHdhcmQgYW5kIGRvd253YXJkIHJvdXRlcy4g VGhlIOKAnGFzeW1tZXRyaWPigJ0gaGVyZSBzaWduaWZpZXMgdGhlIHVwd2FyZCBhbmQgZG93bndh cmQgcm91dGVzIGJldHdlZW4gdGhlIE9yaWdOb2RlDQogYW5kIHRoZSBUYXJnTm9kZSBhcmUgZGlm ZmVyZW50LCB3aGlsZSAmcXVvdDtiaWRpcmVjdGlvbmFsJnF1b3Q7IG1lYW5zIGNvbnRyb2wgbWVz c2FnZXMgY2FuIGJlIHJlY2VpdmVkIGluIHR3byBkaXJlY3Rpb25zLiBCb3RoIFJQTCBhbmQgQU9E Vi1SUEwgdXNlIGJpZGlyZWN0aW9uYWwgbGlua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Imdt YWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUw NTk1MTk1NWdtYWlsLXAxIj4NCjIuIFRoZSBBc3N1bXB0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNv bG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkw bS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDEiPg0KYS4gUXVv dGluZyBkcmFmdCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IiPg0KPHAgY2xhc3M9ImdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2 NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLXAxIj4NCuKAnEVhY2ggaW50ZXJtZWRpYXRl IG5vZGUgUl9pIGNvbXB1dGVzIHRoZSByYW5rIGZvciBSUkVRLUluc3RhbmNlIGFuZCBjcmVhdGVz IGEgcm91dGluZyB0YWJsZSBlbnRyeSBmb3IgdGhlIHVwc3RyZWFtIHJvdXRlIHRvd2FyZHMgdGhl PHNwYW4gY2xhc3M9ImdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAy MTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLWFwcGxlLXRhYi1zcGFuIj4mbmJzcDs8L3NwYW4+ c291cmNlIGlmIHRoZSByb3V0aW5nDQogbWV0cmljcy9jb25zdHJhaW50cyBhcmUgc2F0aXNmaWVk LjxzcGFuIGNsYXNzPSJnbWFpbC1tLTkxMDgzNDQyNjAyNTUzNzg5OTBtLTMxMDMwMzUwNTYzNjUw MjEwM20yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1hcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ow0KPC9zcGFuPkZvciB0aGlzIHB1cnBvc2UgUl9pICoqKm11c3QgdXNlIHRoZSBhc3ltbWV0cmlj IGxpbmsgbWV0cmljIG1lYXN1cmVkIGluIHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24qKiosIGZyb20g Ul9pIHRvIGl0cyB1cHN0cmVhbSBuZWlnaGJvciB0aGF0IG11bHRpY2FzdGVkIHRoZSBSUkVRLUlu c3RhbmNlIG1lc3NhZ2Uu4oCdPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpj dXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9ImdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEw MzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLXAxIj4NClRoaXMgaXMgdGhl IHByaW1hcnkgYXNzdW1wdGlvbiB3aGljaCBhY2hpZXZlcyBhc3ltbWV0cmljIGJlaGF2aW91ci4g QnV0IGl04oCZcyBhbiBpbXBsZW1lbnRhdGlvbiBuaWdodG1hcmUgdG8gZG8gdGhpcyBtZWFzdXJl bWVudCBlc3BlY2lhbGx5IGJlY2F1c2Ugd2UgZG8gbm90IGtub3cgd2hpY2ggbmVpZ2hib3VyIHdl IG1pZ2h0IGVuZCB1cCB0aWVpbmcgdXAgd2l0aCAodGh1cyBuZWVkIHRvIHByb2JlIGFsbCBuZWln aGJvdXJzKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSBkb24ndCB0aGluayB0aGlzIGlzIHRy dWUuJm5ic3A7IEEgbm9kZSBzaW1wbHkgaGFzIHRvIGtlZXAgdHJhY2sgb2YgdGhlIGluZm9ybWF0 aW9uIGZvciB0aGUgdXBzdHJlYW0gZGVzdGluYXRpb24sIGFuZCB0aGUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHNwZWNpZmljIG5vZGUgZnJvbSB3aGljaCB0aGUgUlJFUSB3YXMgcmVjZWl2ZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPltSSl0gQXNzdW1pbmcgYSBtb2RlcmF0ZWx5IHBvcHVsYXRlZCBob3AsIGEgbm9k ZSBub3cgbmVlZHMgdG8ga2VlcCB0cmFjayBvZiBpbmZvcm1hdGlvbiBpbiBjb250ZXh0IGFsbCB0 aGUgcGVlcnMgb24gdGhlIHNhbWUgaG9wLiBZb3UgbWVudGlvbmVkLCAnbm9kZSBuZWVkcyB0byB0 cmFjayBvbmx5IHVwc3RyZWFtIGRlc3RpbmF0aW9uJyAuLi4gYnV0IGltbyB0aGlzIGlzIG5vdCB0 cnVlLiBGb3IgUDJQIHBhdGhzLA0KIGl0cyBhIGRpZmZlcmVudCBEQUcgaW5zdGFuY2UgYW5kIHRo dXMgdGhlcmUgYXJlIG5vIHByZS1kZXRlcm1pbmVkICp1cHN0cmVhbSBkZXN0aW5hdGlvbnMqLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltSZW15XSBUaGUgdXBzdHJlYW0gZGVzdGluYXRpb24g aXMgdGhlIE9yaWdOb2RlLCB3aGljaCBpcyB0aGUgcm9vdCBvZiB0aGUgRE9EQUcuIEFuIGludGVy bWVkaWF0ZSBub2RlIG9ubHkgbmVlZHMgdG8gbWFpbnRhaW4gYSByb3V0ZSBlbnRyeSB0byB0aGUg T3JpZ05vZGUsIGluY2x1ZGluZyB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIG5leHQgaG9wIG9uIHRo ZQ0KIHVwc3RyZWFtIHJvdXRlLiBUaGUgbmV4dCBob3AgaXMgYWN0dWFsbHkgdGhlIG5vZGXigJlz IHByZWZlcnJlZCBwYXJlbnQgaW4gdGhpcyBET0RBRy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iZ21haWwt bS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUx OTU1Z21haWwtcDEiPg0KSXQgd2lsbCBhZGQgdXAgc28gbXVjaCB0byB0aGUgY29udHJvbCBvdmVy aGVhZCBhbmQgYWxzbyByZXF1aXJlcyAoYSBnb29kIGRlYWwgb2YpIHN0YXRlIGluZm8gdG8gYmUg bWFpbnRhaW5lZCBvbiBiZWhhbGYgb2YgdGhlIG5laWdoYm91cmluZyBub2Rlcy48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KSSBkb24ndCBzZWUgd2h5IGl0IGFkZHMgbXVjaCB0byB0aGUgY29udHJv bCBvdmVyaGVhZC4mbmJzcDsgVGhlIHN0YXRlIGNhbiBiZSB0aW1lZCBvdXQgYWZ0ZXIgYSByZWxh dGl2ZWx5IHNtYWxsIGR1cmF0aW9uIG9mIHRpbWUuJm5ic3A7IFdlIHdpbGwgYWRkIHRoYXQgdGlt ZW91dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bUkpdIFRo ZSByZWFzb24gZm9yIGhpZ2ggY29udHJvbCBvdmVyaGVhZCBpcyB0aGF0IHRoZSBub2RlIHdpbGwg aGF2ZSB0byBrZWVwIHByb2JpbmcgdGhlIG5laWdoYm9ycyB0byBtYWludGFpbiBzdGF0ZS4gVGhl IHByb2JsZW0gd2l0aCBzbWFsbGVyIGR1cmF0aW9uIHRpbWUgaXMgdGhhdCB0aGUgcHJvYmUgd2ls bCBiZSBtb3JlIGZyZXF1ZW50ISBSZWdhcmRsZXNzLCB0aGUgdGFibGUgdGhhdCBuZWVkcyB0byBi ZQ0KIG1haW50YWluZWQgZm9yIHN1Y2ggaW5mb3JtYXRpb24gaXMgZGlyZWN0bHkgcHJvcG9ydGlv bmFsIHRvIHRoZSBudW1iZXIgb2YgbmVpZ2hib3JpbmcgcGVlcnMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+W1JlbXld IFRoZSBub2RlIGRvZXNu4oCZdCBoYXZlIHRvIHByb2JlIGFsbCBpdHMgbmVpZ2hib3IuIERvbuKA mXQgZm9yZ2V0IHRoYXQgQU9EVi1SUEwgaXMgYW4gZXh0ZW5zaW9uIG9mIFJQTCwgYW5kIHRoZSBS UkVQIGFuZCBSUkVRIGFyZSB0d28gbmV3IERJTyBvcHRpb25zLiBUaHVzIHRoZSBESU8gdHJhbnNt aXNzaW9uLCBsb2NhbCByZXBhaXIgYW5kIG1hbnkgb3RoZXINCiBtZWNoYW5pc21zIHRvIG1haW50 YWluIHRoZSBzdGF0ZSBhcmUgdGhlIHNhbWUgYXMgUlBMLiAmbmJzcDtUaGVyZWZvcmUsIHRoZSBj b250cm9sIG92ZXJoZWFkIHdpbGwgc3RheSB0aGUgc2FtZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1j b2xvcjpjdXJyZW50Y29sb3IiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVm dDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9ImdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1 NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLXAxIj4NCkFueXdheXMgaSB0cmllZCB0 byBzZWFyY2ggZm9yIHlvdXIgaW1wbGVtZW50YXRpb24gdG8gY2hlY2sgb24gdGhpcyBidXQgaSBj b3VsZCBub3QgZmluZCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8 cCBjbGFzcz0iZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNt MjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDEiPg0KYi4gVXNlIG9mIHBhc3QgY29uZGl0aW9ucyB0 byBzdWdnZXN0IGZ1dHVyZSB0cmFmZmljIHBhdGggc2VsZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4w cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7 Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iZ21haWwtbS05MTA4MzQ0MjYw MjU1Mzc4OTkwbS0zMTAzMDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDEi Pg0K4oCcSWYgdGhlIFJSRVEtSW5zdGFuY2UgYXJyaXZlcyBvdmVyIGFuIGludGVyZmFjZSB0aGF0 IGlzIG5vdCBrbm93biB0bzxzcGFuIGNsYXNzPSJnbWFpbC1tLTkxMDgzNDQyNjAyNTUzNzg5OTBt LTMxMDMwMzUwNTYzNjUwMjEwM20yNzMwNzcwMzM1MDU5NTE5NTVnbWFpbC1hcHBsZS10YWItc3Bh biI+Jm5ic3A7PC9zcGFuPmJlIHN5bW1ldHJpYywgb3IgaXMga25vd24gdG8gYmUgYXN5bW1ldHJp YywgdGhlICdTJyBiaXQgaXMgc2V0IHRvIGJlIDAu4oCdPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAu MHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9ImdtYWlsLW0tOTEwODM0NDI2 MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWlsLXAx Ij4NClRoaXMgaXMgYSB0eXBpY2FsIHByb2JsZW0gd2UgZmFjZSBhcyB3ZWxsLiBQcm9iaW5nIGZv ciBtZWFzdXJlbWVudHMgYXQgc3VjaCBzY2FsZSAoYWxsIG5laWdoYm91cnMpIGlzIGEgcHJvYmxl bS4gSWYgeW91IGRvIHRoZSBwcm9iaW5nIHNwYXJzZWx5LCB0aGUgbmV0d29yayBjb25kaXRpb25z IG1pZ2h0IGhhdmUgY2hhbmdlZCB3aGVuIHlvdSB3YW50IHRvIHVzZSB0aGUgbWVhc3VyZW1lbnRz LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpZZXMsIHRoaXMgaXMgbmF0dXJhbGx5IGEgcHJvYmxl bSBpbiBkeW5hbWljIG5ldHdvcmtzLiZuYnNwOyBXZSBjYW4ndCBwcmVkaWN0IHRoZSBmdXR1cmUs IHNvIHdlIGFyZSBzdHVjayB3aXRoIHJlY29yZGluZyBzYWxpZW50IGFzcGVjdHMgb2YgdGhlIHBh c3QuJm5ic3A7IE5vIG1hdHRlciBob3cgb2Z0ZW4gd2UgbWVhc3VyZSwgaXQgaXMgZ3VhcmFudGVl ZCB0byBiZSB3cm9uZyBzb21lIChvciBtb3N0ISkgb2YgdGhlIHRpbWUgaW4gdGhlIGZ1dHVyZS4m bmJzcDsgQW5kIHlldA0KIHdlIHBlcnNpc3QuPGJyPg0KPGJyPg0KQnV0IHdlIGRvIG5vdCByZXF1 aXJlIHBlcmlvZGljIG9yIGV4aGF1c3RpdmUgbWVhc3VyZW1lbnRzIGZvciBhbGwgbmVpZ2hib3Jz IC0tIG9ubHkgYXMgbmVlZGVkIGZvciB0aGUgcHJvdG9jb2wgdG8gd29yay48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W1JKXSBNYXkgYmUgdGhpcyBpcyB0aGUgcGFydCBpIGRvbid0IGdldCAuLi4gWW91IG1lbnRpb25l ZCAmcXVvdDtvbmx5IGFzIG5lZWRlZCBmb3IgdGhlIHByb3RvY29sIHRvIHdvcmsmcXVvdDsgLi4u IENhbiB0aGlzIGJlIGVsYWJvcmF0ZWQ/DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUmVt eV0gQWdhaW4sIGl0IGlzIHN0aWxsIGluIHRoZSBmcmFtZXdvcmsgb2YgUlBMLCBzbyB0aGUgcHJv YmluZyBpcyBkb25lIGluIHRoZSBzYW1lIHdheSBhcyBSUEwsIGkuZS4gYnkgRElPIGFuZCBESVMs IHdoaWNoIGFyZSBjb250cm9sbGVkIGJ5IHRoZSB0cmlja2xlIHRpbWVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW0tOTEw ODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdt YWlsLXAxIj4NCk90aGVyIHBvaW50czo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlw ZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4N ClVzZSBvZiBvZGQvZXZlbiBudW1iZXJzIGZvciBwYWlyaW5nIGluc3RhbmNlcyBtYXkgbm90IGJl IGEgcm9idXN0IHdheSBvZiBwYWlyaW5nIOKApiBUaGVyZSBjb3VsZCBiZSByYWNlIGNvbmRpdGlv bnMgd2hlcmUgb3RoZXIgUDJQLVJQTCBpbnN0YW5jZXMgb3IgZmxvYXRpbmcgRE9EQUcgaW5zdGFu Y2VzIGVuZCB1cCB1c2luZyBvbmUgb2YgdGhlIHNhbWUgdmFsdWUgaW4gdGhlIGluc3RhbmNlLWlk IHBhaXIuIEhvdyB0byByZXNvbHZlIHN1Y2ggY29sbGlzaW9uPzxvOnA+PC9vOnA+PC9saT48L29s Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpCdXQs IHRoZSBpbnN0YW5jZS1pZHMgYXJlIGxvY2FsLiZuYnNwOyBTbyBpZiB0d28gZGlmZmVyZW50IG5v ZGVzIHVzZSB0aGUgc2FtZSBJRCB0aGF0IGlzIE8uSy4mbmJzcDsgSWYgdGhvc2UgdHdvIG5vZGVz IG5lZWQgdG8gaGF2ZSBhIHBlZXItdG8tcGVlciByb3V0ZSB0byB0aGUgc2FtZSBkZXN0aW5hdGlv biwgdGhhdCBpcyBzdGlsbCBPLksuLCBidXQgdGhlIFJSRVAgc2VudCBiYWNrIHRvIG9uZSBvZiB0 aGUgc291cmNlIG5vZGVzIHdpbGwgYmUgYWJsZSB0byB1c2UNCiB0aGUgcGFpcmVkIGluc3RhbmNl LUlEIGFuZCB0aGUgc3RyZWFtbGluZWQgUlJFUCwgYW5kIHRoZSBvdGhlciBSUkVQIHdpbGwgaGF2 ZSB0byBpbmNsdWRlIGFuIHVucGFpcmVkIGluc3RhbmNlLUlEIGFsb25nIHdpdGggdGhlIElQdjYg YWRkcmVzcyBvZiB0aGUgdGFyZ2V0IG5vZGUuJm5ic3A7IFRoYXQgd2lsbCBiZSBhIHJhcmUgb2Nj dXJyZW5jZSwgYW5kIHNvIHRoZSBvcHRpbWl6YXRpb24gb2YgZWxpZGluZyB0aGUgSVB2NiBhZGRy ZXNzJm5ic3A7IHdpbGwgdXN1YWxseQ0KIGJlIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bUkpdIFll YWgsIGZvciBsb2NhbCBpbnN0YW5jZXMgdGhpcyBtaWdodCBub3QgYmUgYSBwcm9ibGVtLiBUaGFu a3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8b2wg c3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMyI+DQpJIHdvdWxkIHJlY29tbWVuZCB0byB1c2UgQ29vamEgd2l0aCBsaW5rcyBp biBER1JNIG1vZGUgdG8gZXZhbHVhdGUgdGhlIHBlcmYuPG86cD48L286cD48L2xpPjwvb2w+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KVGhpcyBzb3VuZHMgbGlrZSBhIGdvb2QgaWRlYS4mbmJzcDsg VGhlIG90aGVyIGNvLWF1dGhvcnMgd2lsbCBwcm9iYWJseSBoYXZlIG1vcmUgZm9sbG93LXVwIGFi b3V0IHRoaXMuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8b2wgc3RhcnQ9 IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEg bGZvNCI+DQpUaGUgUlNTSSB2YWx1ZXMgaW4gdGhlIEFwcGVuZGl4IGRvIG5vdCBsb29rIGNvcnJl Y3QuIEFuIFJTU0kgb2YgJmx0Oy03MGRibSBpcyB0b28gZ29vZCBbMV0gdG8gaGF2ZSBmb3IgZ29v ZCBQRFIuIFRoZSBtYXBwaW5nIG9mIFJTU0ktRVRYIGluIHRoZSBhcHBlbmRpeCBoZW5jZSBtYXkg bm90IGJlIGNvcnJlY3QgKGkgYmVsaWV2ZSB0aGVzZSB2YWx1ZXMgYXJlIGZyb20gQ29vamEpLjxv OnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpJIGRvbid0IHVuZGVyc3RhbmQgaG93IGFuIFJTU0kgY291bGQgYmUgJnF1 b3Q7dG9vIGdvb2QmcXVvdDssIHVubGVzcyB5b3UgbWVhbiB0aGF0IHRoZSBwb3dlciBsZXZlbCBp cyB0b28gaGlnaCBhbmQgY2F1c2VzIHdpZGVzcHJlYWQgaW50ZXJmZXJlbmNlLiZuYnNwOyBBZG1p dHRlZGx5LCBJIGFtIG5vIGV4cGVydCBpbiBpbnRlcnByZXRpbmcgUEhZIGxheWVyIGVmZmVjdHMs IGJ1dCBhbnl3YXkgdXN1YWxseSBoaWdoZXIgcmVjZWl2ZWQgcG93ZXIgYWxsb3dzIG1vcmUgYWNj dXJhdGUNCiBkZXRlY3Rpb24sIGlmIHRoZSBiYWNrZ3JvdW5kIG5vaXNlIGxldmVsIHJlbWFpbnMg dGhlIHNhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltSSl0gTXkgcmVmZXJlbmNlIGhlcmUgaXMgdG8gdGhlIFJT U0kgdG8gRVRYIG1hcHBpbmcgdGFibGUgaW4gdGhlIGRyYWZ0LiBUaGUgdmFsdWVzIG5vdGVkIGlu IHRoYXQgdGFibGUgZG8gbm90IGxvb2sgY29ycmVjdC4gRm9yIFJTU0kgLTU1IHRvIC00NWRibSwg dGhlIGV4cGVjdGVkIEVUWCBpcyA5OTMuIE9uIHdoYXQgYmFzaXMgd2FzIHRoaXMgdGFibGUgZ2Vu ZXJhdGVkID8gVHlwaWNhbGx5IGkgaGF2ZSBmb3VuZA0KIHRoYXQgUlNTSSBvZiAmbHQ7IC04MGRi bSByZXN1bHRzIGluIHZlcnkgZ29vZCBQRFJzIChhbHNvIHRoZSByZWYgaSBhdHRhY2hlZCBzYXlz IHRoZSBzYW1lKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iZ21haWwtbS05MTA4MzQ0MjYwMjU1Mzc4OTkwbS0zMTAz MDM1MDU2MzY1MDIxMDNtMjczMDc3MDMzNTA1OTUxOTU1Z21haWwtcDMiPg0KPHNwYW4gY2xhc3M9 ImdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAz MzUwNTk1MTk1NWdtYWlsLXMxIj5bMV08L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tOTEwODM0 NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1MTk1NWdtYWls LWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWls LW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3NzAzMzUwNTk1 MTk1NWdtYWlsLXMxIj5SU1NJIGlzIFVuZGVyLUFwcHJlY2lhdGVkDQo8L3NwYW4+PHNwYW4gY2xh c3M9ImdtYWlsLW0tOTEwODM0NDI2MDI1NTM3ODk5MG0tMzEwMzAzNTA1NjM2NTAyMTAzbTI3MzA3 NzAzMzUwNTk1MTk1NWdtYWlsLXMyIj48YSBocmVmPSJodHRwczovL3Npbmcuc3RhbmZvcmQuZWR1 L3NpdGUvcHVibGljYXRpb25zL2VtbmV0czIwMDZzcmluaXZhc2FuLnBkZiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vc2luZy5zdGFuZm9yZC5lZHUvc2l0ZS9wdWJsaWNhdGlvbnMvZW1uZXRzMjAw NnNyaW5pdmFzYW4ucGRmPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhbmtzIGZvciB0aGUgbGluay4m bmJzcDsgSSByZWFkIHRocm91Z2ggaXQgdmVyeSBicmllZmx5IG9uIHRoaXMgZmluZSBtb3JuaW5n LiZuYnNwOyBIb3dldmVyLCBJIGhhdmUgYWxzbyByZWFkIG90aGVyIHBhcGVycyB0aGF0IHNlcmlv dXNseSBxdWVzdGlvbiB0aGUgdmFsdWUgb2YgcmVseWluZyBvbiBSU1NJLiZuYnNwOw0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkn bGwgdHJ5IHRvIHJlbWVtYmVyIGFuZCBmaW5kIG9uZSBmb3IgZnVydGhlciBkaXNjdXNzaW9uLiBO b3RhYmx5LCB0aGUgYXV0aG9ycyBzZWVtIHRvIGZvY3VzIG9uIHBhcnRpY3VsYXIgaGFyZHdhcmUs IGFuZCBhIHNpbmdsZSBsaW5rIGJldHdlZW4gdHdvIG5laWdoYm9ycywgZm9yIHRoZWlyIGRpc2N1 c3Npb24sIHVubGVzcyBJIG1pc3NlZCBzb21ldGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltSSl0gVGhlIGF1 dGhvcnMgaGF2ZSBub3QgbWVyZWx5IGZvY3VzZWQgb24gc2luZ2xlIGxpbmsgYmV0d2VlbiB0d28g bmVpZ2hib3JzLiBUaGUgc2xpZGVzIG9mIHRoZSBwYXBlci10YWxrIGdpdmVzIGEgYmV0dGVyIHBp Y3R1cmUsDQo8YSBocmVmPSJodHRwczovL3Npbmcuc3RhbmZvcmQuZWR1L3NpdGUvdGFsa3MvZW1u ZXRzMjAwNnNyaW5pdmFzYW4ucHB0Ij5odHRwczovL3Npbmcuc3RhbmZvcmQuZWR1L3NpdGUvdGFs a3MvZW1uZXRzMjAwNnNyaW5pdmFzYW4ucHB0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpSZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BB09947B5326FE42BA3918FA28765C2EDC9AC0DGGEMM506MBSchina_--