From nobody Mon Apr 3 22:08:11 2017 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5C21270A7; Mon, 3 Apr 2017 22:08:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149128248961.17258.16470965755309079576@ietfa.amsl.com> Date: Mon, 03 Apr 2017 22:08:09 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 05:08:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking of the IETF. Title : Deterministic Networking Use Cases Authors : Ethan Grossman Craig Gunther Pascal Thubert Patrick Wetterwald Jean Raymond Jouni Korhonen Yu Kaneko Subir Das Yiyong Zha Balázs Varga János Farkas Franz-Josef Goetz Juergen Schmitt Xavier Vilajosana Toktam Mahmoodi Spiros Spirou Petra Vizarreta Filename : draft-ietf-detnet-use-cases-12.txt Pages : 81 Date : 2017-04-03 Abstract: This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include wireless for industrial applications, professional audio, electrical utilities, building automation systems, radio/mobile access networks, automotive, and gaming. For each case, this document will identify the application, identify representative solutions used today, and what new uses an IETF DetNet solution may enable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-12 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-use-cases-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 3 22:15:17 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9343F12785F for ; Mon, 3 Apr 2017 22:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 JoGV0i_AUma9 for ; Mon, 3 Apr 2017 22:15:14 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 205B2126DDF for ; Mon, 3 Apr 2017 22:15:14 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v345EolS029827 for ; Mon, 3 Apr 2017 22:15:11 -0700 Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 29j7r115fx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 03 Apr 2017 22:15:11 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Apr 2017 22:15:10 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Mon, 3 Apr 2017 22:15:10 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Thread-Index: AQHSrQF3IN7+gX7NW0S/cJN9H96cJaG0qSng Date: Tue, 4 Apr 2017 05:15:09 +0000 Message-ID: References: <149128248961.17258.16470965755309079576@ietfa.amsl.com> In-Reply-To: <149128248961.17258.16470965755309079576@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-04_04:, , signatures=0 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 05:15:16 -0000 SGkgQWxsLA0KVGhpcyBuZXcgdmVyc2lvbiAxMiBvZiB0aGUgRGV0TmV0IFVzZSBDYXNlcyBkcmFm dCBpcyBwcmltYXJpbHkgaW50ZW5kZWQgdG8gcHJldmVudCBpdCBmcm9tIGV4cGlyaW5nLCBzbyB0 aGF0IHdlIGNhbiBkbyBXR0xDLiBJdCBkb2VzIGNvbnRhaW4gYSBmZXcgbWlub3IgdHdlYWtzIGR1 ZSB0byBmZWVkYmFjayByZWNlaXZlZCBmcm9tIHRoZSBsaXN0IHNpbmNlIHB1YmxpY2F0aW9uIG9m IHZlcnNpb24gMTEuIA0KSSBrbm93IHRoYXQgdGhlcmUgYXJlIHN0aWxsIHNvbWUgYWRkaXRpb25z IHRoYXQgYXJlIGJlaW5nIGNvbnNpZGVyZWQgZm9yIHRoaXMgZHJhZnQsIGFuZCBJIGV4cGVjdCB0 aGVyZSB3aWxsIGJlIGF0IGxlYXN0IG9uZSBtb3JlIHJldmlzaW9uIHRvIGluY29ycG9yYXRlIHRo ZW0gKGJlZm9yZSBvciBhcyBhIHJlc3VsdCBvZiBXR0xDKS4gDQpCZXN0LA0KRXRoYW4uDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkZXRuZXQgW21haWx0bzpkZXRuZXQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2Vu dDogVHVlc2RheSwgQXByaWwgMDQsIDIwMTcgMTI6MDggQU0NClRvOiBpLWQtYW5ub3VuY2VAaWV0 Zi5vcmcNCkNjOiBkZXRuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFtEZXRuZXRdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMi50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEZXRlcm1pbmlzdGljIE5l dHdvcmtpbmcgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGV0ZXJt aW5pc3RpYyBOZXR3b3JraW5nIFVzZSBDYXNlcw0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBF dGhhbiBHcm9zc21hbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBDcmFpZyBHdW50aGVyDQog ICAgICAgICAgICAgICAgICAgICAgICAgIFBhc2NhbCBUaHViZXJ0DQogICAgICAgICAgICAgICAg ICAgICAgICAgIFBhdHJpY2sgV2V0dGVyd2FsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICBK ZWFuIFJheW1vbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgSm91bmkgS29yaG9uZW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgWXUgS2FuZWtvDQogICAgICAgICAgICAgICAgICAgICAg ICAgIFN1YmlyIERhcw0KICAgICAgICAgICAgICAgICAgICAgICAgICBZaXlvbmcgWmhhDQogICAg ICAgICAgICAgICAgICAgICAgICAgIEJhbMOhenMgVmFyZ2ENCiAgICAgICAgICAgICAgICAgICAg ICAgICAgSsOhbm9zIEZhcmthcw0KICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFuei1Kb3Nl ZiBHb2V0eg0KICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuIFNjaG1pdHQNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgWGF2aWVyIFZpbGFqb3NhbmENCiAgICAgICAgICAgICAgICAg ICAgICAgICAgVG9rdGFtIE1haG1vb2RpDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNwaXJv cyBTcGlyb3UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUGV0cmEgVml6YXJyZXRhDQoJRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTEyLnR4dA0KCVBhZ2Vz ICAgICAgICAgICA6IDgxDQoJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNC0wMw0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZHJhZnQgZG9jdW1lbnRzIHJlcXVpcmVtZW50cyBpbiBzZXZlcmFsIGRpdmVy c2UgaW5kdXN0cmllcyB0bw0KICAgZXN0YWJsaXNoIG11bHRpLWhvcCBwYXRocyBmb3IgY2hhcmFj dGVyaXplZCBmbG93cyB3aXRoIGRldGVybWluaXN0aWMNCiAgIHByb3BlcnRpZXMuICBJbiB0aGlz IGNvbnRleHQgZGV0ZXJtaW5pc3RpYyBpbXBsaWVzIHRoYXQgc3RyZWFtcyBjYW4NCiAgIGJlIGVz dGFibGlzaGVkIHdoaWNoIHByb3ZpZGUgZ3VhcmFudGVlZCBiYW5kd2lkdGggYW5kIGxhdGVuY3kg d2hpY2gNCiAgIGNhbiBiZSBlc3RhYmxpc2hlZCBmcm9tIGVpdGhlciBhIExheWVyIDIgb3IgTGF5 ZXIgMyAoSVApIGludGVyZmFjZSwNCiAgIGFuZCB3aGljaCBjYW4gY28tZXhpc3Qgb24gYW4gSVAg bmV0d29yayB3aXRoIGJlc3QtZWZmb3J0IHRyYWZmaWMuDQoNCiAgIEFkZGl0aW9uYWwgcmVxdWly ZW1lbnRzIGluY2x1ZGUgb3B0aW9uYWwgcmVkdW5kYW50IHBhdGhzLCB2ZXJ5IGhpZ2gNCiAgIHJl bGlhYmlsaXR5IHBhdGhzLCB0aW1lIHN5bmNocm9uaXphdGlvbiwgYW5kIGNsb2NrIGRpc3RyaWJ1 dGlvbi4NCg0KICAgSW5kdXN0cmllcyBjb25zaWRlcmVkIGluY2x1ZGUgd2lyZWxlc3MgZm9yIGlu ZHVzdHJpYWwgYXBwbGljYXRpb25zLA0KICAgcHJvZmVzc2lvbmFsIGF1ZGlvLCBlbGVjdHJpY2Fs IHV0aWxpdGllcywgYnVpbGRpbmcgYXV0b21hdGlvbg0KICAgc3lzdGVtcywgcmFkaW8vbW9iaWxl IGFjY2VzcyBuZXR3b3JrcywgYXV0b21vdGl2ZSwgYW5kIGdhbWluZy4NCg0KICAgRm9yIGVhY2gg Y2FzZSwgdGhpcyBkb2N1bWVudCB3aWxsIGlkZW50aWZ5IHRoZSBhcHBsaWNhdGlvbiwgaWRlbnRp ZnkNCiAgIHJlcHJlc2VudGF0aXZlIHNvbHV0aW9ucyB1c2VkIHRvZGF5LCBhbmQgd2hhdCBuZXcg dXNlcyBhbiBJRVRGIERldE5ldA0KICAgc29sdXRpb24gbWF5IGVuYWJsZS4NCg0KDQpUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy8NCg0KVGhl cmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMt MTINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGV0bmV0LXVzZS1j YXNlcy0xMg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCg== From nobody Wed Apr 5 07:47:57 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF28B129477 for ; Wed, 5 Apr 2017 07:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 TqAkYW5fSnCb for ; Wed, 5 Apr 2017 07:47:53 -0700 (PDT) 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 EB674126DC2 for ; Wed, 5 Apr 2017 07:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16526; q=dns/txt; s=iport; t=1491403673; x=1492613273; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0vfFFalh8wag8RyfQm2nSxvct9L5X8DiNQR+VpcH9Qk=; b=iTYqLFoCWxUKH/i5FmPWdLpfKL/qb5aIay86y2O6gf2nDJGblok1edeU 4nYFolPa3c6TLIkg3SCq1UTEw+9IzB/C0RJ58y/rYgZtCKIA+HKnc2zEZ mKm9/Co5s6aklgwJUYiyl/7XvVt0f5tCaAGYoy7prfN6tkFfbtKOb8xIS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAQAwAuVY/5JdJa1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuOythgQsHhD+JL5E8kCGFNIIOHwEKhS5KAoNNPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQMBASVHFwQCAQgRBAEBKAcnCxQJCAIEARIbiXMOrUc6imwBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhk6EcIMXgRcdhXAFiSqHAIVzhlMBhn2LVIF?= =?us-ascii?q?9VYRZihGTdQEfOIEFWxUYKYZZdYg8gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,279,1486425600"; d="scan'208,217";a="404041151" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 14:47:51 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v35Elp0q013456 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2017 14:47:51 GMT Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 10:47:50 -0400 Received: from xch-rtp-002.cisco.com ([64.101.220.142]) by XCH-RTP-002.cisco.com ([64.101.220.142]) with mapi id 15.00.1210.000; Wed, 5 Apr 2017 10:47:50 -0400 From: "Maik Seewald (maseewal)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Thread-Index: AQHSrQF5bAJ55h1fb0qDXRQ3f50gLKG07eaAgAJT1gA= Date: Wed, 5 Apr 2017 14:47:50 +0000 Message-ID: References: <149128248961.17258.16470965755309079576@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.162.75] Content-Type: multipart/alternative; boundary="_000_D50ACC115DA9Fmaseewalciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:47:56 -0000 --_000_D50ACC115DA9Fmaseewalciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ethan, all, A few comments on section: 3.1.1.2 Intra-Substation Process Bus Communicati= ons The CT/VT in the substation send the sampled value (analog voltage or current) to the MU over hard wire. -> Typi= cally, the CT/VT send analog values. A Merging Unit (MU) converts the analo= g values into digital values, typically into Sampled Values (IEC 61850-9-2) The MU sends the time-synchronized 61850-9-2 sampled values to the IEDs in the substation in GOOSE message format. -> Sampled Values (SV) are = defined in IEC 61850-9-2. SV are not sent as GOOSE messages (IEC 61850-8-1)= . They are sent as Sampled Values, completely defined in IEC 61850-9-2. Cheers. Maik On 04/04/2017, 07:15, "detnet on behalf of Grossman, Ethan A." on behalf of eagros@dolby.com<= mailto:eagros@dolby.com>> wrote: Hi All, This new version 12 of the DetNet Use Cases draft is primarily intended to = prevent it from expiring, so that we can do WGLC. It does contain a few min= or tweaks due to feedback received from the list since publication of versi= on 11. I know that there are still some additions that are being considered for th= is draft, and I expect there will be at least one more revision to incorpor= ate them (before or as a result of WGLC). Best, Ethan. -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Tuesday, April 04, 2017 12:08 AM To: i-d-announce@ietf.org Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Deterministic Networking of the IETF. Title : Deterministic Networking Use Cases Authors : Ethan Grossman Craig Gunther Pascal Thubert Patrick Wetterwald Jean Raymond Jouni Korhonen Yu Kaneko Subir Das Yiyong Zha Bal=E1zs Varga J=E1nos Farkas Franz-Josef Goetz Juergen Schmitt Xavier Vilajosana Toktam Mahmoodi Spiros Spirou Petra Vizarreta Filename : draft-ietf-detnet-use-cases-12.txt Pages : 81 Date : 2017-04-03 Abstract: This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include wireless for industrial applications, professional audio, electrical utilities, building automation systems, radio/mobile access networks, automotive, and gaming. For each case, this document will identify the application, identify representative solutions used today, and what new uses an IETF DetNet solution may enable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-12 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-use-cases-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_D50ACC115DA9Fmaseewalciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6610C7D21D69FC429B49C16229292F70@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Ethan, all, 

A few comments on section: 3.1.1.2 Intra-Substation Process Bus Communicati= ons

The CT/VT in the substation send the
sampled value (analog voltage or = current) to the MU over hard wire. —> Typically, the CT/VT send analog values. A Merging Unit (MU) converts the analog values into digital= values, typically into Sampled Values (IEC 61850-9-2)

The MU sends the time-synchronized 61850-9-2 sampled values to the
IEDs in the substation in GOOSE m= essage format. —> Sampled Values (SV) are defined in IEC 61850-9-2. SV are not sent = as GOOSE messages (IEC 61850-= 8-1). They are sent as Sampled Values, completely defined in IEC 61850-9-2.=

Cheers. Maik



On 04/04/2017, 07:15, "detnet on behalf of Grossman, Ethan A." &l= t;detnet-bounces@ietf.org on= behalf of eagros@dolby.com> wrote:

Hi All,
This new version 12 of the DetNet Use Cases draft is primarily intende= d to prevent it from expiring, so that we can do WGLC. It does contain a fe= w minor tweaks due to feedback received from the list since publication of = version 11.
I know that there are still some additions that are being considered f= or this draft, and I expect there will be at least one more revision to inc= orporate them (before or as a result of WGLC).
Best,
Ethan.

-----Original Message-----
From: detnet [mailto:detnet= -bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, April 04, 2017 12:08 AM
Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Deterministic Networking of the IETF.=

        Title   = ;        : Deterministic Networking Use = Cases
        Authors  &nb= sp;      : Ethan Grossman
           &nbs= p;            &= nbsp; Craig Gunther
           &nbs= p;            &= nbsp; Pascal Thubert
           &nbs= p;            &= nbsp; Patrick Wetterwald
           &nbs= p;            &= nbsp; Jean Raymond
           &nbs= p;            &= nbsp; Jouni Korhonen
           &nbs= p;            &= nbsp; Yu Kaneko
           &nbs= p;            &= nbsp; Subir Das
           &nbs= p;            &= nbsp; Yiyong Zha
           &nbs= p;            &= nbsp; Bal=E1zs Varga
           &nbs= p;            &= nbsp; J=E1nos Farkas
           &nbs= p;            &= nbsp; Franz-Josef Goetz
           &nbs= p;            &= nbsp; Juergen Schmitt
           &nbs= p;            &= nbsp; Xavier Vilajosana
           &nbs= p;            &= nbsp; Toktam Mahmoodi
           &nbs= p;            &= nbsp; Spiros Spirou
           &nbs= p;            &= nbsp; Petra Vizarreta
Filena= me        : draft-ietf-detnet-use-c= ases-12.txt
Pages&= nbsp;          : 81
Date&n= bsp;           : 201= 7-04-03

Abstract:
   This draft documents requirements in several diverse indu= stries to
   establish multi-hop paths for characterized flows with de= terministic
   properties.  In this context deterministic impl= ies that streams can
   be established which provide guaranteed bandwidth and lat= ency which
   can be established from either a Layer 2 or Layer 3 (IP) = interface,
   and which can co-exist on an IP network with best-effort = traffic.

   Additional requirements include optional redundant paths,= very high
   reliability paths, time synchronization, and clock distri= bution.

   Industries considered include wireless for industrial app= lications,
   professional audio, electrical utilities, building automa= tion
   systems, radio/mobile access networks, automotive, and ga= ming.

   For each case, this document will identify the applicatio= n, identify
   representative solutions used today, and what new uses an= IETF DetNet
   solution may enable.


The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:


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

Internet-Drafts are also available by anonymous FTP at:

_______________________________________________
detnet mailing list
_______________________________________________
detnet mailing list

--_000_D50ACC115DA9Fmaseewalciscocom_-- From nobody Wed Apr 5 12:43:51 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE286129498 for ; Wed, 5 Apr 2017 12:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 PN5y5GzP-fqH for ; Wed, 5 Apr 2017 12:43:44 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 0DD22127A90 for ; Wed, 5 Apr 2017 12:37:22 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35JZxl7002376; Wed, 5 Apr 2017 12:37:18 -0700 Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 29n3ffgt1s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 12:37:18 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 12:37:07 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Wed, 5 Apr 2017 12:37:07 -0700 From: "Grossman, Ethan A." To: "Maik Seewald (maseewal)" , "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Thread-Index: AQHSrQF3IN7+gX7NW0S/cJN9H96cJaG0qSnggAKpXgD//9rLkA== Date: Wed, 5 Apr 2017 19:37:07 +0000 Message-ID: References: <149128248961.17258.16470965755309079576@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_d77a47219c244d019dd0823aa02da5e8DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_15:, , signatures=0 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:43:50 -0000 --_000_d77a47219c244d019dd0823aa02da5e8DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Maik. I don't know the technical aspects of these statements - I wou= ld like at least one other expert to please weigh in on whether these are a= ppropriate changes. Thanks, Ethan. From: Maik Seewald (maseewal) [mailto:maseewal@cisco.com] Sent: Wednesday, April 05, 2017 7:48 AM To: Grossman, Ethan A. ; detnet@ietf.org Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Ethan, all, A few comments on section: 3.1.1.2 Intra-Substation Process Bus Communicati= ons The CT/VT in the substation send the sampled value (analog voltage or current) to the MU over hard wire. -> Typi= cally, the CT/VT send analog values. A Merging Unit (MU) converts the analo= g values into digital values, typically into Sampled Values (IEC 61850-9-2) The MU sends the time-synchronized 61850-9-2 sampled values to the IEDs in the substation in GOOSE message format. -> Sampled Values (SV) are = defined in IEC 61850-9-2. SV are not sent as GOOSE messages (IEC 61850-8-1)= . They are sent as Sampled Values, completely defined in IEC 61850-9-2. Cheers. Maik On 04/04/2017, 07:15, "detnet on behalf of Grossman, Ethan A." on behalf of eagros@dolby.com<= mailto:eagros@dolby.com>> wrote: Hi All, This new version 12 of the DetNet Use Cases draft is primarily intended to = prevent it from expiring, so that we can do WGLC. It does contain a few min= or tweaks due to feedback received from the list since publication of versi= on 11. I know that there are still some additions that are being considered for th= is draft, and I expect there will be at least one more revision to incorpor= ate them (before or as a result of WGLC). Best, Ethan. -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Tuesday, April 04, 2017 12:08 AM To: i-d-announce@ietf.org Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Deterministic Networking of the IETF. Title : Deterministic Networking Use Cases Authors : Ethan Grossman Craig Gunther Pascal Thubert Patrick Wetterwald Jean Raymond Jouni Korhonen Yu Kaneko Subir Das Yiyong Zha Bal=E1zs Varga J=E1nos Farkas Franz-Josef Goetz Juergen Schmitt Xavier Vilajosana Toktam Mahmoodi Spiros Spirou Petra Vizarreta Filename : draft-ietf-detnet-use-cases-12.txt Pages : 81 Date : 2017-04-03 Abstract: This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include wireless for industrial applications, professional audio, electrical utilities, building automation systems, radio/mobile access networks, automotive, and gaming. For each case, this document will identify the application, identify representative solutions used today, and what new uses an IETF DetNet solution may enable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-12 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-use-cases-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_d77a47219c244d019dd0823aa02da5e8DLBXCHPW03dolbynet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Maik. I don’t know the technical aspec= ts of these statements – I would like at least one other expert to pl= ease weigh in on whether these are appropriate changes.

Thanks,

Ethan.

 

From: Maik Seewald (maseewal) [mailt= o:maseewal@cisco.com]
Sent: Wednesday, April 05, 2017 7:48 AM
To: Grossman, Ethan A. <eagros@dolby.com>; detnet@ietf.org
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt=

 

Ethan, all, 

 

A few comments on section: 3.1.1.2 Intr= a-Substation Process Bus Communications

 

The CT/VT in the substation send the=

sampled value (analog voltage or current) to the MU over hard wir= e. —> Typic= ally, the CT/VT send analog values. A Merging Unit (MU) converts the a= nalog values into digital values, typically into Sampled Values (IEC 61850-= 9-2)

 

The MU sends the time-synchronized 6= 1850-9-2 sampled values to the

IEDs in the substation in GOOSE message format. —> Sampl= ed Values (SV) are defined in IEC 61850-9-2. SV are not sent as GOOSE&= nbsp;messages (IEC 61850-8-1). They are sent as Sampled Values, completely = defined in IEC 61850-9-2.

 

Cheers. Maik

 

 

 

On 04/04/2017, 07:15, "detnet on b= ehalf of Grossman, Ethan A." <detnet-bounces@ietf.org on behalf of eagros@dolby.com> wrote:

 

Hi All,

This new version 12 of the DetNet Use C= ases draft is primarily intended to prevent it from expiring, so that we ca= n do WGLC. It does contain a few minor tweaks due to feedback received from the list since publication of version 11.

I know that there are still some additi= ons that are being considered for this draft, and I expect there will be at= least one more revision to incorporate them (before or as a result of WGLC).

Best,

Ethan.

 

-----Original Message-----

Sent: Tuesday, April 04, 2017 12:08 AM<= o:p>

Subject: [Detnet] I-D Action: draft-iet= f-detnet-use-cases-12.txt

 

 

A New Internet-Draft is available from = the on-line Internet-Drafts directories.

This draft is a work item of the Determ= inistic Networking of the IETF.

 

      &nb= sp; Title           = : Deterministic Networking Use Cases

      &nb= sp; Authors         : Ethan Gr= ossman

      &nb= sp;            =        Craig Gunther

      &nb= sp;            =        Pascal Thubert<= /p>

      &nb= sp;            =        Patrick Wetterwald

      &nb= sp;            =        Jean Raymond

      &nb= sp;            =        Jouni Korhonen<= /p>

      &nb= sp;            =        Yu Kaneko

      &nb= sp;            =        Subir Das

      &nb= sp;            =        Yiyong Zha

      &nb= sp;            =        Bal=E1zs Varga<= /p>

      &nb= sp;            =        J=E1nos Farkas<= /p>

      &nb= sp;            =        Franz-Josef Goetz

      &nb= sp;            =        Juergen Schmitt=

      &nb= sp;            =        Xavier Vilajosana

      &nb= sp;            =        Toktam Mahmoodi=

      &nb= sp;            =        Spiros Spirou

      &nb= sp;            =        Petra Vizarreta=

Filename     &= nbsp;  : draft-ietf-detnet-use-cases-12.txt

Pages     &nbs= p;     : 81

Date      = ;      : 2017-04-03

 

Abstract:

   This draft documents requi= rements in several diverse industries to

   establish multi-hop paths = for characterized flows with deterministic

   properties.  In = this context deterministic implies that streams can

   be established which provi= de guaranteed bandwidth and latency which

   can be established from ei= ther a Layer 2 or Layer 3 (IP) interface,

   and which can co-exist on = an IP network with best-effort traffic.

 

   Additional requirements in= clude optional redundant paths, very high

   reliability paths, time sy= nchronization, and clock distribution.

 

   Industries considered incl= ude wireless for industrial applications,

   professional audio, electr= ical utilities, building automation

   systems, radio/mobile acce= ss networks, automotive, and gaming.

 

   For each case, this docume= nt will identify the application, identify

   representative solutions u= sed today, and what new uses an IETF DetNet

   solution may enable.<= /o:p>

 

 

The IETF datatracker status page for th= is draft is:

 

There are also htmlized versions availa= ble at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

detnet mailing list

_______________________________________= ________

detnet mailing list

 

--_000_d77a47219c244d019dd0823aa02da5e8DLBXCHPW03dolbynet_-- From nobody Thu Apr 6 06:51:50 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A5712950B for ; Thu, 6 Apr 2017 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.532 X-Spam-Level: X-Spam-Status: No, score=-12.532 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0a0_YDNRXSII for ; Thu, 6 Apr 2017 06:51:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3C8129508 for ; Thu, 6 Apr 2017 06:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42988; q=dns/txt; s=iport; t=1491486698; x=1492696298; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/+jEcuEioPOXz+S59kMD+dS0yGEEsVO798mqI1rPr5k=; b=Oe0kdPivgmxhno78A6vOs9GPt/U+34LHQNMvJ3kDhotVcMIsCJk2gGg+ anOXBHIYya3hrJf47zLg5vVXRhIG3SvbPiI64+5i7mVKNm5Txr1vvVdii f+2Wjd6WfpeQ239h2eXWxiTxNdlAEvewKSLmkDRavioyLqqogCfUjnOas M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCtRuZY/40NJK1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweFYogMkT2VVYIMAx8BCYUvSgKDRT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDAQErPgMXBAIBCBEDAQEBIQEGBycLFAkIAgQBEhuJcw6rUYpoA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYZOhHCDF4EGEQ4PKxaFLwWJKoxzhlYBhn2?= =?us-ascii?q?LVYF+VYRZihGPUYQmAR84gQVbFRgphCKCOXUBAYhQgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208,217";a="406668830" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2017 13:51:36 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v36DpaxL015246 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 13:51:36 GMT Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 09:51:35 -0400 Received: from xch-rtp-002.cisco.com ([64.101.220.142]) by XCH-RTP-002.cisco.com ([64.101.220.142]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 09:51:35 -0400 From: "Maik Seewald (maseewal)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Thread-Index: AQHSrQF5bAJ55h1fb0qDXRQ3f50gLKG07eaAgAJT1gCAAC9UgIABU0WA Date: Thu, 6 Apr 2017 13:51:35 +0000 Message-ID: References: <149128248961.17258.16470965755309079576@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.162.75] Content-Type: multipart/alternative; boundary="_000_D50C11B05DBC4maseewalciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:51:42 -0000 --_000_D50C11B05DBC4maseewalciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ethan, Sure thing. I have another comment. IEC 61850 will recommend the use of the IEEE PTP 1588 Utility Profile (as defined in [IEC62439-3:2012] Annex B) which offers the support of redundant attachment of clocks to Parallel Redundancy Protcol (PRP) and High-availability Seamless Redundancy (HSR) networks. IEC 61850 has published IEC/IEEE 61850-9-3:2016 as joined work with IEEE: h= ttps://webstore.iec.ch/publication/24998 The title is: Precision time protocol profile for power utility automation.= It is based on Annex B/IEC 62439. In other words, for IEC 61850 installations only part 9-3 applies. I=92m a member of of WG10 (IEC 61850) and co-author of several standard doc= uments. Cheers, Maik From: "Grossman, Ethan A." > Date: Wednesday, 5 April 2017 at 21:37 To: Cisco Employee >, "detnet= @ietf.org" = > Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Thanks Maik. I don=92t know the technical aspects of these statements =96 I= would like at least one other expert to please weigh in on whether these a= re appropriate changes. Thanks, Ethan. From: Maik Seewald (maseewal) [mailto:maseewal@cisco.com] Sent: Wednesday, April 05, 2017 7:48 AM To: Grossman, Ethan A. >; detnet@= ietf.org Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt Ethan, all, A few comments on section: 3.1.1.2 Intra-Substation Process Bus Communicati= ons The CT/VT in the substation send the sampled value (analog voltage or current) to the MU over hard wire. =97> Ty= pically, the CT/VT send analog values. A Merging Unit (MU) converts the ana= log values into digital values, typically into Sampled Values (IEC 61850-9-= 2) The MU sends the time-synchronized 61850-9-2 sampled values to the IEDs in the substation in GOOSE message format. =97> Sampled Values (SV) ar= e defined in IEC 61850-9-2. SV are not sent as GOOSE messages (IEC 61850-8-= 1). They are sent as Sampled Values, completely defined in IEC 61850-9-2. Cheers. Maik On 04/04/2017, 07:15, "detnet on behalf of Grossman, Ethan A." on behalf of eagros@dolby.com<= mailto:eagros@dolby.com>> wrote: Hi All, This new version 12 of the DetNet Use Cases draft is primarily intended to = prevent it from expiring, so that we can do WGLC. It does contain a few min= or tweaks due to feedback received from the list since publication of versi= on 11. I know that there are still some additions that are being considered for th= is draft, and I expect there will be at least one more revision to incorpor= ate them (before or as a result of WGLC). Best, Ethan. -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: Tuesday, April 04, 2017 12:08 AM To: i-d-announce@ietf.org Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Deterministic Networking of the IETF. Title : Deterministic Networking Use Cases Authors : Ethan Grossman Craig Gunther Pascal Thubert Patrick Wetterwald Jean Raymond Jouni Korhonen Yu Kaneko Subir Das Yiyong Zha Bal=E1zs Varga J=E1nos Farkas Franz-Josef Goetz Juergen Schmitt Xavier Vilajosana Toktam Mahmoodi Spiros Spirou Petra Vizarreta Filename : draft-ietf-detnet-use-cases-12.txt Pages : 81 Date : 2017-04-03 Abstract: This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include wireless for industrial applications, professional audio, electrical utilities, building automation systems, radio/mobile access networks, automotive, and gaming. For each case, this document will identify the application, identify representative solutions used today, and what new uses an IETF DetNet solution may enable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-12 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-use-cases-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_D50C11B05DBC4maseewalciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Ethan,=

Sure thing. I ha= ve another comment.

 IEC 61850 will recommend the use=
 of the IEEE PTP 1588 Utility Profile
   (as defined in [IEC62439-3:2012] Annex B) which offers the support of
   redundant attachment of clocks to Parallel Redundancy Protcol (PRP)
   and High-availability Seamless Redundancy (HSR) networks.




IEC 61850 has published IEC/IEEE 618=
50-9-3:2016 as joined work with IEEE: https://webstore.iec.ch/publication/24998


The title is: Precision time protocol profile for=
 power utility automation. It is based on Annex B/IEC 62439.


In o=
ther words, for IEC 61850 installations only part 9-3 applies.



=



I=
=92m a member of of WG10 (IEC 61850) and co-author of several standard docu=
ments.



=



Chee=
rs,


Maik=

From: "Grossman, Ethan A."= ; <eagros@dolby.com>
Date: Wednesday, 5 April 2017 at 21= :37
To: Cisco Employee <maseewal@cisco.com>, "detnet@ietf.org" <detnet@ietf.org>
Subject: RE: [Detnet] I-D Action: d= raft-ietf-detnet-use-cases-12.txt

Thanks Maik. I don=92t know the technical aspects o= f these statements =96 I would like at least one other expert to please wei= gh in on whether these are appropriate changes.

Thanks,

Ethan.

 

From: Maik Seewald (maseewal) [mailto:maseewal@cisco.com]
Sent: Wednesday, April 05, 2017 7:48 AM
To: Grossman, Ethan A. <eagro= s@dolby.com>; detnet@ietf.org
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-12.txt=

 

Ethan, all, 

 

A few comments on section: 3.1.1.2 Intr= a-Substation Process Bus Communications

 

The CT/VT in the substation send the=

sampled value (analog voltage or current) to the MU over hard wir= e. =97> Typic= ally, the CT/VT send analog values. A Merging Unit (MU) converts the a= nalog values into digital values, typically into Sampled Values (IEC 61850-= 9-2)

 

The MU sends the time-synchronized 6= 1850-9-2 sampled values to the

IEDs in the substation in GOOSE message format. =97> Sampl= ed Values (SV) are defined in IEC 61850-9-2. SV are not sent as GOOSE&= nbsp;messages (IEC 61850-8-1). They are sent as Sampled Values, completely = defined in IEC 61850-9-2.

 

Cheers. Maik

 

 

 

On 04/04/2017, 07:15, "detnet on b= ehalf of Grossman, Ethan A." <detnet-bounces@ietf.org on behalf of eagros@dolby.com> wrote:

 

Hi All,

This new version 12 of the DetNet Use C= ases draft is primarily intended to prevent it from expiring, so that we ca= n do WGLC. It does contain a few minor tweaks due to feedback received from the list since publication of version 11.

I know that there are still some additi= ons that are being considered for this draft, and I expect there will be at= least one more revision to incorporate them (before or as a result of WGLC).

Best,

Ethan.

 

-----Original Message-----

Sent: Tuesday, April 04, 2017 12:08 AM<= o:p>

Subject: [Detnet] I-D Action: draft-iet= f-detnet-use-cases-12.txt

 

 

A New Internet-Draft is available from = the on-line Internet-Drafts directories.

This draft is a work item of the Determ= inistic Networking of the IETF.

 

      &nb= sp; Title           = : Deterministic Networking Use Cases

      &nb= sp; Authors         : Ethan Gr= ossman

      &nb= sp;            =        Craig Gunther

      &nb= sp;            =        Pascal Thubert<= /p>

      &nb= sp;            =        Patrick Wetterwald

      &nb= sp;            =        Jean Raymond

      &nb= sp;            =        Jouni Korhonen<= /p>

      &nb= sp;            =        Yu Kaneko

      &nb= sp;            =        Subir Das

      &nb= sp;            =        Yiyong Zha

      &nb= sp;            =        Bal=E1zs Varga<= /p>

      &nb= sp;            =        J=E1nos Farkas<= /p>

      &nb= sp;            =        Franz-Josef Goetz

      &nb= sp;            =        Juergen Schmitt=

      &nb= sp;            =        Xavier Vilajosana

      &nb= sp;            =        Toktam Mahmoodi=

      &nb= sp;            =        Spiros Spirou

      &nb= sp;            =        Petra Vizarreta=

Filename     &= nbsp;  : draft-ietf-detnet-use-cases-12.txt

Pages     &nbs= p;     : 81

Date      = ;      : 2017-04-03

 

Abstract:

   This draft documents requi= rements in several diverse industries to

   establish multi-hop paths = for characterized flows with deterministic

   properties.  In = this context deterministic implies that streams can

   be established which provi= de guaranteed bandwidth and latency which

   can be established from ei= ther a Layer 2 or Layer 3 (IP) interface,

   and which can co-exist on = an IP network with best-effort traffic.

 

   Additional requirements in= clude optional redundant paths, very high

   reliability paths, time sy= nchronization, and clock distribution.

 

   Industries considered incl= ude wireless for industrial applications,

   professional audio, electr= ical utilities, building automation

   systems, radio/mobile acce= ss networks, automotive, and gaming.

 

   For each case, this docume= nt will identify the application, identify

   representative solutions u= sed today, and what new uses an IETF DetNet

   solution may enable.<= /o:p>

 

 

The IETF datatracker status page for th= is draft is:

 

There are also htmlized versions availa= ble at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

detnet mailing list

_______________________________________= ________

detnet mailing list

 

 --_000_D50C11B05DBC4maseewalciscocom_-- From nobody Wed Apr 19 12:38:44 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3145129C25 for ; Wed, 19 Apr 2017 12:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 lZYSm1bbW9_C for ; Wed, 19 Apr 2017 12:38:41 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 72BF5129C01 for ; Wed, 19 Apr 2017 12:38:41 -0700 (PDT) Received: (qmail 6577 invoked by uid 0); 19 Apr 2017 19:38:36 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 19 Apr 2017 19:38:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id AKeZ1v00p2SSUrH01KecTH; Wed, 19 Apr 2017 13:38:36 -0600 X-Authority-Analysis: v=2.2 cv=QdwWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=idbB8FVpqfxHGxdvH6MA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w9UTpUpxrdNkAQ/3LeDkFxDnOlNE8uSyLTkSs7vOUJM=; b=yBge2dXzuRKSBm0jWnh8REZqdg 5w7xxvC8EOub6zbukrBglZYeEsYEceCG0R35C4XdRgl8AOhboMmgyqB1fFi83n0wNs2NoyyrNSjk5 iOgp7icormfcGVcdgBSSLRMAv; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:38032 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d0vQv-00089w-4r for detnet@ietf.org; Wed, 19 Apr 2017 13:38:33 -0600 To: DetNet WG From: Lou Berger Message-ID: <29bcbe15-1059-7985-738c-fb63f1f7d98a@labn.net> Date: Wed, 19 Apr 2017 15:38:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1d0vQv-00089w-4r X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:38032 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Detnet] Chicago Minutes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:38:43 -0000 Hi, The draft minutes for our Chicago session have been posted, please review and send comments to the list. Comments can also be reflected in the etherpad. Links are: Minutes: https://datatracker.ietf.org/doc/minutes-98-detnet/ Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-detnet?useMonospaceFont=true Thanks, Lou (and Pat) PS Kudos to our note takers From nobody Thu Apr 20 00:40:57 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74B129474 for ; Thu, 20 Apr 2017 00:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 fO_X3xjJfwnv for ; Thu, 20 Apr 2017 00:40:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA39612EB25 for ; Thu, 20 Apr 2017 00:40:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLJ80336; Thu, 20 Apr 2017 07:40:45 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Apr 2017 08:39:36 +0100 Received: from DGGEMM508-MBS.china.huawei.com ([169.254.4.204]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 20 Apr 2017 15:38:47 +0800 From: zhayiyong To: DetNet WG Thread-Topic: Traffic description in DetNet flow info model Thread-Index: AdK5qSSYqSHwGD/BTl6GOqTnuhSZHw== Date: Thu, 20 Apr 2017 07:38:46 +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.61.15.96] Content-Type: multipart/alternative; boundary="_000_E78F7186ADD5404AB48E27F02660CA07806C9BDCdggemm508mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58F865FE.001A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.204, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a1a858e89f2df88ed00fe8d723161390 Archived-At: Subject: [Detnet] Traffic description in DetNet flow info model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 07:40:56 -0000 --_000_E78F7186ADD5404AB48E27F02660CA07806C9BDCdggemm508mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Recently we have some discussion among authors of the two flow info model d= raft. The DetNet flow info model should provide some common concepts and de= scription of the flow. One part is traffic specification of the flow. Here = is something not clear, is DetNet dealing with VBR flows and what attribute= s are needed? And how to deal with VBR flow, for source guarantee purpose, = do we need to define shaping parameters? In architecture draft, section 4.1.2, "The traffic characteristics of an Ap= p-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In secti= on 4.3.2, mentions synchronous flow and asynchronous flow, but no details o= f that. In use case draft, for some cases such as industrial and BAS, it can assume= s that the traffic is periodic with constant rate. For cases such as Cellul= ar Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP= traffic is between two eNBs, it is hard to say the flow is constant rate. Cheers, Yiyong --_000_E78F7186ADD5404AB48E27F02660CA07806C9BDCdggemm508mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Recently we have some discussion among authors of th= e two flow info model draft. The DetNet flow info model should provide some= common concepts and description of the flow. One part is traffic specifica= tion of the flow. Here is something not clear, is DetNet dealing with VBR flows and what attributes are needed= ? And how to deal with VBR flow, for source guarantee purpose, do we need t= o define shaping parameters?

 

In architecture draft, section 4.1.2, “The tra= ffic characteristics of an App-flow can be CBR (constant bit rate) or VBR (= variable bit rate)”. In section 4.3.2, mentions synchronous flow and = asynchronous flow, but no details of that.

In use case draft, for some cases such as industrial= and BAS, it can assumes that the traffic is periodic with constant rate. F= or cases such as Cellular Radio and M2M, there is usually no assumption on = the traffic. E.g., CoMP traffic is between two eNBs, it is hard to say the flow is constant rate. =

 

Cheers,

Yiyong

--_000_E78F7186ADD5404AB48E27F02660CA07806C9BDCdggemm508mbschi_-- From nobody Thu Apr 20 02:27:09 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D709112EBC1 for ; Thu, 20 Apr 2017 02:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 E1D0GXkAdsxb for ; Thu, 20 Apr 2017 02:27:05 -0700 (PDT) Received: from know-smtprelay-omc-10.server.virginmedia.net (know-smtprelay-omc-10.server.virginmedia.net [80.0.253.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD08912EBBF for ; Thu, 20 Apr 2017 02:27:03 -0700 (PDT) Received: from [192.168.4.61] ([82.21.85.55]) by know-smtprelay-10-imp with bizsmtp id AZT01v00W1BdnUJ01ZT1kJ; Thu, 20 Apr 2017 10:27:01 +0100 X-Originating-IP: [82.21.85.55] X-Authenticated-User: X-Spam: 0 X-Authority: v=2.1 cv=DPhymH5b c=1 sm=1 tr=0 a=JBiNpTwF/IB2dYUHhn0UHw==:117 a=JBiNpTwF/IB2dYUHhn0UHw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=-O5YPv7yAAAA:8 a=le6d79QuAAAA:8 a=48vgC7mUAAAA:8 a=WmfpMMCmeeax00oqlN0A:9 a=pILNOxqGKmIA:10 a=ns13WE7amoM8ChYu:21 a=_W_S_7VecoQA:10 a=TLqBRRHTddABEfEY9lce:22 a=QbAMNLWdp4a7deKPGBBn:22 a=w1C3t2QeGrPiZgrLijVG:22 From: John Grant Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-17--1022854616 Date: Thu, 20 Apr 2017 10:27:00 +0100 In-Reply-To: To: DetNet WG References: Message-Id: <3B18D368-5822-4007-88F8-A02C875D7BAE@ninetiles.com> X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [Detnet] Traffic description in DetNet flow info model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:27:08 -0000 --Apple-Mail-17--1022854616 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 As pointed out in 4.1.2, for a VBR flow you have to make a reservation = for the peak rate, and there isn't any reason to do anything other than = use the service that is already defined for CBR. With circuit-switched = systems any part of the reservation that wasn't used was wasted, but in = packet-based systems it can be used for best-effort traffic, as stated = in 4.3.2. Regarding synchronous flows, the first paragraph of 4.3.2 explains that = if the reservations on incoming and outgoing links are time-aligned then = the latency, and hence the amount of buffer space required, can be = minimised. The details mechanism for achieving that would, I think, be = out of scope for an architecture document. For a description of a system that implements synchronous flows, see = clause 5 of ETSI GR NGP 003, available from the "specifications" tab at = http://www.etsi.org/technologies-clusters/technologies/next-generation-pro= tocols John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 20 Apr 2017, at 08:38, zhayiyong wrote: > Hi All, > =20 > Recently we have some discussion among authors of the two flow info = model draft. The DetNet flow info model should provide some common = concepts and description of the flow. One part is traffic specification = of the flow. Here is something not clear, is DetNet dealing with VBR = flows and what attributes are needed? And how to deal with VBR flow, for = source guarantee purpose, do we need to define shaping parameters? > =20 > In architecture draft, section 4.1.2, =93The traffic characteristics = of an App-flow can be CBR (constant bit rate) or VBR (variable bit = rate)=94. In section 4.3.2, mentions synchronous flow and asynchronous = flow, but no details of that. > In use case draft, for some cases such as industrial and BAS, it can = assumes that the traffic is periodic with constant rate. For cases such = as Cellular Radio and M2M, there is usually no assumption on the = traffic. E.g., CoMP traffic is between two eNBs, it is hard to say the = flow is constant rate. > =20 > Cheers, > Yiyong > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --Apple-Mail-17--1022854616 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://www.etsi.org/technologies-clusters/technologies/nex= t-generation-protocols

John Grant
Nine Tiles, = Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 20 Apr 2017, at 08:38, = zhayiyong wrote:

Hi All,
 
Recently we have some = discussion among authors of the two flow info model draft. The DetNet = flow info model should provide some common concepts and description of = the flow. One part is traffic specification of the flow. Here is = something not clear, is DetNet dealing with VBR flows and what = attributes are needed? And how to deal with VBR flow, for source = guarantee purpose, do we need to define shaping = parameters?
 
In architecture draft, section 4.1.2, =93The traffic = characteristics of an App-flow can be CBR (constant bit rate) or VBR = (variable bit rate)=94. In section 4.3.2, mentions synchronous flow and = asynchronous flow, but no details of that.
In use case draft, for some cases such as industrial and = BAS, it can assumes that the traffic is periodic with constant rate. For = cases such as Cellular Radio and M2M, there is usually no assumption on = the traffic. E.g., CoMP traffic is between two eNBs, it is hard to say = the flow is constant rate.
Cheers,
Yiyong
___________________________________________= ____
detnet mailing list
Subject: Re: [Detnet] Traffic description in DetNet flow info model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 07:37:55 -0000 --_006_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_ Content-Type: multipart/alternative; boundary="_000_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_" --_000_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, Thank you for the reply. I agree that make reservation on peak rate is a si= mple solution. But the "peak rate" here depends on the observation interval= times max packets per interval, which means for same flow, different inter= val leads to different peak rate. Below is a little testbed we built to tes= t the burstness feature of TCP flow. For the same 25Mbps TCP flow with no shaping: [cid:image007.jpg@01D2BAB5.335C2750] 1s observation interval, peak rate 450Mbps. [cid:image008.jpg@01D2BAB5.335C2750] 100ms observation interval, peak rate 900Mbps. [cid:image009.jpg@01D2BAB5.335C2750] 10ms observation interval, peak rate 1Gbps, which is the link speed/physica= l port speed. And further test shows that, 8 of these TCP flows to a 1Gbps port cause pac= ket loss. So my question is how can we make reservation based on "peak rate= "? E.g., for the same flow, if we take 1s observation interval, we can serv= e 2 flows. But for 10ms observation interval, only 1 flow, which does not m= ake sense. And it is hard to say long observation interval can guarantee de= lay and loss, since buffer in router is only milliseconds level. Another thing is how to guarantee the source with max packets within the in= terval. If shaping is necessary, what kind of parameters are needed. Cheers, Yiyong From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant Sent: Thursday, April 20, 2017 5:27 PM To: DetNet WG Subject: Re: [Detnet] Traffic description in DetNet flow info model As pointed out in 4.1.2, for a VBR flow you have to make a reservation for = the peak rate, and there isn't any reason to do anything other than use the= service that is already defined for CBR. With circuit-switched systems any= part of the reservation that wasn't used was wasted, but in packet-based s= ystems it can be used for best-effort traffic, as stated in 4.3.2. Regarding synchronous flows, the first paragraph of 4.3.2 explains that if = the reservations on incoming and outgoing links are time-aligned then the l= atency, and hence the amount of buffer space required, can be minimised. Th= e details mechanism for achieving that would, I think, be out of scope for = an architecture document. For a description of a system that implements synchronous flows, see clause= 5 of ETSI GR NGP 003, available from the "specifications" tab at http://ww= w.etsi.org/technologies-clusters/technologies/next-generation-protocols John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 20 Apr 2017, at 08:38, zhayiyong wrote: Hi All, Recently we have some discussion among authors of the two flow info model d= raft. The DetNet flow info model should provide some common concepts and de= scription of the flow. One part is traffic specification of the flow. Here = is something not clear, is DetNet dealing with VBR flows and what attribute= s are needed? And how to deal with VBR flow, for source guarantee purpose, = do we need to define shaping parameters? In architecture draft, section 4.1.2, "The traffic characteristics of an Ap= p-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In secti= on 4.3.2, mentions synchronous flow and asynchronous flow, but no details o= f that. In use case draft, for some cases such as industrial and BAS, it can assume= s that the traffic is periodic with constant rate. For cases such as Cellul= ar Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP= traffic is between two eNBs, it is hard to say the flow is constant rate. Cheers, Yiyong _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 <= /p>

Thank you for the reply. = I agree that make reservation on peak rate is a simple solution. But the &#= 8220;peak rate” here depends on the observation interval times max packets per interval, which means for same flow, different interval le= ads to different peak rate. Below is a little testbed we built to test the = burstness feature of TCP flow.

For the same 25Mbps TCP f= low with no shaping:

 <= /p>

1s observation interval, = peak rate 450Mbps.

 <= /p>

100ms observation interva= l, peak rate 900Mbps.

 <= /p>

10ms observation interval= , peak rate 1Gbps, which is the link speed/physical port speed.<= /span>

 <= /p>

And further test shows th= at, 8 of these TCP flows to a 1Gbps port cause packet loss. So my question = is how can we make reservation based on “peak rate”? E.g., for the same flow, if we take 1s observation interval, we can serve 2 flow= s. But for 10ms observation interval, only 1 flow, which does not make sens= e. And it is hard to say long observation interval can guarantee delay and = loss, since buffer in router is only milliseconds level.

 <= /p>

Another thing is how to g= uarantee the source with max packets within the interval. If shaping is nec= essary, what kind of parameters are needed.

 <= /p>

Cheers,=

Yiyong<= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of John Grant
Sent: Thursday, April 20, 2017 5:27 PM
To: DetNet WG
Subject: Re: [Detnet] Traffic description in DetNet flow info model<= o:p>

 

As pointed out in 4.1.2, for a VBR flow you have to = make a reservation for the peak rate, and there isn't any reason to do anyt= hing other than use the service that is already defined for CBR. With circu= it-switched systems any part of the reservation that wasn't used was wasted, but in packet-based systems it ca= n be used for best-effort traffic, as stated in 4.3.2.

 

Regarding synchronous flows, the first paragraph of = 4.3.2 explains that if the reservations on incoming and outgoing links are = time-aligned then the latency, and hence the amount of buffer space require= d, can be minimised. The details mechanism for achieving that would, I think, be out of scope for an architecture doc= ument.

 

 

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 20 Apr 2017, at 08:38, zhayiyong wrote:



Hi All,

 

Recently we have some discussion among = authors of the two flow info model draft. The DetNet flow info model should= provide some common concepts and description of the flow. One part is traffic specification of the flow. Here is something not clear= , is DetNet dealing with VBR flows and what attributes are needed? And how = to deal with VBR flow, for source guarantee purpose, do we need to define s= haping parameters?

 

In architecture draft, section 4.1.2, &= #8220;The traffic characteristics of an App-flow can be CBR (constant bit r= ate) or VBR (variable bit rate)”. In section 4.3.2, mentions synchron= ous flow and asynchronous flow, but no details of that.

In use case draft, for some cases such = as industrial and BAS, it can assumes that the traffic is periodic with con= stant rate. For cases such as Cellular Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP traffic is between two= eNBs, it is hard to say the flow is constant rate.

 

Cheers,

Yiyong

_____________________________________= __________
detnet mailing list
detnet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/detnet

 

--_000_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_-- --_006_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_ Content-Type: image/jpeg; name="image007.jpg" Content-Description: image007.jpg Content-Disposition: inline; filename="image007.jpg"; size=7989; creation-date="Fri, 21 Apr 2017 07:37:36 GMT"; modification-date="Fri, 21 Apr 2017 07:37:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACdAXkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDvvCOh aPN4M0OWXSrJ5H063Zma3QliY1ySccmtf/hHtE/6A9h/4DJ/hVbwZ/yI+g/9g23/APRa1tUAZ3/C PaJ/0B7D/wABk/wo/wCEe0T/AKA9h/4DJ/hWjRQBnf8ACPaJ/wBAew/8Bk/wo/4R7RP+gPYf+Ayf 4Vo0UAZ3/CPaJ/0B7D/wGT/Cj/hHtE/6A9h/4DJ/hWjRQBnf8I9on/QHsP8AwGT/AAo/4R7RP+gP Yf8AgMn+FaNFAGd/wj2if9Aew/8AAZP8KP8AhHtE/wCgPYf+Ayf4Vo0UAZ3/AAj2if8AQHsP/AZP 8KP+Ee0T/oD2H/gMn+FaNFAGd/wj2if9Aew/8Bk/wo/4R7RP+gPYf+Ayf4Vo0UAZ3/CPaJ/0B7D/ AMBk/wAKP+Ee0T/oD2H/AIDJ/hWjRQBnf8I9on/QHsP/AAGT/Cj/AIR7RP8AoD2H/gMn+FaNFAGd /wAI9on/AEB7D/wGT/Cj/hHtE/6A9h/4DJ/hWjRQBnf8I9on/QHsP/AZP8KP+Ee0T/oD2H/gMn+F aNFAGd/wj2if9Aew/wDAZP8ACj/hHtE/6A9h/wCAyf4Vo0UAZ3/CPaJ/0B7D/wABk/wo/wCEe0T/ AKA9h/4DJ/hWjRQBnf8ACPaJ/wBAew/8Bk/wo/4R7RP+gPYf+Ayf4Vo0UAZ3/CPaJ/0B7D/wGT/C j/hHtE/6A9h/4DJ/hWjRQBnf8I9on/QHsP8AwGT/AAo/4R7RP+gPYf8AgMn+FaNFAGd/wj2if9Ae w/8AAZP8KP8AhHtE/wCgPYf+Ayf4Vo0UAZ3/AAj2if8AQHsP/AZP8KP+Ee0T/oD2H/gMn+FaNFAG d/wj2if9Aew/8Bk/wo/4R7RP+gPYf+Ayf4Vo0UAZ3/CPaJ/0B7D/AMBk/wAKxUk8PtPfxjw9YkWR KHbHCzu2QoGwcjJPBOKu2Gi2F5LPe3EUjzi7l+bz5B91zjjdjjAp19o97e3jyg2kKxBjbsinc7Eq w3+2VHTOfbFAFJToJeFW8NWyknbcZt4sWx37AG9csMcZ45pgk0NoiU8KwtM5Bgh+zxBpkIJDjsBh W4PPHvVpdCvy6mSW3xcsHvQN3BEhcBPXrt5x6+1ImiarEI50mtDc2oWK3yG2NGqsuW77vnzxxx70 AQGXw2Hdh4ftjbiPcs4tY8O20NsA65wR7dR2oDaEPKV/DFujlitwv2eI/Z/mC5Y9xkjpnjmpj4au gjWi3EQtUXfExB3+bsCcjpt4z684px0PUZHEsk1sHumP2wLuwF3AjZ6nAxzjrn2oAqy2+h3um6kI 9Btbdo7Z5IXa3j/eJhgHXHTkHrz09a+X6+qn0u6stM1J7mSJ1SyeGDy858sBjls9+QOPT3r5VoA+ svBn/Ij6D/2Dbf8A9FrW1WL4M/5EfQf+wbb/APota2qACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigBAQRkHI9qWs7QP+QHa/7n9TWjQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUxJY5QTG6sFYqcHOCOop9ABRRRQBkaHdM8l5bm1nRUuZiJmA8t/3h4Bzn9K16z9H/497j/r 7n/9GNWhQAUUUUAFFFFAFLWf+QJf/wDXtJ/6Ca+QK+v9Y/5Al/8A9e0n/oJr5AoA+svBn/Ij6D/2 Dbf/ANFrW1WL4M/5EfQf+wbb/wDota2qACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigDO0D/kB2v+5/U1o1naB/yA7X/c/qa0aACiiigAooooAKKKKACiiigAooooAKKKKAMf SrkpdyWu0ESz3MhbPTbIox/49+lbFYOmf8hgf795/wCjY63qACiiigDI0S0SOS8uhJOWkupgUaZi g/eHopOB+ArXrI0S4kd7yA2kyIl1MROxXY/7w8DBz+YFa9ABRRRQAUUUUAVNVGdHvR628n/oJr4+ r7D1IZ0u7HrC/wD6Ca+PKAPrLwZ/yI+g/wDYNt//AEWtbVYvgz/kR9B/7Btv/wCi1raoAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKQnAJpaqXN9HDcw2ww0krhSAeUBVyD/AOOE UAUvClwbnwnpt0yhTNbrIVHQZGcfrWna3CXdpDcxghJkV1DdcEZGawvBdxD/AMIZpEPmL5i2UWVz zyuR+gNaui/8gOw/69o//QRQBdooqtNdiG9trbYT9o3/ADZ+7tGaALNFFFABRRVHUp5YDZ+W+3zL lEbjqpByKAL1FRLcRvcyW6n95Gqswx0DZx/6Car6hdtbCARMu5540cHkhWbH+NAF2iiigAooqC5u 4LSJ5JnAEa7mA5IGcZxQBkaZ/wAhgf795/6NjrerA0tg2rgqQRvvRkHP/LWPNb9ABRRRQBn6P/x7 3H/X3P8A+jGrQrI0S1ZJLy4N1O4e5mAhZh5afvDyBjP61r0AFFFFABRRRQBXvhnT7kesTfyNfHdf Yt5/x4z/APXNv5V8dUAfWXgz/kR9B/7Btv8A+i1rarF8Gf8AIj6D/wBg23/9FrW1QAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVhXv8AyMsP1h/9AuK3a5zVbiODxHbhycyPAigD PJW4A/Dkc0AY3hUr/Z2ix5G9I7TcueV/cyDkduQfyNb/AIJkeXwXpLyOzsbVMsxyTxXJ+GpooNUh aVwgb7GgJ7k/agB+ZroPAdxIdA022JHlrpsLgY5yWcH+QoA6muYubuc6bpt4ZT5/2KaTfgZ3eVnP 5109cfcyxjRtLhLASNptwyr3IEQBP6j86AOtiJaJCTklQTT6ybXUpPtv2R1DBpjGhHG0CJH/AB5J rWoArRXfm31xa7MeQEO7PXdn/CqWqXEb3VrbqT5kV1EzDHZg2P5Gq800kPiBxG5USTQI+O42Scfo Kg1KZIvEUSOTumubZEwOpCzN/JTQAuoXktp4utRGflnMcTjJwQRJ/KoIppLhrWaVt8ki2RZj3PmS U3WHVvGNgqsCVmhDAHkfLJ1qCO5W3GlIysTObKNSOx3TNz/3yaAOmi/5D1yP+nWH/wBCkq9VCL/k P3P/AF6w/wDoUlWFuVa+e02nekayE9sEsP8A2U0AZ2n3lxLqSxSSlkP2rjA/hmCr+Q4rF62lyTyf srf+lD1qaZ/yFl+l5/6UCspnWOyuS7BR9lIyTjk3DgUAP8M3ONbFps6yanLuz/0+AYxXYVxHhr/k bB/uan/6XCu3oAKKKKAOf0/V1t5J7U2F/Iftkw8yO3Jj5kP8XpRqEepSXd7Bp15NI7RqWVnVFibe uFVtpwSm/PB7GtDR/wDj3uP+vuf/ANGNQdD04y3Uvktuu/8AXfvXw3TnGcA8DkYPFAGIl9eAIy3V whsPLWSJ3V/OdpSjBmwMgAcYx1/CkiuNQna3tDqk6/bo0uGmULuiLJIxReMbcoOuTjNbq6HpqNas tooNpnyTk8ZOeeeeeec889aYfD2ktby25s18uaTzHAZh83sc5A68Djk+tAGD/a+otbHUPtbK0q+T 5O0bI/3StvAxnOST1xgipGu76GV4RqEzDT2JBbbm4G9Rh+OcAkcY5wa3jo2nNcyXBtEMksXkuecF MYxjp0AH0Apq6DpiLbKLRcWjFossxIJOSSc/Nzg855ANAGZp9zdSR3QnuXnW4tDcbWAxESWG1cDp gDr3Br5Wr68Om2djbX0lrAsbTqzSEEnJwfyHJ4HHJr5DoA+svBn/ACI+g/8AYNt//Ra1tVi+DP8A kR9B/wCwbb/+i1raoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK4LVHWPx9L I7YVJbRmJ7AJNmu8rz3XyD4vvSO/2fH/AH6moAzrBGj1G0RxhlutOBHofMua3fh7I7LFEWJRNGsi q+hLTZ/kPyrFlk8jU3nIyIbqykbPAwJLo8+lbPhOW30zVNRN1cRxRRWdupkkYKP9dcDvQB3FeYXV /cN4b0q9LL5yaJqW07ePl8sDj6CvRW1PT0liie+t1eZd8amVQXX1HPI5rzC5df8AhD9OXcMjRNSy M9MlMfng/kaAOytru2fxKkEcoZxeTDbz/BBGG/IkfnXT153a3cFj4ykubhwkcN5qDuT2GyD+Z4Fd Pe635vh/Vbi0ZRcWyTCJVkGWZU3D6Egj86AKb3Pn+KbqLZt+z3tsmc/ezCzZ/wDHsVnT6guo6/pU mMSi8tDKAMAM1tO3Hthqgkuy/iiS7hPD6jBIACcN/wAS+VgD6jIFZ+mTO93ZXrADZLp8rAe9lIP5 sKAJri9e48c2Nyo8v7Td2rMoOeDaytj8wPyqDTriW5vNHklcsWbSXI7AtDMTgduTUFlM1xr/AIfn cANK9k5A6ZNlKTj86fo/E+i8HhNJcnHRRBLkn0HI/OgDsFvJbbxhqu07gUsIwrE4UM8oOK1o/wDk Yrj/AK9Iv/Q5K4qXUnuPEUV0JVX7ZNphbYfldf37ce3AP4Vs3mqQWXxAjkIaVZtNRFMeCB++OSfY UAc22p3jQ7TOefMJbAyd2phDz6bRioNQYt5hYk4W4HJzwNVUCmkYXHs3/p2p17z5oHXFzx/3FVoA 39D+TxluHVnvUP08xT/NRXcVw2hOkniyN42DI0t4VYHII3Dmu5oAKKKKAMjRLTZLeXX2i4bzLmZf KaTMa/vDyq9q16yNDvIZJLy0XzPNjupi2YmC48w9GIwfwNa9ABRRRQAUUUUAQXn/AB4z/wDXNv5V 8dV9i3n/AB4z/wDXNv5V8dUAfWXgz/kR9B/7Btv/AOi1rarF8Gf8iPoP/YNt/wD0WtbVABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEVz/wAesv8AuH+VebX3/Ibs/wDrxi/9FV6T c/8AHrL/ALh/lXm19/yG7T2sYs+37qgCK5+7eD++txu99u3b+W5sf7xqK7+XxIc8b7V9vvtM+f8A 0JfzqW5+7df7t1/7JUV782vwydhDdx/lhs/+Pj8qAGSQQ2+nMiQpshDMiMNyqfs5fgH/AGucetW/ JgfSrPSy/mLGEgmAypKs7nB+qtz9ar3ZH2Gfn/lm3/pIamg/4/X/AOu1t/I0AFv8xikPLTNbyyE/ xOztuY+5plvDGXjmKhndoJCWGcMzbGx6ZVFBA64p9t9y2/3bX/0N6Lf7kH+7bf8Ao16AIdRQMYEk ZmS5urZnCAgqgiMHUeu9fT71SSRmCKWOM7EMMDxFCdyeVGsY5/4GT+Apbj55kQ9EjtGH1N3CD+gp 10cmZRz5aTDHoomRR/ICgCBoVim/dlkOnW0zWpDHMRWWOJSPcIxX8akVFsVkNsNhhjlRD1wI2RYx z12gYFEv+uvv+vW4/wDSqKnXP3Ln/duv/Q0oAiNvHa200MecR28sAYnkrGEVM/QZ/M+tFi//ABU9 xGFRY7QeVCiKFCoW3kYH+0xqW66XX0uv5pUFj/yNep/74P4YXmgA1NR9iuDH8rEhQB1JeZJ8D6ZY /WqnhzMv28OSTNaw72PJycOx+pYZP1qXVnZTEqsQrvKGHrixcj9QD+FV/CfKTf8AXnb/APoFAGxZ 3slnd2VwPlVDDDuU8jeELE+wVT7816Vb3CXMZkjzgOycjHKsVP6g15bwY4B2862/9F13fg6WSfw1 DLK7O7TTlmY8n989AG5RRRQBn6P/AMe9x/19z/8Aoxq0KyNEt5Ue8na7leN7qYCBguxP3h5BA3fm TWvQAUUUUAFFFFAEF5/x4z/9c2/lXx1X2Lef8eM//XNv5V8dUAfWXgz/AJEfQf8AsG2//ota2qxf Bn/Ij6D/ANg23/8ARa1tUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAVdTZk0 q7dSVZYHII7Haa8tvOLPqfl0sAc9hJagfkGYfia9R1X/AJBF7/17v/6Ca8uvf+PNv+wZ/wC1bSgC 7q3EmskcbYtSZcdiEyD+BAqaCCKTxNNvjVjbyXXlEjOzNtET+pNVtbkIn1hBxj+1UJ/vD7Mjj9WN XLX/AJGa9/66XH/pLDQBrRQxdfKTLSLn5Rz/AKGaxIrYR60DvLJdahZBkxwoFq5wPqwz9a3oui/9 dF/9IjWRgjVrPIIzqFmRkdR9lkoAzdIO6fRi3Jf+yS2e5MMxP5nmtiy0zGmQQl0MrSWb+Zt/h+1u +3/vkBfwqHw9p6Gy0q7kw2610p4xyNhVZEz78E1rWn+ptv8Adsv/AEfJQBg6KqXOqL5yK4dASpHH y6iQPy2iqbuxMr55lR1b6f2kqH/x0Vt+HQPsCHAz9oQZxz/x/wAtY720h02S7BXy0YxkZ5ydUJH/ AKCaAEvCU88qeWS6Qn1H9pqn/oIA/CjUSYluyhwdl8v4DUI0H/jvH0q14jAF/OAAB5MnT/sIR1V1 X7l59L//ANOSUATarZzwtfQxqWl8jUHATk7ftUJH5IcfnVq8tYrTUPFF/DHsn+yXYD84wIU6Dp/C tXL7/kN3f/YP1D/0bDUmuAnT9ZABJNtqOAP+uaUAYGoWu+9i2oDHDfyIwJ6J/Z64Hvy5/OoDFHbx hYEESmGQEIMZ22MhH5HmtyOBZJdT81D+7lmkTORhhZwDP86yJI3eMsiFljglZyP4R9hcZP4kD8aA JJWzJGxXIjmjG0cZCaeJR+O7n8K7bwaAnh6ONW3KskjK3TIZi4/9Cx+FcSVZ2IVS3709B/1CRXb+ EI3i0JI5FKuhCsp6ghVBFAG5RRRQBkaHdpI95aiOcPHdTEs0LBD+8PRiMH8DWvWfo/8Ax73H/X3P /wCjGrQoAKKKKACiiigCC8/48Z/+ubfyr46r66GqWmoW17HbSMzQowbKFQeCMgnqMgjI44NfItAH 1V4ahup/AGgpaXYtZP7Otj5hjD8eUvGDVr+ztd/6GBf/AACX/Gm+DP8AkR9B/wCwbb/+i1raoAx/ 7O13/oYF/wDAJf8AGj+ztd/6GBf/AACX/GtiigDH/s7Xf+hgX/wCX/Gj+ztd/wChgX/wCX/Gtiq1 pf2t8Z1tphIbaUwygdUcdQfzB/GgCh/Z2u/9DAv/AIBL/jR/Z2u/9DAv/gEv+NbFFAGP/Z2u/wDQ wL/4BL/jR/Z2u/8AQwL/AOAS/wCNbFFAGP8A2drv/QwL/wCAS/40f2drv/QwL/4BL/jWxRQBj/2d rv8A0MC/+AS/40f2drv/AEMC/wDgEv8AjWxRQBj/ANna7/0MC/8AgEv+NH9na7/0MC/+AS/41sUU AY/9na7/ANDAv/gEv+NH9na7/wBDAv8A4BL/AI1sUUAY/wDZ2u/9DAv/AIBL/jR/Z2u/9DAv/gEv +NbFFAHK6jouq397BZXOvMY3hkc+XAY84KDB2uMg7u9Zb+FbhdLvZftKMYfNiWNrMneoZTj72cEo nT04rt2tla9jutx3RxvGF7EMVP8A7KPzqegDjbrwncS6j5Ut9E4u0uHlf7GOrKiMPvcblwPw4qJt DvoINT1L7dCs1u0pybIDzP3aqT97uFA49K7eo5oY7iCSCVd8cilWU9weCKAOZk0XVIr22t11SMpL uYt9hHylUCD+L+6SKrzaNqbQ3Nw2oRtJprZtx9hHzFIzt/i5/wBYw/GuyooA5FNB1GzbT7S31KNY dixrixH7pYgSg+92JPX1oGk6okV95eqRE2RVY1FkDu2KJF/i7M5rrqggt1gluJAxJuJBIQex2qvH /fNAHLQaDqNotlFBqMaJcPucCxHyEbpc/e4+cn86YPDd4YL+1N9F5MLhgv2IfvDnzs/e/wCejE8V 2dFAHGtoV/I9jcS6jD5t6DE+6yHyhgZWGN395RTD4Uubm4vYZr2IrFuw32L7/mMJn/i5y4B/Cuxk hjleN3XLRNuQ+hwRn8ifzqSgDjf7F1OZLG7kv4/NvUaKX/QR8iyrvcfe7si9asJomqT315BJqkYV V5f7CPn8wfP/ABf7IrqqSgDjxpuq3FjZXR1KJmvsCUCxB2iRPmP3vYCli8L3Zu7q0GoRLF5CqW+x D5wwZCud391QPxrqrO3Wzs4bVWLLDGqAnqQBipqAOJg0PUY9Ot7hL2NXvGjWVPsP3QUEZ/iyMIoH 4VKfDF/Nq1zF/b00Z8tJm8pXjBLFgflVwB9wdq7GoxDGJ2nC/vHUIzeoBJA/8eP50AcQnh3VW06C 5OuXoeWREZMy/KC4Un/WdhzVhfCupHUHtj4gvdixK4fdLySSMf6z2H512dFAGJZ+H7i2AL67fuxk MjKgjVGJbJGNpIH41t0UUAFFFFABRRRQBz2n2N5bw3H2qARLb2ht423hvNALHeMdBjHXnOa+VK+x bz/jxn/65t/KvjqgD6y8Gf8AIj6D/wBg23/9FrW1XhmjfHT+yNDsNM/4RzzvsdtHB5n27bv2KFzj yzjOOmau/wDDQn/Urf8Ak/8A/a6APZqK8Z/4aE/6lb/yf/8AtdH/AA0J/wBSt/5P/wD2ugD2avPv D2l6tpfxT1ie4uVgstUDzRWzDd5wQhdwOflIyPXIaua/4aE/6lb/AMn/AP7XUbfH6J5kmbwkjSRg hHN8Cyg9cHy+M4H5UAe1UV4z/wANCf8AUrf+T/8A9ro/4aE/6lb/AMn/AP7XQB7NRXjP/DQn/Urf +T//ANro/wCGhP8AqVv/ACf/APtdAHs1FeM/8NCf9St/5P8A/wBro/4aE/6lb/yf/wDtdAHs1FeM /wDDQn/Urf8Ak/8A/a6P+GhP+pW/8n//ALXQB7NRXjP/AA0J/wBSt/5P/wD2uj/hoT/qVv8Ayf8A /tdAHs1FeM/8NCf9St/5P/8A2uj/AIaE/wCpW/8AJ/8A+10AezUV4z/w0J/1K3/k/wD/AGuj/hoT /qVv/J//AO10AdUtytraTS2t2IG2ob8rMI3M259y7mBAfp16gAdxXb2z+baxSfP8yA/OMNyO47Gv HD+0CpBB8KAgnJ/0/r/5Dp3/AA0J/wBSt/5P/wD2ugD2aivGf+GhP+pW/wDJ/wD+10f8NCf9St/5 P/8A2ugD2aivGf8AhoT/AKlb/wAn/wD7XR/w0J/1K3/k/wD/AGugDv8AVJLRb7WYkmTzWtrZrlFf LhN7ByRnIGw/kR61nRmz86HymTAlH9k7Txt8879nqNuOn8PtXH/8NAruLf8ACKDJ6n7f1/8AIdH/ AA0Eox/xSo+Xp/p/T/yHQB6Z4ZvJLqG5WW6e5kjlw0nmK8ZJH8BAGB/snkVuV4wP2ggv3fCoHfi/ /wDtdL/w0J/1K3/k/wD/AGugD2aivGf+GhP+pW/8n/8A7XR/w0J/1K3/AJP/AP2ugD2OXYInMhwm 07jnGB3riJH0qTSklR4BpsskzwJE4KxybF8scHhzhmA65b1rkv8AhoT/AKlb/wAn/wD7XSD9oBAM DwmoGc4F93/790Adk0rRT3MkdylvqIWT7dI0mwqu5NmWIIX5eFJGBkn1rqdHn+06TbTbpW3oDmYg sfqRwfqOvWvJD+0EpznwqDu4P+n9f/IdKP2g8DA8Lf8Ak/8A/a6APZ6K8Z/4aE/6lb/yf/8AtdH/ AA0J/wBSt/5P/wD2ugD2aivGf+GhP+pW/wDJ/wD+10f8NCf9St/5P/8A2ugD2aivGf8AhoT/AKlb /wAn/wD7XR/w0J/1K3/k/wD/AGugD2aivGf+GhP+pW/8n/8A7XR/w0J/1K3/AJP/AP2ugD2aivGf +GhP+pW/8n//ALXR/wANCf8AUrf+T/8A9roA9fvP+PGf/rm38q+Oq9im/aA86CSL/hGMb1K5+39M j/rnXjtAH//Z --_006_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_ Content-Type: image/jpeg; name="image008.jpg" Content-Description: image008.jpg Content-Disposition: inline; filename="image008.jpg"; size=13776; creation-date="Fri, 21 Apr 2017 07:37:36 GMT"; modification-date="Fri, 21 Apr 2017 07:37:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACvAXkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxoHwd 0zU/DumahJfur3VpFMyi3Q4LICRn8a0P+FH6T/0En/8AAZK7TwZ/yI+g/wDYNt//AEWtbVAHmP8A wo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAH mP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp 1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4 DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk /wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/S f+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/ wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4 DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk /wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/S f+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8Awo/Sf+gk/wD4DJR/wo/Sf+gk/wD4DJXp1FAHmP8A wo/Sf+gk/wD4DJSH4I6QM51Nvl6/6PHxXcW+o6tdTkxaXbfZRM0fmteEPtVypbb5fXgnGfxrNvvs QvNXjZofLea1N2pcfdJAbd6DGAc9qAOY/wCFJaPkD+1GywyP9Hj5o/4Uno2M/wBqNjOM/Z4+vpWv H9nEytAU+0Rsq6bg/N5XmSA7P9naOcdgPaodulfZAmYf7P8AL3nn5ftPk5z/AL/f1z70AZ3/AApL R8kf2o2VGT/o8fFH/CktHO3/AImjfNyv+jx81rSfZzK7TlPtLsy6lk/N5W+PG/8A2dp49ifenRi0 Ew8ryvNjkQaXg9E89w3l+23AOO2O1AGFcfBvRrS2kujfNOsPzNH5CANjquRyPSvCK+ndNFqNF1AW RQxm0haXYcjziDvz/tfdz39a+YqAPrLwZ/yI+g/9g23/APRa1tVi+DP+RH0H/sG2/wD6LWrepEi5 03BIzd/+03oAs/aY/PkgBJkjjEhGOxJA/wDQTUOnajHqEKMoKyGKOR0/u71yBnvUY/5Dd3/16Rf+ hS1R8NdG/wCvO1/9ANAG9RRRQBFJcxx3EUDE75gxQY646/zqWs68/wCQ3p3+7N/IVo0AFFFUdake HRbuSJ2R1iYqynBBxQBeqtqNy9nptzcxgF4YmdQ3QkDNWaoa5/yAb/8A693/APQTQBfppdQwUsAz dBnk06siW4WfxHbRhSDbmVCT3yiN/WgDXooqGK5jmuJoFzvgID5HHIyKAJqKKKACiqmp3MlnYtPE FLBkHzDjlgD/ADqSe6WC4toSpJuHKgjthS39KAJ6KKKAKmp3T2WnTXMYVnjXIDdOtW6ztf8A+QHd f7n9RWjQAUUVUvbmS3ls1TGJp/LbI7bWPH5CgC3RVOeeRNXtIFbEckUrMuOpGzH8zVygAooooAKK j8+L7QbfePNCb9v+znGakoAKQnAJ9KWmv9xvpQBHaXC3dnDcoCqzRrIAeoBGamqlov8AyA7D/r2j /wDQRViW4jhmgifO6diqYHcKW/kDQBLRRRQAUUyZikLuOqqSKisJ3udOtriTG+WJHbHTJANAEGjf 8g8/9fE//o16sfYrTfK/2aHdMMSt5YzIPRvX8az9AtpI4p52u55FluJtsL7dkf71/u4UH8ya16AI hbQB43EMYaJdsZ2jKD0HoKb9jtfL8v7NDs3+Zt2DG7Od2PXPOanooAiNtAXkcwxlpV2yHaMuPQ+o oFtbqYiIIwYRiIhB8gxjA9PwqWigDO1WGKHRrwRRJGGVmYKoGSepPvXyJX19rP8AyB7r/rma+QaA PrLwZ/yI+g/9g23/APRa1b1L/j503/r7/wDaclVPBn/Ij6D/ANg23/8ARa1a1NgLvTASATd8DPX9 1JQAD/kN3f8A16Rf+hS1R8NdG/687X/0A1eH/Ibu/wDr0i/9Clqj4a6N/wBedr/6AaAN6qjXqyW1 48OQ1sWQ7h/EFz+XIq3WPb/8ems/9d5P/QFoABK097o0z43yQOzY9SqmtisSD/XaF/17N/6AtbdA BWfr3/ICvf8Ari38q0KxtTuXn0jWEZQBBmNcdx5atz+LGgC7pbs9q5dix+0TjJOeBKwA/Kma5/yA b/8A693/APQTTtJ/485P+vmf/wBGvTdc/wCQDf8A/Xu//oJoAnursWrQAoW86YRcHpkE5/SslP8A kam/66v/AOiYqu6t9/T/APr8X/0FqpJ/yNTf9dX/APRMVAG9WdY/8hfU/wDfj/8AQBWjWdY/8hfU /wDfj/8AQBQBZvLsWixEoW82ZIuDjG44zVisa8uvtdjaT7NmL9VxnP3ZCuf0rVgmS5t454jmOVA6 nGMgjIoApa7/AMgmT/rpH/6MWlv/APkJ6X/12f8A9FPSa7/yCZP+ukf/AKMWlv8A/kJ6X/12f/0U 9AGhRRRQBlaxPHc+G554W3RyRhlOMZBIrVrnz/yIsf8A16p/StOK83a3c2JkX93bxSqnf5mcE/T5 RQBdrP1T/j403/r7H/ot60Kz9U/4+NN/6+x/6LegAuf+Q9Y/9cZv5pWhWfc/8h6x/wCuM380q+GU sVDAkdRnkUALRRVbTrl7zTba6kUK80SuQvQEjNAFcf8AIyt/15j/ANDNaNZw/wCRlb/rzH/oZrRo Ap21zJLqN7A2NkOzZgc8rk1YEscqP5bq20lWwc4I6iqVl/yGdT+sX/oNN0r/AFd//wBfcv8ASgCb Rf8AkB2H/XtH/wCgimX/APyEdL/67v8A+inp+i/8gOw/69o//QRTL/8A5COl/wDXd/8A0U9AGhUM VzHNPPCobdAwVsjjkA8fgamrPsf+Qrqf/XWP/wBFrQBbuf8Aj2l/3D/KoNI/5A1j/wBe8f8A6CKn uf8Aj2l/3D/KoNI/5A1j/wBe8f8A6CKAKmgX9pPFcWkVxG9xb3E3mxq3zJmV+orXqho3/IPP/XxP /wCjXq/QAUUUUAFFFFAFDW1Z9EvEV9jNEwD4ztOOuPavkKvsDVhnSrkf9MzXx/QB9ZeDP+RH0H/s G2//AKLWma7/AMjB4b/6/Zf/AEnlp/gz/kR9B/7Btv8A+i1pmu/8jB4b/wCv2X/0nloASzkkfxhr cbOxRLS12qTwuTNnFHhro3/Xna/+gGo7aVIfF3iGWRtqJZWrMfQDzs1V8FTGa51EhyyCKz2ZPABt 0PHp1z+NAHWVj2//AB6az/13k/8AQFrYrkYby4HhbxVceafNhuL3y2wPl2qQv5YFAGnB/rtC/wCv Zv8A0Ba26wreRftGgIWG9rV2C55ICJk/qPzrdoAia4jW6jtjnzJEZ144wpAP/oQrDvZov7L8Qt5i YExUncMA+VGMfXNPl/5KDa/9gqb/ANGxVgXv/IteK/8AsL//ABmgDrtHdZLF3Rgym5uMFTkH989V fF91JZ+E9SniCllgIG4cc8f1qPwZ/wAizF/13uP/AEe9M8df8iVqn/XH/wBmFAE+vTvFeaJGoGJ9 RCNn0EUjcfiorIstQmm+IE9oyp5aSz4IHPyw22P/AEM/pWn4j/5CXh3/ALCf/tCasLTP+Sm3X/XW 6/8ARNnQB3VZ1j/yF9T/AN+P/wBAFaNY2jTvNrmvq+MQ3Uca4HbyI2/mxoAzE1KGTQdKljDsl5qh VDjGP3kjZI/4DW/o3/IEsP8Ar2j/APQRXGWP/Ip+F/8AsLn/ANCmrs9G/wCQJYf9e0f/AKCKAI9d /wCQTJ/10j/9GLS3/wDyE9L/AOuz/wDop6reK53t9FDR4y93bRnI7NOin9DTdVuZI/E2g2y48uV5 2bI5ysZx/M0AbCzRM5RZELjOVDDPGM/zH50+uP8ADuoy3Xi69t5ET92bohhwcCZEA/JBXWTuY7eR 16qhIz9KAOV1okfDeEgkfLa9P+usdaEP/JQLz/sFQf8Ao2asi/laf4UWMz43yQWTtjpkvGTWvD/y UC8/7BUH/o2agDerP1T/AI+NN/6+x/6LetCs/VP+PjTf+vsf+i3oALn/AJD1j/1xm/mlJaf8h3UP +ucP/s1U7n/kfdO/7Btz/wCjIao+BXeSC7Z3ZiJHGWOeBNMAPyoA6usa1mkt/BqTxNtkjsN6HGcE JkVs1yuryPF8Lrl43ZGGmHDKcEfJQBrxknxCSepsl/8AQzWnWJDK58cXUJb92mmQMq+hMkoP/oI/ KtugDOsv+Qzqf1i/9BqjDfpaW1zIskWJNUMJLNxywDfiOfyq9Zf8hnU/rF/6DXF3w/4p9v8AsZLj /wBGS0AdvohDaDp5BBBtYyCO/wAopt//AMhHS/8Aru//AKKeo/DH/IqaR/14w/8AoAp+pSJHqOlb 2C7rllXJxk+U/H6UASyXuzV47MtGFNu8zZPzDDKAfpyah06RJNT1Qo6sBLHypz/yzU/yI/Osu9H/ ABXEn/YEk/8ARgqn8NneTS7t5GLuxtizMckn7JBQB1tz/wAe0v8AuH+VZE12LHwhaXLTGFUjttz5 6AsgP6Gte5/49pf9w/yrmfEX/JNx/wBcLb/0JKANTQTfbblZ0t1thcTeSUdi5/evncCMD8Ca16pa T/x5yf8AXzP/AOjXq7QAUUUUAFFFFAFXUxnTbj/cNfHtfYWpusel3LuwVEiZmJ7ADJNfHtAH1l4M /wCRH0H/ALBtv/6LWma7/wAjB4b/AOv2X/0nlp/gz/kR9B/7Btv/AOi1pmu/8jB4b/6/Zf8A0nlo AqOofxD4oU9G063H6TVV+H/3tQH92O0X8rdB/Srf/MyeJv8AsH238pqqfD/7+pf7tr/6IWgDsq4u L/kTvF//AF8ah/I12lcXF/yJ3i//AK+NQ/kaALkX/IweGP8AsGXH8oK6iuI1q+bSl0fU1z/o2kXB GACc7YWxg+ytXb0AYMv/ACUK1/7BM3/o2KsC9/5FrxX/ANhf/wCM1vy/8lCtf+wTN/6NirAvf+Ra 8V/9hf8A+M0AdB4M/wCRZi/673H/AKPemeOv+RK1T/rj/wCzCn+DP+RZi/673H/o96Z46/5ErVP+ uP8A7MKAH+I/+Ql4d/7Cf/tCasLTP+Sm3X/XW6/9E2dbviP/AJCXh3/sJ/8AtCasLTP+Sm3X/XW6 /wDRNnQB3VYOg/8AIe8Sf9f0f/pPFW9WDoP/ACHvEn/X9H/6TxUAc7Y/8in4X/7C5/8AQpq7PR/+ QJYf9e0f/oIrhdu7wHoK5IzqEgyDyP8AX12nhti/hrTSe1si/kMf0oAq+Mf+QFH/ANf9n/6UR0zW f+Rw8OfW5/8ARdP8Y/8AICj/AOv+z/8ASiOmaz/yOHhz63P/AKLoAxPCv/I86j9Lv/0prtbr/j0m /wCubfyrivCv/I86j9Lv/wBKa7W6/wCPSb/rm38qAOOuf+SQ6b/162P/AKHFU+p6hNp/xCh8oKRc wWtu+4fws9wePfKioLgFvhJYoBkxW9or+xR4w35bTTPEBB+IOnkdCbL/ANCuaAO6rG8RXTWkmkMi qxk1KOM57BlYE/rWzWB4mAe70SNuV/tFGx7gHFADrn/kfdO/7Btz/wCjIKyfANxma/tdv3Mybs9d 1xcDH/jv61rXP/I+6d/2Dbn/ANGQVheAP+QrqX/XEf8ApVd0Ad1XIatLHN8J7mSJ1dDppAZTkcLg /rXX1wSf8kUm/wCwfL/NqANl7n7L48uW2bvMsLSLGcY3Szc10lcP4jJHi0kEj/kFdD/09yV3FAGH p0sh8Y63CXJjSC1ZV7AkSZP6D8q5a+/5F9v+xkuP/RktdPpgJ8aa64Hy+RaLn3AkJH6j865i+/5F 9v8AsZLj/wBGS0Adj4Y/5FTSP+vGH/0AVV8R/wDIS8O/9hT/ANoTVa8Mf8ippH/XjD/6AKq+IudU 8PKOWGolyPYQygn82H50AV73/keJP+wJJ/6NFUvhn/yCLn/t1/8ASOCrt7/yPEn/AGBJP/Roql8M /wDkEXP/AG6/+kcFAHYTDMEgP90/yri7uWSf4QWksrl5Hs7Usx6k7krrdTdo9Lu3RirLA5BHY7TX K6kqp8KYkQBVWC3AA7DelAG9odn5P2q5+03EnnXM/wC7kkyiYlf7o7VrVgabr+mRSPYPO4uPtkyb fJcjJmbHOMd/Wr+uG/Glv/ZokNzvQDytm7buG7G/5emetAGhRXL/ANr3oKXCXMhhtFjSeGaNA8rs zK24gcFSB93jrUf2/WPKFt/aI88x/avO8lfu7N3l4xjG7jPXHfPNAHWUVyzavqTv5yXIVL1jDDH5 an7OQ6Luz1J+YnB46e+VXU9SR2Zrzemnuscy+Uo+07pWjyf7pAUHjHOe1AHQX3/HjN/uGvjuvq2w ubyawukvLgTs1vHcK2wLsEgPycdQNvB68818pUAfWXgz/kR9B/7Btv8A+i1qPxAdmseH5epS9bj1 3ROn/s2fwqTwZ/yI+g/9g23/APRa1F4j/wCQlof/AF/D/wBBNAFabjxPreON2mru98bsfzP51W8C DZLdgf8ALSC2c/Xy9v8AICrM/wDyM+s/9gwf1qv4G/11x/1623/oJoA7CuLi/wCRO8X/APXxqH8j XaVylkijR/FEOMp9pujg853Lk0AZHjP/AJF2z/7BM/8A6KWvQa868T/P4f0ZGJIlsHjb1wyqD+hr 0RTlAT3FAGHL/wAlCtf+wTN/6NirDuIzL4d8VqDj/ibE/l5J/pW5L/yUK1/7BM3/AKNirGl+TRfF cZ6nUDJ+BEYH/oJoA1/A8gl8J20gGA8s7YPbMzmp/F6hvCmoKwBBi6H6iqvgX/kW1/67P/Orfi3/ AJFXUP8Arl/UUAVNXYtL4XZiSTfqST3/ANHlrJ08bPiTcsfvG4nAH+y0EHP5xEVq6vxF4dbut7EQ fTKMp/QkfjWVaf8AJS5f+ujf+iqAO5rC0XjxHrwHAMsLH3Pl4z+QA/AVu1haN/yMmvf9dIf/AECg Dl0/5EXw/wD9hJ//AGvXYeGP+RZ0/wD64L/KuPceX8O9OzxLBev/AMBbdJ/Q12Phn/kWtP8A+uC0 AVvGX/IADdku7aQ/RZkY/oDTNaBHizw7IfuhrhSfcx8U/wAZf8i5L/10j/8AQxSa7/yH9B/67yf+ gUAYXhX/AJHnUfpd/wDpTXa3f/HnN/1zb+VcV4V/5HnUfpd/+lNdrd/8ec3/AFzb+VAHJN/yStf+ uK/+jBVbXR/xXNi/aNLFm+m+4H8yKst/yStf+uK/+jBVfWTv8Wo54KfYowPYO7Z/8eP5UAd3WD4k /wCP/RP+v9f5Gt6sHxJ/x/6J/wBf6/yNABeHZ450x+u6yuI8e5aNs/8Ajh/OsP4f86pqZHTygM+/ 2q6OP1H5ity//wCR00n/AK4TfyFYfw7/AOPvVP8Arq//AKOloA7S8/48p/8Arm38q4+6/wCSPXP/ AGD5P612F5/x5T/9c2/lXH3X/JHrn/sHyf1oAb4k48Wc8bjpYHvi8fP8x+ddxXD+Kf8AkabQf9NL L/0qWu4oAw9K/wCRo1z/ALYf+gGuYugG0TB6HxLcA/8AfyWun0r/AJGjXP8Ath/6Aa5q9GzTDGOQ PEkhz/vF2/8AZqAOr8LEnwtpoP8ADbqo+gGB+gqtr3/Ie0H/AK+H/wDQaseFf+RX0/8A64iq+vf8 h7Qf+vh//QaAIL3/AJHiT/sCSf8Ao0VS+Gf/ACCLn/t1/wDSOCrt7/yPEn/YEk/9GiqPw2+XTplH RoLSQ/U26L/JRQB1Oq/8gi9/695P/QTXL6p/ySyP/rjB/wCjErqNV/5BF7/17yf+gmuX1T/klsY7 mGD/ANDSgDptJ/485P8Ar5n/APRr1Pd25urZ4RPLAW6SQkBlPtkEfmKz9DF8PtRne3NsbmfyQiMH H7187iTg/gBWtQBkp4ds45reQSXBEI+ZGfKzHJIZ+OSCzHt1+lRf8ItZ/ZPs/wBpvPv583zRv27d uzOPu7ePX3zzW3RQBkv4ds3muJPMnUTrhUV8LCTglk44JKqe/T60J4dtUkt38+5Yw8uGkGJzuLBp OOSGJPGOTWtRQBkppUGk6bd+XLLIGT70z52KB8qj0UDp/OvkmvsDWIPtWjXtsDjzoHjz/vAj+tfH 9AH1l4M/5EfQf+wbb/8Aotai8R/8hLQ/+v4f+gmpfBn/ACI+g/8AYNt//Ra1H4g+bVdHU9Fn3j67 kX+TmgCrP/yM+s/9gwf1qv4G/wBdcf8AXrbf+gmrEwz4l1lh93+ztufcDJH5MPzqv4E+bzpezW8K 4/3dyn+VAHYVytn/AMg3xR/18XH/AKBXVVytlzpfiZuzTzkH1GzrQBh+JP8AkB6F/wBeZ/kleiJ/ q1+grzzxEC2i6Cqgkm0IAHfhK9CiYNCjKQVKggg8GgDEuB/xXNnIvBFm8Te4Y7v5x1jXP/IO8Vf9 fS/+y1sz/wDI52//AFxH8pKx7ohdC8QyNxmQMx9f3h5/ID8qANPwL/yLa/8AXZ/51b8W/wDIq6h/ 1y/qKq+BgV8OJkYzKzD6HkfoRVnxb/yKuof9cv6igCrrH+o8Pf8AX5D/AOgmsm0/5KXL/wBdG/8A RVamp/6zQvqn/ocVZdj8/wARXkHd3LD+7xIg/PyyaAO5rB0hgviLX2Y4AeEk/wDADW9XPad/yG/E f1j/APRZoA567Ur4FiDDB+3sfz3EV13hn/kW9P8A+uC1yl983hWGM/d8x3x7hRj+Zrq/DP8AyLen /wDXBaAK3jL/AJFyX/rpH/6GKTXf+Q/oP/XeT/0Cl8Zf8i5L/wBdI/8A0MUmu/8AIf0H/rvJ/wCg UAYfhsbPHN8Y/mRvP+b/AH5BIP8APpXaXf8Ax5zf9c2/lXF+F/8Aka7r8P8A0AV2l4QtlOWIAEbE k9uKAOSb/kla/wDXFf8A0YKra1x4ntsdXuId2O4ATH5bj+dWWBHwxjiIIkaMKFPXIfJH5A/lVbVv +Rzs/wAf/begDvKwfEn/AB/6J/1/r/I1vVg+JP8Aj/0T/r/X+RoATUOPGmkn/phN/IVjfD8bNQ1a PrtKMT6l8yH8jJj8K2dR/wCRz0r/AK95v5CsfwF/yFtZ/wC2H/olKAOxvP8Ajyn/AOubfyrloxu+ FxXGd1oRj15PFdTef8eU/wD1zb+Vc1Z/8k8tPpF/6NFAGVqhLeI9GYkkmG25Pf5jXoFed6rxqmnM OCunRsp9CAxB/OvRKAMPSv8AkaNc/wC2H/oBrm9SGdFv9v8ArE1iWRT6bRyf1rpNK/5GjXP+2H/o Brm7s79DupennXc0pHpujU4/WgDqvC3/ACLOn/8AXEVW17/kPaD/ANfD/wDoNWfC/wDyLNh/1xFV te/5D2g/9fD/APoNAFXWmaPxJLcRYDR6VKjH35YD9M1D4DjWE38CDCwCGEf8AQp/7LUutf8AIYvP +vCT/wBAameB+ZdVk7PO2B6bZJU/mpP40AdFqv8AyCL3/r3k/wDQTXN3SGT4f6eoIB2wnn2IP9K6 TVf+QRe/9e8n/oJrnpP+RD0//rnH/KgDc0RxLp3mAEB55mAPvKxrQrF8M2ccNg1ysk5eaSTcrzMy D9433VJwv4AVtUAFFFFABRRRQBDd/wDHrJ9K+Oa+wdV87+ybv7OcTeS3lnGcNjj9cV8fUAfWXgz/ AJEfQf8AsG2//otaj17/AJC+k/8AXT/2pFUngz/kR9B/7Btv/wCi1qPXv+QvpP8A10/9qRUAVpP+ Q5rP/Xs//oEdVfAP/HvJ/wBch/6G9WLl/L1jWmxnFs/H/AI6i8Dx+SLiLOfLXbn1xJIKAOurkbP/ AJAGpf8AXdP5rXXVyNn/AMgDUv8Arun81oAo61/qPDn/AFy/+IrsdK/5BFn/ANe6f+giuN1U+b/w j0I4IjQA+u5S38oj+ddlpX/IIs/+vdP/AEEUAZk//I52/wD1xH8pKxbsbtH1mM8q821h6jc9bU// ACOdv/1xH8pKxbn/AJBerf8AXx/7M9AGx4K/5FyH6L/6AtWvEwzokinkM6Aj1G4cVV8Ff8i5B9F/ 9AWrXiX/AJAz/wDXRP8A0IUAZ+o/e0H/AIB/6HFWbpn/ACUCf6j/ANDu60tR+9oP/AP/AEOKs3TP +SgT/Uf+h3dAHcVzulndqevS9C5GR6bd6f8Asufxroq53Sf+P3W/qf8A0OWgDCvP+RZh/wB6X+S1 1fhn/kWtP/64LXH6sxXwjEw7St/NK7bRlCaYkQ6QvJF9drsuf0oAz/GJzoTRf35F59NuX/8AZcfj RrPz+IdGHTypGc++Rijxf/yCU/66N/6Lel1X/kY9N/z3oAwvC/8AyNd1+H/oArrdY/5At9/17Sf+ gmuS8L/8jXdfh/6AK67WP+QLff8AXtJ/6CaAOfvP+RPj/wCu0n/oT1n6t/yOdn9P/ketC8/5E+P/ AK7Sf+hPWdrJ2+K4pB1iglkA9SqQMP5UAd7WD4k/4/8ARP8Ar/X+RrerB8S8XWkydorsOfcYx/Wg BL75vGViT/yzhIX/AIEJM/8AoArG8CnZq+pd/N2Z9tsMOP8A0M/lWzef8jjaf9cR/wCgzVjeCP8A kL3v4/8Aom2oA7K8/wCPKf8A65t/KuZs/wDknlp9Iv8A0aK6W+/48Lj/AK5N/I1zsXHgsgcATqAP T96KAMPUDuu7VjyVtVQH0XyVOPzY/nXotedX/wDx9W//AFwH/ohK9FoAw9K/5GjXP+2H/oBrl72Q ReGJXIziZuPrEgrprH/kbb//AHP6R1y2qf8AIpTf9dj/AOikoA7Tw7H5OgWkROTGhXPrgkVT17/k O6D/ANfD/wDoNaGif8gmH6t/6EaoeIP+QnpX/XUf+jIqAKetf8hi8/68JP8A0BqZ4F6ah/13l/8A Smen61/yGLz/AK8JP/QGpngXpqH/AF3l/wDSmegDotV/5BF7/wBe8n/oJrnpP+RD0/8A65x/yroN XONGvT6W8n/oJrAm+XwVbx9on8sH1Csyg/pQBoeGb2Kaxa2VJg8Mkm4vC6of3jfdYjDfgTW3WZ4e /wCQNH/10l/9GNWnQAUUUUAFFFFAEN3/AMesn0r45r7B1WSSHSbuWJA8iQsyKejMBkD86+PqAPrL wZ/yI+g/9g23/wDRa1Hr3/IX0n/rp/7Uio8KXENp4A0Se4lSKJNMtyzu2Ao8tepqjq+t6Vc6hYTQ ajbSxW7bpnSUERgyRYLEdBQAmocalrh/6dX/APQI6f4QVk1DVVZSoFzMEBGPl+0SgY9qp32pWL3G p3KXkLQ3UUkMMiuCJHCRfKD3PP6GtCz1Ox0zVLn7feQ2vmB9nnOE3YuJumfqPzoA6auRs/8AkAal /wBd0/mtbP8AwlGgf9Bqx/8AAhf8a5221KxTSru2a7hE9zLG0MZcbpASuCo75oAh1D/j68O/SH/0 VPXZaV/yCLP/AK90/wDQRXIobXU5NPNvKJ5LGODcImzsfEq4b3wTxW3pvibQo9LtEfWLJWWBAQZ1 BB2j3oAJ/wDkc7f/AK4j+UlYtz/yC9W/6+P/AGZ6vS6xpkniSO/S/t2tIo1R5xICisRJgFugNZU9 9aPZX8CXEbS3MnmQIGyZU3P8yjuPegDf8Ff8i5B9F/8AQFq14l/5Az/9dE/9CFZHhbWtL07RIra9 1G2tplVCY5ZQrDMa44NWNa1zSb/T/s1nqVrcTvIm2OKUMzfMOgFACaj97Qf+Af8AocVZumf8lAn+ o/8AQ7up7rV9OuU0mWC+gljtBG1wySAiIb4uW9Oh61Qsb+0h8YS6jLcxpZttK3DNiM5e7x83SgD0 Cud0n/j91v6n/wBDlq7/AMJRoH/Qasf/AAIX/GsW01fTbW4uriW+t4oLxJjHI0gCykSuBg98Z7et AGRrH/Inx/8AXRv5pXc6T/x5yf8AXzP/AOjXrgtVuIZPDgso5Fe6jYu8KnLqpKYJHUDkV1tlr+j2 cc1vc6paQypdT7kkmVWH71uoJoATxf8A8glP+ujf+i3pdV/5GPTf896oeJNb0q/09YbPUba4kDO5 SKUMcCJ8nA7Cl1DWtKn1mzuodRtpIIMebKsoKx5PGT2zQBQ8L/8AI13X4f8AoArrdZ40O/8A+vaT /wBBNcboN3b2OuzX93MlvaTYEc8p2o/7sHhjwa39W8SaHNo97FHq9k7vbyKqrOpLEqcADNAFTUgF 8Nyxj7sd5Mqj0GXrN1v/AJGb/tzuP/RcNXru6tLm3l0lLuL7a+oSjyN2XAJbnb1xjms66kXU71tX t2VrRLKcu4bIB8uEEZ9u/wBDQB6BWD4k+aW0XptJkz64eNcf+P5/CrP/AAlGgf8AQasf/Ahf8ayt Y1jTL2VHtb+3nWCFnlMcgYIvmw8nHQcH8qALd5/yONp/1xH/AKDNWP4JVl1a7JUgMCVJHX91bDir VzrelSeJIL1NRtmto0VHmEoKKxWbAJ6ZqPRr220mW2OpTx2YaGRQZ22ZP7njmgDpdXdo9GvnU4Zb eQg++01jzIsXhm6jQYVL0qo9AJwBUmreJNDm0e9ii1ezeR7eRVVZ1JYlTgAZqndalY/2dd6d9rh+ 2Nfti33jzD+/z93r05oAxr35r+3jHX7GZM+ywxDH/jw/KvRa83E0V7qMM1tIJol024UvH8wDLDAc ZHfI6V2KeKdBKKW1mxyQM/v1/wAaAINOO/xPeSjgOrgD/dKKf1WuW1T/AJFKb/rsf/RSVuWGsabb am13Pf28Vvcef5UryALJiUZwehrn9QuIZfDcttHKrzlvOEanLFDGmGx6H1oA7zRP+QTD9W/9CNUP EHOp6XjnEoJ9v3sVN0vxBo1rYJb3Gq2kUsbOrxvMqsp3Hggmqupazpl1fx3FvqFvLFAkZlkSQFYx 9oi6nt0P5UAGtf8AIYvP+vCT/wBAameBemof9d5f/SmeoNT1SwutSuJre8hljlt2t0dHDBpGVgEB Hc5HFN8K6lY6S19HqN3DaM88xUTuELAXM/TPWgDqNbbZol5xnMLL+Yx/WsS9Ty/Cnl5zsupFz64k erGr+IdFudLngg1W0llkXaiJMpZiT0ABqjeahZTaTLp0V1E94l3MWt1cGQASOT8vXpzQBq+GY7tb FnluInt2kk8qNYSrJ+8bOW3Hd+QrarJ8PzxLpUcbSoH82UbSwznzG7VrUAFFFFABRRTXYIjO3RRk 0AR3f/HrJ9K+Oa+rodYuZtJvp7u1RWhtxcxpE2d0bKWUc/xfKQe1fKNAH1Lolq978NtEtkDHfYWY YK5QldqFuQQRxmpP+EQ07+08/Z5/svk/8/kv393pv9Ks+DP+RH0H/sG2/wD6LWtqgDkYvC9jc6S7 wQztP9pdQftko+VZiCPv/wB0Yq4fCGnHUlP2ef7N5Jz/AKZL9/Ixxv8ATNdCqhRhQAOuBS0AcrJ4 Ptf7NlCW8/2nzm2f6ZL9zzDjnf8A3MVI/hjSRrUMAhn8traRyv2ubqGQA/e9z+dbk2p6fbRLNPfW 0UbkqrvKqhiOoBJpVNpNf70lR7mKPaVV8lVYg8j32igDnn8IW/8AZtyEgn+0mV/KP22X7u/5ed/9 2rL+ENM/tCIrbzfZ/Kff/pcv38rt/i9N1bsU8M5kWKZJDG2xwjA7W9D6GpKAOQu/C9ja6LfzSRTr IjSNE32yXhc/L/H6Vefwjpv9oQlLef7OI3En+mS/eyu3+P03V0DKrqVYBgeoI60tAHKv4Ptjp98F t5/tBaT7N/psvT+H+PirEnhDTft9uY7eb7OEfzf9Ml+98u3+P/erflljhjMksixovVmOAPxppurc XItjPGJyu8RFxuK+uOuKAOWj8L2FxZaosMU5nSSRIP8ATJRg7Rt/i9TVubwhpxvrYx28/wBnCv5o +2S9eNvG/wCtbFs1lHby3VvNGYJGaV5RICuehOenb9KsxyJLGskbq6OAVZTkEeoNAHMP4PtPsmoh befzSX+y/wCmS8DYNv8AHx82aW48M6VHqWnw+TOFl8zev2ubnC5/vV1FIVUsGIBI6HHSgDmX8IWf kajtgn8wlvsv+my9PLXH8fHzZ605/CFgZ7IrbzbBn7R/pkv904/j55rpaY0sayLG0ih3ztUnlsdc DvQBzM/hTT4LXU5WhnUKGa3P2yXgCMf7X97dTk8J6fKmnyJBOUb5pz9sl5BQ4/j/AL2K3JrqwmtJ /NuoPIBMMreaAFJ4Kk54PPSpTJb2iQxPKkQYiOMOwG444Az1PFAHP/8ACIWP+nZgnwT/AKN/pkv9 wf7fHzZoXwfY7NPzbz7gR9p/0yX/AJ5t/t8/NiumooA5aHwxpkt3qUQinJiZREPtk3GUB/vetOTw hZiDTw0E+8Efav8ATZeR5bZ/j5+bFdMFUEkAAnqcdaWgDm4/CGni6uy9vN5R2+R/pkv93n+P1qs3 hewgt9KSaGcTSSIk/wDpkvzHy2J/i9RXTfbbXEx+0w4t/wDXHzB+74z83px60yV7K4mtleaNpM+d AokGWwCNwHcYb9aAMaLwhpwvbkyW83kEJ5I+2S9cHd/H9KhXwfa/YtPDQTmYFPtWb2XptO7+PnnF dKLiFrhrcTIZlUM0YYbgD0OOuKkoA52Lwhpv2+4L2832fYnlf6ZL1+bd/F9Kp2vhexutI0yeOKdp H8ppm+2S8rj5v4666kVQqhVAAHAAHSgDn4/COm/b5y0E/wBn8tPL/wBMl+9lt38f+7VVPB9t/Z1m Gt5/tIePz/8ATZfu5+b+PniupZlRC7sFVRkknAAqNLq3kWJo7iJ1m/1RVwRJxnj149KAMCPwvpDa vcQGGcxpbxMq/a5sAlpAT972H5VFH4Qt/wCzbYNBP9qEiecftsv3d3zc7/7tdFCbWS7nlhkR5lCx S7XztxkgEdj8x/OpIbiG5TfBMkqAldyMGGR1HFAGCvhDTf7RkLW832cwpt/0yX7+W3fx+m2qb+Fr G20qAzwzrcNcRo5+2SnhpQMff/unFddSFQwwwB5zzQBzw8Iad/aTk28/2byV2/6ZL9/Jzxv9MVXX wfa/2agaCf7T54Lf6bL9zzeed/8AcrqqjmuILcKZ5o4g7BFLsF3MegGe9AGAPCGnf2mT9nm+zeSM f6ZL9/d6bvSqkHhexudJ8yGKdp/tLDP2yUfIJiCPv/3QRXUfa7YvKguIt0AzKN4zGMZ+b049aihk sbSw85J4ktOZPNMg2fMc53dMEmgCvbeG9DtCjQ6TaCRG3rK0QZ92c53HJJz3zWnSAgjIOQaWgAoo ooAKa6h0KNyGGDTqKAMaz0uawsrgXVwlwWjWFNqbQIkyFB5OTycn36V8mV9h6jMlvptxPKSI4o2d yBnAAyf0FfHlAH1l4M/5EfQf+wbb/wDota2q848M/FLwXp/hXSbK61ny7i2sYYpU+yzHayoARkJg 8jtWp/wt3wJ/0Hf/ACUn/wDiKAOzorjP+Fu+BP8AoO/+Sk//AMRR/wALd8Cf9B3/AMlJ/wD4igC3 CbC+8Pmzs/s80c19Nbr5YV1QGRi2PT5Mn8qSymtLbXpDlY54XuDdHbyEZ18vPsRjH0NVB8XPAY6a 4B9LSf8A+Io/4W54Dzn+3Ov/AE6T/wDxFAFVpoobF3gnWAQpEl6FmMBkmBkLIXHIfPPvwD1rurdt 9tE+HG5AcP8Ae6d/euP/AOFueA/+g2Of+nSf/wCIpf8AhbvgT/oO/wDkpP8A/EUAdnRXGf8AC3fA n/Qd/wDJSf8A+Io/4W74E/6Dv/kpP/8AEUAb3idrZPDd8120SxCInMpAUH+Hr3zjHvXOax+/124N tPC7SJvjhRMyuDbsPMV/7nbA4z35xUh+LngMjB1zI/69J/8A4ij/AIW54Dzn+3B6f8ek/wD8RQBY FzpjaXdm2MX9nyXUcihF+Rok8rzT6YHOfxpmn3CR6xYrFOWt5zIbaCKYptQvIQ/l9HQjHP8ADx61 F/wtzwHjH9uDH/XpP/8AEUf8Lc8B8f8AE8HHT/RJ/wD4igDtKK4z/hbvgT/oO/8AkpP/APEUf8Ld 8Cf9B3/yUn/+IoA7OsbVJbOLX9IE0sSXDtKse5gHI2HIHfrj9Kxf+Fu+BP8AoO/+Sk//AMRSH4ue AyQTrgyP+nSf/wCIoArW7WsJD3ktlNpMDLE0kUZCMwSQAvnq/Kg+hIHWrmoSQ/ZLOG7w062PkRq6 8i5IjKgf7XQ/n70z/hbngPGP7bGPT7JP/wDEUf8AC3PAZ/5jn/kpP/8AEUAa3h6dn1DUoXuGuHjk y0gnLpyzYXaf9WwAwVHHQ963q4sfFzwGOmudf+nSf/4il/4W74E/6Dv/AJKT/wDxFAHZ0V58fjZ4 NBIEt4cHqLc8/rR/wu3wd/z0vf8AwH/+vTsK5p3Vxpk93qE0clqIbaeGK7jUrnCy7ndx6ZOOfRu1 QWRthfWqhVE0ksUll8vPkB5Cdvou08/Ueoql/wALr8Gc/Pec9f8ARuv60f8AC7PBv/PS84/6d/8A 69FguXbmeGa8untrlIbsmWZpzlSsDRrtYkchT8oz2wfQ10mgzLcaLbyLv2kEDfMZScMRw5+8PQ9x iuO/4XZ4M/v3np/x7f8A16B8bfBoGBJef+A//wBeiwXPQqK8+/4Xb4O/56Xv/gP/APXp0fxr8GPI qNcXcYJwXa2OF9zjJ/IUWC529/LbQWFxNebfs0cbNLvGRtAyc1ztrPpqQ6HP9ps91xfSNDskUhS6 vlFI9CQpx3qqfi74EIwdc/8AJSf/AOIpP+Ft+AuP+J2OOn+hzcf+OUhkumyxIt2tuQtwLYwz7Rg/ aC7bQf8AayT+BHqKpi6tooY57GbZZebGoihmMLSyCNQQpH3mBxlD1OR1FWP+FueA/wDoOf8AkpP/ APEUf8Lc8B/9Bsdc/wDHpP8A/EUAdpRXGf8AC3fAn/Qd/wDJSf8A+Io/4W74E/6Dv/kpP/8AEUAd nWL4onsItPSG8e2ja5fyYpLggCMkHLZPQgZP1xWN/wALd8Cf9B3/AMlJ/wD4ikPxc8Bt11sH62k/ /wARQBPqM2nXF7qKwvb5tEVLpEI8xwZEaRmA5ICjGT6mg3WnLpluZni/s8Xzz4I/diEs4VvTbuK4 /CoP+Ft+Ask/22Mnqfsc/wD8RR/wtzwHjH9uDHp9kn/+IoAsaBM8er21tLNI7NaLtiWdh5KhRgPE eOez9c8V1lcX/wALc8B5z/bnPr9kn/8AiKX/AIW74E/6Dv8A5KT/APxFAHZ0Vxn/AAt3wJ/0Hf8A yUn/APiKP+Fu+BP+g7/5KT//ABFAHZ0Vxn/C3fAn/Qd/8lJ//iKP+Fu+BP8AoO/+Sk//AMRQB1d8 iy2M0bjKuhVh6g8GvjuvpS4+LfgZ4HVdcySOB9kn/wDiK+a6AP/Z --_006_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_ Content-Type: image/jpeg; name="image009.jpg" Content-Description: image009.jpg Content-Disposition: inline; filename="image009.jpg"; size=7963; creation-date="Fri, 21 Apr 2017 07:37:36 GMT"; modification-date="Fri, 21 Apr 2017 07:37:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACgAXkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDo9P8A hF4SutNtbiS2m3ywo7YkGMkAntVj/hTfg/8A59p/+/g/wrrtG/5Alh/17R/+girtAHDyfCDwhIqj 7HIu3urgZ4A549v1PrTP+FN+D/8An2n/AO/g/wAK7uigDhP+FN+D/wDn2n/7+D/Cj/hTfg//AJ9p /wDv4P8ACu7ooA4T/hTfg/8A59p/+/g/wo/4U34P/wCfaf8A7+D/AAru6KAOE/4U34P/AOfaf/v4 P8KP+FN+D/8An2n/AO/g/wAK7uigDhP+FN+D/wDn2n/7+D/Cj/hTfg//AJ9p/wDv4P8ACu7ooA4T /hTfg/8A59p/+/g/wo/4U34P/wCfaf8A7+D/AAru6KAOE/4U34P/AOfaf/v4P8KP+FN+D/8An2n/ AO/g/wAK7uigDhP+FN+D/wDn2n/7+D/Cj/hTfg//AJ9p/wDv4P8ACu7ooA4T/hTfg/8A59p/+/g/ wo/4U34P/wCfaf8A7+D/AAru6KAOE/4U34P/AOfaf/v4P8KP+FN+D/8An2n/AO/g/wAK7uigDhP+ FN+D/wDn2n/7+D/Cj/hTfg//AJ9p/wDv4P8ACu7ooA4T/hTfg/8A59p/+/g/wo/4U34P/wCfaf8A 7+D/AAru6KAOE/4U34P/AOfaf/v4P8KP+FN+D/8An2n/AO/g/wAK7uigDhP+FN+D/wDn2n/7+D/C j/hTfg//AJ9p/wDv4P8ACu7ooA4T/hTfg/8A59p/+/g/wo/4U34P/wCfaf8A7+D/AAru6KAOE/4U 34P/AOfaf/v4P8KP+FN+D/8An2n/AO/g/wAK7uigDhP+FN+D/wDn2n/7+D/Cj/hTfg//AJ9p/wDv 4P8ACu7ooA4T/hTfg/8A59p/+/g/wo/4U34P/wCfaf8A7+D/AAru6KAOE/4U34P/AOfaf/v4P8KP +FN+D/8An2n/AO/g/wAK7uigDhP+FN+D/wDn2n/7+D/CmS/CDwXBC8ssEyRopZmMowAO/Sux1i4m tdIuZrdwkqp8jFdwU9M471BHFqVhDcXF5fNqKJESsEdsqsxHPGDyT0x70AcV/wAK2+HvlW0u9tl2 2yEmUfOfTpSP8Nvh4iXTNIwFmwWf96PkJ7dPXj61ttDcyWsUi2VzI97HJG2YCnlSvIGJIPKrx1/2 R60qwXUMqTNp9wy6e+JQseTN+8Y7kH8WAd34+tAGOPhj4Aa5jtgzGWWLzkXzh8yevTpUS/Dr4ctb w3AmPlTyeVG3nDDN6dK2Bpt81uLAWUqyzKJhJj5EHlMuwt2IJxj3qSZLmY3F2ul3QS9jkt44jFho 2KRqGYfwrlDz7D1oAzLX4X+BJL6SKBGmntGUyxGQHB64IxyOOa+da+rdJgnTUTHJbSx/ZUnV5nXC yl5A6lT34Bz6E18pUAfX+jf8gSw/69o//QRV2qWjf8gSw/69o/8A0EVdoAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKAM3xCwXQbtmIVQmSScADIq9BcQ3MQmt5kmjbo8bBgfxFUfEADaFdggEFMEHvyKvxRRwxiO KNY0HRVGAPwoAfRRRQAUUUUAI33T9K+NK+y2+6fpXxpQB9gaSMaNZD0t4/8A0EVcqrpgxpVoPSBP /QRVqgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAzfEW7+wLzZt3+X8u7pnPGfardn9r+zL9tMJn53eSCF68 Yzz0qp4hIXQbtmIACZJJwAMir0M8VxEJYJUljPR0YMD+IoAkooooAKKKKAEb7p+lfGlfZbfdP0r4 0oA+xNPGNOth6Qp/IVYqCy/48bf/AK5L/Kp6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDN8QANoV2rAEFM EEZBGRV+GGK3jEUMSRIOiooAH4CqHiIsNAvCi7mEeVXOMnPAz2q3aSXEtsr3VutvMc7o1k3gc8c4 GaAJ6KKKACiiigBG+6fpXxpX2W33T9K+NKAPsWz/AOPGD/rmv8qnqCz/AOPGD/rmv8qra7eXNhot zdWiq08agoHUkE5AxgdaALwdWJAYEr1APSnVy3hH7YdS1iS8jeN53hnAePYVDpnbj/Z+79Qa6mgB CQASTgDqTRVHXgx8P6gqH52tZFXnuVIH61zaand3ml+Gbu3kddrg3e8nLIuIn+p3sv4ZoA7Oiiig AooooAKKKKACiiigAooooAKKKKACiiigAopksiQxPLI21EUsx9AOtc1oniqXVfEk2mtDsiMT3Nsx jKmWEFFV+fViw6dqAOoooooAKKKKACiiigAprOq/eYD6mnVyvjO0vL5oYbO4aBxBIWZV3HaxRCR7 jdu9PloA6qioLKZriwt53xukiV2x0yQDU9ABRRRQAhIAJJwB1JpayvECzXFglhBL5RvZBA7hdxCE HdgZ64B57daXRmvUa6s765S6e1dVWVYthYFAeRk8+9AGpTWZUGWYKPc4p1YPibTn1o2elpdPbB2a VpEHO1Rgj8d+PxNAG9RVHR5biXTl+1SrLNHJJG0iptD7XZc4yccD1q9QBna//wAgO6/3R/MVfclU ZgpYgZCjvWd4iRZNAvEcblaPawPcE80+z0TT9MaSXTrSOGZkK5ycH2PtmgCofEWLWznFjIfPj86Z d4zAmQCT/ewT0HoaQ+I3JlWPT5GcsFtV8wD7QNxXOf4cEE89sGoE0HUjZWkLz2qyLEbe52BiDGWB yuf4uMc8c+1O/sHUEZpI7m3327ZsgytjbuLEP+eOPTNAEo8TRFkc2ki2xjzJMWHyPtLbNvfgHn1x SHxJKkX7zTJVnjLNPF5qnyowFJfPfhl4+vpUI8NXBC2zXUZtGTdLhDvMuwpkdtvOfwofQtUlVppL q1FzchorkqjbfKZVX5ec7sIDzxyaANGz1f7beS2/2Zo48MYZSwIlCttY47YOOvUHNfItfW1hpdxa Xskkk0bW8ayLbKqkMA7b23H2IAGO1fJNAH2LZ/8AHjB/1zX+VU9ZaR2sLWOLeZ7tCxLYCqh3k+/C 4x71cs/+PGD/AK5r/Kqt7h9Y02MEblMshH+yF2/zcUAFr/yHdQ/65w/+zVo1nWv/ACHdQ/65w/8A s1aNAGfrvGiXRH9z+tYM0UdvYxrEgSOAXcgRRgYW5RsD8q3deI/sS7GefL/rWLef8eEn/XC//wDR y0AdXRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBl+Jr6PTfDd/dSAkLCVGBnlvlH6kVm6TZLZ /wDCPzEKbl7PyJZAPvLs34Htu5q94ntRfaUlk7bUubmJHOM8bwf6Cpr0BdV0tVAADyAAdv3ZoA0q KKKACiiigAooooAK515Xm8UasjOTHb6ciopP3WYuXI+oEf5V0VY1mY7u61vySrMZBFuxjkRqCPzz QBe0r/kEWf8A1wT/ANBFW6p6O4k0ayZehgT/ANBFXKACiiigDPviG1TTIx94SPJ+AjZf5sKSw/5C up/9dI//AEWtFxh/EFkgIBjglc/TKD+tLaDZrWoJ13LFLn0yCuP/ABz9aANCs+Q7/ENuvTy7WRvr llH9K0Kz0AfxDKx6xWiAf8Cds/8AoA/WgA0hj5d3H2ju5QPxbd/NjWhWdpHW/wD+vx/5CtGgDN8R FhoF4UXcwjyFzjJz0z2q3aS3E1sr3VuLeU53RiQPjn1FVdf/AOQHdf7g/mK0aACiiigAooooARvu n6V8aV9lt90/SvjSgD7Fs/8Ajxg/65r/ACrNngd/GtncDGyLT51bnnLSRY/9BNaVn/x4wf8AXNf5 VStpjL4nv4/LYCG1gG89GJaQ4H04/MUASR8eIp8d7SMn/vt60Kz0/wCRin/69I//AEN60KAOS8SZ /t0spOBp0iPz6nIH/jpP4U26OU1Bf+ecV2f++pF/+JP50/Xf3usSherRrbjP98g4/D515+tMnBP9 qgDJ8i4/9GUAdfRSAhgCCCDyCKWgAooooAKKKKACiiigAooooAKKKKACiiigDP1Ehr3TY+pNwXx7 CN+fzIpL7/kL6X/vyf8AoBouwW1rTgvJUSufYYAz+ZH50upDbeaZIPvfaSufYxvn+QoA0KKKKACi iigAooooAjmlEEEkrDIjUsQPYZrnPANtPa6DKl2zPcvcu8rMcklgG/kRW5qkgi0m8kIyFgc4H+6a ks4Ps1pFD8u5UUMQPvEADP6UAVtB/wCQDY/9cF/lWhWfoP8AyAbH/rgv8q0KACiiigDMjijfxPPc BB5kVmke89QGZjj6cD8qfb/8h69/64QfzkotPm1vUGHKhIUJ/wBoBiR+TD86Lf8A5D17/wBcIP5y UAaFYWjOZvEmvSZJRJIok59IwT9OSR+FbtZmixIpvplQBpbuTLj+LBwPyxigB2kdb/8A6/H/AJCt Gs7SOt//ANfj/wAhWjQBm+Il36BeISw3R4ypwRz2PY1btLZbO2WBZZpQufmmkLsec8k8mqniJtmg XjbWbbHnavU89B71btLg3VsszW81uWz+7mADDnvgkUAT0UUUAFFFFACN90/SvjSvstvun6V8aUAf Ytn/AMeMH/XNf5VXsVB1PUpO/mpH+AjU/wDsxqxZ/wDHjB/1zX+VV9NYPc6jIPutdYH/AAGNFP6g 0AIn/IxT/wDXpH/6G9aFZ6ceIpc8brRMe+HfP8x+YrQoA5PVf+Pz7R/EdWihx227EP58U7/lrqv/ AF73X/oZpuqfNsccq2uR4PrhQp/UEfhTmG271mPqYrafcR0G/wCcfof0NAHSWv8Ax6Q/9c1/lU1Q 2v8Ax6Q/9c1/lU1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFCRg3iCBR1jtZC3/AAJkx/6CaTU/ +PjTf+vv/wBpvQg3+IpmHSO1QH33M2P/AEE0an/x8ab/ANff/tN6ANCiiigAooooAKKKKAKGuMF0 O8B/jhZB9WG0fqRV6s/X/wDkDTfVP/QxWjQBn6D/AMgGx/64L/KtCs/Qv+QRCvaMvGv+6rkD9AK0 KACiiigDPsP+Qnqn/XZP/RSUW/8AyHr7/rhB/OSk0v5rnUpD943RX8AigULx4kkx3s1z7/OaANGq Gjf8eDf9fE//AKNer9Z2gc6Jak9SpJPqcmgB1h/x/wCp/wDXwv8A6Kjq/VCw/wCP/U/+vhf/AEVH V+gDO1//AJAd1/uD+YrRrN8RLv0C8TLLujxlTgjnsexq3aWws7ZYBLNKFz88zl2PPcmgCeiiigAo oooARvun6V8aV9lt90/SvjSgD66uL5tN0FLtbd7gpGn7tM5OcD0PrWTpXifTILKWe6aeFpp3dlFr KwQlsbdwTBPH58V0Nn/x4wf9c1/lVO1s/tOlSW8++Pdcyt6H/XMw6+vFAGNf+KbeHV4J7O2ubs/Z 3Ro/IkjYZZTnDJyOKYfH2I2kOjXIRSQzc4BBwQTt9a6g2yG9W73NvWNowO2CQf6VC+mRPYzWhkfZ NIzk5GQWbccfiaAOSudVgntLOLZMtx/aX2uSI202Uj3EnnZ8xG4dPWnjWrH7T4hnaSVYbuNUik+z TYyEKtu+T5cE96614JG1WC4GPLSCRDz3ZkI/9BNMbTImsrq0Mkmy5Z2Y5GRu64oA5yLxvJCkUDaJ db9nA+bJxjJHy/T86X/hPcI7nRrnbHne3OFx1z8vFdS9sr3kVyWYNEjoAOhDbc5/75FUr+z8nRtU WHfI9wkr7ep3FcYGPpQBiHx26uqHRLoM2dqndk464+WkPj0hXY6NchY87zzheM8/LxxXUSWqS3cF yWYNCGAA6HdjOfyqNtOia3vYS77bwsXOeVyoXj8BQBzh8dsGVTol0C/3R82W+ny0n/CeMA5/sW6x H988/Lxnn5eOCDXTvZo89tMWbNvnaOxyMc1Clkz/ANpRzHCXcnylTztMaL/MGgDn/wDhPG+T/iS3 X7z7n3vm4zx8vPFH/CeN8/8AxJbr939/73y8Z5+XjiulNkha0O9v9FOV9/lK8/gaBZIDdne3+lHL e3yhePwFAHM/8J4xCEaLdYk+4efm4zx8vPAzSjx2xZ1GiXRKfeHzZX6/LxW7NbmFtKhjDskE20tj OAInGT+n51ZSzRJ7mUM2bnG4dhgY4oA5j/hPSVRho1ztk+4ecNxnj5eeKUeO3Z2QaJdFlxuUbsjP TPy10a6dEsFlCHfFmVKHPLYUrz+BqSO1WK6nuQzFpgoIPQbc4x+dAHL/APCe5RHGjXO2TGxucNnp j5eaUeOnLsg0S6LqASvzZAPT+H2Nb1rpx/szToLglZLRYyQpyNyrjH0q0lsqXktyGYtKiIQegC5x j/vo0AczpniyyknuL+9Se2FwY44VEEsm5QDjlUxyWapdX8S2M9uqWi3M9xDNFN5JtZkJUNnqU46H r6VtLpkS2VraiSTZbMjKcjJ29M0RI41u5cq2w20QDY4JDSZH6j86AOdHj7MayDRrkoxAVsnBJOAA dvrS/wDCdP5hj/sS63gbivzZx642+1dCmmRJYw2gkfZDIrg5GSVbcM/jUwtkF893ube8axkdsAk/ +zUAcuPHuYxINGuShO0NzgnOMZ2+vFL/AMJ0/meX/Yl1vxu2/NnHrjbW7Lpxj02O0tyW2TxyZc84 Eoc/pmrX2VPtxu9zbzF5eO2M5oA5f/hPv3fmf2Nc7M7d3OM5xjO314+tL/wnT+Z5f9iXW/G7b82c euNtdF/ZsX2E2nmPsMvm7sjOfM3/AM/0qU2qG+F3ubeIjHjtgkH+lAHJXHjJb1Ill024t4UuI2eZ lZgmyQE8BevBGPWtv/hK9IEgj8y63kEhfsU+SB3xs9xU1tZfatLntpt8Ye5mbjg485mHX14q61sr XqXRZtyRtGB2wSpP/oIoA4+08ZDT7WSIaZPNFFLJ++AZVILk91469DVg+OnDhDol2HYEhcNkgdT9 33H510LaZE1jcWhkk2XDu7HIyCxycU+SCRtVt7gY8uOGVG57sUI/9BNAHNHx9hHkOjXISMkO3OFx 1z8vFKfHTh1Q6JdB2BKqd2Tjr/D710LaZE1nd2pkfbds5c5GRu64qaS2SS7huSzBoVZQB0O7Gc/l QBzuleJ9Nhtrqe7M8DyTvJLGLWVxFwBgsEx0AJ9M1Fe+KoLbWUuLW1uLoS2/l7fJkjYEMT0ZOeD2 rcv7PytI1QQ75HuI5X29TuKYwPyq09qstxb3DMwaANgDocjBzQBy7ePG2SEaNcjy87yc4Q4zz8vH HNXdM8SaTZ6bZ20slwJfLAIFnMdzYy2Pk571sNp8bQ3kRd8XhJc55XKBePwFPazRpbWQs2bbO33y u3n86AOWbxfHZ39+9vYXF1E8quZBG6bcRoCCGXI6Z+hFP/4Txvk/4kt1+8+5975uM8fLzxzXQR2b s+orKcR3T/KVPOPLVT+oNS/Yo8Wg3t/ohyn+18hXn8DQByl34ubUrS5sxpF4jlcYWNnO7ghcBep9 8da6Ww1Rr6Vozp17a7VzuuIwoPsME81YhtUhuLiZWYtOwZgegwoHH5VPQAUUUUAFFFFAGDpc9w+p M8l1JItys7GJiNsXlyBF2jtwefUivlGvsKHTrO1ubi6gt0Sa45lcdWr49oA+uHvLiztbBkt0kgcR pK5k2su4qo2jHPJ9RwKrprl5OJ/JtLdMKZYWmnIV4gxVi2FO08ZxzwRzUz2N3dHS5obiFIbdQzxS xFt5wACCGGCBnGQeue1Qx+HpFWeJ73dE6+VEojwUiL7mUnPJPTPHAHFAD59au4dNs51sUe5uIjK8 Pm4CKq7mw2OTyAOBye1MHiRVmkeW2ItCGEEiNueVlKgjbjjJYAc84PSp9U0q5vnDQ3qwFQUXMW7C MCHHUcngg9iO9V38OOWmRbmFrfawghlg3qhYgtu5+YfLx0xk89KANi3nFzbpMEkjDjOyRdrL7Edj UtVdOtGsNPhtWlMpiXBc55/Mk49OTVqgDGl1i9iea3NjF9q8xFgQT/KwfdjcdvykBGJAB7VDbeJ/ tOqW1mIIl89VJQzfvQSpYkJjlAQVLZ608aLqBjnZ763Nw1yLiGYW5+UjIw4L/MNp28YpsHhyS3uY XjvE8uMB/mhy5kCFc7s/d5ztx1780AOm8QTRXEyCyVkLNHbN5uDLIrKhBGPlG5uvPQ1PZ64txNFa yW0q3J3CYRKXSIhmXluOCVODj8qrv4euHkkZr8YGZLcCH/VysyszHnkblzjjqeelLF4flS9s7p7q MvCWeV0hKu7MSSAd3CEt90g9BzQBuUUUUAR3DSpA7QRrJKB8iM20E+57Vjf8JBOBB/oaHGftRE3E Y8zy8rx83IJ7cD14rWvYp57KaK2nEEzoVSUru2E98ZGfzrJOgTtHaobqGNUjWK4SKEhZEVtyhcsS p7EknOTQBJY6+txHcyTxxxiGL7Qqxy728v5h8wwNrfKeOfrUDeIr1Iir6aguYt0k0Yn4WIKrEg7e WwwGMdc845qaHQGV7ySWaDzLz5JTDbiPdHznPPLHdy36VCfDl48RL6khuZd0c0og4aIqqlQN3Bwo OcnnPHagDUstThv5pkhjm2xHHmtGQj4ODtPfBGDVyszT9Jax1K7u/NTZPgCOOMoOvVuSC3bIA465 rToAKo6reXFhaG5gt0mWPLS75NmEAyccHJ9B+tXqz9Xsbu+ihS2uIYhHKHdZoi6yAdAQGXvg/hQB Hc6tLbyXym1B8hImh/ecymQlQDx8vzDHemHWLk6cjpaRm9ec2/kmXCCQE5+bGduATnGfalutJurq 6vZDdxJFPFGsQWE7o3RiysTuwRknjA7VGdFvBaoqX8YuUkM/mGDKmUk5O3dnbglcZ/GgCOPxKGZJ pLYR2W0CSYyZZJNhcrtxyABjOevatayuxe2yzCGaHJI2TJsYfUVlR+HHiZES8U26puMbwhi0uwpu JzjGDkrjr3q9o+nNpdgLZpVchi2EUqi5P3VBJIA9MmgC/RRRQBRnvbiDU4IGt0NvOSiyCT59+0t9 3HTC9c9+lV11a5NhbXDWaK0t39nlQS5EY8wpkHHzcgce9TPY3ba4l99ohNukWwQtES6k9SG3YGfl 7dB71V/snUv7NjtjfWvmrefaC/2ZtpXfv2439cnrnp2oAm1HVpLK9jhS3EkYCvcOX2mNWbaCBjk5 ye3AqtF4kwrG5spFMm17ZID5jyo27BxgYOFJI5471NeaNcXd6JjeqI2IWWPyuWjVgyqDng5zzzkG qkvhmeW0lge8hk4WOEyW5PlxqWI6MDvG77wI6DjrkA6FWDqGGcEZ5GKWmRIY4UjLs5VQNzdWx3NP oAKx59YvbeHUC9jGZbSMTIiz8OhJ6nHynCk457VsViHSNRax1SB722Ml8W2S/Z2ygPGGG/5sLgDG OmaALsl7cRatDbPbp9nnyqSiT59wUscrjpgYznr2qjN4gmiuJ0FkGjDNHbt5vMsisqkEY+UZbrz0 PHSrC2GoHVReSXduyeR5YQQNlGxyVO7GCccEHgAZqs/h2eSSVnvxjl4QIeY5WKszHnkblyBx1PPS gCxZ64s80VrLbSLdEsswiBdIiGK8tgcEqcHH5Vq1hxeH5lvLS5e6iMkLNJK6QlXdmJJAO7hDn7pz 0HfmtygAooooAKKKKACiiigAooooARvun6V8aV9lt90/SvjSgD//2Q== --_006_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_-- From nobody Fri Apr 21 07:20:27 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED78129435 for ; Fri, 21 Apr 2017 07:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 75C7OKZkkIEz for ; Fri, 21 Apr 2017 07:20:23 -0700 (PDT) Received: from know-smtprelay-omc-10.server.virginmedia.net (know-smtprelay-omc-10.server.virginmedia.net [80.0.253.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B023129498 for ; Fri, 21 Apr 2017 07:20:21 -0700 (PDT) Received: from [192.168.4.61] ([82.21.85.55]) by know-smtprelay-10-imp with bizsmtp id B2LK1v0091BdnUJ012LKqD; Fri, 21 Apr 2017 15:20:19 +0100 X-Originating-IP: [82.21.85.55] X-Authenticated-User: X-Spam: 0 X-Authority: v=2.1 cv=DPhymH5b c=1 sm=1 tr=0 a=JBiNpTwF/IB2dYUHhn0UHw==:117 a=JBiNpTwF/IB2dYUHhn0UHw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=le6d79QuAAAA:8 a=48vgC7mUAAAA:8 a=-O5YPv7yAAAA:8 a=lOLC1Cq7A-aMUTsZPwEA:9 a=pILNOxqGKmIA:10 a=k4VDDrVe2UAf5oMPMSEA:9 a=7N_XiRI_zNfhvV8e:21 a=_W_S_7VecoQA:10 a=QbAMNLWdp4a7deKPGBBn:22 a=w1C3t2QeGrPiZgrLijVG:22 a=TLqBRRHTddABEfEY9lce:22 From: John Grant Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-20--918857148 Date: Fri, 21 Apr 2017 15:20:18 +0100 In-Reply-To: To: DetNet WG References: <3B18D368-5822-4007-88F8-A02C875D7BAE@ninetiles.com> Message-Id: X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [Detnet] Traffic description in DetNet flow info model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 14:20:26 -0000 --Apple-Mail-20--918857148 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 TCP isn't really intended for use with the kind of flows that would use = CBR or VBR. The main facilities provided by TCP are rate control and retransmission = of lost packets. When transferring a block of data (such as, say, an = image or a pre-recorded video or a PDF) over a best-effort service, = these allow the transfer to make best use of what the network provides. = But if the network service guarantees a particular data rate you don't = need the kind of rate control that TCP does, and if the network hardly = ever loses a packet you don't need frequent acknowledgements. For instance, if you are sending live audio with a sampling rate of 48k = samples per second, and packing 12 samples in a packet, you need to send = a packet every 250 microseconds, so you need CBR with a rate of 4000 = packets (of a certain size) per second. The VBR service that was defined for ATM was intended for sending = compressed video at constant quality, so that "busy" content needs more = bits per frame than content with less detail. The peak rate is the bit = rate for the "busiest" content, and the average bit rate was also = signalled. I think the idea was that you could "overbook" a link by = routing flows whose peak rates add up to more than the link capacity, in = the expectation that they wouldn't all be demanding the peak rate at the = same time. I think something similar is done with digital television = multiplexes. Note that with CBR (and VBR) the rate is determined by the application's = requirements, whereas with TCP it is determined by what the best-effort = service delivers. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 21 Apr 2017, at 08:37, zhayiyong wrote: > Hi John, > =20 > Thank you for the reply. I agree that make reservation on peak rate is = a simple solution. But the =93peak rate=94 here depends on the = observation interval times max packets per interval, which means for = same flow, different interval leads to different peak rate. Below is a = little testbed we built to test the burstness feature of TCP flow. > For the same 25Mbps TCP flow with no shaping: > =20 > > 1s observation interval, peak rate 450Mbps. > =20 > > 100ms observation interval, peak rate 900Mbps. > =20 > > 10ms observation interval, peak rate 1Gbps, which is the link = speed/physical port speed. > =20 > And further test shows that, 8 of these TCP flows to a 1Gbps port = cause packet loss. So my question is how can we make reservation based = on =93peak rate=94? E.g., for the same flow, if we take 1s observation = interval, we can serve 2 flows. But for 10ms observation interval, only = 1 flow, which does not make sense. And it is hard to say long = observation interval can guarantee delay and loss, since buffer in = router is only milliseconds level. > =20 > Another thing is how to guarantee the source with max packets within = the interval. If shaping is necessary, what kind of parameters are = needed. > =20 > Cheers, > Yiyong > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant > Sent: Thursday, April 20, 2017 5:27 PM > To: DetNet WG > Subject: Re: [Detnet] Traffic description in DetNet flow info model > =20 > As pointed out in 4.1.2, for a VBR flow you have to make a reservation = for the peak rate, and there isn't any reason to do anything other than = use the service that is already defined for CBR. With circuit-switched = systems any part of the reservation that wasn't used was wasted, but in = packet-based systems it can be used for best-effort traffic, as stated = in 4.3.2. > =20 > Regarding synchronous flows, the first paragraph of 4.3.2 explains = that if the reservations on incoming and outgoing links are time-aligned = then the latency, and hence the amount of buffer space required, can be = minimised. The details mechanism for achieving that would, I think, be = out of scope for an architecture document. > =20 > For a description of a system that implements synchronous flows, see = clause 5 of ETSI GR NGP 003, available from the "specifications" tab at = http://www.etsi.org/technologies-clusters/technologies/next-generation-pro= tocols > =20 > John Grant > Nine Tiles, Cambridge, England > +44 1223 862599 and +44 1223 511455 > http://www.ninetiles.com >=20 > On 20 Apr 2017, at 08:38, zhayiyong wrote: >=20 >=20 > Hi All, > =20 > Recently we have some discussion among authors of the two flow info = model draft. The DetNet flow info model should provide some common = concepts and description of the flow. One part is traffic specification = of the flow. Here is something not clear, is DetNet dealing with VBR = flows and what attributes are needed? And how to deal with VBR flow, for = source guarantee purpose, do we need to define shaping parameters? > =20 > In architecture draft, section 4.1.2, =93The traffic characteristics = of an App-flow can be CBR (constant bit rate) or VBR (variable bit = rate)=94. In section 4.3.2, mentions synchronous flow and asynchronous = flow, but no details of that. > In use case draft, for some cases such as industrial and BAS, it can = assumes that the traffic is periodic with constant rate. For cases such = as Cellular Radio and M2M, there is usually no assumption on the = traffic. E.g., CoMP traffic is between two eNBs, it is hard to say the = flow is constant rate. > =20 > Cheers, > Yiyong --Apple-Mail-20--918857148 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Note that with CBR (and VBR) the = rate is determined by the application's requirements, whereas with TCP = it is determined by what the best-effort service = delivers.

John Grant
Nine Tiles, Cambridge, = England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 21 Apr 2017, at 08:37, zhayiyong wrote:

Hi = John,
Thank = you for the reply. I agree that make reservation on peak rate is a = simple solution. But the =93peak rate=94 here depends on the observation = interval times max packets per interval, which means for same flow, = different interval leads to different peak rate. Below is a little = testbed we built to test the burstness feature of TCP = flow.
For = the same 25Mbps TCP flow with no shaping:
1s = observation interval, peak rate 450Mbps.
100ms = observation interval, peak rate 900Mbps.
10ms = observation interval, peak rate 1Gbps, which is the link speed/physical = port speed.
And = further test shows that, 8 of these TCP flows to a 1Gbps port cause = packet loss. So my question is how can we make reservation based on = =93peak rate=94? E.g., for the same flow, if we take 1s observation = interval, we can serve 2 flows. But for 10ms observation interval, only = 1 flow, which does not make sense. And it is hard to say long = observation interval can guarantee delay and loss, since buffer in = router is only milliseconds level.
From: detnet = [mailto:detnet-bounces@ietf.org] On Behalf Of John = Grant
Sent: Thursday, April 20, 2017 = 5:27 PM
To: DetNet = WG
Subject: Re: [Detnet] Traffic = description in DetNet flow info = model
As pointed out in 4.1.2, for a VBR flow you = have to make a reservation for the peak rate, and there isn't any reason = to do anything other than use the service that is already defined for = CBR. With circuit-switched systems any part of the reservation that = wasn't used was wasted, but in packet-based systems it can be used for = best-effort traffic, as stated in 4.3.2.
 
Regarding synchronous = flows, the first paragraph of 4.3.2 explains that if the reservations on = incoming and outgoing links are time-aligned then the latency, and hence = the amount of buffer space required, can be minimised. The details = mechanism for achieving that would, I think, be out of scope for an = architecture document.
For a description of a system that = implements synchronous flows, see clause 5 of ETSI GR NGP 003, available = from the "specifications" tab at 
 
To: "detnet@ietf.org" , =?iso-8859-1?Q?Bal=E1zs_Varga_A?= CC: "draft-farkas-detnet-flow-information-model@tools.ietf.org" Thread-Topic: Some Comments about the information model Thread-Index: AdK9AHgkJCqeqdxxQI2PTXzNe2FrNA== Date: Mon, 24 Apr 2017 13:41:50 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: multipart/alternative; boundary="_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC1390DGGEMA501MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.58FE00AD.000B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.85, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6e37c76e5936e8b90160a5158b488947 Archived-At: Subject: [Detnet] Some Comments about the information model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 13:42:10 -0000 --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC1390DGGEMA501MBXchina_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bala'zs I have read "draft-farkas-detnet-flow-information-model-00". Thank you for = offering the whole picture of DetNet information model, combining L2 and L3= . Here are some comments and questions after reading the draft: 6.1. Identification and Specification of Flows "Identification options for TSN flows are specified by [IEEE8021CB], which = also includes IP flow identification" So I find the relative contents in [IEEE8021CB] as follows: " The IP Stream identification is a passive Stream identification function = that operates at the transport layer and Internet Protocol interface layer.= " That is to say, the information of this part can only be recognized by the = end station or other "DetNet edge node", which contain the transport layer(= It is different from the transport layer in draft-finn-detnet-architecture-= 08. It is the transport layer in IP/TCP I think). However, the intermediate= node which will forward the DetNet flow should also have the ability to se= parate DetNet flows from other flows, and send them to a special queue or m= ake them go through queuing scheduler, in order to limit the delay in this = node. So whether you have considered DetNet identification in every interme= diate node as described above? 10. Status "AccumulatedLatency is specified as an integer number of nanoseconds. Laten= cy is measured using the time at which the data frame's message timestamp p= oint passes the reference plane marking the boundary between the network me= dia and PHY. The message timestamp point is specified by IEEE Std 802.1AS [= IEEE8021AS] for various media. For a successful Status, the network returns= a value less than or equal to the MaxLatency of the UserToNetworkRequireme= nts (Section 9.3)." If AccumulatedLatency of a particular path is MEASURED, even when it is les= s than the MaxLatency, it can not been proved that all the flows going thro= ugh the path will experience latency which is less than their requirements.= Because MEASUREMENT is only a special case. Maybe AccumulatedLatency shoul= d be defined as a value independent of the Internet conditions, such as a c= alculated value by the theory or other methods? Best Regards, Xuesong --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC1390DGGEMA501MBXchina_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bala'zs=

 

 

I have read “draft-farkas= -detnet-flow-information-model-00”. Thank you for offering the whole = picture of DetNet information model, combining L2 and L3.

 

Here are some comments and ques= tions after reading the draft:

 

6.1. Identification and Specifi= cation of Flows

“Identification options f= or TSN flows are specified by [IEEE8021CB], which also includes IP flow ide= ntification”

 

So I find the relative contents= in [IEEE8021CB] as follows:

“ The IP Stream identification is a pas= sive Stream identification function that operates at the transport layer an= d Internet Protocol interface layer.”

 

That is to say, the information of this part = can only be recognized by the end station or other “DetNet edge node&= #8221;, which contain the transport layer(It is different from the transport layer in draft-finn-detnet-architecture-08. It is the t= ransport layer in IP/TCP I think). However, the intermediate node which wil= l forward the DetNet flow should also have the ability to separate DetNet f= lows from other flows, and send them to a special queue or make them go through queuing scheduler, in orde= r to limit the delay in this node. So whether you have considered DetNet id= entification in every intermediate node as described above?

 

 

10. Status

“AccumulatedLatency is specified as an = integer number of nanoseconds. Latency is measured using the time at which = the data frame’s message timestamp point passes the reference plane marking the boundary between the network media and PHY= . The message timestamp point is specified by IEEE Std 802.1AS [IEEE8021AS]= for various media. For a successful Status, the network returns a value le= ss than or equal to the MaxLatency of the UserToNetworkRequirements (Section 9.3).” <= /p>

 

If AccumulatedLatency of a particular path is= MEASURED, even when it is less than the MaxLatency, it can not been proved= that all the flows going through the path will experience latency which is less than their requirements. Because MEA= SUREMENT is only a special case. Maybe AccumulatedLatency should be defined= as a value independent of the Internet conditions, such as a calculated va= lue by the theory or other methods?

 

 

 

 

 

Best Regards,

 

Xuesong

--_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC1390DGGEMA501MBXchina_-- From nobody Tue Apr 25 00:46:19 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E7C128B38 for ; Tue, 25 Apr 2017 00:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 vSVq2NVu1jhp for ; Tue, 25 Apr 2017 00:46:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2241A127698 for ; Tue, 25 Apr 2017 00:46:14 -0700 (PDT) X-AuditID: c1b4fb2d-c616898000004c5d-4c-58fefec41518 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 4A.74.19549.4CEFEF85; Tue, 25 Apr 2017 09:46:13 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 25 Apr 2017 09:44:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UdKVlruM4FjSTL1BWyl0/YSgWhYzqUE9l5cD7f0VlRo=; b=fM3Py2Th84jNHSTJJ6McjPEWcO4GFa5iuKb8QTYj630+B3amEvbJBANqrQSzQgpfyiyDdReK4AkpK3368kxmXeD8pYJ3vH/jAsOcreILVqr8cUDOiy7cslQmY2E7a7Boj8wmBxjrKP3foOTvR/KjpzUb2pBuAxwYhFTqXNw5TXU= Received: from DBXPR07MB128.eurprd07.prod.outlook.com (10.242.138.156) by DBXPR07MB125.eurprd07.prod.outlook.com (10.242.138.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 07:44:16 +0000 Received: from DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.178]) by DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.178]) with mapi id 15.01.1061.010; Tue, 25 Apr 2017 07:44:14 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Gengxuesong (Geng Xuesong)" , "detnet@ietf.org" CC: "draft-farkas-detnet-flow-information-model@tools.ietf.org" Thread-Topic: Some Comments about the information model Thread-Index: AdK9AHgkJCqeqdxxQI2PTXzNe2FrNAAj5ujQ Date: Tue, 25 Apr 2017 07:44:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [195.50.183.210] x-microsoft-exchange-diagnostics: 1; DBXPR07MB125; 7:YivNeqjJyFZa1Ipk9ftnTE+sz8XSP3nj6dQ42lbzK0qnWJcHqJGw9mqgNMP1+Z+B7pjv4V8le4QH8wTm6VHxCJwLoB2aoJvKvGgwobO7247UexhzCfUPcXdxKo507PFIA5odwH+ou6/T2tFDVx1P5YBKJG1BnLZJgVUHKJdqjNtg9Zoxp5XqHNZTf8Y4pyP3JFiKdj5PEBCHSSLGWO8piZNSKnyRpOAinBuZMa7bt+Lgbv1m1ySlS1kv8nHQ0tWrS+9ldbT6mf5pBsx7PkO5EawZ+xRJ5OApkxzHaQwa86+aJlX75I8WNAKRNt4d8q1qcrQ6KdfnwKRFWxisaOWSZQ== x-ms-office365-filtering-correlation-id: e4d465de-4462-4187-fcce-08d48baedf0a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DBXPR07MB125; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:DBXPR07MB125; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB125; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39850400002)(39450400003)(39860400002)(39410400002)(39400400002)(288314003)(3280700002)(3846002)(102836003)(790700001)(6116002)(7736002)(38730400002)(2906002)(3660700001)(8936002)(7906003)(9326002)(7696004)(74316002)(229853002)(8676002)(81166006)(2900100001)(345774005)(5660300001)(2950100002)(53936002)(6246003)(99286003)(9686003)(33656002)(6306002)(54896002)(236005)(2501003)(189998001)(76176999)(50986999)(4326008)(25786009)(66066001)(54356999)(53546009)(122556002)(86362001)(55016002)(606005)(6506006)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB125; H:DBXPR07MB128.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB1283BD89895C623E15D97A8AC1E0DBXPR07MB128eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 07:44:14.3482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB125 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUhUURjFuW8Zn9rAzSW/RgUZCKRQy8r8Q8pCyYKiTEMsyiEfKq6855KF OailjuVSmkuZSlOWFZYZYzEpmaFtauagidKoE42J4Eq4jfnmTeB/v++c83HPvVyGtGumZUxM QjLLJSji5BIbqjJM4+zxwWQK21n9g/Jdnr1D+f6suUr5asayaX8yKKdjig5SqxeJoPnvc5IT ZLiNXyQbF5PKcl77I2yiv75eJJK+VKGLq3/KSSXqz0UqxDCA94B6zlaFbBg73IigQvebEIcu BFP5TaQwUPgGCbemSqxUyHrduU1Am85dTHUgaJt/RgiGBAfCXN6oRGAHHAEVAwZaYBJnQH2X zpyxxz5gXCqixcw+qNGOkEINB+wNCzVHBZnC22Ban22OSHE45CxpJOK5p2BRW2buYI1D4H5J LSkwwlvg76enhHiUEwwZaswMGINa20OK7AgT4yZa6IxwEYLWjmsWQw7Pi8uQYAAuIKHufYHF OAbZpWqJyBkwa8ijRI6B6+oFC4dD99pNQlyeJqBWo7QsuMDQzJiFX9GgLfcSby+Dkf58JLIL GIff0sXIvWpDc5ETwagsoarML7AZPlYaKFH3hMGyUonIO+Bh3SQpsgdUmNqpjXotsmpAjjzL 8/FR3rs9WS7mAs8nJngmsMlNaP0vvWte9mhBTyYPtiPMIPkmqZ4yhdnRilQ+Pb4dAUPKHaR9 giSNVKRfYrnE81xKHMu3I2eGkjtJ/Vt7w+xwlCKZjWXZJJb77xKMtUyJDnUWrnIvqjuzAtJP x/qdG3yQGqoMcG9Ncx12pg73nalO7mjgjqS4GI/LutNdS3tGHa5s/ay/F1k1neXjlhfq3DuQ Fh95+Y3/y8zUu8X+jXrT3uhBe1ur4G9ZgfWPzwavpERk6loKVQeGKtUzv9aGxyfatHWZuY/c cuQrnUblyRCtnOKjFbu2kxyv+AflvfGyRwMAAA== Archived-At: Subject: Re: [Detnet] Some Comments about the information model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:46:18 -0000 --_000_DBXPR07MB1283BD89895C623E15D97A8AC1E0DBXPR07MB128eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xuesong, thanks for your feedback. - chapter6.1, Identification of flows: Good point, maybe worth to put all the pieces together here. We have relate= d text in three drafts (architecture, data-plane, flow-info). You are correct, intermediate nodes have to recognize DetNet flows for prop= er forwarding (e.g., selecting queues, using the allocated resources, etc.). So it is intended to works as follows (example below is w= ith non-detnet-aware end systems): 1, Source: encapsulates data of the application (that requires detnet treatment in the= network). The flow can be recognized based on L2 and/or L3 fields as defined in the info model. 2,a, Edge node: the info model specifies the identification at the edge. For ingress it is = the same as used by the source. 2,b, Edge node: also has the task to adapt the format of the transported DetNet flow (i.e.,= by additional encapsulation) for the forwarding paradigm of the DetNet domain. This encapsulation is described in the datap= lane-solution draft (still under discussion) and intended to ensure that intermediate nodes in the DetNet domain can easily = recognize and serve DetNet flows. 3, Intermediate node: recognizes detnet flows based on the fields in the encapsulation created by= edge nodes. One more thing worth to add here: the DetNet domain may be configured to se= rve aggregate flows. In such a case intermediate nodes are not able to recognize each individual DetNet flows. Intermediate nodes do recog= nize only the aggregates (for example an LSP dedicated to transport the aggregate of DetNet flows, etc.). See also https://tools.ietf.org/html/draft-ietf-detnet-architecture-01 in c= hapter 4.9 " it is possible that an existing DetNet flow can be used as a carrier for = multiple DetNet sub-flows ... Of course, this requires that the aggregate DetNet flow be provisioned prop= erly to carry the sub-flows." - chapter10, Status: Yes, You are correct. Agree, the "measured" should be replaced with "calcul= ated" or similar. Cheers Bala'zs From: Gengxuesong (Geng Xuesong) [mailto:gengxuesong@huawei.com] Sent: 2017. =E1prilis 24. 15:42 To: detnet@ietf.org; Bal=E1zs Varga A Cc: draft-farkas-detnet-flow-information-model@tools.ietf.org Subject: Some Comments about the information model Hi Bala'zs I have read "draft-farkas-detnet-flow-information-model-00". Thank you for = offering the whole picture of DetNet information model, combining L2 and L3= . Here are some comments and questions after reading the draft: 6.1. Identification and Specification of Flows "Identification options for TSN flows are specified by [IEEE8021CB], which = also includes IP flow identification" So I find the relative contents in [IEEE8021CB] as follows: " The IP Stream identification is a passive Stream identification function = that operates at the transport layer and Internet Protocol interface layer.= " That is to say, the information of this part can only be recognized by the = end station or other "DetNet edge node", which contain the transport layer(= It is different from the transport layer in draft-finn-detnet-architecture-= 08. It is the transport layer in IP/TCP I think). However, the intermediate= node which will forward the DetNet flow should also have the ability to se= parate DetNet flows from other flows, and send them to a special queue or m= ake them go through queuing scheduler, in order to limit the delay in this = node. So whether you have considered DetNet identification in every interme= diate node as described above? 10. Status "AccumulatedLatency is specified as an integer number of nanoseconds. Laten= cy is measured using the time at which the data frame's message timestamp p= oint passes the reference plane marking the boundary between the network me= dia and PHY. The message timestamp point is specified by IEEE Std 802.1AS [= IEEE8021AS] for various media. For a successful Status, the network returns= a value less than or equal to the MaxLatency of the UserToNetworkRequireme= nts (Section 9.3)." If AccumulatedLatency of a particular path is MEASURED, even when it is les= s than the MaxLatency, it can not been proved that all the flows going thro= ugh the path will experience latency which is less than their requirements.= Because MEASUREMENT is only a special case. Maybe AccumulatedLatency shoul= d be defined as a value independent of the Internet conditions, such as a c= alculated value by the theory or other methods? Best Regards, Xuesong --_000_DBXPR07MB1283BD89895C623E15D97A8AC1E0DBXPR07MB128eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Xuesong,

thanks for your fee= dback.

 

- chapter6.1, Id= entification of flows:

Good point, maybe w= orth to put all the pieces together here. We have related text in three dra= fts (architecture, data-plane, flow-info).

You are correct, in= termediate nodes have to recognize DetNet flows for proper forwarding (e.g.= , selecting queues, using the allocated

resources, etc.). S= o it is intended to works as follows (example below is with non-detnet-awar= e end systems):

1, Source:

encapsulates data of the application (that requires detnet treatm= ent in the network). The flow can be recognized based on L2

and/or L3 fields as defined in the info model.<= /p>

2,a, Edge node:

the info model specifies the identification at the edge. For ingr= ess it is the same as used by the source.

2,b, Edge node:

also has the task to adapt the format of the transported DetNet f= low (i.e., by additional encapsulation) for the forwarding

paradigm of the DetNet domain. This encapsulation is described in= the dataplane-solution draft (still under discussion) and

intended to ensure that intermediate nodes in the DetNet domain c= an easily recognize and serve DetNet flows.

3, Intermediate nod= e:

recognizes detnet flows based on the fields in the encapsulation = created by edge nodes.

 

One more thing wort= h to add here: the DetNet domain may be configured to serve aggregate flows= . In such a case intermediate nodes are not

able to recognize e= ach individual DetNet flows. Intermediate nodes do recognize only the aggre= gates (for example an LSP dedicated to transport the

aggregate of DetNet= flows, etc.).

See also https://tools.ietf.org/html/draft-ietf-detnet-architecture-01 in chapte= r 4.9

“ it is possi= ble that an existing DetNet flow can be used as a carrier for multiple DetN= et sub-flows …

Of course, this req= uires that the aggregate DetNet flow be provisioned properly to carry the s= ub-flows.”

 

- chapter10, Sta= tus:

Yes, You are correc= t. Agree, the "measured" should be replaced with "calculated= " or similar.

 

Cheers

Bala’zs<= /o:p>

 

From: = Gengxuesong (Geng Xuesong) [mailto:gengxuesong@huawei.com]
Sent: 2017. =E1prilis 24. 15:42
To: detnet@ietf.org; Bal=E1zs Varga A <balazs.a.varga@ericsson.co= m>
Cc: draft-farkas-detnet-flow-information-model@tools.ietf.org
Subject: Some Comments about the information model=

 =

Hi Bal= a'zs

&nbs= p;

&nbs= p;

I have re= ad “draft-farkas-detnet-flow-information-model-00”. Thank you f= or offering the whole picture of DetNet information model, combining L2 and= L3.

&nbs= p;

Here are = some comments and questions after reading the draft:

&nbs= p;

6.1. Iden= tification and Specification of Flows

“Id= entification options for TSN flows are specified by [IEEE8021CB], which als= o includes IP flow identification”

&nbs= p;

So I find= the relative contents in [IEEE8021CB] as follows:

“ The IP Stream i= dentification is a passive Stream identification function that operates at = the transport layer and Internet Protocol interface layer.”

 

That is to say, the inf= ormation of this part can only be recognized by the end station or other &#= 8220;DetNet edge node”, which contain the transport layer(It is different from the transport layer in draft-finn-detnet-archit= ecture-08. It is the transport layer in IP/TCP I think). However, the inter= mediate node which will forward the DetNet flow should also have the abilit= y to separate DetNet flows from other flows, and send them to a special queue or make them go through queu= ing scheduler, in order to limit the delay in this node. So whether you hav= e considered DetNet identification in every intermediate node as described = above?

 

 

10. Status

“AccumulatedLaten= cy is specified as an integer number of nanoseconds. Latency is measured us= ing the time at which the data frame’s message timestamp point passes the reference plane marking the boundary between th= e network media and PHY. The message timestamp point is specified by IEEE S= td 802.1AS [IEEE8021AS] for various media. For a successful Status, the net= work returns a value less than or equal to the MaxLatency of the UserToNetworkRequirements (Section 9.3).= 221;

 

If AccumulatedLatency o= f a particular path is MEASURED, even when it is less than the MaxLatency, = it can not been proved that all the flows going through the path will experience latency which is less than their re= quirements. Because MEASUREMENT is only a special case. Maybe AccumulatedLa= tency should be defined as a value independent of the Internet conditions, = such as a calculated value by the theory or other methods?

 

 

 

 

 

Best Regards,

 

Xuesong

--_000_DBXPR07MB1283BD89895C623E15D97A8AC1E0DBXPR07MB128eurprd_-- From nobody Tue Apr 25 01:22:00 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B96131A7D for ; Tue, 25 Apr 2017 01:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 hyVhhiAQS2FA for ; Tue, 25 Apr 2017 01:21:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB8A131A40 for ; Tue, 25 Apr 2017 01:21:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLS05452; Tue, 25 Apr 2017 08:21:34 +0000 (GMT) Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Apr 2017 09:21:33 +0100 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.85]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0301.000; Tue, 25 Apr 2017 16:21:28 +0800 From: "Gengxuesong (Geng Xuesong)" To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= , "detnet@ietf.org" CC: "draft-farkas-detnet-flow-information-model@tools.ietf.org" Thread-Topic: Some Comments about the information model Thread-Index: AdK9AHgkJCqeqdxxQI2PTXzNe2FrNAAj5ujQAAKZDbA= Date: Tue, 25 Apr 2017 08:21:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: multipart/alternative; boundary="_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC14FCDGGEMA501MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58FF0710.00A2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.85, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fc5093d01e38c9ac76f04ae3dfc5898b Archived-At: Subject: Re: [Detnet] Some Comments about the information model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:21:59 -0000 --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC14FCDGGEMA501MBXchina_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bala'zs, Thank you for your detailed response. 1. DetNet Identification in the encapsulation sounds good to me. But I am a little confused with the "aggregate of DetNet flows" part, even = after rereading the architecture draft. I cannot figure what kind of condit= ion will make it necessary to aggregate flows or dedicate an LSP to more th= an 1 DetNet flows? (BTW the quote is in chapter 4.7 of the architecture draft, in case anyone= else want to check the context) 2. "calculated" is great, thanks. Best Regards, Xuesong From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A Sent: Tuesday, April 25, 2017 3:44 PM To: Gengxuesong (Geng Xuesong); detnet@ietf.org Cc: draft-farkas-detnet-flow-information-model@tools.ietf.org Subject: Re: [Detnet] Some Comments about the information model Hi Xuesong, thanks for your feedback. - chapter6.1, Identification of flows: Good point, maybe worth to put all the pieces together here. We have relate= d text in three drafts (architecture, data-plane, flow-info). You are correct, intermediate nodes have to recognize DetNet flows for prop= er forwarding (e.g., selecting queues, using the allocated resources, etc.). So it is intended to works as follows (example below is w= ith non-detnet-aware end systems): 1, Source: encapsulates data of the application (that requires detnet treatment in the= network). The flow can be recognized based on L2 and/or L3 fields as defined in the info model. 2,a, Edge node: the info model specifies the identification at the edge. For ingress it is = the same as used by the source. 2,b, Edge node: also has the task to adapt the format of the transported DetNet flow (i.e.,= by additional encapsulation) for the forwarding paradigm of the DetNet domain. This encapsulation is described in the datap= lane-solution draft (still under discussion) and intended to ensure that intermediate nodes in the DetNet domain can easily = recognize and serve DetNet flows. 3, Intermediate node: recognizes detnet flows based on the fields in the encapsulation created by= edge nodes. One more thing worth to add here: the DetNet domain may be configured to se= rve aggregate flows. In such a case intermediate nodes are not able to recognize each individual DetNet flows. Intermediate nodes do recog= nize only the aggregates (for example an LSP dedicated to transport the aggregate of DetNet flows, etc.). See also https://tools.ietf.org/html/draft-ietf-detnet-architecture-01 in c= hapter 4.9 " it is possible that an existing DetNet flow can be used as a carrier for = multiple DetNet sub-flows ... Of course, this requires that the aggregate DetNet flow be provisioned prop= erly to carry the sub-flows." - chapter10, Status: Yes, You are correct. Agree, the "measured" should be replaced with "calcul= ated" or similar. Cheers Bala'zs From: Gengxuesong (Geng Xuesong) [mailto:gengxuesong@huawei.com] Sent: 2017. =E1prilis 24. 15:42 To: detnet@ietf.org; Bal=E1zs Varga A > Cc: draft-farkas-detnet-flow-information-model@tools.ietf.org Subject: Some Comments about the information model Hi Bala'zs I have read "draft-farkas-detnet-flow-information-model-00". Thank you for = offering the whole picture of DetNet information model, combining L2 and L3= . Here are some comments and questions after reading the draft: 6.1. Identification and Specification of Flows "Identification options for TSN flows are specified by [IEEE8021CB], which = also includes IP flow identification" So I find the relative contents in [IEEE8021CB] as follows: " The IP Stream identification is a passive Stream identification function = that operates at the transport layer and Internet Protocol interface layer.= " That is to say, the information of this part can only be recognized by the = end station or other "DetNet edge node", which contain the transport layer(= It is different from the transport layer in draft-finn-detnet-architecture-= 08. It is the transport layer in IP/TCP I think). However, the intermediate= node which will forward the DetNet flow should also have the ability to se= parate DetNet flows from other flows, and send them to a special queue or m= ake them go through queuing scheduler, in order to limit the delay in this = node. So whether you have considered DetNet identification in every interme= diate node as described above? 10. Status "AccumulatedLatency is specified as an integer number of nanoseconds. Laten= cy is measured using the time at which the data frame's message timestamp p= oint passes the reference plane marking the boundary between the network me= dia and PHY. The message timestamp point is specified by IEEE Std 802.1AS [= IEEE8021AS] for various media. For a successful Status, the network returns= a value less than or equal to the MaxLatency of the UserToNetworkRequireme= nts (Section 9.3)." If AccumulatedLatency of a particular path is MEASURED, even when it is les= s than the MaxLatency, it can not been proved that all the flows going thro= ugh the path will experience latency which is less than their requirements.= Because MEASUREMENT is only a special case. Maybe AccumulatedLatency shoul= d be defined as a value independent of the Internet conditions, such as a c= alculated value by the theory or other methods? Best Regards, Xuesong --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC14FCDGGEMA501MBXchina_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bala’zs,

 

Than= k you for your detailed response.

 

1. D= etNet Identification in the encapsulation sounds good to me.

But = I am a little confused with the “aggregate of DetNet flows” par= t, even after rereading the architecture draft. I cannot figure what kind o= f condition will make it necessary to aggregate flows or dedicate an LSP to more than 1 DetNet flows?

(BTW= the quote is in chapter = 4.7 of the architecture draft,  in case anyone else want to check the = context)

 

2. &= #8220;calculated” is great, thanks.

 

Best= Regards,

 

Xues= ong

&n= bsp;

From: detnet [mail= to:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A
Sent: Tuesday, April 25, 2017 3:44 PM
To: Gengxuesong (Geng Xuesong); detnet@ietf.org
Cc: draft-farkas-detnet-flow-information-model@tools.ietf.org
Subject: Re: [Detnet] Some Comments about the information model=

 

Hi X= uesong,

than= ks for your feedback.

 

-= chapter6.1, Identification of flows:

Good= point, maybe worth to put all the pieces together here. We have related te= xt in three drafts (architecture, data-plane, flow-info).=

You = are correct, intermediate nodes have to recognize DetNet flows for proper f= orwarding (e.g., selecting queues, using the allocated

reso= urces, etc.). So it is intended to works as follows (example below is with = non-detnet-aware end systems):

1, S= ource:

encapsulates data of the application (that require= s detnet treatment in the network). The flow can be recognized based on L2

and/or L3 fields as defined in the info model.

2,a,= Edge node:

the info model specifies the identification at the= edge. For ingress it is the same as used by the source.<= /p>

2,b,= Edge node:

also has the task to adapt the format of the trans= ported DetNet flow (i.e., by additional encapsulation) for the forwarding

paradigm of the DetNet domain. This encapsulation = is described in the dataplane-solution draft (still under discussion) and

intended to ensure that intermediate nodes in the = DetNet domain can easily recognize and serve DetNet flows.

3, I= ntermediate node:

recognizes detnet flows based on the fields in the= encapsulation created by edge nodes.

 

One = more thing worth to add here: the DetNet domain may be configured to serve = aggregate flows. In such a case intermediate nodes are not

able= to recognize each individual DetNet flows. Intermediate nodes do recognize= only the aggregates (for example an LSP dedicated to transport the

aggr= egate of DetNet flows, etc.).

See = also https://tools.ietf.org/html/draft-ietf-detnet-architecture-01 in chapte= r 4.9

R= 20; it is possible that an existing DetNet flow can be used as a carrier fo= r multiple DetNet sub-flows …

Of c= ourse, this requires that the aggregate DetNet flow be provisioned properly= to carry the sub-flows.”

 

-= chapter10, Status:

Yes,= You are correct. Agree, the "measured" should be replaced with &= quot;calculated" or similar.

 

Chee= rs

Bala= ’zs

 

From: Gengxuesong (Geng Xuesong) [mailto:gengxuesong@huawei.com]
Sent: 2017. =E1prilis 24. 15:42
To: detnet@ietf.org; Bal=E1zs= Varga A <balazs.a.varga@= ericsson.com>
Cc: draft-farkas-detnet-flow-information-model@tools.ietf.org
Subject: Some Comments about the information model=

 

Hi Bala'zs=

 

 

I have read “draft-farkas= -detnet-flow-information-model-00”. Thank you for offering the whole = picture of DetNet information model, combining L2 and L3.

 

Here are some comments and ques= tions after reading the draft:

 

6.1. Identification and Specifi= cation of Flows

“Identification options f= or TSN flows are specified by [IEEE8021CB], which also includes IP flow ide= ntification”

 

So I find the relative contents= in [IEEE8021CB] as follows:

“ The IP Stream identification is a pas= sive Stream identification function that operates at the transport layer an= d Internet Protocol interface layer.”

 

That is to say, the information of this part = can only be recognized by the end station or other “DetNet edge node&= #8221;, which contain the transport layer(It is different from the transport layer in draft-finn-detnet-architecture-08. It is the t= ransport layer in IP/TCP I think). However, the intermediate node which wil= l forward the DetNet flow should also have the ability to separate DetNet f= lows from other flows, and send them to a special queue or make them go through queuing scheduler, in orde= r to limit the delay in this node. So whether you have considered DetNet id= entification in every intermediate node as described above?

 

 

10. Status

“AccumulatedLatency is specified as an = integer number of nanoseconds. Latency is measured using the time at which = the data frame’s message timestamp point passes the reference plane marking the boundary between the network media and PHY= . The message timestamp point is specified by IEEE Std 802.1AS [IEEE8021AS]= for various media. For a successful Status, the network returns a value le= ss than or equal to the MaxLatency of the UserToNetworkRequirements (Section 9.3).” <= /p>

 

If AccumulatedLatency of a particular path is= MEASURED, even when it is less than the MaxLatency, it can not been proved= that all the flows going through the path will experience latency which is less than their requirements. Because MEA= SUREMENT is only a special case. Maybe AccumulatedLatency should be defined= as a value independent of the Internet conditions, such as a calculated va= lue by the theory or other methods?

 

 

 

 

 

Best Regards,

 

Xuesong

--_000_F1C1D5B02EA3FA4A8AF54C86BA4F325CEC14FCDGGEMA501MBXchina_-- From nobody Tue Apr 25 01:24:08 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA68131A97 for ; Tue, 25 Apr 2017 01:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 3TIwiYWCWs8e for ; Tue, 25 Apr 2017 01:23:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 71517131AA7 for ; Tue, 25 Apr 2017 01:23:46 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-31-58ff07906b1c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 2D.91.20220.0970FF85; Tue, 25 Apr 2017 10:23:44 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 25 Apr 2017 10:20:58 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=acavIU9N7og80jRjZ1xtcebIQvGi0mlviMyP3UyrhsQ=; b=YxR0rqvyQjFAR6NIfrTlEyO09p0/dAaid63PoxOh5Qp9UeT8Bhhz4rj4FAXILeE3RuNjYV1E/70WMfpNMMlCQi/OwPMg/rCBbDJW/GsTyTJVvys20eDysWR/ioejUSY+PwXwnxobKMy+nBrHYft+WdNNAKS0XBdfCtEsmBDudzo= Received: from DBXPR07MB128.eurprd07.prod.outlook.com (10.242.138.156) by DBXPR07MB125.eurprd07.prod.outlook.com (10.242.138.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 08:20:59 +0000 Received: from DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.178]) by DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.178]) with mapi id 15.01.1061.010; Tue, 25 Apr 2017 08:20:57 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: John Grant , DetNet WG Thread-Topic: [Detnet] Traffic description in DetNet flow info model Thread-Index: AdK5qSSYqSHwGD/BTl6GOqTnuhSZHwADx6cAAC54fgAADhBrAAC8F69A Date: Tue, 25 Apr 2017 08:20:57 +0000 Message-ID: References: <3B18D368-5822-4007-88F8-A02C875D7BAE@ninetiles.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ninetiles.com; dkim=none (message not signed) header.d=none; ninetiles.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [195.50.183.210] x-microsoft-exchange-diagnostics: 1; DBXPR07MB125; 7:+NCLb843bad62faS+nOyteK/hz6XeblX47G2IE8pzfGkY1nEr1NYuzE/rhvBAmsmWUlkk5mnuBExKX5iLnmUTT4YlCRcb1cFRbMSzgS951dBndLPmUZFmMXLeZ+nabX7BEubm5CWlAjQtXhvbTSP5f8dcC4VnTC1mEa4g31yYcb/nJBQDa17gOd9Ee7ndpmw6zi7aBrV3t7QQUQZGUkD0naB5goge94QMr9BitO8HSS0y2Rar5m1g0jIxfMAuTqOJbdDcgJ/UXh5748MWDLDG9nCGm7ptLxx3B7/gZweNbU8p/+Id+Ez+InehQPE+M/Hz3AH4x9H0NFOJGq/RzWL3w== x-ms-office365-filtering-correlation-id: a229aae9-292c-4ee1-4dee-08d48bb3ffc9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DBXPR07MB125; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:DBXPR07MB125; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB125; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(377454003)(24454002)(85664002)(57704003)(53754006)(3280700002)(3846002)(102836003)(790700001)(6116002)(7736002)(38730400002)(53386004)(2906002)(3660700001)(7906003)(8936002)(9326002)(7696004)(74316002)(229853002)(8676002)(81166006)(2900100001)(19609705001)(345774005)(5660300001)(2950100002)(53936002)(6246003)(966004)(99286003)(93886004)(9686003)(33656002)(6306002)(54896002)(236005)(189998001)(76176999)(50986999)(25786009)(54356999)(66066001)(53546009)(122556002)(86362001)(606005)(55016002)(6506006)(6436002)(781001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB125; H:DBXPR07MB128.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB128D53355B533A8B2EE651AAC1E0DBXPR07MB128eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 08:20:57.1262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB125 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee+9266jwdvUPNgMG6ikucpKDDQaZUgZKUgsIXLqRZdz2u4c WUSrjHSlTXOShjlT+zJQwtLADxoKOqUkS9IsKif5FaZ9WCoz766B//3O85xzOM/LS5PSeoEv rdEZGL1OrZULxVS5qjko1CJaVm0fd2yNWJy7TUVUmR6S+4iY2tq/RIwlv5uKIxLFkamMVmNk 9Nv2JonTawqLRNnPBtAZc0myCd1tRmbkQQPeBQN1y4QZiWkpbkDg+HhFxBfdCP48fSDgCgoX kjBb1bbqlBHgXJoU8kUngmbbZYJbJsTR8CP/s5BjLxwFeT1Nbt0T74exkSGC1w/A1fwy0ozo FT4IvyYTOJnCAVBfZBFxLMGJUDjTRfL7bxAw1phHcYYHVsLbFqu7CeENMO947N5JYh8YdlYR fCAMta2vSJ69YWLU5Y6AsBVBk21htUkOjRYr4gzA10joqZxfnTgCHb/7RTyfhzlnPsVdClgD M8WxvHwYml46SH72OwG2ZpOQN2QwPPtllZcEUGe/wKf3hQ9vChDPMhgfaRPwV2dBV0crsqCg ijUhKtZYFe7XWA895U6K1xXwzloq5DkE7lVPkTyHwi2XnVqr25DoEfJmGTY5My1sp4LRa1JY Nkun0DGGJ2jlC71oWgxoQQPTSjvCNJKvk3yiXCqpQG1kczPtCGhS7iV5zUmSVHXuWUafdVKf o2VYO9pIU3IfibK9XyXFaWoDk8Ew2Yz+v0vQHr4mpDzkb3if02CZi8oL7DX6x7aaRoyb4vwm /IaXCnTHhpKifsrjsxmj51TpiWKZwdh3s1NWHl+dEbKnN/pr16k4r8H7/heLBiNLyoLL0MLx LUGuyIijlapzPiljs/39xWE1TufuuKiE03faM6RTztFpySVFd3ggFV6pfS6s7vt2fbOcYtPV O4JJPav+B6AQneU+AwAA Archived-At: Subject: Re: [Detnet] Traffic description in DetNet flow info model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:24:07 -0000 --_000_DBXPR07MB128D53355B533A8B2EE651AAC1E0DBXPR07MB128eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Good discussion. As a general comment I think applications requiring DetNet transport should= be UDP based and not TCP (as retransmission would violate the transport parameters= the DetNet flow requires). I think what Yiyong is looking for whether we can make better resource rese= rvation for DetNet flow being VBR than reserving for peak rate? With CBR we are on = the safe side, no doubt. However for example not all TSN queuing method (e.g., time = gated queues, etc.) can ensure that unused resources can be used by non-DetNet tr= affic. Additionally, would be good to have feedback on how much applications would= "like" the shaping of DetNet flows. Shaping could help for better resource utiliza= tion, but is it a good idea for DetNet? I would like to ask the authors of the use-cases to comment what type of tr= affic is used in their use-cases (CBR, VBR, something else). Maybe that would help t= o sort this out. Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant Sent: 2017. =E1prilis 21. 16:20 To: DetNet WG Subject: Re: [Detnet] Traffic description in DetNet flow info model TCP isn't really intended for use with the kind of flows that would use CBR= or VBR. The main facilities provided by TCP are rate control and retransmission of = lost packets. When transferring a block of data (such as, say, an image or = a pre-recorded video or a PDF) over a best-effort service, these allow the = transfer to make best use of what the network provides. But if the network = service guarantees a particular data rate you don't need the kind of rate c= ontrol that TCP does, and if the network hardly ever loses a packet you don= 't need frequent acknowledgements. For instance, if you are sending live audio with a sampling rate of 48k sam= ples per second, and packing 12 samples in a packet, you need to send a pac= ket every 250 microseconds, so you need CBR with a rate of 4000 packets (of= a certain size) per second. The VBR service that was defined for ATM was intended for sending compresse= d video at constant quality, so that "busy" content needs more bits per fra= me than content with less detail. The peak rate is the bit rate for the "bu= siest" content, and the average bit rate was also signalled. I think the id= ea was that you could "overbook" a link by routing flows whose peak rates a= dd up to more than the link capacity, in the expectation that they wouldn't= all be demanding the peak rate at the same time. I think something similar= is done with digital television multiplexes. Note that with CBR (and VBR) the rate is determined by the application's re= quirements, whereas with TCP it is determined by what the best-effort servi= ce delivers. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 21 Apr 2017, at 08:37, zhayiyong wrote: Hi John, Thank you for the reply. I agree that make reservation on peak rate is a si= mple solution. But the "peak rate" here depends on the observation interval= times max packets per interval, which means for same flow, different inter= val leads to different peak rate. Below is a little testbed we built to tes= t the burstness feature of TCP flow. For the same 25Mbps TCP flow with no shaping: 1s observation interval, peak rate 450Mbps. 100ms observation interval, peak rate 900Mbps. 10ms observation interval, peak rate 1Gbps, which is the link speed/physica= l port speed. And further test shows that, 8 of these TCP flows to a 1Gbps port cause pac= ket loss. So my question is how can we make reservation based on "peak rate= "? E.g., for the same flow, if we take 1s observation interval, we can serv= e 2 flows. But for 10ms observation interval, only 1 flow, which does not m= ake sense. And it is hard to say long observation interval can guarantee de= lay and loss, since buffer in router is only milliseconds level. Another thing is how to guarantee the source with max packets within the in= terval. If shaping is necessary, what kind of parameters are needed. Cheers, Yiyong From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant Sent: Thursday, April 20, 2017 5:27 PM To: DetNet WG Subject: Re: [Detnet] Traffic description in DetNet flow info model As pointed out in 4.1.2, for a VBR flow you have to make a reservation for = the peak rate, and there isn't any reason to do anything other than use the= service that is already defined for CBR. With circuit-switched systems any= part of the reservation that wasn't used was wasted, but in packet-based s= ystems it can be used for best-effort traffic, as stated in 4.3.2. Regarding synchronous flows, the first paragraph of 4.3.2 explains that if = the reservations on incoming and outgoing links are time-aligned then the l= atency, and hence the amount of buffer space required, can be minimised. Th= e details mechanism for achieving that would, I think, be out of scope for = an architecture document. For a description of a system that implements synchronous flows, see clause= 5 of ETSI GR NGP 003, available from the "specifications" tab at http://ww= w.etsi.org/technologies-clusters/technologies/next-generation-protocols John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 20 Apr 2017, at 08:38, zhayiyong wrote: Hi All, Recently we have some discussion among authors of the two flow info model d= raft. The DetNet flow info model should provide some common concepts and de= scription of the flow. One part is traffic specification of the flow. Here = is something not clear, is DetNet dealing with VBR flows and what attribute= s are needed? And how to deal with VBR flow, for source guarantee purpose, = do we need to define shaping parameters? In architecture draft, section 4.1.2, "The traffic characteristics of an Ap= p-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In secti= on 4.3.2, mentions synchronous flow and asynchronous flow, but no details o= f that. In use case draft, for some cases such as industrial and BAS, it can assume= s that the traffic is periodic with constant rate. For cases such as Cellul= ar Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP= traffic is between two eNBs, it is hard to say the flow is constant rate. Cheers, Yiyong --_000_DBXPR07MB128D53355B533A8B2EE651AAC1E0DBXPR07MB128eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Good discussion.

 

As a general comment I think applications requiring= DetNet transport should be UDP

based and not TCP (as retransmission would violate = the transport parameters the

DetNet flow requires).

 

I think what Yiyong is looking for whether we can m= ake better resource reservation

for DetNet flow being VBR than reserving for peak r= ate? With CBR we are on the safe

side, no doubt. However for example not all TSN que= uing method (e.g., time gated

queues, etc.) can ensure that unused resources can = be used by non-DetNet traffic.

 

Additionally, would be good to have feedback on how= much applications would “like”

the shaping of DetNet flows. Shaping could help for= better resource utilization,

but is it a good idea for DetNet?=

 

I would like to ask the authors of the use-cases to= comment what type of traffic is

used in their use-cases (CBR, VBR, something else).= Maybe that would help to sort

this out.

 

Cheers

Bala’zs

 

From: detnet [mailto:detnet-bounces@= ietf.org] On Behalf Of John Grant
Sent: 2017. =E1prilis 21. 16:20
To: DetNet WG <detnet@ietf.org>
Subject: Re: [Detnet] Traffic description in DetNet flow info model<= o:p>

 

TCP isn't really intended for use with the kind of f= lows that would use CBR or VBR.

 

The main facilities provided by TCP are rate control= and retransmission of lost packets. When transferring a block of data (suc= h as, say, an image or a pre-recorded video or a PDF) over a best-effort se= rvice, these allow the transfer to make best use of what the network provides. But if the network service gua= rantees a particular data rate you don't need the kind of rate control that= TCP does, and if the network hardly ever loses a packet you don't need fre= quent acknowledgements.

 

For instance, if you are sending live audio with a s= ampling rate of 48k samples per second, and packing 12 samples in a packet,= you need to send a packet every 250 microseconds, so you need CBR with a r= ate of 4000 packets (of a certain size) per second.

 

The VBR service that was defined for ATM was intende= d for sending compressed video at constant quality, so that "busy"= ; content needs more bits per frame than content with less d= etail. The peak rate is the bit rate for the "busiest" content, and the average bit rate was also signalled. I think the idea was that you= could "overbook" a link by routing flows whose peak rates add up= to more than the link capacity, in the expectation that they wouldn't all = be demanding the peak rate at the same time. I think something similar is done with digital television multiplexes.

 

Note that with CBR (and VBR) the rate is determined = by the application's requirements, whereas with TCP it is determined by wha= t the best-effort service delivers.

 

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

 

On 21 Apr 2017, at 08:37, zhayiyong wrote:



Hi John,

 

Thank you for the reply. I agree that= make reservation on peak rate is a simple solution. But the “peak ra= te” here depends on the observation interval times max packets per interval, which means for same flow, different interval leads = to different peak rate. Below is a little testbed we built to test the burs= tness feature of TCP flow.

For the same 25Mbps TCP flow with no = shaping:

 

<image007.jpg>

1s observation interval, peak rate 45= 0Mbps.

 

<image008.jpg>

100ms observation interval, peak rate= 900Mbps.

 

<image009.jpg>

10ms observation interval, peak rate = 1Gbps, which is the link speed/physical port speed.

 

And further test shows that, 8 of the= se TCP flows to a 1Gbps port cause packet loss. So my question is how can w= e make reservation based on “peak rate”? E.g., for the same flow, if we take 1s observation interval, we can serve 2 flow= s. But for 10ms observation interval, only 1 flow, which does not make sens= e. And it is hard to say long observation interval can guarantee delay and = loss, since buffer in router is only milliseconds level.

 

Another thing is how to guarantee the= source with max packets within the interval. If shaping is necessary, what= kind of parameters are needed.

 

Cheers,

Yiyong

From: detnet [mailto:detnet-bounces@ietf.org= ] On Behalf Of John Grant
Sent: Thursday, Ap= ril 20, 2017 5:27 PM
To: DetNet WG
Subject: Re: [Detn= et] Traffic description in DetNet flow info model

 

As pointed out in 4.1.2, for a VBR flow you have to = make a reservation for the peak rate, and there isn't any reason to do anyt= hing other than use the service that is already defined for CBR. With circu= it-switched systems any part of the reservation that wasn't used was wasted, but in packet-based systems it ca= n be used for best-effort traffic, as stated in 4.3.2.

 

Regarding synchronous flows, the first paragraph of = 4.3.2 explains that if the reservations on incoming and outgoing links are = time-aligned then the latency, and hence the amount of buffer space require= d, can be minimised. The details mechanism for achieving that would, I think, be out of scope for an architecture doc= ument.

 

For a description of a system that implements synchr= onous flows, see clause 5 of ETSI GR NGP 003, available from the "spec= ifications" tab at http://www.etsi.org/technolo= gies-clusters/technologies/next-generation-protocols

 

John G= rant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 20 Apr 2017, at 08:38, zhayiyong wrote:




Hi All,

 

Recently we have some discussion among authors of t= he two flow info model draft. The DetNet flow info model should provide som= e common concepts and description of the flow. One part is traffic specification of the flow. Here is something not clear= , is DetNet dealing with VBR flows and what attributes are needed? And how = to deal with VBR flow, for source guarantee purpose, do we need to define s= haping parameters?

 

In architecture draft, section 4.1.2, “The tr= affic characteristics of an App-flow can be CBR (constant bit rate) or VBR = (variable bit rate)”. In section 4.3.2, mentions synchronous flow and asynchronous flow, but no details of that.

In use case draft, for some cases such as industria= l and BAS, it can assumes that the traffic is periodic with constant rate. = For cases such as Cellular Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP traffic is between two= eNBs, it is hard to say the flow is constant rate.

 

Cheers,

Yiyong

 

 

--_000_DBXPR07MB128D53355B533A8B2EE651AAC1E0DBXPR07MB128eurprd_-- From nobody Tue Apr 25 01:53:58 2017 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B76129522 for ; Tue, 25 Apr 2017 01:53:56 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yh2vc7-yYGys for ; Tue, 25 Apr 2017 01:53:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D0C12950E for ; Tue, 25 Apr 2017 01:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36974; q=dns/txt; s=iport; t=1493110432; x=1494320032; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aLfh5PMQuqFu5TUOTIMbnH/PLX4ABC3NHhtXLmXuQc8=; b=ZCEzKvmns/CNexNQqsilNKUPZycFN+UVPMMDnMhxCrhTbohoY5rXj8+H 0KgMjXSPfannqUf2ifONbrKizA1qdZb7m4NMe5qUMbVkqAjlkNwNO1tyw WHvTxjjgQ2bOungLlNdNdA0GEgwSMM1CLlU1zBbfTZYPXwgk88IPnB+bW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAACfDf9Y/5tdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYEMB411kWyVZYIPLoV2AoQaPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMtKDQCAQgHCgEDAQEhAQYHMhQDBggBAQQBCQkIARKKAQ6tIosdAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZTg2yBCoUNhS8FiT+HDYV9hngBknyRYJQYAR84Pkh?= =?us-ascii?q?jFYUtHIFjdYgpgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,248,1488844800"; d="scan'208,217";a="235404631" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 08:53:50 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3P8roU2009940 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 08:53:50 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.1210.3; Tue, 25 Apr 2017 03:53:49 -0500 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.1210.000; Tue, 25 Apr 2017 03:53:49 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= , "John Grant" , DetNet WG Thread-Topic: [Detnet] Traffic description in DetNet flow info model Thread-Index: AdK5qSSYqSHwGD/BTl6GOqTnuhSZHwAOQd0AAC54fgAADhBrAAC8nZOAAAoeClA= Date: Tue, 25 Apr 2017 08:53:36 +0000 Deferred-Delivery: Tue, 25 Apr 2017 08:51:56 +0000 Message-ID: References: <3B18D368-5822-4007-88F8-A02C875D7BAE@ninetiles.com> 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.4] Content-Type: multipart/alternative; boundary="_000_f8204cdb8e0149eda7d81e461ea8c0deXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Traffic description in DetNet flow info model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:53:56 -0000 --_000_f8204cdb8e0149eda7d81e461ea8c0deXCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bala'zs, I'd argue that UDP is pushing the problem to the application, but not solvi= ng it. I'd argue that we need a new rate-based (as opposed to window-based)= transport. Like IBM's Rapid Transport Protocol / Adaptive Rate Base for th= ose who played with it at some point. In the early days of industrial control networks (and we are still there fo= r the majority of real world deployments), the application was ultra light = because the analog current modulation would transport the information at sp= eed of light with neither latency nor jitter. Digitazing and then Serializing the information over a serial P2P cable bro= ught latency that applications had to cope with. Multi-drop serial links (b= uses) saved cabling but brought an additional latency, time to get to the T= DM piece awarded to the particular device. These, application could often c= ope with quite easily. Then came statistical multiplexing with such networks as frame relay, and w= ith it came jitter; that's when applications had to start accommodating wit= h jitter absorption buffers -and some did, when there was no choice (e.g. A= /V streaming). But the majority of operational technology would not be both= ered and that's one of the reasons why migration to off the shelf IP has be= en stalled in Operational Technology. And if you look at it, the rate adapt= ation (CIR, ECN) was still a network function, not an application function. Now we are claiming that DetNet should enable OT. And indeed DetNet will pr= ovide a pipe that has a rate and a latency (and a virtual clock) that could= indeed emulate the original serial wire. But for the lack of a rate based = transport, we are pushing the rate adaptation back to the application. Will= work for some, but I'm concerned that without a good ECN and a rate based = flow control, we are leaving a portion of the potential applications aside. Take care, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A Sent: mardi 25 avril 2017 10:21 To: John Grant ; DetNet WG Subject: Re: [Detnet] Traffic description in DetNet flow info model Hi, Good discussion. As a general comment I think applications requiring DetNet transport should= be UDP based and not TCP (as retransmission would violate the transport parameters= the DetNet flow requires). I think what Yiyong is looking for whether we can make better resource rese= rvation for DetNet flow being VBR than reserving for peak rate? With CBR we are on = the safe side, no doubt. However for example not all TSN queuing method (e.g., time = gated queues, etc.) can ensure that unused resources can be used by non-DetNet tr= affic. Additionally, would be good to have feedback on how much applications would= "like" the shaping of DetNet flows. Shaping could help for better resource utiliza= tion, but is it a good idea for DetNet? I would like to ask the authors of the use-cases to comment what type of tr= affic is used in their use-cases (CBR, VBR, something else). Maybe that would help t= o sort this out. Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant Sent: 2017. =E1prilis 21. 16:20 To: DetNet WG > Subject: Re: [Detnet] Traffic description in DetNet flow info model TCP isn't really intended for use with the kind of flows that would use CBR= or VBR. The main facilities provided by TCP are rate control and retransmission of = lost packets. When transferring a block of data (such as, say, an image or = a pre-recorded video or a PDF) over a best-effort service, these allow the = transfer to make best use of what the network provides. But if the network = service guarantees a particular data rate you don't need the kind of rate c= ontrol that TCP does, and if the network hardly ever loses a packet you don= 't need frequent acknowledgements. For instance, if you are sending live audio with a sampling rate of 48k sam= ples per second, and packing 12 samples in a packet, you need to send a pac= ket every 250 microseconds, so you need CBR with a rate of 4000 packets (of= a certain size) per second. The VBR service that was defined for ATM was intended for sending compresse= d video at constant quality, so that "busy" content needs more bits per fra= me than content with less detail. The peak rate is the bit rate for the "bu= siest" content, and the average bit rate was also signalled. I think the id= ea was that you could "overbook" a link by routing flows whose peak rates a= dd up to more than the link capacity, in the expectation that they wouldn't= all be demanding the peak rate at the same time. I think something similar= is done with digital television multiplexes. Note that with CBR (and VBR) the rate is determined by the application's re= quirements, whereas with TCP it is determined by what the best-effort servi= ce delivers. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 21 Apr 2017, at 08:37, zhayiyong wrote: Hi John, Thank you for the reply. I agree that make reservation on peak rate is a si= mple solution. But the "peak rate" here depends on the observation interval= times max packets per interval, which means for same flow, different inter= val leads to different peak rate. Below is a little testbed we built to tes= t the burstness feature of TCP flow. For the same 25Mbps TCP flow with no shaping: 1s observation interval, peak rate 450Mbps. 100ms observation interval, peak rate 900Mbps. 10ms observation interval, peak rate 1Gbps, which is the link speed/physica= l port speed. And further test shows that, 8 of these TCP flows to a 1Gbps port cause pac= ket loss. So my question is how can we make reservation based on "peak rate= "? E.g., for the same flow, if we take 1s observation interval, we can serv= e 2 flows. But for 10ms observation interval, only 1 flow, which does not m= ake sense. And it is hard to say long observation interval can guarantee de= lay and loss, since buffer in router is only milliseconds level. Another thing is how to guarantee the source with max packets within the in= terval. If shaping is necessary, what kind of parameters are needed. Cheers, Yiyong From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant Sent: Thursday, April 20, 2017 5:27 PM To: DetNet WG Subject: Re: [Detnet] Traffic description in DetNet flow info model As pointed out in 4.1.2, for a VBR flow you have to make a reservation for = the peak rate, and there isn't any reason to do anything other than use the= service that is already defined for CBR. With circuit-switched systems any= part of the reservation that wasn't used was wasted, but in packet-based s= ystems it can be used for best-effort traffic, as stated in 4.3.2. Regarding synchronous flows, the first paragraph of 4.3.2 explains that if = the reservations on incoming and outgoing links are time-aligned then the l= atency, and hence the amount of buffer space required, can be minimised. Th= e details mechanism for achieving that would, I think, be out of scope for = an architecture document. For a description of a system that implements synchronous flows, see clause= 5 of ETSI GR NGP 003, available from the "specifications" tab at http://ww= w.etsi.org/technologies-clusters/technologies/next-generation-protocols John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 20 Apr 2017, at 08:38, zhayiyong wrote: Hi All, Recently we have some discussion among authors of the two flow info model d= raft. The DetNet flow info model should provide some common concepts and de= scription of the flow. One part is traffic specification of the flow. Here = is something not clear, is DetNet dealing with VBR flows and what attribute= s are needed? And how to deal with VBR flow, for source guarantee purpose, = do we need to define shaping parameters? In architecture draft, section 4.1.2, "The traffic characteristics of an Ap= p-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In secti= on 4.3.2, mentions synchronous flow and asynchronous flow, but no details o= f that. In use case draft, for some cases such as industrial and BAS, it can assume= s that the traffic is periodic with constant rate. For cases such as Cellul= ar Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP= traffic is between two eNBs, it is hard to say the flow is constant rate. Cheers, Yiyong --_000_f8204cdb8e0149eda7d81e461ea8c0deXCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Bala’zs,

 

I’d argue that UDP is pushing t= he problem to the application, but not solving it. I’d argue that we = need a new rate-based (as opposed to window-based) transport. Like IBM’s Rapid Transport Protocol / Adaptive Rate Base for those w= ho played with it at some point.

 

In the early days of industrial contr= ol networks (and we are still there for the majority of real world deployme= nts), the application was ultra light because the analog current modulation would transport the information at speed of = light with neither latency nor jitter.

Digitazing and then Serializing the i= nformation over a serial P2P cable brought latency that applications had to= cope with. Multi-drop serial links (buses) saved cabling but brought an additional latency, time to get to the TDM piece aw= arded to the particular device. These, application could often cope with qu= ite easily.

Then came statistical multiplexing wi= th such networks as frame relay, and with it came jitter; that’s when= applications had to start accommodating with jitter absorption buffers -and some did, when there was no choice (e.g. A/V strea= ming). But the majority of operational technology would not be bothered and= that’s one of the reasons why migration to off the shelf IP has been stalled in Operational Technology= . And if you look at it, the rate adaptation (CIR, ECN) was still a net= work function, not an application function.

 

Now we are claiming that DetNet shoul= d enable OT. And indeed DetNet will provide a pipe that has a rate and a la= tency (and a virtual clock) that could indeed emulate the original serial wire. But for the lack of a rate based transpo= rt, we are pushing the rate adaptation back to the application. Will work f= or some, but I’m concerned that without a good ECN and a rate based f= low control, we are leaving a portion of the potential applications aside.

 

Take care,

 

Pascal

 

 

From: d= etnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A
Sent: mardi 25 avril 2017 10:21
To: John Grant <j@ninetiles.com>; DetNet WG <detnet@ietf.or= g>
Subject: Re: [Detnet] Traffic description in DetNet flow info model<= o:p>

 

Hi,<= /p>

 

Good discussion.

 

As a general comment I= think applications requiring DetNet transport should be UDP

based and not TCP (as = retransmission would violate the transport parameters the

DetNet flow requires).=

 

I think what Yiyong is= looking for whether we can make better resource reservation

for DetNet flow being = VBR than reserving for peak rate? With CBR we are on the safe

side, no doubt. Howeve= r for example not all TSN queuing method (e.g., time gated

queues, etc.) can ensu= re that unused resources can be used by non-DetNet traffic.

 

Additionally, would be= good to have feedback on how much applications would “like”

the shaping of DetNet = flows. Shaping could help for better resource utilization,

but is it a good idea = for DetNet?

 

I would like to ask th= e authors of the use-cases to comment what type of traffic is

used in their use-case= s (CBR, VBR, something else). Maybe that would help to sort

this out.

 

Cheers

Bala’zs

 

From: d= etnet [mailto:detnet-bounces@iet= f.org] On Behalf Of John Grant
Sent: 2017. =E1prilis 21. 16:20
To: DetNet WG <detnet@ietf.org= >
Subject: Re: [Detnet] Traffic description in DetNet flow info model<= o:p>

 

TCP isn't really intend= ed for use with the kind of flows that would use CBR or VBR.

 

The main facilities pro= vided by TCP are rate control and retransmission of lost packets. When tran= sferring a block of data (such as, say, an image or a pre-recorded video or= a PDF) over a best-effort service, these allow the transfer to make best use of what the network provides. Bu= t if the network service guarantees a particular data rate you don't need t= he kind of rate control that TCP does, and if the network hardly ever loses= a packet you don't need frequent acknowledgements.

 

For instance, if you ar= e sending live audio with a sampling rate of 48k samples per second, and pa= cking 12 samples in a packet, you need to send a packet every 250 microseco= nds, so you need CBR with a rate of 4000 packets (of a certain size) per second.

 

The VBR service that wa= s defined for ATM was intended for sending compressed video at constant qua= lity, so that "busy" content needs more bits per frame than&= nbsp;content with less detail. The peak rate is the bit rate for the "busiest" content, and the average bit rate was als= o signalled. I think the idea was that you could "overbook" a lin= k by routing flows whose peak rates add up to more than the link capacity, = in the expectation that they wouldn't all be demanding the peak rate at the same time. I think something similar is done with dig= ital television multiplexes.

 

Note that with CBR (and= VBR) the rate is determined by the application's requirements, whereas wit= h TCP it is determined by what the best-effort service delivers.=

 

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

 

On 21 Apr 2017, at 08:3= 7, zhayiyong wrote:

 

Hi John,=

 

Thank yo= u for the reply. I agree that make reservation on peak rate is a simple sol= ution. But the “peak rate” here depends on the observation interval times max packets per interval, which means for same flow, differ= ent interval leads to different peak rate. Below is a little testbed we bui= lt to test the burstness feature of TCP flow.

For the = same 25Mbps TCP flow with no shaping:

 

<imag= e007.jpg>

1s obser= vation interval, peak rate 450Mbps.

 

<imag= e008.jpg>

100ms ob= servation interval, peak rate 900Mbps.

 

<imag= e009.jpg>

10ms obs= ervation interval, peak rate 1Gbps, which is the link speed/physical port s= peed.

 

And furt= her test shows that, 8 of these TCP flows to a 1Gbps port cause packet loss= . So my question is how can we make reservation based on “peak rate”? E.g., for the same flow, if we take 1s o= bservation interval, we can serve 2 flows. But for 10ms observation interva= l, only 1 flow, which does not make sense. And it is hard to say long obser= vation interval can guarantee delay and loss, since buffer in router is only milliseconds level.

 

Another = thing is how to guarantee the source with max packets within the interval. = If shaping is necessary, what kind of parameters are needed.

 

Cheers,<= /span>

Yiyong

From: detnet [mailto:detnet-bounces@ietf.org= ] On Behalf Of John Grant
Sent: Thursday, Ap= ril 20, 2017 5:27 PM
To: DetNet WG
Subject: Re: [Detn= et] Traffic description in DetNet flow info model

 

As pointed out in 4.1.2= , for a VBR flow you have to make a reservation for the peak rate, and ther= e isn't any reason to do anything other than use the service that is alread= y defined for CBR. With circuit-switched systems any part of the reservation that wasn't used was wasted, but in pa= cket-based systems it can be used for best-effort traffic, as stated in 4.3= .2.

 

Regarding synchronous f= lows, the first paragraph of 4.3.2 explains that if the reservations on inc= oming and outgoing links are time-aligned then the latency, and hence the a= mount of buffer space required, can be minimised. The details mechanism for achieving that would, I think, be = out of scope for an architecture document.

 

For a description of a = system that implements synchronous flows, see clause 5 of ETSI GR NGP 003, = available from the "specifications" tab at http://www.etsi.org/technologies-clusters/technologies/next-generation-pro= tocols

 

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 20 Apr 2017, at 08:3= 8, zhayiyong wrote:



Hi All,

 

Recently we have some = discussion among authors of the two flow info model draft. The DetNet flow = info model should provide some common concepts and description of the flow. One part is traffic specification of the flow. He= re is something not clear, is DetNet dealing with VBR flows and what attrib= utes are needed? And how to deal with VBR flow, for source guarantee purpos= e, do we need to define shaping parameters?

 

In architecture draft,= section 4.1.2, “The traffic characteristics of an App-flow can be CB= R (constant bit rate) or VBR (variable bit rate)”. In section 4.3.2, mentions synchronous flow and asynchronous flow, but no det= ails of that.

In use case draft, for= some cases such as industrial and BAS, it can assumes that the traffic is = periodic with constant rate. For cases such as Cellular Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP t= raffic is between two eNBs, it is hard to say the flow is constant rate.

 

Cheers,

Yiyong

&nb= sp;

 

--_000_f8204cdb8e0149eda7d81e461ea8c0deXCHRCD001ciscocom_--