From leeyoung@huawei.com Mon Dec 2 11:22:01 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C7C1ADE8A for ; Mon, 2 Dec 2013 11:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.773 X-Spam-Level: X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QQfLAEK1pkk4 for ; Mon, 2 Dec 2013 11:21:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3E1E1ADEA0 for ; Mon, 2 Dec 2013 11:21:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY09940; Mon, 02 Dec 2013 19:21:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:21:05 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:21:52 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 11:21:49 -0800 From: Leeyoung To: "actn@ietf.org" Thread-Topic: test Thread-Index: Ac7vk77HPBnSnm0JSYSN1R+4EeLUGw== Date: Mon, 2 Dec 2013 19:21:48 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9A622@dfweml510-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.149] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Actn] test X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:22:01 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A622dfweml510mbxchi_-- From leeyoung@huawei.com Mon Dec 2 11:35:03 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B91AD8F3 for ; Mon, 2 Dec 2013 11:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Upe-XJ6pI_yz for ; Mon, 2 Dec 2013 11:35:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A30BB1ADEB5 for ; Mon, 2 Dec 2013 11:34:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYN98055; Mon, 02 Dec 2013 19:34:56 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:34:12 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 19:34:54 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 11:34:52 -0800 From: Leeyoung To: "actn@ietf.org" Thread-Topic: Introduction to ACTN mailing list Thread-Index: Ac7vlZDuyRutGTQwSpeYEkHdFSpHbQ== Date: Mon, 2 Dec 2013 19:34:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9A65E@dfweml510-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.149] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "King, Daniel" , 'Young Lee' Subject: [Actn] Introduction to ACTN mailing list X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:35:03 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, This is to introduce the ACTN mailing list. ACTN stands for "Abstraction an= d Control of Transport Networks" and it reads like "Action." This mailing list is created as a result of a Bar BOF held in IETF 88 @ Van= couver. The original Bar BOF was called "Network Control Function Virtualiz= ation (NCFV)". The purpose of the list: Transport networks have a variety of mechanisms to facilitate separation of= data plane and control plane including distributed signaling for path setu= p and protection, centralized path computation for planning and traffic eng= ineering, and a range of management and provisioning protocols to configure= and activate network resources. These mechanisms represent key technologie= s for enabling flexible and dynamic networking. As transport networks evolve, the need to provide network abstraction has e= merged as key requirement for operators; this is in effect virtualization o= f network resources so that the network is "sliced" for different uses, app= lications, services, and clients each being given a different partial view = of the total topology and each considering that it is operating with or on = a single, stand-alone and consistent network. This virtualization is known as Abstraction and Control of Transport Networ= k (ACTN) and facilitates: - Abstraction of underlying network resources to higher-layer applications = and users (clients); - Slicing of network resources, to meet specific application and users requ= irements; - A computation scheme and virtual control capability, via an information m= odel, to clients who request network connectivity and bandwidth; - Coordination of underlying transport layers and presentation as an abstra= cted topology to the client; This mailing list is intended to enable discussion of the architecture, use= -cases/applicability, and requirements that provide abstraction and virtual= control of transport networks to various applications/clients. You can subscribe to the list at: https://www.ietf.org/mailman/listinfo/act= n. Wiki is created to keep track of the latest development and provide some ba= ckground and useful information at: https://sites.google.com/site/actnbof/. To post a message to all the list members, send email to actn@ietf.org. Best Regards, Young & Dan --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

This is to introduce the ACTN mailing list. ACTN stands for “Abstra= ction and Control of Transport Networks” and it reads like “Act= ion.”

This mailing list is created as a result of a Bar BOF held in IETF 88 @ V= ancouver. The original Bar BOF was called “Network Control Function V= irtualization (NCFV)”.

The purpose of the list:

Transport networks have a variety of mechanisms t= o facilitate separation of data plane and control plane including distribut= ed signaling for path setup and protection, centralized path computation fo= r planning and traffic engineering, and a range of management and provisioning protocols to configure and acti= vate network resources. These mechanisms represent key technologies for ena= bling flexible and dynamic networking.

As transport networks evolve, the need to provide= network abstraction has emerged as key requirement for operators; this is = in effect virtualization of network resources so that the network is "= sliced" for different uses, applications, services, and clients each being given a different partial view of the tot= al topology and each considering that it is operating with or on a single, = stand-alone and consistent network.

This virtualization is known as Abstraction and C= ontrol of Transport Network (ACTN) and facilitates:

- Abstraction of underlying network resources to = higher-layer applications and users (clients);

- Slicing of network resources, to meet specific = application and users requirements;

- A computation scheme and virtual control capabi= lity, via an information model, to clients who request network connectivity= and bandwidth;

- Coordination of underlying transport layers and= presentation as an abstracted topology to the client;

This mailing list is intended to enable discussio= n of the architecture, use-cases/applicability, and requirements that provi= de abstraction and virtual control of transport networks to various applica= tions/clients.

You can subscribe to the list at: https://www.ietf.org/mailman/listinfo/actn<= /a>.

Wiki is created to keep track of the latest development an= d provide some background and useful information at: https://sites.google.com/site/actnbof/.

To post a message to all the list members, send email to actn@ietf.org.

Best Regards,

Young & Dan

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9A65Edfweml510mbxchi_-- From ietf-secretariat@ietf.org Tue Dec 3 09:56:03 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160911AE151; Tue, 3 Dec 2013 09:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 h9-b_qNjL-4G; Tue, 3 Dec 2013 09:56:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DE71AE18C; Tue, 3 Dec 2013 09:56:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2013 09:56:01 -0800 X-Mailman-Approved-At: Tue, 03 Dec 2013 11:15:30 -0800 Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org Subject: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:56:03 -0000 A new IETF non-working group email list has been created. List address: actn@ietf.org Archive: http://www.ietf.org/mail-archive/web/actn/ To subscribe: https://www.ietf.org/mailman/listinfo/actn Purpose: Discussion of Abstraction and Control of Transport Networks = (ACTN) For additional information, please contact the list administrators. From jmpolk@cisco.com Tue Dec 3 11:41:18 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0E1AE195; Tue, 3 Dec 2013 11:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kSF40iKl6qIQ; Tue, 3 Dec 2013 11:41:16 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3151ADBCE; Tue, 3 Dec 2013 11:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=523; q=dns/txt; s=iport; t=1386099673; x=1387309273; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=b27eN/U18syb6aJFIpPu+yQ8LQf6/ypnTK3VYx22Sig=; b=cxA8yN0SHW8F86EOIY6gna2a4KOBhsOLM2skQpG+F18ZK7PcmUwv3iqU 6pkeGmyjgW7knWPNgKjN+Z1uBdyP396VXL2500zvell7b0wZGjV7HXxIQ gGdrdEVoMTpsNwt3Phwt6kWsP9OjB+C0spaUM5vr1x+IcvfV4dfxCIHQ0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOYynlKtJXG9/2dsb2JhbABagwc4uTuBGxZ0giUBAQEEAQEBNQI0CxAHBBgJAxIQDwoOMAYBEgmHeA3BMBeOHBACAU8HhDMDiUKgZYFrgV0d X-IronPort-AV: E=Sophos;i="4.93,819,1378857600"; d="scan'208";a="4053280" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 03 Dec 2013 19:41:13 +0000 Received: from jmpolk-WS.cisco.com ([10.89.12.165]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB3JfDcd004847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 19:41:13 GMT Message-Id: <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Dec 2013 13:41:12 -0600 To: , IETF Announcement List From: James Polk In-Reply-To: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk X-Mailman-Approved-At: Tue, 03 Dec 2013 11:49:18 -0800 Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:41:18 -0000 Can this "purpose" have fewer words...? come on, let us know what's really going on this new list James At 11:56 AM 12/3/2013, IETF Secretariat wrote: >A new IETF non-working group email list has been created. > >List address: actn@ietf.org >Archive: http://www.ietf.org/mail-archive/web/actn/ >To subscribe: https://www.ietf.org/mailman/listinfo/actn > >Purpose: Discussion of Abstraction and Control of Transport Networks >(ACTN) > >For additional information, please contact the list administrators. From derhoermi@gmx.net Tue Dec 3 11:49:31 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A051AE198 for ; Tue, 3 Dec 2013 11:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 NirygmOVkSG7 for ; Tue, 3 Dec 2013 11:49:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FD1ACC88 for ; Tue, 3 Dec 2013 11:49:29 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.22.65]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MS5jy-1WBcy408Lq-00TDpE for ; Tue, 03 Dec 2013 20:49:26 +0100 From: Bjoern Hoehrmann To: James Polk Date: Tue, 03 Dec 2013 20:49:26 +0100 Message-ID: <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> In-Reply-To: <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:PtlY4M0l4BqSXEkUS9Ww+oSYe2LU6DmS1rD9dKyI1ocGb3SOT8A G8ie5X+42nvCz7vuGjt3CCC48UG82dgIjySqhXKFJne3fcvJ/dFleCQ+JS7bEx9hpKQD2np xFBOXfrVwtrT3EfWy7XpHq0y8XXj/4WYdwhmHPHl7GkY+6jRV2AA779AIqmauLLCBQ4d35u INahg3NBjNX3VkezCcNhg== X-Mailman-Approved-At: Tue, 03 Dec 2013 11:56:09 -0800 Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, ietf@ietf.org, actn@ietf.org Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:49:31 -0000 * James Polk wrote: >Can this "purpose" have fewer words...? > >come on, let us know what's really going on this new list There is http://www.ietf.org/mail-archive/web/actn/current/msg00002.html -- Bj�rn H�hrmann � mailto:bjoern@hoehrmann.de � http://bjoern.hoehrmann.de Am Badedeich 7 � Telefon: +49(0)160/4415681 � http://www.bjoernsworld.de 25899 Dageb�ll � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/ From d.king@lancaster.ac.uk Tue Dec 3 11:57:00 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47E91ACCDC for ; Tue, 3 Dec 2013 11:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 A72xqYFpu0bS for ; Tue, 3 Dec 2013 11:56:59 -0800 (PST) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA6F1AC404 for ; Tue, 3 Dec 2013 11:56:59 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Vnw5X-0006yW-4R; Tue, 03 Dec 2013 19:56:55 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 19:56:54 +0000 From: "King, Daniel" To: Bjoern Hoehrmann , "jmpolk@cisco.com" Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) Thread-Index: AQHO8GDHeZUouMBhc0ygB4R8mvBWFJpC4PuA Date: Tue, 3 Dec 2013 19:56:54 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D20D6@EX-0-MB2.lancs.local> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> In-Reply-To: <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "actn@ietf.org" Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:57:01 -0000 Thanks Bjoern! James, the list is rather new, we need folks to move their current discussi= ons to the list.=20 In the meantime, did you review the slides from the BoF and/or initial I-Ds= : https://sites.google.com/site/actnbof/home/bar-bof-material https://datatracker.ietf.org/doc/draft-lee-network-control-function-virtual= ization/ https://datatracker.ietf.org/doc/draft-lee-pce-app-oriented-arch/ Any contribution as questions, or suggestions, would be most welcome.=20 Br, Dan.=20 -----Original Message----- From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]=20 Sent: 03 December 2013 19:49 To: James Polk Cc: ietf@ietf.org; King, Daniel; younglee.tx@gmail.com; leeyoung@huawei.com= ; actn@ietf.org Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of Tr= ansport Networks (ACTN) * James Polk wrote: >Can this "purpose" have fewer words...? > >come on, let us know what's really going on this new list There is http://www.ietf.org/mail-archive/web/actn/current/msg00002.html -- Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma= nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsw= orld.de 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From fred@cisco.com Tue Dec 3 12:20:41 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0D1AE1A1; Tue, 3 Dec 2013 12:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.502 X-Spam-Level: X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 JG-i9Axxrf0g; Tue, 3 Dec 2013 12:20:40 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA391AE198; Tue, 3 Dec 2013 12:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1518; q=dns/txt; s=iport; t=1386102037; x=1387311637; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FZpMOhQOFGqTvEWmmZBudL7qI1FawHBLzvL81q1jpI4=; b=H/rvDbf80ICnI1hnfCgC0RoZu164fgUxFRrQCtXC5J2eRhesWXH/BAYZ stmxL+MPfo/znzQePs8MgykePtdHN+KLgHpUiaX7T5Wv6kPZ7foDUu9Oi AVPfkBEhCvXl1DMYqhEAs9aK3n8kxEslda65BBSE+ObdzDF6mAzsW5pe4 E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAOY8nlKtJXHA/2dsb2JhbABagwc4U7hogRsWdIIlAQEBBG4LEAIBCA4KJwcyFBECBA4FCQWHYQMPDcEtF4xtgUABAU8CBQmDF4ETA5AxgTGGMoEwkGOBa4E+gXE5 X-IronPort-AV: E=Sophos;i="4.93,819,1378857600"; d="asc'?scan'208";a="4059667" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 03 Dec 2013 20:20:37 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB3KKbeH014716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 20:20:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 14:20:36 -0600 From: "Fred Baker (fred)" To: Bjoern Hoehrmann Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) Thread-Index: AQHO8FEDY9UrnEdjo0G5rnh8NuMiHJpDQzEAgAACTQCAAAi1AA== Date: Tue, 3 Dec 2013 20:20:36 +0000 Message-ID: <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> In-Reply-To: <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 03 Dec 2013 12:25:59 -0800 Cc: "" , "" , "" , "" , "" , "James Polk $jmpolk$" Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:20:41 -0000 --Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 3, 2013, at 11:49 AM, Bjoern Hoehrmann wrote: > * James Polk wrote: >> Can this "purpose" have fewer words...? >>=20 >> come on, let us know what's really going on this new list >=20 > There is = http://www.ietf.org/mail-archive/web/actn/current/msg00002.html Great. Put that information into the list description so the next person = doesn't have to ask the same question. > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSnj0UbjEdbHIsm0MRAjlNAKCgNtAmBbUkKhKFO1WiB+9OWCe0WwCdF1Oy iJoIbLEJmLO7SecHe+4OXjU= =nAx1 -----END PGP SIGNATURE----- --Apple-Mail=_E1E8CCE0-E354-4834-8C8D-126CE8440F5C-- From d.king@lancaster.ac.uk Tue Dec 3 12:30:29 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18781ADF2F for ; Tue, 3 Dec 2013 12:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 tn-LuOP3JWiv for ; Tue, 3 Dec 2013 12:30:27 -0800 (PST) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 864A61ACCDE for ; Tue, 3 Dec 2013 12:30:27 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Vnwbu-0003ZI-3w; Tue, 03 Dec 2013 20:30:22 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 20:30:21 +0000 From: "King, Daniel" To: "Fred Baker (fred)" Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) Thread-Index: AQHO8GUme2IK1F+NsEaz+yJ61vv6e5pC6+TQ Date: Tue, 3 Dec 2013 20:30:21 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D212D@EX-0-MB2.lancs.local> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com> In-Reply-To: <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Bjoern Hoehrmann , "" , "James Polk $jmpolk$" , "" Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:30:29 -0000 >Great. Put that information into the list description so the next person d= oesn't have to ask the same question. Done! Thanks.=20 Br, Dan.=20 -----Original Message----- From: Fred Baker (fred) [mailto:fred@cisco.com]=20 Sent: 03 December 2013 20:21 To: Bjoern Hoehrmann Cc: James Polk (jmpolk); King, Daniel; ; ; ; Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of Tr= ansport Networks (ACTN) On Dec 3, 2013, at 11:49 AM, Bjoern Hoehrmann wrote: > * James Polk wrote: >> Can this "purpose" have fewer words...? >>=20 >> come on, let us know what's really going on this new list >=20 > There is=20 > http://www.ietf.org/mail-archive/web/actn/current/msg00002.html Great. Put that information into the list description so the next person do= esn't have to ask the same question. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20 > http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681= =20 > =B7 http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20 > http://www.websitedev.de/ ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From d3e3e3@gmail.com Tue Dec 3 13:34:05 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6D51A8032; Tue, 3 Dec 2013 13:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 KjpaIJaIoZXz; Tue, 3 Dec 2013 13:34:04 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 470B61ADED6; Tue, 3 Dec 2013 13:34:04 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so15086773obc.37 for ; Tue, 03 Dec 2013 13:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dIOXm1tb9vetjbDbrA1cEv5Iz6e6YxoWMyBjAao3U88=; b=GbS7vmgvfEG46dauNu601GcWDp5woOuivDTuoQrl5jrMDQpEZK4oOnu35EPH5eS0BI vBOshTYZDNaf3wsW+bQTCDlOqVcXzMVIO1rxPvym5ZHVbO/sDI3xwq1MPElntr8/KTUd UrbIff5MAmbYfl8Fkr3mzS0aciEPLbAgtKR1KuUfr5KSwismQLb02oULPCi5KKO81F7Y /OTyQFw08DginYZMMfvhiYTuu01Hj55UL0kAA46/XIjeMwZTKgdNKNucyPn7C9w4f9kW WQqhS089pRimtAfqCOKlwRxeRJB+IbtivMOmJmsa3hZQlFK/1UYRSQdLhKyl84KKs11J QPqw== X-Received: by 10.182.81.197 with SMTP id c5mr11593218oby.40.1386106441385; Tue, 03 Dec 2013 13:34:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Tue, 3 Dec 2013 13:33:41 -0800 (PST) In-Reply-To: <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> <0dds99dklcctsl6esftqg4peops8slqaln@hive.bjoern.hoehrmann.de> <44C48EE4-96E5-4AA4-B993-8D98F8D851F2@cisco.com> From: Donald Eastlake Date: Tue, 3 Dec 2013 16:33:41 -0500 Message-ID: To: "" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 03 Dec 2013 13:37:54 -0800 Cc: Bjoern Hoehrmann , "" , "Fred Baker $fred$" , "" , "" , "" Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:34:06 -0000 Yes please. A plethora of non-wg mailing lists with cryptic descriptions is a perennial problem. How about a *minimum* description requirement of 50 words or something. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Dec 3, 2013 at 3:20 PM, Fred Baker (fred) wrote: > > On Dec 3, 2013, at 11:49 AM, Bjoern Hoehrmann wrote: > >> * James Polk wrote: >>> Can this "purpose" have fewer words...? >>> >>> come on, let us know what's really going on this new list >> >> There is http://www.ietf.org/mail-archive/web/actn/current/msg00002.html > > Great. Put that information into the list description so the next person = doesn't have to ask the same question. > >> -- >> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoeh= rmann.de >> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworl= d.de >> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitede= v.de/ > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > From adrian@olddog.co.uk Tue Dec 3 15:16:01 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7D1AE1C6; Tue, 3 Dec 2013 15:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 tMrBgHzmnR2D; Tue, 3 Dec 2013 15:15:58 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4E1ADF28; Tue, 3 Dec 2013 15:15:58 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NFlKd024761; Tue, 3 Dec 2013 23:15:47 GMT Received: from 950129200 (no-dns-yet.demon.co.uk [62.49.66.12] (may be forged)) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NFkO3024752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 23:15:46 GMT From: "Adrian Farrel" To: "'James Polk'" , References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> In-Reply-To: <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> Date: Tue, 3 Dec 2013 23:15:45 -0000 Message-ID: <0f5701cef07d$9926acf0$cb7406d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzBhEBAL8QRPWOkmQwqhx5/2DF5gEh+IF7mfHekVA= Content-Language: en-gb Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:16:01 -0000 James, I'm very sorry about that. I sent the Secretariat a long description when requesting list creation. See it below. I will follow up with the Executive Director to find out what happened. Adrian === -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 26 November 2013 20:03 To: 'ietf-action@ietf.org' Cc: iesg@ietf.org; King, Daniel (d.king@lancaster.ac.uk); leeyoung@huawei.com Subject: FW: Please create and announce a new non-WG mailing list Hi, Please create the a new non-working group mailing list as follows... Name and email address of the submitter: Young Lee, leeyoung@huawei.com The name of the list: Abstraction and Control of Transport Networks (ACTN) The URL or email address of the list: actn@ietf.org Name(s) and email address(es) of the list administrator(s): Young Lee leeyoung@huawei.com Daniel King d.king@lancaster.ac.uk The IETF Area to which the list belongs: Routing The URL or other instructions for subscribing to the list: https://www.ietf.org/mailman/listinfo/actn The purpose of the list: Transport networks have a variety of mechanisms to facilitate separation of data plane and control plane including distributed signaling for path setup and protection, centralized path computation for planning and traffic engineering, and a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. As transport networks evolve, the need to provide network abstraction has emerged as key requirement for operators; this is in effect virtualization of network resources so that the network is "sliced" for different uses, applications, services, and clients each being given a different partial view of the total topology and each considering that it is operating with or on a single, stand-alone and consistent network. This virtualization is known as Abstraction and Control of Transport Network (ACTN) and facilitates: - Abstraction of underlying network resources to higher-layer applications and users (clients); - Slicing of network resources, to meet specific application and users requirements; - A computation scheme and virtual control capability, via an information model, to clients who request network connectivity and bandwidth; - Coordination of underlying transport layers and presentation as an abstracted topology to the client; This mailing list is intended to enable discussion of the architecture, use-cases/applicability, and requirements that provide abstraction and virtual control of transport networks to various applications/clients. > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of James Polk > Sent: 03 December 2013 19:41 > To: ietf@ietf.org; IETF Announcement List > Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com; > actn@ietf.org > Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of > Transport Networks (ACTN) > > Can this "purpose" have fewer words...? > > come on, let us know what's really going on this new list > > James > > At 11:56 AM 12/3/2013, IETF Secretariat wrote: > >A new IETF non-working group email list has been created. > > > >List address: actn@ietf.org > >Archive: http://www.ietf.org/mail-archive/web/actn/ > >To subscribe: https://www.ietf.org/mailman/listinfo/actn > > > >Purpose: Discussion of Abstraction and Control of Transport Networks > >(ACTN) > > > >For additional information, please contact the list administrators. From adrian@olddog.co.uk Tue Dec 3 15:17:42 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBA71AE1CE; Tue, 3 Dec 2013 15:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 vji7JrrsueZe; Tue, 3 Dec 2013 15:17:40 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E112A1ADF59; Tue, 3 Dec 2013 15:17:39 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NHU3J027356; Tue, 3 Dec 2013 23:17:30 GMT Received: from 950129200 (no-dns-yet.demon.co.uk [62.49.66.12] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3NHSVI027326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 23:17:29 GMT From: "Adrian Farrel" To: "'James Polk'" , References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com> In-Reply-To: Date: Tue, 3 Dec 2013 23:17:28 -0000 Message-ID: <0f5b01cef07d$d6212e00$82638a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzBhEBAL8QRPWOkmQwqhx5/2DF5gEh+IF7mfHekVCAAAEPUA== Content-Language: en-gb Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:17:43 -0000 Actually, there is also... https://www.ietf.org/mailman/listinfo/actn > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 03 December 2013 23:16 > To: 'James Polk'; 'ietf@ietf.org' > Cc: 'd.king@lancaster.ac.uk'; 'younglee.tx@gmail.com'; 'leeyoung@huawei.com'; > 'actn@ietf.org' > Subject: RE: New Non-WG Mailing List: ACTN -- Abstraction and Control of > Transport Networks (ACTN) > > James, > > I'm very sorry about that. I sent the Secretariat a long description when > requesting list creation. See it below. > > I will follow up with the Executive Director to find out what happened. > > Adrian > > === > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 26 November 2013 20:03 > To: 'ietf-action@ietf.org' > Cc: iesg@ietf.org; King, Daniel (d.king@lancaster.ac.uk); leeyoung@huawei.com > Subject: FW: Please create and announce a new non-WG mailing list > > Hi, > > Please create the a new non-working group mailing list as follows... > > Name and email address of the submitter: > Young Lee, leeyoung@huawei.com > > The name of the list: > Abstraction and Control of Transport Networks (ACTN) > > The URL or email address of the list: > actn@ietf.org > > Name(s) and email address(es) of the list administrator(s): > Young Lee leeyoung@huawei.com > Daniel King d.king@lancaster.ac.uk > > The IETF Area to which the list belongs: > Routing > > The URL or other instructions for subscribing to the list: > https://www.ietf.org/mailman/listinfo/actn > > The purpose of the list: > > Transport networks have a variety of mechanisms to facilitate separation of data > plane and control plane including distributed signaling for path setup and > protection, centralized path computation for planning and traffic engineering, > and a range of management and provisioning protocols to configure and activate > network resources. These mechanisms represent key technologies for enabling > flexible and dynamic networking. > > As transport networks evolve, the need to provide network abstraction has > emerged as key requirement for operators; this is in effect virtualization of > network resources so that the network is "sliced" for different uses, applications, > services, and clients each being given a different partial view of the total topology > and each considering that it is operating with or on a single, stand-alone and > consistent network. > > This virtualization is known as Abstraction and Control of Transport Network > (ACTN) and facilitates: > - Abstraction of underlying network resources to higher-layer applications and > users (clients); > - Slicing of network resources, to meet specific application and users > requirements; > - A computation scheme and virtual control capability, via an information model, > to clients who request network connectivity and bandwidth; > - Coordination of underlying transport layers and presentation as an abstracted > topology to the client; > > This mailing list is intended to enable discussion of the architecture, use- > cases/applicability, and requirements that provide abstraction and virtual control > of transport networks to various applications/clients. > > > -----Original Message----- > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of James Polk > > Sent: 03 December 2013 19:41 > > To: ietf@ietf.org; IETF Announcement List > > Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com; > > actn@ietf.org > > Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of > > Transport Networks (ACTN) > > > > Can this "purpose" have fewer words...? > > > > come on, let us know what's really going on this new list > > > > James > > > > At 11:56 AM 12/3/2013, IETF Secretariat wrote: > > >A new IETF non-working group email list has been created. > > > > > >List address: actn@ietf.org > > >Archive: http://www.ietf.org/mail-archive/web/actn/ > > >To subscribe: https://www.ietf.org/mailman/listinfo/actn > > > > > >Purpose: Discussion of Abstraction and Control of Transport Networks > > >(ACTN) > > > > > >For additional information, please contact the list administrators. From l.wood@surrey.ac.uk Tue Dec 3 16:42:43 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2C81ADFC8; Tue, 3 Dec 2013 16:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 sZizR9rgIVbr; Tue, 3 Dec 2013 16:42:40 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED81ADE89; Tue, 3 Dec 2013 16:42:39 -0800 (PST) Received: from [85.158.137.99:47914] by server-3.bemta-3.messagelabs.com id C6/C4-10658-C7A7E925; Wed, 04 Dec 2013 00:42:36 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-11.tower-217.messagelabs.com!1386117755!16865677!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2207 invoked from network); 4 Dec 2013 00:42:36 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-11.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 4 Dec 2013 00:42:36 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 4 Dec 2013 00:41:58 +0000 From: To: , , Date: Wed, 4 Dec 2013 00:40:38 +0000 Thread-Topic: New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) Thread-Index: AQHzBhEBAL8QRPWOkmQwqhx5/2DF5gEh+IF7mfHekVCAABhwNg== Message-ID: <290E20B455C66743BE178C5C84F1240847E5103796@EXMB01CMS.surrey.ac.uk> References: <20131203175601.13127.58364.idtracker@ietfa.amsl.com> <201312031941.rB3JfDcd004847@rcdn-core2-2.cisco.com>, <0f5701cef07d$9926acf0$cb7406d0$@olddog.co.uk> In-Reply-To: <0f5701cef07d$9926acf0$cb7406d0$@olddog.co.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 03 Dec 2013 17:04:23 -0800 Cc: d.king@lancaster.ac.uk, younglee.tx@gmail.com, leeyoung@huawei.com, actn@ietf.org Subject: Re: [Actn] New Non-WG Mailing List: ACTN -- Abstraction and Control of Transport Networks (ACTN) X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 00:42:44 -0000 Apply the inverted pyramid, as used in news articles. http://en.wikipedia.org/wiki/Inverted_pyramid The last paragraph of the description should have been first, as it is most= relevant. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Adrian Farrel [adrian@olddo= g.co.uk] Sent: 03 December 2013 23:15 To: 'James Polk'; ietf@ietf.org Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com; act= n@ietf.org Subject: RE: New Non-WG Mailing List: ACTN -- Abstraction and Control of Tr= ansport Networks (ACTN) James, I'm very sorry about that. I sent the Secretariat a long description when requesting list creation. See it below. I will follow up with the Executive Director to find out what happened. Adrian =3D=3D=3D -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 26 November 2013 20:03 To: 'ietf-action@ietf.org' Cc: iesg@ietf.org; King, Daniel (d.king@lancaster.ac.uk); leeyoung@huawei.c= om Subject: FW: Please create and announce a new non-WG mailing list Hi, Please create the a new non-working group mailing list as follows... Name and email address of the submitter: Young Lee, leeyoung@huawei.com The name of the list: Abstraction and Control of Transport Networks (ACTN) The URL or email address of the list: actn@ietf.org Name(s) and email address(es) of the list administrator(s): Young Lee leeyoung@huawei.com Daniel King d.king@lancaster.ac.uk The IETF Area to which the list belongs: Routing The URL or other instructions for subscribing to the list: https://www.ietf.org/mailman/listinfo/actn The purpose of the list: Transport networks have a variety of mechanisms to facilitate separation of= data plane and control plane including distributed signaling for path setup and protection, centralized path computation for planning and traffic engineeri= ng, and a range of management and provisioning protocols to configure and activ= ate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. As transport networks evolve, the need to provide network abstraction has emerged as key requirement for operators; this is in effect virtualization = of network resources so that the network is "sliced" for different uses, applications, services, and clients each being given a different partial vi= ew of the total topology and each considering that it is operating with or on a single, stand-alone and consistent network. This virtualization is known as Abstraction and Control of Transport Networ= k (ACTN) and facilitates: - Abstraction of underlying network resources to higher-layer applications = and users (clients); - Slicing of network resources, to meet specific application and users requirements; - A computation scheme and virtual control capability, via an information m= odel, to clients who request network connectivity and bandwidth; - Coordination of underlying transport layers and presentation as an abstra= cted topology to the client; This mailing list is intended to enable discussion of the architecture, use-cases/applicability, and requirements that provide abstraction and virt= ual control of transport networks to various applications/clients. > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of James Polk > Sent: 03 December 2013 19:41 > To: ietf@ietf.org; IETF Announcement List > Cc: d.king@lancaster.ac.uk; younglee.tx@gmail.com; leeyoung@huawei.com; > actn@ietf.org > Subject: Re: New Non-WG Mailing List: ACTN -- Abstraction and Control of > Transport Networks (ACTN) > > Can this "purpose" have fewer words...? > > come on, let us know what's really going on this new list > > James > > At 11:56 AM 12/3/2013, IETF Secretariat wrote: > >A new IETF non-working group email list has been created. > > > >List address: actn@ietf.org > >Archive: http://www.ietf.org/mail-archive/web/actn/ > >To subscribe: https://www.ietf.org/mailman/listinfo/actn > > > >Purpose: Discussion of Abstraction and Control of Transport Networks > >(ACTN) > > > >For additional information, please contact the list administrators. From d.king@lancaster.ac.uk Thu Dec 5 12:57:18 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB81AE0D0 for ; Thu, 5 Dec 2013 12:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 NyQWluE9096L for ; Thu, 5 Dec 2013 12:57:15 -0800 (PST) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 18BD81ACCDF for ; Thu, 5 Dec 2013 12:57:15 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Vofyx-0007Hx-5T for actn@ietf.org; Thu, 05 Dec 2013 20:57:11 +0000 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 20:57:10 +0000 From: "King, Daniel" To: "actn@ietf.org" Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+Fg== X-VoiceMessageDuration: 1 Date: Thu, 5 Dec 2013 20:57:09 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_" MIME-Version: 1.0 Subject: [Actn] Definition of "Transport Network" and requirements within the context of ACTN X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:57:18 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on = the where we would apply ACTN, specifically which layer and subsequent tech= nologies should be targeted/supported. Let's start with a few clarification= s: - By "transport network" do we mean server network that provides connectivi= ty for higher-layer packet networks, clients and applications. - A number of server network technologies exist at L1, L2, L3. - Typically these server networks are run evenly to minimise operational ov= erhead, but lack flexibility/adaptability and dynamic integration with clie= nt layers/interfaces/applications. Now let's review some high-level design goals: - ACTN interfaces with clients/applications (Data Centers, Virtual Network = Operators, et al.) to allow dynamic/automated connectivity and bandwidth re= quest setup. - ACTN provides an abstracted view of the network resources, i.e., the clie= nt/application is agnostic of the underlying technology used within the tra= nsport layer. - ACTN should facilitate the slicing (allocation) of resources, for specifi= c client interfaces and applications. The abstracted topology should also b= e flexible (adaptable), and support adaptation as client/application bandwi= dth and connectivity requirements may change. Therefore, should we categorize ACTN transport networks as being Connection= Orientated (CO) and Traffic Engineered (TE): - Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE) - Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE) And, do we exclude: Connection-less Packet Switched (CL-PS)? When we investigate and document use cases (technology or application speci= fic) might we then focus discussions on ACTN supporting the following techn= ologies: - WSON - OTN - MPLS-TP - MPLS-TE And what about: - OpenFlow (?) - ForCES (?) - Segment Routing (?) Also, would we need to define a new method, for resource description and re= source abstraction for each technology. Or reuse something (information and= data models) that already exist? Finally, do we discuss multi-layer scenarios with ACTN providing the capabi= lity for a client/application to view/use a topology, and also request adap= tations that are comprised of multiple layers? My concern is that the we do= not make the problem/solution search space too wide. At the same time, we = need to make sure that the ACTN problem statement and proposed Charter incl= udes near-term, and longer-term requirements. Br, Dan. --_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

During the ACTN bar-BoF in Vancouver (IETF88) there = was some discussion on the where we would apply ACTN, specifically which la= yer and subsequent technologies should be targeted/supported. Let’s s= tart with a few clarifications:

- By “transport network” do we mean serv= er network that provides connectivity for higher-layer packet networks, cli= ents and applications.

- A number of server network technologies exist at L= 1, L2, L3.

- Typically these server networks are run evenly to = minimise operational overhead, but lack flexibility/adaptability and dynami= c integration with client layers/interfaces/applications.

Now let’s review some high-level design goals:=

- ACTN interfaces with clients/applications (Data Ce= nters, Virtual Network Operators, et al.) to allow dynamic/automated connec= tivity and bandwidth request setup.

- ACTN provides an abstracted view of the network re= sources, i.e., the client/application is agnostic of the underlying technol= ogy used within the transport layer.

- ACTN should facilitate the slicing (allocation) of= resources, for specific client interfaces and applications. The abstracted= topology should also be flexible (adaptable), and support adaptation as cl= ient/application bandwidth and connectivity requirements may change.

Therefore, should we categorize ACTN transport netwo= rks as being Connection Orientated (CO) and Traffic Engineered (TE):

- Connection Oriented Circuit Switched (CO-CS) &= Traffic Engineered (TE)

- Connection Oriented Packet Switched (CO-PS) & = Traffic Engineered (TE)

And, do we exclude:

Connection-less Packet Switched (CL-PS)?<= /p>

When we investigate and document use cases (technolo= gy or application specific) might we then focus discussions on ACTN support= ing the following technologies:

- WSON

- OTN

- MPLS-TP

- MPLS-TE

And what about:

- OpenFlow (?)

- ForCES (?)

- Segment Routing (?)

Also, would we need to define a new method, for reso= urce description and resource abstraction for each technology. Or reuse som= ething (information and data models) that already exist? <= /p>

Finally, do we discuss multi-layer scenarios with AC= TN providing the capability for a client/application to view/use a topology= , and also request adaptations that are comprised of multiple layers? My co= ncern is that the we do not make the problem/solution search space too wide. At the same time, we need to make = sure that the ACTN problem statement and proposed Charter includes near-ter= m, and longer-term requirements.

Br, Dan.

--_000_65174429B5AF4C45BD0798810EC48E0A0D35EFEX0MB2lancslocal_-- From diego.caviglia@ericsson.com Fri Dec 6 03:58:53 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7DE1ADEBB for ; Fri, 6 Dec 2013 03:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 s3-vUge7PrOd for ; Fri, 6 Dec 2013 03:58:49 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAB1AE36E for ; Fri, 6 Dec 2013 03:58:48 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-4b-52a1bbf4a265 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6B.05.23787.4FBB1A25; Fri, 6 Dec 2013 12:58:44 +0100 (CET) Received: from ESESSMB103.ericsson.se ([169.254.3.33]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0347.000; Fri, 6 Dec 2013 12:58:43 +0100 From: Diego Caviglia To: "actn@ietf.org" Thread-Topic: Abstraction and Control of Transport Networks ACTN Thread-Index: Ac7ydDTEIVTJo/gYQr2jb18xFPX4fg== Date: Fri, 6 Dec 2013 11:58:43 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C4D9977@ESESSMB103.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre6X3QuDDI5sErPY0nOBzeLFumAH Jo8lS34yeZw6kB7AFMVlk5Kak1mWWqRvl8CVcXL3ZPaC3mbGiu5dv9kaGH8XdTFyckgImEhs mtHJAmGLSVy4t56ti5GLQ0jgEKPEyVO/mUASQgKLGCW2P60AsdkEjCR2dcwEaxARUJZYfPgP G4jNLOAiceH1FbC4sIC1xMP2uawQNQ4S7Q0fmSBsPYld09aB2SwCKhKTnn8Dq+cV8JWYMO88 WJxRQFZiwu5FjBAzxSVuPZnPBHGcgMSSPeeZIWxRiZeP/7FC2IoSV6cvB6rhAKrPl9jzoBZi pKDEyZlPWCYwCs9CMmkWQtUsJFUQJToSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7Kkb23MTM nPRyw02MwOg4uOW37g7GU+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoEx0XNCRkRw6q0D6Wd62+39otxco9cEqV60ljAWXnRh8v4wvYl9sVImy1TnTYiUcNvAG+RS YXZnkeZt2asJy7isPv0IN7aQFLvzJS9TrucNq7DeJoFNfp5/GVi7y/m9/b92zfmp+DAxYc7t 2PAvi6SuRapf11ghPNWstbxRfW5d8CntoIyHfUosxRmJhlrMRcWJAId3aEhcAgAA Cc: "King, Daniel $d.king@lancaster.ac.uk$" Subject: [Actn] Abstraction and Control of Transport Networks ACTN X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:58:53 -0000 --_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all Some comments to the Dan list. Ciao D Hi All, During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on = the where we would apply ACTN, specifically which layer and subsequent tech= nologies should be targeted/supported. Let's start with a few clarification= s: - By "transport network" do we mean server network that provides connectivi= ty for higher-layer packet networks, clients and applications. [DC] Yes I think is a good definition; we need to promote this a little bit= if we would include L3, usually when someone says Transport people think t= o L0/1 - A number of server network technologies exist at L1, L2, L3. [DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2= =3DEth etc etc, L3=3DIP/MPLS - Typically these server networks are run evenly to minimize operational ov= erhead, but lack flexibility/adaptability and dynamic integration with clie= nt layers/interfaces/applications. [DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di= rectly driven by client layers/interface/applications but via intermediate = system e.g. NMS or automated control planes but the "trigger" of the set-up= is always in the hand of a human been...well always is may be too strong m= ost the time is human but very unlikely is linked to any applications Now let's review some high-level design goals: - ACTN interfaces with clients/applications (Data Centers, Virtual Network = Operators, et al.) to allow dynamic/automated connectivity and bandwidth re= quest setup. [DC] I would add teardown and modification - ACTN provides an abstracted view of the network resources, i.e., the clie= nt/application is agnostic of the underlying technology used within the tra= nsport layer. [DC] yes we should define better what we mean with abstract here....won't b= e easy. - ACTN should facilitate the slicing (allocation) of resources, for specifi= c client interfaces and applications. The abstracted topology should also b= e flexible (adaptable), and support adaptation as client/application bandwi= dth and connectivity requirements may change. Therefore, should we categorize ACTN transport networks as being Connection= Orientated (CO) and Traffic Engineered (TE): [DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp. Sounds g= ood - Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE) [DC] yes - Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE) [DC] I think here we'll avoid ATM, PBB-TE etc etc so basically is MPLS(-TP)= with RSVP-TE right? And, do we exclude: Connection-less Packet Switched (CL-PS)? [DC] agreed When we investigate and document use cases (technology or application speci= fic) might we then focus discussions on ACTN supporting the following techn= ologies: - WSON [DC] hmmm here WSON is a data plane plus a control plane....i would say DWD= M with or without a GMPLS/PCE based control plane - OTN [DC] as above with or without a GMPLS/PCE based control plane - MPLS-TP [DC] just the data plane here - MPLS-TE [DC] as above, do we want to consider also segment routing here? And what about: - OpenFlow (?) - ForCES (?) - Segment Routing (?) [DC]- I2RS (?) [DC]- PCEP (?) Also, would we need to define a new method, for resource description and re= source abstraction for each technology. Or reuse something (information and= data models) that already exist? [DC] I think ONF is doing a lot of work here so we should have a look. Finally, do we discuss multi-layer scenarios with ACTN providing the capabi= lity for a client/application to view/use a topology, and also request adap= tations that are comprised of multiple layers? [DC] I think this is one of the key point we have to solve and this why I s= aid the abstraction won't be easy My concern is that the we do not make the problem/solution search space too= wide. At the same time, we need to make sure that the ACTN problem stateme= nt and proposed Charter includes near-term, and longer-term requirements. [DC] Yes Br, Dan. --_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

&nbs= p; Some comments to the Dan list.

Ciao

Hi All,

During the ACTN bar-BoF in Vancouver (IETF88) ther= e was some discussion on the where we would apply ACTN, specifically which layer and subsequent technologies should be targeted/supported. Let&= #8217;s start with a few clarifications:

- By “transport network” do we mean se= rver network that provides connectivity for higher-layer packet networks, clients and applications.
[DC] Yes I think is a good definition; we need to promote this a little bit= if we would include L3, usually when someone says Transport people think t= o L0/1

- A number of server network technologies exist at= L1, L2, L3.
[DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2= =3DEth etc etc, L3=3DIP/MPLS

- Typically these server networks are run evenly t= o minimize operational overhead, but lack flexibility/adaptability and dynamic integration with client layers/interfaces/applications.
[DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di= rectly driven by client layers/interface/applications but via intermediate = system e.g. NMS or automated control planes but the “trigger” o= f the set-up is always in the hand of a human been…well always is may be too strong most the time is human but ver= y unlikely is linked to any applications

Now let’s review some high-level design goal= s:

- ACTN interfaces with clients/applications (Data = Centers, Virtual Network Operators, et al.) to allow dynamic/automated connectivity and bandwidth request setup.
[DC] I would add teardown and modification

- ACTN provides an abstracted view of the network = resources, i.e., the client/application is agnostic of the underlying technology used within the transport layer.
[DC] yes we should define better what we mean with abstract here….won= ’t be easy.

- ACTN should facilitate the slicing (allocation) = of resources, for specific client interfaces and applications. The abstracted topology should also be flexible (adaptable), and support a= daptation as client/application bandwidth and connectivity requirements may= change.

Therefore, should we categorize ACTN transport net= works as being Connection Orientated (CO) and Traffic Engineered (TE):
[DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp. Sou= nds good

- Connection Oriented Circuit Switched (CO-CS) &am= p; Traffic Engineered (TE)
[DC] yes

- Connection Oriented Packet Switched (CO-PS) &= ; Traffic Engineered (TE)
[DC] I think here we’ll avoid ATM, PBB-TE etc etc so basically is MPL= S(-TP) with RSVP-TE right?

And, do we exclude:

Connection-less Packet Switched (CL-PS)?
[DC] agreed

When we investigate and document use cases (techno= logy or application specific) might we then focus discussions on ACTN supporting the following technologies:

- WSON
[DC] hmmm here WSON is a data plane plus a control plane….i would say= DWDM with or without a GMPLS/PCE based control plane

- OTN
[DC] as above with or without a GMPLS/PCE based control plane

- MPLS-TP
[DC] just the data plane here

- MPLS-TE
[DC] as above, do we want to consider also segment routing here?=

And what about:

- OpenFlow (?)

- ForCES (?)

- Segment Routing (?)

[DC]- I2RS (?)

[DC]- PCEP (?)

Also, would we need to define a new method, for re= source description and resource abstraction for each technology. Or reuse something (information and data models) that already exist?
[DC] I think ONF is doing a lot of work here so we should have a look.=

Finally, do we discuss multi-layer scenarios with = ACTN providing the capability for a client/application to view/use a topology, and also request adaptations that are comprised of mu= ltiple layers?
[DC] I think this is one of the key point we have to solve and this why I s= aid the abstraction won’t be easy

My concern is that the we do not make the problem/solution search space too= wide. At the same time, we need to make sure that the ACTN problem stateme= nt and proposed Charter includes near-term, and longer-term requirements.
[DC] Yes

Br, Dan.

&nbs= p; =

--_000_4E9BAD336C18BD49A429157A855607F11C4D9977ESESSMB103erics_-- From leeyoung@huawei.com Fri Dec 6 07:54:35 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C41ADFFB for ; Fri, 6 Dec 2013 07:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gOXujRJa9Rxt for ; Fri, 6 Dec 2013 07:54:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5D31ADA5D for ; Fri, 6 Dec 2013 07:54:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR85244; Fri, 06 Dec 2013 15:54:24 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 15:53:28 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 15:54:20 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 07:54:18 -0800 From: Leeyoung To: "King, Daniel" , "actn@ietf.org" Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+FgAmqF0A Date: Fri, 6 Dec 2013 15:54:17 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com> References: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.96] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Actn] Definition of "Transport Network" and requirements within the context of ACTN X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:54:35 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, I think this is very useful discussion. Here's my comment inline. Thanks. Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of King, Daniel Sent: Thursday, December 05, 2013 2:57 PM To: actn@ietf.org Subject: [Actn] Definition of "Transport Network" and requirements within t= he context of ACTN Hi All, During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on = the where we would apply ACTN, specifically which layer and subsequent tech= nologies should be targeted/supported. Let's start with a few clarification= s: - By "transport network" do we mean server network that provides connectivi= ty for higher-layer packet networks, clients and applications. - A number of server network technologies exist at L1, L2, L3. - Typically these server networks are run evenly to minimise operational ov= erhead, but lack flexibility/adaptability and dynamic integration with clie= nt layers/interfaces/applications. Now let's review some high-level design goals: - ACTN interfaces with clients/applications (Data Centers, Virtual Network = Operators, et al.) to allow dynamic/automated connectivity and bandwidth re= quest setup. - ACTN provides an abstracted view of the network resources, i.e., the clie= nt/application is agnostic of the underlying technology used within the tra= nsport layer. - ACTN should facilitate the slicing (allocation) of resources, for specifi= c client interfaces and applications. The abstracted topology should also b= e flexible (adaptable), and support adaptation as client/application bandwi= dth and connectivity requirements may change. YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) = network-wide abstracted topology and (ii) client-specific abstracted topolo= gy. The former one is for general usage to include all end-points of the ne= twork similar to ALTO topology map. Of course, the abstracted topology can = have a graph form to give a bit more detail than just giving a tunnel view.= The latter one is specific to the client in terms of a set of limited clie= nt-end points, client's objective function (this means client has a certain= service objective such as delay, bandwidth, reliability of paths, etc) as = well as the abstraction level. Some client may want to see just a tunnel vi= ew (similar to ALTO topology map) while other clients may want to see more = detail than a tunnel view. YOUNG>> Basically, the interface facing clients should be able to support t= his programmable aspects of the client-specificity. As you said, this inter= face and abstracted topology should be flexible/adaptable and there should = a mechanism to support changes to topology from physical to abstracted. Thi= s interaction makes this work very interesting, I think. Therefore, should we categorize ACTN transport networks as being Connection= Orientated (CO) and Traffic Engineered (TE): - Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE) - Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE) YOUNG>> I think this is a good starting point. The underlying transport net= works should be able to "guarantee" network resource committed to the clien= t when client makes use of them. From that angle, TE-based transport networ= ks make sense as a starting point. Also when network releases abstract topo= logy to the clients, the link characteristics should tell some resource inf= ormation about the network. TE-metric is a good way to say that. And, do we exclude: Connection-less Packet Switched (CL-PS)? When we investigate and document use cases (technology or application speci= fic) might we then focus discussions on ACTN supporting the following techn= ologies: - WSON - OTN - MPLS-TP - MPLS-TE And what about: - OpenFlow (?) - ForCES (?) - Segment Routing (?) YOUNG>> As long as any of these can support traffic engineering principle,= we can include them, especially SR. I am not sure OF and ForCES as they ar= e just protocols, not data plane technologies. Also, would we need to define a new method, for resource description and re= source abstraction for each technology. Or reuse something (information and= data models) that already exist? YOUNG>> There is some work in ALTO area based on JSON encoding. If we can r= e-use some existing framework. Finally, do we discuss multi-layer scenarios with ACTN providing the capabi= lity for a client/application to view/use a topology, and also request adap= tations that are comprised of multiple layers? My concern is that the we do= not make the problem/solution search space too wide. At the same time, we = need to make sure that the ACTN problem statement and proposed Charter incl= udes near-term, and longer-term requirements. YOUNG>> I agree. Br, Dan. --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,

I think this is very u= seful discussion. Here’s my comment inline.

Thanks.

Young

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of King, Daniel
Sent: Thursday, December 05, 2013 2:57 PM
To: actn@ietf.org
Subject: [Actn] Definition of "Transport Network" and requ= irements within the context of ACTN

Hi All,

During the ACTN bar-BoF in Vanc= ouver (IETF88) there was some discussion on the where we would apply ACTN, = specifically which layer and subsequent technologies should be targeted/sup= ported. Let’s start with a few clarifications:

- By “transport network&#= 8221; do we mean server network that provides connectivity for higher-layer= packet networks, clients and applications.

- A number of server network te= chnologies exist at L1, L2, L3.

- Typically these server networ= ks are run evenly to minimise operational overhead, but lack flexibility/ad= aptability and dynamic integration with client layers/interfaces/applicatio= ns.

Now let’s review some hig= h-level design goals:

- ACTN interfaces with clients/= applications (Data Centers, Virtual Network Operators, et al.) to allow dyn= amic/automated connectivity and bandwidth request setup.

- ACTN provides an abstracted v= iew of the network resources, i.e., the client/application is agnostic of t= he underlying technology used within the transport layer.

- ACTN should facilitate the sl= icing (allocation) of resources, for specific client interfaces and applica= tions. The abstracted topology should also be flexible (adaptable), and sup= port adaptation as client/application bandwidth and connectivity requirements may change.

&n= bsp;

YOUNG&g= t;> Yes. The abstracted topology has two types generally speaking: (i) n= etwork-wide abstracted topology and (ii) client-specific abstracted topolog= y. The former one is for general usage to include all end-points of the network similar to ALTO topology map. Of course, the= abstracted topology can have a graph form to give a bit more detail than j= ust giving a tunnel view. The latter one is specific to the client in terms= of a set of limited client-end points, client’s objective function (this means client has a certain= service objective such as delay, bandwidth, reliability of paths, etc) as = well as the abstraction level. Some client may want to see just a tunnel vi= ew (similar to ALTO topology map) while other clients may want to see more detail than a tunnel view. <= /span>

&n= bsp;

YOUNG&g= t;> Basically, the interface facing clients should be able to support th= is programmable aspects of the client-specificity. As you said, this interf= ace and abstracted topology should be flexible/adaptable and there should a mechanism to support changes to topology from physical = to abstracted. This interaction makes this work very interesting, I think.<= o:p>

Therefore, should we categorize= ACTN transport networks as being Connection Orientated (CO) and Traffic En= gineered (TE):

- Connection Oriented Circuit S= witched (CO-CS) & Traffic Engineered (TE)

- Connection Oriented Packet Sw= itched (CO-PS) & Traffic Engineered (TE)

&n= bsp;

YOUNG&g= t;> I think this is a good starting point. The underlying transport netw= orks should be able to “guarantee” network resource committed t= o the client when client makes use of them. From that angle, TE-based transport networks make sense as a starting point. Also when netw= ork releases abstract topology to the clients, the link characteristics sho= uld tell some resource information about the network. TE-metric is a good w= ay to say that.

&n= bsp;

And, do we exclude:<= /span>

Connection-less Packet Switched= (CL-PS)?

&n= bsp;

When we investigate and documen= t use cases (technology or application specific) might we then focus discus= sions on ACTN supporting the following technologies:

- WSON

- OTN

- MPLS-TP

- MPLS-TE

And what about:

- OpenFlow (?)

- ForCES (?)<= /p>

- Segment Routing (?)

YOUNG&g= t;> As long as any of these can support traffic engineering princi= ple, we can include them, especially SR. I am not sure OF and ForCES as the= y are just protocols, not data plane technologies.

&n= bsp;

Also, would we need to define a= new method, for resource description and resource abstraction for each tec= hnology. Or reuse something (information and data models) that already exis= t?

YOUNG&g= t;> There is some work in ALTO area based on JSON encoding. If we can re= -use some existing framework.

Finally, do we discuss multi-la= yer scenarios with ACTN providing the capability for a client/application t= o view/use a topology, and also request adaptations that are comprised of m= ultiple layers? My concern is that the we do not make the problem/solution search space too wide. At the same tim= e, we need to make sure that the ACTN problem statement and proposed Charte= r includes near-term, and longer-term requirements.

YOUNG&g= t;> I agree.

Br, Dan.

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1dfweml510mbxchi_-- From leeyoung@huawei.com Fri Dec 6 09:25:54 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F61ADF6E for ; Fri, 6 Dec 2013 09:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QslzrTyQtxUN for ; Fri, 6 Dec 2013 09:25:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 607E21AD83F for ; Fri, 6 Dec 2013 09:25:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBC13827; Fri, 06 Dec 2013 17:25:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 17:24:49 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 17:25:42 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 09:25:39 -0800 From: Leeyoung To: Diego Caviglia , "actn@ietf.org" Thread-Topic: Abstraction and Control of Transport Networks ACTN Thread-Index: Ac7ydDTEIVTJo/gYQr2jb18xFPX4fgAKWN+A Date: Fri, 6 Dec 2013 17:25:38 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729B9C23E@dfweml510-mbx.china.huawei.com> References: <4E9BAD336C18BD49A429157A855607F11C4D9977@ESESSMB103.ericsson.se> In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C4D9977@ESESSMB103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.96] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "King, Daniel $d.king@lancaster.ac.uk$" Subject: Re: [Actn] Abstraction and Control of Transport Networks ACTN X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:25:54 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Diego, Great discussion. Please see my comment inline. Regards, Young From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Diego Caviglia Sent: Friday, December 06, 2013 5:59 AM To: actn@ietf.org Cc: King, Daniel (d.king@lancaster.ac.uk) Subject: [Actn] Abstraction and Control of Transport Networks ACTN Hi all Some comments to the Dan list. Ciao D Hi All, During the ACTN bar-BoF in Vancouver (IETF88) there was some discussion on = the where we would apply ACTN, specifically which layer and subsequent tech= nologies should be targeted/supported. Let's start with a few clarification= s: - By "transport network" do we mean server network that provides connectivi= ty for higher-layer packet networks, clients and applications. [DC] Yes I think is a good definition; we need to promote this a little bit= if we would include L3, usually when someone says Transport people think t= o L0/1 YOUNG>> "transport network" defined as connectivity for HL packet networks= , clients and applications is a good definition, beyond just packet network= s. Packet networks themselves can also be a server 'transport network' to c= lients/applications. In that sense, we have a wider scope of what 'transpor= t network' is. But we have to recognize the nature of applications/clients = may differ as to what 'transport' service they choose. For best-effort appl= ications, L3 transport may be adequate; for services/applications needing s= tringent QoS and resource reservations/guarantee, TE-based transport may be= adequate. The point is that the driver is the requirement of clients/applications. - A number of server network technologies exist at L1, L2, L3. [DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2= =3DEth etc etc, L3=3DIP/MPLS - Typically these server networks are run evenly to minimize operational ov= erhead, but lack flexibility/adaptability and dynamic integration with clie= nt layers/interfaces/applications. [DC] hmmmm I would say to lower the cost/bit/Km I would say that are not di= rectly driven by client layers/interface/applications but via intermediate = system e.g. NMS or automated control planes but the "trigger" of the set-up= is always in the hand of a human been...well always is may be too strong m= ost the time is human but very unlikely is linked to any applications YOUNG>> This is a good point. There is a need for an intermediate system su= ch as "mediation layer" or "virtualization layer" between client/applicatio= n and the transport network that can support programmable interfaces. This = programmable intermediate system is neither NMS nor automated control plane= s. This is 'shim' layer that facilitates the activity of NMS or automated c= ontrol planes. Now let's review some high-level design goals: - ACTN interfaces with clients/applications (Data Centers, Virtual Network = Operators, et al.) to allow dynamic/automated connectivity and bandwidth re= quest setup. [DC] I would add teardown and modification YOUNG>> Agree. In addition to this, I see the value for monitoring/notifica= tion between transport networks and clients/applications. - ACTN provides an abstracted view of the network resources, i.e., the clie= nt/application is agnostic of the underlying technology used within the tra= nsport layer. [DC] yes we should define better what we mean with abstract here....won't b= e easy. YOUNG>> Yes, this is one of the most important work items as to how to char= acterize/define abstraction. There are two issues: (i) how to represent the= underlying resource into applications - this is information/data model; (i= i) how to efficiently map between physical resources and virtual resources = and how accurate the abstraction is --- this is about compute model and alg= orithm. This aspect is a research item that needs to be worked out in paral= lel with the info/data model. The compute model and algorithm work is perha= ps addressed in SDN RG in parallel to ACTN. - ACTN should facilitate the slicing (allocation) of resources, for specifi= c client interfaces and applications. The abstracted topology should also b= e flexible (adaptable), and support adaptation as client/application bandwi= dth and connectivity requirements may change. Therefore, should we categorize ACTN transport networks as being Connection= Orientated (CO) and Traffic Engineered (TE): [DC] so p2p and p2mp are part of the work but NOT mp2p and mp2mp. Sounds g= ood YOUNG>> I agree. - Connection Oriented Circuit Switched (CO-CS) & Traffic Engineered (TE) [DC] yes - Connection Oriented Packet Switched (CO-PS) & Traffic Engineered (TE) [DC] I think here we'll avoid ATM, PBB-TE etc etc so basically is MPLS(-TP)= with RSVP-TE right? And, do we exclude: Connection-less Packet Switched (CL-PS)? [DC] agreed When we investigate and document use cases (technology or application speci= fic) might we then focus discussions on ACTN supporting the following techn= ologies: - WSON [DC] hmmm here WSON is a data plane plus a control plane....i would say DWD= M with or without a GMPLS/PCE based control plane - OTN [DC] as above with or without a GMPLS/PCE based control plane - MPLS-TP [DC] just the data plane here - MPLS-TE [DC] as above, do we want to consider also segment routing here? And what about: - OpenFlow (?) - ForCES (?) - Segment Routing (?) [DC]- I2RS (?) [DC]- PCEP (?) Also, would we need to define a new method, for resource description and re= source abstraction for each technology. Or reuse something (information and= data models) that already exist? [DC] I think ONF is doing a lot of work here so we should have a look. Finally, do we discuss multi-layer scenarios with ACTN providing the capabi= lity for a client/application to view/use a topology, and also request adap= tations that are comprised of multiple layers? [DC] I think this is one of the key point we have to solve and this why I s= aid the abstraction won't be easy YOUNG>> Yes, we discussed this aspect earlier. My concern is that the we do not make the problem/solution search space too= wide. At the same time, we need to make sure that the ACTN problem stateme= nt and proposed Charter includes near-term, and longer-term requirements. [DC] Yes Br, Dan. --_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Diego,

Great discussion. Plea= se see my comment inline.

Regards,

Young

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Diego Caviglia
Sent: Friday, December 06, 2013 5:59 AM
To: actn@ietf.org
Cc: King, Daniel (d.king@lancaster.ac.uk)
Subject: [Actn] Abstraction and Control of Transport Networks ACTN

Hi all

&nbs= p; Some comments to the Dan list.

Ciao

Hi All,

YOUNG>> “transport= network” defined as connectivity for HL packet networks, clients and= applications is a good definition, beyond just packet networks. Packet networks themselves can also be a server ‘transport network&#= 8217; to clients/applications. In that sense, we have a wider scope of what= ‘transport network’ is. But we have to recognize the nature of= applications/clients may differ as to what ‘transport’ service they choose. For best-effort applications, L3 transport may be ade= quate; for services/applications needing stringent QoS and resource reserva= tions/guarantee, TE-based transport may be adequate.

The point is that the driver is the = requirement of clients/applications.

- A number of server network technologies exist at= L1, L2, L3.
[DC] hmmm I would add L0 say L0=3DDWDM, L1=3DTDM Stuff (SDH/SONET/OTN), L2= =3DEth etc etc, L3=3DIP/MPLS

YOUNG>> This is a good point. = There is a need for an intermediate system such as “mediation layer&#= 8221; or “virtualization layer” between client/application and the transport network that can support programmable interfaces. This p= rogrammable intermediate system is neither NMS nor automated control planes= . This is ‘shim’ layer that facilitates the activity of NMS or = automated control planes.

Now let’s review some high-level design goal= s:

YOUNG>> Agree. In addition to = this, I see the value for monitoring/notification between transport network= s and clients/applications.

YOUNG>> Yes, this is one of th= e most important work items as to how to characterize/define abstraction. T= here are two issues: (i) how to represent the underlying resource into applications – this is information/data mod= el; (ii) how to efficiently map between physical resources and virtual reso= urces and how accurate the abstraction is --- this is about compute model a= nd algorithm. This aspect is a research item that needs to be worked out in parallel with the info/data model. The= compute model and algorithm work is perhaps addressed in SDN RG in paralle= l to ACTN.

- ACTN should facilitate the slicing (allocation) of res= ources, for specific client interfaces and applications. The abstracted topology should also be flexible (adaptable), and support adapt= ation as client/application bandwidth and connectivity requirements may cha= nge.

YOUNG>> I agree.

- Connection Oriented Circuit Switched (CO-CS) &am= p; Traffic Engineered (TE)
[DC] yes

- Connection Oriented Packet Switched (CO-PS) &= ; Traffic Engineered (TE)
[DC] I think here we’ll avoid ATM, PBB-TE etc etc so basically is MPL= S(-TP) with RSVP-TE right?

And, do we exclude:

Connection-less Packet Switched (CL-PS)?
[DC] agreed

When we investigate and document use cases (techno= logy or application specific) might we then focus discussions on ACTN supporting the following technologies:

- WSON
[DC] hmmm here WSON is a data plane plus a control plane….i would say= DWDM with or without a GMPLS/PCE based control plane

- OTN
[DC] as above with or without a GMPLS/PCE based control plane

- MPLS-TP
[DC] just the data plane here

- MPLS-TE
[DC] as above, do we want to consider also segment routing here?=

And what about:

- OpenFlow (?)

- ForCES (?)

- Segment Routing (?)

[DC]- I2RS (?)

[DC]- PCEP (?)

YOUNG>> Yes, we discussed this= aspect earlier.

My concern is that the we do not make the problem/solution search space too= wide. At the same time, we need to make sure that the ACTN problem stateme= nt and proposed Charter includes near-term, and longer-term requirements.
[DC] Yes

Br, Dan.

&nbs= p; =

--_000_7AEB3D6833318045B4AE71C2C87E8E1729B9C23Edfweml510mbxchi_-- From dhruv.dhody@huawei.com Sun Dec 8 20:03:01 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD24B1AC7F1 for ; Sun, 8 Dec 2013 20:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 caYU5yRRpjjE for ; Sun, 8 Dec 2013 20:02:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97C1AE1C7 for ; Sun, 8 Dec 2013 20:02:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT33775; Mon, 09 Dec 2013 04:02:53 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 04:02:49 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 04:02:51 +0000 Received: from szxeml556-mbs.china.huawei.com ([169.254.4.227]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 12:02:39 +0800 From: Dhruv Dhody To: Leeyoung , "King, Daniel" , "actn@ietf.org" Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+FgAmqF0AAH7pHMA= Date: Mon, 9 Dec 2013 04:02:38 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B52143CB7@szxeml556-mbs.china.huawei.com> References: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Actn] Definition of "Transport Network" and requirements within the context of ACTN X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 04:03:01 -0000 --_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, (snip) - ACTN should facilitate the slicing (allocation) of resources, for specifi= c client interfaces and applications. The abstracted topology should also b= e flexible (adaptable), and support adaptation as client/application bandwi= dth and connectivity requirements may change. YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) = network-wide abstracted topology and (ii) client-specific abstracted topolo= gy. The former one is for general usage to include all end-points of the ne= twork similar to ALTO topology map. Of course, the abstracted topology can = have a graph form to give a bit more detail than just giving a tunnel view.= The latter one is specific to the client in terms of a set of limited clie= nt-end points, client's objective function (this means client has a certain= service objective such as delay, bandwidth, reliability of paths, etc) as = well as the abstraction level. Some client may want to see just a tunnel vi= ew (similar to ALTO topology map) while other clients may want to see more = detail than a tunnel view. [DD] Is (i) network-wide abstracted topology in scope of ACTN? Do you have = some use-case in mind for this? Conceptually I think (i) is just a special case of (ii) with all end-points= in network and no specific constraints. (snip) Regards, Dhruv --_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young,

(snip)

&n= bsp;

[DD] Is (i) network-w= ide abstracted topology in scope of ACTN? Do you have some use-case in mind= for this?

Conceptually I think = (i) is just a special case of (ii) with all end-points in network and no sp= ecific constraints.

(snip)

Regards,<= /p>

Dhruv

--_000_23CE718903A838468A8B325B80962F9B52143CB7szxeml556mbschi_-- From leeyoung@huawei.com Mon Dec 9 08:23:34 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349F1AE313 for ; Mon, 9 Dec 2013 08:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 R77lNtC_8cVi for ; Mon, 9 Dec 2013 08:23:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4E1AE2C0 for ; Mon, 9 Dec 2013 08:23:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYU01754; Mon, 09 Dec 2013 16:23:22 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 16:23:17 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 16:23:21 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 08:23:12 -0800 From: Leeyoung To: Dhruv Dhody , "King, Daniel" , "actn@ietf.org" Thread-Topic: Definition of "Transport Network" and requirements within the context of ACTN Thread-Index: Ac7x/H/R/7nh5QYeTl+IGwUIewp+FgAmqF0AAH7pHMAAGWAHoA== Date: Mon, 9 Dec 2013 16:23:12 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA2042@dfweml510-mbx.china.huawei.com> References: <65174429B5AF4C45BD0798810EC48E0A0D35EF@EX-0-MB2.lancs.local> <7AEB3D6833318045B4AE71C2C87E8E1729B9C1E1@dfweml510-mbx.china.huawei.com> <23CE718903A838468A8B325B80962F9B52143CB7@szxeml556-mbs.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B52143CB7@szxeml556-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Actn] Definition of "Transport Network" and requirements within the context of ACTN X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:23:34 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dhruv, What I was envisioning on a network-wide abstracted topology is a repositor= y of the baseline network resource view which derives from physical network= resource view. As you said, there is no specific constraints on this topol= ogy with all end-points. Perhaps, client-specific abstracted topology is a special of this general n= etwork-wide abstracted topology. >From this network-wide abstracted topology, each client-specific abstracted= topology is derived. As network resource is sliced to the list of clients,= this network-wide abstracted topology is updated so that it gives the holi= stic network resource availability. If the client is a packet network administration/controller which has the = same administrative domain as the optical transport network, then the packe= t network administrator may want inquire the network-wide abstracted topolo= gy for its operation. There may be other cases where this network-wide abs= tracted topology may be useful to share under policy and security constrain= ts. Please note that this network-wide abstracted topology is different from a = physical network topology. The virtual network controller needs to maintain= this "master" DB to administer its virtual network control capability to i= ts clients. Regards, Young From: Dhruv Dhody Sent: Sunday, December 08, 2013 10:03 PM To: Leeyoung; King, Daniel; actn@ietf.org Subject: RE: Definition of "Transport Network" and requirements within the = context of ACTN Hi Young, (snip) - ACTN should facilitate the slicing (allocation) of resources, for specifi= c client interfaces and applications. The abstracted topology should also b= e flexible (adaptable), and support adaptation as client/application bandwi= dth and connectivity requirements may change. YOUNG>> Yes. The abstracted topology has two types generally speaking: (i) = network-wide abstracted topology and (ii) client-specific abstracted topolo= gy. The former one is for general usage to include all end-points of the ne= twork similar to ALTO topology map. Of course, the abstracted topology can = have a graph form to give a bit more detail than just giving a tunnel view.= The latter one is specific to the client in terms of a set of limited clie= nt-end points, client's objective function (this means client has a certain= service objective such as delay, bandwidth, reliability of paths, etc) as = well as the abstraction level. Some client may want to see just a tunnel vi= ew (similar to ALTO topology map) while other clients may want to see more = detail than a tunnel view. [DD] Is (i) network-wide abstracted topology in scope of ACTN? Do you have = some use-case in mind for this? Conceptually I think (i) is just a special case of (ii) with all end-points= in network and no specific constraints. (snip) Regards, Dhruv --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dhruv,

What I was envisioning= on a network-wide abstracted topology is a repository of the baseline netw= ork resource view which derives from physical network resource view. As you= said, there is no specific constraints on this topology with all end-points.

Perhaps, client-specif= ic abstracted topology is a special of this general network-wide abstracted= topology.

From this network-wide= abstracted topology, each client-specific abstracted topology is derived. = As network resource is sliced to the list of clients, this network-wide abs= tracted topology is updated so that it gives the holistic network resource availability.

If the client is a pac= ket network administration/controller which has the same administrati= ve domain as the optical transport network, then the packet network adminis= trator may want inquire the network-wide abstracted topology for its operation. There may be other cases wher= e this network-wide abstracted topology may be useful to share under policy= and security constraints.

Please note that this = network-wide abstracted topology is different from a physical network topol= ogy. The virtual network controller needs to maintain this “master= 221; DB to administer its virtual network control capability to its clients.

Regards,

Young

From: Dhruv Dh= ody
Sent: Sunday, December 08, 2013 10:03 PM
To: Leeyoung; King, Daniel; actn@ietf.org
Subject: RE: Definition of "Transport Network" and require= ments within the context of ACTN

Hi Young,

(snip)

&n= bsp;

[DD] Is (i) network-w= ide abstracted topology in scope of ACTN? Do you have some use-case in mind= for this?

Conceptually I think = (i) is just a special case of (ii) with all end-points in network and no sp= ecific constraints.

(snip)

Regards,<= /p>

Dhruv

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA2042dfweml510mbxchi_-- From leeyoung@huawei.com Tue Dec 17 08:34:32 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2491AE1B6 for ; Tue, 17 Dec 2013 08:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable 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 pt7PFTXdHORd for ; Tue, 17 Dec 2013 08:34:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBFCF1AE1C7 for ; Tue, 17 Dec 2013 08:34:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC49490; Tue, 17 Dec 2013 16:34:25 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 16:33:58 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 16:34:24 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 08:34:20 -0800 From: Leeyoung To: "actn@ietf.org" Thread-Topic: virtual network mapping/embedding (VNM/VNE) problem Thread-Index: Ac77RdTjI/gEkOJNRuyLHsDiwda0eQ== Date: Tue, 17 Dec 2013 16:34:19 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sdn@irtf.org" Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:34:33 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Related to the ACTN work, there has been active research termed "virtual ne= twork mapping/embedding (VNM/VNE)": Here's some pointer to key papers: http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and= path migration) http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf= (survivable VNE) http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef= ficient VNE) The focus of ACTN perhaps does not have a direct bearing with these papers = as they are concerned about the VNM/VNE algorithms; however, these bring so= me key issues and constraints for virtual network path computation. These i= ssues and constraints should be of interest of the ACTN work that may impac= t on the design, information models and interface/protocol extensions (if n= ecessary). Some of the issues such as efficiency of algorithm are perhaps = better fit to SDN RG, some of key issues and constraints for virtual netwo= rk path computation related to VNM/VNE are as follows: - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Related to the ACTN work, there has been active rese= arch termed “virtual network mapping/embedding (VNM/VNE)”:=

Here’s some pointer to key papers:<= /p>

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with= path split and path migration)

http://nsm1.cs.uwaterloo.ca/rboutaba/Pa= pers/Conferences/2010/Muntasir10.pdf (survivable VNE)

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber= =3D5616527 (Resource Efficient VNE)

The focus of ACTN perhaps does not have a direct bea= ring with these papers as they are concerned about the VNM/VNE algorithms; = however, these bring some key issues and constraints for virtual network pa= th computation. These issues and constraints should be of interest of the ACTN work that may impact on the design, info= rmation models and interface/protocol extensions (if necessary). Some= of the issues such as efficiency of algorithm are perhaps better fit to SD= N RG, some of key issues and constraints for virtual network path computation related to VNM/VNE are as follows:

=

<= ![if !supportLists]>- Request Processing

This is concerned about whether a set of client requ= ests for VN creation can be dealt with simultaneously or not. This depends = on the nature of applications the client support. If the client does not re= quire real-time instantiation of VN creation, the computation engine can process a set of VN creation requests= simultaneously to improve network efficiency.

<= a name=3D"_Toc374709104">- Types of Network Resources

When client makes a VN creation request to the subst= rate network, what kind of network resources is consumed is of concern of b= oth the client and network providers. It depends on the application. For tr= ansport network virtualization, the network resource consumed by the client is primarily network bandwidth tha= t the paths would occupy on the physical link. However, there may be other = resource types such as CPU and memory that need to be considered for certai= n applications. These resource types are a part of the client’s VN request.

<= ![if !supportLists]>- Accuracy of Network Resource Representation

As the underlying transport network in itself may co= nsists of layered structure, it is a challenge how to represent these under= lying physical network resources and topology into a form that can be relia= bly used by the computation engine that assigns the client requests into the physical network resource and to= pology.

<= ![if !supportLists]>- Resource Efficiency

Related to the accuracy of network resource represen= tation is resource efficiency. As a set of independent client VN is created= and mapped onto physical network resources, the overall network resource u= tilization is of the primary concern of the infrastructure provider.

<= ![if !supportLists]>- Guarantee of Client Isolation

While network resource sharing across a set of clien= ts for efficient utilization is important aspect of network virtualization,= client isolation has to be guaranteed. Admissions of new client requests o= r any changes of other existing clients’ VNs must not affect any particular client in terms of resource guarantee, = security constraints, and other performance constraints.

<= ![if !supportLists]>- Computing Time

Depending on the nature of applications, how quickly= a VN is instantiated from the time of request is an important factor. For = dynamic applications that require instantaneous VN creation, the computatio= n model/algorithm should support this constraint.

<= ![if !supportLists]>- Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

<= a name=3D"_Toc374709110">- Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation. Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_-- From daniele.ceccarelli@ericsson.com Fri Dec 20 02:30:50 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72EB1AE1B6 for ; Fri, 20 Dec 2013 02:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 sA71F09ReBaI for ; Fri, 20 Dec 2013 02:30:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8A11AE1B9 for ; Fri, 20 Dec 2013 02:30:45 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-fb-52b41c52f09d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.77.23787.25C14B25; Fri, 20 Dec 2013 11:30:42 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.140]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0347.000; Fri, 20 Dec 2013 11:30:17 +0100 From: Daniele Ceccarelli To: Leeyoung , "actn@ietf.org" Thread-Topic: [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: Ac77RdTjI/gEkOJNRuyLHsDiwda0eQBgPBxw Date: Fri, 20 Dec 2013 10:30:17 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvrW6QzJYgg38n1Sy29Fxgs5g2z9Xi /ILnLA7MHi1H3rJ6LFnyk8lj8sbDbAHMUVw2Kak5mWWpRfp2CVwZr1pWMhZ0f2CsWHD/AUsD 48vzjF2MnBwSAiYSJ67uZYawxSQu3FvP1sXIxSEkcIhR4ub8l1DOEkaJv9tWsnYxcnCwCVhJ PDnkA9IgIuAssWH7UbBmZgFFiRPPn4ENFRbwkLjef4IZosZTYu7Gh4wQtpHE5NZZYDaLgKrE yTVn2UFsXgFfiSuHdoDVCwmESqyce5wJxOYUCJP4cus6mM0oICsxYfciRohd4hK3nsxngjha QGLJnvNQD4hKvHz8jxXCVpS4On05E0R9vsTal51MELsEJU7OfMIygVF0FpJRs5CUzUJSBhHX k7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGy5yZm5qSXG25iBEbawS2/dXcwnjoncohR moNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MKQ/0F3+fJVz1VVxqwr49Wece rz5w8ueDd/PZrLy1Nmgs+h/4SsGCaVnZq00dHs9+R05yW7367a+yU/2SD7Rs7nme17YvF22Z LiAYt9GC/WiHxnuDs2tvTTK43rNv9bGHl55Grsx63uU+JdTr1k/uFA+b5Iyf59XXXDu09cpu a8n/u3bcvLlg3z8lluKMREMt5qLiRADPxci6ggIAAA== Cc: "sdn@irtf.org" Subject: Re: [Actn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 10:30:50 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Young, Thanks for the pointers and the list of issues. Please find in line some loud thinking from my side. BR Daniele From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: marted=EC 17 dicembre 2013 17:34 To: actn@ietf.org Cc: sdn@irtf.org Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem Related to the ACTN work, there has been active research termed "virtual ne= twork mapping/embedding (VNM/VNE)": Here's some pointer to key papers: http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and= path migration) http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf= (survivable VNE) http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef= ficient VNE) The focus of ACTN perhaps does not have a direct bearing with these papers = as they are concerned about the VNM/VNE algorithms; however, these bring so= me key issues and constraints for virtual network path computation. These i= ssues and constraints should be of interest of the ACTN work that may impac= t on the design, information models and interface/protocol extensions (if n= ecessary). Some of the issues such as efficiency of algorithm are perhaps = better fit to SDN RG, some of key issues and constraints for virtual netwo= rk path computation related to VNM/VNE are as follows: - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. [[DC]] I think here we can assume that VN creation requests are non real ti= me. Instantiation of services and bandwidth might be real time (and hence c= oncurrency needs to be managed) but I would say this is not the case of VN = creation. - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. [[DC]] Here the issue is thorny. The point is: a given resource is dedicate= d to a given VN or shared among different ones? We should start considering= network resources partitioning issues... - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. [[DC]] Damnly true - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. [[DC]] This issue is pretty much linked to the one above (types of network = resources) - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. [[DC]] Again linked to issues above. If network resources are dedicated to = each VN, this is true, but if they (or part of them) are shared, the instan= tiation of a service from a given client would impact the VN seen by others= . On the other side, aspects like security o performances should not be imp= acted in any of the two cases. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. [[DC]] I would say that timing constraints need to be met for service provi= sioning (i.e. upon client requests on a given VN) but I think VN instantiat= ion could be also a non real time procedure. I might be wrong...are there u= se cases for real time and timing constrained VN creation requrests? - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. [[DC]] Yes. To understand where is the best place to do that. Cline control= ? VNC? - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. [[DC]] True. With path constraints I think we should include something more= . When a client needs to setup a service/LSP there might be TE constraints = associated to the request. Whan the VN needs to include is not only reachab= ility information but in many cases is should be TE-reachability informatio= n. In this case we could leverage on the overlay work being done e.g. in CC= AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-= exchange-02). --_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Young,

Thanks for the pointer= s and the list of issues.

Please find in line so= me loud thinking from my side.

BR
Daniele

From: ACTN [ma= ilto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: marted=EC 17 dicembre 2013 17:34
To: actn@ietf.org
Cc: sdn@irtf.org
Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem<= o:p>

Related to the ACTN work, there has been active rese= arch termed “virtual network mapping/embedding (VNM/VNE)”:=

Here’s some pointer to key papers:<= /p>

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with= path split and path migration)

http://nsm1.cs.uwaterloo.ca/rboutaba/Pa= pers/Conferences/2010/Muntasir10.pdf (survivable VNE)

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber= =3D5616527 (Resource Efficient VNE)

=

- Request Processing

[[DC]] I think h= ere we can assume that VN creation requests are non real time. Instantiatio= n of services and bandwidth might be real time (and hence concurrency needs= to be managed) but I would say this is not the case of VN creation.

- Types of Network Resources

[[DC]] Here the = issue is thorny. The point is: a given resource is dedicated to a given VN = or shared among different ones? We should start considering network resourc= es partitioning issues…<= o:p>

- Accuracy of Network Resource Representation

[[DC]] Damnly tr= ue

- Resource Efficiency

[[DC]] This issu= e is pretty much linked to the one above (types of network resources)

- Guarantee of Client Isolation

[[DC]] Again lin= ked to issues above. If network resources are dedicated to each VN, this is= true, but if they (or part of them) are shared, the instantiation of a ser= vice from a given client would impact the VN seen by others. On the other side, aspects like security o performa= nces should not be impacted in any of the two cases.

- Computing Time

[[DC]] I would s= ay that timing constraints need to be met for service provisioning (i.e. up= on client requests on a given VN) but I think VN instantiation could be als= o a non real time procedure. I might be wrong…are there use cases for real time and timing constrained VN= creation requrests?

- Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

[[DC]] Yes. To u= nderstand where is the best place to do that. Cline control? VNC?

- Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation. Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

[[DC]] True. Wit= h path constraints I think we should include something more. When a client = needs to setup a service/LSP there might be TE constraints associated to th= e request. Whan the VN needs to include is not only reachability information but in many cases is should be TE-rea= chability information. In this case we could leverage on the overlay work b= eing done e.g. in CCAMP and in (http://tools.iet= f.org/html/draft-farrel-interconnected-te-info-exchange-02).

--_000_4A1562797D64E44993C5CBF38CF1BE4812662B06ESESSMB301erics_-- From leeyoung@huawei.com Fri Dec 20 11:12:32 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1985D1AE111 for ; Fri, 20 Dec 2013 11:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable 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 3_owhQ5YshZq for ; Fri, 20 Dec 2013 11:12:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF3B1AE101 for ; Fri, 20 Dec 2013 11:12:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZF47078; Fri, 20 Dec 2013 19:12:20 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 19:11:45 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 19:12:04 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 20 Dec 2013 11:12:00 -0800 From: Leeyoung To: Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/W6RDeEpEZPP50m1uop4SSQtEppdaWyQ Date: Fri, 20 Dec 2013 19:11:59 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.97] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sdn@irtf.org" Subject: Re: [Actn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 19:12:32 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniele, Thanks for your feedback and comments. Please see inline for my reply. Thanks. Young From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, December 20, 2013 4:30 AM To: Leeyoung; actn@ietf.org Cc: sdn@irtf.org Subject: RE: [Actn] virtual network mapping/embedding (VNM/VNE) problem Hi Young, Thanks for the pointers and the list of issues. Please find in line some loud thinking from my side. BR Daniele From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: marted=EC 17 dicembre 2013 17:34 To: actn@ietf.org Cc: sdn@irtf.org Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem Related to the ACTN work, there has been active research termed "virtual ne= twork mapping/embedding (VNM/VNE)": Here's some pointer to key papers: http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and= path migration) http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf= (survivable VNE) http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef= ficient VNE) The focus of ACTN perhaps does not have a direct bearing with these papers = as they are concerned about the VNM/VNE algorithms; however, these bring so= me key issues and constraints for virtual network path computation. These i= ssues and constraints should be of interest of the ACTN work that may impac= t on the design, information models and interface/protocol extensions (if n= ecessary). Some of the issues such as efficiency of algorithm are perhaps = better fit to SDN RG, some of key issues and constraints for virtual netwo= rk path computation related to VNM/VNE are as follows: - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. [[DC]] I think here we can assume that VN creation requests are non real ti= me. Instantiation of services and bandwidth might be real time (and hence c= oncurrency needs to be managed) but I would say this is not the case of VN = creation. YOUNG>> Good point. I was loose on the term 'VN creation". There are cert= ainly negotiation aspects of VN creation which can be viewed as non-real ti= me as the client endpoints need to be negotiated with network provider(s) b= efore service creation. Yes, in that sense, I agree with you. Here what I m= eant to say was when there are multiple service requests to setup virtual = connections that need not be instantiated real-time, (in other words, if so= me request can be queued for a delay scheduling), then a batch processing o= f multiple requests would be more optimal in general from a network efficie= ncy perspective than sequential processing. - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. [[DC]] Here the issue is thorny. The point is: a given resource is dedicate= d to a given VN or shared among different ones? We should start considering= network resources partitioning issues... YOUNG>> A given resource is "virtually" dedicated to a particular client; = yet this does not mean a particular client occupies a particular port (say = ODU port 1 vs 2). As long as resource is guaranteed for use to the client,= it is fine for the Working Path at least; however for 1:N kind of protecti= on case, there is a level of sharing backup path resource for multiple clie= nts. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. [[DC]] Damnly true - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. [[DC]] This issue is pretty much linked to the one above (types of network = resources) YOUNG>> Yes. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. [[DC]] Again linked to issues above. If network resources are dedicated to = each VN, this is true, but if they (or part of them) are shared, the instan= tiation of a service from a given client would impact the VN seen by others= . On the other side, aspects like security o performances should not be imp= acted in any of the two cases. YOUNG>> Agree. So I guess we need to be clear on resource partitioning and= sharing issue clearly --- I think some application/client requires a hard = dedicated resource while for some others it is fluid. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. [[DC]] I would say that timing constraints need to be met for service provi= sioning (i.e. upon client requests on a given VN) but I think VN instantiat= ion could be also a non real time procedure. I might be wrong...are there u= se cases for real time and timing constrained VN creation requrests? YOUNG>> Again here what I meant was service request. I need to be clear on= the terminology. If we were to define VN creation as the process of negot= iation (similar to SLA negotiation), the initial VN creation is always off-= line (static and non-real time). Once the initial VN creation negotiation i= s done, then there might be cases where VN can be re-negotiated on the fly = (e.g., changing some b/w or service objectives, or some physical failures s= uch as fiber cut). But this is not VN creation; we need to distinguish this= from VN re-negotiation. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. [[DC]] Yes. To understand where is the best place to do that. Cline control= ? VNC? YOUNG>> As there are many clients that the VNC needs to support, I assume V= NC has to have admission control module at the least. Client Controller, ho= wever, may have its own admission control for supporting multiple applicati= ons. We need to recognize a recursive client-server relationship. As long a= s controller is a server controller of any sort, then admission control fun= ction would help to coordinate its clients. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. [[DC]] True. With path constraints I think we should include something more= . When a client needs to setup a service/LSP there might be TE constraints = associated to the request. Whan the VN needs to include is not only reachab= ility information but in many cases is should be TE-reachability informatio= n. In this case we could leverage on the overlay work being done e.g. in CC= AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-= exchange-02). YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN = scope, then the TE-reacheability needs to be known/advertised by the serve= r network to clients as 'capability' attribute. --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniele,=

Thanks for your feedba= ck and comments. Please see inline for my reply.

Thanks.

Young

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Friday, December 20, 2013 4:30 AM
To: Leeyoung; actn@ietf.org
Cc: sdn@irtf.org
Subject: RE: [Actn] virtual network mapping/embedding (VNM/VNE) prob= lem

Hi Young,

Thanks for the pointer= s and the list of issues.

Please find in line so= me loud thinking from my side.

BR
Daniele

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: marted=EC 17 dicembre 2013 17:34
To: actn@ietf.org
Cc: sdn@irtf.org
Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem<= o:p>

Related to the ACTN work, there has been active rese= arch termed “virtual network mapping/embedding (VNM/VNE)”:=

Here’s some pointer to key papers:<= /p>

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with= path split and path migration)

http://nsm1.cs.uwaterloo.ca/rboutaba/Pa= pers/Conferences/2010/Muntasir10.pdf (survivable VNE)

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber= =3D5616527 (Resource Efficient VNE)

The focus of ACTN perhaps does not have a direct bea= ring with these papers as they are concerned about the VNM/VNE algorithms; = however, these bring some key issues and constraints for virtual network pa= th computation. These issues and constraints should be of interest of the ACTN work that may impact on the design, info= rmation models and interface/protocol extensions (if necessary). Some= of the issues such as efficiency of algorithm are perhaps better fit to SD= N RG, some of key issues and constraints for virtual network path computation related to VNM/VNE are as follows:

=

<= ![if !supportLists]>-   Request Processing

This is concerned about whether a set of client requ= ests for VN creation can be dealt with simultaneously or not. This depends = on the nature of applications the client support. If the client does not re= quire real-time instantiation of VN creation, the computation engine can process a set of VN creation requests= simultaneously to improve network efficiency.

[[DC]] I think h= ere we can assume that VN creation requests are non real time. Instantiatio= n of services and bandwidth might be real time (and hence concurrency needs= to be managed) but I would say this is not the case of VN creation.

YOUNG>> Good poi= nt. I was loose on the term ‘VN creation”. There ar= e certainly negotiation aspects of VN creation which can be viewed as non-r= eal time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I agree with you.= Here what I meant to say was when there are multiple service requests &nbs= p;to setup virtual connections that need not be instantiated real-time, (in= other words, if some request can be queued for a delay scheduling), then a batch processing of multiple reques= ts would be more optimal in general from a network efficiency perspective t= han sequential processing.

<= a name=3D"_Toc374709104">-   Types of Network Resources

When client makes a VN creation request to the subst= rate network, what kind of network resources is consumed is of concern of b= oth the client and network providers. It depends on the application. For tr= ansport network virtualization, the network resource consumed by the client is primarily network bandwidth tha= t the paths would occupy on the physical link. However, there may be other = resource types such as CPU and memory that need to be considered for certai= n applications. These resource types are a part of the client’s VN request.

[[DC]] Here the = issue is thorny. The point is: a given resource is dedicated to a given VN = or shared among different ones? We should start considering network resourc= es partitioning issues…

YOUNG>> A = given resource is “virtually” dedicated to a particular client;= yet this does not mean a particular client occupies a particular port (say= ODU port 1 vs 2). As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however for 1:N k= ind of protection case, there is a level of sharing backup path resource fo= r multiple clients.

<= ![if !supportLists]>-   Accuracy of Network Resource Representation

As the underlying transport network in itself may co= nsists of layered structure, it is a challenge how to represent these under= lying physical network resources and topology into a form that can be relia= bly used by the computation engine that assigns the client requests into the physical network resource and to= pology.

[[DC]] Damnly tr= ue

<= ![if !supportLists]>-   Resource Efficiency

Related to the accuracy of network resource represen= tation is resource efficiency. As a set of independent client VN is created= and mapped onto physical network resources, the overall network resource u= tilization is of the primary concern of the infrastructure provider.

[[DC]] This issu= e is pretty much linked to the one above (types of network resources)<= /o:p>

YOUNG>> Yes.

<= ![if !supportLists]>-   Guarantee of Client Isolation

While network resource sharing across a set of clien= ts for efficient utilization is important aspect of network virtualization,= client isolation has to be guaranteed. Admissions of new client requests o= r any changes of other existing clients’ VNs must not affect any particular client in terms of resource guarantee, = security constraints, and other performance constraints.

[[DC]] Again lin= ked to issues above. If network resources are dedicated to each VN, this is= true, but if they (or part of them) are shared, the instantiation of a ser= vice from a given client would impact the VN seen by others. On the other side, aspects like security o performa= nces should not be impacted in any of the two cases.<= /b>

YOUNG>> Agree.&n= bsp; So I guess we need to be clear on resource partitioning and sharing is= sue clearly --- I think some application/client requires a hard dedicated r= esource while for some others it is fluid.

<= ![if !supportLists]>-   Computing Time

Depending on the nature of applications, how quickly= a VN is instantiated from the time of request is an important factor. For = dynamic applications that require instantaneous VN creation, the computatio= n model/algorithm should support this constraint.

[[DC]] I would s= ay that timing constraints need to be met for service provisioning (i.e. up= on client requests on a given VN) but I think VN instantiation could be als= o a non real time procedure. I might be wrong…are there use cases for real time and timing constrained VN= creation requrests?

YOUNG>> Again here what I meant was service request= . I need to be clear on the terminology. If we were to define VN crea= tion as the process of negotiation (similar to SLA negotiation), the initial VN= creation is always off-line (static and non-real time). Once the initial V= N creation negotiation is done, then there might be cases where VN can be r= e-negotiated on the fly (e.g., changing some b/w or service objectives, or some physical failures such as fiber cu= t). But this is not VN creation; we need to distinguish this from VN re-neg= otiation.

<= ![if !supportLists]>-   Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

[[DC]] Yes. To u= nderstand where is the best place to do that. Cline control? VNC?

YOUNG>> As there= are many clients that the VNC needs to support, I assume VNC has to have a= dmission control module at the least. Client Controller, however, may have = its own admission control for supporting multiple applications. We need to recognize a recursive client-server relationship.= As long as controller is a server controller of any sort, then admission c= ontrol function would help to coordinate its clients.

<= a name=3D"_Toc374709110">-   Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation. Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

[[DC]] True. Wit= h path constraints I think we should include something more. When a client = needs to setup a service/LSP there might be TE constraints associated to th= e request. Whan the VN needs to include is not only reachability information but in many cases is should be TE-rea= chability information. In this case we could leverage on the overlay work b= eing done e.g. in CCAMP and in (http://tools.iet= f.org/html/draft-farrel-interconnected-te-info-exchange-02).

YOUNG>> Yes, if = we include non-TE underlying transport as part of the ACTN scope, then &nbs= p;the TE-reacheability needs to be known/advertised by the server network t= o clients as ‘capability’ attribute.

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_-- From diego.caviglia@ericsson.com Mon Dec 23 00:02:02 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA91AD7C1 for ; Mon, 23 Dec 2013 00:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 QiLRIlXDQ3Tg for ; Mon, 23 Dec 2013 00:01:56 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 706151AD83F for ; Mon, 23 Dec 2013 00:01:55 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-d5-52b7edee3a16 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 07.1D.03802.EEDE7B25; Mon, 23 Dec 2013 09:01:50 +0100 (CET) Received: from ESESSMB103.ericsson.se ([169.254.3.125]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0347.000; Mon, 23 Dec 2013 09:01:48 +0100 From: Diego Caviglia To: Leeyoung , Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/bdeyrxcXYsoskm9e7JN2Y4fJJphautg Date: Mon, 23 Dec 2013 08:01:48 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvre67t9uDDJb2W1ps6bnAZjFtnqvF +QXPWRyYPVqOvGX1WLLkJ5PH5I2H2QKYo7hsUlJzMstSi/TtErgypvXtZy2YMI2pYnXXfKYG xqfvGLsYOTkkBEwkFvX/ZoWwxSQu3FvP1sXIxSEkcIhR4tPcaYwQzhJGiSPvr7ODVLEJGEns 6pjJAmKLCFRLrPpxDaybWUBR4sTzZ0ANHBzCAr4Sm3tcIEoCJP7+m84EYRtJNPVPAWtlEVCV WLZ5JdhIXqDyeVPOMUPsesoosezeRTaQBKdAmMSGhxfA5jMKyEpM2L2IEWKXuMStJ/OZIK4W kFiy5zwzhC0q8fLxP1aQGySA7lneLwdRni+xoOUz1C5BiZMzn7BMYBSdhWTSLCRls5CUQcR1 JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM7LmJmTnp5UabGIGRdnDLb9UdjHfOiRxilOZg URLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0Pt9nN3up+3cweuPbPKrdfh9KRy K25lyUtfnK2m2546kHxj+fdcvSXiv3gkd3VwPGL20tx4jUlezLO9+4bNZK4NjZtCP09auJ19 q0PMu22N0zcdOOspoXygZMGpuZm3NoX+Xf+Pb5uk+Pvafd/EuTiPudgcWBxj8dVM/JXG3R3y H2tT0uSqbiuxFGckGmoxFxUnAgA4aS9/ggIAAA== Cc: "sdn@irtf.org" Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 08:02:03 -0000 --_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all some more thought with some cleaning BR and Season greetings! D - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. [[DC]] I think here we can assume that VN creation requests are non real ti= me. Instantiation of services and bandwidth might be real time (and hence c= oncurrency needs to be managed) but I would say this is not the case of VN = creation. YOUNG>> Good point. I was loose on the term 'VN creation". There are cert= ainly negotiation aspects of VN creation which can be viewed as non-real ti= me as the client endpoints need to be negotiated with network provider(s) b= efore service creation. Yes, in that sense, I agree with you. Here what I m= eant to say was when there are multiple service requests to setup virtual = connections that need not be instantiated real-time, (in other words, if so= me request can be queued for a delay scheduling), then a batch processing o= f multiple requests would be more optimal in general from a network efficie= ncy perspective than sequential processing. [DC] yes and this is one of the biggest advantage of a centralized approach= versus a distributed one, that is the possibility to compute the optimal s= olution of a bunch of requests - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. [[DC]] Here the issue is thorny. The point is: a given resource is dedicate= d to a given VN or shared among different ones? We should start considering= network resources partitioning issues... YOUNG>> A given resource is "virtually" dedicated to a particular client; = yet this does not mean a particular client occupies a particular port (say = ODU port 1 vs 2). As long as resource is guaranteed for use to the client,= it is fine for the Working Path at least; however for 1:N kind of protecti= on case, there is a level of sharing backup path resource for multiple clie= nts. [DC] well at least tributary port can't be virtual I need to nail it to a p= hysical numbering to physically connect the HW, for the rest I agree. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. [[DC]] Damnly true [DC] I vote for a KISS approach :) - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. [[DC]] This issue is pretty much linked to the one above (types of network = resources) YOUNG>> Yes. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. [[DC]] Again linked to issues above. If network resources are dedicated to = each VN, this is true, but if they (or part of them) are shared, the instan= tiation of a service from a given client would impact the VN seen by others= . On the other side, aspects like security o performances should not be imp= acted in any of the two cases. YOUNG>> Agree. So I guess we need to be clear on resource partitioning and= sharing issue clearly --- I think some application/client requires a hard = dedicated resource while for some others it is fluid. [DC] yes and this will give to the carriers the possibility to differentiat= e their service offering, do you want guaranteed bandwidth in case of multi= ple failures? Then you have to pay more. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. [[DC]] I would say that timing constraints need to be met for service provi= sioning (i.e. upon client requests on a given VN) but I think VN instantiat= ion could be also a non real time procedure. I might be wrong...are there u= se cases for real time and timing constrained VN creation requrests? YOUNG>> Again here what I meant was service request. I need to be clear on= the terminology. If we were to define VN creation as the process of negot= iation (similar to SLA negotiation), the initial VN creation is always off-= line (static and non-real time). Once the initial VN creation negotiation i= s done, then there might be cases where VN can be re-negotiated on the fly = (e.g., changing some b/w or service objectives, or some physical failures s= uch as fiber cut). But this is not VN creation; we need to distinguish this= from VN re-negotiation. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. [[DC]] Yes. To understand where is the best place to do that. Cline control= ? VNC? YOUNG>> As there are many clients that the VNC needs to support, I assume V= NC has to have admission control module at the least. Client Controller, ho= wever, may have its own admission control for supporting multiple applicati= ons. We need to recognize a recursive client-server relationship. As long a= s controller is a server controller of any sort, then admission control fun= ction would help to coordinate its clients. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. [[DC]] True. With path constraints I think we should include something more= . When a client needs to setup a service/LSP there might be TE constraints = associated to the request. Whan the VN needs to include is not only reachab= ility information but in many cases is should be TE-reachability informatio= n. In this case we could leverage on the overlay work being done e.g. in CC= AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-= exchange-02). YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN = scope, then the TE-reacheability needs to be known/advertised by the serve= r network to clients as 'capability' attribute. --_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all some more thoug= ht with some cleaning

BR and Season greeting= s!

D

=

-   Request Processing

This is concerned about whether a set of client requ= ests for VN creation can be dealt with simultaneously or not. This depends = on the nature of applications the client support. If the client does not re= quire real-time instantiation of VN creation, the computation engine can process a set of VN creation requests= simultaneously to improve network efficiency.

[[DC]] I think h= ere we can assume that VN creation requests are non real time. Instantiatio= n of services and bandwidth might be real time (and hence concurrency needs= to be managed) but I would say this is not the case of VN creation.

YOUNG>> Good poi= nt. I was loose on the term ‘VN creation”. There ar= e certainly negotiation aspects of VN creation which can be viewed as non-r= eal time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I agree with you.= Here what I meant to say was when there are multiple service requests &nbs= p;to setup virtual connections that need not be instantiated real-time, (in= other words, if some request can be queued for a delay scheduling), then a batch processing of multiple reques= ts would be more optimal in general from a network efficiency perspective t= han sequential processing.

[DC] yes and thi= s is one of the biggest advantage of a centralized approach versus a distri= buted one, that is the possibility to compute the optimal solution of a bun= ch of requests

-   Types of Network Resources

When client makes a VN creation request to the subst= rate network, what kind of network resources is consumed is of concern of b= oth the client and network providers. It depends on the application. For tr= ansport network virtualization, the network resource consumed by the client is primarily network bandwidth tha= t the paths would occupy on the physical link. However, there may be other = resource types such as CPU and memory that need to be considered for certai= n applications. These resource types are a part of the client’s VN request.

[[DC]] Here the = issue is thorny. The point is: a given resource is dedicated to a given VN = or shared among different ones? We should start considering network resourc= es partitioning issues…

YOUNG>> A = given resource is “virtually” dedicated to a particular client;= yet this does not mean a particular client occupies a particular port (say= ODU port 1 vs 2). As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however for 1:N k= ind of protection case, there is a level of sharing backup path resource fo= r multiple clients.

[DC] well at lea= st tributary port can’t be virtual I need to nail it to a physical nu= mbering to physically connect the HW, for the rest I agree.

-   Accuracy of Network Resource Representation

As the underlying transport network in itself may co= nsists of layered structure, it is a challenge how to represent these under= lying physical network resources and topology into a form that can be relia= bly used by the computation engine that assigns the client requests into the physical network resource and to= pology.

[[DC]] Damnly tr= ue

[DC] I vote for = a KISS approach J<= /span>

-   Resource Efficiency

Related to the accuracy of network resource represen= tation is resource efficiency. As a set of independent client VN is created= and mapped onto physical network resources, the overall network resource u= tilization is of the primary concern of the infrastructure provider.

[[DC]] This issu= e is pretty much linked to the one above (types of network resources)<= /o:p>

YOUNG>> Yes.

-   Guarantee of Client Isolation

While network resource sharing across a set of clien= ts for efficient utilization is important aspect of network virtualization,= client isolation has to be guaranteed. Admissions of new client requests o= r any changes of other existing clients’ VNs must not affect any particular client in terms of resource guarantee, = security constraints, and other performance constraints.

[[DC]] Again lin= ked to issues above. If network resources are dedicated to each VN, this is= true, but if they (or part of them) are shared, the instantiation of a ser= vice from a given client would impact the VN seen by others. On the other side, aspects like security o performa= nces should not be impacted in any of the two cases.<= /b>

YOUNG>> Agree.&n= bsp; So I guess we need to be clear on resource partitioning and sharing is= sue clearly --- I think some application/client requires a hard dedicated r= esource while for some others it is fluid.

[DC] yes and thi= s will give to the carriers the possibility to differentiate their service = offering, do you want guaranteed bandwidth in case of multiple failures? Th= en you have to pay more.<= /o:p>

-   Computing Time

Depending on the nature of applications, how quickly= a VN is instantiated from the time of request is an important factor. For = dynamic applications that require instantaneous VN creation, the computatio= n model/algorithm should support this constraint.

[[DC]] I would s= ay that timing constraints need to be met for service provisioning (i.e. up= on client requests on a given VN) but I think VN instantiation could be als= o a non real time procedure. I might be wrong…are there use cases for real time and timing constrained VN= creation requrests?

YOUNG>> Again here what I meant was service request= . I need to be clear on the terminology. If we were to define VN crea= tion as the process of negotiation (similar to SLA negotiation), the initial VN= creation is always off-line (static and non-real time). Once the initial V= N creation negotiation is done, then there might be cases where VN can be r= e-negotiated on the fly (e.g., changing some b/w or service objectives, or some physical failures such as fiber cu= t). But this is not VN creation; we need to distinguish this from VN re-neg= otiation.

-   Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

[[DC]] Yes. To u= nderstand where is the best place to do that. Cline control? VNC?

YOUNG>> As there= are many clients that the VNC needs to support, I assume VNC has to have a= dmission control module at the least. Client Controller, however, may have = its own admission control for supporting multiple applications. We need to recognize a recursive client-server relationship.= As long as controller is a server controller of any sort, then admission c= ontrol function would help to coordinate its clients.

-   Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation. Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

[[DC]] True. Wit= h path constraints I think we should include something more. When a client = needs to setup a service/LSP there might be TE constraints associated to th= e request. Whan the VN needs to include is not only reachability information but in many cases is should be TE-rea= chability information. In this case we could leverage on the overlay work b= eing done e.g. in CCAMP and in (http://tools.iet= f.org/html/draft-farrel-interconnected-te-info-exchange-02).

YOUNG>> Yes, if = we include non-TE underlying transport as part of the ACTN scope, then &nbs= p;the TE-reacheability needs to be known/advertised by the server network t= o clients as ‘capability’ attribute.

--_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_-- From zhangfatai@huawei.com Mon Dec 23 01:15:08 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF8C1AC82A for ; Mon, 23 Dec 2013 01:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham 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 oiqMAqqtfeiH for ; Mon, 23 Dec 2013 01:15:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7D0C1A1F78 for ; Mon, 23 Dec 2013 01:15:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBS22461; Mon, 23 Dec 2013 09:14:55 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 09:14:07 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 09:14:52 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.231]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 17:14:42 +0800 From: Fatai Zhang To: Diego Caviglia , Leeyoung , Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/7VORIr9tYTDQkCiAjaniNYAJZphfwIA Date: Mon, 23 Dec 2013 09:14:41 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sdn@irtf.org" Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 09:15:08 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Open my eyes to look for Diego, but see another [DC], :) Merry Charismas: My major comment, :) Best Regards Fatai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Diego Caviglia Sent: Monday, December 23, 2013 4:02 PM To: Leeyoung; Daniele Ceccarelli; actn@ietf.org Cc: sdn@irtf.org Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) probl= em Hi all some more thought with some cleaning BR and Season greetings! D - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. [[DC]] I think here we can assume that VN creation requests are non real ti= me. Instantiation of services and bandwidth might be real time (and hence c= oncurrency needs to be managed) but I would say this is not the case of VN = creation. YOUNG>> Good point. I was loose on the term 'VN creation". There are cert= ainly negotiation aspects of VN creation which can be viewed as non-real ti= me as the client endpoints need to be negotiated with network provider(s) b= efore service creation. Yes, in that sense, I agree with you. Here what I m= eant to say was when there are multiple service requests to setup virtual = connections that need not be instantiated real-time, (in other words, if so= me request can be queued for a delay scheduling), then a batch processing o= f multiple requests would be more optimal in general from a network efficie= ncy perspective than sequential processing. [DC] yes and this is one of the biggest advantage of a centralized approach= versus a distributed one, that is the possibility to compute the optimal s= olution of a bunch of requests - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. [[DC]] Here the issue is thorny. The point is: a given resource is dedicate= d to a given VN or shared among different ones? We should start considering= network resources partitioning issues... YOUNG>> A given resource is "virtually" dedicated to a particular client; = yet this does not mean a particular client occupies a particular port (say = ODU port 1 vs 2). As long as resource is guaranteed for use to the client,= it is fine for the Working Path at least; however for 1:N kind of protecti= on case, there is a level of sharing backup path resource for multiple clie= nts. [DC] well at least tributary port can't be virtual I need to nail it to a p= hysical numbering to physically connect the HW, for the rest I agree. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. [[DC]] Damnly true [DC] I vote for a KISS approach :) - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. [[DC]] This issue is pretty much linked to the one above (types of network = resources) YOUNG>> Yes. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. [[DC]] Again linked to issues above. If network resources are dedicated to = each VN, this is true, but if they (or part of them) are shared, the instan= tiation of a service from a given client would impact the VN seen by others= . On the other side, aspects like security o performances should not be imp= acted in any of the two cases. YOUNG>> Agree. So I guess we need to be clear on resource partitioning and= sharing issue clearly --- I think some application/client requires a hard = dedicated resource while for some others it is fluid. [DC] yes and this will give to the carriers the possibility to differentiat= e their service offering, do you want guaranteed bandwidth in case of multi= ple failures? Then you have to pay more. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. [[DC]] I would say that timing constraints need to be met for service provi= sioning (i.e. upon client requests on a given VN) but I think VN instantiat= ion could be also a non real time procedure. I might be wrong...are there u= se cases for real time and timing constrained VN creation requrests? YOUNG>> Again here what I meant was service request. I need to be clear on= the terminology. If we were to define VN creation as the process of negot= iation (similar to SLA negotiation), the initial VN creation is always off-= line (static and non-real time). Once the initial VN creation negotiation i= s done, then there might be cases where VN can be re-negotiated on the fly = (e.g., changing some b/w or service objectives, or some physical failures s= uch as fiber cut). But this is not VN creation; we need to distinguish this= from VN re-negotiation. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. [[DC]] Yes. To understand where is the best place to do that. Cline control= ? VNC? YOUNG>> As there are many clients that the VNC needs to support, I assume V= NC has to have admission control module at the least. Client Controller, ho= wever, may have its own admission control for supporting multiple applicati= ons. We need to recognize a recursive client-server relationship. As long a= s controller is a server controller of any sort, then admission control fun= ction would help to coordinate its clients. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. [[DC]] True. With path constraints I think we should include something more= . When a client needs to setup a service/LSP there might be TE constraints = associated to the request. Whan the VN needs to include is not only reachab= ility information but in many cases is should be TE-reachability informatio= n. In this case we could leverage on the overlay work being done e.g. in CC= AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-= exchange-02). YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN = scope, then the TE-reacheability needs to be known/advertised by the serve= r network to clients as 'capability' attribute. --_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Open my eyes to look for Diego, but see another [DC], J

Merry Charismas: My major comment, J

&n= bsp;

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Diego Caviglia
Sent: Monday, December 23, 2013 4:02 PM
To: Leeyoung; Daniele Ceccarelli; actn@ietf.org
Cc: sdn@irtf.org
Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE= ) problem

Hi all = some more thought with some cleaning

&n= bsp;

BR and = Season greetings!

&n= bsp;

D<= /o:p>

&n= bsp;

&n= bsp;

-   Request Processing=

This is concerned about whether= a set of client requests for VN creation can be dealt with simultaneously = or not. This depends on the nature of applications the client support. If t= he client does not require real-time instantiation of VN creation, the computation engine can process a set of = VN creation requests simultaneously to improve network efficiency.

[= [DC]] I think here we can assume that VN creation requests are non real tim= e. Instantiation of services and bandwidth might be real time (and hence co= ncurrency needs to be managed) but I would say this is not the case of VN creation.

&n= bsp;

YOUNG&g= t;> Good point. I was loose on the term ‘VN creation”.= There are certainly negotiation aspects of VN creation which can be = viewed as non-real time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I ag= ree with you. Here what I meant to say was when there are multiple service = requests to setup virtual connections that need not be instantiated r= eal-time, (in other words, if some request can be queued for a delay scheduling), then a batch processing of multiple= requests would be more optimal in general from a network efficiency perspe= ctive than sequential processing.

[= DC] yes and this is one of the biggest advantage of a centralized approach = versus a distributed one, that is the possibility to compute the optimal so= lution of a bunch of requests

&n= bsp;

&n= bsp;

-   Types of Network Resour= ces

When client makes a VN creation= request to the substrate network, what kind of network resources is consum= ed is of concern of both the client and network providers. It depends on th= e application. For transport network virtualization, the network resource consumed by the client is primarily n= etwork bandwidth that the paths would occupy on the physical link. However,= there may be other resource types such as CPU and memory that need to be c= onsidered for certain applications. These resource types are a part of the client’s VN request.

[= [DC]] Here the issue is thorny. The point is: a given resource is dedicated= to a given VN or shared among different ones? We should start considering = network resources partitioning issues…

&n= bsp;

YOUNG&g= t;> A given resource is “virtually” dedicated to a par= ticular client; yet this does not mean a particular client occupies a parti= cular port (say ODU port 1 vs 2). As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however f= or 1:N kind of protection case, there is a level of sharing backup path res= ource for multiple clients.

[= DC] well at least tributary port can’t be virtual I need to nail it t= o a physical numbering to physically connect the HW, for the rest I agree.&= nbsp;

-   Accuracy of Network Res= ource Representation

As the underlying transport net= work in itself may consists of layered structure, it is a challenge how to = represent these underlying physical network resources and topology into a f= orm that can be reliably used by the computation engine that assigns the client requests into the physical netw= ork resource and topology.

[= [DC]] Damnly true

[= DC] I vote for a KISS approach J<= o:p>

-   Resource Efficiency

Related to the accuracy of netw= ork resource representation is resource efficiency. As a set of independent= client VN is created and mapped onto physical network resources, the overa= ll network resource utilization is of the primary concern of the infrastructure provider.

[= [DC]] This issue is pretty much linked to the one above (types of network r= esources)

&n= bsp;

YOUNG&g= t;> Yes.

-   Guarantee of Client Iso= lation

While network resource sharing = across a set of clients for efficient utilization is important aspect of ne= twork virtualization, client isolation has to be guaranteed. Admissions of = new client requests or any changes of other existing clients’ VNs must not affect any particular client in= terms of resource guarantee, security constraints, and other performance c= onstraints.

[= [DC]] Again linked to issues above. If network resources are dedicated to e= ach VN, this is true, but if they (or part of them) are shared, the instant= iation of a service from a given client would impact the VN seen by others. On the other side, aspects like securi= ty o performances should not be impacted in any of the two cases.

&n= bsp;

YOUNG&g= t;> Agree. So I guess we need to be clear on resource partitioning= and sharing issue clearly --- I think some application/client requires a h= ard dedicated resource while for some others it is fluid.

[= DC] yes and this will give to the carriers the possibility to differentiate= their service offering, do you want guaranteed bandwidth in case of multip= le failures? Then you have to pay more.

-   Computing Time

Depending on the nature of appl= ications, how quickly a VN is instantiated from the time of request is an i= mportant factor. For dynamic applications that require instantaneous VN cre= ation, the computation model/algorithm should support this constraint.

[= [DC]] I would say that timing constraints need to be met for service provis= ioning (i.e. upon client requests on a given VN) but I think VN instantiati= on could be also a non real time procedure. I might be wrong…are there use cases for real time and timing constr= ained VN creation requrests?

YOUNG>> Again here what I meant was = service request. I need to be clear on the terminology. If we were to define VN creation as the process of negotiation (similar to SLA negotiati= on), the initial VN creation is always off-line (static and non-real time).= Once the initial VN creation negotiation is done, then there might be case= s where VN can be re-negotiated on the fly (e.g., changing some b/w or service objectives, or some physica= l failures such as fiber cut). But this is not VN creation; we need to dist= inguish this from VN re-negotiation.

-   Admission Control<= /o:p>

To coordinate the request proce= ss of multiple clients, an admission control will help maximize an overall = efficiency.

[= [DC]] Yes. To understand where is the best place to do that. Cline control?= VNC?

&n= bsp;

YOUNG&g= t;> As there are many clients that the VNC needs to support, I assume VN= C has to have admission control module at the least. Client Controller, how= ever, may have its own admission control for supporting multiple applications. We need to recognize a recursive client-= server relationship. As long as controller is a server controller of any so= rt, then admission control function would help to coordinate its clients.

-   Path Constraints=

There may be some factors of pa= th constraints that can affect the overall efficiency. Path Split can lower= VN request blocking if the underlying network can support such capability.= Packet-based TE network can support path split while circuit-based transport may have a limitation. Path= migration is a technique that allows changes of nodes or links assignment = of the established paths in an effort to accommodate new requests which wou= ld not be accepted without path migration. This can improve overall efficiency, yet additional care needs to be appli= ed to avoid any adverse impacts associated with changing the existing paths= .

Re-optimization is a global pro= cess to re-shuffle all existing path assignment to minimize network resourc= e fragmentation. Again, an extra care needs to be applied for re-optimizati= on.

[= [DC]] True. With path constraints I think we should include something more.= When a client needs to setup a service/LSP there might be TE constraints a= ssociated to the request. Whan the VN needs to include is not only reachability information but in many cases is= should be TE-reachability information. In this case we could leverage on t= he overlay work being done e.g. in CCAMP and in (http://tools.ietf.org/html/draft-farrel-interconnect= ed-te-info-exchange-02).

YOUNG&g= t;> Yes, if we include non-TE underlying transport as part of the ACTN s= cope, then the TE-reacheability needs to be known/advertised by the s= erver network to clients as ‘capability’ attribute.

--_000_F82A4B6D50F9464B8EBA55651F541CF85CAA93B1SZXEMA504MBSchi_-- From zhang.xian@huawei.com Tue Dec 31 01:02:02 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AD81AE145 for ; Tue, 31 Dec 2013 01:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham 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 vtGso3V6Wkn2 for ; Tue, 31 Dec 2013 01:01:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D1F811AD6D1 for ; Tue, 31 Dec 2013 01:01:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZM99019; Tue, 31 Dec 2013 09:01:48 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 09:01:38 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 09:01:46 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.167]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 31 Dec 2013 17:01:38 +0800 From: "Zhangxian (Xian)" To: Diego Caviglia , Leeyoung , Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/7VO+OStUqH2F06tUPCRN9xKhppuCJqQ Date: Tue, 31 Dec 2013 09:01:37 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sdn@irtf.org" Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 09:02:02 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQogICBTb21lIGZ1cnRoZXIgdGhvdWdodHMgb24gc29tZSBvZiB0aGUgaXNzdWVz Lg0KDQogICBCVFcsIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkIHRvIHNlZSB0aGUgc3RhdHVzIHF1 byBvZiBWTkUgcmVzZWFyY2gsIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUgYSBnb29kIHN0YXJ0aW5n IHBvaW50Og0KDQpodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1LmRlL2ZpbGVhZG1pbi9maWxlcy9s ZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2NoZXIyMDEzYS5wZGYNCg0KSGFwcHkg bmV3IHllYXIsDQoNClhpYW4NCg0KRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5v cmddIE9uIEJlaGFsZiBPZiBEaWVnbyBDYXZpZ2xpYQ0KU2VudDogMjAxM8TqMTLUwjIzyNUgMTY6 MDINClRvOiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBhY3RuQGlldGYub3JnDQpDYzog c2RuQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW1Nkbl0gW0FjdG5dIHZpcnR1YWwgbmV0d29yayBt YXBwaW5nL2VtYmVkZGluZyAoVk5NL1ZORSkgcHJvYmxlbQ0KDQpIaSBhbGwgc29tZSBtb3JlIHRo b3VnaHQgd2l0aCBzb21lIGNsZWFuaW5nDQoNCkJSIGFuZCBTZWFzb24gZ3JlZXRpbmdzIQ0KDQpE DQoNCg0KDQotICAgUmVxdWVzdCBQcm9jZXNzaW5nDQpUaGlzIGlzIGNvbmNlcm5lZCBhYm91dCB3 aGV0aGVyIGEgc2V0IG9mIGNsaWVudCByZXF1ZXN0cyBmb3IgVk4gY3JlYXRpb24gY2FuIGJlIGRl YWx0IHdpdGggc2ltdWx0YW5lb3VzbHkgb3Igbm90LiBUaGlzIGRlcGVuZHMgb24gdGhlIG5hdHVy ZSBvZiBhcHBsaWNhdGlvbnMgdGhlIGNsaWVudCBzdXBwb3J0LiBJZiB0aGUgY2xpZW50IGRvZXMg bm90IHJlcXVpcmUgcmVhbC10aW1lIGluc3RhbnRpYXRpb24gb2YgVk4gY3JlYXRpb24sIHRoZSBj b21wdXRhdGlvbiBlbmdpbmUgY2FuIHByb2Nlc3MgYSBzZXQgb2YgVk4gY3JlYXRpb24gcmVxdWVz dHMgc2ltdWx0YW5lb3VzbHkgdG8gaW1wcm92ZSBuZXR3b3JrIGVmZmljaWVuY3kuDQpbW0RDXV0g SSB0aGluayBoZXJlIHdlIGNhbiBhc3N1bWUgdGhhdCBWTiBjcmVhdGlvbiByZXF1ZXN0cyBhcmUg bm9uIHJlYWwgdGltZS4gSW5zdGFudGlhdGlvbiBvZiBzZXJ2aWNlcyBhbmQgYmFuZHdpZHRoIG1p Z2h0IGJlIHJlYWwgdGltZSAoYW5kIGhlbmNlIGNvbmN1cnJlbmN5IG5lZWRzIHRvIGJlIG1hbmFn ZWQpIGJ1dCBJIHdvdWxkIHNheSB0aGlzIGlzIG5vdCB0aGUgY2FzZSBvZiBWTiBjcmVhdGlvbi4N Cg0KWU9VTkc+PiBHb29kIHBvaW50LiAgSSB3YXMgbG9vc2Ugb24gdGhlIHRlcm0goa5WTiBjcmVh dGlvbqGxLiAgVGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3RzIG9mIFZOIGNy ZWF0aW9uIHdoaWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0aGUgY2xpZW50 IGVuZHBvaW50cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQgd2l0aCBuZXR3b3JrIHByb3ZpZGVyKHMp IGJlZm9yZSBzZXJ2aWNlIGNyZWF0aW9uLiBZZXMsIGluIHRoYXQgc2Vuc2UsIEkgYWdyZWUgd2l0 aCB5b3UuIEhlcmUgd2hhdCBJIG1lYW50IHRvIHNheSB3YXMgd2hlbiB0aGVyZSBhcmUgbXVsdGlw bGUgc2VydmljZSByZXF1ZXN0cyAgdG8gc2V0dXAgdmlydHVhbCBjb25uZWN0aW9ucyB0aGF0IG5l ZWQgbm90IGJlIGluc3RhbnRpYXRlZCByZWFsLXRpbWUsIChpbiBvdGhlciB3b3JkcywgaWYgc29t ZSByZXF1ZXN0IGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2NoZWR1bGluZyksIHRoZW4gYSBi YXRjaCBwcm9jZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdvdWxkIGJlIG1vcmUgb3B0aW1h bCBpbiBnZW5lcmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kgcGVyc3BlY3RpdmUgdGhhbiBz ZXF1ZW50aWFsIHByb2Nlc3NpbmcuDQpbRENdIHllcyBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlIGJp Z2dlc3QgYWR2YW50YWdlIG9mIGEgY2VudHJhbGl6ZWQgYXBwcm9hY2ggdmVyc3VzIGEgZGlzdHJp YnV0ZWQgb25lLCB0aGF0IGlzIHRoZSBwb3NzaWJpbGl0eSB0byBjb21wdXRlIHRoZSBvcHRpbWFs IHNvbHV0aW9uIG9mIGEgYnVuY2ggb2YgcmVxdWVzdHMNCg0KW1hpYW5dIEkgdGhpbmsgd2UgaGF2 ZSBhIHByZXR0eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSBhbmQgYXMgSSB1bmRlcnN0YW5k LCB0aGUgcG9pbnRzIHJlbGF0ZWQgdG8gQUNUTiB3b3VsZCBpbmNsdWRlIGF0IGxlYXN0ICgxKSB3 aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIHBhc3NlZCBmcm9tIGNsaWVudCB0byB2aXJ0dWFs IG5ldHdvcmsgcHJvdmlkZXI/OyAoMikgd2hhdCBjb25zdHJhaW50cyAgdGhlIGNsaWVudCBjYW4g YWNjZXB0ICh0aW1lIG1pZ2h0IGJlIGEgY29uc3RyYWludHMpLiAgSWYgdGhlcmUgaXMgbW9yZSwg cGxlYXNlIGFtZW5kLg0KDQotICAgVHlwZXMgb2YgTmV0d29yayBSZXNvdXJjZXMNCldoZW4gY2xp ZW50IG1ha2VzIGEgVk4gY3JlYXRpb24gcmVxdWVzdCB0byB0aGUgc3Vic3RyYXRlIG5ldHdvcmss IHdoYXQga2luZCBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBjb25zdW1lZCBpcyBvZiBjb25jZXJu IG9mIGJvdGggdGhlIGNsaWVudCBhbmQgbmV0d29yayBwcm92aWRlcnMuIEl0IGRlcGVuZHMgb24g dGhlIGFwcGxpY2F0aW9uLiBGb3IgdHJhbnNwb3J0IG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIHRo ZSBuZXR3b3JrIHJlc291cmNlIGNvbnN1bWVkIGJ5IHRoZSBjbGllbnQgaXMgcHJpbWFyaWx5IG5l dHdvcmsgYmFuZHdpZHRoIHRoYXQgdGhlIHBhdGhzIHdvdWxkIG9jY3VweSBvbiB0aGUgcGh5c2lj YWwgbGluay4gSG93ZXZlciwgdGhlcmUgbWF5IGJlIG90aGVyIHJlc291cmNlIHR5cGVzIHN1Y2gg YXMgQ1BVIGFuZCBtZW1vcnkgdGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgZm9yIGNlcnRhaW4g YXBwbGljYXRpb25zLiBUaGVzZSByZXNvdXJjZSB0eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGll bnShr3MgVk4gcmVxdWVzdC4NCltbRENdXSBIZXJlIHRoZSBpc3N1ZSBpcyB0aG9ybnkuIFRoZSBw b2ludCBpczogYSBnaXZlbiByZXNvdXJjZSBpcyBkZWRpY2F0ZWQgdG8gYSBnaXZlbiBWTiBvciBz aGFyZWQgYW1vbmcgZGlmZmVyZW50IG9uZXM/IFdlIHNob3VsZCBzdGFydCBjb25zaWRlcmluZyBu ZXR3b3JrIHJlc291cmNlcyBwYXJ0aXRpb25pbmcgaXNzdWVzoa0NCg0KWU9VTkc+PiAgQSBnaXZl biByZXNvdXJjZSBpcyChsHZpcnR1YWxseaGxIGRlZGljYXRlZCB0byBhIHBhcnRpY3VsYXIgY2xp ZW50OyB5ZXQgdGhpcyBkb2VzIG5vdCBtZWFuIGEgcGFydGljdWxhciBjbGllbnQgb2NjdXBpZXMg YSBwYXJ0aWN1bGFyIHBvcnQgKHNheSBPRFUgcG9ydCAxIHZzIDIpLiAgQXMgbG9uZyBhcyByZXNv dXJjZSBpcyBndWFyYW50ZWVkIGZvciB1c2UgdG8gdGhlIGNsaWVudCwgaXQgaXMgZmluZSBmb3Ig dGhlIFdvcmtpbmcgUGF0aCBhdCBsZWFzdDsgaG93ZXZlciBmb3IgMTpOIGtpbmQgb2YgcHJvdGVj dGlvbiBjYXNlLCB0aGVyZSBpcyBhIGxldmVsIG9mIHNoYXJpbmcgYmFja3VwIHBhdGggcmVzb3Vy Y2UgZm9yIG11bHRpcGxlIGNsaWVudHMuDQpbRENdIHdlbGwgYXQgbGVhc3QgdHJpYnV0YXJ5IHBv cnQgY2Fuoa90IGJlIHZpcnR1YWwgSSBuZWVkIHRvIG5haWwgaXQgdG8gYSBwaHlzaWNhbCBudW1i ZXJpbmcgdG8gcGh5c2ljYWxseSBjb25uZWN0IHRoZSBIVywgZm9yIHRoZSByZXN0IEkgYWdyZWUu DQoNCltYaWFuXSBJIHRoaW5rIFlvdW5nIG1lYW50IHRoZSBwaHlzaWNhbCByZXNvdXJjZSBjYW4g YmUgc2hhcmVkIGJ5IG11bHRpcGxlIGNsaWVudHMsIHByb2JhYmx5IGJ5IGFzc2lnbmluZyB0aGUg c2FtZSBwaHlzaWNhbCBudW1iZXJpbmcgdG8gdGhlIGRpZmZlcmVudCBjbGllbnRzLiBUaGUgcG9p bnQgdGhhdCB3b3J0aCBub3RpbmcgaXMgdGhhdCB3aGV0aGVyIHRoaXMga2luZCBvZiBzaGFyaW5n IGNhbiBtYWtlIHN1cmUgbm8gY29uZmxpY3Qgd291bGQgYXJpc2Ugb3IgaWYgc28sIHdoZXRoZXIg aXQgaXMgYWNjZXB0YWJsZS4NCg0KLSAgIEFjY3VyYWN5IG9mIE5ldHdvcmsgUmVzb3VyY2UgUmVw cmVzZW50YXRpb24NCkFzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBuZXR3b3JrIGluIGl0c2Vs ZiBtYXkgY29uc2lzdHMgb2YgbGF5ZXJlZCBzdHJ1Y3R1cmUsIGl0IGlzIGEgY2hhbGxlbmdlIGhv dyB0byByZXByZXNlbnQgdGhlc2UgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNl cyBhbmQgdG9wb2xvZ3kgaW50byBhIGZvcm0gdGhhdCBjYW4gYmUgcmVsaWFibHkgdXNlZCBieSB0 aGUgY29tcHV0YXRpb24gZW5naW5lIHRoYXQgYXNzaWducyB0aGUgY2xpZW50IHJlcXVlc3RzIGlu dG8gdGhlIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2UgYW5kIHRvcG9sb2d5Lg0KW1tEQ11dIERh bW5seSB0cnVlDQpbRENdIEkgdm90ZSBmb3IgYSBLSVNTIGFwcHJvYWNoIDopDQpbWGlhbl1DYW5u b3QgYWdyZWUgd2l0aCBEaWVnbyBtb3JlLCA6RC4NCg0KLSAgIFJlc291cmNlIEVmZmljaWVuY3kN ClJlbGF0ZWQgdG8gdGhlIGFjY3VyYWN5IG9mIG5ldHdvcmsgcmVzb3VyY2UgcmVwcmVzZW50YXRp b24gaXMgcmVzb3VyY2UgZWZmaWNpZW5jeS4gQXMgYSBzZXQgb2YgaW5kZXBlbmRlbnQgY2xpZW50 IFZOIGlzIGNyZWF0ZWQgYW5kIG1hcHBlZCBvbnRvIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2Vz LCB0aGUgb3ZlcmFsbCBuZXR3b3JrIHJlc291cmNlIHV0aWxpemF0aW9uIGlzIG9mIHRoZSBwcmlt YXJ5IGNvbmNlcm4gb2YgdGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLg0KW1tEQ11dIFRoaXMg aXNzdWUgaXMgcHJldHR5IG11Y2ggbGlua2VkIHRvIHRoZSBvbmUgYWJvdmUgKHR5cGVzIG9mIG5l dHdvcmsgcmVzb3VyY2VzKQ0KDQpZT1VORz4+IFllcy4NCltYaWFuXSBUaGlzIHByb2JhYmx5IGlz IG1vcmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFkIG9mIEFDVE4sIGJ1dCBmb3Igc3Vy ZSBhbiBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KLSAgIEd1 YXJhbnRlZSBvZiBDbGllbnQgSXNvbGF0aW9uDQpXaGlsZSBuZXR3b3JrIHJlc291cmNlIHNoYXJp bmcgYWNyb3NzIGEgc2V0IG9mIGNsaWVudHMgZm9yIGVmZmljaWVudCB1dGlsaXphdGlvbiBpcyBp bXBvcnRhbnQgYXNwZWN0IG9mIG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIGNsaWVudCBpc29sYXRp b24gaGFzIHRvIGJlIGd1YXJhbnRlZWQuIEFkbWlzc2lvbnMgb2YgbmV3IGNsaWVudCByZXF1ZXN0 cyBvciBhbnkgY2hhbmdlcyBvZiBvdGhlciBleGlzdGluZyBjbGllbnRzoa8gVk5zIG11c3Qgbm90 IGFmZmVjdCBhbnkgcGFydGljdWxhciBjbGllbnQgaW4gdGVybXMgb2YgcmVzb3VyY2UgZ3VhcmFu dGVlLCBzZWN1cml0eSBjb25zdHJhaW50cywgYW5kIG90aGVyIHBlcmZvcm1hbmNlIGNvbnN0cmFp bnRzLg0KW1tEQ11dIEFnYWluIGxpbmtlZCB0byBpc3N1ZXMgYWJvdmUuIElmIG5ldHdvcmsgcmVz b3VyY2VzIGFyZSBkZWRpY2F0ZWQgdG8gZWFjaCBWTiwgdGhpcyBpcyB0cnVlLCBidXQgaWYgdGhl eSAob3IgcGFydCBvZiB0aGVtKSBhcmUgc2hhcmVkLCB0aGUgaW5zdGFudGlhdGlvbiBvZiBhIHNl cnZpY2UgZnJvbSBhIGdpdmVuIGNsaWVudCB3b3VsZCBpbXBhY3QgdGhlIFZOIHNlZW4gYnkgb3Ro ZXJzLiBPbiB0aGUgb3RoZXIgc2lkZSwgYXNwZWN0cyBsaWtlIHNlY3VyaXR5IG8gcGVyZm9ybWFu Y2VzIHNob3VsZCBub3QgYmUgaW1wYWN0ZWQgaW4gYW55IG9mIHRoZSB0d28gY2FzZXMuDQoNCllP VU5HPj4gQWdyZWUuICBTbyBJIGd1ZXNzIHdlIG5lZWQgdG8gYmUgY2xlYXIgb24gcmVzb3VyY2Ug cGFydGl0aW9uaW5nIGFuZCBzaGFyaW5nIGlzc3VlIGNsZWFybHkgLS0tIEkgdGhpbmsgc29tZSBh cHBsaWNhdGlvbi9jbGllbnQgcmVxdWlyZXMgYSBoYXJkIGRlZGljYXRlZCByZXNvdXJjZSB3aGls ZSBmb3Igc29tZSBvdGhlcnMgaXQgaXMgZmx1aWQuDQpbRENdIHllcyBhbmQgdGhpcyB3aWxsIGdp dmUgdG8gdGhlIGNhcnJpZXJzIHRoZSBwb3NzaWJpbGl0eSB0byBkaWZmZXJlbnRpYXRlIHRoZWly IHNlcnZpY2Ugb2ZmZXJpbmcsIGRvIHlvdSB3YW50IGd1YXJhbnRlZWQgYmFuZHdpZHRoIGluIGNh c2Ugb2YgbXVsdGlwbGUgZmFpbHVyZXM/IFRoZW4geW91IGhhdmUgdG8gcGF5IG1vcmUuDQoNCi0g ICBDb21wdXRpbmcgVGltZQ0KRGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgYXBwbGljYXRpb25z LCBob3cgcXVpY2tseSBhIFZOIGlzIGluc3RhbnRpYXRlZCBmcm9tIHRoZSB0aW1lIG9mIHJlcXVl c3QgaXMgYW4gaW1wb3J0YW50IGZhY3Rvci4gRm9yIGR5bmFtaWMgYXBwbGljYXRpb25zIHRoYXQg cmVxdWlyZSBpbnN0YW50YW5lb3VzIFZOIGNyZWF0aW9uLCB0aGUgY29tcHV0YXRpb24gbW9kZWwv YWxnb3JpdGhtIHNob3VsZCBzdXBwb3J0IHRoaXMgY29uc3RyYWludC4NCltbRENdXSBJIHdvdWxk IHNheSB0aGF0IHRpbWluZyBjb25zdHJhaW50cyBuZWVkIHRvIGJlIG1ldCBmb3Igc2VydmljZSBw cm92aXNpb25pbmcgKGkuZS4gdXBvbiBjbGllbnQgcmVxdWVzdHMgb24gYSBnaXZlbiBWTikgYnV0 IEkgdGhpbmsgVk4gaW5zdGFudGlhdGlvbiBjb3VsZCBiZSBhbHNvIGEgbm9uIHJlYWwgdGltZSBw cm9jZWR1cmUuIEkgbWlnaHQgYmUgd3JvbmehrWFyZSB0aGVyZSB1c2UgY2FzZXMgZm9yIHJlYWwg dGltZSBhbmQgdGltaW5nIGNvbnN0cmFpbmVkIFZOIGNyZWF0aW9uIHJlcXVyZXN0cz8NCg0KWU9V Tkc+PiAgQWdhaW4gaGVyZSB3aGF0IEkgbWVhbnQgd2FzIHNlcnZpY2UgcmVxdWVzdC4gSSBuZWVk IHRvIGJlIGNsZWFyIG9uIHRoZSB0ZXJtaW5vbG9neS4gIElmIHdlIHdlcmUgdG8gZGVmaW5lIFZO IGNyZWF0aW9uIGFzIHRoZSBwcm9jZXNzIG9mIG5lZ290aWF0aW9uIChzaW1pbGFyIHRvIFNMQSBu ZWdvdGlhdGlvbiksIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIGlzIGFsd2F5cyBvZmYtbGluZSAo c3RhdGljIGFuZCBub24tcmVhbCB0aW1lKS4gT25jZSB0aGUgaW5pdGlhbCBWTiBjcmVhdGlvbiBu ZWdvdGlhdGlvbiBpcyBkb25lLCB0aGVuIHRoZXJlIG1pZ2h0IGJlIGNhc2VzIHdoZXJlIFZOIGNh biBiZSByZS1uZWdvdGlhdGVkIG9uIHRoZSBmbHkgKGUuZy4sIGNoYW5naW5nIHNvbWUgYi93IG9y IHNlcnZpY2Ugb2JqZWN0aXZlcywgb3Igc29tZSBwaHlzaWNhbCBmYWlsdXJlcyBzdWNoIGFzIGZp YmVyIGN1dCkuIEJ1dCB0aGlzIGlzIG5vdCBWTiBjcmVhdGlvbjsgd2UgbmVlZCB0byBkaXN0aW5n dWlzaCB0aGlzIGZyb20gVk4gcmUtbmVnb3RpYXRpb24uDQotICAgQWRtaXNzaW9uIENvbnRyb2wN ClRvIGNvb3JkaW5hdGUgdGhlIHJlcXVlc3QgcHJvY2VzcyBvZiBtdWx0aXBsZSBjbGllbnRzLCBh biBhZG1pc3Npb24gY29udHJvbCB3aWxsIGhlbHAgbWF4aW1pemUgYW4gb3ZlcmFsbCBlZmZpY2ll bmN5Lg0KW1tEQ11dIFllcy4gVG8gdW5kZXJzdGFuZCB3aGVyZSBpcyB0aGUgYmVzdCBwbGFjZSB0 byBkbyB0aGF0LiBDbGluZSBjb250cm9sPyBWTkM/DQoNCllPVU5HPj4gQXMgdGhlcmUgYXJlIG1h bnkgY2xpZW50cyB0aGF0IHRoZSBWTkMgbmVlZHMgdG8gc3VwcG9ydCwgSSBhc3N1bWUgVk5DIGhh cyB0byBoYXZlIGFkbWlzc2lvbiBjb250cm9sIG1vZHVsZSBhdCB0aGUgbGVhc3QuIENsaWVudCBD b250cm9sbGVyLCBob3dldmVyLCBtYXkgaGF2ZSBpdHMgb3duIGFkbWlzc2lvbiBjb250cm9sIGZv ciBzdXBwb3J0aW5nIG11bHRpcGxlIGFwcGxpY2F0aW9ucy4gV2UgbmVlZCB0byByZWNvZ25pemUg YSByZWN1cnNpdmUgY2xpZW50LXNlcnZlciByZWxhdGlvbnNoaXAuIEFzIGxvbmcgYXMgY29udHJv bGxlciBpcyBhIHNlcnZlciBjb250cm9sbGVyIG9mIGFueSBzb3J0LCB0aGVuIGFkbWlzc2lvbiBj b250cm9sIGZ1bmN0aW9uIHdvdWxkIGhlbHAgdG8gY29vcmRpbmF0ZSBpdHMgY2xpZW50cy4NCg0K LSAgIFBhdGggQ29uc3RyYWludHMNClRoZXJlIG1heSBiZSBzb21lIGZhY3RvcnMgb2YgcGF0aCBj b25zdHJhaW50cyB0aGF0IGNhbiBhZmZlY3QgdGhlIG92ZXJhbGwgZWZmaWNpZW5jeS4gUGF0aCBT cGxpdCBjYW4gbG93ZXIgVk4gcmVxdWVzdCBibG9ja2luZyBpZiB0aGUgdW5kZXJseWluZyBuZXR3 b3JrIGNhbiBzdXBwb3J0IHN1Y2ggY2FwYWJpbGl0eS4gUGFja2V0LWJhc2VkIFRFIG5ldHdvcmsg Y2FuIHN1cHBvcnQgcGF0aCBzcGxpdCB3aGlsZSBjaXJjdWl0LWJhc2VkIHRyYW5zcG9ydCBtYXkg aGF2ZSBhIGxpbWl0YXRpb24uICBQYXRoIG1pZ3JhdGlvbiBpcyBhIHRlY2huaXF1ZSB0aGF0IGFs bG93cyBjaGFuZ2VzIG9mIG5vZGVzIG9yIGxpbmtzIGFzc2lnbm1lbnQgb2YgdGhlIGVzdGFibGlz aGVkIHBhdGhzIGluIGFuIGVmZm9ydCB0byBhY2NvbW1vZGF0ZSBuZXcgcmVxdWVzdHMgd2hpY2gg d291bGQgbm90IGJlIGFjY2VwdGVkIHdpdGhvdXQgcGF0aCBtaWdyYXRpb24uIFRoaXMgY2FuIGlt cHJvdmUgb3ZlcmFsbCBlZmZpY2llbmN5LCB5ZXQgYWRkaXRpb25hbCBjYXJlIG5lZWRzIHRvIGJl IGFwcGxpZWQgdG8gYXZvaWQgYW55IGFkdmVyc2UgaW1wYWN0cyBhc3NvY2lhdGVkIHdpdGggY2hh bmdpbmcgdGhlIGV4aXN0aW5nIHBhdGhzLg0KUmUtb3B0aW1pemF0aW9uIGlzIGEgZ2xvYmFsIHBy b2Nlc3MgdG8gcmUtc2h1ZmZsZSBhbGwgZXhpc3RpbmcgcGF0aCBhc3NpZ25tZW50IHRvIG1pbmlt aXplIG5ldHdvcmsgcmVzb3VyY2UgZnJhZ21lbnRhdGlvbi4gQWdhaW4sIGFuIGV4dHJhIGNhcmUg bmVlZHMgdG8gYmUgYXBwbGllZCBmb3IgcmUtb3B0aW1pemF0aW9uLg0KW1tEQ11dIFRydWUuIFdp dGggcGF0aCBjb25zdHJhaW50cyBJIHRoaW5rIHdlIHNob3VsZCBpbmNsdWRlIHNvbWV0aGluZyBt b3JlLiBXaGVuIGEgY2xpZW50IG5lZWRzIHRvIHNldHVwIGEgc2VydmljZS9MU1AgdGhlcmUgbWln aHQgYmUgVEUgY29uc3RyYWludHMgYXNzb2NpYXRlZCB0byB0aGUgcmVxdWVzdC4gV2hhbiB0aGUg Vk4gbmVlZHMgdG8gaW5jbHVkZSBpcyBub3Qgb25seSByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24g YnV0IGluIG1hbnkgY2FzZXMgaXMgc2hvdWxkIGJlIFRFLXJlYWNoYWJpbGl0eSBpbmZvcm1hdGlv bi4gSW4gdGhpcyBjYXNlIHdlIGNvdWxkIGxldmVyYWdlIG9uIHRoZSBvdmVybGF5IHdvcmsgYmVp bmcgZG9uZSBlLmcuIGluIENDQU1QIGFuZCBpbiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmFycmVsLWludGVyY29ubmVjdGVkLXRlLWluZm8tZXhjaGFuZ2UtMDIpLg0KDQpZT1VO Rz4+IFllcywgaWYgd2UgaW5jbHVkZSBub24tVEUgdW5kZXJseWluZyB0cmFuc3BvcnQgYXMgcGFy dCBvZiB0aGUgQUNUTiBzY29wZSwgdGhlbiAgdGhlIFRFLXJlYWNoZWFiaWxpdHkgbmVlZHMgdG8g YmUga25vd24vYWR2ZXJ0aXNlZCBieSB0aGUgc2VydmVyIG5ldHdvcmsgdG8gY2xpZW50cyBhcyCh rmNhcGFiaWxpdHmhryBhdHRyaWJ1dGUuDQpbWGlhbl0gSGF2ZSB3ZSBhbHJlYWR5IGNvbmZpbmVk IHRoZSBzY29wZSB0byBURSB0cmFuc3BvcnQgbmV0d29yayBvbmx5Pw0KDQpJIHRoaW5rIHdoZXRo ZXIgdGhlIFRFIGluZm9ybWF0aW9uIGlzIGNvbnZleWVkIHRvIHRoZSBjbGllbnQgZGVwZW5kcyBv biB0aGUgZGV0YWlscyB0aGUgY2xpZW50IHdhbnRzIHRvIGtub3cuIEZyb20gQUNUTiB3b3JrIHBv aW50IG9mIHZpZXcsIGl0IHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIHBhcnQgb2YgdGhlIGNvbnN0 cmFpbnRzIHdvcnRoIGNvbnNpZGVyaW5nLg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

   Some further thoughts on some of the issues.

BTW, if anyone is interested to see the status quo o= f VNE research, the following might be a good starting point:

http://www.fim.uni-passau.de/filea= dmin/files/lehrstuhl/meer/publications/pdf/Fischer2013a.pdf<= /span>

Happy new year,

Xian

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Diego Caviglia
Sent: 2013=C4=EA12=D4=C223=C8= =D5 16:02
To: Leeyoung; Daniele Ceccarelli; actn@ietf.org
Cc: sdn@irtf.org
Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE= ) problem

Hi all = some more thought with some cleaning

&n= bsp;

BR and = Season greetings!

&n= bsp;

D<= /o:p>

&n= bsp;

&n= bsp;

-   Request Processing=

This is concerned about whether= a set of client requests for VN creation can be dealt with simultaneously = or not. This depends on the nature of applications the client support. If t= he client does not require real-time instantiation of VN creation, the computation engine can process a set of = VN creation requests simultaneously to improve network efficiency.

[= [DC]] I think here we can assume that VN creation requests are non real tim= e. Instantiation of services and bandwidth might be real time (and hence co= ncurrency needs to be managed) but I would say this is not the case of VN creation.

&n= bsp;

YOUNG&g= t;> Good point. I was loose on the term =A1=AEVN creation=A1=B1.&n= bsp; There are certainly negotiation aspects of VN creation which can be vi= ewed as non-real time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I ag= ree with you. Here what I meant to say was when there are multiple service = requests to setup virtual connections that need not be instantiated r= eal-time, (in other words, if some request can be queued for a delay scheduling), then a batch processing of multiple= requests would be more optimal in general from a network efficiency perspe= ctive than sequential processing.

[= DC] yes and this is one of the biggest advantage of a centralized approach = versus a distributed one, that is the possibility to compute the optimal so= lution of a bunch of requests

[Xian] I think we have a pretty understanding of the issue and as I = understand, the points related to ACTN would include at least (1) what info= rmation needs to be passed from client to virtual network provider?; (2) what constraints the client can ac= cept (time might be a constraints). If there is more, please amend.

&n= bsp;

-   Types of Network Resour= ces

When client makes a VN creation= request to the substrate network, what kind of network resources is consum= ed is of concern of both the client and network providers. It depends on th= e application. For transport network virtualization, the network resource consumed by the client is primarily n= etwork bandwidth that the paths would occupy on the physical link. However,= there may be other resource types such as CPU and memory that need to be c= onsidered for certain applications. These resource types are a part of the client=A1=AFs VN request.

[= [DC]] Here the issue is thorny. The point is: a given resource is dedicated= to a given VN or shared among different ones? We should start considering = network resources partitioning issues=A1=AD

&n= bsp;

YOUNG&g= t;> A given resource is =A1=B0virtually=A1=B1 dedicated to a parti= cular client; yet this does not mean a particular client occupies a particu= lar port (say ODU port 1 vs 2). As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however f= or 1:N kind of protection case, there is a level of sharing backup path res= ource for multiple clients.

[= DC] well at least tributary port can=A1=AFt be virtual I need to nail it to= a physical numbering to physically connect the HW, for the rest I agree.&n= bsp;

[Xian] I think Young meant the physical resource can be shared by mu= ltiple clients, probably by assigning the same physical numbering to the di= fferent clients. The point that worth noting is that whether this kind of sharing can make sure no conflict woul= d arise or if so, whether it is acceptable.

-   Accuracy of Network Res= ource Representation

As the underlying transport net= work in itself may consists of layered structure, it is a challenge how to = represent these underlying physical network resources and topology into a f= orm that can be reliably used by the computation engine that assigns the client requests into the physical netw= ork resource and topology.

[= [DC]] Damnly true

[= DC] I vote for a KISS approach J

[Xian]Cannot agree with Diego more, :D.

-   Resource Efficiency

Related to the accuracy of netw= ork resource representation is resource efficiency. As a set of independent= client VN is created and mapped onto physical network resources, the overa= ll network resource utilization is of the primary concern of the infrastructure provider.

[= [DC]] This issue is pretty much linked to the one above (types of network r= esources)

&n= bsp;

YOUNG&g= t;> Yes.

[Xian] This probably is more VNE algorithm related, instead of ACTN,= but for sure an important aspect for the overall solution.

-   Guarantee of Client Iso= lation

While network resource sharing = across a set of clients for efficient utilization is important aspect of ne= twork virtualization, client isolation has to be guaranteed. Admissions of = new client requests or any changes of other existing clients=A1=AF VNs must not affect any particular client in = terms of resource guarantee, security constraints, and other performance co= nstraints.

[= [DC]] Again linked to issues above. If network resources are dedicated to e= ach VN, this is true, but if they (or part of them) are shared, the instant= iation of a service from a given client would impact the VN seen by others. On the other side, aspects like securi= ty o performances should not be impacted in any of the two cases.

&n= bsp;

YOUNG&g= t;> Agree. So I guess we need to be clear on resource partitioning= and sharing issue clearly --- I think some application/client requires a h= ard dedicated resource while for some others it is fluid.

[= DC] yes and this will give to the carriers the possibility to differentiate= their service offering, do you want guaranteed bandwidth in case of multip= le failures? Then you have to pay more.

-   Computing Time

Depending on the nature of appl= ications, how quickly a VN is instantiated from the time of request is an i= mportant factor. For dynamic applications that require instantaneous VN cre= ation, the computation model/algorithm should support this constraint.

[= [DC]] I would say that timing constraints need to be met for service provis= ioning (i.e. upon client requests on a given VN) but I think VN instantiati= on could be also a non real time procedure. I might be wrong=A1=ADare there use cases for real time and timing constra= ined VN creation requrests?

YOUNG>> Again here what I meant was = service request. I need to be clear on the terminology. If we were to define VN creation as the process of negotiation (similar to SLA negotiati= on), the initial VN creation is always off-line (static and non-real time).= Once the initial VN creation negotiation is done, then there might be case= s where VN can be re-negotiated on the fly (e.g., changing some b/w or service objectives, or some physica= l failures such as fiber cut). But this is not VN creation; we need to dist= inguish this from VN re-negotiation.

-   Admission Control<= /o:p>

To coordinate the request proce= ss of multiple clients, an admission control will help maximize an overall = efficiency.

[= [DC]] Yes. To understand where is the best place to do that. Cline control?= VNC?

&n= bsp;

YOUNG&g= t;> As there are many clients that the VNC needs to support, I assume VN= C has to have admission control module at the least. Client Controller, how= ever, may have its own admission control for supporting multiple applications. We need to recognize a recursive client-= server relationship. As long as controller is a server controller of any so= rt, then admission control function would help to coordinate its clients.

-   Path Constraints=

There may be some factors of pa= th constraints that can affect the overall efficiency. Path Split can lower= VN request blocking if the underlying network can support such capability.= Packet-based TE network can support path split while circuit-based transport may have a limitation. Path= migration is a technique that allows changes of nodes or links assignment = of the established paths in an effort to accommodate new requests which wou= ld not be accepted without path migration. This can improve overall efficiency, yet additional care needs to be appli= ed to avoid any adverse impacts associated with changing the existing paths= .

Re-optimization is a global pro= cess to re-shuffle all existing path assignment to minimize network resourc= e fragmentation. Again, an extra care needs to be applied for re-optimizati= on.

[= [DC]] True. With path constraints I think we should include something more.= When a client needs to setup a service/LSP there might be TE constraints a= ssociated to the request. Whan the VN needs to include is not only reachability information but in many cases is= should be TE-reachability information. In this case we could leverage on t= he overlay work being done e.g. in CCAMP and in (http://tools.ietf.org/html/draft-farrel-interconnect= ed-te-info-exchange-02).

YOUNG&g= t;> Yes, if we include non-TE underlying transport as part of the ACTN s= cope, then the TE-reacheability needs to be known/advertised by the s= erver network to clients as =A1=AEcapability=A1=AF attribute.

[Xian] Have we already confined the scope to TE transport network on= ly?

I think whether the TE information is conveyed to the client depends= on the details the client wants to know. From ACTN work point of view, it = should be considered as part of the constraints worth considering.

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_-- From matta@bu.edu Tue Dec 31 08:06:13 2013 Return-Path: X-Original-To: actn@ietfa.amsl.com Delivered-To: actn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC551AE1D5; Tue, 31 Dec 2013 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 afLjP2QMzw6v; Tue, 31 Dec 2013 08:06:09 -0800 (PST) Received: from relay67.bu.edu (relay67.bu.edu [128.197.228.67]) by ietfa.amsl.com (Postfix) with ESMTP id BAD451AE01F; Tue, 31 Dec 2013 08:06:07 -0800 (PST) X-Envelope-From: matta@bu.edu X-BU-AUTH: ist-ex10hub-2.bu.edu [10.231.8.45] Received: from BU-AUTH (localhost.localdomain [127.0.0.1]) by relay67.bu.edu (8.14.3/8.13.8) with ESMTP id rBVG3hlh024140; Tue, 31 Dec 2013 11:03:43 -0500 Received: from IST-EX10MBX-1.ad.bu.edu ([fe80::d9cd:e5be:f6e3:104a]) by IST-EX10HUB-2.ad.bu.edu ([fe80::28b2:ee45:cbfd:5915%12]) with mapi id 14.02.0342.003; Tue, 31 Dec 2013 11:03:43 -0500 From: "Matta, Abraham I" To: "Zhangxian (Xian)" , Diego Caviglia , Leeyoung , "Daniele Ceccarelli" , "actn@ietf.org" Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/befd9ha2IsnEUaqfiiqSR+BPJphwtcAgAyjXYCAACIRAA== Date: Tue, 31 Dec 2013 16:03:42 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.231.8.171] Content-Type: multipart/alternative; boundary="_000_CEE853F7430D5mattabuedu_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 31 Dec 2013 08:20:26 -0800 Cc: Flavio Esposito , "sdn@irtf.org" Subject: Re: [Actn] [Sdn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: actn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Abstraction and Control of Transport Networks $ACTN$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 16:06:14 -0000 --_000_CEE853F7430D5mattabuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5vdGhlciBzdXJ2ZXk6DQoNCmh0dHA6Ly93d3cuY3MuYnUuZWR1L3RlY2hyZXBvcnRzL3BkZi8y MDExLTAyNS1zbGljZS1lbWJlZGRpbmcucGRmDQoNCg0KRi4gRXNwb3NpdG8sIEkuIE1hdHRhLCBh bmQgVi4gSXNoYWtpYW4uIFNsaWNlIEVtYmVkZGluZyBTb2x1dGlvbnMgZm9yDQoNCkRpc3RyaWJ1 dGVkIFNlcnZpY2UgQXJjaGl0ZWN0dXJlcy4gQUNNIENvbXB1dGluZyBTdXJ2ZXlzLCBBY2NlcHRl ZA0KDQpOb3ZlbWJlciAyMDEyICh0byBhcHBlYXIgaW4gVm9sdW1lIDQ2LCBJc3N1ZSAxLCBNYXJj aCAyMDE0KS4NCg0KQmVzdCwNCmlicmFoaW0NCg0KRnJvbTogIlpoYW5neGlhbiAoWGlhbikiIDx6 aGFuZy54aWFuQGh1YXdlaS5jb208bWFpbHRvOnpoYW5nLnhpYW5AaHVhd2VpLmNvbT4+DQpEYXRl OiBUdWVzZGF5LCBEZWNlbWJlciAzMSwgMjAxMyA0OjAxIEFNDQpUbzogRGllZ28gQ2F2aWdsaWEg PGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTxtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nz b24uY29tPj4sIExlZXlvdW5nIDxsZWV5b3VuZ0BodWF3ZWkuY29tPG1haWx0bzpsZWV5b3VuZ0Bo dWF3ZWkuY29tPj4sIERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbTxtYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT4+LCAiYWN0bkBp ZXRmLm9yZzxtYWlsdG86YWN0bkBpZXRmLm9yZz4iIDxhY3RuQGlldGYub3JnPG1haWx0bzphY3Ru QGlldGYub3JnPj4NCkNjOiAic2RuQGlydGYub3JnPG1haWx0bzpzZG5AaXJ0Zi5vcmc+IiA8c2Ru QGlydGYub3JnPG1haWx0bzpzZG5AaXJ0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtTZG5dIFtBY3Ru XSB2aXJ0dWFsIG5ldHdvcmsgbWFwcGluZy9lbWJlZGRpbmcgKFZOTS9WTkUpIHByb2JsZW0NCg0K SGkgYWxsLA0KDQogICBTb21lIGZ1cnRoZXIgdGhvdWdodHMgb24gc29tZSBvZiB0aGUgaXNzdWVz Lg0KDQogICBCVFcsIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkIHRvIHNlZSB0aGUgc3RhdHVzIHF1 byBvZiBWTkUgcmVzZWFyY2gsIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUgYSBnb29kIHN0YXJ0aW5n IHBvaW50Og0KDQpodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1LmRlL2ZpbGVhZG1pbi9maWxlcy9s ZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2NoZXIyMDEzYS5wZGYNCg0KSGFwcHkg bmV3IHllYXIsDQoNClhpYW4NCg0KRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5v cmddIE9uIEJlaGFsZiBPZiBEaWVnbyBDYXZpZ2xpYQ0KU2VudDogMjAxM+W5tDEy5pyIMjPml6Ug MTY6MDINClRvOiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBhY3RuQGlldGYub3JnPG1h aWx0bzphY3RuQGlldGYub3JnPg0KQ2M6IHNkbkBpcnRmLm9yZzxtYWlsdG86c2RuQGlydGYub3Jn Pg0KU3ViamVjdDogUmU6IFtTZG5dIFtBY3RuXSB2aXJ0dWFsIG5ldHdvcmsgbWFwcGluZy9lbWJl ZGRpbmcgKFZOTS9WTkUpIHByb2JsZW0NCg0KSGkgYWxsIHNvbWUgbW9yZSB0aG91Z2h0IHdpdGgg c29tZSBjbGVhbmluZw0KDQpCUiBhbmQgU2Vhc29uIGdyZWV0aW5ncyENCg0KRA0KDQoNCg0KLSAg IFJlcXVlc3QgUHJvY2Vzc2luZw0KVGhpcyBpcyBjb25jZXJuZWQgYWJvdXQgd2hldGhlciBhIHNl dCBvZiBjbGllbnQgcmVxdWVzdHMgZm9yIFZOIGNyZWF0aW9uIGNhbiBiZSBkZWFsdCB3aXRoIHNp bXVsdGFuZW91c2x5IG9yIG5vdC4gVGhpcyBkZXBlbmRzIG9uIHRoZSBuYXR1cmUgb2YgYXBwbGlj YXRpb25zIHRoZSBjbGllbnQgc3VwcG9ydC4gSWYgdGhlIGNsaWVudCBkb2VzIG5vdCByZXF1aXJl IHJlYWwtdGltZSBpbnN0YW50aWF0aW9uIG9mIFZOIGNyZWF0aW9uLCB0aGUgY29tcHV0YXRpb24g ZW5naW5lIGNhbiBwcm9jZXNzIGEgc2V0IG9mIFZOIGNyZWF0aW9uIHJlcXVlc3RzIHNpbXVsdGFu ZW91c2x5IHRvIGltcHJvdmUgbmV0d29yayBlZmZpY2llbmN5Lg0KW1tEQ11dIEkgdGhpbmsgaGVy ZSB3ZSBjYW4gYXNzdW1lIHRoYXQgVk4gY3JlYXRpb24gcmVxdWVzdHMgYXJlIG5vbiByZWFsIHRp bWUuIEluc3RhbnRpYXRpb24gb2Ygc2VydmljZXMgYW5kIGJhbmR3aWR0aCBtaWdodCBiZSByZWFs IHRpbWUgKGFuZCBoZW5jZSBjb25jdXJyZW5jeSBuZWVkcyB0byBiZSBtYW5hZ2VkKSBidXQgSSB3 b3VsZCBzYXkgdGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgVk4gY3JlYXRpb24uDQoNCllPVU5HPj4g R29vZCBwb2ludC4gIEkgd2FzIGxvb3NlIG9uIHRoZSB0ZXJtIOKAmFZOIGNyZWF0aW9u4oCdLiAg VGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3RzIG9mIFZOIGNyZWF0aW9uIHdo aWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0aGUgY2xpZW50IGVuZHBvaW50 cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQgd2l0aCBuZXR3b3JrIHByb3ZpZGVyKHMpIGJlZm9yZSBz ZXJ2aWNlIGNyZWF0aW9uLiBZZXMsIGluIHRoYXQgc2Vuc2UsIEkgYWdyZWUgd2l0aCB5b3UuIEhl cmUgd2hhdCBJIG1lYW50IHRvIHNheSB3YXMgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgc2Vydmlj ZSByZXF1ZXN0cyAgdG8gc2V0dXAgdmlydHVhbCBjb25uZWN0aW9ucyB0aGF0IG5lZWQgbm90IGJl IGluc3RhbnRpYXRlZCByZWFsLXRpbWUsIChpbiBvdGhlciB3b3JkcywgaWYgc29tZSByZXF1ZXN0 IGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2NoZWR1bGluZyksIHRoZW4gYSBiYXRjaCBwcm9j ZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdvdWxkIGJlIG1vcmUgb3B0aW1hbCBpbiBnZW5l cmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kgcGVyc3BlY3RpdmUgdGhhbiBzZXF1ZW50aWFs IHByb2Nlc3NpbmcuDQpbRENdIHllcyBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlIGJpZ2dlc3QgYWR2 YW50YWdlIG9mIGEgY2VudHJhbGl6ZWQgYXBwcm9hY2ggdmVyc3VzIGEgZGlzdHJpYnV0ZWQgb25l LCB0aGF0IGlzIHRoZSBwb3NzaWJpbGl0eSB0byBjb21wdXRlIHRoZSBvcHRpbWFsIHNvbHV0aW9u IG9mIGEgYnVuY2ggb2YgcmVxdWVzdHMNCg0KW1hpYW5dIEkgdGhpbmsgd2UgaGF2ZSBhIHByZXR0 eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSBhbmQgYXMgSSB1bmRlcnN0YW5kLCB0aGUgcG9p bnRzIHJlbGF0ZWQgdG8gQUNUTiB3b3VsZCBpbmNsdWRlIGF0IGxlYXN0ICgxKSB3aGF0IGluZm9y bWF0aW9uIG5lZWRzIHRvIGJlIHBhc3NlZCBmcm9tIGNsaWVudCB0byB2aXJ0dWFsIG5ldHdvcmsg cHJvdmlkZXI/OyAoMikgd2hhdCBjb25zdHJhaW50cyAgdGhlIGNsaWVudCBjYW4gYWNjZXB0ICh0 aW1lIG1pZ2h0IGJlIGEgY29uc3RyYWludHMpLiAgSWYgdGhlcmUgaXMgbW9yZSwgcGxlYXNlIGFt ZW5kLg0KDQotICAgVHlwZXMgb2YgTmV0d29yayBSZXNvdXJjZXMNCldoZW4gY2xpZW50IG1ha2Vz IGEgVk4gY3JlYXRpb24gcmVxdWVzdCB0byB0aGUgc3Vic3RyYXRlIG5ldHdvcmssIHdoYXQga2lu ZCBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBjb25zdW1lZCBpcyBvZiBjb25jZXJuIG9mIGJvdGgg dGhlIGNsaWVudCBhbmQgbmV0d29yayBwcm92aWRlcnMuIEl0IGRlcGVuZHMgb24gdGhlIGFwcGxp Y2F0aW9uLiBGb3IgdHJhbnNwb3J0IG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIHRoZSBuZXR3b3Jr IHJlc291cmNlIGNvbnN1bWVkIGJ5IHRoZSBjbGllbnQgaXMgcHJpbWFyaWx5IG5ldHdvcmsgYmFu ZHdpZHRoIHRoYXQgdGhlIHBhdGhzIHdvdWxkIG9jY3VweSBvbiB0aGUgcGh5c2ljYWwgbGluay4g SG93ZXZlciwgdGhlcmUgbWF5IGJlIG90aGVyIHJlc291cmNlIHR5cGVzIHN1Y2ggYXMgQ1BVIGFu ZCBtZW1vcnkgdGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgZm9yIGNlcnRhaW4gYXBwbGljYXRp b25zLiBUaGVzZSByZXNvdXJjZSB0eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGllbnTigJlzIFZO IHJlcXVlc3QuDQpbW0RDXV0gSGVyZSB0aGUgaXNzdWUgaXMgdGhvcm55LiBUaGUgcG9pbnQgaXM6 IGEgZ2l2ZW4gcmVzb3VyY2UgaXMgZGVkaWNhdGVkIHRvIGEgZ2l2ZW4gVk4gb3Igc2hhcmVkIGFt b25nIGRpZmZlcmVudCBvbmVzPyBXZSBzaG91bGQgc3RhcnQgY29uc2lkZXJpbmcgbmV0d29yayBy ZXNvdXJjZXMgcGFydGl0aW9uaW5nIGlzc3Vlc+KApg0KDQpZT1VORz4+ICBBIGdpdmVuIHJlc291 cmNlIGlzIOKAnHZpcnR1YWxseeKAnSBkZWRpY2F0ZWQgdG8gYSBwYXJ0aWN1bGFyIGNsaWVudDsg eWV0IHRoaXMgZG9lcyBub3QgbWVhbiBhIHBhcnRpY3VsYXIgY2xpZW50IG9jY3VwaWVzIGEgcGFy dGljdWxhciBwb3J0IChzYXkgT0RVIHBvcnQgMSB2cyAyKS4gIEFzIGxvbmcgYXMgcmVzb3VyY2Ug aXMgZ3VhcmFudGVlZCBmb3IgdXNlIHRvIHRoZSBjbGllbnQsIGl0IGlzIGZpbmUgZm9yIHRoZSBX b3JraW5nIFBhdGggYXQgbGVhc3Q7IGhvd2V2ZXIgZm9yIDE6TiBraW5kIG9mIHByb3RlY3Rpb24g Y2FzZSwgdGhlcmUgaXMgYSBsZXZlbCBvZiBzaGFyaW5nIGJhY2t1cCBwYXRoIHJlc291cmNlIGZv ciBtdWx0aXBsZSBjbGllbnRzLg0KW0RDXSB3ZWxsIGF0IGxlYXN0IHRyaWJ1dGFyeSBwb3J0IGNh buKAmXQgYmUgdmlydHVhbCBJIG5lZWQgdG8gbmFpbCBpdCB0byBhIHBoeXNpY2FsIG51bWJlcmlu ZyB0byBwaHlzaWNhbGx5IGNvbm5lY3QgdGhlIEhXLCBmb3IgdGhlIHJlc3QgSSBhZ3JlZS4NCg0K W1hpYW5dIEkgdGhpbmsgWW91bmcgbWVhbnQgdGhlIHBoeXNpY2FsIHJlc291cmNlIGNhbiBiZSBz aGFyZWQgYnkgbXVsdGlwbGUgY2xpZW50cywgcHJvYmFibHkgYnkgYXNzaWduaW5nIHRoZSBzYW1l IHBoeXNpY2FsIG51bWJlcmluZyB0byB0aGUgZGlmZmVyZW50IGNsaWVudHMuIFRoZSBwb2ludCB0 aGF0IHdvcnRoIG5vdGluZyBpcyB0aGF0IHdoZXRoZXIgdGhpcyBraW5kIG9mIHNoYXJpbmcgY2Fu IG1ha2Ugc3VyZSBubyBjb25mbGljdCB3b3VsZCBhcmlzZSBvciBpZiBzbywgd2hldGhlciBpdCBp cyBhY2NlcHRhYmxlLg0KDQotICAgQWNjdXJhY3kgb2YgTmV0d29yayBSZXNvdXJjZSBSZXByZXNl bnRhdGlvbg0KQXMgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IG5ldHdvcmsgaW4gaXRzZWxmIG1h eSBjb25zaXN0cyBvZiBsYXllcmVkIHN0cnVjdHVyZSwgaXQgaXMgYSBjaGFsbGVuZ2UgaG93IHRv IHJlcHJlc2VudCB0aGVzZSB1bmRlcmx5aW5nIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2VzIGFu ZCB0b3BvbG9neSBpbnRvIGEgZm9ybSB0aGF0IGNhbiBiZSByZWxpYWJseSB1c2VkIGJ5IHRoZSBj b21wdXRhdGlvbiBlbmdpbmUgdGhhdCBhc3NpZ25zIHRoZSBjbGllbnQgcmVxdWVzdHMgaW50byB0 aGUgcGh5c2ljYWwgbmV0d29yayByZXNvdXJjZSBhbmQgdG9wb2xvZ3kuDQpbW0RDXV0gRGFtbmx5 IHRydWUNCltEQ10gSSB2b3RlIGZvciBhIEtJU1MgYXBwcm9hY2gg4pi6DQpbWGlhbl1DYW5ub3Qg YWdyZWUgd2l0aCBEaWVnbyBtb3JlLCA6RC4NCg0KLSAgIFJlc291cmNlIEVmZmljaWVuY3kNClJl bGF0ZWQgdG8gdGhlIGFjY3VyYWN5IG9mIG5ldHdvcmsgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24g aXMgcmVzb3VyY2UgZWZmaWNpZW5jeS4gQXMgYSBzZXQgb2YgaW5kZXBlbmRlbnQgY2xpZW50IFZO IGlzIGNyZWF0ZWQgYW5kIG1hcHBlZCBvbnRvIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2VzLCB0 aGUgb3ZlcmFsbCBuZXR3b3JrIHJlc291cmNlIHV0aWxpemF0aW9uIGlzIG9mIHRoZSBwcmltYXJ5 IGNvbmNlcm4gb2YgdGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLg0KW1tEQ11dIFRoaXMgaXNz dWUgaXMgcHJldHR5IG11Y2ggbGlua2VkIHRvIHRoZSBvbmUgYWJvdmUgKHR5cGVzIG9mIG5ldHdv cmsgcmVzb3VyY2VzKQ0KDQpZT1VORz4+IFllcy4NCltYaWFuXSBUaGlzIHByb2JhYmx5IGlzIG1v cmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFkIG9mIEFDVE4sIGJ1dCBmb3Igc3VyZSBh biBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KLSAgIEd1YXJh bnRlZSBvZiBDbGllbnQgSXNvbGF0aW9uDQpXaGlsZSBuZXR3b3JrIHJlc291cmNlIHNoYXJpbmcg YWNyb3NzIGEgc2V0IG9mIGNsaWVudHMgZm9yIGVmZmljaWVudCB1dGlsaXphdGlvbiBpcyBpbXBv cnRhbnQgYXNwZWN0IG9mIG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIGNsaWVudCBpc29sYXRpb24g aGFzIHRvIGJlIGd1YXJhbnRlZWQuIEFkbWlzc2lvbnMgb2YgbmV3IGNsaWVudCByZXF1ZXN0cyBv ciBhbnkgY2hhbmdlcyBvZiBvdGhlciBleGlzdGluZyBjbGllbnRz4oCZIFZOcyBtdXN0IG5vdCBh ZmZlY3QgYW55IHBhcnRpY3VsYXIgY2xpZW50IGluIHRlcm1zIG9mIHJlc291cmNlIGd1YXJhbnRl ZSwgc2VjdXJpdHkgY29uc3RyYWludHMsIGFuZCBvdGhlciBwZXJmb3JtYW5jZSBjb25zdHJhaW50 cy4NCltbRENdXSBBZ2FpbiBsaW5rZWQgdG8gaXNzdWVzIGFib3ZlLiBJZiBuZXR3b3JrIHJlc291 cmNlcyBhcmUgZGVkaWNhdGVkIHRvIGVhY2ggVk4sIHRoaXMgaXMgdHJ1ZSwgYnV0IGlmIHRoZXkg KG9yIHBhcnQgb2YgdGhlbSkgYXJlIHNoYXJlZCwgdGhlIGluc3RhbnRpYXRpb24gb2YgYSBzZXJ2 aWNlIGZyb20gYSBnaXZlbiBjbGllbnQgd291bGQgaW1wYWN0IHRoZSBWTiBzZWVuIGJ5IG90aGVy cy4gT24gdGhlIG90aGVyIHNpZGUsIGFzcGVjdHMgbGlrZSBzZWN1cml0eSBvIHBlcmZvcm1hbmNl cyBzaG91bGQgbm90IGJlIGltcGFjdGVkIGluIGFueSBvZiB0aGUgdHdvIGNhc2VzLg0KDQpZT1VO Rz4+IEFncmVlLiAgU28gSSBndWVzcyB3ZSBuZWVkIHRvIGJlIGNsZWFyIG9uIHJlc291cmNlIHBh cnRpdGlvbmluZyBhbmQgc2hhcmluZyBpc3N1ZSBjbGVhcmx5IC0tLSBJIHRoaW5rIHNvbWUgYXBw bGljYXRpb24vY2xpZW50IHJlcXVpcmVzIGEgaGFyZCBkZWRpY2F0ZWQgcmVzb3VyY2Ugd2hpbGUg Zm9yIHNvbWUgb3RoZXJzIGl0IGlzIGZsdWlkLg0KW0RDXSB5ZXMgYW5kIHRoaXMgd2lsbCBnaXZl IHRvIHRoZSBjYXJyaWVycyB0aGUgcG9zc2liaWxpdHkgdG8gZGlmZmVyZW50aWF0ZSB0aGVpciBz ZXJ2aWNlIG9mZmVyaW5nLCBkbyB5b3Ugd2FudCBndWFyYW50ZWVkIGJhbmR3aWR0aCBpbiBjYXNl IG9mIG11bHRpcGxlIGZhaWx1cmVzPyBUaGVuIHlvdSBoYXZlIHRvIHBheSBtb3JlLg0KDQotICAg Q29tcHV0aW5nIFRpbWUNCkRlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIGFwcGxpY2F0aW9ucywg aG93IHF1aWNrbHkgYSBWTiBpcyBpbnN0YW50aWF0ZWQgZnJvbSB0aGUgdGltZSBvZiByZXF1ZXN0 IGlzIGFuIGltcG9ydGFudCBmYWN0b3IuIEZvciBkeW5hbWljIGFwcGxpY2F0aW9ucyB0aGF0IHJl cXVpcmUgaW5zdGFudGFuZW91cyBWTiBjcmVhdGlvbiwgdGhlIGNvbXB1dGF0aW9uIG1vZGVsL2Fs Z29yaXRobSBzaG91bGQgc3VwcG9ydCB0aGlzIGNvbnN0cmFpbnQuDQpbW0RDXV0gSSB3b3VsZCBz YXkgdGhhdCB0aW1pbmcgY29uc3RyYWludHMgbmVlZCB0byBiZSBtZXQgZm9yIHNlcnZpY2UgcHJv dmlzaW9uaW5nIChpLmUuIHVwb24gY2xpZW50IHJlcXVlc3RzIG9uIGEgZ2l2ZW4gVk4pIGJ1dCBJ IHRoaW5rIFZOIGluc3RhbnRpYXRpb24gY291bGQgYmUgYWxzbyBhIG5vbiByZWFsIHRpbWUgcHJv Y2VkdXJlLiBJIG1pZ2h0IGJlIHdyb25n4oCmYXJlIHRoZXJlIHVzZSBjYXNlcyBmb3IgcmVhbCB0 aW1lIGFuZCB0aW1pbmcgY29uc3RyYWluZWQgVk4gY3JlYXRpb24gcmVxdXJlc3RzPw0KDQpZT1VO Rz4+ICBBZ2FpbiBoZXJlIHdoYXQgSSBtZWFudCB3YXMgc2VydmljZSByZXF1ZXN0LiBJIG5lZWQg dG8gYmUgY2xlYXIgb24gdGhlIHRlcm1pbm9sb2d5LiAgSWYgd2Ugd2VyZSB0byBkZWZpbmUgVk4g Y3JlYXRpb24gYXMgdGhlIHByb2Nlc3Mgb2YgbmVnb3RpYXRpb24gKHNpbWlsYXIgdG8gU0xBIG5l Z290aWF0aW9uKSwgdGhlIGluaXRpYWwgVk4gY3JlYXRpb24gaXMgYWx3YXlzIG9mZi1saW5lIChz dGF0aWMgYW5kIG5vbi1yZWFsIHRpbWUpLiBPbmNlIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIG5l Z290aWF0aW9uIGlzIGRvbmUsIHRoZW4gdGhlcmUgbWlnaHQgYmUgY2FzZXMgd2hlcmUgVk4gY2Fu IGJlIHJlLW5lZ290aWF0ZWQgb24gdGhlIGZseSAoZS5nLiwgY2hhbmdpbmcgc29tZSBiL3cgb3Ig c2VydmljZSBvYmplY3RpdmVzLCBvciBzb21lIHBoeXNpY2FsIGZhaWx1cmVzIHN1Y2ggYXMgZmli ZXIgY3V0KS4gQnV0IHRoaXMgaXMgbm90IFZOIGNyZWF0aW9uOyB3ZSBuZWVkIHRvIGRpc3Rpbmd1 aXNoIHRoaXMgZnJvbSBWTiByZS1uZWdvdGlhdGlvbi4NCi0gICBBZG1pc3Npb24gQ29udHJvbA0K VG8gY29vcmRpbmF0ZSB0aGUgcmVxdWVzdCBwcm9jZXNzIG9mIG11bHRpcGxlIGNsaWVudHMsIGFu IGFkbWlzc2lvbiBjb250cm9sIHdpbGwgaGVscCBtYXhpbWl6ZSBhbiBvdmVyYWxsIGVmZmljaWVu Y3kuDQpbW0RDXV0gWWVzLiBUbyB1bmRlcnN0YW5kIHdoZXJlIGlzIHRoZSBiZXN0IHBsYWNlIHRv IGRvIHRoYXQuIENsaW5lIGNvbnRyb2w/IFZOQz8NCg0KWU9VTkc+PiBBcyB0aGVyZSBhcmUgbWFu eSBjbGllbnRzIHRoYXQgdGhlIFZOQyBuZWVkcyB0byBzdXBwb3J0LCBJIGFzc3VtZSBWTkMgaGFz IHRvIGhhdmUgYWRtaXNzaW9uIGNvbnRyb2wgbW9kdWxlIGF0IHRoZSBsZWFzdC4gQ2xpZW50IENv bnRyb2xsZXIsIGhvd2V2ZXIsIG1heSBoYXZlIGl0cyBvd24gYWRtaXNzaW9uIGNvbnRyb2wgZm9y IHN1cHBvcnRpbmcgbXVsdGlwbGUgYXBwbGljYXRpb25zLiBXZSBuZWVkIHRvIHJlY29nbml6ZSBh IHJlY3Vyc2l2ZSBjbGllbnQtc2VydmVyIHJlbGF0aW9uc2hpcC4gQXMgbG9uZyBhcyBjb250cm9s bGVyIGlzIGEgc2VydmVyIGNvbnRyb2xsZXIgb2YgYW55IHNvcnQsIHRoZW4gYWRtaXNzaW9uIGNv bnRyb2wgZnVuY3Rpb24gd291bGQgaGVscCB0byBjb29yZGluYXRlIGl0cyBjbGllbnRzLg0KDQot ICAgUGF0aCBDb25zdHJhaW50cw0KVGhlcmUgbWF5IGJlIHNvbWUgZmFjdG9ycyBvZiBwYXRoIGNv bnN0cmFpbnRzIHRoYXQgY2FuIGFmZmVjdCB0aGUgb3ZlcmFsbCBlZmZpY2llbmN5LiBQYXRoIFNw bGl0IGNhbiBsb3dlciBWTiByZXF1ZXN0IGJsb2NraW5nIGlmIHRoZSB1bmRlcmx5aW5nIG5ldHdv cmsgY2FuIHN1cHBvcnQgc3VjaCBjYXBhYmlsaXR5LiBQYWNrZXQtYmFzZWQgVEUgbmV0d29yayBj YW4gc3VwcG9ydCBwYXRoIHNwbGl0IHdoaWxlIGNpcmN1aXQtYmFzZWQgdHJhbnNwb3J0IG1heSBo YXZlIGEgbGltaXRhdGlvbi4gIFBhdGggbWlncmF0aW9uIGlzIGEgdGVjaG5pcXVlIHRoYXQgYWxs b3dzIGNoYW5nZXMgb2Ygbm9kZXMgb3IgbGlua3MgYXNzaWdubWVudCBvZiB0aGUgZXN0YWJsaXNo ZWQgcGF0aHMgaW4gYW4gZWZmb3J0IHRvIGFjY29tbW9kYXRlIG5ldyByZXF1ZXN0cyB3aGljaCB3 b3VsZCBub3QgYmUgYWNjZXB0ZWQgd2l0aG91dCBwYXRoIG1pZ3JhdGlvbi4gVGhpcyBjYW4gaW1w cm92ZSBvdmVyYWxsIGVmZmljaWVuY3ksIHlldCBhZGRpdGlvbmFsIGNhcmUgbmVlZHMgdG8gYmUg YXBwbGllZCB0byBhdm9pZCBhbnkgYWR2ZXJzZSBpbXBhY3RzIGFzc29jaWF0ZWQgd2l0aCBjaGFu Z2luZyB0aGUgZXhpc3RpbmcgcGF0aHMuDQpSZS1vcHRpbWl6YXRpb24gaXMgYSBnbG9iYWwgcHJv Y2VzcyB0byByZS1zaHVmZmxlIGFsbCBleGlzdGluZyBwYXRoIGFzc2lnbm1lbnQgdG8gbWluaW1p emUgbmV0d29yayByZXNvdXJjZSBmcmFnbWVudGF0aW9uLiBBZ2FpbiwgYW4gZXh0cmEgY2FyZSBu ZWVkcyB0byBiZSBhcHBsaWVkIGZvciByZS1vcHRpbWl6YXRpb24uDQpbW0RDXV0gVHJ1ZS4gV2l0 aCBwYXRoIGNvbnN0cmFpbnRzIEkgdGhpbmsgd2Ugc2hvdWxkIGluY2x1ZGUgc29tZXRoaW5nIG1v cmUuIFdoZW4gYSBjbGllbnQgbmVlZHMgdG8gc2V0dXAgYSBzZXJ2aWNlL0xTUCB0aGVyZSBtaWdo dCBiZSBURSBjb25zdHJhaW50cyBhc3NvY2lhdGVkIHRvIHRoZSByZXF1ZXN0LiBXaGFuIHRoZSBW TiBuZWVkcyB0byBpbmNsdWRlIGlzIG5vdCBvbmx5IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBi dXQgaW4gbWFueSBjYXNlcyBpcyBzaG91bGQgYmUgVEUtcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9u LiBJbiB0aGlzIGNhc2Ugd2UgY291bGQgbGV2ZXJhZ2Ugb24gdGhlIG92ZXJsYXkgd29yayBiZWlu ZyBkb25lIGUuZy4gaW4gQ0NBTVAgYW5kIGluIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1mYXJyZWwtaW50ZXJjb25uZWN0ZWQtdGUtaW5mby1leGNoYW5nZS0wMikuDQoNCllPVU5H Pj4gWWVzLCBpZiB3ZSBpbmNsdWRlIG5vbi1URSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBhcyBwYXJ0 IG9mIHRoZSBBQ1ROIHNjb3BlLCB0aGVuICB0aGUgVEUtcmVhY2hlYWJpbGl0eSBuZWVkcyB0byBi ZSBrbm93bi9hZHZlcnRpc2VkIGJ5IHRoZSBzZXJ2ZXIgbmV0d29yayB0byBjbGllbnRzIGFzIOKA mGNhcGFiaWxpdHnigJkgYXR0cmlidXRlLg0KW1hpYW5dIEhhdmUgd2UgYWxyZWFkeSBjb25maW5l ZCB0aGUgc2NvcGUgdG8gVEUgdHJhbnNwb3J0IG5ldHdvcmsgb25seT8NCg0KSSB0aGluayB3aGV0 aGVyIHRoZSBURSBpbmZvcm1hdGlvbiBpcyBjb252ZXllZCB0byB0aGUgY2xpZW50IGRlcGVuZHMg b24gdGhlIGRldGFpbHMgdGhlIGNsaWVudCB3YW50cyB0byBrbm93LiBGcm9tIEFDVE4gd29yayBw b2ludCBvZiB2aWV3LCBpdCBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSBjb25z dHJhaW50cyB3b3J0aCBjb25zaWRlcmluZy4NCg== --_000_CEE853F7430D5mattabuedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgIj5Bbm90aGVyIHN1cnZleTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyAiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY3MuYnUuZWR1L3RlY2hyZXBvcnRzL3BkZi8y MDExLTAyNS1zbGljZS1lbWJlZGRpbmcucGRmIj5odHRwOi8vd3d3LmNzLmJ1LmVkdS90ZWNocmVw b3J0cy9wZGYvMjAxMS0wMjUtc2xpY2UtZW1iZWRkaW5nLnBkZjwvYT4mbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7ICI+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFy Z2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgZm9u dDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOHB4L25vcm1hbCBIZWx2ZXRpY2E7ICI+DQo8Zm9udCBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Ri4gRXNwb3Np dG8sIEkuIE1hdHRhLCBhbmQgVi4gSXNoYWtpYW4uIFNsaWNlIEVtYmVkZGluZyBTb2x1dGlvbnMg Zm9yPC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDog MHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IGZvbnQ6IG5vcm1hbCBu b3JtYWwgbm9ybWFsIDhweC9ub3JtYWwgSGVsdmV0aWNhOyAiPg0KPGZvbnQgY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPkRpc3RyaWJ1dGVkIFNlcnZpY2Ug QXJjaGl0ZWN0dXJlcy4gQUNNIENvbXB1dGluZyBTdXJ2ZXlzLCBBY2NlcHRlZDwvZm9udD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCA4 cHgvbm9ybWFsIEhlbHZldGljYTsgIj4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBm YWNlPSJDYWxpYnJpIiBzaXplPSIzIj5Ob3ZlbWJlciAyMDEyICh0byBhcHBlYXIgaW4gVm9sdW1l IDQ2LCBJc3N1ZSAxLCBNYXJjaCAyMDE0KS48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj5CZXN0LDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ aWJyYWhpbTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7ICI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtaaGFu Z3hpYW4gKFhpYW4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86emhhbmcueGlhbkBodWF3ZWku Y29tIj56aGFuZy54aWFuQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMzEsIDIwMTMgNDow MSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkRpZWdv IENhdmlnbGlhICZsdDs8YSBocmVmPSJtYWlsdG86ZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29t Ij5kaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb208L2E+Jmd0OywgTGVleW91bmcgJmx0OzxhIGhy ZWY9Im1haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIj5sZWV5b3VuZ0BodWF3ZWkuY29tPC9hPiZn dDssIERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb20iPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208L2E+Jmd0 OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86YWN0bkBpZXRmLm9yZyI+YWN0bkBpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphY3RuQGlldGYub3JnIj5hY3RuQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4m cXVvdDs8YSBocmVmPSJtYWlsdG86c2RuQGlydGYub3JnIj5zZG5AaXJ0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2RuQGlydGYub3JnIj5zZG5AaXJ0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtT ZG5dIFtBY3RuXSB2aXJ0dWFsIG5ldHdvcmsgbWFwcGluZy9lbWJlZGRpbmcgKFZOTS9WTkUpIHBy b2JsZW08YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOndvcmQiIHhtbG5zOng9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmV4Y2Vs IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29t bWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9 IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSki Pg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpCYXRhbmc7DQoJcGFub3NlLTE6MiAzIDYgMCAwIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBCYXRhbmci Ow0KCXBhbm9zZS0xOjIgMyA2IDAgMCAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbWFyZ2luLXRvcDowY207DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEyLjBwdDsNCgltYXJnaW4tbGVmdDoy MS42cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDsNCglsaW5lLWhlaWdodDoxMi4wcHQ7DQoJbXNv LWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseTsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1z by1saXN0OmwxIGxldmVsMSBsZm8yOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpub3JtYWw7fQ0KaDINCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFyIjsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdp bi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBw dDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZv aWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQpoMw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENoYXIiOw0KCW1h cmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbToxMi4wcHQ7 DQoJbWFyZ2luLWxlZnQ6ODAuMXB0Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7DQoJbGluZS1oZWln aHQ6MTIuMHB0Ow0KCW1zby1saW5lLWhlaWdodC1ydWxlOmV4YWN0bHk7DQoJcGFnZS1icmVhay1h ZnRlcjphdm9pZDsNCgltc28tbGlzdDpsMSBsZXZlbDMgbGZvMjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJZm9udC13ZWlnaHQ6bm9ybWFsO30NCmg0 DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQgQ2hh ciI7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjEyLjBwdDsNCgltYXJnaW4tbGVmdDoyMS42cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDsNCgls aW5lLWhlaWdodDoxMi4wcHQ7DQoJbXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseTsNCglwYWdl LWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1saXN0OmwxIGxldmVsNCBsZm8yOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpub3Jt YWw7fQ0KaDUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRp bmcgNSBDaGFyIjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEu NnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5 Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw1IGxmbzI7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDt9DQpoNg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu azoiSGVhZGluZyA2IENoYXIiOw0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbWFyZ2luLWJvdHRvbToxMi4wcHQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRleHQtaW5k ZW50Oi0yMS42cHQ7DQoJbGluZS1oZWlnaHQ6MTIuMHB0Ow0KCW1zby1saW5lLWhlaWdodC1ydWxl OmV4YWN0bHk7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCgltc28tbGlzdDpsMSBsZXZlbDYg bGZvMjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsO30NCnAuTXNvSGVhZGluZzcsIGxpLk1zb0hlYWRpbmc3LCBkaXYu TXNvSGVhZGluZzcNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Ikhl YWRpbmcgNyBDaGFyIjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDot MjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFj dGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw3IGxmbzI7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv SGVhZGluZzgsIGxpLk1zb0hlYWRpbmc4LCBkaXYuTXNvSGVhZGluZzgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgOCBDaGFyIjsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdp bi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBw dDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZv aWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw4IGxmbzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvSGVhZGluZzksIGxpLk1zb0hlYWRpbmc5LCBk aXYuTXNvSGVhZGluZzkNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6 IkhlYWRpbmcgOSBDaGFyIjsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MTIuMHB0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVu dDotMjEuNnB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCgltc28tbGluZS1oZWlnaHQtcnVsZTpl eGFjdGx5Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDEgbGV2ZWw5IGxm bzI7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSGVh ZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVh ZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJI ZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IZWFkaW5nM0No YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uSGVhZGluZzRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcg NCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmc1Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSGVhZGluZyA1IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0K CW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDUiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5IZWFkaW5nNkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNiBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA2IjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSGVhZGluZzdDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIZWFkaW5nIDcgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0 eWxlLWxpbms6IkhlYWRpbmcgNyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkhlYWRpbmc4Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA4IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDgiOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IZWFkaW5nOUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhlYWRpbmcgOSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu azoiSGVhZGluZyA5IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFsbG9v blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoy NjU2MjE2Nzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xODYyNDg5ODM4IC0xNDAyNDM2NzgwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjczMDczNzk4NDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0Nzk2MDcyMTY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9u ZTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiAiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMS42cHQ7DQoJ dGV4dC1pbmRlbnQ6LTIxLjZwdDsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJbXNvLXRleHQtYW5pbWF0 aW9uOm5vbmU7DQoJbXNvLWhpZGU6bm9uZTsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXBvc2l0 aW9uOnJlbGF0aXZlOw0KCXRvcDowcHQ7DQoJbXNvLXRleHQtcmFpc2U6MHB0Ow0KCWxldHRlci1z cGFjaW5nOjBwdDsNCgltc28tZm9udC1rZXJuaW5nOjBwdDsNCgl0ZXh0LWVmZmVjdDpub25lOw0K CXRleHQtc2hhZG93Om5vbmU7DQoJdGV4dC1lZmZlY3Q6bm9uZTsNCgl0ZXh0LWVmZmVjdDpub25l Ow0KCWZvbnQtZW1waGFzaXplOm5vbmU7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6bm9ybWFsOw0K CW1zby1iaWRpLWZvbnQtd2VpZ2h0Om5vcm1hbDsNCgltc28tYW5zaS1mb250LXN0eWxlOm5vcm1h bDsNCgltc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbDsNCgltc28tbm8tcHJvb2Y6bm87DQoJdGV4 dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRlY29yYXRp b246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3VnaDpub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAy IjsNCgltc28tbGV2ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuICI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0O30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCgltc28tbGV2 ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiAiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoxNzkuMXB0Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7DQoJZm9udC12YXJpYW50 Om5vcm1hbCAhaW1wb3J0YW50Ow0KCW1zby10ZXh0LWFuaW1hdGlvbjpub25lOw0KCW1zby1oaWRl Om5vbmU7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCglwb3NpdGlvbjpyZWxhdGl2ZTsNCgl0b3A6 MHB0Ow0KCW1zby10ZXh0LXJhaXNlOjBwdDsNCglsZXR0ZXItc3BhY2luZzowcHQ7DQoJbXNvLWZv bnQta2VybmluZzowcHQ7DQoJdGV4dC1lZmZlY3Q6bm9uZTsNCgl0ZXh0LXNoYWRvdzpub25lOw0K CXRleHQtZWZmZWN0Om5vbmU7DQoJdGV4dC1lZmZlY3Q6bm9uZTsNCglmb250LWVtcGhhc2l6ZTpu b25lOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0Om5vcm1hbDsNCgltc28tYW5zaS1mb250LXN0eWxl Om5vcm1hbDsNCgltc28tYmlkaS1mb250LXN0eWxlOm5vcm1hbDsNCgltc28tbm8tcHJvb2Y6bm87 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRl Y29yYXRpb246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3VnaDpub25lOw0KCXZlcnRpY2FsLWFsaWdu OmJhc2VsaW5lO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVh ZGluZyA0IjsNCgltc28tbGV2ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4l MlwuJTNcLiU0XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRleHQtaW5kZW50Oi0y MS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5n IDUiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4l M1wuJTRcLiU1XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRleHQtaW5kZW50Oi0y MS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5n IDYiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4l M1wuJTRcLiU1XC4lNlwuICI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVu dDotMjEuNnB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVh ZGluZyA3IjsNCgltc28tbGV2ZWwtc3VmZml4Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC4l MlwuJTNcLiU0XC4lNVwuJTZcLiU3XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEuNnB0Ow0KCXRl eHQtaW5kZW50Oi0yMS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1zdHlsZS1s aW5rOiJIZWFkaW5nIDgiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCgltc28tbGV2ZWwtdGV4 dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4XC4gIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MjEuNnB0Ow0KCXRleHQtaW5kZW50Oi0yMS42cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDkiOw0KCW1zby1sZXZlbC1zdWZmaXg6bm9uZTsNCglt c28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4XC4lOVwuICI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjIxLjZwdDsNCgl0ZXh0LWluZGVudDotMjEuNnB0O30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjkyNzczMjAyMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6NjQ0NDg4NTI0IDE0MjIyOTcwNTYgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6QmF0YW5nO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6 bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLA0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgU29t ZSBmdXJ0aGVyIHRob3VnaHRzIG9uIHNvbWUgb2YgdGhlIGlzc3Vlcy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwO0JUVywgaWYgYW55b25lIGlz IGludGVyZXN0ZWQgdG8gc2VlIHRoZSBzdGF0dXMgcXVvIG9mIFZORSByZXNlYXJjaCwgdGhlIGZv bGxvd2luZyBtaWdodCBiZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1 LmRlL2ZpbGVhZG1pbi9maWxlcy9sZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2No ZXIyMDEzYS5wZGYiPmh0dHA6Ly93d3cuZmltLnVuaS1wYXNzYXUuZGUvZmlsZWFkbWluL2ZpbGVz L2xlaHJzdHVobC9tZWVyL3B1YmxpY2F0aW9ucy9wZGYvRmlzY2hlcjIwMTNhLnBkZjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkhhcHB5IG5ldyB5ZWFyLA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5YaWFuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7ICI+IHNkbiBbPGEgaHJlZj0ibWFpbHRvOnNkbi1ib3VuY2VzQGlydGYub3JnIj5tYWlsdG86 c2RuLWJvdW5jZXNAaXJ0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EaWVnbyBDYXZp Z2xpYTxicj4NCjxiPlNlbnQ6PC9iPiAyMDEzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAi PjEyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9 kyI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjIzPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5pelPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5z LXNlcmlmOyAiPg0KIDE2OjAyPGJyPg0KPGI+VG86PC9iPiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNj YXJlbGxpOyA8YSBocmVmPSJtYWlsdG86YWN0bkBpZXRmLm9yZyI+YWN0bkBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZG5AaXJ0Zi5vcmciPnNkbkBpcnRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTZG5dIFtBY3RuXSB2aXJ0dWFsIG5ldHdv cmsgbWFwcGluZy9lbWJlZGRpbmcgKFZOTS9WTkUpIHByb2JsZW08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgYWxsIHNvbWUgbW9yZSB0 aG91Z2h0IHdpdGggc29tZSBjbGVhbmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CUiBhbmQgU2Vhc29uIGdyZWV0aW5ncyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxoMiBzdHlsZT0ibXNvLWxpc3Q6 bm9uZSI+PGEgbmFtZT0iX1RvYzM3NDcwOTEwMyI+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2gyPg0KPGgyIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+PCEtLVtpZiAhc3Vw cG9ydExpc3RzXS0tPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4g bGFuZz0iRU4tVVMiPlJlcXVlc3QgUHJvY2Vzc2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBjb25jZXJuZWQg YWJvdXQgd2hldGhlciBhIHNldCBvZiBjbGllbnQgcmVxdWVzdHMgZm9yIFZOIGNyZWF0aW9uIGNh biBiZSBkZWFsdCB3aXRoIHNpbXVsdGFuZW91c2x5IG9yIG5vdC4gVGhpcyBkZXBlbmRzIG9uIHRo ZSBuYXR1cmUgb2YgYXBwbGljYXRpb25zIHRoZSBjbGllbnQgc3VwcG9ydC4gSWYgdGhlIGNsaWVu dCBkb2VzIG5vdCByZXF1aXJlIHJlYWwtdGltZQ0KIGluc3RhbnRpYXRpb24gb2YgVk4gY3JlYXRp b24sIHRoZSBjb21wdXRhdGlvbiBlbmdpbmUgY2FuIHByb2Nlc3MgYSBzZXQgb2YgVk4gY3JlYXRp b24gcmVxdWVzdHMgc2ltdWx0YW5lb3VzbHkgdG8gaW1wcm92ZSBuZXR3b3JrIGVmZmljaWVuY3ku DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltbRENdXSBJIHRoaW5rIGhlcmUg d2UgY2FuIGFzc3VtZSB0aGF0IFZOIGNyZWF0aW9uIHJlcXVlc3RzIGFyZSBub24gcmVhbCB0aW1l LiBJbnN0YW50aWF0aW9uIG9mIHNlcnZpY2VzIGFuZCBiYW5kd2lkdGggbWlnaHQgYmUgcmVhbCB0 aW1lIChhbmQgaGVuY2UgY29uY3VycmVuY3kgbmVlZHMgdG8gYmUgbWFuYWdlZCkgYnV0IEkgd291 bGQNCiBzYXkgdGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgVk4gY3JlYXRpb24uPC9zcGFuPjwvaT48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WU9VTkcm Z3Q7Jmd0OyBHb29kIHBvaW50LiAmbmJzcDtJIHdhcyBsb29zZSBvbiB0aGUgdGVybSDigJhWTiBj cmVhdGlvbuKAnS4mbmJzcDsgVGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3Rz IG9mIFZOIGNyZWF0aW9uIHdoaWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0 aGUgY2xpZW50IGVuZHBvaW50cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQNCiB3aXRoIG5ldHdvcmsg cHJvdmlkZXIocykgYmVmb3JlIHNlcnZpY2UgY3JlYXRpb24uIFllcywgaW4gdGhhdCBzZW5zZSwg SSBhZ3JlZSB3aXRoIHlvdS4gSGVyZSB3aGF0IEkgbWVhbnQgdG8gc2F5IHdhcyB3aGVuIHRoZXJl IGFyZSBtdWx0aXBsZSBzZXJ2aWNlIHJlcXVlc3RzICZuYnNwO3RvIHNldHVwIHZpcnR1YWwgY29u bmVjdGlvbnMgdGhhdCBuZWVkIG5vdCBiZSBpbnN0YW50aWF0ZWQgcmVhbC10aW1lLCAoaW4gb3Ro ZXIgd29yZHMsIGlmIHNvbWUgcmVxdWVzdA0KIGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2No ZWR1bGluZyksIHRoZW4gYSBiYXRjaCBwcm9jZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdv dWxkIGJlIG1vcmUgb3B0aW1hbCBpbiBnZW5lcmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kg cGVyc3BlY3RpdmUgdGhhbiBzZXF1ZW50aWFsIHByb2Nlc3NpbmcuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPltEQ10geWVzIGFuZCB0aGlzIGlzIG9uZSBvZiB0aGUgYmlnZ2Vz dCBhZHZhbnRhZ2Ugb2YgYSBjZW50cmFsaXplZCBhcHByb2FjaCB2ZXJzdXMgYSBkaXN0cmlidXRl ZCBvbmUsIHRoYXQgaXMgdGhlIHBvc3NpYmlsaXR5IHRvIGNvbXB1dGUgdGhlIG9wdGltYWwgc29s dXRpb24gb2YgYSBidW5jaCBvZiByZXF1ZXN0czwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bHVlIj5bWGlhbl0gSSB0aGluayB3ZSBoYXZlIGEgcHJldHR5IHVuZGVyc3RhbmRpbmcgb2YgdGhl IGlzc3VlIGFuZCBhcyBJIHVuZGVyc3RhbmQsIHRoZSBwb2ludHMgcmVsYXRlZCB0byBBQ1ROIHdv dWxkIGluY2x1ZGUgYXQgbGVhc3QgKDEpIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgcGFz c2VkIGZyb20gY2xpZW50DQogdG8gdmlydHVhbCBuZXR3b3JrIHByb3ZpZGVyPzsgKDIpIHdoYXQg Y29uc3RyYWludHMmbmJzcDsgdGhlIGNsaWVudCBjYW4gYWNjZXB0ICh0aW1lIG1pZ2h0IGJlIGEg Y29uc3RyYWludHMpLiZuYnNwOyBJZiB0aGVyZSBpcyBtb3JlLCBwbGVhc2UgYW1lbmQuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxo MiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzQiPjxhIG5hbWU9Il9Ub2MzNzQ3MDkxMDQiPjwhLS1baWYgIXN1cHBvcnRM aXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGxhbmc9 IkVOLVVTIj5UeXBlcyBvZiBOZXR3b3JrIFJlc291cmNlczwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+V2hlbiBjbGllbnQgbWFrZXMgYSBWTiBjcmVhdGlvbiByZXF1ZXN0IHRv IHRoZSBzdWJzdHJhdGUgbmV0d29yaywgd2hhdCBraW5kIG9mIG5ldHdvcmsgcmVzb3VyY2VzIGlz IGNvbnN1bWVkIGlzIG9mIGNvbmNlcm4gb2YgYm90aCB0aGUgY2xpZW50IGFuZCBuZXR3b3JrIHBy b3ZpZGVycy4gSXQgZGVwZW5kcyBvbiB0aGUgYXBwbGljYXRpb24uIEZvciB0cmFuc3BvcnQgbmV0 d29yaw0KIHZpcnR1YWxpemF0aW9uLCB0aGUgbmV0d29yayByZXNvdXJjZSBjb25zdW1lZCBieSB0 aGUgY2xpZW50IGlzIHByaW1hcmlseSBuZXR3b3JrIGJhbmR3aWR0aCB0aGF0IHRoZSBwYXRocyB3 b3VsZCBvY2N1cHkgb24gdGhlIHBoeXNpY2FsIGxpbmsuIEhvd2V2ZXIsIHRoZXJlIG1heSBiZSBv dGhlciByZXNvdXJjZSB0eXBlcyBzdWNoIGFzIENQVSBhbmQgbWVtb3J5IHRoYXQgbmVlZCB0byBi ZSBjb25zaWRlcmVkIGZvciBjZXJ0YWluIGFwcGxpY2F0aW9ucy4NCiBUaGVzZSByZXNvdXJjZSB0 eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGllbnTigJlzIFZOIHJlcXVlc3QuIDxhIG5hbWU9Il9U b2MzNzQ3MDkxMDUiPg0KPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W1tE Q11dIEhlcmUgdGhlIGlzc3VlIGlzIHRob3JueS4gVGhlIHBvaW50IGlzOiBhIGdpdmVuIHJlc291 cmNlIGlzIGRlZGljYXRlZCB0byBhIGdpdmVuIFZOIG9yIHNoYXJlZCBhbW9uZyBkaWZmZXJlbnQg b25lcz8gV2Ugc2hvdWxkIHN0YXJ0IGNvbnNpZGVyaW5nIG5ldHdvcmsgcmVzb3VyY2VzIHBhcnRp dGlvbmluZyBpc3N1ZXPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZT1VORyZndDsmZ3Q7Jm5ic3A7IEEgZ2l2 ZW4gcmVzb3VyY2UgaXMg4oCcdmlydHVhbGx54oCdIGRlZGljYXRlZCB0byBhIHBhcnRpY3VsYXIg Y2xpZW50OyB5ZXQgdGhpcyBkb2VzIG5vdCBtZWFuIGEgcGFydGljdWxhciBjbGllbnQgb2NjdXBp ZXMgYSBwYXJ0aWN1bGFyIHBvcnQgKHNheSBPRFUgcG9ydCAxIHZzIDIpLiZuYnNwOyBBcyBsb25n IGFzIHJlc291cmNlIGlzIGd1YXJhbnRlZWQNCiBmb3IgdXNlIHRvIHRoZSBjbGllbnQsIGl0IGlz IGZpbmUgZm9yIHRoZSBXb3JraW5nIFBhdGggYXQgbGVhc3Q7IGhvd2V2ZXIgZm9yIDE6TiBraW5k IG9mIHByb3RlY3Rpb24gY2FzZSwgdGhlcmUgaXMgYSBsZXZlbCBvZiBzaGFyaW5nIGJhY2t1cCBw YXRoIHJlc291cmNlIGZvciBtdWx0aXBsZSBjbGllbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5bRENdIHdlbGwgYXQgbGVhc3QgdHJpYnV0YXJ5IHBvcnQgY2Fu4oCZdCBi ZSB2aXJ0dWFsIEkgbmVlZCB0byBuYWlsIGl0IHRvIGEgcGh5c2ljYWwgbnVtYmVyaW5nIHRvIHBo eXNpY2FsbHkgY29ubmVjdCB0aGUgSFcsIGZvciB0aGUgcmVzdCBJIGFncmVlLiZuYnNwOw0KPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymx1ZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsdWUiPltYaWFuXSBJIHRoaW5rIFlv dW5nIG1lYW50IHRoZSBwaHlzaWNhbCByZXNvdXJjZSBjYW4gYmUgc2hhcmVkIGJ5IG11bHRpcGxl IGNsaWVudHMsIHByb2JhYmx5IGJ5IGFzc2lnbmluZyB0aGUgc2FtZSBwaHlzaWNhbCBudW1iZXJp bmcgdG8gdGhlIGRpZmZlcmVudCBjbGllbnRzLiBUaGUgcG9pbnQgdGhhdCB3b3J0aA0KIG5vdGlu ZyBpcyB0aGF0IHdoZXRoZXIgdGhpcyBraW5kIG9mIHNoYXJpbmcgY2FuIG1ha2Ugc3VyZSBubyBj b25mbGljdCB3b3VsZCBhcmlzZSBvciBpZiBzbywgd2hldGhlciBpdCBpcyBhY2NlcHRhYmxlLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwh LS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlm XS0tPjxzcGFuIGxhbmc9IkVOLVVTIj5BY2N1cmFjeSBvZiBOZXR3b3JrIFJlc291cmNlIFJlcHJl c2VudGF0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBuZXR3b3JrIGlu IGl0c2VsZiBtYXkgY29uc2lzdHMgb2YgbGF5ZXJlZCBzdHJ1Y3R1cmUsIGl0IGlzIGEgY2hhbGxl bmdlIGhvdyB0byByZXByZXNlbnQgdGhlc2UgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIHJl c291cmNlcyBhbmQgdG9wb2xvZ3kgaW50byBhIGZvcm0gdGhhdCBjYW4gYmUgcmVsaWFibHkgdXNl ZCBieSB0aGUNCiBjb21wdXRhdGlvbiBlbmdpbmUgdGhhdCBhc3NpZ25zIHRoZSBjbGllbnQgcmVx dWVzdHMgaW50byB0aGUgcGh5c2ljYWwgbmV0d29yayByZXNvdXJjZSBhbmQgdG9wb2xvZ3kuDQo8 YSBuYW1lPSJfVG9jMzc0NzA5MTA2Ij48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5bW0RDXV0gRGFtbmx5IHRydWU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+W0RDXSBJIHZvdGUgZm9yIGEgS0lTUyBhcHByb2FjaA0KPC9zcGFuPjwvaT48L2I+ PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+SjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsdWUiPltYaWFuXUNhbm5vdCBhZ3JlZSB3aXRoIERpZWdvIG1vcmUsIDpELg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwhLS1baWYgIXN1 cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFu IGxhbmc9IkVOLVVTIj5SZXNvdXJjZSBFZmZpY2llbmN5PG86cD48L286cD48L3NwYW4+PC9oMj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWxhdGVkIHRvIHRoZSBh Y2N1cmFjeSBvZiBuZXR3b3JrIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIGlzIHJlc291cmNlIGVm ZmljaWVuY3kuIEFzIGEgc2V0IG9mIGluZGVwZW5kZW50IGNsaWVudCBWTiBpcyBjcmVhdGVkIGFu ZCBtYXBwZWQgb250byBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNlcywgdGhlIG92ZXJhbGwgbmV0 d29yayByZXNvdXJjZSB1dGlsaXphdGlvbiBpcyBvZg0KIHRoZSBwcmltYXJ5IGNvbmNlcm4gb2Yg dGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPltbRENdXSBUaGlzIGlzc3VlIGlzIHByZXR0eSBtdWNoIGxpbmtlZCB0byB0aGUgb25l IGFib3ZlICh0eXBlcyBvZiBuZXR3b3JrIHJlc291cmNlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZT1VORyZn dDsmZ3Q7IFllcy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsdWUiPltY aWFuXSBUaGlzIHByb2JhYmx5IGlzIG1vcmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFk IG9mIEFDVE4sIGJ1dCBmb3Igc3VyZSBhbiBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFs bCBzb2x1dGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGNtO3RleHQtaW5kZW50OjBjbTttc28tbGlzdDpub25lIj48YSBuYW1lPSJfVG9jMzc0NzA5 MTA3Ij48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaDI+ DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwyIGxldmVsMSBsZm80Ij48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0i RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBsYW5nPSJFTi1VUyI+R3VhcmFudGVlIG9m IENsaWVudCBJc29sYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoaWxlIG5ldHdvcmsgcmVzb3VyY2Ugc2hhcmluZyBh Y3Jvc3MgYSBzZXQgb2YgY2xpZW50cyBmb3IgZWZmaWNpZW50IHV0aWxpemF0aW9uIGlzIGltcG9y dGFudCBhc3BlY3Qgb2YgbmV0d29yayB2aXJ0dWFsaXphdGlvbiwgY2xpZW50IGlzb2xhdGlvbiBo YXMgdG8gYmUgZ3VhcmFudGVlZC4gQWRtaXNzaW9ucyBvZiBuZXcgY2xpZW50IHJlcXVlc3RzIG9y IGFueSBjaGFuZ2VzIG9mDQogb3RoZXIgZXhpc3RpbmcgY2xpZW50c+KAmSBWTnMgbXVzdCBub3Qg YWZmZWN0IGFueSBwYXJ0aWN1bGFyIGNsaWVudCBpbiB0ZXJtcyBvZiByZXNvdXJjZSBndWFyYW50 ZWUsIHNlY3VyaXR5IGNvbnN0cmFpbnRzLCBhbmQgb3RoZXIgcGVyZm9ybWFuY2UgY29uc3RyYWlu dHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltbRENdXSBBZ2Fp biBsaW5rZWQgdG8gaXNzdWVzIGFib3ZlLiBJZiBuZXR3b3JrIHJlc291cmNlcyBhcmUgZGVkaWNh dGVkIHRvIGVhY2ggVk4sIHRoaXMgaXMgdHJ1ZSwgYnV0IGlmIHRoZXkgKG9yIHBhcnQgb2YgdGhl bSkgYXJlIHNoYXJlZCwgdGhlIGluc3RhbnRpYXRpb24gb2YgYSBzZXJ2aWNlIGZyb20gYSBnaXZl biBjbGllbnQNCiB3b3VsZCBpbXBhY3QgdGhlIFZOIHNlZW4gYnkgb3RoZXJzLiBPbiB0aGUgb3Ro ZXIgc2lkZSwgYXNwZWN0cyBsaWtlIHNlY3VyaXR5IG8gcGVyZm9ybWFuY2VzIHNob3VsZCBub3Qg YmUgaW1wYWN0ZWQgaW4gYW55IG9mIHRoZSB0d28gY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WU9VTkcm Z3Q7Jmd0OyBBZ3JlZS4mbmJzcDsgU28gSSBndWVzcyB3ZSBuZWVkIHRvIGJlIGNsZWFyIG9uIHJl c291cmNlIHBhcnRpdGlvbmluZyBhbmQgc2hhcmluZyBpc3N1ZSBjbGVhcmx5IC0tLSBJIHRoaW5r IHNvbWUgYXBwbGljYXRpb24vY2xpZW50IHJlcXVpcmVzIGEgaGFyZCBkZWRpY2F0ZWQgcmVzb3Vy Y2Ugd2hpbGUgZm9yIHNvbWUgb3RoZXJzIGl0IGlzDQogZmx1aWQuJm5ic3A7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0RDXSB5ZXMgYW5kIHRoaXMgd2lsbCBnaXZlIHRvIHRo ZSBjYXJyaWVycyB0aGUgcG9zc2liaWxpdHkgdG8gZGlmZmVyZW50aWF0ZSB0aGVpciBzZXJ2aWNl IG9mZmVyaW5nLCBkbyB5b3Ugd2FudCBndWFyYW50ZWVkIGJhbmR3aWR0aCBpbiBjYXNlIG9mIG11 bHRpcGxlIGZhaWx1cmVzPyBUaGVuIHlvdSBoYXZlIHRvIHBheSBtb3JlLjwvc3Bhbj48L2k+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGgyIHN0eWxlPSJtYXJnaW4tbGVmdDowY207dGV4dC1pbmRlbnQ6MGNtO21zby1s aXN0Om5vbmUiPjxhIG5hbWU9Il9Ub2MzNzQ3MDkxMDgiPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9oMj4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwhLS1baWYg IXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxz cGFuIGxhbmc9IkVOLVVTIj5Db21wdXRpbmcgVGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVwZW5kaW5nIG9uIHRoZSBu YXR1cmUgb2YgYXBwbGljYXRpb25zLCBob3cgcXVpY2tseSBhIFZOIGlzIGluc3RhbnRpYXRlZCBm cm9tIHRoZSB0aW1lIG9mIHJlcXVlc3QgaXMgYW4gaW1wb3J0YW50IGZhY3Rvci4gRm9yIGR5bmFt aWMgYXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSBpbnN0YW50YW5lb3VzIFZOIGNyZWF0aW9uLCB0 aGUgY29tcHV0YXRpb24gbW9kZWwvYWxnb3JpdGhtDQogc2hvdWxkIHN1cHBvcnQgdGhpcyBjb25z dHJhaW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltbRENdXSBJIHdvdWxk IHNheSB0aGF0IHRpbWluZyBjb25zdHJhaW50cyBuZWVkIHRvIGJlIG1ldCBmb3Igc2VydmljZSBw cm92aXNpb25pbmcgKGkuZS4gdXBvbiBjbGllbnQgcmVxdWVzdHMgb24gYSBnaXZlbiBWTikgYnV0 IEkgdGhpbmsgVk4gaW5zdGFudGlhdGlvbiBjb3VsZCBiZSBhbHNvIGEgbm9uIHJlYWwgdGltZSBw cm9jZWR1cmUuDQogSSBtaWdodCBiZSB3cm9uZ+KApmFyZSB0aGVyZSB1c2UgY2FzZXMgZm9yIHJl YWwgdGltZSBhbmQgdGltaW5nIGNvbnN0cmFpbmVkIFZOIGNyZWF0aW9uIHJlcXVyZXN0cz88L3Nw YW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO3RleHQtaW5kZW50 OjBjbTttc28tbGlzdDpub25lIj48YSBuYW1lPSJfVG9jMzc0NzA5MTA5Ij48L2E+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2gyPg0KPGgyIHN0eWxlPSJtYXJnaW4tbGVmdDowY207dGV4dC1pbmRlbnQ6MGNtO21zby1saXN0 Om5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+WU9V TkcmZ3Q7Jmd0OyAmbmJzcDtBZ2FpbiBoZXJlIHdoYXQgSSBtZWFudCB3YXMgc2VydmljZSByZXF1 ZXN0LiBJIG5lZWQgdG8gYmUgY2xlYXIgb24gdGhlIHRlcm1pbm9sb2d5LiZuYnNwOyBJZg0KIHdl IHdlcmUgdG8gZGVmaW5lIFZOIGNyZWF0aW9uIGFzIHRoZSBwcm9jZXNzIG9mIG5lZ290aWF0aW9u IChzaW1pbGFyIHRvIFNMQSBuZWdvdGlhdGlvbiksIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIGlz IGFsd2F5cyBvZmYtbGluZSAoc3RhdGljIGFuZCBub24tcmVhbCB0aW1lKS4gT25jZSB0aGUgaW5p dGlhbCBWTiBjcmVhdGlvbiBuZWdvdGlhdGlvbiBpcyBkb25lLCB0aGVuIHRoZXJlIG1pZ2h0IGJl IGNhc2VzIHdoZXJlIFZOIGNhbiBiZSByZS1uZWdvdGlhdGVkDQogb24gdGhlIGZseSAoZS5nLiwg Y2hhbmdpbmcgc29tZSBiL3cgb3Igc2VydmljZSBvYmplY3RpdmVzLCBvciBzb21lIHBoeXNpY2Fs IGZhaWx1cmVzIHN1Y2ggYXMgZmliZXIgY3V0KS4gQnV0IHRoaXMgaXMgbm90IFZOIGNyZWF0aW9u OyB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIHRoaXMgZnJvbSBWTiByZS1uZWdvdGlhdGlvbi4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48IS0tW2lmICFzdXBwb3J0 TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi Pi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBsYW5n PSJFTi1VUyI+QWRtaXNzaW9uIENvbnRyb2w8bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvIGNvb3JkaW5hdGUgdGhlIHJlcXVl c3QgcHJvY2VzcyBvZiBtdWx0aXBsZSBjbGllbnRzLCBhbiBhZG1pc3Npb24gY29udHJvbCB3aWxs IGhlbHAgbWF4aW1pemUgYW4gb3ZlcmFsbCBlZmZpY2llbmN5Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5bW0RDXV0gWWVzLiBUbyB1bmRlcnN0YW5kIHdoZXJlIGlzIHRoZSBi ZXN0IHBsYWNlIHRvIGRvIHRoYXQuIENsaW5lIGNvbnRyb2w/IFZOQz88bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Z T1VORyZndDsmZ3Q7IEFzIHRoZXJlIGFyZSBtYW55IGNsaWVudHMgdGhhdCB0aGUgVk5DIG5lZWRz IHRvIHN1cHBvcnQsIEkgYXNzdW1lIFZOQyBoYXMgdG8gaGF2ZSBhZG1pc3Npb24gY29udHJvbCBt b2R1bGUgYXQgdGhlIGxlYXN0LiBDbGllbnQgQ29udHJvbGxlciwgaG93ZXZlciwgbWF5IGhhdmUg aXRzIG93biBhZG1pc3Npb24gY29udHJvbCBmb3INCiBzdXBwb3J0aW5nIG11bHRpcGxlIGFwcGxp Y2F0aW9ucy4gV2UgbmVlZCB0byByZWNvZ25pemUgYSByZWN1cnNpdmUgY2xpZW50LXNlcnZlciBy ZWxhdGlvbnNoaXAuIEFzIGxvbmcgYXMgY29udHJvbGxlciBpcyBhIHNlcnZlciBjb250cm9sbGVy IG9mIGFueSBzb3J0LCB0aGVuIGFkbWlzc2lvbiBjb250cm9sIGZ1bmN0aW9uIHdvdWxkIGhlbHAg dG8gY29vcmRpbmF0ZSBpdHMgY2xpZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48YSBuYW1lPSJfVG9jMzc0NzA5MTEwIj48IS0tW2lm ICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48 c3BhbiBsYW5nPSJFTi1VUyI+UGF0aCBDb25zdHJhaW50czwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlcmUgbWF5IGJlIHNvbWUgZmFjdG9ycyBvZiBwYXRoIGNvbnN0cmFp bnRzIHRoYXQgY2FuIGFmZmVjdCB0aGUgb3ZlcmFsbCBlZmZpY2llbmN5LiBQYXRoIFNwbGl0IGNh biBsb3dlciBWTiByZXF1ZXN0IGJsb2NraW5nIGlmIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgY2Fu IHN1cHBvcnQgc3VjaCBjYXBhYmlsaXR5LiBQYWNrZXQtYmFzZWQgVEUgbmV0d29yayBjYW4gc3Vw cG9ydA0KIHBhdGggc3BsaXQgd2hpbGUgY2lyY3VpdC1iYXNlZCB0cmFuc3BvcnQgbWF5IGhhdmUg YSBsaW1pdGF0aW9uLiAmbmJzcDtQYXRoIG1pZ3JhdGlvbiBpcyBhIHRlY2huaXF1ZSB0aGF0IGFs bG93cyBjaGFuZ2VzIG9mIG5vZGVzIG9yIGxpbmtzIGFzc2lnbm1lbnQgb2YgdGhlIGVzdGFibGlz aGVkIHBhdGhzIGluIGFuIGVmZm9ydCB0byBhY2NvbW1vZGF0ZSBuZXcgcmVxdWVzdHMgd2hpY2gg d291bGQgbm90IGJlIGFjY2VwdGVkIHdpdGhvdXQgcGF0aCBtaWdyYXRpb24uDQogVGhpcyBjYW4g aW1wcm92ZSBvdmVyYWxsIGVmZmljaWVuY3ksIHlldCBhZGRpdGlvbmFsIGNhcmUgbmVlZHMgdG8g YmUgYXBwbGllZCB0byBhdm9pZCBhbnkgYWR2ZXJzZSBpbXBhY3RzIGFzc29jaWF0ZWQgd2l0aCBj aGFuZ2luZyB0aGUgZXhpc3RpbmcgcGF0aHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmUtb3B0aW1pemF0aW9uIGlzIGEg Z2xvYmFsIHByb2Nlc3MgdG8gcmUtc2h1ZmZsZSBhbGwgZXhpc3RpbmcgcGF0aCBhc3NpZ25tZW50 IHRvIG1pbmltaXplIG5ldHdvcmsgcmVzb3VyY2UgZnJhZ21lbnRhdGlvbi4gQWdhaW4sIGFuIGV4 dHJhIGNhcmUgbmVlZHMgdG8gYmUgYXBwbGllZCBmb3IgcmUtb3B0aW1pemF0aW9uLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bW0RDXV0gVHJ1ZS4gV2l0aCBwYXRoIGNvbnN0 cmFpbnRzIEkgdGhpbmsgd2Ugc2hvdWxkIGluY2x1ZGUgc29tZXRoaW5nIG1vcmUuIFdoZW4gYSBj bGllbnQgbmVlZHMgdG8gc2V0dXAgYSBzZXJ2aWNlL0xTUCB0aGVyZSBtaWdodCBiZSBURSBjb25z dHJhaW50cyBhc3NvY2lhdGVkIHRvIHRoZSByZXF1ZXN0LiBXaGFuIHRoZSBWTg0KIG5lZWRzIHRv IGluY2x1ZGUgaXMgbm90IG9ubHkgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIGJ1dCBpbiBtYW55 IGNhc2VzIGlzIHNob3VsZCBiZSBURS1yZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uIEluIHRoaXMg Y2FzZSB3ZSBjb3VsZCBsZXZlcmFnZSBvbiB0aGUgb3ZlcmxheSB3b3JrIGJlaW5nIGRvbmUgZS5n LiBpbiBDQ0FNUCBhbmQgaW4gKDwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWwtaW50ZXJjb25uZWN0 ZWQtdGUtaW5mby1leGNoYW5nZS0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZmFycmVsLWludGVyY29ubmVjdGVkLXRlLWluZm8tZXhjaGFuZ2UtMDI8L2E+KS48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPllPVU5HJmd0OyZndDsgWWVzLCBpZiB3ZSBpbmNsdWRlIG5vbi1URSB1bmRlcmx5 aW5nIHRyYW5zcG9ydCBhcyBwYXJ0IG9mIHRoZSBBQ1ROIHNjb3BlLCB0aGVuICZuYnNwO3RoZSBU RS1yZWFjaGVhYmlsaXR5IG5lZWRzIHRvIGJlIGtub3duL2FkdmVydGlzZWQgYnkgdGhlIHNlcnZl ciBuZXR3b3JrIHRvIGNsaWVudHMgYXMg4oCYY2FwYWJpbGl0eeKAmSBhdHRyaWJ1dGUuDQogJm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6Ymx1ZSI+W1hpYW5dIEhhdmUgd2UgYWxyZWFkeSBjb25maW5lZCB0aGUgc2NvcGUg dG8gVEUgdHJhbnNwb3J0IG5ldHdvcmsgb25seT8mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6Ymx1ZSI+SSB0aGluayB3aGV0aGVyIHRoZSBURSBpbmZvcm1hdGlvbiBpcyBjb252 ZXllZCB0byB0aGUgY2xpZW50IGRlcGVuZHMgb24gdGhlIGRldGFpbHMgdGhlIGNsaWVudCB3YW50 cyB0byBrbm93LiBGcm9tIEFDVE4gd29yayBwb2ludCBvZiB2aWV3LCBpdCBzaG91bGQgYmUgY29u c2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSBjb25zdHJhaW50cw0KIHdvcnRoIGNvbnNpZGVyaW5nLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CEE853F7430D5mattabuedu_--